- •Пояснювальна записка
- •Розділ 1 структурне тестування програмного забезпечення
- •Тема 1.1 Класифікація принципів тестування програмного забезпечення
- •1. Структурні критерії (клас і)
- •2. Функціональні критерії (клас II)
- •3. Стохастичні критерії (клас III)
- •4. Мутаційний критерій (клас IV)
- •Тема 1.2 Переваги та недоліки принципів тестування
- •Тема 1.3 Кроки способу тестування базового шляху
- •Тема 1.4 Спосіб тестування потоків даних
- •Тема 1.5 Тестування вкладених циклів
- •Розділ 2 функціональне тестування програмного забезпечення
- •Тема 2.1 Спосіб тестування діаграм причин-наслідків
- •Тема 2.2 Тестування елементів
- •Тема 2.3 Переваги та недоліки низхідного та висхідного тестування
- •Тема 2.4 Стресове тестування та тестування виробності
- •Тема 2.5 Переваги та недоліки різних методів відлагодження
- •Тема 3.1 Особливості інтеграційного тестування для об’єктно-орієнтованого програмування
- •Тема 3.2 Переваги та недоліки системного та регресійного тестування
- •Тема 3.3 Тестування поверхневої та поглибленої структури системи
- •Тема 3.4 Тестування взаємодії класів
- •Тема 3.5 Переваги та недоліки ручного та автоматизованого тестування
- •Розділ 4 особливості індустріального тестування
- •Тема 4.1 Оцінка якості тестування
- •Тема 4.2 Використання специфікацій вимог до розробки тестів
- •Тема 4.3 Автоматизація тестування з допомогою скриптів
- •Тема 4.4 Документування та життєвий цикл дефекту
- •Розділ 5 принципи розробки програм для тестування
- •Тема 5.1 Особливості моделей апаратного забезпечення
- •Тема 5.2 Тестування Verilog-моделей
- •Тема 5.3 Тестування на етапі супроводу
- •Тема 5.4 Встановлення, наладка та використання пакету Everest
- •Тема 5.5 Документування результатів роботи тестового пакету
Тема 3.2 Переваги та недоліки системного та регресійного тестування
Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.
Логічним завершенням інтеграційного тестування є системне тестування. На цьому етапі всі модулі системи об'єднані й працюють разом. Системне тестування призначене не для виявлення проблем окремих модулів - всі вони повинні були бути усунуті раніше, а для виявлення проблем системи в цілому, проблем використання системи в реальному оточенні. Системні тести враховують такі аспекти системи, як стійкість у роботі, продуктивність, відповідність системи очікуванням користувача й т.п. Для визначення повноти системного тестування також використаються інші способи - оцінюється повнота виконання всіх можливих сценаріїв роботи (як штатних, так і позаштатних), повнота різних методів взаємодії системи із зовнішнім миром і т.п.
По завершенню інтеграційного тестування всі модулі системи є погодженими по інтерфейсах і функціональності. Починаючи із цього моменту можна переходити до тестування системи в цілому як єдиного об'єкта тестування - до системного тестування. На рівні інтеграційного тестування тестувальника цікавили в основному структурні аспекти системи, на рівні системного тестування цікавлять поведінкові аспекти системи. Як правило, для системного тестування застосовується підхід чорного ящика, при цьому в якості вхідних і вихідних даних використаються реальні дані, з якими працює система, або дані, подібні їм.
Системне тестування - один із самих складних видів тестування. На цьому етапі проводиться не тільки функціональне тестування, але й оцінка характеристик якості системи - її стійкості, надійності, безпеці й продуктивності. На цьому етапі виявляються багато роблем зовнішніх інтерфейсів системи, пов'язані з невірною взаємодією з іншими системами, апаратним забезпеченням, невірним розподілом пам'яті, відсутністю коректного звільнення ресурсів і т.п.
Після завершення системного тестування розробка переходить у фазу приймально-здавальних випробувань (для програмних систем, розроблювальних на замовлення) або у фазу альфа- і бета-тестування (для програмних систем загального застосування).
Оскільки системне тестування - процес, що вимагає значних ресурсів, для його проведення часто виділяють окремий колектив тестувальників, а найчастіше системне тестування виконується організацією, що не пов'язана з колективом розроблювачів і тестувальників, що виконувала роботи на попередніх етапах тестування. При цьому необхідно відзначити, що при розробці деяких типів програмного забезпечення (наприклад, авіаційного бортового) вимога незалежного тестування на всіх етапах розробки є обов'язковою.
Системне тестування проводиться в кілька фаз, на кожній з яких перевіряється один з аспектів поведінки системи, тобто проводиться один з типів системного тестування. Всі ці фази можуть протікати одночасно або послідовно.
Прийнято виділяти наступні види системного тестування:
- функціональне тестування;
- тестування продуктивності;
- навантажувальне або стресове тестування;
- тестування конфігурації;
- тестування безпеки;
- тестування надійності й відновлення після збоїв;
- тестування зручності використання.
У ході системного тестування проводяться далеко не все з перерахованих видів тестування - конкретний їхній набір залежить від системи, що тестується.
Вихідною інформацією для проведення перерахованих видів тестування є два класи вимог: функціональні й нефункціональні. Функціональні вимоги явно описують, що система повинна робити і які виконувати перетворення вхідних значень у вихідні. Нефункціональні вимоги визначають властивості системи, прямо не пов'язані з її функціональністю. Прикладом таких властивостей може служити час відгуку на запит користувача (наприклад, не більше 2 секунд), час безперебійної роботи (наприклад, не менш 10000 годин між двома збоями), кількість помилок, які допускає починаючий користувач за перший тиждень роботи (не більше 100), і т.п.
При коректуваннях програми необхідно гарантувати збереження якості. Для цього використовується регресійне тестування - дорога, але необхідна діяльність у рамках етапу супроводу, спрямована на повторний огляд коректності зміненої програми. У відповідності зі стандартним визначенням, регресійне тестування - це вибіркове тестування, що дозволяє переконатися, що зміни не викликали небажаних побічних ефектів, або що змінена система як і раніше відповідає вимогам.
Головним завданням етапу супроводу є реалізація систематичного процесу обробки змін у коді. Після кожної модифікації програми необхідно впевнитися, що на функціональність програми не зробив впливу модифікований код. Якщо такий вплив виявлений, говорять про регресійний дефект. Для регресійного тестування функціональних можливостей, зміна яких не планувалася, використовуються раніше розроблені тести. Одна із цілей регресійного тестування полягає в тому, щоб, відповідно до використовуваного критерію покриття коду (наприклад, критерієм покриття потоку операторів або потоку даних), гарантувати той же рівень покриття, що й при повному повторному тестуванні програми. Для цього необхідно запускати тести, що відносяться до змінених областей коду або функціональних можливостей.
Інша мета регресійного тестування полягає в тому, щоб упевнитися, що програма функціонує у відповідності зі своєю специфікацією, і що зміни не привели до внесення нових помилок у раніше протестований код. Ця мета завжди може бути досягнута повторним виконанням всіх тестів регресійного набору, але більш перспективно відсівати тести, на яких вихідні дані модифікованої й старої програми не можуть розрізнятися.
Контрольні запитання:
Для чого призначені системні тести?
Які характеристики перевіряються на етапі системного тестування?
Який недолік має системне тестування?
Які види системного тестування розрізняють?
Для чого використовується регресійне тестування?
Які типи дефектів знаходять з допомогою регресійного тестування?
Чому регресіне тестування є коштовним?
Яка мета регресійного тестування?
