С.Трофімов
Ніхто не сумнівається в необхідності тестування програм. Будь то невеликий навчальний приклад або ціла інформаційна система. Питання тільки в тому, скільки потрібно тестувати і коли можна вважати програму протестованої?
Людям властиво помилятися при будь-якому виді діяльності, у тому числі і при створенні програм. Звичайно, ці помилки ненавмисні і людина врешті-решт їх виправить, але як кажуть, програм без помилок не буває, і на деякому етапі тестування виникає питання, чи варто далі шукати помилки або змиритися з їх деякою кількістю до пори до часу. Це питання підводить нас до визначення критеріїв, за якими можна судити, що програма більш-менш працездатна.
Відомо, що можна написати програму з одного оператора без єдиної помилки. Здавалося б до одного безпомилкового оператору можна додати ще один, а потім ще один, на перший погляд, безпомилковий, проте, людям властиво помилятися ... і результат виходить не той, якого очікували.
Помилки бувають різні і час на їх пошук буде різна. Від простих описок, які знаходяться в перший же запуск програми, до неявних помилок алгоритму або неправильного використання мовних конструкцій, на пошук яких можна витратити не тільки години, а дні. Останні знайти особливо важко.
Сучасні мови програмування - це надзвичайно складний інструмент, на освоєння якого йдуть роки копіткої праці. Іноді помилки в документації, а частіше просто недостатнє розуміння роботи тієї або іншої конструкції мови або призначення бібліотеки, веде до неправильної роботи програми.
Програміст дивиться в код і не розуміє, чому він працює не так, як задумано. У таких випадках говорять "уперся" і звуть сусіда на допомогу. У цьому випадку "Свіжий" погляд може значно прискорити пошук помилки.
Скоротити кількість помилок можна кількома шляхами:
застосувати спеціальні методи і засоби написання програм, наприклад, CASE-засоби Rational Rose;
-->> застосувати надійні, багаторазово протестовані компоненти і бібліотеки;
суворо дотримуватися і головне контролювати відповідність створюваних програм проектної документації.
Ще одним, досить ефективним, але трудомістким методом скорочення помилок (я говорю саме про скорочення, а не повне усунення) буде тестування. Зазвичай ресурсів (читай часу) для повного тестування не вистачає. Тому повне тестування з перевіркою системи у всіх режимах і з усіма параметрами важко реалізовується.
Однією з основних особливостей тестування є відсутність еталона програми, з яким можна було б порівняти щось вже створене. З цього витікає трудність визначення моменту, коли необхідна якість програми досягнуто.
Основним еталоном в цьому випадку буде проектна документація, яка призводить різницю поглядів різних людей на якість програми до одного знаменника. При відсутності такої документації, я вважаю, що в принципі неможливо протестувати програму, оскільки погляд на обсяг і якість виконуваних функцій не збігається не тільки у різних людей, але й може розрізнятися в одного людини в різні проміжки часу.
Тому важливо визначити кілька рівнів досягнення необхідної якості програм:
відсутність синтаксичних помилок і аварійних зупинок в програмі, що досягається прогоном програми з різними даними по максимальному числу гілок. Для визначення ділянок, які жодного разу не були запущені при прогоні програми, існують спеціальні засоби, наприклад Rational Pure Coverage. З практики роботи я можу зробити висновок, що ділянка коду, який жодного разу не був запущений при тестуванні, приблизно в 80% випадків непрацездатний;
виконувані функції програм відповідають технічній документації;
розрахункові значення, отримані за допомогою процедур розрахунку, відповідають еталонним.
Часто перші два рівня можна тестувати одночасно, вносячи корективи в супровідну документацію. Останній пункт найтриваліший і важко тестований, неможливо підготувати тест на всі можливі поєднання даних, тому існує так зване бета-тестування, тобто тестування самими користувачами.
Тепер, коли деякі критерії тестування були тут згадані, можна відповісти на питання, винесене в заголовок статті.
Перший етап тестування можна припиняти, коли є впевненість, що більша частина синтаксичних помилок і аварійний остановов усунена. Решта поступово будуть усуватися в процесі інших етапів тестування.
Другий етап тестування можна припиняти, коли велика частина функціональності перевірена і працює у відповідності з проектною документацією. Решта невідповідності будуть усуватися в процесі написання супровідної документації.
І нарешті, третій етап тестування можна припиняти, коли основні розрахункові тести дають правильні результати.
Тестування користувачами триватиме на всьому етапі життєвого циклу програмного забезпечення, і аж до зміни ПО на більш сучасне, користувачі будуть знаходити в ньому неточності і помилки, до яких, врешті-решт, вони звикнуть і почнуть сприймати їх як само собою зрозуміле, поки програмісти не видадуть "нагора" нову версію, в якій "виправлені старі помилки і додані нові "і все почнеться спочатку.
Список літератури
Для підготовки даної роботи були використані матеріали з сайту progcpp.narod.ru/doc/prog.htm
