Лекція 8. Тестування і відлагодження програмного засобу

4.Види Тестування

4.1.Тестування правильності

Після закінчення тестування інтеграції програмна система зібрана в єдиний корпус, інтерфейсні помилки виявлені і відкоректовані. Тепер починається останній крок програмного тестування — тестування правильності. Мета — підтвердити, що функції, описані в специфікації вимог до ПС, відповідають очікуванням замовника [64] [69].

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

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

1)системну специфікація;

2)план програмного проекту;

3)специфікацію вимог до ПС; працюючий або паперовий макет;

4)попереднє керівництво користувача;

5)специфікація проектування;

6)лістинги початкових текстів програм;

7)план і методикутестування; тестові варіанти і отримані результати;

8)керівництво по роботі і інсталяції;

9)ехе-код виконуваної програми;

10)опис бази даних;

11)керівництво користувача по настройці;

12)документи супроводу, звіти про проблеми, запити супроводу, звіти про конструкторські зміни;

13)стандарти і методики конструювання ПС.

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

Розробник не може передбачити, як замовник реально використовуватиме ПС. Для виявлення помилок, які здатний знайти тільки кінцевий користувач, використовують процес, що включає альфа- і бета-тестування.

Альфа-тестірованіє проводиться замовником в організації розробника. Розробник фіксує всі виявлені замовником помилки і проблеми використання.

Бета-тестування проводиться кінцевим користувачем в організації замовника. Розробник в цьому процесі участі не приймає. Фактично, бета-тестування — це реальне застосування ПС в середовищі, яке не управляється розробником. Замовник сам записує всі виявлені проблеми і повідомляє про них розробника. Бета-тестування проводиться протягом фіксованого терміну (близько року). За наслідками виявлених проблем розробник змінює ПС і тим самим готує продукт повністю на базі замовника.

4.2.Системне тестування

Системне тестування має на увазі вихід за рамки області дії програмного проекту і проводиться не тільки програмним розробником. Класична проблема системного тестування — вказівка причини. Вона виникає, коли розробник одного системного елементу звинувачує розробника іншого елементу в причині виникнення дефекту. Для захисту від подібного звинувачення розробник програмного елементу винен:

передбачити засоби обробки помилки, які тестують всі введення інформації від інших елементів системи;

провести тести, що моделюють невдалі дані або інші потенційні помилки інтерфейсу ПС; записати результати тестів, щоб використовувати їх як доказ невинності у разі «вказівки

причини»; взяти участь в плануванні і проектуванні системних тестів, щоб гарантувати адекватне тестування

ПС.

93

Лекція 8. Тестування і відлагодження програмного засобу Кінець кінцем системні тести повинні перевіряти, що всі системні елементи правильно об'єднані і

виконують призначені функції. Розглянемо основні типи системних тестів [13] [52].

4.3.Тестування відновлення

Багато комп'ютерних систем повинні відновлюватися після відмов і відновлювати обробку в межах заданого часу. В деяких випадках система повинна бути відмовостійкою, тобто відмови обробки не повинні бути причиною припинення роботи системи. У інших випадках системна відмова повинна бути усунений в межах заданого кванта часу, інакше замовникові завдається серйозного економічного збитку.

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

4.4.Тестування безпеки

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

Тестування безпеки перевіряє фактичну реакцію захисних механізмів, вбудованих в систему, на проникнення.

В ході тестування безпеки випробувач грає роль зломщика. Йому дозволено все: спроби дізнатися пароль за допомогою зовнішніх засобів; атака системи за допомогою спеціальних утиліт, що аналізують захист;

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

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

4.5.Стресове тестування

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

Стресове тестування проводиться при ненормальних запитах на ресурси системи (по кількості, частоті, розміру-об'єму).

Приклади:

генерується 10 переривань в секунду (при середній частоті 1,2 переривань в секунду); швидкість введення даних збільшується прямо пропорціонально їх важливості (щоб визначити

реакцію вхідних функцій); формуються варіанти, що вимагають максимуму пам'яті і інших ресурсів;

генеруються варіанти, що викликають переповнювання віртуальної пам'яті; проектуються варіанти, що викликають надмірний пошук даних на диску.

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

94

Лекція 8. Тестування і відлагодження програмного засобу

4.6.Тестування продуктивності

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

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

95