Аналіз тестів та основи тестування
Томас Гамільтон
⚡ Розумний підсумок
Тестовий аналіз, також званий тестовою основою, — це структурований огляд вимог, проектної документації та інших артефактів, що використовуються для визначення тестованих умов. У цій статті пояснюються джерела, покроковий робочий процес та розміщення тестового аналізу в V-моделі.
Аналіз тестів, також відомий як тестова основа, знаходиться на самому початку життєвого циклу тестування. Кожна тестова умова та тестовий випадок зрештою tracповертаємося до цього. У розділах нижче визначається термін, пояснюються його джерела, дається покрокова інструкція з аналізу та розміщується його у V-моделі.
Що таке тестовий аналіз?
Аналіз тесту У тестуванні програмного забезпечення це процес перевірки вхідних даних, що використовуються для визначення тестових умов та тестових випадків. Ці вхідні дані — специфікації, вимоги, проектна документація, історії користувачів та аналогічні результати — разом називаються артефакти тестуМета тестового аналізу полягає в тому, щобtracЦілі t-тесту достатньо чіткі, щоб кожну з них можна було перетворити на однозначну умову тестування. Оскільки аналізований матеріал формує основу, на якій базуються всі тести, його також називають Тестова основа.
Типові джерела, з яких тестувальники отримують інформацію для тестування, включають:
- SRS — Специфікація вимог до програмного забезпечення
- BRS — Специфікація бізнес-вимог
- Функціональні проектні документи
- Користувацькі історії, критерії прийнятності та вайрфрейми
Тестери також можуть створювати тестові умови, досліджуючи безпосередньо тестовану програму або спираючись на минулий досвід, але більшість тестові справи походять з артефактів тестування для підтримки tracлегкість.
👉 Зареєструйтесь на безкоштовний проект тестування програмного забезпечення в реальному часі
Чому важливий тестовий базис?
Тестова основа є найважливішим фактором, що визначає, чи виявляє тестовий набір реальні дефекти, чи переслідує фантомні. Розгляд її як необов'язкової є найпоширенішою причиною потрапляння помилок у продакшн. Надійний аналіз тестів забезпечує чотири конкретні переваги:
- Tracможливість: Кожен тестовий випадок можна пов'язати з певною вимогою, що робить аналіз впливу змін швидким, а аудиторські перевірки безболісними.
- Чіткість покриття: Revперегляд прогалин базисних поверхонь — невизначених станів помилок, відсутніх граничних випадків, невизначених нефункціональних порогів — до того, як вони стануть виробничими інцидентами.
- Узгодження інтересів зацікавлених сторін: Коли команда тестування отримує умови з тих самих документів, на яких базується команда розробників, обидві сторони мають спільне визначення «готово».
- Раннє виявлення дефектів: Багато дефектів вимог (неоднозначність, суперечності, відсутність критеріїв прийнятності) виявляються під час самого тестового аналізу, задовго до написання будь-якого коду — це, безумовно, найдешевше місце для їх виправлення.
Загальні джерела тестової бази
Різні артефакти забезпечують різні рівні тестування. Використовуйте таблицю нижче як швидкий орієнтир, вирішуючи, з яким документом звертатися під час написання тестових випадків.
| Артефакт джерела | Найкраще підходить для | Що ти колишній/колишняtract |
|---|---|---|
| Специфікація бізнес-вимог (BRS) | Приймальні та системні випробування | Комплексні бізнес-правила, регуляторні обмеження, критерії успіху |
| Специфікація вимог до програмного забезпечення (SRS) | Тестування системи | Функціональні та нефункціональні вимоги з вимірюваними порогами |
| Документи функціонального/технічного проектування | Інтеграційне тестування | Інтерфейси модулів, потік даних, специфікації обробки помилок |
| Історії користувачів та критерії прийнятності | Гнучке спринт-тестування | Поведінкові очікування у формі «Дано–Коли–Тоді» |
| Ваєрфрейми та макети інтерфейсу користувача | Тестування інтерфейсу користувача / зручності використання | Макет, навігація, правила перевірки вхідних даних |
| Застосунок у процесі тестування (дослідний) | Дослідницьке та регресійне тестування | Недокументована поведінка, реальні робочі процеси, граничні випадки |
Як виконати тестовий аналіз крок за кроком
Ефективний аналіз тестів дотримується повторюваного п'ятиетапного робочого процесу, незалежно від розміру проекту чи методології.
- Зберіть та проінвентаризуйте тестову базу. Зберіть кожен артефакт, що описує заплановану поведінку — SRS, BRS, проектну документацію, історії користувачів, макети. Зверніть увагу, який документ містить кожну вимогу, щоб tracПрацездатність залишається незмінною.
- Revперегляд для тестованості. Прочитайте кожен артефакт, маючи на увазі три питання: Чи є це твердження вимірним? Чи воно однозначне? Чи воно повне? Позначте будь-яку вимогу, яка не проходить одну з цих перевірок, і поверніть її автору, перш ніж писати тести для неї.
- Визначте умови випробування. Для кожного тестованого твердження перелічіть умови, які потребують перевірки (позитивні шляхи, негативні шляхи, граничні значення, обробка помилок, безпека, продуктивність). Тестова умова – це абс.tracт «що» — наприклад, «Система відхиляє замовлення з нульовою кількістю» — відмінне від конкретного «як» у тестовому випадку.
- Розставте пріоритети та згрупуйте умови. Класифікуйте кожну умову за ризиком та частотою використання. Умови високого ризику та високої частоти потребують детального охоплення; умови низького ризику можна комбінувати або вибірково обробляти. Тут також ви вирішуєте, які умови є кандидатами для автоматизації.
- Перетворіть умови на тестові випадки. Кожна пріоритетна умова стає однією або кількома тестові справи з передумовами, кроками, тестовими даними та очікуваними результатами. Підтримуйте вимоги tracМатриця доцільності, що пов'язує кожен тестовий випадок з його початковою вимогою.
Дотримання цієї послідовності дозволяє уникнути найпоширеніших помилок тестового аналізу: написання тестових випадків без чіткої основи, пропуску негативних сценаріїв та створення тестів, які неможливо пов'язати з вимогою під час сортування дефектів.
Аналіз тестів у V-моделі
V-модель поєднує кожну дію розробки з відповідною діяльністю тестування. Аналіз тестування відбувається на кожному рівні з використанням будь-якого документа, доступного на даний момент життєвого циклу.
Рисунок 1: Аналіз тестів на різних фазах V-модель.
Тематичне дослідження: Виведення тестових випадків з вимог клієнта
Розглянемо сценарій, у якому клієнт надсилає наступну однорядкову вимогу.
Client requirement: Add search functionality to an eCommerce Store
Навіть якщо застосунок ще не створено, тестер вже може вивести кілька тестових умов, аналізуючи, що передбачає вимога — як поведінку «щасливого шляху», так і режими відмови, які клієнт не вказав явно. Ось кілька прикладів:
- Перевірити результат пошуку, якщо ключове слово не введено.
- Перевірити результат пошуку, якщо для введеного ключового слова не існує відповідного продукту.
- Перевірити результат пошуку, якщо для ключового слова існує кілька відповідних товарів.
- Перевіряйте поведінку за допомогою спеціальних символів, початкових/кінцевих пробілів та дуже довгих вхідних даних.
- Перевірте чутливість до регістру та часткове збігання.
- Перевірте час відгуку пошуку за очікуваного навантаження користувачів.
Тестувальник бере вимогу клієнта (тестову основу), аналізує її та перетворює на умови тестування. Цей шаблон повторюється на кожному етапі V-моделі — плани тестування та тестові випадки створюються з використанням будь-якого документа, доступного на даний момент життєвого циклу.
Відео: Пояснення аналізу тестів
Якщо відео не завантажується, перегляньте його безпосередньо на YouTube.
