Реферат Проектування процесу тестування програмного забезпечення

Предмет дослідження: тестування програмного забезпечення.

Тип даного дослідження: розробка.

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

На малюнку 1 показана схема двоетапного процесу тестування. На етапі покомпонентного тестування перевіряються окремі компоненти. Це можуть бути функції, набори методів, зібрані в один модуль, або об'єкти. На етапі тестування зборки ці компоненти інтегруються в підсистеми або закінчену систему. На цьому етапі основна увага приділяється тестуванню взаємодій між компонентами, а також показниками функціональності і продуктивності системи як єдиного цілого. Але, звичайно, на етапі тестування збірки також можуть виявлятися помилки в окремих компонентах, не помічені на етапі покомпонентного тестування [1,2].

Рисунок 1 - Етапи тестування ПО

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

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

При розробці некритичних, "звичайних" систем докладні специфікації для кожного системного компонента, як правило, не створюються. Визначаються тільки інтерфейси компонентів, причому за проектування, розробку і тестування цих компонентів несуть відповідальність окремі програмісти або групи програмістів. Таким чином, тестування компонентів, як правило, грунтується тільки на розумінні розробниками того, що повинен робити компонент [1,2].

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

Під багатьох книгах, присвячених тестування програмного забезпечення, наприклад [1], описується процес тестування програмних систем, що реалізують функціональну модель ПО, але не розглядається окремо тестування об'єктно-орієнтованих систем. У контексті тестування між об'єктно-орієнтованими і функціонально-орієнтованими системами є ряд відмінностей.

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

2. В об'єктно-орієнтованих системах, як правило, немає такої чіткої ієрархії об'єктів, як у функціонально-орієнтованих системах. Тому такі методи інтеграції систем, як спадна або висхідна збірка (1.5), часто не підходять для об'єктно-орієнтованих систем [1,3].

Таким чином, в об'єктно-орієнтованих системах між тестуванням компонентів і тестуванням збірки немає чітких меж. У таких системах процес тестування є продовженням процесу розробки, де основною системною структурою є об'єкти. Незважаючи на те, що більша частина методів тестування підходить для систем будь-яких видів, для тестування об'єктно-орієнтованих систем необхідні спеціальні методи. Такі методи розглянуті в розділі 2 [1,2].

Метою тестування дефектів є виявлення в програмній системі прихованих дефектів до того, як вона буде здана замовникові. Тестування дефектів протилежно атестації, в ході якої перевіряється відповідність системи своїй специфікації. Під час атестації система повинна коректно працювати з усіма заданими тестовими даними. При тестуванні дефектів запускається такий тест, який викликає некоректну роботу програми і, отже, виявляє дефект. Зверніть увагу на цю важливу особливість: тестування дефектів демонструє наявність, а не відсутність дефектів у програмі [2].

Загальна модель процесу тестування дефектів показана на малюнку 2 Тестові сценарії - це специфікації вхідних тестових даних і очікуваних вихідних даних плюс опис процедури тестування. Тестові дані іноді генеруються автоматично. Автоматична генерація тестових сценаріїв неможлива, оскільки результати проведення тесту не завжди можна передбачити заздалегідь.

Малюнок 2 - Процес тестування дефектів

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

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

1.2 Тестування методом чорного ящика

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