what is test scenario
Този урок обяснява какво е тестов сценарий заедно с важността, изпълнението, примерите и шаблоните на тестовия сценарий:
Всяка софтуерна функционалност / функция, която може да бъде тествана, се счита за тестов сценарий. Перспективата за крайния потребител се взема предвид при написването на тестови сценарии.
Този урок ще ви помогне да отговорите на въпросите: защо са необходими тестови сценарии, кога са написани тестови сценарии и как да напишете тестовите сценарии.
Какво ще научите:
Какво е тест сценарий?
Помислете за хипотетична ситуация: Има необятен океан. Трябва да пътувате през океана от един морски бряг на друг. Например, от Мумбай, Индийски бряг до Коломбо, морския бряг на Шриланка.
Режимът на пътуване, който можете да изберете, е:
(i) Дихателни пътища: Вземете полет до Коломбо
(ii) Водни пътища:Предпочитайте кораб за пътуване до Коломбо
(iii) Железници:Вземете влак до Шриланка
Сега за тестовите сценарии: Пътуването от брега на Мумбай до морския бряг на Коломбо е функционалност, която предстои да бъде тествана.
Тестовите сценарии включват:
- Пътуване с Airways,
- Пътуване по водни пътища или
- Пътуване с железници.
Тези тестови сценарии ще имат тестови случаи.
Тестовите случаи, които могат да бъдат написани за горните тестови сценарии, включват:
Тест сценарий: Пътуване с авиолинии
Тестовите случаи могат да включват сценарии като:
- Полетът е според определеното време.
- Полетът не е по разписание.
- Последва извънредна ситуация (обилни валежи и буря).
По същия начин може да се напише отделен набор от тестови случаи за останалите сценарии.
Сега нека да стигнем до сценариите за технологични тестове.
Всичко, което може да бъде тествано, е тестов сценарий. По този начин можем да заявим, че всяка софтуерна функционалност, която е в процес на изпитване и може да бъде разделена на множество по-малки функционалности и може да се нарече „Тестов сценарий“.
въпроси за интервю за осигуряване на качество за по-свежи
Преди да доставите какъвто и да е продукт на клиента, качеството на продукта трябва да бъде оценено и оценено. Тестовият сценарий помага за оценка на функционалното качество на софтуерно приложение, което е в съответствие с неговите бизнес изисквания.
Тестващият сценарий е процес, при който тестващият тества софтуерно приложение от гледна точка на крайния потребител. Ефективността и качеството на софтуерното приложение се оценяват задълбочено преди внедряването в производствената среда.
Значение на тестовия сценарий
- Един тестов сценарий може да има множество „Тестови случаи“. Може да се разбере като голямо панорамно изображение и тестовите случаи са малките части, които са важни за завършване на панорамата.
- Това е едноредово изявление и тестовите случаи се състоят от стъпково описание, за да се изпълни целта на изявлението на тестовия сценарий.
- Пример:
Тест сценарий: Направете плащането за таксиметровото обслужване на разположение.
Това ще има множество тестови случаи, както е посочено по-долу:
(i) Начин на плащане, който ще се използва: PayPal, Paytm, кредитна / дебитна карта.
(ii) Плащанетонаправено е успешно.
(iii) Извършеното плащане е неуспешно.
(iv) Плащанетопроцес, прекъснат между тях.
(v) Нямам достъп до начините на плащане.
(ние) Приложениетосе разпада между тях.
- По този начин тестовите сценарии помагат за оценка на софтуерното приложение според реалните ситуации.
- Тестовите сценарии, когато са определени, помагат за раздвоение на обхвата на тестване.
- Това раздвоение се нарича приоритет, което помага при определянето на важните функционалности на софтуерното приложение.
- Приоритетното тестване на функционалностите до голяма степен спомага за успешното внедряване на софтуерното приложение.
- Тъй като тестовите сценарии получават приоритет, най-важните функционалности могат лесно да бъдат идентифицирани и тествани с приоритет. Това гарантира, че по-голямата част от ключовите функционалности работят добре и дефектите, свързани с нея, са надлежно уловени и отстранени.
- Тестовите сценарии определят потока на бизнес процеса на софтуера и по този начин е възможно цялостно тестване на приложението.
Разлика между сценария на теста и тестовия случай
Тест сценарий | Тестови случаи |
---|---|
Изисква се кратка документация. | Необходима е подробна документация. |
Тестовият сценарий е концепция. | Тестовите случаи са решенията за проверка на тази концепция. |
Тестовият сценарий е функционалност от високо ниво. | Тестовите случаи са подробна процедура за тестване на високо ниво на функционалност. |
Тестовите сценарии са получени от Изисквания / Потребителски истории. | Тестовите случаи са получени от тестови сценарии. |
Тестовият сценарий е „Каква функционалност трябва да се тества“ | Тестовите случаи са „Как да тествате функционалността“. |
Тестовите сценарии имат множество тестови случаи. | Тестовият случай може или не може да бъде свързан с множество тестови сценарии. |
Сценариите за единични тестове никога не се повтарят. | Един тестов случай може да се използва няколко пъти в различни сценарии. |
За финализиране на тестов сценарий са необходими мозъчни атаки. | Необходими са подробни технически познания за софтуерното приложение |
Пестене на време като подробности за минутите не се изисква. | Отнема време, тъй като трябва да се погрижи за всяка минута. |
Разходите за поддръжка са ниски, тъй като необходимите ресурси са ниски. | Разходите за поддръжка са високи, тъй като необходимите ресурси са високи |
Защо са необходими сценариите за тестове?
Тестовите сценарии се извличат от изисквания или потребителски истории.
- Вземете примера на тестов сценарий за резервация в кабината.
- Сценариите могат да бъдат като опции за резервация на кабината, начини на плащане, GPS проследяване, пътна карта, показана правилно или не, подробности за кабината и водача, показани правилно или не и т.н., всички са изброени в шаблона за тестов сценарий.
- Сега да предположим, че тестовият сценарий е да проверите дали услугите за местоположение са включени, ако не са включени, покажете съобщението „Включване на услугите за местоположение“. Този сценарий е пропуснат и не е включен в шаблона за тестови сценарии.
- Сценарият „Услуга за местоположение“ поражда други тестови сценарии, свързани с него. Това могат да бъдат:
- Услугата за местоположение е сива.
- Услугата за местоположение е включена, но няма интернет.
- Ограничения за услуги за местоположение.
- Показва се грешното местоположение.
- Липсва един сценарий може да означава пропускане на много други критични сценарии или тестови случаи . Това може да има страхотно отрицателно въздействие докато внедрявате софтуерното приложение. Това води до голяма загуба на ресурси (срокове).
- Тестовите сценарии помагат до голяма степен в избягване на изчерпателни тестове . Той гарантира, че всички решаващи и очаквани бизнес потоци се тестват, което допълнително помага в края на края на тестването на приложението.
- Това са спестяващи време. Също така не се изисква много подробно описание според тестовите случаи. Посочено е еднолинейно описание за това какво да тествате.
- Тестовите сценарии се пишат след мозъчна атака на членовете на екипа. Следователно вероятността да пропуснете който и да е сценарий (решаващ или незначителен) е минимална. Това се прави, като се имат предвид техническите характеристики, както и бизнес потокът на софтуерното приложение.
- Освен това тестовите сценарии могат да бъдат одобрени или от бизнес анализатор, или от клиент, или и двамата, които имат изричните познания за тестваното приложение.
Следователно тестовите сценарии са незаменима част от SDLC.
Прилагане на тестови сценарии
Нека да видим изпълнението на тестови сценарии или как да напишем тестови сценарии-
- Формират се епични / бизнес изисквания.
- Пример за епос : Създайте акаунт в Gmail. Epic може да бъде основната характеристика на приложение или бизнес изискване.
- Epics са разделени на по-малки потребителски истории в спринтовете.
- Потребителските истории са получени от Epics. Тези потребителски истории трябва да бъдат изходни и одобрени от заинтересованите страни.
- Тестовите сценарии се извличат от потребителски истории или BRS (документ за бизнес изисквания), SRS (документ за спецификация на системните изисквания) или FRS (документ за функционални изисквания), който е финализиран и изходен.
- Тестерите пишат тестовите сценарии.
- Тези тестови сценарии се одобряват от ръководител на екип, бизнес анализатор или ръководител на проекти в зависимост от организацията.
- Всеки тестов сценарий трябва да бъде обвързан с поне една потребителска история.
- Трябва да се идентифицират както положителните, така и отрицателните сценарии на теста.
- Потребителски истории се състоят от Критерии за приемане като :
- Критериите за приемане са списък на условията или състоянието на намеренията за изискванията на клиента. Очакванията на клиента, както и недоразуменията се вземат предвид при изписването на критериите за приемане.
- Те са уникални за една потребителска история и всяка потребителска история трябва да има поне един критерий за приемане, който трябва да бъде проверяван независимо.
- Критериите за приемане помагат да се определи кои характеристики са в обхвата и кои са извън обхвата на даден проект. Тези критерии трябва да включват както функционални, така и нефункционални характеристики.
- Бизнес анализаторите пишат критерии за приемане и собственикът на продукта ги одобрява.
- Или в някои случаи собственикът на продукта може сам да напише критериите.
- Тестовите сценарии могат да бъдат получени от критериите за приемане.
Примери за сценарий на теста
# 1) Тестови сценарии за приложението Kindle
Kindle е приложението, което позволява на своите електронни четци да търсят електронни книги онлайн, да ги изтеглят и купуват. Amazon Kindle дава на читателя на електронни книги реалния опит да държи книга в ръка и да я чете. Дори обръщането на страници е добре симулирано в приложението.
Сега да отбележим тестовите сценарии. ( Забележка: Ограничените сценарии са изброени по-долу, за да получите обща идея за писане на тестовия сценарий. От него могат да бъдат изведени множество тестови случаи).
Тестови сценарии # | Тестови сценарии |
---|---|
7 | Проверете дали функционалността за изтегляне работи правилно. |
1 | Проверете дали Kindle App стартира правилно. |
две | Проверете дали разделителната способност на екрана се настройва според различните устройства след стартиране на приложението. |
3 | Уверете се, че показаният текст е четим. |
4 | Проверете дали опциите за увеличаване и отдалечаване работят. |
5 | Проверете дали съвместимите файлове, внесени в приложението Kindle, са четливи. |
6 | Проверете капацитета за съхранение на приложението Kindle. |
8 | Проверете дали симулацията за обръщане на страници работи правилно |
9 | Проверете съвместимостта на форматите на електронни книги с приложението Kindle. |
10 | Проверете шрифтовете, поддържани от приложението Kindle. |
единадесет | Проверете живота на батерията, използван от приложението Kindle. |
12 | Проверете производителността на Kindle в зависимост от мрежовата свързаност (Wi-Fi, 3G или 4G). |
От всеки тестов сценарий, посочен по-горе, могат да бъдат извлечени множество тестови случаи.
# 2) Критерии за приемане за Google Docs
„Google docs“ е уеб-базирано приложение за създаване, редактиране и споделяне на текстови документи, електронни таблици, слайдове и формуляри. Всички файлове могат да бъдат достъпни онлайн чрез уеб браузър, който има интернет връзка.
Създадените документи могат да се споделят като уеб страница или документ, готов за печат. Потребителят може да зададе ограничения за това кой може да преглежда и редактира документите. Един-единствен документ може да бъде споделян съвместно и да се работи по него от различни лица от различни географски местоположения.
Ограничените тестови сценарии са посочени по-долу за общо разбиране. Задълбочените тестови сценарии за документи на Google могат да бъдат съвсем отделна тема.
Критерии за приемане # | Критерии за приемане |
---|---|
7 | Множество потребители могат да работят върху един документ. |
1 | Word, Sheets или Forms могат да бъдат отворени успешно без грешка. |
две | Предлагат се шаблони за документи, листове и слайдове. |
3 | Наличните шаблони са достъпни за потребителите. |
4 | Използваният шаблон може да се редактира (напр. Шрифтове, размер на шрифта, добавяне на текст, изтриване на текст, вмъкване на слайд). |
5 | Ако интернет връзката временно не е достъпна, файлът може да се съхранява локално и да се качва при наличие на интернет връзка. |
6 | Промените, направени от множество потребители, не са презаписани. |
8 | Свършената работа се съхранява, ако при качване на файл се загуби интернет връзка. |
9 | Ограниченията за споделяне се прилагат правилно. |
10 | Потребителите с ограничение на изгледа не могат да правят никакви редакции на документите. |
единадесет | Документите могат да бъдат публикувани в интернет за широката публика. |
12 | Промените, направени в документите, се записват с времеви печат и данни за автора. |
Броят на тестовите сценарии ще бъде многократен и много огромен за Google Docs. В такива случаи обикновено само заинтересованите страни определят и одобряват само критериите за приемане и членовете на екипа работят по тези критерии. Писането на тестови случаи за или по-скоро тестови сценарии може да бъде изчерпателната задача за огромни приложения.
Тези критерии за приемане играят важна роля в итеративното планиране на процеса и никога не трябва да се пренебрегват. Дефинирането им предварително и предварително избягва изненади или шокове в края на спринтовете или освобождаванията
Дадено предпоставка.
Кога да направиш действие.
Тогава очакваният резултат.
Форматите „Дадено, кога и тогава“ са полезни за определяне на критериите за приемане.
Пример за шаблон за тестов сценарий
Използвайте идентификационен номер № | Идент. № на тестовия сценарий | Версия # | Тестови сценарии | # Брой тестови случаи | Значение |
---|---|---|---|---|---|
USID 12.1 | TSID 12.1.1 | 12.4 | Проверете дали Kindle App стартира правилно. | 4 | Високо |
USID 12.1 | TSID 12.1.2 | 12.4 | Проверете капацитета за съхранение на приложението Kindle. | 3 | Среден |
Заключение
Във всяко софтуерно тестване жизнения цикъл разбирането и определянето на тестовите сценарии е много важен елемент. Качеството на софтуера може да се подобри, като има добра основа за тестови сценарии. Често използването на тестови случаи и тестови сценарии може да се разменят.
Правилото за палеца обаче е, че тестовият сценарий се използва за писане на множество тестови случаи или можем да кажем, че тестовите случаи са получени от тестови сценарии. Добре дефинираните тестови сценарии осигуряват добро качество на софтуера.
Препоръчително четене
- Примерен шаблон за план за тестване на софтуер с формат и съдържание
- Примерен шаблон за тестови случаи с примери за тестови случаи [Изтегляне]
- Примерен шаблон за доклад за изпитване за приемане с примери
- Шаблони в C ++ с примери
- Урок за Python DateTime с примери
- Изрежете командата в Unix с примери
- Тестов сценарий срещу тестов случай: Каква е разликата между тях?
- Приставка за Blazemeter и шаблон Jmeter