Този урок обяснява какво е тестови сценарий, както и значението, прилагането, примерите и шаблоните на тестовия сценарий:
Всяка функционалност/функция на софтуера, която може да бъде тествана, се нарича тестови сценарий. При писането на тестови сценарии се взема предвид гледната точка на крайния потребител.
Това ръководство ще ви помогне да си отговорите на въпросите: защо са необходими тестови сценарии, кога се пишат тестови сценарии и как се пишат тестови сценарии.
Какво представлява тестовият сценарий?
Разгледайте една хипотетична ситуация: Има огромен океан. Трябва да прекосите океана от единия до другия бряг. Например, от Мумбай, крайбрежие на Индия, до Коломбо, крайбрежие на Шриланка.
Можете да изберете следните начини на пътуване:
(i) авиокомпания: Вземете полет до Коломбо
(ii) Водни пътища: Предпочитайте кораб, за да пътувате до Коломбо
(iii) Железници: Вземете влак до Шриланка
Сега за тестовите сценарии: Пътуването от крайбрежието на Мумбай до крайбрежието на Коломбо е функционалност, която трябва да бъде изпитана.
Сценариите за тестване включват:
- Пътуване с авиокомпания,
- Пътуване по водни пътища или
- Пътуване с влак.
Тези тестови сценарии ще имат тестови случаи.
Случаите за изпитване, които могат да бъдат написани за горните сценарии за изпитване, включват:
Сценарий за изпитване: Пътуване с авиокомпания
Случаите за тестване могат да включват сценарии като:
- Полетът е по разписание.
- Полетът не е по разписание.
- Възникнала е извънредна ситуация (проливни дъждове и буря).
По същия начин може да се напише отделен набор от тестови случаи за останалите сценарии.
Сега нека преминем към сценариите за технологични тестове.
Всичко, което може да бъде тествано, е тестови сценарий. По този начин можем да заявим, че всяка функционалност на софтуера, която се тества, може да бъде разделена на множество по-малки функционалности и може да бъде наречена "тестови сценарий".
Преди да се достави какъвто и да е продукт на клиента, качеството на продукта трябва да бъде оценено. Сценарият за тестване спомага за оценка на функционалното качество на софтуерното приложение, което е в съответствие с бизнес изискванията.
Сценарият на тестващия е процес, при който тестващият тества софтуерно приложение от гледна точка на крайния потребител. Изпълнението и качеството на софтуерното приложение се оценяват обстойно преди внедряването му в производствена среда.
Значение на тестовия сценарий
- Един тестови сценарий може да има множество "тестови случаи". Той може да се представи като голямо панорамно изображение, а тестовите случаи са малките части, които са важни за завършване на панорамата.
- Това е твърдение на един ред, а тестовите случаи се състоят от описание на стъпки, за да се изпълни целта на твърдението за тестовия сценарий.
- Пример:
Сценарий за изпитване: Извършете плащането за ползваната таксиметрова услуга.
Това ще включва множество тестови случаи, както е посочено по-долу:
(i) Метод на плащане: PayPal, Paytm, кредитна/дебитна карта.
(ii) Извършеното плащане е успешно.
(iii) Извършеното плащане е неуспешно.
(iv) Процесът на плащане се прекъсва междувременно.
(v) Нямате достъп до методите за плащане.
(vi) Приложението се разпада между тях.
- По този начин тестовите сценарии помагат за оценяване на софтуерното приложение според реалните ситуации.
- Определените тестови сценарии помагат за раздвояване на обхвата на тестването.
- Това раздвояване се нарича приоритизиране, което помага за определяне на важните функционалности на софтуерното приложение.
- Приоритетното тестване на функционалностите подпомага до голяма степен успешното внедряване на софтуерното приложение.
- Тъй като тестовите сценарии се приоритизират, най-важните функционалности могат лесно да бъдат идентифицирани и тествани приоритетно. Това гарантира, че по-голямата част от важните функционалности работят добре и свързаните с тях дефекти са надлежно уловени и отстранени.
- Сценариите за тестване определят потока на бизнес процесите на софтуера и по този начин е възможно тестване на приложението от край до край.
Разлика между тестови сценарий и тестови случай
| Сценарий за изпитване | Тестови случаи |
|---|---|
| Тестовият сценарий е концепция. | Тестовите случаи са решенията за проверка на тази концепция. |
| Сценарият за изпитване е функционалност от високо ниво. | Случаите за тестване са подробна процедура за тестване на функционалността на високо ниво. |
| Сценариите за тестване се извеждат от изискванията/потребителските истории. | Случаите за тестване се извеждат от сценариите за тестване. |
| Сценарият за тестване е "Каква функционалност трябва да се тества". | Тестовите случаи са "Как да тестваме функционалността". |
| Сценариите за тестване имат множество тестови случаи. | Тестовият случай може да бъде или да не бъде свързан с няколко тестови сценария. |
| Единичните тестови сценарии никога не могат да бъдат повторени. | Един тестови случай може да се използва многократно в различни сценарии. |
| Необходими са кратки документи. | Изисква се подробна документация. |
| За финализиране на тестовия сценарий са необходими сесии за мозъчна атака. | Необходими са подробни технически познания за софтуерното приложение |
| Спестява време, тъй като не се изискват дребни детайли. | Отнема много време, тъй като трябва да се обърне внимание на всяка дребна подробност. |
| Разходите за поддръжка са ниски, тъй като необходимите ресурси са малко. | Разходите за поддръжка са високи, тъй като са необходими много ресурси. |
Защо са необходими тестови сценарии?
Сценариите за тестване се извличат от изискванията или потребителските истории.
- Да вземем за пример тестови сценарий за резервация на такси.
- Сценариите могат да бъдат опции за резервация на такси, методи на плащане, GPS проследяване, пътна карта, която се показва правилно или не, информация за таксито и шофьора, която се показва правилно или не, и т.н. - всички те са изброени в шаблона за тестови сценарии.
- Сега да предположим, че тестовият сценарий е да се провери дали услугите за определяне на местоположението са включени, а ако не са включени, да се покаже съобщението "Включете услугите за определяне на местоположението. Този сценарий е пропуснат и не е посочен в шаблона за тестови сценарии.
- Сценарият "Услуга за определяне на местоположението" поражда други тестови сценарии, свързани с него.
Те могат да бъдат:
- Услугата за местоположение е в сив цвят.
- Услугата за местоположение е включена, но няма интернет.
- Ограничения на услугите на място.
- Показва се грешното местоположение.
- Липса на един сценарий може да означава, че ще пропуснете много други ключови сценарии или тестови случаи . Това може да има голямо значение отрицателно въздействие Това води до големи загуби на ресурси (срокове).
- Тестовите сценарии помагат до голяма степен за избягване на изчерпателно изпитване Той гарантира, че всички важни и очаквани бизнес потоци се тестват, което допълнително подпомага цялостното тестване на приложението.
- Те спестяват време. Също така не се изисква много по-подробно описание според тестовите случаи. Посочва се описание в един ред за това какво да се тества.
- Сценариите за изпитване се пишат след мозъчни атаки на членовете на екипа. Следователно вероятността да се пропусне някой сценарий (решаващ или незначителен) е минимална. Това се прави, като се имат предвид техническите особености, а също и бизнес потока на софтуерното приложение.
- Освен това тестовите сценарии могат да бъдат одобрени от бизнес анализатор или от двамата, които имат ясни познания за тестваното приложение.
По този начин тестовите сценарии са незаменима част от SDLC.
Изпълнение на тестови сценарии
Нека да разгледаме прилагането на тестови сценарии или как се пишат тестови сценарии:
- Формират се епични/бизнес изисквания.
- Пример за Epic : Създаване на акаунт в Gmail. Epic може да бъде основна функция на приложение или бизнес изискване.
- Епичните проекти се разделят на по-малки потребителски истории в рамките на спринтовете.
- Потребителските истории се извеждат от Epics. Тези потребителски истории трябва да бъдат базирани и одобрени от заинтересованите страни.
- Сценариите за тестване се извличат от потребителски истории или BRS (документ за бизнес изисквания), SRS (документ за спецификация на системните изисквания) или FRS (документ за функционални изисквания), които са финализирани и базирани.
- Тестерите пишат тестовите сценарии.
- Тези тестови сценарии се одобряват от ръководителя на екипа, бизнес анализатора или ръководителя на проекта в зависимост от организацията.
- Всеки тестови сценарий трябва да бъде свързан с поне една потребителска история.
- Трябва да се определят положителни и отрицателни сценарии за изпитване.
- Историите на потребителите се състоят от Критерии за приемливост като :
- Критериите за приемане са списък от условия или състояние на намерение за изискванията на клиента. Очакванията на клиента, както и недоразуменията се вземат предвид при писането на критериите за приемане.
- Те са уникални за една потребителска история и всяка потребителска история трябва да има поне един критерий за приемане, който трябва да може да се тества самостоятелно.
- Критериите за приемане помагат да се определи кои функции са в обхвата и кои са извън обхвата на проекта. Тези критерии трябва да включват функционални и нефункционални функции.
- Бизнес анализаторите пишат критериите за приемане, а собственикът на продукта ги одобрява.
- В някои случаи собственикът на продукта може сам да напише критериите.
- Сценариите за изпитване могат да бъдат получени от критериите за приемане.
Примери за тестови сценарии
#1) Тестови сценарии за Kindle App
Kindle е приложението, което позволява на електронните четци да търсят електронни книги онлайн, да ги изтеглят и купуват. Amazon Kindle дава на читателя на електронни книги реалното преживяване да държи книга в ръка и да я чете. Дори обръщането на страниците е добре симулирано в приложението.
Сега нека запишем тестовите сценарии. ( Забележка: По-долу са изброени ограничени сценарии, за да се получи обща представа за написването на тестовия сценарий. От него могат да бъдат извлечени множество тестови случаи).
| Сценарии за тестване # | Сценарии за изпитване |
|---|---|
| 1 | Проверете дали приложението Kindle се стартира правилно. |
| 2 | Проверете дали резолюцията на екрана се настройва според различните устройства след стартиране на приложението. |
| 3 | Проверете дали показаният текст е четлив. |
| 4 | Проверете дали опциите за увеличаване и намаляване на мащаба работят. |
| 5 | Проверете дали съвместимите файлове, импортирани в приложението Kindle, могат да се четат. |
| 6 | Проверете капацитета за съхранение на Kindle App. |
| 7 | Проверете дали функцията за изтегляне работи правилно. |
| 8 | Проверете дали симулацията на обръщане на страници работи правилно |
| 9 | Проверете съвместимостта на форматите на електронните книги с приложението Kindle. |
| 10 | Проверка на шрифтовете, поддържани от приложението Kindle. |
| 11 | Проверете живота на батерията, използван от приложението Kindle. |
| 12 | Проверете работата на Kindle в зависимост от мрежовата свързаност (Wi-Fi, 3G или 4G). |
От всеки сценарий за изпитване, посочен по-горе, могат да се извлекат множество случаи на изпитване.
#2) Критерии за приемане на документи на Google
"Google docs" е уеб базирано приложение за създаване, редактиране и споделяне на текстови документи, електронни таблици, слайдове и формуляри. Достъпът до всички файлове се осъществява онлайн с помощта на уеб браузър с интернет връзка.
Създадените документи могат да се споделят като уеб страница или готов за печат документ. Потребителят може да зададе ограничения за това кой може да разглежда и редактира документите. Един документ може да се споделя съвместно и да се работи по него от различни лица от различни географски местоположения.
По-долу са посочени ограничени тестови сценарии за общо разбиране. Задълбочените тестови сценарии за документи на Google могат да бъдат отделна тема.
| Критерии за приемливост # | Критерии за приемане |
|---|---|
| 1 | Програмите Word, Sheets или Forms могат да бъдат отворени успешно и без грешка. |
| 2 | Налични са шаблони за документи, листове и слайдове. |
| 3 | Наличните шаблони са достъпни за потребителите. |
| 4 | Използваният шаблон може да се редактира (например: шрифтове, размер на шрифта, добавяне на текст, изтриване на текст, вмъкване на слайд). |
| 5 | Ако временно не е налична интернет връзка, файлът може да се съхранява локално и да се качва при наличие на интернет връзка. |
| 6 | Промените, направени от няколко потребители, не се презаписват. |
| 7 | Няколко потребители могат да работят върху един документ. |
| 8 | Извършената работа се съхранява, ако интернет връзката се изгуби по време на качване на файл. |
| 9 | Ограниченията за споделяне се прилагат правилно. |
| 10 | Потребителите с ограничение на прегледа не могат да извършват никакви редакции на документите. |
| 11 | Документите могат да бъдат публикувани в интернет за широката общественост. |
| 12 | Направените промени в документите се записват с времеви печат &; данни за автора. |
Броят на тестовите сценарии ще бъде многоброен и огромен за Google Docs. В такива случаи обикновено само критериите за приемане се определят и одобряват от заинтересованите страни, а членовете на екипа работят по тези критерии за приемане. Писането на тестови случаи или по-скоро на тестови сценарии може да бъде изтощителна задача за огромни приложения.
Тези критерии за приемане играят важна роля в итеративното планиране на процесите и никога не трябва да се пренебрегват. Предварителното им определяне предотвратява изненади или сътресения в края на спринтовете или версиите.
Даден е предварително условие.
Когато за извършване на дадено действие.
След това резултатът е очакван.
Форматите "Дадено", "Когато" и "Тогава" са полезни за определяне на критериите за приемане.
Пример за шаблон на тестови сценарий
| Използвайте ID на историята # | Идентификационен номер на тестовия сценарий # | Версия # | Сценарии за изпитване | # Брой тестови случаи | Значение |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Проверете дали приложението Kindle се стартира правилно. | 4 | Висока |
| USID12.1 | TSID12.1.2 | Kin12.4 | Проверете капацитета за съхранение на Kindle App. | 3 | Среден |
Заключение
При всяко тестване на софтуер, разбирането на жизнения цикъл и определянето на тестови сценарии е много важен елемент. Качеството на софтуера може да се подобри чрез добра основа за тестови сценарии. Често използването на тестови случаи и тестови сценарии може да се обърка.
Въпреки това, основното правило е, че тестовият сценарий се използва за написването на множество тестови случаи или можем да кажем, че тестовите случаи произтичат от тестовите сценарии. Добре дефинираните тестови сценарии гарантират добро качество на софтуера.