Рефераты
Видео уроки
ВУЗы Украины
Мир
Рефератов
Рефератов
Купить авто, автообзоры Ремонт АКПП
|
Большая база бесплатных русских и украинских рефератов
Доклады, сочинения, контрольные работы, экзаменационные билеты и шпаргалки/шпоры Коллекция курсовых и дипломных работ для студентов 
|
Рефераты по Інформатика
Програма складної структури з використанням меню
КУРСОВА
“Програма складної структури з використанням меню"
ЗМІСТ
1. ВИДИ КОНТРОЛЮ ПРОГРАМ
2. ЦІЛІ, ПРИНЦИПИ І ЕТАПИ ТЕСТУВАННЯ
3. СТРУКТУРНЕ ТЕСТУВАННЯ
4. СПІЛЬНЕ ТЕСТУВАННЯ МОДУЛІВ
5. ФУНКЦІОНАЛЬНЕ ТЕСТУВАННЯ
6. ТЕСТУВАННЯ ПРОГРАМНОГО КОМПЛЕКУ ВЦІЛОМУ
7. ВІДЛАДКА ПРОГРАМ
ВИДИ КОНТРОЛЮ ПРОГРАМ
Програмний комплекс - це сукупність програмних модулів, призначених для рішення однієї задачі і складових одне ціле.
Основними різновидами контролю програмного забезпечення є візуальний, статичний і динамічний.
Візуальний контроль - це перевірка програм “ за столом “, без використання комп'ютера. На першому етапі візуального контролю здійснюється читання програми, причому особлива увага приділяється наступним її елементам:
коментарям і їх відповідності тексту програми;
умовам в операторах умовного вибору ( IF, CASE ) і циклу;
складним логічним виразам;
можливості незавершення ітераціонних циклів ( WHILE, REPEAT, LOOP ).
Другий етап візуального контролю - крізний контроль програми
( її ручна прокрутка на декількох зазделегідь підібраних простих тестах). Поширена думка, що більш вигідним є перекладання більшої частини роботи по контролю програмних засобів на комп'ютері, помилкова. Основний довід на користь цього такий: при роботі на комп'ютері головним чином удосконалюються навички у використанні клавіатури, в той час як програмістсьа кваліфікація присвоюється передусім за столом.
Статичний контроль- це перевірка програми по її тексту (без виконання) за допомогою інструментальних засобів. Найбільш відомою формою статичного контролю є синтаксичний контроль програми за допомогою компілятора, при якому перевіряється відповідність тексту програми синтаксичним правилам мови програмування.
Повідомлення компілятора звичайно діляться на декілька груп в залежності від рівня тягаря порушення синтаксису мови програмування:
- інформаційні повідомлення і попередження, при виявленні яких компілятор, як правило, будує коректний об'єктний код і подальшу роботу з програмою (компонування, виконання) можлива (проте повідомлення цієї групи також повинні ретельно аналізуватися, оскільки їх поява також може свідчити про помилку в програмі - наприклад, через невірне розуміння синтаксису мови);
- повідомлення про помилки, при виявленні яких компілятор намагається їх виправити і будує об'єктний код, але його коректність малоймовірна і подальша робота з ним швидше усього не можлива;
3
- повідомлення про серйозні помилки, при наявності яких побудований компілятором об'єктний код явно некоректний і його подальше використання неможливо;
- повідомлення про помилки, виявлення яких привело до припинення синтаксичного контролю і побудови об'єктного коду.
Однак, практично будь-який компілятор пропускає деякі види синтаксичних помилок. Місце виявлення помилки може знаходитися далеко по тексту програми від місця істинної помилки, а текст повідомлення компілятора може не вказувати на істинну причину помилки. Одна синтаксична помилка може спричинити генерацію компілятором декількох повідомлень про помилки (наприклад, помилка в описі змінної приводить до появи повідомлення про помилку в кожному операторі програми, що використовує цю змінну).
Другою формою синтаксичного контролю може бути контроль структурованості програм, тобто перевірка виконання угод і обмежень структурного програмування. Прикладом подібної перевірки може бути виявлення в тексті програми ситуацій, коли цикл утвориться за допомогою оператора безумовного переходу (використання оператора GOTO для переходу вгору по тексту програми ). Для проведення контролю структурованості можуть бути створені спеціальні інструментальні засоби, а при їх відсутності ця форма статичного контролю може поєднуватися з візуальним контролем.
Третя форма статичного контролю - контроль правдоподібності програми, тобто виявлення в її тексті конструкцій, які хоч і синтаксично коректні, але швидше усього містять помилку або свідчать про неї. Основні неправдоподібні ситуації:
- використання в програмі неініціалізувати змінних (тобто змінних, що не набули початкового значення);
- наявність в програмі описів елементів, змінних, процедур, міток, файлів, надалі що не використовуються в її тексті;
- наявність в тексті програми фрагментів, що ніколи не виконуються;
- наявність в тексті програми змінних, ні разу що не використовуються для читання після привласнюючи їм значень;
- наявність в тексті програми явно нескінченних циклів;
Навіть якщо присутність в тексті програми неправдоподібних конструкцій не приводить до її неправильної роботи, виправлення цього фрагмента підвищить ясність і ефективність програми, т. е. благотворно позначиться на її якості.
Для можливості проведення контролю правдоподібності в повному об'ємі також повинні бути створені спеціальні інструментальні засоби, хоч ряд можливостей по контролю правдоподібності є в існуючих відлагоджувальний і звичайних компіляторах.
4
Потрібно зазначити, що створення інструментальних засобів контролю структурованості і правдоподібності програм може бути істотне
спрощено при застосуванні наступних принципів:
1) проведення цих додаткових форм статичного контролю після завершення компіляції і тільки для синтаксично коректних програм;
2) максимальне використання результатів компіляції програми і, зокрема, інформації, що включається в лістинг компілятора;
3) замість повного синтаксичного розбору тексту програми, що перевіряється побудова для неї списку ідентифікаторів і списку операторів з вказівкою всіх їх необхідних ознак.
При відсутності інструментальних засобів контролю правдоподібності ця фаза статичного контролю також може об'єднуватися з візуальним контролем.
Четвертою формою статичного контролю програм є їх верифікація, тобто аналітичний доказ їх коректності.
У інтуїтивному значенні під коректністю розуміють властивості програми, що свідчать про відсутність в ній помилок, допущених розробником на різних етапах проектування ( специфікації, проектування алгоритму і структур даних, кодування ). Коректність самої програми по відношенню до цілей, поставлених перед її розробкою ( тобто ця відносна властивість ). Відмінність поняття коректності і надійності програм в наступному:
надійність характеризує як програму, так і її “оточення" ( якість апаратури, кваліфікацію користувача і т.п. );
кажучи про надійність програми, звичайно допускають певну, хоч і малу, частку помилок в ній і оцінюють імовірність їх появи.
Надійність можна представити сукупністю наступних характеристик:
1) цілісність програмного засобу (здатність його до захисту від відмов);
2) живучість (здібність до вхідного контролю даних і їх перевірки в ході роботи);
3) завершеність (бездефектність готового програмного засобу, характеристика якості його тестування);
4) працездатність (здатність програмного засобу до відновлення своїх можливостей поле збоїв).
Очевидно, що не всяка синтаксично правильна програма є коректною у вказаному вище значенні, т. е. коректність характеризує семантичні властивості програм.
5
З урахуванням специфіки появи помилок в програмах можна виділити дві сторони поняття коректності:
1) коректність як точна відповідність цілям розробки програми (які відображені в специфікації) при умові її завершення або часткова коректність;
2) завершення програми, тобто досягнення програмою в процесі її виконання своєї кінцевої точки.
У залежності від виконання або невиконання кожного з двох названих властивостей програми розрізнюють шість задач аналізу коректності:
1) доказ часткової коректності;
2) доказ часткової некоректність;
3) доказ завершення програми;
4) доказ незавершення програми;
5) доказ тотальної (повної ) коректності (тобто одночасне рішення першої і третьої задач);
6) доказ некоректність (рішення другої або четвертої задачі).
Методи доказу часткової коректності програм як правило спираються на аксіоматичний підхід до формалізації семантики мов програмування. У цей час відомі аксіоматичні семантики Паськаля, підмножини ПЛ/1 і деяких інших мов.
Аксіоматична семантика мови програмування являє собою сукупність аксіом і правил висновку. За допомогою аксіом задається семантика простих операторів мови (привласнення, введення - виведення, процедур). За допомогою правил висновку описується семантика складових операторів або керуючих структур (послідовності, умовного вибору, циклів). Серед цих правил висновку треба відмітити правило висновку для операторів циклу оскільки воно вимагає знання інваріанта циклу (формули, істинності якій не змінюється при будь-якому проходженні циклу).
Побудова інваріанта для оператора циклу по його тексту є алгоритмічно не вирішуваної задачі, тому для опису семантики циклів потрібно свого роду "підказка" від розробника програми.
Найбільш відомим з методів доказу часткової коректності програм є метод індуктивних тверджень запропонований Флойдом і вдосконалений Хоаром. Метод складається з трьох етапів.
Перший етап - отримання анотованої програми. На цьому етапі для синтаксично правильної програми повинні бути задані твердження на мові логіки предикатів першого порядку:
6
вхідний предикат;
вихідний предикат;
за одному твердженням для кожного циклу (ці твердження задаються для вхідної точки циклу і повинні характеризувати семантику обчислень в циклі).
Доказ неістинності умов коректності свідчить про неправильність програми, або її специфікації, або програми і специфікацій.
Незважаючи на достатню складність процесу верифікації програми і на те, що навіть успішно завершена верифікація не дає гарантій якості програми ( так як помилка може міститися і у верифікації ), застосування методів аналітичного доказу правильності дуже корисне для уточнення значення програми, що розробляється, а знання цих методів благотворно позначається на кваліфікації програміста.
Нарешті, динамічний контроль програми - це перевірка правильності програми при її виконанні на комп'ютері, тобто тестування.
ЦЕЛІ, ПРІНЦИПИ І ЕТАПИ ТЕСТУВАННЯ
Кожному програмісту відомо, скільки часу і сил йде на відладку і тестування програм. На цей етап доводиться біля 50% загальної вартості розробки програмного забезпечення.
Але не кожний з розробників програмних засобів може вірно визначити мету тестування. Нерідко можна почути, що тестування - це процес виконання програми з метою виявлення в ній помилок. Але ця мета недосяжна: ні яке саме ретельне тестування не дає гарантії, що програма не містить помилок.
Інше визначення тестування ( у м. Майерса ) тестування - це процес виконання програми з метою виявлення в ній помилок. Таке визначення мети стимулює пошук помилок в програмах. Звідси також ясно, що “вдалим" тестом є такою, на якому виконання програми завершилося з помилкою. Навпаки, “невдалим можна назвати тест, що не дозволив виявити помилку в програмі.
Визначення м. Маєрса вказує на об'єктивну трудність тестування: це деструктивний ( тобто зворотний творчому ) процес. Оскільки програмування - процес конструктивний, ясно, що більшості розробників програмних засобів складно “перемкнутися" при тестуванні створеної ними продукції.
7
У Майерса сформульовані також основні принципи організації тестування:
1) необхідною частиною кожного тесту повинно бути опис очікуваних результатів роботи програми, щоб можна було швидко з'ясувати наявність або відсутність помилки в ній;
2) слідує по можливості уникати тестування програми її автором, так як крім вже вказаної об'єктивної складності тестування для програмістів тут присутній і той чинник, що виявлення недоліків в своїй діяльності суперечить людській психології ( однак відладка програми ефективніше усього виконується саме автором програми );
3) по тих же міркуваннях організація - розробник програмного забезпечення не повинна “одноосібно " його тестувати ( повинні існувати організації, що спеціалізуються на тестуванні програмних засобів );
4) повинні бути правилом доскональне вивчення результатів кожного тесту, щоб не пропустити малопомітну на поверхневий погляд помилку в програмі;
5) необхідно ретельно підбирати тест не тільки для правильних ( передбачених ) вхідних даних, але і для неправильних (непередбачених);
6) при аналізі результатів кожного тесту необхідно перевіряти, чи не робить програма того, що вона не повинна робити;
7) потрібно зберігати використані тести (для підвищення ефективності повторного тестування програми після її модифікації або установки у замовника);
8) тестування не повинне плануватися виходячи з припущення, що в програмі не будуть виявлені помилки (зокрема, потрібно виділяти для тестування достатні тимчасові і матеріальні ресурси);
9) потрібно враховувати так званий “принцип скупчення помилок": імовірність наявності не виявлених помилок в деякій частині програми прямо пропорційна числу помилок, вже виявлених в цій частині;
10) потрібно завжди пам'ятати, що тестування - творчий процес, а не відноситися до нього як до рутинного заняття.
Існує два основних вигляду тестування: функціональне і структурне. При функціональному тестуванні програма розглядається як “чорний ящик" (тобто її текст не використовується). Відбувається перевірка відповідності поведінки програми її зовнішньої специфікації. Чи Можливо при цьому повне тестування програми? Очевидно, що критерієм повноти тестування в цьому випадку був би перебір всіх можливих значень вхідних даних, що нездійсненно.
8
Оскільки вичерпне функціональне тестування неможливе, мова може йти об розробки методів, що дозволяють підбирати тести не “наосліп", а з великою імовірністю виявлення помилок в програмі.
При структурному тестуванні програма розглядається як “білий ящик" (тобто її текст відкритий для користування ). Відбувається перевірка логіки програми. Повним тестуванням в цьому випадку буде таке, яке приведе до перебору всіх можливих шляхів на графі передач управління програми (її керуючому графові). Навіть для середніх по складності програм числом таких шляхів може досягати десятків тисяч. Якщо обмежитися перебором тільки лінійних не залежних шляхів, то і в цьому випадку вичерпне структурне тестування практично неможливе, т. к. неясне, як підбирати тести, щоб забезпечити “покриття" всіх таких шляхів. Тому при структурному тестуванні необхідно використати інші критерії його повноти, що дозволяють досить просто контролювати їх виконання, але не даючі гарантії повної перевірки логіки програми.
Але навіть якщо передбачити, що вдалося досягнути повного структурного тестування деякої програми, в ній проте можуть міститися помилки, так як
1) програма може не відповідати своїй зовнішній специфікації, що зокрема, може привести до того, що в її керуючому графові виявляться пропущеними деякі необхідні шляхи;
2) не будуть виявлені помилки, поява яких залежить від даних (, що обробляються тобто на одних початкових даних програма працює правильно, а на інших - з помилкою).
Таким чином, ні структурне, ні функціональне тестування не може бути вичерпним. Розглянемо детальніше основні етапи тестування програмних комплексів.
У тестування багатомодульных програмних комплексів можна виділити чотири етапи:
1) тестування окремих модулів;
2) спільне тестування модулів;
3) тестування функцій програмного комплексу (тобто пошук відмінностей між розробленою програмою і її зовнішньою специфікацією );
4) тестування всього комплексу загалом (тобто пошук невідповідності створеного програмного продукту сформульованим раніше цілям проектування, відображеним звичайно в технічному завданні).
На перших двох етапах використовуються передусім методи структурного тестування, так як
на подальших етапах тестування ці методи використати складніше через великі розміри програмного забезпечення, що перевіряється;
подальші етапи тестування орієнтовані на виявлення помилок різного типу, які не обов'язково пов'язані з логікою програми.
При тестуванні як окремих модулів, так і їх комплексів повинні бути вирішені дві задачі:
1) побудова ефективної безлічі тестів;
2) вибір способу комбінування (збирання) модулів при створенні трестируємого варіанту програми.
СТРУКТУРНЕ ТЕСТУВАННЯ
Оскільки вичерпне структурне тестування неможливе, необхідно вибрати такі критерії його повноти, які допускали б їх просту перевірку і полегшували б цілеспрямований підбір тестів.
Найбільш слабою з критеріїв повноти структурного тестування є вимога хоч би однократного виконання (покриття) кожного оператора програми.
Більш сильним критерієм є так званий критерій С1: кожна гілка алгоритму (кожний перехід) повинна бути пройдена (виконана) хоч би один раз. Для більшості мов програмування покриття переходів забезпечує і покриття операторів, але, наприклад, для програм на мові ПЛ/1 додатково до покриття всіх гілок потрібно всіх додаткових точок входу в процедуру (що задаються операторами ENTRY) і всіх ON - одиниць.
Використання критерію покриття умов може викликати підбір тестів, що забезпечують перехід в програмі, який пропускається при використанні критерію С1 (наприклад, в програмі на мові Паськаль, що використовує конструкцію циклу WHILE х AND у DO..., застосування критерію покриття умов вимагає перевірки обох варіантів виходу з циклу: NOT х і NOT у ).
З іншого боку покриття умов може не забезпечувати покриття всіх переходів. Наприклад, конструкція IF А AND В THEN... вимагає по критерію покриття умов двох тестів (наприклад, А=true, В=false і А=false, В=true ), при яких може не виконуватися оператор, розташований в then - гілки оператора if.
Практично єдиним засобом, що надається сучасними системами програмування, є можливість визначення частоти виконання різних операторів програми (її профілізації). Але за допомогою цього інструмента підтримки тестування можна перевірити виконання тільки найслабішого з критеріїв повноти - покриття всіх операторів.
Правда, за допомогою цього ж інструмента можна перевірити і виконання критерію С1. Але для цього заздалегідь текст програми повинен бути перетворений таким чином, щоб всі конструкції умовного вибору (IF і CASE
10
або SWITCH ) містили гілки ELSE або DEFAULT, хоч би і пусті. У цьому випадку всі гілки алгоритму, ті, що не виконувалися на даному тесті будуть “видимі" з таблиці частоти виконання операторів перетвореної програми.
Актуальною залишається задача створення інструментальних засобів, що дозволяють:
1) нагромаджувати інформації про покриті і непокриті гілки для всіх використаних тестів;
2) виділяти розробнику ще не покриті при тестуванні дільниці програми, полегшуючи вибір наступних тестів;
3) підтримувати більш могутні критерії повноти структурного тестування.
СПІЛЬНЕ ТЕСТУВАННЯ МОДУЛІВ.
Відомі два підходи до спільного тестування модулів: покрокове і монолітне тестування.
При монолітному тестуванні спочатку по окремості тестуються всі модулі програмного комплексу, а потім всі вони об'єднуються в робочу програму для комплексного тестування.
При покроковому тестуванні кожний модуль для свого тестування підключається до набору вже перевірених модулів.
У першому випадку для автономного тестування кожного модуля потрібний модуль - драйвер ( тобто допоміжний модуль, що імітує виклик модуля, що тестується ) і один або декілька модулів - заглушок ( тобто допоміжних модулів, що імітують роботу модулів, що викликаються з того, що тестується). При покроковому тестуванні модулі перевіряються не ізольовано один від одного, тому потрібні або тільки драйвери, або тільки заглушки.
А
B C D
E F
мал. 1
При порівнянні покрокового і монолітного тестування можна відмітити наступні переваги першого підходу:
1) менша трудомісткість (для прикладу на мал. 1 при монолітному тестуванні потрібно 5 драйверів і 5 заглушок; при покроковому тестуванні потрібні або тільки 5 драйверів - якщо модулі підключаються “знизу вгору ", - або тільки 5 заглушок - якщо модулі підключаються “зверху вниз");
2) більш раннє виявлення помилок в інтерфейсах між модулями (їх збирання починається раніше, ніж при монолітному тестуванні );
3) легше відладка, тобто локалізація помилок (вони в основному пов'язані з останнім з підключених модулів );
4) більш досконалі результати тестування (більш ретельна перевірка спільного використання модулів).
Є переваги і у монолітного тестування:
1) менше витрата машинного часу (хоч через більшу складність відладки може бути потрібна додаткова перевірка програми і ця перевага буде зведена на немає);
2) надається більше можливостей для організації паралельної роботи на початковому етапі тестування.
Загалом більш доцільним є вибір покрокового тестування. При його використанні можливі дві стратегії підключення модулів: низхідна і висхідна.
Низхідне тестування починається з головного (або верхнього) модуля програми, а вибір наступного модуля, що підключається відбувається з числа модулів, що викликаються з вже протестованих. Одна з основних проблем, виникаючих при низхідному тестуванні, - створення заглушок. Це тривіальна задача, т. к. як правило недостатньо, щоб в заглушці виконувався висновок відповідного інформаційного повідомлення і повернення завжди одних і тих же значень вихідних даних.
Інша проблема, яку необхідно вирішувати при низхідному тестуванні, - форма представлення тестів в програмі, оскільки, як правило, головний модуль отримує вхідні дані не безпосередньо, а через спеціальні модулі введення, які при тестуванні на початку замінюються заглушками. Для передачі в головний модуль різних тестів треба або мати декілька різних заглушок, або записати ці тести в файл у зовнішній пам'яті і за допомогою заглушки прочитувати їх.
Оскільки після тестування головного модуля процес перевірки може продовжуватися по-різному, потрібно дотримуватися наступних правил:
а) модулі, що містять операції введення-висновку, повинні підключатися до тестування як можна раніше;
б) критичні (тобто найбільш важливі ) для програми загалом модулі також повинні тестуватися насамперед.
12
Основні переваги низхідного тестування:
ів можна виділити чотири етапи:
1) тестування окремих модулів;
2) спільне тестування модулів;
3) тестування функцій програмного комплексу (тобто пошук відмінностей між розробленою програмою і її зовнішньою специфікацією );
4) тестування всього комплексу загалом (тобто пошук невідповідності створеного програмного продукту сформульованим раніше цілям проектування, відображеним звичайно в технічному завданні).
На перших двох етапах використовуються передусім методи структурного тестування, так як
на подальших етапах тестування ці методи використати складніше через великі розміри програмного забезпечення, що перевіряється;
подальші етапи тестування орієнтовані на виявлення помилок різного типу, які не обов'язково пов'язані з логікою програми.
При тестуванні як окремих модулів, так і їх комплексів повинні бути вирішені дві задачі:
1) побудова ефективної безлічі тестів;
2) вибір способу комбінування (збирання) модулів при створенні трестируємого варіанту програми.
СТРУКТУРНЕ ТЕСТУВАННЯ
Оскільки вичерпне структурне тестування неможливе, необхідно вибрати такі критерії його повноти, які допускали б їх просту перевірку і полегшували б цілеспрямований підбір тестів.
Найбільш слабою з критеріїв повноти структурного тестування є вимога хоч би однократного виконання (покриття) кожного оператора програми.
Більш сильним критерієм є так званий критерій С1: кожна гілка алгоритму (кожний перехід) повинна бути пройдена (виконана) хоч би один раз. Для більшості мов програмування покриття переходів забезпечує і покриття операторів, але, наприклад, для програм на мові ПЛ/1 додатково до покриття всіх гілок потрібно всіх додаткових точок входу в процедуру (що задаються операторами ENTRY) і всіх ON - одиниць.
Використання критерію покриття умов може викликати підбір тестів, що забезпечують перехід в програмі, який пропускається при використанні критерію С1 (наприклад, в програмі на мові Паськаль, що використовує конструкцію циклу WHILE х AND у DO..., застосування критерію покриття умов вимагає перевірки обох варіантів виходу з циклу: NOT х і NOT у ).
З іншого боку покриття умов може не забезпечувати покриття всіх переходів. Наприклад, конструкція IF А AND В THEN... вимагає по критерію покриття умов двох тестів (наприклад, А=true, В=false і А=false, В=true ), при яких може не виконуватися оператор, розташований в then - гілки оператора if.
Практично єдиним засобом, що надається сучасними системами програмування, є можливість визначення частоти виконання різних операторів програми (її профілізації). Але за допомогою цього інструмента підтримки тестування можна перевірити виконання тільки найслабішого з критеріїв повноти - покриття всіх операторів.
Правда, за допомогою цього ж інструмента можна перевірити і виконання критерію С1. Але для цього заздалегідь текст програми повинен бути перетворений таким чином, щоб всі конструкції умовного вибору (IF і CASE
10
або SWITCH ) містили гілки ELSE або DEFAULT, хоч би і пусті. У цьому випадку всі гілки алгоритму, ті, що не виконувалися на даному тесті будуть “видимі" з таблиці частоти виконання операторів перетвореної програми.
Актуальною залишається задача створення інструментальних засобів, що дозволяють:
1) нагромаджувати інформації про покриті і непокриті гілки для всіх використаних тестів;
2) виділяти розробнику ще не покриті при тестуванні дільниці програми, полегшуючи вибір наступних тестів;
3) підтримувати більш могутні критерії повноти структурного тестування.
СПІЛЬНЕ ТЕСТУВАННЯ МОДУЛІВ.
Відомі два підходи до спільного тестування модулів: покрокове і монолітне тестування.
При монолітному тестуванні спочатку по окремості тестуються всі модулі програмного комплексу, а потім всі вони об'єднуються в робочу програму для комплексного тестування.
При покроковому тестуванні кожний модуль для свого тестування підключається до набору вже перевірених модулів.
У першому випадку для автономного тестування кожного модуля потрібний модуль - драйвер ( тобто допоміжний модуль, що імітує виклик модуля, що тестується ) і один або декілька модулів - заглушок ( тобто допоміжних модулів, що імітують роботу модулів, що викликаються з того, що тестується). При покроковому тестуванні модулі перевіряються не ізольовано один від одного, тому потрібні або тільки драйвери, або тільки заглушки.
А
B C D
E F
мал. 1
При порівнянні покрокового і монолітного тестування можна відмітити наступні переваги першого підходу:
1) менша трудомісткість (для прикладу на мал. 1 при монолітному тестуванні потрібно 5 драйверів і 5 заглушок; при покроковому тестуванні потрібні або тільки 5 драйверів - якщо модулі підключаються “знизу вгору ", - або тільки 5 заглушок - якщо модулі підключаються “зверху вниз");
2) більш раннє виявлення помилок в інтерфейсах між модулями (їх збирання починається раніше, ніж при монолітному тестуванні );
3) легше відладка, тобто локалізація помилок (вони в основному пов'язані з останнім з підключених модулів );
4) більш досконалі результати тестування (більш ретельна перевірка спільного використання модулів).
Є переваги і у монолітного тестування:
1) менше витрата машинного часу (хоч через більшу складність відладки може бути потрібна додаткова перевірка програми і ця перевага буде зведена на немає);
2) надається більше можливостей для організації паралельної роботи на початковому етапі тестування.
Загалом більш доцільним є вибір покрокового тестування. При його використанні можливі дві стратегії підключення модулів: низхідна і висхідна.
Низхідне тестування починається з головного (або верхнього) модуля програми, а вибір наступного модуля, що підключається відбувається з числа модулів, що викликаються з вже протестованих. Одна з основних проблем, виникаючих при низхідному тестуванні, - створення заглушок. Це тривіальна задача, т. к. як правило недостатньо, щоб в заглушці виконувався висновок відповідного інформаційного повідомлення і повернення завжди одних і тих же значень вихідних даних.
Інша проблема, яку необхідно вирішувати при низхідному тестуванні, - форма представлення тестів в програмі, оскільки, як правило, головний модуль отримує вхідні дані не безпосередньо, а через спеціальні модулі введення, які при тестуванні на початку замінюються заглушками. Для передачі в головний модуль різних тестів треба або мати декілька різних заглушок, або записати ці тести в файл у зовнішній пам'яті і за допомогою заглушки прочитувати їх.
Оскільки після тестування головного модуля процес перевірки може продовжуватися по-різному, потрібно дотримуватися наступних правил:
а) модулі, що містять операції введення-висновку, повинні підключатися до тестування як можна раніше;
б) критичні (тобто найбільш важливі ) для програми загалом модулі також повинні тестуватися насамперед.
12
Основні переваги низхідного тестування:
вже на ранній стадії тестування є можливість отримати працюючий варіант програми, що розробляється;
швидко можуть бути виявлені помилки, пов'язані з організацією взаємодія з користувачем.
Недоліки низхідної стратегії продемонструються з допомогою мал. 2.
Допустимо, що на наступному кроці тестування заглушка модуля Н замінюється його реальним текстом. Тоді
1) може виявитися важким або навіть неможливим побудувати такий тест на вході модуля J, якому відповідав би будь-яка задана наперед послідовность значень даних на вході модуля Н;
2) не завжди виявиться можливим легко оцінити відповідність значень даних на вході модуля J необхідним тестам для перевірки модуля Н;
3) т. я. результати виконання програми на побудованому
| 1 | 2 | след. → |
