Тестування на етапі кодування

На цьому етапі застосовується так звана технологія тестування «білої скриньки» - white box, glass box. При тестуванні чорної скриньки програма розглядається як обєкт, внутрішня структура якої невідома. Тестувальник вводить дані, аналізує результат, але як працює програма він не знає. При тестуванні “білої скриньки» ситуація інша. Тестувальник (як правило це програміст) розробляє тести, спираючись на знанні вихідного коду, до якого він має повний доступ. В результаті він отримує наступні переваги:

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

Повне охоплення коду. Програміст завжди може визначити, які саме фрагменти коду працюють в кожному тесті. Він може підібрати умови, при яких всі гілки коду будуть протестовані.

Управління потоком. Програміст може включити у програму команди відлагодження. Або користуватися спеціальним програмним засобом – відлагоджувачем. Вілагоджувач може відслідковувати і міняти послідовність виконання команд програми, показувати вміст змінних величин, їх адреси в памяті тощо.

Відслідковування цілісності даних. Можна виявити такі помилки, як змінення даних не тими модулями, їх невірна інтерпретація або невдала організація.

Внутрішні граничні точки. Наприклад, проблема переповнення буфера.

Тестування на етапів тестування

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

Основною роботою тестувальників є так зване регресійне тестування. У цього терміна два значення, об'єднаних ідеєю повторного виконання розроблених тестів.

Уявіть, що ви провели тест, виявили помилку і програміст її виправив. Ви знову проводите той же тест, щоб переконатися, що помилки більше немає. Це і є регресійне тестування. Можна провести кілька варіацій вихідного тесту, щоб як слід перевірити виправлений фрагмент програми. В даному випадку завдання регресійного тестування полягає в тому, щоб переконатися, що виявлена помилка повністю виправлена програмістом і більше не проявляється.

У деяких колективах в набір регресійних тестів включають кожну знайдену помилку, навіть якщо вона виправлена вже давним-давно. Кожного разу, коли в програму вноситься змінення, всі ці тести проводяться знову. Особливо важливо провести таке грунтовне тестування, якщо програма змінюється через досить тривалий час або новим програмістом. Виправлення дуже чутливі до таких змін, оскільки в тексті програми вони виглядають як незрозумілі або невдалі фрагменти.

Другий приклад застосування регресійного тестування. Після виявлення і виправлення помилки проводиться стандартна серія тестів, але вже з іншою метою: переконатися, що виправляючи одну частину програми, програміст не зіпсував іншу. У цьому випадку тестується цілісність усієї програми, а не виправлення однієї помилки.