Тест-кейс: приклади та шаблон, атрибути структури, життєвий цикл та статуси, правила складання та оформлення

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

Приклади тест-кейсів

Приклад тест-кейсу для перевірки функції логіну:

  • Ім'я тест-кейсу: Перевірка успішного входу користувача
  • Передумови: Користувач зареєстрований у системі
  • Кроки:
    • Відкрити сторінку логіна
    • Ввести коректний логін та пароль
    • Натиснути кнопку Увійти

    Атрибути структури тест-кейсу

    Правильно структурований тест-кейс має включати такі атрибути:

    1. Ідентифікатор тест-кейсу: Унікальний номер або код для ідентифікації тест-кейсу.
    2. Ім'я тест-кейсу: Коротка та зрозуміла назва, що описує, що перевіряє даний тест-кейс.
    3. Опис: Короткий опис мети та завдань тест-кейсу.
    4. Передумови: Умови чи дії, які мають бути виконані до початку тестування.
    5. Кроки: Детальний опис усіх кроків, необхідних для тестування.
    6. Очікуваний результат: Опис того, що має статися, якщо програма працює правильно.
    7. Фактичний результат: Опис того, що сталося насправді під час тестування.
    8. Примітки: Додаткова інформація або будь-який контекст, який може бути корисним для тестувальника.

    Життєвий цикл та статуси тест-кейсів

    Життєвий цикл тест-кейсу складається з кількох етапів:

    1. Створення: На цьому етапі тест-кейси розробляються та документуються.
    2. Рецензування: Потім тест-кейси проходять перевірку та затвердження, щоб гарантувати їхню повноту та точність.
    3. Виконання: Тест-кейси виконуються у процесі тестування.
    4. Звітність: Результати виконання тест-кейсів документуються та аналізуються.
    5. Обслуговування: Через зміни в програмному забезпеченні або вимогах тест-кейси можуть періодично оновлюватися або модифікуватися.
    • Нове: Щойно створений або оновлений тест-кейс.
    • На рецензії: Тест-Кейс знаходиться на етапі перевірки.
    • Затверджено: Тест-кейс перевірено та затверджено для використання.
    • Використаний: Тест-кейс був використаний у тестуванні та має задокументовані результати.
    • Не актуальний: Тест-кейс більше не застосовується через зміни в ПЗ або вимоги.

    Правила складання та оформлення тест-кейсів

    При складанні тест-кейсів важливо дотримуватися певних правил, щоб гарантувати їх ефективність та зручність використання:

    1. Чіткість та лаконічність: Опис кроків та очікуваних результатів мають бути чіткими та зрозумілими.
    2. Однозначність: Уникайте двозначних формулювань, які можуть спричинити плутанину.
    3. Атомарність: Кожен тест-кейс має тестувати один конкретний аспект чи функціональність ПЗ.
    4. Повторюваність: Тест-кейси повинні бути відтвореними незалежно від того, хто і коли їх виконує.
    5. Відстеження: Вказуйте посилання на пов'язані вимоги або інші документи для забезпечення зв'язку тестів з вимогами.
    6. Оновлення: Тест-кейси повинні періодично переглядатися та оновлюватись при зміні ПЗ або вимог.

    Популярні запитання та відповіді на тему

    Запитання: Як створювати тест-кейси для складних систем?
    Відповідь: Для створення тест-кейсів для складних систем важливо розбивати систему на менші модулі та створювати тест-кейс для кожного модуля.Також корисно використовувати діаграми та схеми для візуалізації функцій, що тестуються.
    Запитання: Який інструмент краще використовувати для керування тест-кейсами?
    Відповідь: Існує безліч інструментів для керування тест-кейсами, такі як TestRail, Jira, Zephyr, TestLink та інші. Вибір інструменту залежить від ваших вимог та переваг.
    Як часто потрібно оновлювати тест-кейси?
    Відповідь: Тест-кейси слід оновлювати щоразу при внесенні значних змін до програмного забезпечення або вимог. Також корисно періодично переглядати тест-кейси для гарантії їхньої актуальності.

    Висновок

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

    Тест-кейс: приклади та шаблон, атрибути структури, життєвий цикл та статуси, правила складання та оформлення - Mriya.v.ua

    Привіт, Хабре! Так-так, про тестування ПЗ тут вже купа статей. Тут я просто намагатимуся структурувати якомога повніше охоплення даних із різних джерел (щоб з теорії все основне було відразу в одному місці, і новачкам, наприклад, було легше орієнтуватися). При цьому, щоб стаття не здавалася надто громіздкою, інформація буде надана без зайвої деталізації, як необхідна та достатня для проходження співбесіди (згідно з моїм досвідом), розраховане на стажистів/джунів (як варіант, ця інформація може бути для загального розуміння корисна ІТ-рекрутерам, які проводять первинну співбесіду і принагідно ставлять деякі навколо-технічні питання).

    ОСНОВНІ ТЕРМІНИ

    Тестування ПЗ (Software Testing) – перевірка відповідності між реальною та очікуваною поведінкою програмипроводиться на наборі тестів, який вибирається деяким чином. Чим займаються у тестуванні:

    1. плануванням робіт (Test Management)
    2. проектуванням тестів (Test Design) – Етап, на якому створюються тестові сценарії (тест кейси), відповідно до визначених раніше критеріїв. Тобто визначається, ЯК буде тестуватися продукт.
    3. виконанням тестування (Test Execution)
    4. аналізом результатів (Test Analysis)

    Основні цілі тестування

    • технічна: надання актуальної інформації про стан продукту зараз.
    • комерційна: підвищення лояльності до компанії та продукту, т.к. Будь-який виявлений дефект негативно впливає на довіру користувачів.

    Верифікація (Verification)

    Валідація (validation)

    Відповідність продукту вимогам (Специфікації)

    Відповідність продукту потребам користувачів

    Дефект (баг) – це невідповідність фактичного результату виконання програми очікуваному результату.

    Слід вміти розрізняти, що:

    • Error – Це помилка користувача, тобто він намагається використовувати програму в інший спосіб (наприклад, вводить літери в поля, де потрібно вводити цифри). У якісній програмі передбачені такі ситуації та видаються повідомлення про помилку (error message).
    • Bug (defect) – це помилка програміста (або дизайнера або ще кого, хто бере участь у розробці), тобто коли в програмі щось йде не так, як планувалося. Наприклад, усередині програма побудована так, що спочатку не відповідає тому, що від неї очікується.
    • Failure – це збій у роботі компонента, всієї програми чи системи (може бути як апаратним, і викликаним дефектом).
    • Серйозність (Severity) – характеризує вплив дефекту на працездатність програми. Виставляється тестувальником.
    • Blocker – Помилка, що приводить додаток в неробочий стан, через яку подальша робота з системою або її ключовими функціями стає неможлива, тобто. тестування значної частини функціональності стає недоступним
    • Крит (Critical) – неправильно працююча ключова бізнес-логіка, дірка в системі безпеки, проблема, що призвела до тимчасового падіння сервера або приводить до неробочого стану деяку частину системи, без можливості вирішення проблеми, використовуючи інші непрямі шляхи (workaround).
    • Значний (Major) – частина основної бізнес логіки працює некоректно, є можливість для роботи з функцією, що тестується, використовуючи обхідні шляхи (workaround); або дефект з високим visibility – зазвичай дефекти дизайну, що не сильно впливають на функціональність, які, однак, відразу кидаються в очі.
    • Minor – часто помилки GUI, які не впливають на функціональність, але псують юзабіліті або зовнішній вигляд; або незначна функціональна помилка, що не порушує бізнес-логіку частини програми, що тестується.
    • Тривіальна (Trivial) – помилка, що не стосується бізнес-логіки програми, яка не впливає на загальну якість продукту, наприклад, друкарські помилки, невідповідність шрифту і відтінку і т.д.
    • Пріоритет (Priority) – вказує на черговість виконання завдання або усунення дефекту. Чим вищий пріоритет, тим швидше потрібно виправляти дефект. Виставляється менеджером, тимлідом чи замовником.

    ДЕЯКІ ТЕХНІКИ ТЕСТ-ДИЗАЙНУ

    1. Еквівалентний Поділ (Equivalence Partitioning) – це техніка, при якій функціонал (часто діапазон можливих значень, що вводяться) поділяється на групи еквівалентних за своїм впливом на систему значень. ПРИКЛАД: є діапазон допустимих значень від 1 до 10, вибирається одне вірне значення всередині інтервалу (наприклад, 5) та одне неправильне значення поза інтервалу – 0.
    2. Аналіз Граничних Значень (Boundary Value Analysis) – це техніка перевірки поведінки продукту на крайніх (граничних) значеннях вхідних даних. Якщо брати вище ПРИКЛАД: як значення для позитивного тестування береться мінімальна та максимальна межі (1 та 10), та значення більше і менше меж (0 та 11). BVA може застосовуватися до полів, записів, файлів, або до будь-яких сутностей, що мають обмеження.
    3. Доменний аналіз (Domain Analysis Testing) – це техніка заснована на розбиття діапазону можливих значень змінної на піддіапазони, з наступним вибором одного або кількох значень кожного домену для тестування.
    4. Передбачення помилки (Error Guessing – EG). Це коли тестувальник використовує свої знання системи та здатність до інтерпретації специфікації щодо того, щоб «передбачити» за яких вхідних умов система може видати помилку.
    5. Причина/Слідство (Cause/Effect – CE). Мається на увазі введення умов для отримання відповіді від системи (слідство).
    6. Сценарій використання (Use Case Testing) — Use Case описує сценарій взаємодії двох і більше учасників (як правило, користувача та системи).
    7. Вичерпне тестування (Exhaustive Testing – ET) – мається на увазі перевірка всіх можливих комбінацій вхідних значень. На практиці не використовується.
    8. Попарне тестування (Pairwise Testing) – це техніка формування наборів тестових даних з повного набору вхідних даних у системі, яка дозволяє суттєво скоротити загальну кількість тест-кейсів. Використовується для тестування, наприклад фільтрів, сортувань. Цей цікавий метод заслуговує на окрему увагу і більш докладно розглядається в статті за посиланням (наприкінці якої згадуються інструменти для автоматизації застосування PT).
    9. Тестування на основі станів та переходів (State-Transition Testing) — застосовується для фіксування вимог та опису дизайну програми.
    10. Таблиця прийняття рішень (decision table) – інструмент для упорядкування бізнес-вимог, які мають бути реалізовані у продукті. Застосовується для систем зі складною логікою. У таблицях рішень подано набір умов, одночасне виконання яких призводить до певної дії.

    ВИДИ ТЕСТУВАННЯ

    Класифікація за цілями

    • Функціональне тестування (functional testing) розглядає заздалегідь зазначене поведінка і полягає в аналізі специфікації компонента чи системи загалом, тобто. перевіряється коректність роботи функціональності програми.
    • Тестування інтерфейсу користувача (GUI Testing) – перевірка інтерфейсу на відповідність вимогам (розмір, шрифт, колір, consistent behavior).
    • Тестування зручності використання (Usability Testing) – це метод тестування, спрямований на встановлення ступеня зручності використання, навчання, зрозумілості та привабливості для користувачів продукту, що розробляється в контексті заданих умов. Складається з: UX – що відчуває користувач під час використання цифрового продукту, та UI – Інструмент, що дозволяє здійснювати інтеракцію «користувач – веб-ресурс».
    • Тестування безпеки (security testing) — це стратегія тестування, яка використовується для перевірки безпеки системи, а також для аналізу ризиків, пов'язаних із забезпеченням цілісного підходу до захисту додатків, хакерів, вірусів, несанкціонованого доступу до конфіденційних даних.
    • Інсталяційне тестування (installation testing) спрямоване на перевірку успішної установки і налаштування, а також оновлення або видалення програми.
    • Конфігураційне тестування (Configuration Testing) — спеціальний вид тестування, спрямований на перевірку роботи програмного забезпечення при різних конфігураціях системи (заявлених платформах, драйверах, що підтримуються, при різних конфігураціях комп'ютерів і т.д.)
    • Тестування на відмову та відновлення (Failover and Recovery Testing) перевіряє тестований продукт з погляду здатності протистояти й успішно відновлюватися, тобто. забезпечувати збереження та цілісність даних, після можливих збоїв, що виникли у зв'язку з помилками програмного забезпечення, відмови обладнання або проблемами зв'язку (наприклад, відмова мережі).
    • Тестування локалізації (localization testing) – перевірка адаптації програмного забезпечення для певної аудиторії відповідно до її культурних особливостей.
    • Навантажувальний тестування (load testing) — визначення або збирання показників продуктивності та часу відгуку програмно-технічної системи або пристрою у відповідь на зовнішній запит з метою встановлення відповідності вимогам до цієї системи (пристрою).
    • Тестування стабільності або надійності (Stability / Reliability Testing) – це перевірка працездатності програми при тривалому (багатогодинному) тестуванні із середнім рівнем навантаження.
    • Стресове тестування (Stress Testing) дозволяє перевірити наскільки додаток і система загалом працездатні за умов стресу (наприклад, підвищення інтенсивності виконання операцій дуже високих значень чи аварійне зміна конфігурації сервера) і навіть оцінити здатність системи до регенерації, тобто. до повернення до нормального стану після припинення дії стресу.
    • Об'ємне тестування (Volume Testing) – тестування, яке проводиться для отримання оцінки продуктивності зі збільшенням обсягів даних у базі даних програми.
    • Тестування масштабованості (scalability testing) — тестування, яке вимірює продуктивність мережі або системи, коли кількість запитів користувача збільшується або зменшується.

    Класифікація за позитивністю сценарію

    • Позитивне – Тест кейс використовує тільки коректні дані і перевіряє, що програма правильно виконала функцію, що викликається.
    • Негативне — тест кейс оперує як коректними так і некоректними даними (мінімум 1 некоректний параметр) і має на меті перевірку виняткових ситуацій; при такому тестуванні часто виконуються некоректні операції.

    Класифікація за знанням системи

    • Тестування білої скриньки (White Box) — спосіб тестування ПЗ, який передбачає повний доступом до коду проекту, тобто. внутрішня структура/пристрій/реалізація системи відомі тестувальнику.
    • Тестування сірої скриньки — метод тестування програмного забезпечення, який передбачає частковий доступ до коду проекту (комбінація White Box та Black Box методів).
    • Тестування чорної скриньки (Black Box) — метод тестування ПЗ, також відомий як тестування, заснований на специфікації чи тестування поведінки — техніка тестування, яка передбачає доступу (повного чи часткового) до системи, тобто. ґрунтується на роботі виключно із зовнішнім інтерфейсом тестованої системи.

    Класифікація за виконавцями тестування

    • Альфа-тестування – є ранньою версією програмного продукту, тестування якої проводиться всередині організації-розробника; Можливе часткове залучення кінцевих користувачів.
    • Бета-тестування — практично готове програмне забезпечення, яке випускається для обмеженої кількості користувачів, розробляється в першу чергу для тестування кінцевими користувачами та отримання відгуків клієнтів про продукт для внесення відповідних змін.

    Класифікація за рівнем тестування

    • Модульна (компонентна) тестування (Unit Testing) проводиться самими розробниками, т.к. передбачає повний доступ до коду, для тестування будь-якого одного логічно виділеного та ізольованого елемента (модуля) системи в коді, перевіряє функціональність і шукає дефекти в частинах програми, які доступні і можуть бути протестовані окремо (модулі програм, об'єкти, класи, функції тощо).
    • Інтеграційне тестування (Integration Testing) спрямовано перевірку коректності взаємодії кількох модулів, об'єднаних у єдине ціле, тобто. перевіряється взаємодія між компонентами системи після проведення компонентного тестування.
    • Знизу нагору (Bottom Up Integration) Усі низькорівневі модулі, процедури або функції збираються докупи і потім тестуються. Після чого збирається наступний рівень модулів щодо інтеграційного тестування. Даний підхід вважається корисним, якщо всі або практично всі модулі, що розробляється, готові. Також цей підхід допомагає визначити за результатами тестування рівень готовності програми.
    • Зверху вниз (Top Down Integration) Спочатку тестуються всі високорівневі модулі і поступово один за одним додаються низькорівневі. Усі модулі нижчого рівня симулюються заглушками з аналогічною функціональністю, потім у міру готовності заміняються реальними активними компонентами.
    • Великий вибух («Big Bang» Integration) Усі або практично всі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини, а потім проводиться інтеграційне тестування. Такий підхід дуже добрий для збереження часу. Проте якщо тест кейси та його результати записані не так, то сам процес інтеграції сильно ускладниться, що стане перепоною для команди тестування при досягненні основної мети інтеграційного тестування.
    • Системне тестування (System Testing) – це перевірка як функціональних, так і не функціональних вимог у системі загалом.При цьому виявляються дефекти, такі як неправильне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання і т.д., і оцінюються характеристики якості системи – її стійкість, надійність, безпека і продуктивність.
    • Операційне тестування (Release Testing). Навіть якщо система задовольняє всі вимоги, важливо переконатися в тому, що вона задовольняє потреби користувача і виконує свою роль у середовищі своєї експлуатації. Тому важливо провести операційне тестування як фінальний крок валідації. Крім цього, тестування в середовищі експлуатації дозволяє виявити і нефункціональні проблеми, такі як: конфлікт з іншими системами, суміжними в галузі бізнесу або в програмних та електронних оточеннях та ін.

    Класифікація за виконанням коду

    • Статичне тестування – процес тестування, який проводиться для верифікації практично будь-якого артефакту розробки. Наприклад, шляхом аналізу коду (Code Review). Аналіз може проводитись як вручну, так і за допомогою спеціальних інструментальних засобів. Метою аналізу є раннє виявлення помилок та потенційних проблем у продукті. Також до цього виду відноситься тестування вимог, специфікацій та іншої документації.
    • Динамічне тестування проводиться у працюючій системі, тобто. із здійсненням запуску програмного коду програми.

    Класифікація з хронології виконання

    • Повторне/підтверджуюче тестування (re-testing/confirmation testing) — тестування, під час якого виконуються тестові сценарії, які виявили помилки під час останнього запуску, на підтвердження успішності виправлення цих помилок, тобто. перевіряється виправлення багів.
    • Регресійне тестування (regression testing) — це тестування після внесення змін до коду програми (починання дефекту, злиття коду, міграція на іншу операційну систему, базу даних, веб-сервер або сервер програми), для підтвердження того факту, що ці зміни не внесли помилки в областях , які зазнали змін, тобто. перевіряється те, що виправлення багів, а також будь-які зміни в коді програми не вплинули на інші модулі ПЗ і не викликали нових багів.
    • Приймальне тестування перевіряє відповідність системи потребам, вимогам та бізнес-процесам користувача.

    ДОКУМЕНТАЦІЯ

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

    Основні атрибути вимог:

    • Повнота — у вимогі має бути вся необхідна для реалізації функціональності інформація.
    • Несуперечливість – вимога не повинна містити внутрішніх протиріч та протиріч іншим вимогам та документам.
    • Недвозначність – вимога має містити однозначні формулювання.
    • Перевірюваність (Тістопридатність) — формулювання вимог таким чином, щоб можна було виставити однозначний вердикт, виконано все відповідно до вимог чи ні.
    • Пріоритетність — кожна вимога має мати пріоритет (кількісна оцінка ступеня значущості вимоги).

    Тест план (Test Plan) – документ, що описує весь обсяг робіт із тестування:

    • Що потрібно випробувати?
    • Як проводитиметься тестування?
    • Коли проводитиметься тестування?
    • Критерії початку тестування.
    • Критерії закінчення тестування.

    Основні пункти, з яких може складатися тест-план, перераховані в стандарті IEEE 829.

    Невід'ємною частиною тест-плану є Traceability matrix. Матриця відповідності вимог (МСТ) – це таблиця, що містить відповідність функціональних вимог (functional requirements) продукту та підготовлених тестових сценаріїв (test cases). У заголовках колонок таблиці розміщені вимоги, а заголовках рядків — тестові сценарії. На перетині — позначка, що означає, що вимога поточної колонки покрита тестовим сценарієм поточного рядка. МСТ використовується для покриття продукту тестами.

    Функціональна вимога 1

    Функціональна вимога 2

    Функціональна вимога 3