Методи оцінки та засоби підвищення надійності програмного забезпечення (стр. 3 из 6)

У таблиці 1 представлені функції інтенсивності виявлення несправностей

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

, , , , .

де

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

Табл.1. Зв'язок між моделями негомогенного пуасонівського процесу

Назва моделі	Функція інтенсивності виявлення несправностей	Функція кумулятивної кількості несправностей
Модель Гоеля-Окумото
Модель Шнайдевінда
Базова модель Муси
S-подібна модель
Узагальнена модель негомогенного пуасонівського процесу

Застосуванням методу максимальної правдоподібності визначення параметрів

, та n зведено до розв’язання системи рівнянь:

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

n=0 – для невеликого проекту, в якому розробник є одночасно і тестером (моделі Муси, Гоеля-Окумото і Шнайдевинда);

n=1 – для середнього проекту, в якому тестування і проектування ПЗ виробляється різними людьми з однієї робочої групи (S-подібна модель);

n=2 – для великого проекту, в якому групи тестування і розробки ПЗ працюють над проектом паралельно;

n=3 – для дуже великого проекту, в якому відділи тестування і розробки незалежні.

На основі наданих експериментальних даних проведено ряд досліджень, який дозволив дослідити вигляд функцій кумулятивної кількості несправностей

запропонованої узагальненої моделі та інтенсивностей виявлення несправностей при різних вихідних даних та різних значеннях параметра n.

Наведені результати одного з експериментів демонструють, що найкраще наближення буде досягнуте при n=3, а найгірше – при n=0 (модель Муси, Шнайдевінда та Гоеля-Окумото). Це підтверджується і відповідними статистичними даними (табл.2), які характеризують різницю між вихідними даними (t_2) та відповідними значеннями функції

при різних значеннях n.

Табл. 2. Статистичні дані до різниці

при різних n і вихідних даних t_2

Статистичні показники	різниця функційt_2-	різниця функцій t_2-	різниця функцій t_2-	різниця функцій t_2-
Mean	16.13522	16.22889	19.88367	58.93807
Median	15.27700	14.11600	16.00000	60.89700
Maximum	33.58100	54.23600	49.10800	88.80200
Minimum	4.848000	-1.280000	4.175000	15.96200
Std. Dev.	8.374089	17.37143	14.07056	23.63765

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

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

Аналіз розпочато з класичних методів тестування: функціонального та структурного. При функціональному тестуванні програма розглядається як "чорна шухляда", тобто її текст не використовується. Відбувається перевірка відповідності поведінки програми її зовнішнім специфікаціям. Критерієм повноти тестування в цьому випадку є перебір усіх можливих значень вхідних даних, що не є завжди досяжним. В роботі детально проаналізовані такі види функціонального тестування: випадкове тестування; метод еквівалентного розбиття; метод аналізу граничних умов. Обґрунтовано, що їхнє застосування пов’язано з значними фінансовими витратами, причому локалізація несправностей не здійснюється.

При структурному тестуванні програма розглядається як "біла шухляда", тобто її текст відкритий для користування. Відбувається перевірка внутрішньої логіки. Критерієм повноти є перебір всіх можливих шляхів на графі передач управління програми. Навіть для середніх за складністю програм число таких шляхів може досягати десятків тисяч. Крім великої кількості необхідних тестових прикладів виникає питання про створення тестів, які забезпечують задане покриття. В розділі проаналізовані такі види структурного тестування: тестування на основі потоку управління і тестування на основі потоку даних. При використанні першого типу тестується логіка програми, яка представлена у виді графа управління: вершинами є оператори, а ребрами - переходи між ними. В другому випадку увага приділяється взаємозв'язкам між змінними. Виділяються вершини, у яких змінна ініціалізується або використовується, і вивчаються переходи і взаємозв'язки між такими вершинами.

З огляду на сучасні тенденції в розробці ПЗ, насамперед компонентно-базоване програмування, де найчастіше компоненти представлені як "чорні шухляди", вочевидь, що для них класичні методи структурного тестування, для яких рівень абстракції - це рівень операторів мови програмування, не застосовні. Структура такого ПЗ формалізується шляхом використання UML діаграм, які створюються на етапі ЖЦ ПЗ “аналіз вимог та проектування”. Отже, виникає необхідність у розробці спеціалізованих критеріїв тестування, починаючи з цього етапу ЖЦ ПЗ, а не з етапу тестування, як це було раніше.

У розділі сформульовано декілька критеріїв.

Критерій покриття інтерфейсу: кожна операція, оголошена в інтерфейсі повинна бути протестована принаймні один раз.

Критерій покриття інтерфейсів не є досить репрезентативним тому що він:

- повинний бути досягнутий на фазі модульного тестування;

- не розрізняє виклики, що виходять з різних компонентів.

Для того, щоб врахувати цю інформацію пропонується критерій покриття викликів операцій.

Нехай Cі позначає компонент Системи, і=1.. n, де n - кількість компонентів.

І(Cі) - Інтерфейс (Іnterface) компонента Cі.

sj,k - сервіс, оголошений у Ck,

j=1.. mk, де mk -кількість сервісів, оголошених у Ck критерій покриття викликів операцій має вигляд:

sj,k I(Ck), i, i=1.. n, i k, якщо можливо здійснити виклик sj,k з Cі, то тоді такий виклик необхідно протестувати хоча б один раз.