Dynamic - Black box
Розробка тестів методом чорної скриньки (black box test design technique): Процедура створення та/або вибору тестових сценаріїв, заснована на аналізі функціональної або нефункціональної специфікації компонента або системи без знання внутрішньої структури. (ISTQB)
Засновані на специфікації методи проектування тестування використовуються для отримання контрольних прикладів базису тестування, що визначає очікувану поведінку елемента тестування. При використанні цих методів вхідні дані для тестування контрольного прикладу та очікуваний результат виходять з базису тестування. Вибір, які з заснованих на специфікації методів проектування тестування використовувати у кожній конкретній ситуації, залежить від природи базису тестування та/або елемента тестування та від властивих ризиків. (ГОСТ 56920)
Всі specification-based або Black Box testing techniques можуть бути зручно описані та систематизовані за допомогою наступної таблиці:
Група
Техніка
Коли використовується
Елементарні техніки:
зосереджені на аналізі вхідних/вихідних параметрів;
можна комбінувати для найкращого покриття;
зазвичай не використовують та не залежать від інших методик;
Equivalence Partitioning
Вхідні та вихідні параметри мають велику кількість можливих значень
Boundary Value Analysis
Значення параметрів мають явні (наприклад, чітко визначені в документації) межі та діапазони або неявні (наприклад, відомі технічні обмеження) межі
Комбінаторні стратегії:
поєднують можливі значення кількох параметрів введення/виведення;
можуть використовувати елементарні прийоми зменшення кількості можливих значень;
All Combinations
Кількість можливих комбінацій вхідних значень досить мало, або кожна окрема комбінація вхідних значень призводить до певного вихідного значення
Pairwise Testing
Кількість вхідних комбінацій надзвичайно велика і має бути скорочена до прийнятного набору кейсів
Each Choice Testing
У вас є функції, при яких скоріше конкретне значення параметра викликає помилку, ніж комбінація значень
Base Choice Testing
Ви можете виділити набір значень параметрів, що має найбільшу ймовірність використання
Просунуті техніки:
допомагають проаналізувати Систему з погляду бізнес-логіки, ієрархічних відносин, сценаріїв тощо;
аналіз заснований на даних, організованих у таблиці, діаграми та шаблони;
може покладатися на елементарні та комбінаторні методи розробки тестових прикладів;
Decision Table Testing
Існує набір комбінацій параметрів та їх вихідних даних, що описуються бізнес-логікою чи іншими правилами
Classification Tree Method
У вас є ієрархічно структуровані дані або дані можуть бути представлені у вигляді ієрархічного дерева
State Transition Testing
У функціональності є очевидні стани, переходи яких регулюються правилами (наприклад, потоки)
Cause-Effect Graphing
Причини (входи) та наслідки (виходи) пов'язані великою кількістю складних логічних залежностей
Scenario Testing
У функціоналі є чіткі сценарії
Інші техніки
Random Testing
Вам необхідно імітувати непередбачуваність реальних вступних даних, або функціональність має несистематичні дефекти
Syntax Testing
Функціональність має складний синтаксичний формат для вхідних даних (наприклад, коди, складні імена електронної пошти тощо)
Еквівалентний поділ (Equivalence Partitioning (ISTQB/Myers 1979) / Equivalence Class Testing (Lee Copeland))
Клас еквівалентності є набором даних, які або однаково обробляються модулем, або їх обробка видає однакові результати. При тестуванні будь-яке значення даних, що входить до класу еквівалентності, аналогічно до будь-якого іншого значення класу.
Еквівалентний поділ – це поділ всього набору даних введення/виведення на такі розділи. Таким чином, вам не потрібно виконувати тести для кожного елемента підмножини, і достатньо однієї перевірки, щоб охопити все підмножина. Хитрість у тому, щоб побачити та ідентифікувати розділи, т.к. далеко не завжди вони є числами.
Приклад: Ми пишемо модуль для системи відділу кадрів, який визначає, у якому порядку слід розглядати заяви прийому працювати залежно від віку кандидата.
Правила нашої організації такі:
від 0 до 16 - не приймаються;
від 16 до 18 - можуть бути прийняті лише на неповний робочий день;
від 18 до 55 - можуть бути прийняті як співробітники на повний робочий день;
від 55 до 99 - не приймаються;
Що у коді виглядає як:
If (applicantAge >= 0 && applicantAge <=16)
hireStatus="NO";
If (applicantAge >= 16 && applicantAge <=18)
hireStatus="PART";
If (applicantAge >= 18 && applicantAge <=55)
hireStatus="FULL";
If (applicantAge >= 55 && applicantAge <=90)
hireStatus="NO";
З чого очевидно, що замість 100 кейсів нам знадобиться 4 за кількістю еквівалентних класів, всі інші кейси всередині своїх класів будуть давати однаковий результат тестів і є надмірними.
Тепер ми готові розпочати тестування? Мабуть, ні. Що про такі вхідні дані як 969, -42, FRED або &$#! ? Чи маємо ми створювати тестові сценарії для некоректних вхідних даних? Для того, щоб зрозуміти відповідь, ми повинні перевірити підхід, який прийшов з об'єктно-орієнтованого світу, названий "проектування-по-контракту".
У підході "проектування-по-контракту" модулі (у парадигмі об'єктно-орієнтованого програмування вони називаються "методами", але "модуль" є більш загальним терміном) визначені у термінах передумов та постумов. Постуслів визначають, що модуль обіцяє зробити (обчислити значення, відкрити файл, надрукувати звіт, оновити запис у базі даних, змінити стан системи і т.д.). Передумови описують вимоги до модуля, у яких він перетворюється на стан, описуване постумовами.
Наприклад, якщо у нас є модуль "openFile", що він обіцяє зробити? Відкрийте файл. Які будуть розумні передумови цього модуля?
файл повинен існувати,
ми маємо надати ім'я (або іншу ідентифікуючу інформацію),
файл може бути " відкривається " , тобто. він не може бути відкритим в іншому процесі,
ми повинні мати права доступу до файлу і т.д.
Передумови та постумови засновують контракт між модулем та всіма, хто його викликає. Тестування-по-контракту ґрунтується на філософії проектування-по-контракту. При використанні цього підходу ми створюємо ті тест-кейси, які задовольняють нашим передумовам. Наприклад, ми не будемо тестувати модуль openFile, якщо файл не існує. Причина проста. Якщо файл не існує, то openFile не обіцяє працювати. Якщо немає вимоги працездатності за певних умов, немає необхідності проводити тестування у умовах.
У цей момент випробувачі зазвичай заперечують. Так, вони згодні, що модуль не претендує на роботу в цьому випадку, але що робити, якщо передумови порушуються у процесі розробки? Що робити системі? Чи повинні ми отримати повідомлення про помилку на екрані або воронку, що димить, на місці нашої компанії? Іншим підходом до проектування є оборонне проектування. І тут модуль призначений прийому будь-якого вхідного значення. Якщо виконані звичайні передумови, модуль досягне своїх звичайних постумов. Якщо звичайні попередні умови не виконуються, то модуль повідомить зухвалого, повернувши код помилки або кинувши виняток (залежно від мови програмування, що використовується). Насправді це повідомлення є ще однією з постумов модуля.
За підсумками цього підходу ми могли б визначити оборонне тестування: підхід, який аналізує як звичайні, і незвичайні попередні умови.
Чи потрібно робити перевірку з такими вхідними значеннями, як -42, FRED і &$#! @? Якщо ми використовуємо проектування-по-контракту та тестування-по-контракту, то відповідь "Ні". Якщо ми використовуємо оборонне проектування і тому оборонне тестування, то відповідь "Так". Запитайте у ваших проектувальників, який підхід вони використовують. Якщо їх відповіддю буде «контрактний» чи «оборонний», ви знаєте, який стиль тестування використовувати. Якщо вони дадуть відповідь "Хм?", то це означає, що вони не думають про те, як взаємодіють модулі. Вони не думають про передумови та постумови контрактів. Вам варто очікувати, що інтеграційне тестування буде головним джерелом дефектів, буде складнішим і вимагатиме більше часу, ніж очікувалося.
Незважаючи на те, що тестування класів еквівалентності корисне, його найбільшим внеском є те, що воно призводить до тестування граничних значень.
Аналіз граничних значень (BVA - Boundary Value Analysis (Myers 1979)/range checking)
Тестування класів еквівалентності – це найголовніша методика тест-дизайну. Вона допомагає тестувальникам вибрати невелику підмножину з усіх можливих тестових сценаріїв і забезпечити прийнятне покриття. Ця техніка має ще один плюс. Вона призводить до ідеї про тестування граничних значень – другої ключової техніки тест-дизайну.
приклад. Вище описані правила, які вказували, яким чином відбуватиметься обробка заявок на вакансії залежно від віку претендента.
Зверніть увагу на проблеми на кордонах – це "краї" кожного класу. Вік "16" входить у два різні класи еквівалентності (як і "18", і "55"). Перше правило не наймати шістнадцятирічних. Друге правило свідчить, що шістнадцятирічні можуть бути найняті на неповний робочий день. Тестування граничних значень фокусується на кордонах саме тому, що там заховано дуже багато дефектів. Досвідчені тестувальники стикалися із цією ситуацією багато разів. У недосвідчених тестувальників може виникнути інтуїтивне відчуття, що помилки виникатимуть найчастіше на кордонах. Ці дефекти можуть бути у вимогах, або в коді, якщо програміст помилиться із зазначенням меж у коді (включно/не включно, індекс +-1).
Спробуємо виправити наведений вище приклад:
від 0 до 15 - не приймаються;
від 16 до 17 - можуть бути прийняті лише на неповний робочий день;
від 18 до 54 - можуть бути прийняті як співробітники на повний робочий день;
від 55 до 99 - не приймаються;
А що щодо віку -3 та 101? Зверніть увагу, що вимоги не вказують, як слід розглядати ці значення. Ми можемо здогадатися, але "вгадування вимог" не є прийнятною практикою. Наступний код реалізує виправлені правила:
if (applicantAge >= 0 && applicantAge <= 15)
hireStatus = "NO";
if (applicantAge >= 16 && applicantAge <= 17)
hireStatus = "PART";
if (applicantAge >= 18 && applicantAge <= 54)
hireStatus = "FULL";
if (applicantAge >= 55 && applicantAge <= 99)
hireStatus = "NO";
У цьому прикладі цікавими значеннями на кордонах або поблизу них є {-1, 0, 1}, {15, 16, 17}, {17, 18, 19}, {54, 55, 56} та {98, 99, 100 }. Інші значення, наприклад {-42, 1001, FRED, %$#@} можуть бути включені залежно від умов документації модуля.
Для створення тест-кейсів для кожного граничного значення визначте класи еквівалентності, виберіть одну точку на кордоні, одну точку трохи нижче за кордон і одну точку трохи вище за кордон. Варто зазначити, що точка трохи вище за кордон може входити в інший клас еквівалентності. У такому разі не потрібно дублювати тест. Те саме може бути вірно по відношенню точки трохи нижче кордону.
Тестування граничних значень є найбільш підходящим там, де вхідні дані є безперервним діапазоном значень.
Тестування таблиць рішень (Decision Table testing)
Цей простий, але ефективний метод полягає у документуванні бізнес-логіки у таблиці як набори правил, умов виконання дій та самих дій. Тестування таблиць прийняття рішень може бути використане, коли система має реалізовувати складні бізнес-правила, коли ці правила можуть бути представлені у вигляді комбінації умов і коли ці умови мають дискретні дії, пов'язані з ними.
приклад. Компанія з автострахування дає знижку водіям, які перебувають у шлюбі та/або добре навчаються.
-
Правило 1
Правило 2
Правило 3
Правило 4
Умови
-
-
-
-
Перебуває у шлюбі?
Так
Так
Ні
Ні
Гарний студент?
Так
Ні
Так
Ні
-
-
-
-
-
Дії
-
-
-
-
Знижка ($)
60
25
50
0
Ця таблиця містить всі комбінації умов. Задавши дві бінарні умови ("так" чи "ні"), можливі комбінації будуть: ("так", "так"), ("так", "ні"), ("ні", "так") і (" ні ні"). Кожне правило є однією з цих комбінацій. Нам, тестувальникам, потрібно буде перевірити, чи визначаються всі комбінації умов. Пропущене поєднання може призвести до розробки такої системи, яка зможе правильно обробити певний набір вихідних даних. Кожне правило є причиною "запуску" дії. Кожне правило може задати дію, унікальну для цього правила, або правила можуть мати спільні дії. Для кожного правила за допомогою таблиці рішень можна вказати більше однієї дії. Знову ж, ці правила можуть бути унікальними або загальними. У такій ситуації вибрати тести просто – кожне правило (вертикальна колонка) стає тест-кейсом. Умови вказують на вхідні значення, а дії – на очікувані результати.
Якщо система, що тестується, має складні бізнес-правила, а у ваших бізнес-аналітиків або проектувальників немає документації цих правил, то тестувальникам слід зібрати цю інформацію і подати її у вигляді таблиці рішень. Причина проста: представляючи поведінку системи у такій повній та компактній формі, тест-кейси можуть бути створені безпосередньо з таблиці рішень. При тестуванні кожного правила створюється як мінімум один тест-кейс. Якщо стан цього правила бінарний, то має бути достатньо одного тесту для кожного поєднання. З іншого боку, якщо стан є діапазоном значень, тестування має враховувати і нижню, і вищу межі діапазону. Таким чином, ми об'єднуємо ідею тестування граничних значень з тестуванням таблиць рішень.
Щоб створити тестову таблицю, просто змініть заголовки рядків та стовпців: правила стануть тест-кейсами, умови вхідними значеннями, а дії очікуваними результатами.
Комбінаторні техніки тест-дизайну (Combination Strategies)
Комбінаторне тестування (combinatorial testing): Метод, що дозволяє виділити відповідну підгрупу тестових комбінацій з метою домогтися певного рівня покриття при тестуванні об'єкта з множинними параметрами у випадках, коли ці параметри самі по собі складаються з кількох значень, що призводить до появи більшої кількості комбінацій, ніж можна встигнути протестувати за відведений час. також метод дерева класифікації, попарне тестування, n-вимірне (перебірне) тестування, тестування з використанням ортогонального масиву. (ISTQB)
Тестові приклади вибираються на основі деякого поняття покриття, і мета стратегії комбінування полягає в тому, щоб вибрати тестові приклади з набору тестів таким чином, щоб було досягнуто 100% покриття.
1-wise coverage (each-used) – це найпростіший критерій покриття. Для 100% each-used покриття потрібно, щоб кожне значення кожного параметра було включено хоча б один тестовий приклад в наборі тестів.
2-wise (pair-wise) coverage вимагає, щоб кожну можливу пару значень будь-яких двох параметрів було включено в деякий тестовий приклад. Зверніть увагу, що той самий тестовий приклад часто охоплює більше однієї унікальної пари значень.
Природним продовженням 2-wise coverage є t-wise coverage, яке вимагає включення всіх можливих комбінацій цікавих значень параметрів t будь-який тестовий приклад у наборі тестів.
Найретельніший критерій покриття, N-wise coverage, вимагає набору тестів, який містить усі можливі комбінації значень параметрів у input parameter model (IPM).
Усі комбінації (All combinations): як видно з назви, цей алгоритм має на увазі генерацію всіх можливих комбінацій. Це означає вичерпне тестування і має сенс лише за розумної кількості комбінацій. Наприклад, 3 змінні із 3 значеннями для кожної дають нам матрицю параметрів 3х3 з 27 можливими комбінаціями.
Тестування кожного вибору (EC - Each choice testing): ця стратегія вимагає, щоб кожне значення кожного параметра було включено принаймні один тестовий приклад (Ammann & Offutt, 1994). Це також визначення 1-wise coverage.
Тестування базового вибору(BC – Base choice testing): алгоритм стратегії комбінування базового вибору починається з визначення одного базового тестового прикладу. Базовий тестовий приклад може бути визначений за будь-яким критерієм, включаючи найпростіший, найменший або перший. Критерій, запропонований Амманом і Оффуттом (Ammann & Offutt, 1994), - це «найбільш ймовірне значення» з погляду кінцевого користувача. Це значення може бути визначено тестувальником або засноване на робочому профілі, якщо існує. З базового тестового прикладу створюються нові тестові приклади, змінюючи значення одного параметра, що цікавлять, за раз, зберігаючи значення інших параметрів фіксованими в базовому тестовому прикладі. Базовий вибір включає кожне значення кожного параметра принаймні в одному прикладі, тому він задовольняє 1-wise coverage.
Попарне тестування (Pairwise testing)
Pairwise testing – техніка тест-дизайну, а саме метод виявлення дефектів з використанням комбінаційного методу із двох тестових випадків. Він заснований на спостереженнях про те, що більшість дефектів викликано взаємодією не більше двох факторів (дефекти, що виникають при взаємодії трьох і більше факторів, як правило, менш критичні). Отже, вибирається пара двох тестових параметрів, і всі можливі пари цих двох параметрів відправляються як вхідні параметри для тестування. Pairwise testing скорочує загальну кількість тест-кейсів, тим самим зменшуючи час та витрати, витрачені на тестування. Захоплюючою надією попарного тестування є те, що шляхом створення та запуску 1-20% тестів ви знайдете 70-85% загального обсягу дефектів.
Приклад: По ТЗ сайт повинен працювати у 8 браузерах, використовуючи різні плагіни, запускатись на різних клієнтських операційних системах, отримувати сторінки від різних веб-серверів, працювати з різними серверними операційними системами. Разом:
8 браузерів;
3 плагіна;
6 клієнтських операційних систем;
3 сервери;
3 серверні операційні системи;
= 1296 комбінацій. Кількість комбінацій настільки велика, що, швидше за все, у нас не вистачить ресурсів, щоб спроектувати та пройти тест-кейси. Не слід намагатися перевірити всі комбінації значень для всіх змінних, а слід перевіряти комбінації пар значень змінних.
Використання всіх пар для створення тест-кейсів ґрунтується на двох техніках:
Ортогональні масиви (OA - Orthogonal Array): це двовимірний масив символів. На прикладі вище ми складаємо таблицю, де стовпці є змінними (браузер, плагін, клієнтська операційна система, веб-сервер і серверна операційна система, а рядки - значення кожної змінної (Chrome/Opera, Windows 8/10/11 і т.п.) .) Після чого потрібно визначити ортогональний масив, у якого буде стовпець для кожної змінної (кожен стовпець ортогонального масиву має стільки ж варіантів значень, скільки має ваша змінна). всього лише 64 тестами.
Алгоритм Allpairs: генерує пари безпосередньо, не вдаючись до таких до ортогональних масивів. "Незбалансований" характер алгоритму вибору всіх пар вимагає лише 48 тестів для прикладу. Слід зазначити, що комбінації, вибрані методом ортогонального масиву, можуть бути не такими, як ті, які вибрані Allpairs. Але це не важливо. Важливо лише те, щоб було обрано всі парні комбінації параметрів. Це будуть комбінації, які ми хочемо перевірити.
Докладніше з розбором прикладу див. у Копленда у розділі 6.
На практиці ж ці масиви вручну ніхто не формує, всю механіку реалізують автоматизовані інструменти, найпопулярніший з них PICT. Тестувальнику залишається лише підготувати та згодувати дані.
Classification tree метод
Метод дерева класифікації (Classification tree method): Розробка тестів методом чорної скриньки, в якій тестові сценарії, описані засобами дерева класифікації, розробляються для перевірки комбінацій вибірок вхідних та/або вихідних підмножин. (Grochtmann) Див. також комбінаторне тестування.
Метод дерева класифікації: вид комбінаторної техніки, у якій тестові приклади, описані за допомогою дерева класифікації, призначені для виконання комбінацій представників вхідних та/або вихідних доменів.
Щоб розрахувати кількість тестових прикладів, нам необхідно проаналізувати вимоги, визначити відповідні тестові функції (класифікації) та відповідні значення (класи).
Зазвичай для створення Classification tree використовується інструмент Classification Tree Editor. Якщо ж взяти аркуш паперу та ручку, то у нас є тестовий об'єкт (цілий додаток, певна функція, абстрактна ідея тощо) вгорі як корінь. Ми малюємо відгалуження від кореня як класифікації (перевіряємо відповідні аспекти, які ми визначили). Потім, використовуючи класи еквівалентності та аналіз граничних значень, ми визначаємо наше листя як класи з діапазону всіх можливих значень для конкретної класифікації. І якщо деякі з класів можуть бути класифіковані далі, ми малюємо підвітку / класифікацію з власним листям / класами. Коли наше дерево завершено, ми робимо проекції листя на горизонтальній лінії (Test case), використовуючи одну з комбінаторних стратегій (all combinations, each choice тощо),
Максимальна кількість тестових прикладів - це декартовий добуток всіх класів усіх класифікацій у дереві, що швидко призводить до великих чисел для реалістичних тестових завдань. Мінімальна кількість тестових прикладів - це кількість класів у класифікації з класами, що найбільш утримуються. На другому етапі тестові приклади складаються шляхом вибору одного класу з кожної класифікації дерева класифікації.
Тестування переходів між станами (State Transition testing)
Таблиця станів (state table): Таблиця, що показує кінцеві переходи кожному за стану внаслідок кожної можливої події, як коректних, так некоректних переходів. (ISTQB)
Тестування переходів між станами визначається як метод тестування ПЗ, при якому зміни вхідних умов викликають зміни стану в додатку, що тестується (AUT). У цьому методі тестувальник надає як позитивні, і негативні вхідні значення тесту і записує поведінка системи. Це модель, на якій засновані система та тести. Будь-яка система, в якій ви отримуєте різні вихідні дані для того самого введення, залежно від того, що сталося раніше, є системою кінцевих станів. Техніка тестування переходів між станами є корисною, коли вам потрібно протестувати різні системні переходи. Цей підхід найкраще підходить там, де можна розглядати всю систему як кінцевий автомат. Для наочності візьмемо класичний приклад покупки авіаквитків:
Стан (state, представлений у вигляді кола на діаграмі) - це стан програми, в якому вона очікує одну або більше подій. Стан пам'ятає вхідні дані, отримані раніше, і показує, як додаток буде реагувати на отримані події. Події можуть викликати зміну стану та/або ініціювати дії;
Перехід (transition, представлене у вигляді стрілки на діаграмі) - це перетворення одного стану на інший, що відбувається за подією;
Подія (event, представлена ярликом над стрілкою) - це щось, що змушує додаток змінити свій стан. Події можуть надходити ззовні програми, через інтерфейс програми. Сама програма також може генерувати події (наприклад, подія «вийшов таймер»). Коли відбувається подія, програма може змінити (або не змінити) стан і виконати (або не виконати) дію. Події можуть мати параметри (наприклад, подія «Оплата» може мати параметри «Готівка», «Чек», «Прибуткова картка» або «Кредитна картка»);
Дія (action, представлена після "/" в ярлику над переходом) ініціюється зміною стану ("надрукувати квиток", "показати на екрані" та ін.). Зазвичай дії створюють щось, що є вихідними/повертаними даними системи. Дії виникають при переходах, самі собою стану пасивні;
Крапка входу позначається чорним кружком;
Точка виходу показується на діаграмі як мішені;
Все починається з точки входу. Ми (клієнти) надаємо авіакомпанії інформацію для бронювання. Службовець авіакомпанії є інтерфейсом між нами та системою бронювання авіаквитків. Він використовує надану інформацію для створення бронювання. Після цього наше бронювання перебуває у стані «Створено». Після створення бронювання система також запускає таймер. Якщо час таймера спливає, а заброньований квиток ще не сплачено, система автоматично знімає бронь.
Кожна дія, виконана над квитком, та відповідний стан (скасування бронювання користувачем, оплата квитка, отримання квитка на руки, тощо) відображаються у блок-схемі.
З отриманої схеми складається набір тестів.
Визначимо чотири різні рівні покриття:
Набір тестів, у якому всі стани будуть відвідані щонайменше один раз. Цій вимогі задовольняє набір із трьох тестів, показаний нижче. Зазвичай, це низький рівень тестового покриття.
Набір тестів, у якому всі події виконуються щонайменше один раз. Слід зазначити, що тест-кейси, які покривають кожну подію, можуть бути точно тими самими, що покривають кожний стан. Знову ж таки, це низький рівень покриття.
Набір тестів, в якому всі шляхи будуть пройдені щонайменше один раз. Незважаючи на те, що цей рівень є найкращим через його рівень покриття, це може бути нездійсненно. Якщо діаграма станів і переходів містить петлі, кількість можливих шляхів може бути нескінченним.
Набір тестів, в якому всі переходи будуть здійснені щонайменше один раз. Цей рівень тестування забезпечує добрий рівень покриття без породження великої кількості тестів. Цей рівень, як правило, один із рекомендованих.
Діаграма станів та переходів - не єдиний спосіб документування поведінки системи. Діаграми, можливо, легше у розумінні, але таблиці станів та переходів можуть бути простіше у використанні на постійній та тимчасовій основі. Таблиці станів і переходів складаються з чотирьох стовпців - "Поточний стан", "Подія", "Дія" та "Наступний стан". Перевага таблиці станів та переходів у тому, що в ній перераховуються всі можливі комбінації станів та переходів, а не лише допустимі. При вкрай необхідному тестуванні систем з високим ступенем ризику, наприклад, авіаційної радіоелектротехніки або медичних пристроїв, може знадобитися тестування кожної пари стан-перехід, включаючи ті, які не є допустимими. Крім того, створення таблиці станів і переходів часто витягує комбінації, які були визначені, задокументовані чи розглянуті у вимогах. Дуже корисно виявити ці дефекти на початок кодування.
Використання таблиці станів та переходів може допомогти виявити дефекти в реалізації, які дозволяють неприпустимі шляхи з одного стану до іншого. Недоліком таких таблиць є те, що коли кількість станів і подій зростає, вони дуже швидко стають величезними. З іншого боку, у таблицях, зазвичай, більшість клітин порожні.
Докладніше з розбором прикладу див. у Копленда у розділі 7.
Domain testing
Аналіз доменів (domain analysis): Методика розробки тестів, що відноситься до методу чорної скриньки, що використовується для визначення дієвих та ефективних тестових сценаріїв у випадках, коли множинні параметри можуть або повинні бути протестовані одночасно. Методика базується та узагальнює методи еквівалентного розбиття та аналізу граничних значень/ (ISTQB)
У розділах із тестування класів еквівалентності та граничних значень ми розглянули тестування одиночних змінних, які вимагали оцінки у зазначених діапазонах. У цьому розділі ми розглянемо тестування кількох змінних одночасно. Існують дві причини, через які варто звернути на це увагу:
у нас рідко буде достатньо часу на створення тест-кейсів для кожної змінної у нашій системі. Їх просто надто багато;
часто змінні взаємодіють. Значення однієї змінної обмежує допустимі значення інший. У разі, якщо перевіряти змінні поодинці, можна виявити деякі дефекти;
Domain-тестування - це техніка, яка може застосовуватися для визначення ефективних і дієвих тест-кейсів, коли кілька змінних (наприклад, поля введення) повинні перевірятися разом - або для ефективності, або через їх логічну взаємодію. Вона використовує та узагальнює тестування класів еквівалентності та граничних значень у n одновимірних вимірах. Подібно до цих технік, ми шукаємо випадки, де кордон був невірно визначений або реалізований. Незважаючи на те, що ця техніка найкраще підходить для числових значень, вона може бути узагальнена на інші типи - boolean, string, enumeration і т.д.
У двомірному вимірі (з двома взаємодіючими параметрами) можуть виникнути такі дефекти:
зсув кордону - межа, переміщена вертикально чи горизонтально;
напрямок кордону - кордон, повернутий під неправильним кутом;
пропущений кордон;
зайвий кордон
Докладніше з розбором прикладу див. у Копленда у розділі 8.
Use case-based Testing
Сценарій використання системи (use case): Послідовність операцій у взаємодії актора і компонента або системи зі значним результатом, коли актором може бути як користувач, так і все, що може обмінюватися інформацією з системою. (ISTQB)
До цих пір ми досліджували техніки розробки тестових сценаріїв для частин системи - вхідні змінні з їх діапазонами та межами, бізнес-правила, представлені у вигляді таблиць рішень, а також поведінки системи, що представлені за допомогою діаграм станів та переходів. Тепер настав час розглянути тестові сценарії, які використовують системні функції від початку до кінця шляхом тестування кожної з їх індивідуальних операцій.
Варіант використання (Use Case) – це сценарій, який описує використання системи дійовою особою для досягнення певної мети (Івар Якобсон – "Об'єктно-орієнтована розробка програм: підхід, заснований на варіантах використання").
Чинна особа (або актор) - це користувач, що грає роль з повагою до системи, що намагається використовувати систему для досягнення чогось важливого всередині конкретного контексту. Чинними особами переважно є люди, хоча дійовими особами також можуть виступати інші системи;
"Сценарій" - це послідовність кроків, що описують взаємодії між актором та системою. Зауважте, що варіанти використання визначені з погляду користувача, а чи не системи. Зауважте також, що операції, які виконуються всередині системи, хоч і важливі, але не є частиною визначення варіантів використання. Набір варіантів використання складає функціональні вимоги системи.
Перш ніж використовувати сценарії для створення Test case, їх необхідно описати за допомогою шаблону. Шаблони можуть змінюватись від проекту до проекту. Але серед таких звичайних полів, як ім'я, ціль, попередні умови, актор(и) і т. д., завжди є основний успішний сценарій і так звані розширення (плюс іноді подваріації). Розширення – це умови, що впливають на основний сценарій успіху. А подваріації - це умови, які не впливають на основний flow, але все ж таки мають бути розглянуті. Після того, як шаблон заповнений даними, ми створюємо конкретні Test case, використовуючи методи еквівалентного поділу та граничних значень. Для мінімального охоплення нам потрібен щонайменше один тестовий сценарій для основного сценарію успіху та як мінімум один Test case для кожного розширення. Знову ж, цей метод відповідає загальній формулі «отримайте умови, які змінюють наш результат, та перевірте комбінації». Але спосіб отримати це – проаналізувати поведінку Системи за допомогою сценаріїв.
Користь варіантів використання в тому, що вони:
дозволяють виявити функціональні вимоги системи з погляду користувача попри технічну перспективу і незалежно від цього, яка парадигма розробки використовувалася;
можуть бути використані для активного залучення користувачів у процес збирання вимог та визначень;
надають базис для ідентифікації ключових компонентів системи, структур, баз даних та зв'язків;
служать основою розробки тест-кейсів системи на приймальному рівні.
Докладніше з розбором прикладу див. у Копленда у розділі 8.
Як створити хороші сценарії (Сем Канер):
Напишіть історію життя для об'єктів у системі.
Перерахуйте можливих користувачів, проаналізуйте їхні інтереси та цілі.
Подумайте про негативних користувачів: як вони хочуть зловживати системою?
Перелічіть "системні події". Як система справляється із нею?
Перерахуйте "особливі події". Які пристрої система робить для них?
Перерахуйте переваги та створіть наскрізні завдання, щоб перевірити їх.
Інтерв'ю користувачів про відомі проблеми та збої старої системи.
Працюйте разом із користувачами, щоб побачити, як вони працюють і що вони роблять.
Читайте про те, що повинні робити такі системи.
Вивчіть скарги на попередника цієї системи чи її конкурентів.
Створити фіктивний бізнес. Ставтеся до нього як до реального та обробляйте його дані.
Спробуйте перетворити реальні дані з конкуруючого або попереднього застосування.
Cause/Effect, Cause-Effect (CE)
Таблиця причинно-наслідкових рішень (cause-effect decision table): Див. Таблиця рішень.
Таблиця рішень (decision table): Таблиця, що відображає комбінації вхідних даних та/або причин з відповідними вихідними даними та/або діям (наслідкам), яка може бути використана для проектування тестових сценаріїв. (ISTQB)
Тестові приклади повинні бути розроблені так, щоб виявляти принципи, що характеризують взаємозв'язок між вхідними та вихідними даними компонента, де кожен принцип відповідає єдиній можливій комбінації вхідних даних компонента, які були виражені як логічні значення. Для кожного тестового прикладу слід уточнити:
логічний стан для кожного ефекту;
Логічний стан (істина чи брехня) з будь-якої причини;
Граф причинно-наслідкових зв'язків (Cause-Effect Graph) використовує таку модель логічних взаємозв'язків між причинами та наслідками для компонента. Кожна причина виражається як умова, яка може бути істинною, хибною на вході або комбінацією вхідних даних компонента. Кожен ефект виражається у вигляді логічного виразу, що представляє результати або комбінацію результатів для компонента, що відбувся (? Модель зазвичай представлена як логічний граф, що пов'язує похідні логічні вирази введення та виведення з використанням логічних операторів:
І (AND);
АБО (OR);
НЕ (NOT).
Cause-Effect Graph також відомий як діаграма Ісікави, оскільки він був винайдений Каору Ісікава, або як діаграма риб'ячої кістки через те, як він виглядає.
Граф причинно-наслідкових зв'язків схожий на Decision Table і використовує ідею об'єднання умов. І іноді вони описуються як один метод. Але якщо між умовами існує багато логічних залежностей, можливо простіше їх візуалізувати на cause-effect graph.
Syntax testing
Синтаксичне тестування (syntax testing): Розробка тестів методом чорної скриньки, в якій тестові сценарії будуються на основі області визначення вхідних та/або вихідних значень. (ISTQB)
Як правило, синтаксичні тести автоматизовані, оскільки вони передбачають створення великої кількості кейсів. Синтаксис тестується з використанням двох умов:
Валідні: Перевірка нормального стану з використанням покриваючого набору шляхів синтаксичного графа для мінімально необхідних вимог (? Іншими словами, знаходимо можливі варіанти значень, що допускаються окремими елементами визначення BNF, а потім розробляємо кейси, щоб просто охопити ці варіанти;
Невалідні: Перевірка сміттєвих умов* з використанням неприпустимого набору вхідних даних.
Примітка *: умови для сміття - це метод перевірки стійкості системи до невірних або брудних даних. Умова виконується шляхом надання в систему брудних даних (неприпустимих даних), які не підтримуються вказаним форматом та граматикою синтаксису. Для створення таких даних ми визначаємо та застосовуємо можливі мутації (наприклад, відсутній елемент, небажаний додатковий елемент, неприпустиме значення для елемента тощо) до окремих елементів визначення BNF. Потім ми розробляємо наші кейси, застосовуючи мутації, які можуть давати відмітні результати (випадки, що призводять до дійсних комбінацій, виключаються).
Check List Based Testing
Тестування на основі контрольного списку (чекліста) виконується за допомогою попередньо підготовленого досвідченими тестувальниками чекліста, який продовжує оновлюватися з урахуванням будь-яких нових дефектів, виявлених під час виконання контрольних прикладів контрольного списку. За будь-яких змін у продукті проганяється швидкий чекліст, щоб переконатися, що через зміни не виникло нових дефектів. Цей контрольний список не має відношення до історій користувача.
User Journey Test
User Journey test, як випливає з назви, охоплює повну подорож користувача системою. Він охоплює наскрізні тести, через які відсоток покриття тестами більший у порівнянні з іншими методами. Цей метод допомагає зменшити кількість тестових прикладів, оскільки тестові приклади є вичерпними та охоплюють більшу частину функціональності в одному сценарії. Сценарії написані для найскладнішої подорожі. Тести взаємодії з користувачем не пов'язані з історіями користувача (user stories).
User Story Testing (Agile)
Користувацька історія - це короткий та простий опис вимог клієнтів або кінцевого користувача. Історії користувача написані власником продукту (Product owner), оскільки саме він отримує від клієнта інформацію про продукт, який буде створений. Якщо користувальницька історія велика, вона розбивається на кілька дрібніших історій. Історії користувачів записуються на облікових картках та вивішуються на стіні для обговорення. Обговорюючи важливі аспекти функції, виберіть ті, які надалі використовуються в історії користувача. Приймальні випробування - це заключний етап, у якому продукт приймає замовник по тому, як він відповідає всім критеріям виходу. Критерії прийнятності визначаються власником продукту, замовник на постачання також може залучати розробників, визначаючи те саме.
Exhaustive testing
Вичерпне тестування (exhaustive testing): Методика тестування, в якій набір тестів включає всі комбінації вхідних даних і передумов. (ISTQB)
Вичерпне тестування (Exhaustive testing – ET) – це крайній випадок. У межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і в принципі це має знайти всі проблеми. Насправді застосування цього методу майже завжди неможливо, через величезної кількості вхідних значень.
Джерела:
Лі Копланд - “A Practitioner's Guide to Software Test Design”, Глави 3-9
Дод. матеріал:
Last updated