Как да напишете тестови случаи с примери
Томас Хамилтън
🚀 Интелигентно обобщение
Тестовият случай е документиран набор от условия, входни данни, действия и очаквани резултати за проверка дали дадена функция работи правилно в софтуерни приложения.
Какво е тестов случай?
A тестов случай е набор от действия, вложения и очаквани резултати което помага на тестерите да проверят дали дадена функция или функционалност в софтуера работи както е предвидено. Служи като Ръководство стъпка по стъпка който определя какво да се тества, как да се тества и какъв резултат да се очаква.
Мислете за тестов случай като за рецепта за валидиране — казва ви точните съставки (данни от тестове), процеса (стъпки за изпълнение) и как трябва да изглежда едно перфектно ястие (очакваният резултат).
Добре написаният тестов случай помага да се гарантира:
- Софтуерът отговаря на бизнес и потребителски изисквания.
- Грешки или неочаквано поведение са хванат рано.
- Тестването може да бъде повторено и прегледано от всеки QA професионалист.
- Екипите могат проследи кое изискване проверява всеки тест.
👉 Запишете се за безплатен проект за тестване на софтуер на живо
Стъпки за създаване на тестови случаи при ръчно тестване
Нека създадем тестов случай за сценария: Проверка на функционалността за влизане
Стъпка 1) Един прост тестов случай за обяснение на сценария би бил
| Тестов случай # | Тестов случай Descriptйон |
|---|---|
| 1 | Проверете отговора при въвеждане на валиден имейл и парола |
Стъпка 2) Тествайте данните.
За да изпълните тестовия случай, ще ви трябва Данни от теста. Добавяне по-долу
| Тестов случай # | Тестов случай Descriptйон | Данни от теста |
|---|---|---|
| 1 | Проверете отговора при въвеждане на валиден имейл и парола | Имейл: guru99@email.com Парола: lNf9^Oti7^2h |
Идентифицирането на тестови данни може да отнеме много време и понякога може да изисква създаване на тестови данни наново. Причината трябва да бъде документирана.
Стъпка 3) Извършване на действия.
За да изпълни тестов случай, тестерът трябва да извърши специфичен набор от действия на AUT. Това е документирано по-долу:
| Тестов случай # | Тестов случай Descriptйон | Тестови стъпки | Данни от теста |
|---|---|---|---|
| 1 | Проверете отговора при въвеждане на валиден имейл и парола | 1) Въведете имейл адрес
2) Въведете парола 3) Щракнете върху Вход |
Имейл: guru99@email.com
Парола: lNf9^Oti7^2h |
Много пъти стъпките на теста не са толкова прости, колкото по-горе, следователно е необходима документация. Също така, авторът на тестовия случай може да напусне организацията, да отиде на почивка, да е болен и да не е на работа, или да е много зает с други критични задачи. Наскоро нает служител може да бъде помолен да изпълни тестовия случай. Документираните стъпки ще му помогнат и ще улеснят прегледите от други заинтересовани страни.
Стъпка 4) Проверете поведението на AUT.
Целта на тестовите случаи в софтуерното тестване е да се провери поведението на AUT за очакван резултат. Това трябва да бъде документирано, както е показано по-долу.
| Тестов случай # | Тестов случай Descriptйон | Данни от теста | очакван резултат |
|---|---|---|---|
| 1 | Проверете отговора при въвеждане на валиден имейл и парола | Имейл: guru99@email.com Парола: lNf9^Oti7^2h |
Влизането трябва да е успешно |
По време на времето за изпълнение на теста, тестерът ще сравни очакваните резултати с действителните резултати и ще присвои статус на успешно или неуспешно
| Тестов случай # | Тестов случай Descriptйон | Данни от теста | очакван резултат | Действителен резултат | Pass / Fail |
|---|---|---|---|---|---|
| 1 | Проверете отговора при въвеждане на валиден имейл и парола | Имейл: guru99@email.com Парола: lNf9^Oti7^2h | Влизането трябва да е успешно | Влизането беше успешно | Pass |
Стъпка 5) Това освен вашия тестов случай - може да има поле като,
предварително условие, което определя нещата, които трябва да са налице, преди тестът да може да се изпълни. За нашия тестов случай предварително условие би било да има инсталиран браузър, за да има достъп до тестовия сайт. Тестовият случай може също да включва постусловия, които определят всичко, което се прилага след завършването му. За нашия тестов случай постусловие би било часът и датата на влизане, които се съхраняват в базата данни.
Ключови елементи на тестовия случай
Стандартният тестов случай обикновено включва:
- ID на тестов случай – Уникален идентификатор (напр. TC001)
- Заглавие или Descriptйон – Какво проверява тестът
- Предпоставки – Какво трябва да е налице преди началото на теста
- Тестови стъпки – Точните действия, които трябва да се извършат
- Данни от теста – Входни стойности или параметри
- очакван резултат – Резултатът, който трябва да видите
- Действителен резултат – Какво всъщност се случи
- Статус – Преминал, неуспешен или блокиран
Тестов случай срещу тестов сценарий
A тестов сценарий описва какво трябва да се тества - широката функционалност или потребителското пътуване.
A тестов случай, от друга страна, обяснява как ще бъде проверена тази функционалност — точните стъпки, данни и очаквани резултати.
С прости думи:
- Тестов сценарий = Идея за това какво да се тества.
- Тестов случай = Имплементация за това как да се тества тази идея.
Мислете за това така —
„Ако тестовият сценарий е заглавие на глава, всеки тестов случай е параграф, който обяснява подробно тази глава.“
Примерна илюстрация:
Нека вземем пример, за да стане по-ясно:
Тестов сценарий:
„Проверете функционалността за вход в уебсайта.“
Свързани тестови случаи:
- Потвърдете входа с валидно потребителско име и парола.
- Проверете съобщението за грешка с невалидна парола.
- Потвърдете входа с празни полета.
- Полето за проверка на паролата скрива въведения текст.
Тук сценарият е такъв единична функционална цел, докато тестовите случаи го разделят на специфични, проверими условия.
Прочетете за повече информация относно Разлика между тестов случай и тестов сценарий
Предимства от писането на висококачествени тестови случаи
- Висококачествените тестови случаи гарантират задълбочена тестово покритие, последователност и проследимост в целия процес на осигуряване на качеството.
- Те помагат на тестерите да уловят ранни грешки, поддържа регресионна стабилности гарантират, че всяка функционалност е в съответствие с бизнес изискванията.
- Добре написаните тестови случаи са ясни, многократно използваеми и повтаряеми, позволявайки на всеки тестер или инструмент за автоматизация да ги изпълнява надеждно.
- Те също така действат като комуникационен мост между разработчици, тестери и заинтересовани страни — намаляване на неяснотата и спестяване на време.
- Чрез документиране на целите, стъпките и резултатите от теста, екипите могат измерване на напредъка, спазване на стандартите, и да управлявате актуализациите ефективно.
- Най-важното е, че са добри тестови случаи намаляване на разходите за поддръжка, ускоряване на автоматизацията и осигуряване увереност в качеството на софтуера.
- Те служат като „жива“ документация за адаптиране на нови тестери и като структуриран вход за ИИ и инструменти за управление на тестове.
Често срещани грешки, които трябва да се избягват при писане на тестови случаи
Дори опитните тестери правят малки грешки, които отслабват качеството на теста.
Избягването на тези грешки може драстично да подобри точност, яснота и поддръжка от вашия тестов набор.
- Писане на неясни стъпки: Неясни инструкции като „проверете страницата за вход“ объркват тестерите. Използвайте ясни, основани на действия стъпки.
- Пропускане на негативни сценарии: Винаги включвайте невалидни входни данни или гранични тестове, за да осигурите пълно покритие.
- Повторно използване на неясни тестови данни: Необозначените или непоследователни данни правят резултатите от тестовете ненадеждни. Поддържайте споделен лист с тестови данни.
- Прекалено усложняване на тестовите случаи: Дългите, многоетапни случаи са трудни за поддържане. Поддържайте всеки случай фокусиран и атомарен.
- Игнориране на актуализации след промени в продукта: Остарелите тестови случаи създават неверни резултати. Revпреглеждайте и преразглеждайте редовно.
- Липсва проследимост: Винаги свързвайте тестовите случаи с изискванията, за да следите покритието и съответствието.
- Пропускане на експертни оценки: Свежият поглед улавя неясни или излишни стъпки рано.
