Термінологія та визначення

Чому важлива термінологія? Тому що вона створює спільну мову між членами команди, які займаються розробкою програмного забезпечення. Термінологія — це стислі «ярлики» для цілих концепцій. Якщо кожного разу замість «інкапсуляції» пояснювати «приховування деталей реалізації та надання лише інтерфейсу», знання будуть передаватися в три рази довше і з трьома шансами на викривлення. Щоб запобігти викривленню передачі знань ми надаємо базову термінологію та визначення, які ми використовуємо у цьому курсі.

Загальні терміни тестування

Більшість з нас створює програмне забезпечення, щоб воно було корисним для інших людей. Користь визначає кожна людина для себе окремо, але існує загальне визначення того, що таке якісна програма.

Якість програмного забезпечення (software quality) — ступінь, у якій система, компонент або процес задовольняють потреби чи очікування замовника або користувача [IEEE Std 610.12-1990]. У цьому визначенні вводяться такі поняття:

• обʼєкт тестування — система, компонент або процес;
• вимоги — потреби чи очікування;
• зацікавлені сторони — замовники та користувачі.

Щоб дізнатись, а чи якісна програма перед нами — треба мати вимоги до цієї програми та протестувати її відносно цих вимог. Таким чином, тестування (testing) — визначення ступеня задоволення реалізацією системи вимог шляхом експериментів із цією системою. Тут дуже важливе уточнення, що робиться це шляхом експериментів. Наприклад, ревʼю кода (code review) — це не тестування. Без експериментів (тестування) визначити якість програми неможливо.

Обʼєкт тестування (іноді використовуються терміни unit under test (UUT), application under test (AUT), system under test (SUT)) — це система, підсистема, застосунок, компонент чи окремий модуль програмного забезпечення, до якого застосовується процес тестування з метою перевірки його відповідності вимогам і очікуванням зацікавлених сторін.

В контексті модульного тестування обʼєкт — це найменший ізольований фрагмент програмного забезпечення, який можна протестувати автономно. Зазвичай це:

• окрема функція;
• метод класу;
• невеликий клас або компонент, що має чітко визначений інтерфейс і поведінку.

Предмет тестування — це конкретна властивість, характеристика, функціональність або аспект обʼєкта тестування, які підлягають перевірці у процесі тестування.

Приклади предметів тестування: 

• Функціональність: перевірка, що кнопка «Зберегти» створює новий запис у базі.
• Нефункціональні характеристики: швидкодія, безпека, зручність інтерфейсу.
• Процеси: коректність міграції даних між системами.
• Сумісність: робота застосунку в різних браузерах чи ОС.

Тестування складається з елементарних перевірок обʼєкта — дія, яка характеризується поданим на обʼєкт тестовим або робочим впливом і зафіксованою з обʼєкта відповіддю.

Приклади елементарних перевірок: 

• ми вводимо значення у формули, натискаємо «Розрахувати» та перевіряємо результат розрахунку;
• ми створюємо користувача в системі та перевіряємо, чи він зʼявився в базі даних;
• ми надсилаємо повідомлення іншому користувачу та перевіряємо, що він отримав це повідомлення та воно не спотворене.

Іноді однієї елементарної перевірки недостатньо, щоб переконатися що програма працює вірно. Наприклад, щоб протестувати функцію входу в систему потрібно як мінімум три елементарні перевірки:

• логін з неправильним паролем: очікуємо повідомлення про помилку;
• логін із правильним паролем: очікуємо доступ;
• спроба входу з пустим полем: очікуємо повідомлення про обовʼязковість.

Якщо результат будь-якої елементарної перевірки нас не влаштовує, то ми кажемо, що це програмна помилка (software error, software fault, software bug) — некоректна поведінка системи, що спостерігається на межі цієї системи: інтерфейсі користувача, програмному інтерфейсі, у створених файлах, або у записах в базу даних.

Приклади програмних помилок:

• після натискання кнопки застосунок закрився (крешнувся);
• після збереження документа на жорсткий диск у нього зникла остання сторінка;
• після видалення товару з кошика в інтернет-магазині він там залишається після перезавантаження сторінки;
• неправильний розрахунок заробітної платні;
• після створення користувача в базі даних не зберігається його прізвище.

Програмні помилки не зʼявляються самі по собі. Частіше усього, є людина яка написала код, який призводить до програмної помилки.

Людська помилка (human error, human fault) — дія людини, внаслідок якої створено документацію або програмне забезпечення з помилкою.

Приклади людських помилок:

• бізнес-аналітик не записав важливу вимогу в специфікацію на розробку продукту;
• програміст переплутав порядок аргументів у виклику функції;
• програміст видалив функцію збереження даних у файл;
• програміст переплутав порядок аріфметичних операцій у формулі розрахунку.

Треба вміти відрізняти програмні помилки від людських помилок. Якщо ви бачите спотворені дані на екрані, то ще треба зрозуміти — це програмна помилка (дані спотворені кодом), чи дія людини, яка помилково спотворила дані руками.

Дефект, несправність (defect, fault) — конкретне місце в коді, яке призводить до помилки.

Приклади дефектів: 

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

Активація дефекта — це умова або сукупність умов виконання програми, за яких дефект (несправність) починає проявлятися у вигляді програмної помилки на межі системи.

Не кожен дефект активний завжди. Дефект може «сидіти» у коді роками, але поки не виконалися певні умови (наприклад, значення параметра = 0), він не проявляється.

Активація залежить від вхідних даних і середовища:

• Тестові дані (наприклад, користувач ввів пустий рядок у форму).
• Конфігурація системи (браузер, ОС, версія бібліотеки).
• Послідовність дій (натиснув спочатку «Зберегти», потім «Видалити»).

Навіть після активації дефекту потрібно, щоб його наслідки стали видимими на інтерфейсі (програмна помилка, збій, відмова). Якщо система «проковтнула» дефект, користувач його не побачить.

Відношення між термінами «програмна помилка», «людська помилка», «дефект» та «активація» можна показати на такому прикладі:

Програміст припустився помилки під час програмування. У результаті в програмі зʼявився дефект (несправність). Через дефект у програмі кінцевий користувач спостерігає програмні помилки на межах системи (інтерфейс користувача, вихідні файли). Дефект (несправність) проявляє себе на межах системи лише за певних умов (активація). Кінцевий користувач не може безпосередньо спостерігати дефект (несправність), адже для цього потрібно мати вихідний код, щоб знайти конкретне місце дефекту.

Приклади:

Термінологія модульного тестування

Тестова фікстура (test fixture), або просто фікстура — функція, яка виконує підготовку, необхідну для виконання одного чи кількох тестів (іноді це називають set up), а також будь-які повʼязані дії з очищення (tear down). Приклади підготовки: створити тимчасову базу даних, відкрити файл, підняти HTTP-сервер. Приклади очищення: закрити файл, видалити тимчасову базу даних, завершити серверний процес.

Тестовий випадок (test case), іноді називають просто тестом — це індивідуальна одиниця тестування. Він перевіряє конкретну відповідь на певний набір вхідних даних.

Тестовий набір (test suite) — колекція тестових випадків, тестових наборів або їх комбінації. Він використовується для агрегування тестів, які слід виконувати разом. Тести обʼєднуються за рівнями тестування, функціональністью, технічними аспектами, контекстом запуску тощо. Наприклад:

• Unit test suite — набір модульних тестів для перевірки окремих функцій або класів.
• Shopping cart suite — тести додавання товару в кошик, видалення, оновлення кількості, розрахунок загальної суми.
• Security suite — перевірка автентифікації, авторизації, захисту від SQL-інʼєкцій, XSS.
• Smoke test suite — базові тести, що перевіряють, чи взагалі система запускається й виконує критичні функції.

Тестовий раннер (test runner, дослівно «запускач тестів») — це компонент, який виконує пошук тестів у проєкті, керує виконанням тестів і надає результати у вигляді звіту. Раннер може використовувати графічний інтерфейс, текстовий інтерфейс або повертати спеціальне значення, щоб вказати результати виконання тестів.

Асерція (assertion) — твердження, яке є істинним або хибним.

Наприклад:

• асерція на початку методу перевіряє, що всі параметри методу належать області визначення (самотестування);
• асерція в кінці функції перевіряє, що значення, яке повертається, належить області значень функції (самотестування);
• асерція в тесті перевіряє що фактичний результат перевірки відповідає очікуванному результату.

Дуже важливо зрозуміти, що сам по собі тест не може визначити, яка поведінка системи правильна, а яка помилкова. Треба записати асерцію у вигляді умови. Тестовий раннер аналізує результати перевірки асерцій та формує звіт, де вказує, які тести пройшли, а які ні. Видсутність асерцій в коді тесту — це одна з ознак низькоякісного тесту.

Arrange-Act-Assert (AAA) — це структурований підхід до написання тестів, що розділяє тест на три чіткі етапи: 

• arrange, підготовка середовища — ініціалізуються обʼєкти, задаються початкові дані, конфігурується система тощо. У цьому допомагають фікстури;
• act, виконання дії з обʼєктом тестування — Безпосереднє виконання дії, яку ми тестуємо: виклик методу чи функції, запуск процесу, виконання користувацької операції;
• assert, перевірка результату — застосовуються твердження (асерції), порівнюється фактичний результат із очікуваним, визначається, чи тест успішний.