Комплексна відладка програмного засобу

Як вже було сказано вище, при комплексній відладці тестується ПС в цілому, причому тести готуються по кожному з документів ПС [10.8]. Тестування цих документів проводиться, як правило, в порядку, зворотному їх розробці. Виключення складає лише тестування документації по застосуванню, яка розробляється по зовнішньому опису паралельно з розробкою текстів програм - це тестування краще проводити після завершення тестування зовнішнього опису. Тестування при комплексній відладці є застосуванням ПС до конкретних даних, які в принципі можуть виникнути у користувача (зокрема, всі тести готуються у формі, розрахованій на користувача), але, можливо, в модельованому (а не в реальній) середовищі. Наприклад, деякі недоступні при комплексній відладці пристрої введення і виводу можуть бути замінені їх програмними імітаторами.

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

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

Тестування якості ПС. Метою тестування є пошук порушень вимог якості, сформульованих в специфікації якості ПС. Це найбільш важкий і найменш вивчений вид тестування. Ясно лише, що далеко не кожен примітив якості ПС може бути випробуваний тестуванням (про оцінку якості ПС див. лекцію 14). Завершеність ПС перевіряється вже при тестуванні зовнішніх функцій. На даному етапі тестування цього примітиву якості може бути продовжене, якщо потрібно отримати яку-небудь імовірнісну оцінку ступеня надійності ПС. Проте, методика такого тестування ще вимагає своєї розробки. Можуть тестуватися такі примітиви якості, як точність, стійкість, захищеність, тимчасова ефективність, в якійсь мірі - ефективність по пам'яті, ефективність по пристроях, розширюваність і, частково, незалежність від пристроїв. Кожен з цих видів тестування має свою специфіку і заслуговує окремого розгляду. Ми тут обмежимося лише їх перерахуванням. Легкість застосування ПС (критерій якості, що включає декілька примітивів якості, див. лекцію 4) оцінюється при тестуванні документації по застосуванню ПС.

Тестування документації по застосуванню ПС. Метою тестування є пошук неузгодженості документації по застосуванню і сукупністю програм ПС, а також виявлення незручностей, що виникають при застосуванні ПС. Цей етап безпосередньо передує підключенню користувача до завершення розробки ПС (тестуванню визначення вимог до ПС і атестацій ПС), тому вельми важливо розробникам спочатку самим скористатися ПС так, як це робитиме користувач [10.1]. Всі тести на цьому етапі готуються виключно на підставі тільки документації по застосуванню ПС. Перш за все, повинні тестуватися можливості ПС як це робилося при тестуванні зовнішніх функцій, але тільки на підставі документації по застосуванню. Повинні бути протестовані всі неясні місця в документацію, а також всі приклади, використані в документації. Далі тестуються найбільш важкі випадки застосування ПС з метою виявити порушення вимог відносності легкості застосування ПС.

Тестування визначення вимог до ПС. Метою тестування є з'ясування, якою мірою ПС не відповідає пред'явленому визначенню вимог до нього. Особливість цього виду тестування полягає в тому, що його здійснює організація-покупець або організація-користувач ПС [10.1] як один з шляхів подолання бар'єру між розробником і користувачем (див. лекцію 3). Звичайне це тестування проводиться за допомогою контрольних завдань - типових завдань, для яких відомий результат рішення. У тих випадках, коли ПС, що розробляється, винне придти на зміну іншої версії ПС, яка вирішує хоч би частину завдань ПС, що розробляється, тестування проводиться шляхом вирішення загальних завдань за допомогою як старого, так і нового ПС (з подальшим зіставленням отриманих результатів). Іноді як форма такого тестування використовують дослідну експлуатацію ПС - обмежене застосування нового ПС з аналізом використання результатів в практичній діяльності. По суті, цей вид тестування багато в чому перекликається з випробуванням ПС при його атестації (див. лекцію 14), але виконується до атестації, а іноді і замість атестації.

Дата добавления: 2014-01-07