Лекція 8. Тестування і відлагодження програмного засобу
Лекція 8.Тестування і відлагодження ПЗ
1.Основні поняття тестування і відлагодження
Відлагодження ПЗ - це діяльність, направлена на виявлення і виправлення помилок в ПЗ з використанням процесів виконання його програм.
Тестування ПЗ - це процес виконання його програм на деякому наборі даних, для якого заздалегідь відомий результат застосування або відомі правила поведінки цих програм.
Вказаний набір даних називається тестовим або просто тестом. Таким чином, відладку можна представити у вигляді багатократного повторення трьох процесів: тестування, в результаті якого може бути констатоване наявність в ПЗ помилки, пошуку місця помилки в програмах і документації ПЗ і редагування програм і документації з метою усунення виявленої помилки. Іншими словами:
Відладка = Тестування + Пошук помилок + Редагування.
Узарубіжній літературі відлагодження часто розуміють тільки як процес пошуку і виправлення помилок (без тестування), факт наявності яких встановлюється при тестуванні. Іноді тестування і відладку вважають синонімами .
Унаший країні в поняття відладки зазвичай включають і тестування, тому ми слідуватимемо нашій традиції. Крім того, сумісний розгляд в даній лекції цих двох процесів робить вказане різночитання не таким істотним. Слід проте памятати, що тестування також використовується і як частина процесу атестації ПЗ.
2.Основні підходи і принципи відлагодження.
Успіх відладки в значній мірі зумовлює раціональна організація тестування. При відладці відшукуються і усуваються, в основному, ті помилки, наявність яких в ПЗ встановлюється при тестуванні. Як було вже відмічено, тестування не може довести правильність ПЗ, в кращому разі воно може продемонструвати наявність в нім помилки. Іншими словами, не можна гарантувати, що тестуванням ПЗ практично здійснимим набором тестів можна встановити наявність кожною наявною
вПЗ помилки. Тому виникає два завдання.
1.Перше завдання: підготувати такий набір тестів і застосувати до них ПЗ, щоб виявити в нім по можливості більше число помилок. Проте чим довше продовжується процес тестування (і відладки в цілому), тим більшою стає вартість ПЗ.
2.Друге завдання: визначити момент закінчення відладки ПЗ (або окремою його компоненти). Ознакою можливості закінчення відладки є повнота обхвату пропущеними через ПЗ тестами (тобто тестами, до яких застосоване ПЗ) безлічі різних ситуацій, що виникають при виконанні програм ПЗ, і відносний рідкісний прояв помилок в ПЗ на останньому відрізку процесу тестування. Останнє визначається відповідно до необхідного ступеня надійності ПЗ, вказаної в специфікації його якості.
Для оптимізації набору тестів, тобто для підготовки такого набору тестів, який дозволяв би при заданому їх числі (або при заданому інтервалі часі, відведеному на тестування) виявляти більше число помилок, необхідно:
•по-перше, заздалегідь планувати цей набір і,
•по-друге, використовувати раціональну стратегію планування (проектування ) тестів.
Проектування тестів можна починати відразу ж після завершення етапу зовнішнього опису ПЗ. Можливі різні підходи до вироблення стратегії проектування тестів, які можна умовно графічно розмістити (див. мал. 9.1) між наступними двома крайніми підходами [10.1]. Лівий крайній підхід полягає в тому, що тести проектуються тільки на підставі вивчення специфікацій ПЗ (зовнішнього опису, опису архітектури і специфікації модулів). Будова модулів при цьому ніяк не враховується, тобто вони розглядаються як чорні ящики. Фактично такий підхід вимагає повного перебору всіх наборів вхідних даних, оскільки при використанні як тести тільки частині цих наборів деякі ділянки програм ПЗ можуть не працювати ні на якому тесті і, значить, помилки, що містяться в них, не
76
Лекція 8. Тестування і відлагодження програмного засобу
виявлятимуться. Проте тестування ПЗ повним безліччю наборів вхідних даних практично нездійсненно. Правий крайній підхід полягає в тому, що тести проектуються на підставі вивчення текстів програм з метою протестувати всі шляхи виконання кожній програм ПЗ. Якщо взяти до уваги наявність в програмах циклів із змінним числом повторень, то різних шляхів виконання програм ПЗ може опинитися також надзвичайно багато, так що їх тестування також буде практично нездійсненно.
Рис. 8.1. Спектр підходів до проектування тестів.
Оптимальна стратегія проектування тестів розташована усередині інтервалу між цими крайніми підходами, але ближче до лівого краю. Вона включає проектування значної частини тестів по специфікаціях, виходячи з принципів: на кожну використовувану функцію або можливість - хоч би один тест, на кожну область і на кожну межу зміни якої-небудь вхідної величини - хоч би один тест, на кожен особливий випадок або на кожну виняткову ситуацію, вказані в специфікаціях, - хоч би один тест. Але вона вимагає також проектування деяких тестів і по текстах програм, виходячи з принципу (як мінімум): кожна команда кожної програми ПЗ повинна пропрацювати хоч би на одному тесті.
Оптимальну стратегію проектування тестів можна конкретизувати на підставі наступного принципу: для кожного програмного документа (включаючи тексти програм), що входить до складу ПЗ, повинні проектуватися свої тести з метою виявлення в нім помилок. В усякому разі, цей принцип необхідно дотримувати відповідно до визначення ПЗ і змістом поняття технології програмування як технології розробки надійних ПЗ (див. лекцію 1). У зв'язку з цим Майерс навіть визначає різні види тестування залежно від вигляду програмного документа, на підставі якого будуються тести. У наший країні розрізняються два основні види відладки (включаючи тестування): автономну і комплексну відладку. Автономна відладка означає тестування тільки якоїсь частини програми, що входить в ПЗ, з пошуком і виправленням в ній помилок, що фіксуються при тестуванні. Вона фактично включає відладку кожного модуля і відладку сполучення модулів. Комплексна відладка означає тестування ПЗ в цілому з пошуком і виправленням помилок, що фіксуються при тестуванні, у всіх документах (включаючи тексти програм ПЗ), що відносяться до ПЗ в цілому. До таких документів відносяться визначення вимог до ПЗ, специфікація якості ПЗ, функціональна специфікація ПЗ, опис архітектури ПЗ і тексти програм ПЗ.
Тестування повинне бути організоване по наступних принципах (згідно Майерсу):
1.кожен тест повинен включати опис очікуваних результатів роботи програми, щоб можна було швидко з'ясувати наявність або відсутність помилок в ній;
2.бажано, щоб окрім автора тестування проводили і інші спеціалісти, оскільки виявлення недоліків в своїй діяльності протирічить людській психології. Однак, відладка програми найефективніше виконується саме автором програми;
3.організація-розробник програмного забезпечення не повинна "одноосібно" тестувати ПП, потрібно організовувати бета-тестування з залученням інших організацій;
4.результати кожного тесту повинні бути документовані і детально вивчені, щоб не пропустити малопомітну на перший погляд помилку в програмі;
5.тести для неправильних (непередбачуваних) даних повинні підбиратися так само ретельно, як і для правильних (передбачуваних) вхідних даних;
6.при аналізі результатів кожного тесту необхідно перевіряти, чи не робить програма того, що вона не повинна робити;
7.слід зберігати використані тести (для підвищення ефективності повторного тестування програми після її модифікації або установки у замовника);
77
Лекція 8. Тестування і відлагодження програмного засобу
8.тестування не повинно плануватися виходячи з припущення, що в програмі не будуть виявлені помилки (зокрема, слід виділяти на тестування достатньо часових і матеріальних ресурсів);
9.слід враховувати так званий "принцип накопичення помилок": вірогідність наявності не виявлених помилок в деякій частині програми прямо пропорційна числу помилок, вже виявлених в цій частині;
10.слід завжди пам'ятати, що тестування - творчий процес, і не відноситися до нього як до рутинного заняття.
•Заповіді відлагодження.
Слід зазначити деякий феномен, який підтверджує важливість усунення помилок на попередніх етапах розробки: в міру зростання числа виявлених і виправлених помилок в ПЗ також росте відносна вірогідність існування невиявлених помилок. Це пояснюється тим, що при зростанні числа помилок, виявлених в ПЗ, уточнюється і наше уявлення про загальне число допущених у ньому помилок, а значить, в якійсь мірі, і про число невиявлених ще помилок. Цей феномен підтверджує важливість раннього виявлення помилок і необхідність ретельного контролю ухвалюваних рішень на кожному етапі розробки ПЗ.
Принципи організації процесу відладки (у формі заповідей).
Заповідь 1. вважайте тестування ключовим завданням в розробці ПЗ, доручайте його лише найбільш кваліфікованим і обдарованим програмістам.
Заповідь 2. Хороший той тест, для якого висока вірогідність виявити помилку, а не той, який демонструє правильну роботу програми.
Заповідь 3. Готуйте тести як для правильних, так і для неправильних даних.
Заповідь 4. Уникайте невідтворних тестів, документуйте їх проходження через комп'ютер, детально вивчайте результати кожного тесту.
Заповідь 5. Кожен модуль підключайте до програми тільки один раз – ніколи не змінюйте програму, щоб полегшити її тестування.
Заповідь 6. Проводьте заново всі тести, пов'язані з перевіркою роботи якої-небудь програми, ПЗ або її взаємодії з іншими програмами, якщо до неї були внесені зміни (наприклад, в результаті усунення помилок).
По ступеню обхвату проекту розрізняють:
•автономне відлагодження
•проміжне відлагодження
•комплексне відлагодження
• Автономна відладка модулів
При автономній відладці кожен модуль насправді тестується в деякому програмному оточенні, крім випадку, коли відладжувана програма складається тільки з одного модуля. Це оточення складається з інших модулів, частина яких є модулями відладжуваної програми, які вже відладжені, а частина - модулями, керівниками відладкою (налагоджувальними модулями, див. нижчий). Таким чином, при автономній відладці тестується завжди деяка програма, побудована спеціально для тестування відладжуваного модуля. Ця програма лише частково співпадає з відладжуваною програмою, крім випадку, коли відладжується останній модуль відладжуваної програми. У міру просування відладки програми все велику частину оточення чергового відладжуваного модуля складатимуть вже відладжені модулі цієї програми, а при відладці останнього модуля цієї програми оточення відладжуваного модуля буде цілком складатися з решти (вже відладжених) всіх модулів відладжуваної програми (без яких-небудь) налагоджувальних модулів, тобто в цьому випадку тестуватися буде сама відладжувана програма. Такий процес нарощування відладжуваної програми відладженими і відладжуваними модулями називається інтеграцією програми.
Налагоджувальні модулі, що входять в оточення відладжуваного модуля, залежать від порядку, в якому відладжуються модулі цієї програми, від того, який модуль відладжується і, можливо, від того, який тест пропускатиметься.
78
Лекція 8. Тестування і відлагодження програмного засобу
Автономне тестування модуля доцільно здійснювати в чотири послідовних кроки:
•Крок 1. На підставі специфікації відладжуваного модуля підготуйте тест для кожної можливості і кожної ситуації, для кожної межі областей допустимих значень всіх вхідних даних, для кожної області зміни даних, для кожної області неприпустимих значень всіх вхідних даних і кожної неприпустимої умови.
•Крок 2. Перевірте текст модуля, щоб переконатися, що кожен напрям будь-якого розгалуження буде пройдений хоч би на одному тесті. Додайте бракуючі тести.
•Крок 3. Переконаєтеся по тексту модуля, що для кожного циклу існує тест, для якого тіло циклу не виконується, тест, для якого тіло циклу виконується один раз, і тест, для якого тіло циклу виконується максимальне число разів. Додайте бракуючі тести.
•Крок 4. Перевірте по тексту модуля його чутливість до окремих особливих значень вхідних даних - всі такі значення повинні входити в тести. Додайте бракуючі тести.
• Проміжна відладка програмного засобу
Коли декілька компонент зв'язані між собою даними складного формату, то провести ізольоване (автономне) тестування буде досить важко. Тоді тест будується для деякої множини компонент (модулів) і перевіряється результат роботи всього такого комплексу.
Іншою причиною проведення проміжного відлагодження є необхідність тестування сполучення модулів. Річ у тому, що специфікація кожного модуля програми, окрім головного, використовується в програмі в двох ситуаціях: по-перше, при розробці тексту (іноді говорять: тіла) цього модуля і, по-друге, при написанні звернення до цього модуля в інших модулях програми. В обох випадках в результаті помилки може бути порушена необхідна відповідність заданій специфікації модуля. Такі помилки потрібно виявляти і усувати. Для цього і призначено проміжне тестування сполучення модулів.
При низхідному тестуванні тестування сполучення здійснюється попутно кожним тестом, що пропускається, що вважають найсильнішою гідністю низхідного тестування. При висхідному тестуванні звернення до відладжуваного модуля проводиться не з модулів відладжуваної програми, а з провідного налагоджувального модуля. У зв'язку з цим існує небезпека, що останній модуль може пристосуватися до деяких "помилок" відладжуваного модуля. Тому приступаючи (в процесі інтеграції програми) до відладки нового модуля доводиться тестувати кожне звернення до раніше відладженого модуля з метою виявлення неузгодженості цього поводження з тілом відповідного модуля (і не виключено, що винен в цьому раніше відладжений модуль). Таким чином, доводиться частково повторювати в нових умовах тестування раніше відладженого модуля, при цьому виникають ті ж труднощі, що і при низхідному тестуванні.
•Комплексна відладка програмного засобу.
Як вже було сказано вище, при комплексній відладці тестується ПЗ в цілому, причому тести готуються по кожному з документів ПЗ [10.8]. Тестування цих документів проводиться, як правило, в порядку, зворотному їх розробці (виключення складає лише тестування документації по застосуванню, яка розробляється по зовнішньому опису паралельно з розробкою текстів програм; це тестування краще проводити після завершення тестування зовнішнього опису). Тестування при комплексній відладці є застосуванням ПЗ до конкретних даних, які в принципі можуть виникнути у користувача (зокрема, всі тести готуються у формі, розрахованій на користувача), але, можливо, в модельованому (а не в реальній) середовищі. Наприклад, деякі недоступні при комплексній відладці пристрої введення і виводу можуть бути замінені їх програмними імітаторами.
Тестування архітектури ПЗ. Метою тестування є пошук невідповідності між описом архітектури і сукупністю програм ПЗ. До моменту почала тестування архітектури ПЗ повинна бути вже закінчена автономна відладка кожної підсистеми. Помилки реалізації архітектури можуть бути пов'язані перш за все з взаємодією цих підсистем, зокрема, з реалізацією архітектурних функцій (якщо вони є). Тому хотілося б перевірити всі шляхи взаємодії між підсистемами ПЗ. Але оскільки їх може бути дуже багато, то бажано б протестувати хоч би всі ланцюжки виконання підсистем без повторного
79