У строгому сенсі не справедливо пред'являти будь-які претензії, поки не буде встановлено якість тестового набору. Здавання 100% тестів не має сенсу, якщо більшість тестів є тривіальними або повторюваними між собою.
Питання: Чи в історії проекту хтось із цих тестів виявляв помилки? Мета тесту - знайти помилок. І якщо вони цього не зробили, вони провалилися як тести. Замість поліпшення якості коду вони можуть створювати лише помилкове почуття безпеки.
Для вдосконалення тестових конструкцій ви можете використовувати (1) техніку білого поля, (2) техніку blackbox та (3) тестування на мутацію.
(1) Ось кілька хороших методик білого поля, які слід застосувати до ваших тестових конструкцій. Тест білої коробки побудований з урахуванням конкретного вихідного коду. Одним з важливих аспектів тестування білої скриньки є покриття коду:
- Чи називається кожна функція? [Функціональне покриття]
- Чи виконується кожна заява? [Покриття заяви - І функціональне покриття, і висвітлення заяви дуже важливі, але краще, ніж нічого]
- Чи маєте ви кожне рішення (наприклад,
ifчи while) тест, який змушує його бути правдивим, та інше, яке змушує його бути помилковим? [Покриття рішення]
- Для кожної умови, яка є сполучником (використовує
&&) або диз'юнкцією (використовує ||), чи має кожна субэкспрессия тест там, де це правда / хибність? [Стан покриття]
- Покриття циклу: чи є у вас тест, який змушує 0 ітерацій, 1 ітерації, 2 ітерацій?
- Чи кожен
breakз петлі покритий?
(2) Технології Blackbox використовуються, коли вимоги є, але сам код - ні. Це може призвести до високоякісних тестів:
- Чи охоплюють ваші тести на чорному блоці кілька цілей тестування? Ви хочете, щоб ваші тести були «жирними»: вони не лише перевіряють функцію X, але й перевіряють Y і Z. Взаємодія різних функцій - це прекрасний спосіб знайти помилки.
- Єдиний випадок, коли ви не хочете "жирових" тестів, це тестування стану помилок. Наприклад, тестування недійсного введення користувача. Якщо ви намагалися досягти декількох недійсних цілей тестування введення (наприклад, недійсний поштовий індекс та недійсна адреса вулиці), ймовірно, один випадок маскує інший.
- Розглянемо типи введення та сформуємо "клас еквівалентності" для типів входів. Наприклад, якщо ваш код перевіряє, чи є трикутник рівностороннім, тест, який використовує трикутник зі сторонами (1, 1, 1), ймовірно, знайде ті самі види помилок, що і дані тесту (2, 2, 2) та (3, 3, 3) знайдемо. Краще витратити свій час на роздуми про інші класи введення. Наприклад, якщо ваша програма обробляє податки, вам потрібно перевірити кожну податкову категорію. [Це називається розділенням еквівалентності.]
- Особливі випадки часто пов’язані з дефектами. Ваші тестові дані також повинні мати граничні значення, такі як ті, що знаходяться над, над або під ребрами завдання еквівалентності. Наприклад, тестуючи алгоритм сортування, вам потрібно буде протестувати порожній масив, масив з одним елементом, масив з двома елементами, а потім дуже великий масив. Ви повинні розглядати крайові випадки не лише для введення даних, але і для виводу. [Це аналіз граничного значення виклику.]
- Ще одна методика - "помилка вгадування". У вас є почуття, якщо ви спробуєте якусь особливу комбінацію, яку ви можете змусити програму розбити? Тоді просто спробуйте! Пам'ятайте: Ваша мета - знайти помилки, а не підтвердити, що програма дійсна . Деякі люди вміють вгадувати помилки.
(3) Нарешті, припустимо, у вас вже є багато приємних тестів на покриття білої скриньки та застосованих методик blackbox. Що ще можна зробити? Пора перевірити свої тести . Один з методів, яким ви можете скористатися, є тест на мутацію.
Під час тестування на мутацію ви вносите модифікацію (копію) своєї програми в надії створити помилку. Мутація може бути:
Змінити посилання однієї змінної на іншу змінну; Вставте функцію abs (); Змінити менше, ніж на більше; Видалити заяву; Замініть змінну постійною; Видалити переорієнтовний метод; Видалити посилання на супер-метод; Змінити порядок аргументів
Створіть кілька десятків мутантів у різних місцях вашої програми [програму все одно потрібно буде скласти для тестування]. Якщо у ваших тестах не виявлено цих помилок, вам тепер потрібно написати тест, який зможе знайти помилку у мутованій версії вашої програми. Як тільки тест знайде помилку, ви вбили мутанта і можете спробувати іншого.
Додаток : Я забув згадати такий ефект: Клопи мають тенденцію до скупчення . Це означає, що чим більше помилок ви знайдете в одному модулі, тим вище ймовірність того, що ви знайдете більше помилок. Отже, якщо у вас є тест, який не вдається (що означає, тест виявився успішним, оскільки мета - знайти помилки), ви не тільки повинні виправити помилку, але і ви повинні написати більше тестів для модуля, використовуючи прийоми вище.
Поки ви виявляєте помилок з постійною швидкістю, тестування потрібно продовжувати. Тільки коли спостерігається зниження кількості нових помилок, ви повинні бути впевнені, що ви доклали зусиль для тестування на цій фазі розвитку.