2.7.1.Технологія тестування

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

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

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

Група формальної інспекції проекту аналізує критичні компоненти проекту і намагається з'ясувати, чи всі можливі ситуації враховані в них. Для того щоб забезпечити “покриття” усіх припустимих варіантів функціонування системи, часто використовуються діаграми дерева аналізу рішень (decision-tree analysis). Формальний апарат такого аналізу дозволяє графічно відобразити послідовність виконання операцій в основних компонентах, причому в результаті розгалуження ходу виконання графічна схема дуже нагадує малюнок розкидистого дерева.

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

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

• Формальна перевірка коду включає його перегляд і аналіз на предмет відповідності стандартам оформлення: наявність коментарів, вибір імен перемінних, визначення зони видимості перемінних і т. п.

• Моделювання, або робота з прототипами, включає використання різноманітних інструментальних засобів, що дозволяють швидко створити середовище для роботи додатка. Ціль цієї процедури — перевірити загалом функціональні можливості продукту. Стосовно до Visual FoxPro це включає створення основних екранних форм і звітів, зв'язаних один з одним за допомогою простих меню. Хоча такі форми і виглядають як повнофункціональні, вони не включають безлічі засобів обробки для реалізації всього набору функцій. Точно так само і звіти можуть не включати засобів сортування чи вибіркової обробки. За цією технологією зараз закріпився термін RAD — Rapid Application Development (розробка додатків на швидку руку).

• Перевірка синтаксису має на меті проаналізувати коректність програмного коду, його відповідність формальним правилам мови програмування. Хоча велику частину турбот по перевірці синтаксису бере на себе компілятор Visual FoxPro, деякі синтаксичні помилки виявляються тільки в процесі виконання коду.

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

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

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

• Функціональне тестування перевіряє правильність реалізації задуманої логіки поводження програми. Наприклад, при виборі в меню опції формування звіту повинний формуватися саме звіт, а не що-небудь інше. Якщо у формі виведене повідомлення, що натискання F2 відкриває деякий список, те потрібно перевірити, чи дійсно форма реагує на клавішу <F2> саме в такий спосіб. На цій стадії ще не перевіряється, які саме дані виведені в звіті чи що виявилося у відкритому списку.

• Перевірка обмежень за даними має на меті з'ясувати реакцію програми на уведення вхідних даних за межами обговореного діапазону. Іноді подібну перевірку називають стрес-тестом (stress testing), оскільки при цьому програми штучно “заганяються” у стресовий стан. Наприклад, якщо ви маєте справу з екранною формою нарахування оплати за місяць, цікаво з'ясувати, як програма буде реагувати на введення кількості робочих годин, скажемо, -170. Стрес-тест мережного додатка також повинний дати інформацію про те, як воно буде реагувати на спробу великого числа користувачів одночасно звернутися до тих чи інших функцій. Що відбудеться, якщо декілька користувачів одночасно спробують змінити дані в одній і тій же таблиці? Чи правильно блокуються записи і файли і якою мірою забезпечується мінімізація часу чекання інших користувачів при цьому? Відповіді на всі ці питання також повинний дати стрес-тест.

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

• І нарешті, тест сумісності перевіряє, як поводиться програма в різному робочому середовищі. У поняття робочого середовища входять і розмаїтість апаратури — моделі моніторів, принтерів, і розмаїтість організації програмного оточення. Не можна залишати без уваги й особливості регіонального настроювання операційної системи — способи відображення часу, дат і грошових сум. Те ж саме стосується й особливостей сортування з урахуванням національних алфавітів. Звичайно, чим більше уваги ви приділите цим “дріб'язкам”, тим більшою популярністю буде користатися створений програмний продукт у світовому масштабі.

Коли завершувати тестування? На перший погляд, відповідь на це питання тривіальна: програму треба тестувати усе її “свідоме” життя, тобто увесь час, поки вона використовується. У процесі експлуатації постійно з'являються нові комбінації вихідних даних. Згодом програма модифікується (часом не в кращу сторону), у неї додаються нові функції і поля введення даних. А включення кожного нового фрагмента коду вже таїть у собі небезпеку появи помилок. Можуть змінитися шляху доступу до файлів, нові перемінні можуть конфліктувати із вже існуючими, можуть проявитися побічні ефекти в результаті інтерференції з існуючим кодом. Тому при включенні кожного нового фрагмента коду приходиться в більшому чи меншому ступені повторювати процес тестування. У такому випадку говорять про регресійне тестування.

Деякі розроблювачі використовують для оцінки якості тестування так називаний фактор частоти помилок (bag rate factor). Це не що інше, як кількість помилок, знайдених за визначений відрізок часу, скажемо, за робочий день. Вважається, що якщо цей показник знижується до визначеного рівня, то цілеспрямоване тестування можна припиняти. Але є й інші підходи. Деякі керівники проектів порівнюють вартість продовження пошуку помилок з вартістю потенційних утрат, що може принести не виявлена вчасно помилка. Наприклад, якщо не помітили орфографічної помилки в якому-небудь написі в екранній формі, то втрати користувача від її навряд чи будуть великі (якщо тільки це не помилка в інструкції з використання боєголовки — уключити замість виключити). Але помилка, що приводить до вирахування суми податку з вартості продаваної продукції замість підсумовування, обійдеться користувачу трохи дорожче. Інший варіант помилки такого ж ступеня ваги — невірний пошук ціни виробу по його коду. З усього сказаного випливає очевидний висновок: планувати витрати часу на тестування випливає з урахуванням важливості компонента в додатку.

Але незалежно від застосовуваного методу оцінки якості тестування одне можна сказати з упевненістю: усі помилки в мало-мальськи серйозному додатку винищити неможливо. Тестування ж варто продовжувати доти, поки в кожного учасника команди не з'явиться почуття впевненості в працездатності додатка.