Автономне налагодження модуля
Заповіді налагодження.
У цьому розділі надаються загальні рекомендації щодо організації налагодження. Але спочатку слід зазначити деякий феномен [10.1], який підтверджує важливість попередження помилок на попередніх етапах розробки: зі зростанням кількості виявлених та виправлених помилок у ПС зростає також відносна ймовірність існування в ньому невиявлених помилок. Це пояснюється тим, що при зростанні числа помилок, виявлених у ПС, уточнюється і наше уявлення про загальну кількість допущених у ньому помилок, а значить, певною мірою, і про кількість невиявлених помилок. Цей феномен підтверджує важливість раннього виявлення помилок та необхідність ретельного контролю прийнятих рішень на кожному етапі розробки ПС.
Нижче наводяться рекомендації щодо організації налагодження у формі заповідей [10.1, 10.8].
Заповідь 1. Вважайте тестування ключовим завданням розробки ПС, доручайте його кваліфікованим та обдарованим програмістам; небажано тестувати свою програму.
Заповідь 2. Хороший тест, для якого висока ймовірність виявити помилку, а не той, який демонструє правильну роботу програми.
Заповідь 3. Готуйте тести для правильних і неправильних даних.
Заповідь 4. Уникайте невідтворюваних тестів, документуйте їх пропуск через комп'ютер; детально вивчайте результати кожного тесту.
Заповідь 5. Кожен модуль підключайте до програми лише один раз; ніколи не змінюйте програму, щоб полегшити її тестування.
Заповідь 6. Пропускайте знову всі тести, пов'язані з перевіркою роботи будь-якої програми ПС або її взаємодії з іншими програмами, якщо в неї були внесені зміни (наприклад, внаслідок усунення помилки).
При автономному налагодженні кожен модуль насправді тестується в деякому програмному оточенні, крім випадку, коли програма, що налагоджується, складається тільки з одного модуля. Це оточення складається [10.8] з інших модулів, частина яких є модулями налагоджуваної програми, які вже налагоджені, а частина - модулями, що керують налагодженням (налагоджувальними модулями, див. нижче). Таким чином, при автономному налагодженні тестується завжди деяка програма, побудована спеціально для тестування модуля, що відладжується. Ця програма лише частково збігається з програмою, що налагоджується, крім випадку, коли налагоджується останній модуль програми, що відладжується. У міру просування налагодження програми все більшу частину оточення чергового модуля, що налагоджується, будуть складати вже налагоджені модулі цієї програми, а при налагодженні останнього модуля цієї програми оточення модуля, що налагоджується, буде повністю складатися з усіх інших (вже налагоджених) модулів налагоджувальної програми (без будь-яких) модулів, тобто. у цьому випадку тестуватиметься сама програма, що налагоджується. Такий процес нарощування програми, що відладжується, налагодженими і налагоджуваними модулями називається інтеграцією програми [10.1].
Налагоджувальні модулі, що входять в оточення модуля, залежать від порядку, в якому налагоджуються модулі цієї програми, від того, який модуль налагоджується і, можливо, від того, який тест буде пропускатися.
При висхідному тестуванні (див. лекцію 7) це оточення завжди міститиме лише один налагоджувальний модуль (крім випадку, коли налагоджується останній модуль програми, що налагоджується), який буде головним у тестованій програмі і який називають ведучим (або драйвером [10.1]). Провідний модуль налагодження готує інформаційне середовище длятестування модуля, що відладжується (тобто формує її стан, необхідне для тестування цього модуля, зокрема, може здійснювати введення деяких тестових даних), здійснює звернення до модуля, що налагоджується, і після закінчення його роботи видає необхідні повідомлення. При налагодженні одного модуля для різних тестів можуть складатися різні провідні модулі налагодження.
При низхідному тестуванні (див. лекцію 7) оточення модуля, що відладжується, як налагоджувальні модулі містить імітатори всіх модулів, до яких може звертатися налагоджуваний модуль, а також імітатори тих модулів, до яких можуть звертатися налагоджені модулі налагоджуваної програми (включені в це оточення), але які ще не налагоджені. Деякі з цих імітаторів при налагодженні одного модуля можуть бути змінені для різних тестів.
Насправді в оточенні модуля, що відладжується в багатьох випадках можуть утримуватися налагоджувальні модулі обох типів з нижче наступних міркувань. Як висхідне, і низхідне тестування має свої переваги і недоліки.
До переваг висхідного тестування відносяться
простота підготовки тестів та
можливість повної реалізації плану тестування модуля
Це пов'язано з тим, що тестовий стан інформаційного середовища готується безпосередньо перед зверненням до модуля, що відладжується (провідним налагоджувальним модулем). Недоліками висхідного тестування є такі його особливості:
тестові дані готуються, як правило, не в тій формі, яка розрахована на користувача (крім випадку, коли налагоджується останній, головний, модуль програм, що налагоджується);
великий обсяг налагоджувального програмування (при налагодженні одного модуля часто доводиться складати для різних тестів багато провідних модулів налагодження);
необхідність спеціального тестування сполучення модулів.
До переваг низхідного тестування належать такі його особливості:
більшість тестів готується у формі, розрахованій на користувача;
у багатьох випадках відносно невеликий обсяг налагоджувального програмування (імітатори модулів, як правило, дуже прості і кожен придатний для великої кількості, нерідко – для всіх, тестів);
відпадає необхідність тестування сполучення модулів.
Недоліком низхідного тестування є те, що тестовий стан інформаційного середовища перед зверненням до модуля, що налагоджується, готується побічно - воно є результатом застосування вже налагоджених модулів до тестових даних або даних, що видаються імітаторами. Це, по-перше, ускладнює підготовку тестів, вимагає високої кваліфікації виконавця-тестовика, а по-друге, утруднює або навіть неможливе реалізацію повного плану тестування модуля, що відладжується. Зазначений недолік іноді змушує розробників застосовувати висхідне тестування навіть у разі низхідної розробки. Однак частіше застосовують деякі модифікації низхідного тестування, або деяку комбінацію низхідного та висхідного тестування.
Виходячи з того, що низхідне тестування, в принципі, є кращим, зупинимося на прийомах, що дозволяють певною мірою подолати зазначені труднощі. Насамперед необхідно організувати налагодження програми таким чином, щоб якомога раніше були налагоджені модулі, які здійснюють введення даних, - тоді тестові дані можна готувати у формі, розрахованій на користувача, що спростить підготовку наступних тестів. Далеко не завжди це введення здійснюється в головному модулі, тому доводиться в першу чергуналагоджувати ланцюжки модулів, що ведуть до модулів, що здійснюють зазначене введення (пор. з методом цілеспрямованої конструктивної реалізації в лекції 7). Поки модулі, що здійснюють введення даних, не налагоджені, тестові дані поставляються деякими імітаторами: вони включаються до імітатора як його частина, або вводяться цим імітатором.
При низхідному тестуванні деякі стани інформаційного середовища, при яких потрібно тестувати модуль, що налагоджується, можуть не виникати при виконанні налагоджуваної програми ні при яких вхідних даних. У цих випадках можна було б взагалі не тестувати модуль, що налагоджується, так як виявляються при цьому помилки не будуть проявлятися при виконанні програми, що відладжується, ні при яких вхідних даних. Однак так чинити не рекомендується, тому що при змінах програми, що налагоджується (наприклад, при супроводі ПС) не використані для тестування налагоджуваного модуля стану інформаційного середовища можуть вже виникати, що вимагає додаткового тестування цього модуля (а цього при раціональній організації налагодження можна було б не робити , якщо сам модуль не змінювався). Для здійснення тестування модуля, що налагоджується, в зазначених ситуаціях іноді використовують підходящі імітатори, щоб створити необхідний стан інформаційного середовища. Найчастіше користуються модифікованим варіантом низхідного тестування, при якому модулі, що налагоджуються, перед їх інтеграцією попередньо тестуються окремо (у цьому випадку в оточенні модуля, що налагоджується, з'являється провідний налагоджувальний модуль, поряд з імітаторами модулів, до яких може звертатися налагоджуваний модуль). Однак, більш доцільною є інша модифікація низхідного тестування: після завершення низхідного тестування налагоджуваного модуля длядосяжних тестових станів інформаційного середовища слід окремо протестувати й інших необхідних станів інформаційного середовища.
Часто застосовують також комбінацію висхідного та низхідного тестування, яку називають методом сандвіча [10.1]. Сутність цього методу полягає в одночасному здійсненні як висхідного, так і низхідного тестування, поки ці два процеси тестування не зустрінуться на якому-небудь модулі десь у середині структури програми, що відладжується. Цей метод дозволяє при розумному підході скористатися перевагами як висхідного, так і низхідного тестування та значною мірою нейтралізувати їх недоліки. Цей ефект є проявом більш загального принципу: найбільшого технологічного ефекту можна досягти, поєднуючи низхідні та висхідні методи розробки програм ПС. Саме для підтримки цього методу і призначений архітектурний підхід до розробки програм (див. лекцію 7): шар кваліфіковано розроблених та ретельно відтестованих модулів суттєво полегшує реалізацію сімейства програм у відповідній предметній галузі та їх подальшу модернізацію.
Дуже важливим при автономному налагодженні є тестування модулів сполучення. Справа в тому, що специфікація кожного модуля програми, крім головного, використовується в цій програмі у двох ситуаціях: по-перше, при розробці тексту (іноді говорять: тіла) цього модуля і, по-друге, при написанні звернення до цього модуля в інших модулі програми. І в тому, і в іншому випадку в результаті помилки може бути порушена відповідність заданої специфікації модуля. Такі помилки потрібно виявляти та усувати. Для цього і призначено тестування сполучення модулів. При низхідному тестуванні тестування сполучення здійснюєтьсяпопутно кожним тестом, що пропускається, що вважають найсильнішим гідністю низхідного тестування. При висхідному тестуванні звернення до модуля, що налагоджується, проводиться не з модулів налагоджуваної програми, а з провідного налагоджувального модуля. У зв'язку з цим існує небезпека, що останній модуль може пристосуватися до деяких "помилок" модуля, що відладжується. Тому, приступаючи (у процесі інтеграції програми) до налагодження нового модуля доводиться тестувати кожне звернення до раніше налагодженого модуля з метою виявлення неузгодженості цього поводження з тілом відповідного модуля (і не виключено, що винен у цьому раніше налагоджений модуль). Таким чином, доводиться частково повторювати в нових умовах тестування раніше налагодженого модуля, при цьому виникають ті ж труднощі, що при низхідному тестуванні.
Автономне тестування модуля доцільно здійснювати чотири послідовно виконуваних кроку [10.1].
Крок 1. На підставі специфікації модуля, що налагоджується, підготуйте тест для кожної можливості і кожної ситуації, для кожної межі областей допустимих значень всіх вхідних даних, для кожної області зміни даних, для кожної області недопустимих значень всіх вхідних даних і кожної недопустимої умови.
Крок 2. Перевірте текст модуля, щоб переконатися, що кожен напрямок будь-якого розгалуження буде пройдено хоча б на одному тесті. Додайте відсутні тести.
Крок 3. Переконайтеся, що для кожного циклу існує тест, для якого тіло циклу не виконується, тест, для якого тіло циклу виконується один раз, і тест, для якого тіло циклу виконується максимальне число разів. Додайте відсутні тести.
Крок 4. Перевірте за текстом модуля його чутливість до окремих спеціальнихзначення вхідних даних - всі такі значення повинні входити в тести. Додайте відсутні тести.