Пример за употреба и тестване на случаи на употреба Пълен урок

use case use case testing complete tutorial

Като начало, нека разберем „Какво е случай на употреба?“ и по-късно ще обсъдим „Какво е тестване на случаи на употреба?“ .

Случаят на употреба е инструмент за определяне на необходимото потребителско взаимодействие. Ако се опитвате да създадете ново приложение или да направите промени в съществуващо приложение, се правят няколко дискусии. Една от критичните дискусии, които трябва да направите, е как ще представите изискването за софтуерното решение.

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

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

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

• Случай за употреба
• Кой използва документите „Use Case“?
• Видове случаи на употреба
  • # 1) Слънчев ден Използвайте калъфи
  • # 2) Случаи за използване на дъждовен ден
• Случаи на използване на елементи
• Представителство
• Как да напиша случай на употреба?
• Използвайте диаграма на случая
• Потребителски действия
• Какво е тестване на случаи на употреба?
  • Някои факти
  • Как да създам шаблон за тест?
• Заключение
• Препоръчително четене

Случай за употреба

Случаят на употреба играе съществена роля в отделните фази на жизнения цикъл на разработката на софтуер. Случаят на употреба зависи от „Действия на потребителя“ и „Отговор на системата“ на действията на потребителя.

Това е документацията на „Действия“, извършени от Актьора / Потребителя и съответното „Поведение“ на Системата към Потребителя „Действия“. Случаи на употреба може или не може да доведе до постигане на цел от „Актьор / Потребител“ относно взаимодействията със системата.

В случай на употреба ще опишем ‘Как една система ще реагира на даден сценарий?’ . Той е „ориентиран към потребителя“, а не „ориентиран към системата“.

Той е „ориентиран към потребителя“: Ще посочим „какви са действията, извършени от потребителя?“ И „Какво виждат Актьорите в системата?“.

Той не е „ориентиран към системата“: Няма да уточняваме „Какъв е входът, даден на системата?“ И „Какъв е резултатът, произведен от системата?“.

Екипът на разработчиците трябва да напише „Случаи на използване“, тъй като фазата на развитие силно зависи от тях.

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

След внедряване на случая документът се тества и поведението на Системата се проверява съответно. В случай, че главната буква „А“ означава „Актьор“, буквата „S“ означава „Система“.

Кой използва документи „Use Case“?

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

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

Използване на документите:

• Разработчиците използват документите за внедряване на кода и неговото проектиране.
• Тестерите ги използват за създаване на тестови случаи .
• Заинтересованите страни в бизнеса използват документа за разбиране на софтуерните изисквания.

Видове случаи на употреба

Има 2 вида.

Те са:

• Слънчев ден
• Дъждовен ден

# 1) Слънчев ден Използвайте калъфи

Те са основните случаи, които най-вероятно се случват, когато всичко се справя добре. На тях се дава приоритет повече от останалите случаи. След като приключим делата, ние го даваме на екипа на проекта за преглед и гарантираме, че сме обхванали всички необходими случаи.

как да започнете нов проект в затъмнение

# 2) Случаи за използване на дъждовен ден

Те могат да бъдат определени като списък на крайните случаи. Приоритетът на такива случаи ще дойде след „Слънчеви случаи на употреба“. Можем да потърсим помощта на заинтересованите страни и продуктовите мениджъри, за да дадем приоритет на случаите.

Случаи на използване на елементи

По-долу са дадени различните елементи:

1) Кратко описание : Кратко описание, обясняващо случая.

2) Актьор : Потребители, които участват в Действия за случаи на употреба.

3) Предпоставка : Условия, които трябва да бъдат изпълнени преди започване на делото.

4) Основни Поток : „Основен поток“ или „Основен сценарий“ е нормалният работен процес в системата. Това е потокът от транзакции, извършени от Актьорите за постигане на техните цели. Когато актьорите взаимодействат със системата, тъй като това е нормалният работен процес, няма да има грешка и Актьорите ще получат очакваната продукция.

5) Алтернативен поток : Освен нормалния работен процес, системата може да има и „Алтернативен работен процес“. Това е по-рядкото взаимодействие, извършено от потребител със системата.

6) Изключение поток : Потокът, който пречи на потребителя да постигне целта.

7) Публикуване Условия : Условията, които трябва да бъдат проверени след приключване на делото.

Представителство

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

Пример за употреба:

Тук ще обясня казуса за „Вход“ към „Система за управление на училище“.

Точки, които трябва да се отбележат

• Често срещани грешки, които участниците правят с Use Case е, че или съдържа твърде много подробности за конкретен случай, или изобщо няма достатъчно подробности.
• Това са текстови модели, ако е необходимо, можем или не да добавим визуална диаграма към него.
• Определете приложимата предпоставка.
• Напишете стъпките на процеса в правилния ред.
• Посочете изискване за качество на процеса.

Как да напиша случай на употреба?

Обобщените по-долу точки ще ви помогнат да напишете следните:

=> Когато се опитваме да напишем казус, първият въпрос, който трябва да повдигне, е „Каква е основната употреба за клиента?“ Този въпрос ще ви накара да напишете вашите случаи от гледна точка на потребителя.

=> Трябва да сме получили шаблон за тях.

=> Тя трябва да бъде продуктивна, проста и силна. Силният случай на употреба може да впечатли публиката, дори ако има незначителни грешки.

=> Трябва да го номерираме.

=> Трябва да напишем стъпката на процеса в нейния ред.

=> Дайте правилно име на Сценариите, именуването трябва да става според целта.

=> Това е итеративен процес, което означава, че когато ги напишете за първи път, няма да е перфектен.

=> Идентифицирайте участниците в системата. Може да намерите куп актьори в системата.

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

Първоначално нека разгледаме първите актьори. Можем да имаме повече от един актьор с едно и също поведение.

Например , както купувачът, така и продавачът могат да „създадат акаунт“. По същия начин и „Купувачът, и продавачът“ могат да „търсят артикул“. И така, това са дублиращи се поведения и те трябва да бъдат премахнати. Освен да използваме дублираните случаи, трябва да имаме и по-общи случаи. Следователно трябва да обобщим случаите, за да избегнем дублиране.

=> Трябва да определим приложимата предпоставка.

Използвайте диаграма на случая

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

Фиг. No: UC 01

Както е показано в Фиг. No: UC 01 тя представлява диаграма, където Rectangle представлява „система“, овалът представлява „случай на употреба“, стрелката представлява „връзка“, а човекът представлява „потребител / актьор“. Той показва система / приложение, след това показва организацията / хората, които взаимодействат с него и показва основния поток на „Какво прави системата?“

Фиг. No: UC 02

Фиг. No: UC 03 - Използвайте диаграма на случая за влизане

Това е диаграмата на случаите на използване на случая „Вход“. Тук имаме повече от един актьор, всички те са поставени извън системата. Учениците, учителите и родителите се считат за основни действащи лица. Ето защо всички те са поставени от лявата страна на правоъгълника.

Администраторът и персоналът се считат за второстепенни актьори, затова ги поставяме от дясната страна на правоъгълника. Актьорите могат да влязат в системата, така че ние свързваме актьорите и случая за влизане с конектор.

Други функции, открити в системата, са Reset Password и Forgot password. Всички те са свързани със случая за вход, затова ги свързваме към конектора.

Потребителски действия

Това са действията, които се извършват от потребителя в дадена система.

Например: Търсене в сайта, добавяне на елемент към предпочитани, опит за контакт и т.н.

Забележка:

• Система е „каквото и да разработвате“. Това може да бъде уебсайт, приложение или друг софтуерен компонент. Обикновено е представен от правоъгълник. Съдържа случаи на употреба. Потребителите се поставят извън „правоъгълника“.
• Случаи на употреба обикновено са представени от овални форми, указващи действията вътре в него.
• Актьори / потребители са хората, които използват системата. Но понякога това могат да бъдат други системи, човек или друга организация.

Какво е тестване на случаи на употреба?

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

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

Някои факти

• Не се извършва тестване, за да се определи качеството на софтуера.
• Дори да е тип тестване от край до край, това няма да осигури цялостното покритие на потребителското приложение.
• Въз основа на резултата от теста, известен от тестването на Use Case, не можем да решим внедряването на производствената среда.
• Той ще открие дефектите при интеграционното тестване.

Пример за тестване на случай на употреба:

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

След всичко това той ще провери. Така че това е Пример за логически свързани поредици от стъпки, които потребителят ще извърши в система за изпълнение на задачата.

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

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

Етап 1: Първата стъпка е преглед на документите за употреба.

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

Стъпка 2: Трябва да се уверим, че случаите на използване са атомни.

Например: Помислете за „Система за управление на училище, която има много функционалности като„ Вход “,„ Показване на подробности за ученика “,„ Показване на марки “,„ Показване на присъствието “,„ Контакт с персонала “,„ Изпращане на такси “и др. В този случай ние се опитваме да подгответе Използвайте случаи за функционалност „Вход“.

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

Стъпка 3: Трябва да проверим нормалния работен процес в системата.

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

Стъпка 4: Уверете се, че алтернативният работен процес в системата е завършен.

Стъпка 5: Трябва да се уверим, че всяка стъпка в случая на употреба е проверима.

Всяка стъпка, обяснена в теста за употреба, е проверима.

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

Стъпка 6: След като сме съживили тези случаи, можем да напишем тестовите случаи.

Трябва да напишем тестови случаи за всеки нормален и алтернативен поток.

Например , Да разгледаме случая „Показване на бележки за ученици“ в система за управление на училище.

Име на случая на употреба: Показване на студентски марки

Актьори: Студенти, учители, родители

Предварително условие:

1) Системата трябва да бъде свързана към мрежата.

две) Актьорите трябва да имат „студентска книжка“.

Случай за използване на „Показване на марки на ученици“:

Съответстващ тестов случай за случай „Показване на студентски марки“:

Моля, обърнете внимание, че показаната тук таблица за тестови случаи съдържа само основната информация. „Как да създам шаблон за тест“ е обяснено подробно по-долу.

Таблицата показва „Тестовия случай“, съответстващ на случая „Показване на марка на ученика“, както е показано по-горе.

Най-добрият начин да напишете тестови случаи е първо да напишете тестовите случаи за „Основния сценарий“ и след това да ги напишете за „Алтернативни стъпки“. „ Стъпки в тестови случаи се получават от документите за употреба. Първото ‘ Стъпка от случая „Показване на студентска марка“ „Enter Student Name“ ще стане първият Стъпка в „Тестовия случай“.

Потребителят / Актьорът трябва да може да влезе в него. Това се превръща в очакван резултат .

Можем да потърсим помощта на техника за проектиране на тестове като „ анализ на гранична стойност “ , „Разделяне на еквивалентност“, докато подготвяме тестовите случаи. Техниката за проектиране на тестове ще помогне да се намали броят на тестовите случаи и по този начин да се намали времето, необходимо за тестване.

Как да създам шаблон за тест?

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

На пазара има няколко инструмента, които могат да помогнат в този контекст. ' TestLodge ’е един от тях, но не е безплатен инструмент. Трябва да го закупим.

Нуждаем се от шаблон за документиране на тестовия случай. Нека разгледаме един често срещан сценарий „FLIPKART влизане“, с който всички сме запознати. Електронната таблица на Google може да се използва за създаване на таблица с тестови случаи и споделяне с членовете на екипа. За момента използвам документ на Excel.

Ето пример

=> ИЗТЕГЛЕТЕ този шаблон за таблица от тестови случаи тук

Първо, назовете тестовия лист с подходящо име. Пишем тестови случаи за определен модул в проект. И така, трябва да добавим 'Име на проекта' и ‘Модул на проекта ’Колони в таблицата с тестови случаи. Документът трябва да включва името на създателя на тестовите случаи.

Затова добавете 'Създадено от' и „Създадена дата“ колони. Документът трябва да бъде прегледан от някой (ръководител на екип, ръководител на проекти и т.н.), така че добавете 'Прегледан от' колона и ‘Прегледана дата’ .

Следващата колона е „Тестов сценарий“ , тук сме предоставили примерния сценарий за тест ‘Потвърдете влизането във Facebook’ . Добавете колоните „Идентификационен номер на тестовия сценарий“ и ‘Описание на тестовия случай’ .

За всеки тест сценарий ще напишем ‘Тестови случаи ’. Така че, добавете колоните „Идент. № на тестовия случай“ и ‘Описание на тестовия случай ’. За всеки тестов сценарий ще има „Условие за публикуване“ и „Предварително условие“ . Добавете колоните ‘Post-Condition’ и ‘Pre-Condition’.

Друга важна колона е „Тестови данни“ . Той ще съдържа данните, които използваме за тестване. Тестовият сценарий трябва да приема очакван резултат и действителен резултат. Добавете колоната 'Очакван резултат' и „Действителен резултат“. „Състояние“ показва резултата от изпълнението на тестовия сценарий. Може да бъде или преминаване / неуспех.

Тестерите ще изпълняват тестовите случаи. Трябва да го включим като ‘Изпълнено от’ и ‘Изпълнена дата’ . Ще добавим „Команди“, ако има такива.

Заключение

Надявам се, че бихте имали ясна представа за случаи на употреба и тестване на случаи на употреба.

Писането на тези случаи е итеративен процес. Трябва само малко практика и добри познания за система, за да напишете тези случаи.

Накратко, можем да използваме ‘Use Case testing’ в приложение, за да намерим липсващите връзки, непълни изисквания и др. Намирането им и модифицирането на системата ще постигнат ефективност и точност на системата.

Имате ли предишен опит със случаи на употреба и тестване? Чувствайте се свободни да споделите с нас в раздела за коментари по-долу.

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

• Функционално тестване срещу нефункционално тестване
• Уроци за задълбочено затъмнение за начинаещи
• Алфа тестване и бета тестване (Пълно ръководство)
• Урок за тестване на DevOps: Как DevOps ще повлияе на QA тестването?
• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Урок за тестване на използваемост: Пълно ръководство за начало
• Урок за тестване на GUI: Пълно ръководство за тестване на потребителския интерфейс (UI)
• Урок за деструктивно тестване и безразрушително тестване