Програма складної структури з використанням меню

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

МОСКОВСЬКИЙ ДЕРЖАВНИЙ ГІРНИЧИЙ УНІВЕРСИТЕТ

кафедра вм

Курсовик

"П рограмма складної структури з використанням меню"

ВИКОНАВ: Пікулін Є. Г.

прийняв: Солодовников А. Д.

ã Москва 1996 рік

ЗМІСТ.

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 y DO ..., застосування критерію покриття умов вимагає перевірки обох варіантів виходу з циклу: NOT x і NOT y).

З іншого боку покриття умов може не забезпечувати покриття всіх переходів. Наприклад, конструкція IF A AND B THEN ... вимагає по критерію покриття умов двох тестів (наприклад, A = true, B = false і A = false, B = true), при яких може не виконуватися оператор, розташований в then - гілки оператора if.

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

Правда, за допомогою цього ж інструмента можна перевірити і виконання критерію С1. Але для цього заздалегідь текст програми повинен бути перетворений таким чином, щоб всі конструкції умовного вибору (IF і CASE

10

або SWITCH) містили гілки ELSE або DEFAULT, хоч би і пусті. У цьому випадку всі гілки алгоритму, що не виконувалися на даному тесті будуть "видимі" з таблиці частоти виконання операторів перетвореної програми.

Актуальною залишається задача створення інструментальних засобів, що дозволяють:

1) нагромаджувати інформації про покриті і непокриті гілки для всіх використаних тестів;

2) виділяти розробнику ще не покриті при тестуванні дільниці програми, полегшуючи вибір наступних тестів;

3) підтримувати більш могутні критерії повноти структурного тестування.

Спільне тестування модулів.

Відомі два підходи до спільного тестування модулів: покрокове і монолітне тестування.

При монолітному тестуванні спочатку по окремості тестуються всі модулі програмного комплексу, а потім всі вони об'єднуються в робочу програму для комплексного тестування.

При покроковому тестуванні кожний модуль для свого тестування підключається до набору вже перевірених модулів.

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

Програма складної структури з використанням меню


А   

Програма складної структури з використанням меню
Програма складної структури з використанням менюПрограма складної структури з використанням менюПрограма складної структури з використанням меню


B C D

Програма складної структури з використанням менюПрограма складної структури з використанням меню


E F

рис. 1

12

При порівнянні покрокового і монолітного тестування можна відмітити наступні переваги першого підходу:

1) менша трудомісткість (для прикладу на рис.1 при монолітному тестуванні потрібно 5 драйверів і 5 заглушок; при покроковому тестуванні потрібні або тільки 5 драйверів - якщо модулі підключаються "знизу вгору", - або тільки 5 заглушок - якщо модулі підключаються "зверху вниз ");

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

3) легше відладка, тобто локалізація помилок (вони в основному пов'язані з останнім з підключених модулів);

4) більш досконалі результати тестування (більш ретельна перевірка спільного використання модулів).

Є переваги і у монолітного тестування:

1) менше витрата машинного часу (хоча через більшу складність відладки може бути потрібна додаткова перевірка програми і ця перевага буде зведена на немає);

2) надається більше можливостей для організації паралельної роботи на початковому етапі тестування.

Загалом більш доцільним є вибір покрокового тестування. При його використанні можливі дві стратегії підключення модулів: низхідна і висхідна.

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

Інша прблеми, яку необхідно вирішувати при низхідному тестуванні, - форма представлення тестів в програмі, оскільки, як правило, головний модуль отримує вхідні дані не безпосередньо, а через спеціальні модулі введення, які при тестуванні на початку замінюються заглушками. Для передачі в головний модуль різних тестів треба або мати декілька різних заглушок, або записати ці тести в файл у зовнішній пам'яті і за допомогою заглушки прочитувати їх.

Оскільки після тестування головного модуля процес перевірки може продовжуватися по-різному, потрібно дотримуватися наступних правил:

а) модулі, що містять операції введення-висновку, повинні підключатися до тестування як можна раніше;

б) критичні (тобто найбільш важливі) для програми загалом модулі також повинні тестуватися насамперед.

12

Основні переваги низхідного тестування:

вже на ранній стадії тестування є можливість отримати працюючий варіант програми;

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

Недоліки низхідної стратегії продемонструють за допомогою рис.2.

Припустимо, що на наступному кроці тестування заглушка модуля H замінюється його реальним текстом. Тоді

1) може виявитися важким або навіть неможливим побудувати такий тест на вході модуля J, якому відповідав би будь-який заданою наперед послідовності значень даних на вході модуля Н;

2) не завжди виявиться можливим легко оцінити відповідність значень даних на вході модуля J необхідним тестам для перевірки модуля Н;

3) тому що результати виконання програми на побудованому для перевірки модуля Н тесті виводяться не їм, а модулем I, може виявитися важким відновлення дійсних результатів роботи модуля Н.

Інші проблеми, які можуть виникати при низхідному тестуванні:

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

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

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

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

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

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

немає можливості поєднання проектування з тестуванням;

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

Основними недоліком висхідного тестування є те, що перевірка всієї структури програмного комплексу можлива тільки на завершальній стадії тестування.

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

На третьому етапі тестування програмних комплексів (тестуванні функцій) використовуються передусім методи функціонального тестування.

Функціональне тестування.

Огляд методів проектування тестів при функціоналному тестуванні почнемо з методу зквівалентного розбиття.

Оскільки нашою метою є побудови безлічі тестів, що характеризується найвищою імовірністю виявлення більшості помилок в програмі, що тестується, то тест з цієї безлічі повинен:

1) зменшувати (більш ніж на одиницю) число інших тестів, які повинні бути розроблені для досягнення зазделегідь поставленої мети "задовільного" тестування;

2) покривати собою значну частину інших можливих тестів.

Іншими словами:

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

2) необхідно розбити область значень вхідних даних на кінцеве число підобластей (які будуть називатися класами еквівалентності), щоб можна було вважати кожний тест, що є представником деякого класу, еквівалентним будь-якому другому тесту цього класу (тобто що виявляє одні і ті ж помилки) .

У загальному випадку використання терміну "клас еквівалентності" є тут не цілком точним, так виділені підобласті можуть перетинатися.

Проектування тестів по методу еквівалентного роздроблення проводиться в два етапи:

виділення по зовнішній специфікації класів еквівалентності;

побудова безлічі тестів.

Програма складної структури з використанням менюПрограма складної структури з використанням менюПрограма складної структури з використанням менюПрограма складної структури з використанням меню На першому етапі відбувається вибір з специфікації кожної вхідної умови і роздроблення його на дві або більше за групу, відповідні так званим "правильним" (ПКЕ) і "неправильним" класом еквівалентності (НКЕ), тобто областям допустимих для програми і недопустимих значень вхідних даних. Цей процес залежить від вигляду вхідної умови. Якщо вхідна умова описує область (наприклад, х 0), то визначаються один ПКЕ (N> 0) і один НКЕ (N = замість>. При проектуванні тестів по методу еквівалентного роздроблення будуть побудовані тести для випадків можливості побудови трикутника (наприклад, 3, 4, 5) і неможливості його побудови (наприклад, 1, 2, 4), тобто помилка в програмі не буде виявлена ​​(на вхідні дані 1, 2, 3 буде виведене повідомлення "різносторонній трикутник"). Але подібний тест буде отриманий при використанні методу аналізу граничних умов.

Аналіз граничних умов - один з найбільш корисних методів проектування тестів. Але він часто виявляється неефективним через те, що граничні умови іноді ледве вловимі, ​​а їх виявлення вельми важко.

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

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

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

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

а) Тотожність: (а = 1 => b = 1) & (а = 0 => b = 0)

а b

б) Заперечення: (а = 1 => b = 0) & (a = 0 => b = 1)

~

a b

в) Диз'юнкція: (a = 1ïb = 1 => c = 1) & (a = 0 & b => 0> c = 0)

a

ï c

b

г) Кон'юнкція: (a = 1 & b = 1 => c = 1) & (a = 0ïb = 0 => c = 0)

a

& C

b

рис.3

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

а) Виключення однієї з причин:

a

E ((a = 1ïb = 1) ^ ~ (a = 1 & b = 1)) ï (a = 0 & b = 0)

b

б) Включення хоч би однієї причини:

a

I (a = 1ïb = 1) & ~ (a = 0 & b = 0)

b

в) Існує одна і тільки одна причина:

a

O (a = 1ïb = 1) & ~ (a = 1 & b = 1) & ~ (a = 0 & b = 0)

b

г) Одна причина спричиняє за собою лругих:

a

R ~ (a = 1 & b = 0)

b

д) Одне слідство приховує в собі інше:

a

M (a = 1 & b = 0) & (a = 1 & b = 1)

b

рис.4

П'ятий етап - функціональна діаграма перетворюється в таблицю рішень:

вибирається слідство, яке встановлюється в 1;

знаходяться всі комбінації причин (з урахуванням обмежень),

які встановлюють вибране слідство в 1


Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
61.9кб. | скачати


Схожі роботи:
Програма провідник Основні прийоми роботи із програмою Провідник опис усіх пунктів меню
Програма установки захищених мережевих з`єднань з використанням протоколу ISAKMP
Керуючі структури мови Сі Програмування з використанням покажчиків
Меню ПРАВКА редактора Word Опис усіх пунктів меню Правка редактора Word
Надійність людини як ланки складної технічної системи
Оцінка надійності людини як ланки складної технічної системи
Програма Txtprintcom - резидентна програма для швидкого і зручного друкування виборчого тексту
ОС Windows XP програма Провідник програма Total Commander
© Усі права захищені
написати до нас