Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Аналіз_Вимог.doc
Скачиваний:
1
Добавлен:
01.04.2025
Размер:
1.85 Mб
Скачать

5.3.3.2 Тестування маршрутів

5.3.3.2.1 Тестування структури маршрутів програмних модулів виконують шляхом перевірки коректності виділених маршрутів виконання програм і виявлення логічних помилок формування маршрутів. На практиці за відсутності впорядкованого аналізу потоків управління деякі маршрути у програмі (до 50%) виявляються пропущеними під час тестування. Тому перше завдання, яке вирішують під час тестування структури програмних модулів, – це отримання інформації про повну сукупність реальних маршрутів виконання. Наочне подання реалізованих маршрутів дозволяє впорядковано контролювати повноту їхнього тестування та до деякої міри охороняє від випадкового пропуску окремих маршрутів. У результаті тестування набуває запланованого систематичного характеру. Для забезпечення коректності програми всі маршрути можливого виконання програмного модуля повинні бути перевірені під час її створення та тим самим визначають складність повного тестування.

5.3.3.2.2 Під час планування тестування маршрутів виникають, насамперед, два завдання:

– формування та відбір критеріїв для виділення маршрутів під час тестування;

– вибір стратегій упорядкування виділених маршрутів під час підготовки тестів.

5.3.3.2.3 Критерії виділення маршрутів для тестування відповідають критеріям визначення структурної складності програмних модулів. Використовують переважно такі критерії:

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

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

– виділення маршрутів для усіх можливих комбінацій дуг, які входять до маршрутів (критерій 3).

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

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

5.3.3.2.6 Упорядкування маршрутів під час планування тестування базується на використанні переважно трьох характеристик програмних модулів:

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

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

– імовірності виконання маршрутів під час функціонування програми (стратегія 3).

5.3.3.2.7 За умови використання стратегії 1 первинному тестуванню підлягають маршрути, найбільш довгі за числом рядків тексту та за часом виконання. Їм відповідають зазвичай маршрути з найбільшим обсягом обчислень і перетворень змінних. Ця стратегія є доцільною під час планування тестування програм, які мають обчислювальний характер оброблення даних з невеликим числом логічних умов і маршрутів виконання програм. Обрані первинні маршрути не обов'язково є найбільш складними за логікою функціонування.

5.3.3.2.8 За умови використання стратегії 2 пріоритет віддається маршрутам, найбільш складним за числом аналізованих умов розгалуження. Ця стратегія є найкращою під час тестування логічних програм з невеликим обсягом обчислень. Для обох стратегій на завершальні етапи тестування залишаються маршрути, прості за обсягом обчислень або за логікою, для яких необхідні відносно прості тести. Це відповідає традиційній стратегії, яка реалізує спочатку підготовку тестів з якомога більшим охопленням елементів структури програми, що налагоджується. В результаті вивчення структури програми виявляють найбільш критичні за тривалістю або найчастіші маршрути виконання програми. Такий підхід дозволяє сконцентрувати зусилля на перевірці найбільш активно функціонуючих компонентів і визначити слабко перевірені частини програми, які виконуються відносно рідко.

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

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

5.3.3.2.11 На рисунку 5.6 представлено приклад структурного графа програмного модуля, який має 14 вершин, 20 дуг і 3 цикли. Такий модуль порівняно невисокої складності містить близько 50 операторів, написаних мовою високого рівня та може розглядатися як досить типовий. Для повної перевірки модуля за критерієм 1 достатньо чотирьох маршрутів (див. рисунок 5.7). За цим критерієм гарантується перевірка усіх передач управління між операторами програми та кожного оператора не менше одного разу. Найдовший за числом вершин маршрут не охоплює тільки 3 вершин з 14 і тільки 6 дуг з 20.

Рисунок 5.6—Приклад графа структури програмного модуля

5.3.3.2.12 Після перевірки ще двох маршрутів поза контролем залишається одна вершина та дві дуги. Однак по цьому критерію не враховується комбінаторика сполучення умов на різних ділянках маршрутів, наприклад, при сполученнях напрямків розгалужень у вершинах 3 і 12. Складність тестування характеризує сумарне число умов, які необхідно задати у тестах для повної перевірки усіх маршрутів, виділених за критерієм 1. Умови у вершинах кожного маршруту можуть використовуватися для автоматизованого формування предикатів у відповідних тестах.

Рисунок 5.7—Маршрути, які виділено у графі структури програмного модуля за критерієм 1

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

Рисунок 5.8—Маршрути, які виділено у графі структури програмного модуля за критерієм 2

5.3.3.2.14 Найбільш глибокий критерій 3 перевірки та визначення складності тестування структури програми включає вимоги однократної перевірки не тільки лінійно незалежних, але й усіх лінійно залежних циклів і ациклічних маршрутів. Він полягає в аналізі хоча б один раз кожного з реальних ациклічних маршрутів вихідного графа програми та кожного циклу, досяжного з усіх цих маршрутів. Для прикладу графа програми, представленого на рис. 5.6, за даним критерієм необхідно виконати 6 ациклічних маршрутів і 5 маршрутів, з яких досяжні елементарні цикли. Для реалізації виділених маршрутів у 11 тестах необхідно в сукупності задати 66 умов. При цьому особливістю чотирьох останніх маршрутів із циклами, а також відповідних їм ациклічних маршрутів, є повний перебір сполучень розгалужень у вершинах 3 і 12. У реальних програмах деякі маршрути можуть виявитися нереалізованими через несумісність умов, які послідовно аналізуються у різних вершинах. З іншого боку, для кожного реалізованого маршруту може бути необхідна перевірка за декількома проходженнями циклів і декількох значень кожної оброблюваної змінної.