Меню

Писане на тестови случаи от SRS документ (ИЗТЕГЛЯНЕ на примерни тестови случаи на проект)

writing test cases from srs document

Опитайте Нашия Инструмент За Премахване На Проблемите

Писане на тестови случаи от SRS документ (Изтегляне на примерни тестови случаи на проект) - Тестване на софтуер QA Training Day 4

Само за да преосмислим това, което сме правили досега - ние работим през Обучение за тестване на софтуер мини-курс по проект на живо OrangeHRM.

В тази безплатна онлайн серия за QA обучение досега приключихме с:

  1. Преглед на SRS,
  2. Идентификация на сценария на теста / обхвата на теста и
  3. Документиран план за изпитване .

Писане на тестови случаи от SRS документ

Сега стигнахме до частта, която е истинската сделка,тестовите случаи.

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

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

Нека веднага да стигнем до него.

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

Основи на писането на тестови дела

# 1) Ако тестовите сценарии са били за „Какво ще тестваме“ на AUT - тестовите случаи са за всички „Как ще тестваме изискване“.

Например , ако тестовият сценарий е „Проверка на функционалността за вход на администратор“ - Това ще доведе до 3 тестови случая (или условия) - Влизане (успешно), Неуспешно влизане при въвеждане на неправилно потребителско име, Неуспешно влизане при въвеждане на неправилна парола . Всеки тестов случай от своя страна ще има стъпки за справяне с начина, по който можем да проверим дали дадено условие на теста е изпълнено или не.

# две) Входът за създаване на документ за тестов случай е FRD, Тестови сценарии, създадени в по-ранната стъпка, и всички други справочни документи, ако има такива.

# 3) Документацията за тестовия случай е важен резултат от екипа за осигуряване на качеството и се споделя с BA, PM и други екипи, когато се направи за тяхната обратна връзка.

# 4) Работата е разделена между членовете на екипа и всеки член ще отговаря за създаването на тестови случаи за определен модул или част от определен модул.

# 5) Точно както при тестовите сценарии, преди да започнем документацията за тестови случаи, трябва да се договори общ шаблон. На практика всичко може да се използва за създаване на тестови случаи. Двата най-често използвани варианта са MS Excel и MS word.

# 6) The MS word шаблон изглежда по следния начин:

Тестови случаи MS word шаблон

# 7) The Шаблон на Excel може да изглежда по следния начин:

qa учебни тестови случаи проби xls

# 8) От горните два шаблона може да се забележи, че полетата (или компонентите), които съставляват тестовия случай, са еднакви, единствената разлика е в начина, по който са организирани.

Така че, докато има поле за всеки от видовете информация, която трябва да бъде включена в тест, форматът на шаблона няма значение. Моят личен фаворит обаче е Excel листът, тъй като е лесен за разгъване, свиване, сортиране и др. Но отново изберете всеки формат, който най-добре работи за вас.

Полета в тестови случаи

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

Id на тестовия случай и описанието на тестовия случай са общите.

Останалите полета могат да бъдат обяснени както следва:

  • Предпоставка: Състояние на AUT (състоянието, в което AUT трябва да бъде, за да започнем).
  • Вход: Стъпки за въвеждане на данни. За тези стъпки е важно да се отбележи какъв вид входна информация се изисква - Тестови данни.
  • Точка за проверка / задействане / действие : Какво причинява валидирането? (Щракнете върху бутон или превключете или достъпа до връзката. Уверете се, че има поне една точка за проверка на тестов случай - в противен случай всичко ще бъде въвеждане на данни, без да се търси нищо. Също така, за да гарантираме, че имаме достатъчно модулност, опитайте се да не комбинирате твърде много точки за валидиране в един тест. Оптимално е 1 на тест.)
  • Изход: Очакван резултат.
  • Постусловие: Това е допълнителна информация, която се предоставя в полза на тестера, само за да направи тестовия случай по-проницателен и информативен. Това включва обяснение на това, което се случва или какво може да се очаква от AUT, след като бъдат изпълнени всички стъпки от тестовия случай.

Вижте също => Примерен шаблон за тест

Примерни тестови случаи на проект на живо (изтегляне)

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

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

=> Изтеглете примерни документи за тестови случаи за нашия проект на живо от тук .

Забележка: Има няколко изображения, отнасящи се до примерни XLS документи за тестови случаи. Ако гледате това в по-старата версия на MS Office, може да се сблъскате с проблеми със съвместимостта.

Изброили сме тези изображения по-долу според имената им в XLS файловете:

Вижте снимка 1
Вижте снимка 2
Вижте снимка 3

Ето, всичко направено и всичко добро.

Методи за писане / оптимизиране на тестови случаи

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

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

разлика между тестване на sit и uat

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

Малко важни точки, които трябва да бъдат отбелязани

  • Тестовите случаи, които създаваме, са не само отправна точка за QA фазата, но и UAT.
  • Вътрешно тестовите случаи са Рецензиран в екипа .
  • Когато определена ситуация не се разглежда от тестов случай - правилото е, че няма да се тества. Така че, това е добро място да проверите дали тестовият пакет, който създадохме, постига целта за 100% покритие на теста или не. За целта може да се създаде матрица за проследяване. Вижте всичко, което трябва да знаете за Матрица за проследимост тук .
  • Инструменти - инструменти за управление на тестове като КК , qТест помогнете ни с дейността по създаване на тестови случаи. За пример как могат да се разглеждат тестови случаи с помощта на Центъра за качество, вижте това Урок за Център за качество .
  • Инструментите за автоматизация могат да се използват за създаване на тестови случаи - в този случай те се наричат ​​Тестови скриптове.
Професионален съвет :Моля, извършете проверка на правописа и граматиката на всеки документ, който създаваме. Ние сме представители на качеството за ИТ проекти - и това не ни се отразява положително, ако самите ни продукти са с по-ниско качество.

Това ни води до финала на друг интересен сегмент.

Заключение

Краят на процеса на създаване на тест / фаза на проектиране на теста (STLC) и краят на фазата на кода (SDLC) обикновено означават края на фазата на подготовка на теста и началото на фазата на теста.

Следващ урок в този курс за тестване на софтуер - В следващата статия ще говорим за това какво е тестовото изпълнение, какво включва и какви са очакванията от екипа за QA през тази фаза.

=> QA Training Day 5: Изпълнение на теста

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

Моля, уведомете ни за вашите въпроси и коментари по-долу. Приятно тестване!

PREV Урок | СЛЕДВАЩ Урок

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

^