Завантаження шаблону тестового випадку в Excel

Автор: Томас Гамільтон Томас Гамільтон
Hours оновлений

⚡ Розумний підсумок

Шаблон тестового випадку надає стандартизовану структуру для документування тестових випадків для будь-якого програмного проекту. У цьому посібнику пояснюються всі важливі поля, пропонуються зразки Excel та Word для завантаження, а також перелічені найкращі практики, які забезпечують узгодженість артефактів тестування для всієї команди контролю якості.

  • 📋 Послідовність понад усе: Стандартний шаблон узгоджує роботу команди з контролю якості та скорочує час адаптації для нових тестувальників.
  • 🧾 Основні поля: Ідентифікатор тестового випадку, пріоритет, кроки, тестові дані, очікуваний результат та статус є невід'ємними елементами.
  • 📊 Excel проти Word: Excel ідеально підходить для табличного виконання tracкороль; Слово підходить для наративних тестових сценаріїв.
  • 🔗 Додаткове збагачення: Ідентифікатор дефекту, посилання на вимоги, посилання та прапорець автоматизації підвищують готовність до аудиту.
  • 🤖 Впровадження штучного інтелекту: Інструменти штучного інтелекту автоматично генерують, групують та пріоритезують тестові випадки на основі вимог.
Детальніше

Зразок шаблону тестового випадку

Що таке шаблон тестового випадку?

A Шаблон тестового випадку – це добре розроблений документ, який допомагає тестувальникам розробляти та послідовно розуміти дані для конкретного тестового сценарію. Гарний Тестовий випадок Шаблон підтримує узгодженість артефактів тестування для команди та спрощує виконання тестових випадків для всіх зацікавлених сторін. Написання тестових випадків у стандартному форматі зменшує зусилля на тестування та знижує рівень помилок. Стандартизований формат особливо бажаний, коли тестові випадки перевіряють зовнішні експерти.

Шаблон, який ви оберете для свого проєкту, залежить від вашої політики тестування. Багато організацій створюють тестові випадки в Microsoft Excel, інші в Microsoft Word, а деякі використовують інструменти керування тестуванням, такі як HP ALM.

Важливі поля в шаблоні тестового випадку

Незалежно від обраного методу документування, будь-який хороший шаблон тестового випадку повинен містити наступні поля.

Тестове поле Опис
Ідентифікатор тестового випадку Кожен тестовий випадок має бути представлений унікальним ідентифікатором. Використовуйте умовні позначення, такі як «TC_UI_1», для позначення типу тесту, наприклад, «Тестовий випадок інтерфейсу користувача №1».
Пріоритет тесту Корисно під час виконання. Загальні значення: Низький, Середній та Високий.
Назва модуля Основний модуль або підмодуль, що тестується.
Тест розроблений Ім'я тестувальника.
Дата розробленого тесту Дата розробки тесту.
Тест Виконав Тестер, який виконав тест.
Дата виконання тесту Дата, коли потрібно виконати тест.
Ім'я або назва тесту Назва тестового випадку.
Descriptіон / Короткий зміст Короткий виклад мети тестування.
Передумова Будь-які передумови, які необхідно виконати перед виконанням цього тестового випадку. Перелічіть кожну передумову.
Залежності Будь-які залежності від вимог до тестування або інших тестових випадків.
Етапи тестування Детальний опис кроків у порядку їх виконання. Будьте якомога конкретнішими.
Дані тесту Дані тесту використовуються як вхідні дані. Надайте різні набори даних з точними значеннями.
Очікуваний результат Очікуваний результат, включаючи будь-які помилки або повідомлення, які мають з’явитися на екрані.
Постумова Стан системи після запуску тестового випадку.
Фактичний результат Фактичний результат, зафіксований після виконання.
Статус (пройшов/не пройшов) Позначте як «Невдало», якщо фактичний результат не відповідає очікуваному.
примітки Спеціальні умови, які не відображені в інших місцях.

Необов'язкові поля можна додати залежно від вимог проекту.

  • Ідентифікатор посилання / дефекту: Посилання на дефект або номер дефекту, якщо тест не пройшов.
  • Ключові слова / Тип тесту: Використовується для категоризації тестів за типом, таким як зручність використання, функціональність або бізнес-правила.
  • Вимоги: Вимога(и), для якої(их) написано тестовий випадок.
  • Список літератури / Додатки: Шлях до супровідного документа або схеми для складних сценаріїв.
  • Автоматизація (Так/Ні): TracСтан автоматизації k для автоматизованих тестових випадків.
  • Спеціальні поля: Поля, що відповідають потребам клієнта або процесу вашого проекту.

Зразок шаблону тестового випадку

Завантажити шаблон тестового випадку (Excel та Word)

Обидва шаблони містять поля, описані вище. Виберіть формат, який відповідає стилю документації вашої команди.

Найкращі практики для написання тестових випадків

Шаблон цінний лише настільки, наскільки цінна дисципліна, що застосовується під час його заповнення. Наведені нижче практики дозволяють використовувати тестові випадки повторно, tracзрозумілий та чіткий.

  1. Чітко запишіть кожен крок: будь-який тестер повинен мати змогу виконати кроки, не вимагаючи пояснень.
  2. Почнімо з точки зору користувача: описуйте, що робить користувач, а не те, що робить код.
  3. Повторне використання замість дублювання: посилатися на існуючий тестовий випадок за ідентифікатором замість повторення його кроків.
  4. Забезпечте повне покриття: зіставити тестові випадки з вимогами за допомогою Вимоги TracМатриця доцільності.
  5. Використовуйте інструмент управління: платформи, такі як ДЖИРА або HP ALM зберігають історію версій, вкладення та журнали виконання в одному місці.

Поширені запитання

Excel підходить для структурованого виконання tracкороль зі стовпцями стану та фільтрами. Word підходить для сценаріїв наративного тестування. Багато команд переносять обидва формати в інструменти управління тестуванням, такі як HP ALM або ДЖИРА та цінності tracлегкість.

Тестовий сценарій — це загальне твердження про те, що потрібно протестувати. Тестовий випадок — це детальна покрокова процедура, яка доводить, що сценарій пройшов або не пройшов перевірку. Один сценарій зазвичай відповідає кільком тестовим випадкам.

Використовуйте чітку схему іменування, яка вказує на тип модуля та тесту. Наприклад, TC_UI_LOGIN_001 означає Інтерфейс користувача, Модуль входу, Перший тестовий випадок. Цей шаблон забезпечує передбачуваність ідентифікаторів у всьому проєкті.

Очікуваний результат визначається під час розробки тестового випадку та відображає правильну поведінку. Фактичний результат записується після виконання та показує, що система фактично зробила. Невідповідність позначає тест як невдалий.

Ні. Передумови описують стан системи, необхідний перед початком кроків. Зберігайтеping Розділення їх робить кроки тестування коротшими та придатнішими для повторного використання в кількох тестових випадках, що мають однакову конфігурацію.

Використовуйте вимогу TracМатриця спроможності (RTM), яка зіставляє кожен ідентифікатор вимоги з тестовими випадками, що його перевіряють. Це гарантує повне охоплення та спрощує аналіз впливу змін вимог.

Так. Інструменти штучного інтелекту читають історії користувачів або специфікації та пропонують позитивні, негативні та граничні тестові випадки. Тестери все одно перевіряють результати, щоб переконатися, що бізнес-наміри та граничні випадки правильно відображені.

Штучний інтелект ранжує тестові випадки за останніми змінами коду, історичним рівнем збоїв та бізнес-ризиком. Випадки з високим рівнем ризику запускаються першими, тому регресійні цикли виявляють критичні дефекти на ранній стадії, а не чекають на повне проходження.

Підсумуйте цей пост за допомогою: