- •4 Верифікація, валідація та тестування. Стандарти тестування пп
- •Тема 10 Верифікація і атестація програм
- •4.1 Методи верифікації об'єктно-орієнтованих програм
- •4.2 Тестування та налагодження програм
- •4.3 Організаційні аспекти процесу тестування
- •4.4 Класифікація помилок. Міжнародний стандарт ansi/ieee - 729-83 розділяє усі помилки в розробці програм:
- •4.5 Джерело помилок.
- •4.6 Організація підготовки тестів
- •7 Команда тестувальників
- •8 Організація процесу тестування
- •9 Організація тестування по регулюється наступними стандартами:
- •Ieee 829-1998 Standard for Software Test Documentation.
- •Ieee 1008-1987 (r1993, r2002) Standard for Software Unit Testing.
4.1 Методи верифікації об'єктно-орієнтованих програм
Верифікація таких програм має свою специфіку і її можна розглядати виходячи з композиційного методу, застосовуючи до них відомі методи доказу правильності композиційних програм [14, 16, 17].
Виділимо декілька етапів для верифікації початкового проектування об'єктних моделей і програм:
1. Верифікація базових (простих) об'єктів зводиться до верифікації структури, де атрибути об'єктів є даними структури, а внутрішні операції об'єкту - функціями над цими даними.
2. Верифікація об'єктів, побудованих за допомогою спадкоємства, агрегації або інкапсуляції, здійснюється виходячи з таких припущень:
- базові об'єкти вважаються перевіреними, якщо їх операції (функції) прийняті за теореми;
- доказ об'єктів зводиться до цих теорем;
- доводиться, що усі операції, які застосовуються над підоб’єктами, не виводять їх з безлічі станів, для яких вони верифіковані.
3. Верифікація інтерфейсів об'єктів зводиться до доказу:
- правильності цього інтерфейсу;
- достатності параметрів інтерфейсу.
Метод верифікації на основі композиційного підходу можна використовувати як "вниз" так і "вгору". Спочатку доводиться правильність побудованої об’єктної моделі (ОМ) для деякої предметної області. Верифікація ОМ вимагає реалізації на етапах ЖЦ наступних питання:
- видалення зайвих атрибутів об'єктів і їх інтерфейсів в ОМ, внесення необхідних змін і повторний доказ правильності об'єкту;
- вибір типу великої кількості для атрибутів об'єкту і перевірка реалізації операцій і безліч значень цього типу.
Правильність специфікацій будь-якого об'єкту ПП доводиться незалежно від правильності суміжних об'єктів і верифікації їх інтерфейсів. Це є завершальною перевіркою ОМ.
4.2 Тестування та налагодження програм
Тестування є одним з етапів ЖЦ ПВ, спрямованим на підвищення якісних характеристик. За даними [60], під час створення типового ПВ близько 40% загальної тривалості та 40% загальної вартості розробки витрачається на перевірку (тестування) програми. Тому головним критерієм заходів щодо стратегії та правил тестування залишається мінімізація трудомісткості тестування.
Тестування - це спосіб семантичної відладки (перевірки) програми, що полягає в обробці послідовності різних контрольних наборів тестів, для яких відомий результат. Тестування ґрунтується на виконанні програми і отриманні результатів виконання тестів [1-7, 21, 22].
Тести підбираються так, щоб вони охопили якомога більше різних типів ситуацій обробки елементів програми.
Історично першим різновидом тестування була відладка.
Процес тестування об'єднує різні способи тестування в сплановану послідовність кроків, які призводять до успішної побудови програмної системи (ПП)[3], [13], [64], [69]. Методика тестування ПП може бути представлена у вигляді спіралі (рис. 4.1), що розгортається.
Рис. 4.1. Спіраль процесу тестування ПП
На початку здійснюється тестування елементів (модулів), яке перевіряє результати етапу кодування ПП. На другому кроці виконується тестування інтеграції, орієнтоване на виявлення помилок етапу проектування ПП. На третьому обороті спіралі проходить тестування правильності, яке перевіряє коректність етапу аналізу вимог до ПП. На завершальному витку спіралі проводиться системне тестування, що виявляє дефекти етапу системного аналізу ПП.
Охарактеризуємо кожен крок процесу тестування.
1. Тестування елементів. Мета - індивідуальна перевірка кожного модуля. Використовуються способи тестування "білої скрині".
2. Тестування інтеграції. Мета - тестування зборки модулів в програмну систему. В основному застосовують способи тестування "чорної скрині".
3. Тестування правильності. Мета - перевірити реалізацію в програмній системі усіх функціональних і поведінкових вимог, а також вимог ефективності. Використовуються виключно способи тестування "чорної скрині".
4. Системне тестування. Мета - перевірка правильності об'єднання і взаємодії усіх елементів комп'ютерної системи, реалізації усіх системних функцій.
Організація процесу тестування у вигляді еволюційної спіралі, що розгортається, забезпечує максимальну ефективність пошуку помилок.
Тестування - кінцева процедура. Набір ситуацій, в яких перевірятиметься ПП завжди кінцевий. Більше того, він має бути настільки малий, щоб тестування можна було провести у рамках проекту розробки ПП, не занадто збільшуючи його бюджет і терміни. Це означає, що при тестуванні завжди перевіряється дуже невелика доля усіх можливих ситуацій.
Для цього необхідно мати критерії повноти тестування, що описують важливість різних ситуацій для оцінки якості, а також еквівалентності і залежності між ними. Цей критерій може стверджувати, що все одно в якій з ситуацій, A або B, перевіряти правильність роботи ПП, або, якщо програма правильно працює в ситуації A, то, швидше за все, в ситуації B усе також буде правильно.
Таким чином, основні завдання тестування: побудувати такий набір ситуацій, який був би досить показний і дозволяв би завершити тестування з достатньою мірою упевненості в правильності ПП взагалі, і переконатися, що в конкретній ситуації ПП працює правильно, відповідно до вимог.
Рис. 4.2. Схема процесу тестування
Тестування - найбільш широко вживаний метод контролю якості. Для оцінки багатьох атрибутів якості не існує інших ефективних способів, окрім тестування.
Тестування здійснюється шляхом створення середовища, що є еквівалентним реальному середовищу, в якому повинна функціонувати програма. Середовище функціонування містить дві складові: інформаційне та програмне середовище.
Інформаційне середовище містить вхідні дані, які обробляються; вхідні керуючі параметри та вихідну інформацію. Цей напрям перевірки називається функціональне тестування. Функціональне тестування (стратегія «чорної скрині») мета:
визначення НЕвідповідності між задачею, для розв’язання якої вона призначена, і тією, яку вона дійсно вирішує;
визначення з достатнім ступенем вірогідності рівнів безвідмовності та стійкості програми.
Програмне середовище реалізує зв’язки програми, яка перевіряється, з іншими програмами, в тому числі й операційною системою. Цей напрямок перевірки називається структурне тестування. Структурне тестування (стратегія «білої скрині») має за мету дослідження внутрішньої структури програми. Комбінація методів перевірки дає змогу вирішити такі задачі:
перевірка логіки;
перевірка обчислювальних функцій;
контроль за процедурами вводу-виводу;
контроль за маніпулюванням даними.
Для забезпечення повноти тестування не можна обмежуватись тільки одним типом тестування, а треба поєднувати можливості функціонального та структурного тестування.
Технологія тестування передбачає використання набору тестів. Тест — це сукупність, яка містить початкові дані, що спеціально підібрані для програми, яка перевіряється, та відповідні їм еталонні результати (не тільки остаточні, а і проміжні), та використовується для виявлення дефектів і помилок у програмі. Виходячи з визначення «тестування», вдалим можна вважати тест, що приводить до викриття нової помилки, а ефективним — той тестовий набір, який має високу ймовірність викриття більшої кількості помилок. Таким чином, тестування програми зводиться до підбору системи ефективних тестів, їх прогону та порівняння отриманих результатів з еталонними.
Повнота тестування обумовлена різноманітністю тестів, підготовлених для перевірки програми. Серед них виділяють групи тестів за напрямами тестування. Типи тестів, що використовуються для функціонального тестування: основні, тести межових значень, аварійні, вироджені.
Основні тести призначені для перевірки основних функцій програми без урахування хибних ситуацій. У цьому випадку можна використовувати набір правильних вхідних даних.
Тести межових значень дають змогу контролювати програму для межових значень даних, що визначають обчислювальний процес, а також можуть містити дані, що не є типовими для програми, яка перевіряється.
Аварійні тести використовуються для перевірки реакції програми на виникнення ситуацій, пов’язаних із хибними даними, що надходять на обробку.
Вироджені тести використовуються для перевірки правильності виконання зовнішніх функцій програми.
Типи тестів, що використовуються для структурного тестування: стикові, комплексні.
Стикові тести призначені для перевірки взаємозв’язку вже налагоджених частин програми і застосовуються в міру готовності модулів нижчих рівнів.
Комплексні тести перевіряють правильність роботи всіх або більшості модулів програми після їх об’єднання.
Ефективність тестування визначається співвідношенням трудомісткості процесу тестування і кількістю виявлених помилок. Зменшенню трудомісткості тестування сприяє правильне визначення обсягу тестових даних та організація проведення тестових випробувань.
Ефективність тестового набору для функціонального тестування може бути забезпечена методами [60]: еквівалентного розподілу, аналізу межових значень, функціональних діаграм.
Метод еквівалентного розподілу передбачає виділення класів еквівалентності та побудову тестів для кожного класу. Класом еквівалентності є множина вхідних значень, кожне з яких має однакову ймовірність виявлення помилки певного типу.
Аналіз межових значень передбачає дослідження ситуацій, пов’язаних із межовими значеннями кожного класу еквівалентного розподілу.
Метод функціональних діаграм передбачає перетворення вхідної специфікації програми у функціональну діаграму за допомогою найпростіших булевських відношень, побудови таблиці рішень, яка є основою для створення ефективних тестових наборів даних.
Критеріями формування ефективного тестового набору для структурного тестування можуть бути: покриття операторів, покриття вузлів розгалуження, покриття умов, комбінаторне покриття умов.
Покриття операторів. Цей критерій передбачає підготовку такого тестового набору даних, який викликає виконання кожного оператору програмі хоча би один раз.
Покриття вузлів розгалуження. Цей критерій передбачає підготовку такої кількості тестів, щоб у кожному вузлі розгалуження був забезпечений перехід гілками «істина» та «хибність» хоча би один раз.
Покриття умов. Якщо вузол розгалуження містить більше ніж одну умову, кількість тестів, яку необхідно підготувати, повинна бути достатньою для того, щоб можливі результати кожної умови виконувалися хоча би один раз.
Комбінаторне покриття умов. Цей критерій потребує створення такої кількості тестів, щоб усі можливі комбінації результатів умови у кожному рішенні виконувалися хоча би один раз.
Мета тестування, а саме виявлення максимальної кількості помилок, може бути досягнута дотриманням основних принципів тестування:
Опис передбачуваних значень результатів тестових прогонів повинен бути невід’ємною часткою тестового набору. Треба пам’ятати, що правдоподібний результат є не завжди правильним.
Процес тестування більш ефективний, якщо виконується не її автором. Це пояснюється тим, що після завершення проектування та кодування програми автору психологічно важко відразу перейти до пошуку помилок у ній. Крім того, якщо під час проектування програмістом було допущено неправильне трактування постановки задачі, то під час тестування він не зможе виявити пов’язані з цим помилки. Це не означає, що автор не може тестувати свою програму, йдеться про підвищення ефективності тестування.
Потрібно вивчати результати застосування кожного тесту. Пропущені помилки так чи інакше проявляться у більш складних тестах, але виявити їх буде важче.
Тести для неправильних і непередбачуваних вхідних даних потрібно розробляти так само старанно, як і для правильних і передбачуваних.
Потрібно перевіряти відсутність непередбачених побічних ефектів у роботі програми. Для цього треба встановити, чи не робить програма того, чого робити не повинна поза свого функціонального призначення.
Не слід знищувати тести після завершення випробувань, тому що вони будуть потрібні під час модифікації програми.
Імовірність наявності невиявлених помилок у частині програми пропорційна кількості помилок, що вже виявлені у цій частині. Така властивість помилок групуватися пояснюється тим, що ділянка програми, де під час тестування виявлена найбільша кількість помилок, була погано спроектована концептуально або розроблялася програмістом низької кваліфікації. Таким частинам програми слід приділяти особливу увагу під час тестування.
