5 важни диаграми, които тестерите трябва да научат как да използват

5 important diagrams that testers need learn how use

Ако не бяха снимки, нямаше записи на ранна история, проходими познания и еволюция на езика.

Не за прекалено драматизиране, но диаграмите имат своето специално място дори в свят с силно развити и усъвършенствани форми на писане и изразяване.

В технологичната индустрия нашите диаграми са ни скъпи.

Ето някои от най-известните, с които ние, тестерите, често контактуваме и как ги използваме.

Какво ще научите:

• 5 диаграми, които тестерите трябва да научат как да използват
• # 1) Диаграми на потока:
• # 2) Диаграми за преход на състоянието:
• # 3) Контекстни диаграми:
• # 4) Мисловни карти:
• # 5) ER диаграми:
• # 6) Бонус: Макет на екрани / Wireframes:
• За да приключите - Как можете да създадете тези диаграми, ако е необходимо?
• Препоръчително четене

5 диаграми, които тестерите трябва да научат как да използват

Ето ни.

# 1) Диаграми на потока:

Диаграмите на потока са най-подходящи за илюстрации на процеси. Те използват специфични символи за всяка задача / вид действие, което се извършва в рамките на процеса. Той позволява решения, клонове, цикли и т.н., което го прави идеален инструмент за документиране и разбиране.

Тестерите обикновено намират блок-схемите в тестовия план, тестовата стратегия, артефакти на изискванията (BRD, FRD и др.) Или други документи на процеса.

Най-често използваните символи и техните значения в блок-схема са:

• Овали За стартиране и спиране
• Правоъгълници- За обработка / или задача
• Диамант- За решения

За пълна информация относно формите на диаграмата, вижте Блок-схема Символи .

Да се ​​разбере процес или поток на контрол чрез блок-схема е супер просто. Помага за запомнянето, разбирането и служи като бърза справка.

Прочетете също => Как да напиша сложни тестове за бизнес логика, използвайки техниката на таблицата за вземане на решения

Ето два начина, по които тестерите използват диаграми на потока:

а) Диаграми на потока за контролен поток и статистически анализ:

Цикломатична сложност е показател, който ни помага да измерим колко сложна е дадена софтуерна програма. Една от възможностите за познаване на цикломатичната сложност е, че тя ни помага да разберем степента на единично тестване, което трябва да се направи, за да се постигне пълно покритие (повече информация и връзки по-долу).

Диаграмата на потока е метод за преминаване към тази мярка.

Нека се научим как да го изчислим Cyclomatic Complexity за следващата програма чрез контролна схема.

Просто създайте диаграма на контролния поток, както е показано по-долу, и използвайте тази формула:

Цикломатична сложност: = Брой връзки или линии - Брой възли + 2

От диаграмата броят на възлите е 7, а връзките са 7.

Следователно цикломатичната сложност на този код е 7-7 + 2 = 2.

Нуждаете се от повече информация за това как да използвате диаграмата на контролния поток и цикломатичната сложност?

Виж това:

• Корелация между циклометричната сложност и покритието на кода по време на тестване на бяла кутия
• Цикломатичната сложност на McCabe и защо не го използваме

б) Блок-схеми за илюстрация на процеса:

Следва процесът на проследяване на дефекти, представен във формат на диаграма. Както виждате, усвояването и прилагането е изключително лесно:

(Забележка:Щракнете върху изображението за увеличен изглед)

# 2) Диаграми за преход на състоянието:

Таблиците или диаграмите за преход на състоянието са чудесни инструменти за анализ, когато разглеждате сложни системи, които претърпяват много промени от едно състояние в друго.

За начинаещите, които си мислят „какво е преход на държавата?“ - Помислете за крушка, която се управлява от превключвател. Превключвателят може да бъде включен / изключен. Така че състоянието, в което крушката може да бъде в даден момент от време, е ВКЛЮЧЕНО или ИЗКЛЮЧЕНО и събитието / действието, което я кара да преминава от едно състояние в друго, е превключването на превключвателя.

Това може да бъде показано под формата на диаграма или таблица. Както по-долу:

Просто, нали? Нека вземем нещо малко по-сложно. Погледнете диаграмата за преход на състояние за система за билети. Това е доста просто и лесно за разбиране.

Моля, обърнете внимание, че диаграмите за преход на състоянието обикновено са ориентирани към бизнес субекта, а не визуално ориентирани към навигация по страница.

Например: Основният бизнес субект в нашия случай е самият билет, който е създаден чрез приложението. Първата част, съставяща билета, може да включва навигация в системата през няколко страници:

• Страница 1-> Изберете не. на пътници - възрастни, деца и възрастни.
• Страница 2-> Изберете вида на билета - дневна, седмична, месечна и т.н.
• Страница 3-> Прегледайте подробности и финализирайте.
• Страница4-> Направете плащане и т.н.

Така че, може да има много различни визуални преходи на страница по страница, но самият билет е в състояние на изработка. Така че обикновено не създаваме ST диаграма за визуални преходи (можете, ако искате, но не се използва толкова често), ние го правим за държавни преходи на основния бизнес обект.

След като се създаде диаграмата ST, можете да я използвате, за да идентифицирате лесно сценариите от край до край и транзакциите на крайния потребител, както следва:

Трите жълти линии са 3 случая от край до край, които при тестване ще покрият най-критичните и най-използваните области на приложението. Това е толкова полезен инструмент за създаване на смислени тестови случаи и от край до край на тестове за приемане.

За много по-изчерпателно обяснение и използване в реалния свят, вижте => Техника за държавно преходно тестване за тестване на сложни приложения

# 3) Контекстни диаграми:

Софтуерните системи рядко функционират като независими единици. Прости приложения, като калкулатор, бележник и др., Могат да работят сами, но корпоративното приложение често се свързва с много други приложения.

Например: Системата за изплащане на заплати може да взаимодейства със счетоводно приложение, система за разписания за часове на служителите и портал за човешки ресурси за подробности за служителите. Контекстните диаграми са отлични диаграми, които показват всички тези взаимоотношения по лесен за разбиране начин.

Следва контекстна диаграма за току-що описаната система за заплати:

Контекстната диаграма много ясно показва контекста на определена система с всички останали обекти, които са свързани с нея. За просто обяснение проверете тук =>

За просто обяснение проверете тук => Диаграма на контекста на системата

Контекстните диаграми помагат на тестерите да разберат системата в по-широк смисъл и помагат при създаването на тестови стратегии, които включват тези входящи и изходящи връзки, които системата има с останалите обекти. Може да не създадем контекстна диаграма като част от нашия процес на тестване, но ако е налице, това помага за голямо разбиране.

# 4) Мисловни карти:

Умната карта проследява зает ум, който прескача от тема на тема; всяка мисъл се задълбочава и разклонява по-широко с всяка идея. Това е форма на диаграма, като просто започнете с основната си идея и документирате всяка отделна подмисъл, която произхожда от нея.

sql заявки интервюиране въпроси и отговори за 3 години опит

Умните карти могат да се използват за всичко и всичко. Въпреки че тепърва ще се появяват в IEEE, CMMI или други стандартни шаблони или обработват документи, те все още са много популярна част от културата на софтуерната индустрия.

Едно много популярно използване на умствените карти е проследяването на изследователски тестове. (Знам, знам, мислите си, защо изобщо трябва да се проследява изследователското тестване? Това е така, защото с бързи цикли на разработка, пъргави и други по-бързи методи за разработване на софтуер, става все по-малко вероятно тестерите да намерят време и обхват за пълна документация. Това означава, че степента на проучване нараства и трябва да бъде укрепена. Умните карти могат да направят точно това за вас.)

Например: Следва диаграма за приложение за електронна търговия, където просто проследявате тестването си с мисловна карта, както следва:

Тестерите може да не получат картите на ума като входни данни. Но може да видим ситуации, когато трябва да ги създадем. Това е много лесно. Започнете с вашата централна идея или отправна точка и следвайте къде ви отвеждат мислите ви. Има много прости и лесни безплатни онлайн инструменти, които можете да използвате за картографиране на ума. Това е, което използвах, за да нарисувам горното карта тук.

За повече информация и инструменти разгледайте => Картографиране на ума при тестване на софтуер - начини да направим тестването по-забавно!

# 5) ER диаграми:

Диаграмите Entity-Relationship (ER) се използват за моделиране на база данни. Те ни помагат да разберем таблиците, техните полета и как полетата в една таблица са свързани с полета в други таблици в системата на DB. Той показва визуално компонентите на вашата DB система и връзките между тях.

Диаграмите на ER също действат като първоначално пробно пускане на DB модела и визуализация, преди DB системите да бъдат проектирани и изградени.

ER диаграмите имат обекти (екземплярите на DB таблици) и техните взаимоотношения (едно към едно, едно към много, едно към задължително и т.н.), представени с помощта на кутии и съединители на пачи крак. )

Има много вариации на ER диаграмите, но най-простата версия може да изглежда по-долу:

Изображение Източник

За бързо въведение и обяснение проверете:

• Диаграма на връзката между субектите (ERD) Видео за обучение
• Диаграма на връзката между субектите (ERD)

# 6) Бонус: Макет на екрани / Wireframes:

Wireframes са или HTML, или прости изображения (екранни снимки), които ни показват бъдещата страница / компонент на потребителския интерфейс схематично.

Wireframes са благословия за тестерите, тъй като ни улесняват изключително лесно да визуализираме крайния продукт и да можем да подобрим техния процес на анализ на тестовия дизайн. Това означава по-добри тестови сценарии, по-добри тестови случаи и от своя страна по-висока ефективност на теста.

Wireframes могат да бъдат прости ръчно рисувани изображения или интерактивно създадени структури на уеб страници или всякакви други диаграми, които са представителни за крайната система.

Един прост каркас за екрана за вход може да бъде както по-долу:

Ето бърза връзка за разбиране на начина, по който екипите за QA използват телени рамки за ранно тестване и някои инструменти за тяхното създаване => Wireframes - трябва ли наистина да бъдат тествани? И ако да, как?

За да приключите - Как можете да създадете тези диаграми, ако е необходимо?

Най-често тестерите интерпретират повечето от гореспоменатите диаграми. Но рядко може да се наложи да ги създадем. MS Visio и SmartDraw са чудесни инструменти за използване. Ако обаче търсите нещо безплатно и леко (без инсталиране и настройка), вижте тук.

Когато нямате достъп до интернет и всичко, което имате, е вашата дума или боя, можете да използвате наличните фигури за създаване на тези диаграми (добре, поне повечето от тях). Това е най-малко любимият ми метод, тъй като отнема време и не е толкова лесен за употреба, но ще го направи.

За автора: Тази статия е написана от члена на нашия екип Swati.

И така, какви диаграми използвате и кои са вашите любими?

Препоръчително четене

• Съвети за тестване на софтуер за начинаещи тестери
• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Какво е тестване на компоненти или модули (научете с примери)
• Какво е сравнително тестване (научете с примери)
• Тестерите губят ли сцеплението си при тестване поради автоматизация?
• Глобалният бизнес за тестване на софтуер скоро ще достигне $ 28,8 милиарда
• Как да запазите мотивацията жива в софтуерните тестери?
• Изтегляне на eBook за тестване на Primer