Атестація програмних систем
Атестація ПЗ, або більш узагальнено ‒ верифікація і атестація, призначено показати відповідність системи її специфікації, а також очікуванням і вимогам замовника і користувачів. До процесу атестації також можна віднести елементи контролю, такі як інспекція і оцінювання, які виконуються на кожному етапі створення ПЗ ‒ від формування загальних вимог до кодування програм. Але все-таки основні дії по атестації виконуються після завершення реалізації на етапі тестування закінченої системи.
За винятком невеликих програм, програмні системи неможливо протестувати як єдиний цільний програмний елемент. Великі системи будуються на основі підсистем, які, у свою чергу, будуються з модулів, модулі ж компонуються із програм-процедур і програм-функцій. Для таких систем процес тестування виконується поступово, у міру реалізації системи.
Рис. 1.11. Процес тестування
На рис. 1.11 показаний п'ятиетапний процес тестування, де спочатку тестуються окремі програмні компоненти і підсистеми, потім зібрана система і нарешті система з даними, наданими замовником. В ідеалі помилки в програмних компонентах повинні виявлятися і виправлятися ще в процесі їх кодування, а помилки і недогляду в інтерфейсах ‒ під час складання системи. Але, оскільки після виявлення будь-яких програмних помилок необхідно виконати налагодження програми, це приводить до необхідності повторення деяких етапів тестування. Наприклад, якщо програмна помилка виявилася на етапі складання системи, необхідно повторити процес тестування того програмного компонента, у якому виявлена ця помилка. Тому процес тестування ітераційний, зі зворотною передачею інформації з наступних етапів на попередні.
Процес тестування складається з декількох етапів.
Тестування компонентів. Тестуються окремі компоненти для перевірки правильності їх функціонування. Кожний компонент тестується незалежно від інших.
Тестування модулів. Програмний модуль ‒ це сукупність залежних компонентів, таких як опис класу об'єктів, декларування абстрактних типів даних і набір процедур і функцій. Кожний модуль тестується незалежно від інших системних модулів.
Тестування підсистем. Тестуються набори модулів, які складають окремі підсистеми. Основна проблема, яка часто проявляється на цьому етапі ‒ непогодженість модульних інтерфейсів. Тому при тестуванні підсистем основна увага приділяється виявленню помилок у модульних інтерфейсах шляхом прогону їх через усі можливі режими.
Тестування системи. З підсистем збирається кінцева система. На цьому етапі основна увага приділяється сумісності інтерфейсів підсистем і виявленню програмних помилок, які проявляються у вигляді непередбаченої взаємодії між підсистемами. Тут також проводиться атестація системи, тобто перевіряється відповідність системної специфікації її функціональних і нефункціональних показників, а також оцінюються інтеграційні характеристики системи.
Приймальні випробування. Це кінцевий етап процесу тестування, після якого система приймається до експлуатації. Тут система тестується із залученням даних, що надаються замовником системи, а не на основі тестових даних, як було на попередньому етапі. На цьому етапі можуть виявитися помилки, допущені ще на етапі визначення системних вимог, оскільки випробування з реальними даними можуть дати інший результат, чим тестування зі спеціально підібраними тестовими даними. Приймальні випробування можуть також виявити інші проблеми в системних вимогах, якщо реальні системні характеристики не відповідають потребам замовника або система функціонує непередбаченим образом.
Тестування програмних компонентів і модулів зазвичай виконується тим програмістом, який їх розробляв. Програмісти мають власні набори тестових даних і тестують програмний код поступово, у міру його створення. Такий підхід до тестування окремих компонентів і модулів цілком виправданий, оскільки ніхто краще програміста, що розробив програмний компонент, його не знає, і тому він може підібрати найкращі тестові дані. Тестування програмних елементів можна розглядати як частину процесу їх створення, тому ми маємо право очікувати точної відповідності цих елементів і їх специфікацій.
Останні етапи тестування виконуються в процесі складання системи, до якого залучається декілька програмістів. Тому ці роботи повинні бути сплановані заздалегідь. Якщо тестування виконує незалежна команда випробувачів, плани проведення тестування повинні бути погоджені з етапами розробки специфікації і проектування. На рис. 1.12 показано, як плани тестування можуть бути пов'язані з іншими процесами розробки ПЗ.
Рис. 1.12. Етапи тестування в процесі розробки ПЗ
Приймальні випробування іноді називають альфа-тестуванням. Зроблені на замовлення системи призначені для одного замовника. Для таких систем процес альфа-тестування триває доти, поки розробники і замовник не впевняться в тому, що розроблена система повністю відповідає системним вимогам.
Якщо система розробляється для продажу на ринку програмних продуктів, використовується так зване бета-тестування. Для бета-тестування система розсилається великій кількості потенційних користувачів і замовників. Вони відсилають розробникам звіти про виявлені проблеми в експлуатації системи. Бета-тестування дозволяє перевірити систему в реальних умовах експлуатації і знайти помилки, пропущені розробниками. Після одержання звітів про випробування система модернізується і знову передається на бета-тестування або відразу надходить у продаж.