Як написати тестові випадки з прикладами
🚀 Розумний підсумок
Тестовий випадок — це задокументований набір умов, вхідних даних, дій та очікуваних результатів для перевірки правильності роботи певної функції в програмних застосунках.
Що таке тестовий приклад?
A тестовий випадок це сукупність дії, внески та очікувані результати що допомагає тестувальникам перевірити, чи працює певна функція або функціональність програмного забезпечення належним чином. Він служить крок за кроком керівництво що визначає, що тестувати, як це тестувати та якого результату очікувати.
Уявіть собі тестовий випадок як рецепт для підтвердження — він повідомляє вам точні інгредієнти (дані тестування), процес (кроки для виконання) та як має виглядати ідеальна страва (очікуваний результат).
Добре написаний тестовий випадок допомагає забезпечити:
- Програмне забезпечення відповідає бізнес-вимоги та вимоги користувачів.
- Помилки або неочікувані поведінки є спіймали рано.
- Тестування може бути повторений та переглянутий будь-яким фахівцем з контролю якості.
- Команди можуть простежувати яку вимогу перевіряє кожен тест.
👉 Зареєструйтесь на безкоштовний проект тестування програмного забезпечення в реальному часі
Кроки для створення тестових випадків у ручному тестуванні
Давайте створимо тестовий приклад для сценарію: Перевірте функціональність входу
Крок 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іон | Дані тесту | Очікуваний результат | Фактичний результат | Пройти / провалити |
|---|---|---|---|---|---|
| 1 | Перевірте відповідь, коли введено дійсну адресу електронної пошти та пароль | Електронна пошта: guru99@email.com Пароль: lNf9^Oti7^2h | Вхід має бути успішним | Вхід пройшов успішно | Проходити |
Крок 5) Це, окрім вашого тестового прикладу, може мати таке поле, як
передумова, яка визначає речі, які мають бути виконані перед запуском тесту. Для нашого тестового випадку передумовою було б встановлення браузера для доступу до тестованого сайту. Тестовий випадок також може містити постумови, які визначають будь-що, що застосовується після завершення тестового випадку. Для нашого тестового випадку постумовою було б те, що час і дата входу зберігаються в базі даних.
Ключові елементи тестового випадку
Стандартний тестовий випадок зазвичай включає:
- Ідентифікатор тестового випадку – Унікальний ідентифікатор (наприклад, TC001)
- Назва або Descriptіон – Що підтверджує тест
- Передумови – Що має бути до початку тестування
- Етапи тестування – Точні дії, які потрібно виконати
- Дані тесту – Вхідні значення або параметри
- Очікуваний результат – Результат, який ви повинні побачити
- Фактичний результат – Що насправді сталося
- Статус – Пройдено, не пройдено або заблоковано
Тестовий приклад проти тестового сценарію
A тестовий сценарій описує, що потрібно протестувати — широку функціональність або шлях користувача.
A тестовий випадок, з іншого боку, пояснює, як ця функціональність буде перевірена — точні кроки, дані та очікувані результати.
Простіше кажучи:
- Тестовий сценарій = Ідея що тестувати.
- Тестовий випадок = Реалізація про те, як перевірити цю ідею.
Подумайте про це так —
«Якщо тестовий сценарій є назвою розділу, то кожен тестовий випадок — це абзац, який детально пояснює цей розділ».
Приклад ілюстрації:
Візьмемо приклад, щоб було зрозуміліше:
Тестовий сценарій:
«Перевірте функцію входу на вебсайт».
Пов'язані тестові випадки:
- Підтвердьте вхід, використовуючи дійсне ім'я користувача та пароль.
- Перевірте повідомлення про помилку з недійсним паролем.
- Підтвердьте вхід, виконуючи дії порожніми полями.
- Поле перевірки пароля приховує введений текст.
Тут сценарій такий єдина функціональна мета, поки тестові випадки розбивають його на специфічні, перевірені умови.
Читайте більше інформації про Різниця між тестовим випадком та тестовим сценарієм
Переваги написання високоякісних тестових випадків
- Високоякісні тестові випадки забезпечують ретельність тестове покриття, узгодженість та простежуваність протягом усього процесу забезпечення якості.
- Вони допомагають тестерам вловити ранні помилки, підтримувати регресійна стійкість, та гарантувати, що кожна функціональність відповідає бізнес-вимогам.
- Добре написані тестові випадки – це прозорі, багаторазові та повторювані, що дозволяє будь-якому тестувальнику або засобу автоматизації надійно їх виконувати.
- Вони також виступають як комунікаційний міст між розробниками, тестувальниками та зацікавленими сторонами — зменшення неоднозначності та економія часу.
- Документуючи цілі, кроки та результати тестування, команди можуть вимірювати прогрес, дотримуватися стандартів, та ефективно керувати оновленнями.
- Найголовніше, хороші тестові випадки зменшити витрати на технічне обслуговування, пришвидшити автоматизацію та забезпечити впевненість у якості програмного забезпечення.
- Вони слугують живою документацією для адаптації нових тестувальників та структурованим вхідним даними для ШІ та інструменти управління тестуванням.
Типові помилки, яких слід уникати під час написання тестових випадків
Навіть досвідчені тестувальники роблять невеликі помилки, які послаблюють якість тестування.
Уникнення цих помилок може значно покращити точність, чіткість та зручність обслуговування вашого набору тестів.
- Написання нечітких кроків: Неоднозначні інструкції на кшталт «перевірити сторінку входу» бентежать тестувальників. Використовуйте чіткі кроки, що ґрунтуються на діях.
- Пропускання негативних сценаріїв: Завжди включайте недійсні вхідні дані або граничні тести, щоб забезпечити повне покриття.
- Повторне використання нечітких тестових даних: Немарковані або суперечливі дані роблять результати тестів ненадійними. Ведіть спільний аркуш даних тестів.
- Надмірне ускладнення тестових випадків: Довгі, багатоетапні справи важко підтримувати. Зосередьтеся на кожній справі та зосередьтеся на ній.
- Ігнорування оновлень після змін у продукті: Застарілі тестові випадки створюють хибні результати. Revпереглядати та регулярно переглядати.
- Відсутність відстеження: Завжди пов'язуйте тестові випадки з вимогами, щоб відстежувати покриття та відповідність.
- Пропускання експертних оцінок: Свіжий погляд рано помічає нечіткі або зайві кроки.


