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