Як уже було сказано вище, при комплексному налагодженні тестується ПЗ у цілому, причому тести готуються по кожному з документів ПЗ. Тестування цих документів виробляється, як правило, у порядку, зворотному їхній розробці (виключення становить лише тестування документації по застосуванню, що розробляється по зовнішньому описі паралельно з розробкою текстів програм; це тестування краще робити після завершення тестування зовнішнього опису). Тестування при комплексному налагодженні являє собою застосування ПЗ до конкретних даних, які в принципі можуть виникнути в користувача (зокрема, всі тести готуються у формі, розрахованої на користувача), але, можливо, у моделюємій (а не в реальній) середовищі. Наприклад, деякі недоступні при комплексному налагодженні пристрою уведення й висновку можуть бути замінені їхніми програмними імітаторами.
Тестування архітектури ПЗ. Метою тестування є пошук невідповідності між описом архітектури й сукупністю програм ПЗ. До моменту початку тестування архітектури ПЗ повинна бути вже закінчене автономне налагодження кожної підсистеми. Помилки реалізації архітектури можуть бути зв'язані насамперед із взаємодією цих підсистем, зокрема, з реалізацією архітектурних функцій (якщо вони є). Тому хотілося б перевірити всі шляхи взаємодії між підсистемами ПЗ. Але тому що їх може бути занадто багато, те бажано б протестувати хоча б всі ланцюжки виконання підсистем без повторного входження останніх. Якщо задана архітектура представляє ПЗ як мала система з виділених підсистем, то число таких ланцюжків буде цілком доступно для огляду.
Тестування зовнішніх функцій. Метою тестування є пошук розбіжностей між функціональною специфікацією й сукупністю програм ПЗ. Незважаючи на те, що всі ці програми автономно вже налагоджені, зазначені розбіжності можуть бути, наприклад, через невідповідність внутрішніх специфікацій програм і їхніх модулів (на підставі яких вироблялося автономне тестування) зовнішньої функціональної специфікації ПЗ. Як правило, тестування зовнішніх функцій виробляється так само, як і тестування модулів на першому кроці, тобто як чорного ящика.
Тестування якості ПЗ. Метою тестування є пошук порушень вимог якості, сформульованих у специфікації якості ПЗ. Це найбільш важкий і найменш вивчений вид тестування. Ясно лише, що далеко не кожний примітив якості ПЗ може бути випробуваний тестуванням (про оцінку якості ПЗ див. наступну лекцію). Наприкінці ПЗ перевіряється вже при тестуванні зовнішніх функцій. На даному етапі тестування цього примітива якості може бути продовжене якщо потрібно одержати яку-небудь імовірнісну оцінку ступеня надійності ПЗ. Однак, методика такого тестування ще вимагає своєї розробки. Точність, стійкість, захищеність, тимчасова ефективність, якоюсь мірою - ефективність по пам'яті, ефективність по пристроях, розширюваність і, частково, незалежність від пристроїв можуть тестуватися. Кожний із цих видів тестування має свою специфіку й заслуговує окремого розгляду. Ми тут обмежимося лише їхнім перерахуванням. Легкість застосування ПЗ (критерій якості, що включає кілька примітивів якості, див. лекцію 4) оцінюється при тестуванні документації по застосуванню ПЗ.
Тестування документації по застосуванню ПЗ. Метою тестування є пошук непогодженості документації по застосуванню й сукупністю програм ПЗ, а також незручностей застосування ПЗ. Цей етап безпосередньо передує підключенню користувача до завершення розробки ПЗ (тестуванню вимог до ПЗ і атестації ПЗ), тому досить важливо розроблювачам спочатку самим скористатися ПЗ так, як це буде робити користувач. Всі тести на цьому етапі готуються винятково на підставі тільки документації по застосуванню ПЗ. Насамперед, повинні тестуватися можливості ПЗ, як це робилося при тестуванні зовнішніх функцій, але тільки на підставі документації по застосуванню. Повинні бути протестовані всі неясні місця в документації, а також всі приклади, використані в документації. Далі тестується найбільш важкі випадки застосування ПЗ із метою виявити порушення вимог відносності легкості застосування ПЗ.
Тестування визначення вимог до ПЗ. Метою тестування є з'ясування, якою мірою ПЗ не відповідає пред'явленому визначенню вимог до нього. Особливість цього виду тестування полягає в тім, що його здійснює організація-покупець або організація-користувач ПЗ як один зі шляхів подолання бар'єра між розроблювачем і користувачем (див. лекцію 3). Звичайно це тестування виробляється за допомогою контрольних завдань - типових задах, для яких відомий результат рішення. У тих випадках, коли розроблювальне ПЗ повинне прийти на зміну іншому варіанту ПЗ, що вирішує хоча б частина завдань розроблювального ПЗ, тестування виробляється шляхом рішення загальних завдань за допомогою як старого, так і нового ПЗ із наступним зіставленням отриманих результатів. Іноді як форма такого тестування використовують досвідчену експлуатацію ПЗ - обмежене застосування нового ПЗ із аналізом використання результатів у практичній діяльності. По-істоті, цей вид тестування багато в чому перегукується з випробуванням ПЗ при його атестації, але виконується до атестації, а іноді й замість атестації.
Лекція №3
Тема: Інтегровані засоби налагодження програмного продукту.
Мета: Призбання знань про інтегровані засоби налагодження програмних продуктів. Визначення їх призначення, переваги та недоліки.
Перелік питань, що розглядаються на лекції:
1. Інструменти розробки програмних продуктів.
2. Інструментальні середовища розробки ПЗ.
3. Інструментальні середовища програмування
