2.7.Тестування та налагодження додатків

Тестування додатка варто розглядати як окремий етап його розробки, якому в загальному графіку виконання робіт повинна бути приділена першорядна увага. При використанні програмних планувальників проекту типу Microsoft Project його потрібно включати в завдання в статусі окремої задачі. Існує безліч методик планування цього етапу. Деякі розроблювачі воліють приступати до тестування тільки після того, як весь програмний код додатка буде написаний. Але для середовища Visual FoxPro, з огляду на його інтерактивну природу, набагато продуктивніше використовувати стратегію паралельного тестування підзадач і компонентів додатку. Але тоді на плечі менеджера проекту лягає інша турбота: як відстежити час, що затрачується на таке паралельне тестування. У цьому розділі ви познайомитеся з різними методиками тестування і спробами проаналізувати за і проти кожної.

Чому віддати перевагу — даним чи логіці?

Тестування програмного продукту переслідує дві мети: перевірку достовірності результатів і перевірку правильності функціонування всіх компонентів програми. Перевірка достовірності результатів (тест достовірності – validity testing) дозволяє судити про те, чи формуються в процесі виконання додатка очікувані результати при заданому наборі вхідних даних. Перевірка правильності функціонування всіх компонентів програми (її часто називають тестом покриття – coverage testing) дозволяє судити про те, чи всі гілки програми функціонують правильно і чи не залишилося в ній “мін уповільненої дії”⁹. Про тест покриття мова йтиме пізніше, а зараз розглянемо докладніше методику тестування достовірності.

Існує два підходи до тестування достовірності. Перший — пріоритет у виконанні тестування віддається даним у вхідному наборі (його ще для стислості називають data - driven — відомий даними). Суть його полягає в тому, що за допомогою великої кількості варіантів набору вхідних даних (випадкових чи підготовлених заздалегідь) перевіряється достовірність результатів — чи відповідають вони очікуваним. При цьому можна не дуже поглиблюватися в особливості технології обробки цих даних у програмі що тестується.

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

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

Методика, відома логікою, дозволяє перебороти зазначений недолік. Правильно організоване тестування за цією методикою змушує “спрацювати” кожен оператор у програмі. Звичайно, таке тестування вимагає вдумливої підготовки наборів вхідних даних і займає досить багато часу (вважаючи і підготовку, і власне тестування).