Какво е тест?
А тест е набор от действия, извършени за да се провери по-специално на функция или характеристика на вашето софтуерно приложение. Тестовият случай съдържа тестови стъпки, тестови данни, предварително условие, последващо условие, разработено за конкретен тестов сценарий за проверка на всяко изискване. Тестовият случай включва специфични променливи или условия, с помощта на които инженер по тестване може да сравнява очакваните и действителните резултати, за да определи дали даден софтуерен продукт функционира според изискванията на клиента.
Тестов сценарий срещу тестов случай
Тестовите сценарии са доста неясни и обхващат широк спектър от възможности. Тестването е свързано с това да бъдете много специфични.
За сценарий на теста: Проверете функционалността за влизане, има много възможни тестови случаи:
- Тест 1: Проверете резултатите при въвеждане на валиден потребителски идентификатор и парола
- Тест 2: Проверете резултатите при въвеждане на невалиден потребителски идентификатор и парола
- Тест 3: Проверете отговора, когато потребителски идентификатор е празен и бутон за влизане е натиснат и много други
Това не е нищо друго освен тестов случай.
В този урок ще научите как да пишете тестови случаи при ръчно тестване с пример -
- Как да пиша тестови случаи при ръчно тестване
- Форматът на стандартните тестови случаи
- Най-добра практика за писане на добър пример от тестови случаи.
- Инструменти за управление на тестови случаи
- Ресурси
Щракнете тук, ако видеоклипът не е достъпен
Как да пиша тестови случаи при ръчно тестване
Нека създадем тестов случай за сценария: Проверете функционалността за вход
Стъпка 1) Ще бъде прост тестов случай за обяснение на сценария
| Тестов случай # | Описание на тестовия случай |
|---|---|
| 1 | Проверете отговора, когато са въведени валидни имейл и парола |
Стъпка 2) За да изпълните тестовия случай, ще са ви необходими тестови данни. Добавяйки го по-долу
| Тестов случай # | Описание на тестовия случай | Тестови данни |
|---|---|---|
| 1 | Проверете отговора, когато са въведени валидни имейл и парола | Имейл: Този имейл адрес е защитен от спам ботове. Трябва да имате активиран JavaScript, за да го видите. Парола: lNf9 Oti7 2h |
Идентифицирането на тестови данни може да отнеме много време и понякога може да се наложи създаването на тестови данни отново. Причината за това трябва да бъде документирана.
Стъпка 3) За да изпълни тестов случай, тестерът трябва да извърши определен набор от действия на AUT. Това е документирано по-долу:
| Тестов случай # | Описание на тестовия случай | Тестови стъпки | Тестови данни |
|---|---|---|---|
| 1 | Проверете отговора, когато са въведени валидни имейл и парола |
1) Въведете имейл адрес 2) Въведете парола 3) Щракнете върху Вход |
Имейл: Този имейл адрес е защитен от спам ботове. Трябва да имате активиран JavaScript, за да го видите. Парола: lNf9 Oti7 2h |
Много пъти тестовите стъпки не са прости, както по-горе, поради което се нуждаят от документация. Също така авторът на тестовия случай може да напусне организацията или да отиде на почивка или да е болен и извън служба или да е много зает с други критични задачи. Наскоро нает може да бъде поискан да изпълни тестовия случай. Документираните стъпки ще му помогнат, а също така ще улеснят прегледите от други заинтересовани страни.
Стъпка 4) Целта на тестовите случаи при тестване на софтуера е да се провери поведението на AUT за очакван резултат. Това трябва да бъде документирано, както е показано по-долу
| Тестов случай # | Описание на тестовия случай | Тестови данни | очакван резултат |
|---|---|---|---|
| 1 | Проверете отговора, когато са въведени валидни имейл и парола | Имейл: Този имейл адрес е защитен от спам ботове. Трябва да имате активиран JavaScript, за да го видите. Парола: lNf9 Oti7 2h | Влизането трябва да е успешно |
По време на времето за изпълнение на теста тестерът ще провери очакваните резултати спрямо действителните резултати и ще присвои състояние на преминаване или неуспех
| Тестов случай # | Описание на тестовия случай | Тестови данни | очакван резултат | Действителен резултат | Pass / Fail |
|---|---|---|---|---|---|
| 1 | Проверете отговора, когато са въведени валидни имейл и парола | Имейл: Този имейл адрес е защитен от спам ботове. Трябва да имате активиран JavaScript, за да го видите. Парола: lNf9 Oti7 2h | Влизането трябва да е успешно | Влизането беше успешно | Подайте |
Стъпка 5) Отделно, че вашият тестов случай може да има поле като Pre-Condition, което определя неща, които трябва да са налице, преди тестът да може да се изпълни. За нашия тестов случай предварително условие е да има инсталиран браузър, за да има достъп до тествания сайт. Тестовият случай може също да включва Post - условия, който определя всичко, което се прилага след приключване на тестовия случай. За нашия тестов случай след условие ще бъде времето и датата на влизане се съхранява в базата данни
Форматът на стандартните тестови случаи
По-долу е даден формат на стандартен пример за тестови случаи за влизане.
| Идентификатор на тестовия случай | Тест сценарий | Тестови стъпки | Тестови данни | Очаквани резултати | Актуални резултати | Pass / Fail |
|---|---|---|---|---|---|---|
| TU01 | Проверете влизането на клиента с валидни данни |
| Userid = guru99 Парола = pass99 | Потребителят трябва да влезе в приложение | Както се очаква | Подайте |
| TU02 | Проверете влизането на клиента с невалидни данни |
| Userid = guru99 Парола = glass99 | Потребителят не трябва да влиза в приложение | Както се очаква | Подайте |
Цялата тази таблица може да бъде създадена в Word, Excel или друг инструмент за управление на тестове. Това е всичко, за да тествате дизайна на калъфите
Докато съставяте тестов случай, за да включите следната информация
- Описание на изискването, което се тества
- Обяснението как ще се тества системата
- Тестовата настройка като версия на тествано приложение, софтуер, файлове с данни, операционна система, хардуер, достъп до защита, физическа или логическа дата, час от деня, предпоставки като други тестове и всякаква друга информация за настройка, свързана с изискванията, които се тестват
- Входове и изходи или действия и очаквани резултати
- Всякакви доказателства или приложения
- Използвайте активен език на регистъра
- Тестовият случай не трябва да бъде повече от 15 стъпки
- Автоматизиран тестов скрипт се коментира с входни данни, цел и очаквани резултати
- Настройката предлага алтернатива на предварително необходимите тестове
- При други тестове това трябва да е неправилна поръчка за бизнес сценарий
Най-добра практика за писане на добър пример от тестови случаи.
1. Тестовите случаи трябва да бъдат прости и прозрачни:
Създайте тестови случаи, които са възможно най-прости. Те трябва да са ясни и кратки, тъй като авторът на тестовия случай може да не ги изпълни.
Използвайте категоричен език, като отидете на началната страница, въведете данни, кликнете върху това и така нататък. Това прави разбирането на тестовите стъпки лесно и тестването по-бързо.
2. Създайте тестов случай с мисъл за крайния потребител
Крайната цел на всеки софтуерен проект е да създаде тестови случаи, които отговарят на изискванията на клиента и е лесен за използване и експлоатация. Тестерът трябва да създаде тестови случаи, имайки предвид перспективата на крайния потребител
3. Избягвайте повторение на тестови случаи.
Не повтаряйте тестови случаи. Ако е необходим тестов случай за изпълнение на друг тестов случай, извикайте тестовия случай чрез неговия идентификатор на тестовия случай в колоната за предварително условие
4. Не приемайте
Не приемайте функционалността и характеристиките на вашето софтуерно приложение, докато подготвяте тестов случай. Придържайте се към документите за спецификация.
5. Осигурете 100% покритие
Уверете се, че сте написали тестови случаи, за да проверите всички софтуерни изисквания, посочени в документацията за спецификация. Използвайте проследяващата матрица, за да се уверите, че няма оставени функции / условия непроверени.
6. Тестовите случаи трябва да могат да бъдат идентифицирани.
Назовете идентификационния номер на тестовия случай, така че да се идентифицират лесно, докато проследявате дефекти или идентифицирате софтуерно изискване на по-късен етап.
7. Прилагане на техники за тестване
Не е възможно да проверите всички възможни условия във вашето софтуерно приложение. Техниките за софтуерно тестване ви помагат да изберете няколко тестови случая с максимална възможност за откриване на дефект.
- Анализ на гранична стойност (BVA): Както подсказва името, това е техниката, която определя тестването на граници за определен диапазон от стойности.
- Разделяне на еквивалентност (EP): Тази техника разделя обхвата на равни части / групи, които са склонни да имат едно и също поведение.
- Техника на преход на държавата : Този метод се използва, когато поведението на софтуера се променя от едно състояние в друго след конкретно действие.
- Техника за отчитане на грешки: Това е отгатване / предвиждане на грешката, която може да възникне по време на ръчно тестване. Това не е официален метод и се възползва от опита на тестера с приложението
8. Самопочистване
Тестовият случай, който създавате, трябва да върне тестовата среда в състоянието преди теста и не трябва да прави тестовата среда неизползваема. Това важи особено за тестването на конфигурацията.
9. Повторяем и самостоятелен
Тестовият случай трябва да генерира едни и същи резултати всеки път, независимо кой го тества
10. Партньорска проверка.
След създаването на тестови случаи ги накарайте да бъдат прегледани от вашите колеги. Вашите връстници могат да открият дефекти в дизайна на вашия тест, които лесно можете да пропуснете.
Инструменти за управление на тестови случаи
Инструментите за управление на тестове са инструментите за автоматизация, които помагат да се управляват и поддържат тестовите случаи. Основните характеристики на инструмента за управление на тестови случаи са
- За документиране на тестови случаи: С инструменти можете да ускорите създаването на тестови случаи с помощта на шаблони
- Изпълнете тестовия случай и запишете резултатите: Тестовият случай може да бъде изпълнен чрез инструментите и получените резултати могат лесно да бъдат записани.
- Автоматизирайте проследяването на дефекти: Неуспешните тестове се свързват автоматично с програмата за проследяване на грешки, която от своя страна може да бъде възложена на разработчиците и може да бъде проследена чрез известия по имейл.
- Проследимост: Изискванията, тестовите случаи, изпълнението на тестовите случаи са свързани помежду си чрез инструментите и всеки случай може да бъде проследен един до друг, за да се провери покритието на теста.
- Защита на тестови случаи: Тестовите случаи трябва да се използват многократно и трябва да бъдат защитени от загуба или повреда поради лош контрол на версиите. Инструментите за управление на тестови случаи предлагат функции като
- Конвенции за именуване и номериране
- Версиониране
- Съхранение само за четене
- Контролиран достъп
- Архивиране извън сайта
Популярни инструменти за управление на тестове са: Център за качество и JIRA
Ресурси
- Моля, обърнете внимание, че използваният шаблон ще варира в зависимост от проект. Прочетете този урок, за да научите Шаблон за тестов случай с обяснение на важни полета
Изтеглете горния шаблон на тестовия пример Excel (.xls)
