Тестування

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

Тестування — кінцева процедура. Набір ситуацій, в яких перевірятиметься тестоване ПО завжди кінцевий. Більш того, він повинен бути настільки малий, щоб тестування можна було провести в рамках проекту розробки ПО, не дуже збільшуючи його бюджет і терміни. Це означає, що при тестуванні завжди перевіряється дуже невелика частка всіх можливих ситуацій. Із цього приводу Дейкстра (Dijkstra) сказав, що тестування дозволяє точно визначити, що помилка є в програмі, але ніколи не дозволяє стверджувати, що там немає помилок.

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

Таким чином, основні завдання тестування — побудувати такий набір ситуацій, який був би достатньо представницький і дозволяв би завершити тестування з достатнім ступенем упевненості в правильності що перевіряється ПО взагалі, і переконатися, що в конкретній ситуації ПО працює правильно, відповідно до вимог.

Рис. 14.3 – Схема процесу тестування

Тестування — найбільш широко вживаний метод контролю якості. Для оцінки багатьох атрибутів якості не існує інших ефективних способів, окрім тестування.

Організація тестування ПО регулюється наступними стандартами.

- IEEE 829-1998 Standard for Software Test Documentation. Описує види документів, що служать для підготовки тестів.

- IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing. Описує організацію модульного тестування.

- ISO/IEC 12119:1994 (аналог AS/NZS 4366:1996 і ГОСТ Р-2000, також прийнятий IEEE під номером IEEE 1465-1998) Information Technology. Software packages — Quality requirements and testing.

Тестувати можна дотримання будь-яких вимог, відповідність яким виявляється під час роботи ПО. З характеристик якості по ISO 9126 цією властивістю не володіють тільки атрибути зручності супроводу. Тому виділяють види тестування, пов'язані з перевіркою певних характеристик і атрибутів якості, — тестування функціональності, надійності, зручності використання, переносимості і продуктивності, а також тестування захищеності, функціональній придатності і ін. Крім того, особливо виділяють тестування навантаження або стресового,перевіряюче працездатність ПО і показники його продуктивності в умовах підвищених навантажень, — великій кількості користувачів, інтенсивному обміні даними з іншими системами, великим об'ємом передаваних або використовуваних даних, і ін.

На основі початкових даних, використовуваних для побудови тестів, тестування ділять на наступні види.

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

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

3. Тестирование, нацеленное на определенные ошибки. Тесты для такого тестирования строятся так, чтобы гарантированно выявлять определенные виды ошибок. Полнота тестирования определяется на основе количества проверенных ситуаций по отношению к общему числу ситуаций, которые мы пытались достичь. К этому виду относится, например, тестирование на отказ (smoke testing), в ходе которого просто пытаются вывести систему из строя, давая ей на вход как обычные данные, так и некорректные, с нарочно внесенными ошибками. Другим примером служит метод оценки полноты тестирования при помощи набора мутантов — программ, совпадающих с тестируемой всюду, кроме нескольких мест, где специально внесены некоторые ошибки. Чем больше мутантов тесты находят, тем полнее проводимое с их помощью тестирование.

Ще одна класифікація видів тестування заснована на тому рівні, на який воно націлене. Ці ж різновиди тестування можна пов'язати з фазою життєвого циклу, на якій вони виконуються.

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

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

3. Системне тестування (system testing) призначене для перевірки правильності роботи системи в цілому, її здатності правильно вирішувати поставлені користувачами завдання в різних ситуаціях. Системне тестування тісно пов'язане з тестуванням призначеного для користувача інтерфейсу (або через призначений для користувача інтерфейс), що проводиться за допомогою імітації дій користувачів над елементами цього інтерфейсу. Окремими випадками цього виду тестування є тестування графічного призначеного для користувача інтерфейсу (Graphical User Interface, GUI) і призначеного для користувача інтерфейсу Інтернет-додатків (Web UI). Якщо інтеграційне і модульне тестування найчастіше проводять, впливаючи на компоненти системи за допомогою операцій що надається ними програмного інтерфейсу (Application Programming Interface, API), то на системному рівні без використання призначеного для користувача інтерфейсу не обійтися, хоча тестування через API в цьому випадку також часто можливо.

4. Проверка свойств на моделях (model checking) [10] — проверка соответствия ПО требованиям при помощи формализации проверяемых свойств, построения формальных моделей проверяемого ПО (чаще всего в виде автоматов различных видов) и автоматической проверки выполнения этих свойств на построенных моделях. Проверка свойств на моделях позволяет проверять достаточно сложные свойства автоматически, при минимальном участии человека. Однако она оставляет открытым вопрос о том, насколько выявленные свойства модели можно переносить на само ПО.

Рис. 14.4 – Схема процесу перевірки властивостей ПО на моделях

Зазвичай за допомогою перевірки властивостей на моделях аналізують два види властивостей використаних при побудові ПО алгоритмів. Властивості безпеки (safety properties) стверджують, що щось небажане ніколи не трапиться в ході роботи ПО. Властивості живучості (liveness properties) затверджують, навпаки, що щось бажане при будь-якому розвитку подій відбудеться в ході його роботи.

Прикладом властивості першого типу служить відсутність взаємних блокувань (deadlocks). Взаємне блокування виникає, якщо кожен з групи тих, що паралельно працюють в тому, що перевіряється ПО процесів або потоків чекає прибуття даних або зняття блокування від одного з інших, а той не може цього зробити, тому що не може продовжити виконання, чекаючи того ж від першого або від третього процесу, і так далі

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

У класичному підході до перевірки на моделях властивості, що перевіряються, формалізуються у вигляді формул так званих тимчасових логік. Їх загальною межею є наявність операторів «завжди в майбутньому» і «колись в майбутньому». Відмітимо, що другий оператор може бути виражений за допомогою першого і заперечення — те, що деяка властивість колись буде виконана, еквівалентно тому, що заперечення цієї властивості не буде виконано завжди. Властивості безпеки легко записуються у вигляді «завжди буде виконано заперечення небажаної властивості», а властивості жвавості — у вигляді «колись обов'язково буде виконано бажане».

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

Основная проблема этого подхода — огромное количество состояний в моделях, достаточно хорошо отражающих поведение реальных программ. Для борьбы с комбинаторным взрывом состояний используются многочисленные методы оптимизации представления автомата и оптимизации выделения и поиска существенных для выполнения проверяемого свойства состояний.