Въведение в тестовия сценарий

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

Защо да създадете тестови сценарии?

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

Причината за създаването им е следната:

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

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

  • Може да не се създава в проекти, следващи Agile Методологии като Scrum и т.н.
  • Когато приложенията, които трябва да бъдат тествани, са нестабилни или твърде сложни или когато проектът е в критично време, създаването му може да бъде избегнато.
  • Създаването му може да бъде избегнато за регресионно тестване или за нова грешка, тъй като в проектите за поддръжка тежки документации на тях биха се случили предварително в предишните тестови цикли.

Как могат да бъдат написани тестови сценарии?

Следните стъпки могат да бъдат извършени от тестер за създаване на тестови сценарии:

  • Стъпка 1: Документът за изисквания като спецификация за бизнес изисквания (BRS), спецификация за функционални изисквания (FRS) и спецификация за системно изискване (SRS) на приложението, което трябва да бъде тествано, трябва да бъде прочетено внимателно и внимателно. Ръководства, книги, случаи на използване и др. На тестваното приложение могат да бъдат отнесени към същото.
  • Стъпка 2: Всички възможни цели и действия на потребителите трябва да се определят правилно за всяко изискване. Всички технически характеристики на всяко изискване също трябва да бъдат определени.
  • Стъпка 3: Всички възможни причини за хакване на системата и оценка на потребителите трябва да бъдат направени от гледна точка на хакера. Оценката на потребителя може да се извърши, като се намерят всички възможности за работа на потребителите с приложенията.
  • Стъпка 4: След пълното прочитане на документа за изискване и приключване на анализа трябва да се направи пълен списък на всички възможни тестови случаи за проверка на всички функционалности на заявлението.
  • Стъпка 5: След включването на всички тях за проверка на изискването и неговия тестов сценарий съвпадат, трябва да се създаде матрица за проследяване.
  • Стъпка 6: Всички създадени тестови сценарии се преглеждат и оценяват от ръководителя. Освен това се проверява от всички заинтересовани страни.

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

Примери

По-долу са дадени някои примери за тестов сценарий

Тестов сценарий за приложение за онлайн пазаруване Buykart

Тестови сценарии, които могат да бъдат взети предвид при проверката на приложение за онлайн пазаруване Buykart, са както следва:

Тестов сценарий 1: Проверка на функционалността за влизане

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

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

Тестов сценарий 2: Проверка на функционалността на търсенето

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

  • Поведение на приложението при търсене на валиден продукт.
  • Поведение на приложението при търсене на невалиден продукт.

Тест сценарий 3: Проверка на подробности за продукта

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

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

Тестов сценарий 4: Проверка на функционалността на плащанията

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

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

Тестов сценарий 5: Проверка на функционалността на подробностите за поръчката

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

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

заключение

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

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

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

  1. Стрес на несигурността за работа
  2. Самомотивиран и посветен
  3. Какво е Agile Testing?
  4. Как да напиша тестов случай?