Автономна відладка програмного засобу.

Заповіді відладки програмного засобу.

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

Нижче приводяться рекомендації по організації відладки у формі заповідей [10.1, 10.8].

Заповідь 1. Рахуйте тестування ключовим завданням розробки ПС, доручайте його найкваліфікованішим і обдарованішим програмістам; небажано тестувати свою власну програму.

Заповідь 2. Хороший той тест, для якого висока вірогідність виявити помилку, а не той, який демонструє правильну роботу програми.

Заповідь 3. Готуйте тести як для правильних, так і для неправильних даних.

Заповідь 4. Документуйте пропуск тестів через комп'ютер; детально вивчайте результати кожного тесту; уникайте тестів, пропуск яких не можна повторити.

Заповідь 5. Кожен модуль підключайте до програми тільки один раз; ніколи не змінюйте програму, щоб полегшити її тестування.

Заповідь 6. Пропускайте наново всі тести, пов'язані з перевіркою роботи якої-небудь програми ПС або її взаємодії з іншими програмами, якщо до неї були внесені зміни (наприклад, в результаті усунення помилки).

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

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

При низхідному тестуванні (див. лекцію 7) оточення відладжуваного модуля як налагоджувальні модулі містить налагоджувальні імітатори (заглушки) деяких ще не відладжених модулів. До таких модулів відносяться, перш за все, всі модулі, до яких може звертатися відладжуваний модуль, а також ще не відладжені модулі, до яких можуть звертатися вже відладжені модулі (включені в це оточення). Деякі з цих імітаторів при відладці одного модуля можуть змінюватися для різних тестів.

На практиці в оточенні відладжуваного модуля можуть міститися налагоджувальні модулі обох типів, якщо використовується змішана стратегія тестування. Це пов'язано з тим, що як висхідне, так і низхідне тестування має свої достоїнства і свої недоліки.

До достоїнств висхідного тестування відносяться:

· простота підготовки тестів

· можливість повної реалізації плану тестування модуля.

Це пов'язано з тим, що тестовий стан інформаційного середовища готується безпосередньо перед зверненням до відладжуваного модуля (провідним налагоджувальним модулем).

Недоліками висхідного тестування є наступні його особливості:

· тестові дані готуються, як правило, не в тій формі, яка розрахована на користувача (крім випадку, коли відладжується останній, головний, модуль відладжуваної програм);

· великий об'єм налагоджувального програмування (при відладці одного модуля доводиться складати багато провідних налагоджувальних модулів, що формують відповідний стан інформаційного середовища для різних тестів);

· необхідність спеціального тестування сполучення модулів.

До достоїнств низхідного тестування відносяться наступні його особливості:

· більшість тестів готуються у формі, розрахованій на користувача;

· у багатьох випадках відносно невеликий об'єм налагоджувального програмування (імітатори модулів, як правило, вельми прості і кожен придатний для великого числа, нерідко -для всіх, тестів);

· відпадає необхідність тестування сполучення модулів.

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

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

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

Часто застосовують також комбінацію висхідного і низхідного тестування, яку називають методом сандвіча [10.1]. Суть цього методу полягає в одночасному здійсненні як висхідного, так і низхідного тестування, поки ці два процеси тестування не зустрінуться на якому-небудь модулі десь в середині структури відладжуваної програми. Цей метод при розумному порядку тестування дозволяє скористатися достоїнствами як висхідного, так і низхідного тестування, а також в значній мірі нейтралізувати їх недоліки.

Вельми важливим при автономній відладці є тестування

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

Автономне тестування модуля доцільно здійснювати в чотири послідовно виконуваних кроку [10.1].

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

Крок 2. Перевірте текст модуля, щоб переконатися, що кожен напрям будь-якого розгалуження буде пройдений хоч би на одному тесті. Додайте бракуючі тести.

Крок 3. Перевірте текст модуля, щоб переконатися, що для кожного циклу існують тести, що забезпечують, принаймні, три наступні ситуації: тіло циклу не виконується жодного разу, тіло циклу виконується один раз і тіло циклу виконується максимальне число разів. Додайте бракуючі тести.

Крок 4. Перевірте текст модуля, щоб переконатися, що існують тести, перевіряючі чутливість до окремих особливих значень вхідних даних. Додайте бракуючі тести.