ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 26.11.2019
Просмотров: 261
Скачиваний: 1
Лише та - помилка, що не виправляється.
Конфуцій
Лекція 10.
ТЕСТУВАННЯ І ВІДЛАДКА ПРОГРАМНОГО ЗАСОБУ
Основні поняття. Стратегія проектування тестів. Заповіді відладки. Автономна відладка і тестування програмного модуля. Комплексна відладка і тестування програмного засобу.
10.1. Основні поняття.
Відладка ПС це діяльність, направлена на виявлення і виправлення помилок в ПС з використанням процесів виконання його програм. Тестування ПС це процес виконання його програм на деякому наборі даних, для якого заздалегідь відомий результат застосування або відомі правила поведінки цих програм. Вказаний набір даних називається тестовим або просто тестом. Таким чином, відладку можна представити у вигляді багатократного повторення трьох процесів: тестування, в результаті якого може бути констатоване наявність в ПС помилки, пошуку місця помилки в програмах і документації ПС і редагування програм і документації з метою усунення виявленої помилки. Іншими словами:
Відладка = Тестування + Пошук помилок + Редагування.
У зарубіжній літературі відладку часто розуміють [10.1-10.3] тільки як процес пошуку і виправлення помилок (без тестування), факт наявності яких встановлюється при тестуванні. Іноді тестування і відладку вважають синонімами [10.4,10.5]. У наший країні в поняття відладки зазвичай включають і тестування [10.6 -10.8], тому ми слідуватимемо традиції, що склалася. Втім, сумісний розгляд в даній лекції цих процесів робить вказане різночитання не таким істотним. Слідує, проте, відзначити, що тестування використовується і як частина процесу атестації ПС (див. лекцію 14).
10.2. Принципи і види відладки програмного засобу.
Успіх відладки ПС в значній мірі зумовлює раціональна організація тестування. При відладці ПС відшукуються і усуваються, в основному, ті помилки, наявність яких в ПС встановлюється при тестуванні. Як було вже відмічено, тестування не може довести правильність ПС [10.9], в кращому разі воно може продемонструвати наявність в нім помилки. Іншими словами, не можна гарантувати, що тестуванням ПС практично здійснимим набором тестів можна встановити наявність кожною наявною в ПС помилки. Тому виникає два завдання. Перше завдання: підготувати такий набір тестів і застосувати до них ПС, щоб виявити в нім по можливості більше число помилок. Проте чим довше продовжується процес тестування (і відладки в цілому), тим більшою стає вартість ПС. Звідси друге завдання: визначити момент закінчення відладки ПС (або окремою його компоненти). Ознакою можливості закінчення відладки є повнота обхвату пропущеними через ПС тестами (тобто тестами, до яких застосоване ПС) безлічі різних ситуацій, що виникають при виконанні програм ПС, і відносний рідкісний прояв помилок в ПС на останньому відрізку процесу тестування. Останнє визначається відповідно до необхідного ступеня надійності ПС, вказаної в специфікації його якості.
Для оптимізації набору тестів, тобто для підготовки такого набору тестів, який дозволяв би при заданому їх числі (або при заданому інтервалі часі, відведеному на тестування) виявляти більше число помилок в ПС, необхідно, по-перше, заздалегідь планувати цей набір і, по-друге, використовувати раціональну стратегію планування (проектування [10.1]) тестів. Проектування тестів можна починати відразу ж після завершення етапу зовнішнього опису ПС. Можливі різні підходи до вироблення стратегії проектування тестів, які можна умовно графічно розмістити (див. мал. 9.1) між наступними двома крайніми підходами [10.1]. Лівий крайній підхід полягає в тому, що тести проектуються тільки на підставі вивчення специфікацій ПС (зовнішнього опису, опису архітектури і специфікації модулів). Будова модулів при цьому ніяк не враховується, тобто вони розглядаються як чорні ящики. Фактично такий підхід вимагає повного перебору всіх наборів вхідних даних, оскільки інакше деякі ділянки програм ПС можуть не працювати при пропуску будь-якого тесту, а це означає, що помилки, що містяться в них, не виявлятимуться. Проте тестування ПС повним безліччю наборів вхідних даних практично нездійсненно. Правий крайній підхід полягає в тому, що тести проектуються на підставі вивчення текстів програм з метою протестувати всі шляхи виконання кожній програм ПС. Якщо взяти до уваги наявність в програмах циклів із змінним числом повторень, то різних шляхів виконання програм ПС може опинитися також надзвичайно багато, так що їх тестування також буде практично нездійсненно.
Мал. 10.1. Спектр підходів до проектування тестів.
Оптимальна стратегія проектування тестів розташована усередині інтервалу між цими крайніми підходами, але ближче до лівого краю. Вона включає проектування значної частини тестів по специфікаціях, але вона вимагає також проектування деяких тестів і по текстах програм. При цьому в першому випадку ця стратегія базується на принципах:
-
на кожну використовувану функцію або можливість хоч би один тест
-
на кожну область і на кожну межу зміни якої-небудь вхідної величини хоч би один тест
-
на кожну особливу (виняткову) ситуацію, вказану в специфікаціях, хоч би один тест.
У другому випадку ця стратегія базується на принципі: кожна команда кожної програми ПС повинна пропрацювати хоч би на одному тесті.
Оптимальну стратегію проектування тестів можна конкретизувати на підставі наступного принципу: для кожного програмного документа (включаючи тексти програм), що входить до складу ПС, повинні проектуватися свої тести з метою виявлення в нім помилок. В усякому разі, цей принцип необхідно дотримувати відповідно до визначення ПС і змістом поняття технології програмування як технології розробки надійних ПС (див. лекцію 1). У зв'язку з цим Майерс навіть визначає різні види тестування [10.1] залежно від вигляду програмного документа, на підставі якого будуються тести. У наший країні розрізняються [10.8] два основні види відладки (включаючи тестування): автономну і комплексну відладку ПС. Автономна відладка ПС означає послідовне роздільне тестування різних частин програм, що входять в ПС, з пошуком і виправленням в них помилок, що фіксуються при тестуванні. Вона фактично включає відладку кожного програмного модуля і відладку сполучення модулів. Комплексна відладка означає тестування ПС в цілому з пошуком і виправленням помилок, що фіксуються при тестуванні, у всіх документах (включаючи тексти програм ПС), що відносяться до ПС в цілому. До таких документів відносяться визначення вимог до ПС, специфікація якості ПС, функціональна специфікація ПС, опис архітектури ПС і тексти програм ПС.
10.3. Заповіді відладки програмного засобу.
У цьому розділі даються загальні рекомендації по організації відладки ПС. Але спочатку слід зазначити деякий феномен [10.1], який підтверджує важливість попередження помилок на попередніх етапах розробки: у міру зростання числа виявлених і виправлених помилок в ПС росте також відносна вірогідність існування в нім невиявлених помилок. Це пояснюється тим, що при зростанні числа помилок, виявлених в ПС, уточнюється і наше уявлення про загальне число допущених в нім помилок, а значить, в якійсь мірі, і про число невиявлених ще помилок.
Нижче приводяться рекомендації по організації відладки у формі заповідей [10.1, 10.8].
Заповідь 1. Рахуйте тестування ключовим завданням розробки ПС, доручайте його найкваліфікованішим і обдарованішим програмістам; небажано тестувати свою власну програму.
Заповідь 2. Хороший той тест, для якого висока вірогідність виявити помилку, а не той, який демонструє правильну роботу програми.
Заповідь 3. Готуйте тести як для правильних, так і для неправильних даних.
Заповідь 4. Документуйте пропуск тестів через комп'ютер; детально вивчайте результати кожного тесту; уникайте тестів, пропуск яких не можна повторити.
Заповідь 5. Кожен модуль підключайте до програми тільки один раз; ніколи не змінюйте програму, щоб полегшити її тестування.
Заповідь 6. Пропускайте наново всі тести, пов'язані з перевіркою роботи якої-небудь програми ПС або її взаємодії з іншими програмами, якщо до неї були внесені зміни (наприклад, в результаті усунення помилки).
10.4. Автономна відладка програмного засобу.
При автономній відладці ПС кожен модуль насправді тестується в деякому програмному оточенні, крім випадку, коли відладжувана програма складається тільки з одного модуля. Це оточення складається [10.8] з інших модулів, частина яких є модулями відладжуваної програми, які вже відладжені, а частина модулями, керівниками відладкою (налагоджувальними модулями, див. нижчий). Таким чином, при автономній відладці тестується завжди деяка програма (тестована програма), побудована спеціально для тестування відладжуваного модуля. Ця програма лише частково співпадає з відладжуваною програмою, крім випадку, коли відладжується останній модуль відладжуваної програми. В процесі автономної відладки ПС проводиться нарощування тестованої програми відладженими модулями: при переході до відладки наступного модуля в його програмне оточення додається останній відладжений модуль. Такий процес нарощування програмного оточення відладженими модулями називається інтеграцією програми [10.1]. Налагоджувальні модулі, що входять в оточення відладжуваного модуля, залежать від порядку, в якому відладжуються модулі цієї програми, від того, який модуль відладжується і, можливо, від того, який тест пропускатиметься.
При висхідному тестуванні (див. лекцію 7) це оточення міститиме тільки один налагоджувальний модуль (крім випадку, коли відладжується останній модуль відладжуваної програми), який буде головним в тестованій програмі. Такий налагоджувальний модуль називають таким, що веде (або драйвером [10.1]). Провідний налагоджувальний модуль готує інформаційне середовище для тестування відладжуваного модуля (тобто формує її стан, потрібний для тестування цього модуля, зокрема, шляхом введення деяких тестових даних), здійснює звернення до відладжуваного модуля і після закінчення його роботи видає необхідні повідомлення. При відладці одного модуля для різних тестів можуть складатися різні провідні налагоджувальні модулі.
При низхідному тестуванні (див. лекцію 7) оточення відладжуваного модуля як налагоджувальні модулі містить налагоджувальні імітатори (заглушки) деяких ще не відладжених модулів. До таких модулів відносяться, перш за все, всі модулі, до яких може звертатися відладжуваний модуль, а також ще не відладжені модулі, до яких можуть звертатися вже відладжені модулі (включені в це оточення). Деякі з цих імітаторів при відладці одного модуля можуть змінюватися для різних тестів.
На практиці в оточенні відладжуваного модуля можуть міститися налагоджувальні модулі обох типів, якщо використовується змішана стратегія тестування. Це пов'язано з тим, що як висхідне, так і низхідне тестування має свої достоїнства і свої недоліки.
До достоїнств висхідного тестування відносяться:
-
простота підготовки тестів
-
можливість повної реалізації плану тестування модуля.
Це пов'язано з тим, що тестовий стан інформаційного середовища готується безпосередньо перед зверненням до відладжуваного модуля (провідним налагоджувальним модулем).
Недоліками висхідного тестування є наступні його особливості:
-
тестові дані готуються, як правило, не в тій формі, яка розрахована на користувача (крім випадку, коли відладжується останній, головний, модуль відладжуваної програм);
-
великий об'єм налагоджувального програмування (при відладці одного модуля доводиться складати багато провідних налагоджувальних модулів, що формують відповідний стан інформаційного середовища для різних тестів);
-
необхідність спеціального тестування сполучення модулів.
До достоїнств низхідного тестування відносяться наступні його особливості:
-
більшість тестів готуються у формі, розрахованій на користувача;
-
у багатьох випадках відносно невеликий об'єм налагоджувального програмування (імітатори модулів, як правило, вельми прості і кожен придатний для великого числа, нерідко для всіх, тестів);
-
відпадає необхідність тестування сполучення модулів.
Недоліком низхідного тестування є те, що тестовий стан інформаційного середовища перед зверненням до відладжуваного модуля готується побічно воно є результатом застосування вже відладжених модулів до тестових даних або даних, що видаються імітаторами. Це, по-перше, утрудняє підготовку тестів і вимагає високої кваліфікації тестовика (розробника тестів), а по-друге, робить скрутним або навіть неможливим реалізацію повного плану тестування відладжуваного модуля. Вказаний недолік іноді вимушує розробників застосовувати висхідне тестування навіть у разі низхідної розробки. Проте частіше застосовують деякі модифікації низхідного тестування, або деяку комбінацію низхідного і висхідного тестування. Виходячи з того, що низхідне тестування, в принципі, є переважним, зупинимося на прийомах, що дозволяють в якійсь мірі подолати вказані труднощі.
Перш за все, необхідно організувати відладку програми так, щоб якомога раніше були відладжені модулі, що здійснюють введення даних, тоді тестові дані можна готувати у формі, розрахованій на користувача, що істотно спростить підготовку подальших тестів. Далеко не завжди це введення здійснюється в головному модулі, тому доводиться в першу чергу відладжувати ланцюжки модулів, що ведуть до модулів, що здійснюють вказане введення (ср. з методом цілеспрямованої конструктивної реалізації в лекції 7). Поки модулі, що здійснюють введення даних, не відладжені, тестові дані поставляються деякими імітаторами: вони або включаються в імітатор як його частина, або вводяться цим імітатором.
При низхідному тестуванні деякі стани інформаційного середовища, при яких потрібно тестувати відладжуваний модуль, можуть не виникати при виконанні відладжуваної програми ні при яких вхідних даних. У цих випадках можна було б взагалі не тестувати відладжуваний модуль, оскільки помилки, що виявляються при цьому, не виявлятимуться при виконанні відладжуваної програми ні при яких вхідних даних. Проте так поступати не рекомендується, оскільки при змінах відладжуваної програми (наприклад, при супроводі ПС) не використані для тестування відладжуваного модуля стану інформаційного середовища можуть вже виникати, що вимагає додаткового тестування цього модуля (а цього при раціональній організації відладки можна було б не робити, якщо сам даний модуль не змінювався). Для здійснення тестування відладжуваного модуля у вказаних ситуаціях іноді використовують відповідні імітатори, щоб створити необхідний стан інформаційного середовища. Частіше ж користуються модифікованим варіантом низхідного тестування, при якому відладжувані модулі перед їх інтеграцією заздалегідь тестуються окремо (в цьому випадку в оточенні відладжуваного модуля з'являється провідний налагоджувальний модуль, разом з імітаторами модулів, до яких може звертатися відладжуваний модуль). Проте, представляється доцільнішою інша модифікація низхідного тестування: після завершення низхідного тестування відладжуваного модуля для досяжних тестових станів інформаційного середовища слідує його окремо протестувати для решти необхідних станів інформаційного середовища.
Часто застосовують також комбінацію висхідного і низхідного тестування, яку називають методом сандвіча [10.1]. Суть цього методу полягає в одночасному здійсненні як висхідного, так і низхідного тестування, поки ці два процеси тестування не зустрінуться на якому-небудь модулі десь в середині структури відладжуваної програми. Цей метод при розумному порядку тестування дозволяє скористатися достоїнствами як висхідного, так і низхідного тестування, а також в значній мірі нейтралізувати їх недоліки.