ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 26.11.2019
Просмотров: 272
Скачиваний: 1
Вельми важливим при автономній відладці є тестування
сполучення модулів. Річ у тому, що специфікація кожного модуля програми, окрім головного, використовується в цієї програми в двох ситуаціях: по-перше, при розробці тексту (іноді говорять: тіла) цього модуля і, по-друге, при написанні звернення до цього модуля в інших модулях програми. І у тому, і в іншому випадку в результаті помилки може бути порушене необхідна відповідність заданій специфікації модуля. Такі помилки потрібно виявляти і усувати. Для цього і призначено тестування сполучення модулів. При низхідному тестуванні тестування сполучення здійснюється попутно кожним тестом, що пропускається, що вважають гідністю низхідного тестування. При висхідному тестуванні звернення до відладжуваного модуля проводиться не з модулів відладжуваної програми, а з провідного налагоджувального модуля. У зв'язку з цим існує небезпека, що останній модуль може пристосуватися до деяких "помилок" відладжуваного модуля. Тому, приступаючи (в процесі інтеграції програми) до відладки нового модуля, доводиться тестувати кожне звернення до раніше відладженого модуля з метою виявлення неузгодженості цього поводження з тілом відповідного модуля (і не виключено, що винен в цьому раніше відладжений модуль). Таким чином, доводиться частково повторювати в нових умовах тестування раніше відладженого модуля, при цьому виникають ті ж труднощі, що і при низхідному тестуванні.
Автономне тестування модуля доцільно здійснювати в чотири послідовно виконуваних кроку [10.1].
Крок 1. На підставі специфікації відладжуваного модуля підготуйте тести для кожної можливості і кожної ситуації, для кожної межі областей допустимих значень всіх вхідних даних, для кожної області зміни даних, для кожної області неприпустимих значень всіх вхідних даних і кожної неприпустимої умови.
Крок 2. Перевірте текст модуля, щоб переконатися, що кожен напрям будь-якого розгалуження буде пройдений хоч би на одному тесті. Додайте бракуючі тести.
Крок 3. Перевірте текст модуля, щоб переконатися, що для кожного циклу існують тести, що забезпечують, принаймні, три наступні ситуації: тіло циклу не виконується жодного разу, тіло циклу виконується один раз і тіло циклу виконується максимальне число разів. Додайте бракуючі тести.
Крок 4. Перевірте текст модуля, щоб переконатися, що існують тести, перевіряючі чутливість до окремих особливих значень вхідних даних. Додайте бракуючі тести.
10.5. Комплексна відладка програмного засобу.
Як вже було сказано вище, при комплексній відладці тестується ПС в цілому, причому тести готуються по кожному з документів ПС [10.8]. Тестування цих документів проводиться, як правило, в порядку, зворотному їх розробці. Виключення складає лише тестування документації по застосуванню, яка розробляється по зовнішньому опису паралельно з розробкою текстів програм це тестування краще проводити після завершення тестування зовнішнього опису. Тестування при комплексній відладці є застосуванням ПС до конкретних даних, які в принципі можуть виникнути у користувача (зокрема, всі тести готуються у формі, розрахованій на користувача), але, можливо, в модельованому (а не в реальній) середовищі. Наприклад, деякі недоступні при комплексній відладці пристрої введення і виводу можуть бути замінені їх програмними імітаторами.
Тестування архітектури ПС. Метою тестування є пошук невідповідності між описом архітектури і сукупністю програм ПС. До моменту почала тестування архітектури ПС повинна бути вже закінчена автономна відладка кожної підсистеми. Помилки реалізації архітектури можуть бути зв'язані, перш за все, з взаємодією цих підсистем, зокрема, з реалізацією архітектурних функцій (якщо вони є). Тому хотілося б перевірити всі шляхи взаємодії між підсистемами ПС. При цьому бажано хоч би протестувати всі ланцюжки виконання підсистем без повторного входження останніх. Якщо задана архітектура представляє ПС як малої системи з виділених підсистем, то число таких ланцюжків буде цілком осяжно.
Тестування зовнішніх функцій. Метою тестування є пошук розбіжностей між функціональною специфікацією і сукупністю програм ПС. Не дивлячись на те, що всі ці програми автономно вже відладжені, вказані розбіжності можуть бути, наприклад, із-за невідповідності внутрішніх специфікацій програм і їх модулів (на підставі яких проводилося автономне тестування) функціональної специфікації ПС. Як правило, тестування зовнішніх функцій проводиться так само, як і тестування модулів на першому кроці, тобто як чорного ящика.
Тестування якості ПС. Метою тестування є пошук порушень вимог якості, сформульованих в специфікації якості ПС. Це найбільш важкий і найменш вивчений вид тестування. Ясно лише, що далеко не кожен примітив якості ПС може бути випробуваний тестуванням (про оцінку якості ПС див. лекцію 14). Завершеність ПС перевіряється вже при тестуванні зовнішніх функцій. На даному етапі тестування цього примітиву якості може бути продовжене, якщо потрібно отримати яку-небудь імовірнісну оцінку ступеня надійності ПС. Проте, методика такого тестування ще вимагає своєї розробки. Можуть тестуватися такі примітиви якості, як точність, стійкість, захищеність, тимчасова ефективність, в якійсь мірі ефективність по пам'яті, ефективність по пристроях, розширюваність і, частково, незалежність від пристроїв. Кожен з цих видів тестування має свою специфіку і заслуговує окремого розгляду. Ми тут обмежимося лише їх перерахуванням. Легкість застосування ПС (критерій якості, що включає декілька примітивів якості, див. лекцію 4) оцінюється при тестуванні документації по застосуванню ПС.
Тестування документації по застосуванню ПС. Метою тестування є пошук неузгодженості документації по застосуванню і сукупністю програм ПС, а також виявлення незручностей, що виникають при застосуванні ПС. Цей етап безпосередньо передує підключенню користувача до завершення розробки ПС (тестуванню визначення вимог до ПС і атестацій ПС), тому вельми важливо розробникам спочатку самим скористатися ПС так, як це робитиме користувач [10.1]. Всі тести на цьому етапі готуються виключно на підставі тільки документації по застосуванню ПС. Перш за все, повинні тестуватися можливості ПС як це робилося при тестуванні зовнішніх функцій, але тільки на підставі документації по застосуванню. Повинні бути протестовані всі неясні місця в документацію, а також всі приклади, використані в документації. Далі тестуються найбільш важкі випадки застосування ПС з метою виявити порушення вимог відносності легкості застосування ПС.
Тестування визначення вимог до ПС. Метою тестування є з'ясування, якою мірою ПС не відповідає пред'явленому визначенню вимог до нього. Особливість цього виду тестування полягає в тому, що його здійснює організація-покупець або організація-користувач ПС [10.1] як один з шляхів подолання бар'єру між розробником і користувачем (див. лекцію 3). Звичайне це тестування проводиться за допомогою контрольних завдань типових завдань, для яких відомий результат рішення. У тих випадках, коли ПС, що розробляється, винне придти на зміну іншої версії ПС, яка вирішує хоч би частину завдань ПС, що розробляється, тестування проводиться шляхом вирішення загальних завдань за допомогою як старого, так і нового ПС (з подальшим зіставленням отриманих результатів). Іноді як форма такого тестування використовують дослідну експлуатацію ПС обмежене застосування нового ПС з аналізом використання результатів в практичній діяльності. По суті, цей вид тестування багато в чому перекликається з випробуванням ПС при його атестації (див. лекцію 14), але виконується до атестації, а іноді і замість атестації.
Вправи до лекції 10.
10.1. Що таке відладка програмного засобу?
10.2. Що таке тестування програмного засобу?
10.3. Що таке автономна відладка програмного засобу?
10.4. Що таке комплексна відладка програмного засобу?
10.5. Що таке провідний налагоджувальний модуль?
10.6. Що таке налагоджувальний імітатор програмного модуля?
Литература к лекции 10.
10.1. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 171-262.
10.2. Д. Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. - С. 179-295.
10.3. Дж. Хьюз, Дж. Мичтом. Структурный подход к программированию. - М.: Мир, 1980. - С. 254-268.
10.4. Дж. Фокс. Программное обеспечение и его разработка. - М.: Мир, 1985. - С. 227-241.
10.5. М. Зелковиц, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - С. 105-116.
10.6. Ю.М. Безбородов. Индивидуальная отладка программ. - М.: Наука, 1982. - С. 9-79.
10.7. В.В. Липаев. Тестирование программ. - М.: Радио и связь, 1986. - С. 15-47.
10.8. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
10.9. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-13.