Зростаюче тecтування інтеграції

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

Кроки методики:

1. Модулі нижнього рівня поєднуються в кластери (групи, блоки), що виконують визначену програмну підфункцію.

2. Для координації введення-виведення тестового варіанта пишеться драйвер, керуючий тестуванням кластерів.

3. Тестується кластер.

4. Драйвери віддаляються, а кластери поєднуються в структуру рухом нагору.

Порiвияиня спадного I зростаючого тестування інтеграції

Спадне тестування:

1) основний недолік - необхідність заглушок i зв’язані з ними труднощі тестування;

2) основне достоїнство - можливість раннього тестування головних керуючих функцій.

Зростаюче тестування:

1) основний недолік - система не існує як об’єкт доти, поки не буде доданий останнiй модуль;

2) основне достоїнство - спрощується розробка тестових варіантів, відсутні заглушки.

При проведенні тестування інтеграції дуже важливо виявити критичні модулі.

Ознаки критичного модуля:

1) реалізує кілька вимог до ПС;

2) має високий рівень керування (знаходиться досить високо в програмній структурі);

3) має високу складність чи схильність до помилок (як індикатор може використовуватися

цикломатична складнiсть - її верхня розумна межа складає 10);

4) має визначені вимоги до продуктивності обробки.

Критичні модулі повинні тестуватися якомога раніше. Крім того, до них повинне застосовуватися регресійне тестування (повторення уже виконаних тестів у повному чи частковому обсязі).

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

Ocтaнній крок програмного тестування - тестування правильності.

Мета - підтвердити, що функції, описані в специфікації вимог до ПС, відповідають очікуванням замовника.

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

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

Мінімальна конфігурація ПС включає наступні базові елементи:

1. системну специфікацію;

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

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

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

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

6. лістинги вихідних тестів програм;

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

8. посібник з роботи й інсталяції;

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

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

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

12. документи супроводу; звіти про проблеми ПС; запити супроводи-звiти про конструкторські зміни;

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

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

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

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