Глосарій лекції №5 «Тест-дизайн. Тест-кейси» з курсу «Основи тестування ПЗ»

Граничні значення (Border Condition, Boundary Condition, Boundary Value) – вхідні чи вихідні значення, які знаходяться на межі еквівалентної області або на найменшій відстані від обох сторін межі, наприклад, мінімальне і максимальне значення області.

Еквівалентна область (Equivalence class) – частина області вхідних або вихідних даних, для якої поведінка компонента або системи, ґрунтуючись на специфікації, вважається однаковою.

Негативний тест-кейс (Negative Test Case) – оперує як валідними так і невалідними даними (мінімум 1 невалідний параметр) та ставить за мету перевірку виняткових випадків (спрацьовування валідаторів), а також перевіряє, що викликана додатком функція не виконується при спрацьовуванні валідатора.

(Див. також негативний сценарій)

Позитивний тест-кейс (Positive Test Case) – використовує тільки валідні дані та перевіряє, що додаток правильно виконав функцію, що викликається.

(Див. також позитивний сценарій)

Покриття вимог (Requirements Coverage) – оцінка покриття тестами функціональних і нефункціональних вимог до продукту шляхом побудови матриць трасування (traceability matrix).

Покриття коду (Code Coverage) – оцінка покриття виконуваного коду тестами, шляхом відстеження неперевірених в процесі тестування частин програмного забезпечення.

Тест-дизайн (Test Design) – це етап процесу тестування ПЗ, на якому проєктуються та створюються тест-кейси, відповідно до визначених раніше критеріїв якості та задач тестування.

Тест-кейс (Test Case) – це сукупність кроків, конкретних умов та параметрів, необхідних для перевірки реалізації тестованої функції або її частини.

(Див. також тестовий випадок, тестовий сценарій)

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

(Див. також набір тест-кейсів)

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

Тестовий сценарій низького рівня (Low Level Test Case) – тестовий сценарій з конкретними значеннями вхідних даних та очікуваних результатів.

(Див. також тест-кейс низького рівня)

Тестовий сценарій високого рівня (High Level Test Case) – тестовий сценарій без конкретних значень вхідних даних та очікуваних результатів. Використовує логічні оператори, екземпляри реальних значень, які ще не визначені або недоступні.

(Див. також тест-кейс високого рівня)

Аналіз граничних значень (Boundary Value Analysis) – це техніка перевірки поведінки продукту на крайніх (граничних) значеннях вхідних даних. Граничне тестування також може включати тести, що перевіряють поведінку системи на вхідних даних, що виходять за допустимий діапазон значень. При цьому система повинна певним (заздалегідь обумовленим) способом обробляти такі ситуації. Наприклад, за допомогою виняткової ситуації або повідомлення про помилку.

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

Еквівалентний розподіл (Equivalence Partitioning) – це техніка, яка полягає в розбитті всього набору тестів на класи еквівалентності з подальшим скороченням числа тестів.

(Див. також еквівалентне розбиття)

Передбачення помилки (Error Guessing). Це коли тест аналітик використовує свої знання системи і здатність до інтерпретації специфікації на предмет того, щоб «вгадати», за яких вхідних умов система може видати помилку. Наприклад, специфікація каже: «користувач повинен ввести код». Тест аналітик буде думати: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код?» І так далі. Це і є передбачення помилки.

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

(Див. також техніка попарного перебору, метод всіх пар)

Причина/Наслідок (Cause/Effect) – це, як правило, введення комбінацій умов (причин) для отримання відповіді від системи (наслідок). Наприклад, натискання кнопки «Додати» для відправки форми додавання клієнта – це «Причина». Після натискання кнопки «Додати», система додає клієнта в базу даних і показує його номер на екрані – це «Наслідок».

Таблиця прийняття рішень (Decision Table) – це інструмент для упорядкування складних бізнес вимог, які повинні бути реалізовані в продукті. У таблицях рішень представлений набір умов, одночасне виконання яких повинно привести до певної дії.