Тест-дизайн та техніки тест-дизайну (Test Design and Software Testing Techniques)
Проектування тесту (test design): Процес переведення загальних причин тестування у конкретні тестові умови та тестові сценарії. (ISTQB)
Причина тестування (test objective): Причина чи мета розробки та виконання тесту. (ISTQB)
Тестова умова: Об'єкт або подія в компоненті або системі, яка повинна бути перевірена одним або декількома тестовими наборами. Наприклад: функція, транзакція, властивість, атрибут якості чи структурний елемент. (ISTQB)
Тест-дизайн - важливий етап STLС, а саме діяльність з отримання та визначення тестових прикладів із test objectives та test conditions. Простіше кажучи, мета тест-дизайну - створити максимально ефективний набір кейсів, що покриває найважливіші аспекти ПЗ, що тестується, тобто. мінімізувати кількість тестів, необхідні знаходження більшості серйозних помилок.
Одним з найважливіших аспектів тесту є те, що він перевіряє, чи виконує система те, що вона повинна робити. Copeland каже: "По суті, тестування - це процес порівняння того, що є з тим, що має бути". Якщо ми просто введемо якісь дані і подумаємо, що це було весело, я припускаю, що з системою, ймовірно, все гаразд, тому що вона не фарбувалася, але чи справді ми її тестуємо? Beizer називає це «дитячим тестуванням» (kiddie testing). Ми можемо не знати щоразу, яка правильна відповідь у деталях, і іноді ми все одно можемо отримати деяку вигоду від цього підходу, але насправді це не перевірка. Щоб знати, що система повинна робити, нам потрібне джерело інформації про правильну поведінку системи - це називається оракул або тестовий оракул (test oracle). Після того,
Давайте прояснимо. Вимоги або користувальницькі історії з критеріями прийнятності (форми test basis) визначають, що ви повинні тестувати (test objects and test conditions), і виходячи з цього ви повинні з'ясувати спосіб тестування, тобто спроектувати тестові приклади. Одне з найважливіших питань полягає в наступному: які фактори впливають на успішний дизайн тесту? Якщо ви читаєте різні блоги, статті чи книги, ви знайдете приблизно таке:
Час та бюджет, доступні для тестування;
Відповідні знання та досвід залучених людей;
Визначено цільовий рівень покриття (вимірювання рівня достовірності (measuring the confidence level));
Спосіб організації процесу розроблення програмного забезпечення (наприклад, водоспад або гнучка розробка);
Встановлюється співвідношення методів створення тестів (наприклад, ручних та автоматичних);
Це не правда! Без достатнього часу та бюджету ви, мабуть, взагалі не розпочнете жодного проекту. Якщо у вас немає кваліфікованих фахівців із тестування програмного забезпечення, включаючи дизайн тестів, то, ймовірно, ви теж не розпочнете проект. Однак, хороший дизайн тесту включає три попередні умови:
Повна специфікація (Complete specification) (test bases);
Аналіз ризиків та складності (Risk and complexity analysis);
Історичні дані ваших попередніх розробок;
Потрібні деякі пояснення. Повна специфікація не означає безпомилкову специфікацію, тому що під час розробки тесту можна знайти та виправити безліч проблем (запобігання дефектам). Це тільки означає, що у нас є всі необхідні вимоги або в Agile розробці у нас є всі епіки, теми та історії користувача з критеріями прийнятності (acceptance criteria). Існує мінімальна цінність у одночасному розгляді витрат на тестування та витрат на виправлення дефектів, і мета хорошого тест-дизайну – вибрати відповідні методи тестування, що наближаються до цього мінімуму. Це можна зробити, проаналізувавши складність, ризики та використовуючи історичні дані. Отже, аналіз ризиків неминучий визначення ретельності тестування. Чим вище ризик використання функції/об'єкта, тим паче ретельне тестування необхідне. Те саме можна сказати і про складність коду. Для більш ризикованого або складного коду ми повинні спочатку застосувати більше некомбінаторних методів проектування тестів замість чисто комбінаторного.
Наше інше та правильне уявлення про дизайн тестування полягає в тому, що якщо у вас є відповідна специфікація (тестова база) та надійний аналіз ризиків та складності, то, знаючи ваші історичні дані, ви можете виконати дизайн тесту оптимальним чином. Спочатку у вас немає історичних даних, і ви, мабуть, не досягнете оптимуму. Немає проблем, давайте зробимо попередню оцінку. Наприклад, якщо ризик і складність низькі, використовуйте лише тестування. Якщо вони трохи вищі, використовуйте дослідження та прості методи, що базуються на специфікаціях, такі як класи еквівалентності з аналізом граничних значень. Якщо ризик високий, ви можете використовувати дослідницьке тестування, комбінаційне тестування, запобігання дефектам, статичний аналіз та огляди (reviews).
Ще одне важливе зауваження. Критерії вибору тестів та адекватності тестових даних різні. Перший – невід'ємна частина будь-якої техніки тест-дизайну. Другий перевіряє набір тестів. В результаті процесу розробки тестів створюються незалежні від реалізації тестові приклади, які перевіряють вимоги або користувальницькі історії. Навпаки, тести, що створюються на основі відсутності покриття за обраними критеріями адекватності тестових даних, підтверджують проблеми, що залежать від реалізації; Однак це не дизайн тесту, це створення тесту. Дуже важливо використовувати метод «спочатку тестування» (test-first method), т. е. дизайн тесту має бути відправною точкою розробки. Дизайн тестів також дуже ефективний для запобігання дефектам, якщо він застосовується до застосування.
Отже, хороший процес тест-дизайну виглядає так:
Збір інформації, щоб зрозуміти вимоги користувачів;
отримання всіх важливих бізнес-сценаріїв;
створення тестових сценаріїв для кожного похідного критично важливого бізнес-сценарію;
Призначення всіх запланованих тестових сценаріїв різним тестовим випадкам;
Ролі , відповідальні за тест дизайн:
Тест аналітик (test analyst) – визначає "ЩО тестувати?":
Досліджує продукт:
розуміння мети створення продукту;
Якими способами мета має досягатися;
Які та основні та допоміжні можливості надає продукт користувачам;
Оцінка, чи правильно зрозумів розробник замовника.
Складає логічну карту продукту: Інтелект – карта – це техніка представлення будь-якого процесу, події, думки чи ідеї у систематизованій візуальній формі;
Розбиває програмний продукт на основні частини:
Система розчленовується лише за однією, постійному всім рівнів ознакою (Вони повинні відповідати одне й те питання, стосовно свого батька);
Підсистеми, що вичленюються, повинні взаємно виключати один одного, а в сумі - характеризувати систему;
На кожному рівні рекомендується використовувати трохи більше 7 підсистем;
Розставляє пріоритети для тестування:
Вимоги клієнта;
Ступінь ризику;
Складність системи;
Тимчасові обмеження;
Тест дизайнер - визначає "ЯК тестувати?";
Просто кажучи, завдання тест аналітиків та дизайнерів зводиться до того, щоб використовуючи різні стратегії та техніки тест дизайну, створити набір Test case, що забезпечує оптимальне тестове покриття програми, що тестується. Однак, на більшості проектів ці ролі не виділяється, а довіряється звичайним тестувальникам, що не завжди позитивно позначається на якості тестів, тестуванні і, як випливає, на якості ПЗ (кінцевого продукту).
Техніки тест-дизайну (Software testing techniques)
Статичні (Static):
Reviews:
Неформальне реву (Informal review)
Проходження (Walkthrough)
Технічне рев'ю (Technical Review)
Інспекція (Inspection)
Статичний аналіз (Static Analysis):
Потік даних (Data Flow)
Потік керування (Control Flow)
Шлях (Path)
Стандарти (Standards)
Динамічні (Dynamic):
Біла скринька (White-box, Structure-Based)
Вираз (Statement)
Рішення (Decision)
Гілка (Branch)
Умова (Condition)
Кінцевий автомат (FSM)
Засновані на досвіді (Experience-based):
Передбачення помилки (Error Guessing – EG);
Дослідницьке тестування (Exploratory Testing);
Ad-hoc testing;
Чорний ящик (Black-box, Specification-based):
Еквівалентний Поділ (Equivalence Partitioning – EP)
Аналіз Граничних Значень (Boundary Value Analysis – BVA)
Переходи між станами (State transition)
Випадки використання (Use case testing)
Domain testing
Decision Table Testing
Classification Tree Method
State Transition Testing
Cause-Effect Graphing
Scenario Testing
Random Testing
Syntax Testing
Check List Based Testing
Risk-Based Testing
User Journey Test
Джерела:
Дод. матеріал:
Борис Бейзер – “Тестування чорної скриньки. Технології функціонального тестування програмного забезпечення та систем”
Last updated