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

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

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

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

З огляду на сучасні тенденції в розробці ПЗ, насамперед компонентно-базоване програмування, де найчастіше компоненти представлені як "чорні шухляди", вочевидь, що для них класичні методи структурного тестування, для яких рівень абстракції - це рівень операторів мови програмування, не застосовні. Структура такого ПЗ формалізується шляхом використання 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і, то тоді такий виклик необхідно протестувати хоча б один раз.

Для врахування контексту даних було введено критерій покриття активізації інтерфейсу: Cі- компонент, Ci System, i=1.. n, де n - кількість компонентів

діаграми станів компонента Ci - State-Chart Diagram SD(Ci),

t – перехід (Transition), t= (Source, Target, Trigger, Effect, Guard),

якщо t SD(Ci), та Effect i, то t повинно бути протестовано хоча б раз під час інтеграційного тестування.

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

СDj – діаграма взаємодії (collaboration diagram); CDj System; j=1..J, де J – кількість діаграм взаємодії в системі.

Sl,j – послідовність повідомлень; Sl,j СDj; i=1..nj, де nj – кількість послідовностей в діаграмі взаємодії СDj

Sl,j={mk}l,j, k=1..rl,j, rl,j - кількість повідомлень в послідовності Sl,j

mk – повідомлення в послідовності;

Ci – компонент; Cl System; l=1..n, де n – кількість компонентів в системі

SD (Ci) – діаграма станів (state-chart diagram of component Ci)

tg,i – перехід (transition), tg,i SD (Ci), g=1..ni; ni – кількість переходів в діаграмі станів SD(Ci)

mk - повідомлення між компонентами Ci1 та Ci2.

mk tg1,i1 Ci1 | Effect(tg1,i1)=Name(mk)

tg2,i2 Ci2 | Trigger(tg2,i2)=Name(mk).

Тоді mk може бути представлено як: mk = ( tg1,i1, tg2,i2)k (*)

Позначимо:

Te(mk)={ tg1,i1| Effect(tg1,i1)=Name(mk) }

Tt(mk)={ tg2,i2| Trigger(tg2,i2)=Name(mk) }

Визначимо |T| як кількість елементів у множині T

|Te(mk)| ;|Tt(mk)|t

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

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

Для того, щоб обробити інформацію про порядок взаємодії було введено поняття відношення залежності: активізація Іnv2 пов'язана відношенням залежності з активізацією Іnv1, якщо існує шлях (executіon path), при якому активізація Іnv1 викликає активізацію Іnv2. Будемо говорити, що Іnv2 пов'язане з Іnv1 послідовністю активізацій, яка реалізує відношення залежності між цими двома активізаціями.

Критерій покриття залежностей: кожна послідовність активізацій, яка реалізує кожне відношення залежності, повинна бути протестована хоча б один раз.

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

Критерій покриття послідовностей викликів операцій: кожна послідовність повідомлень mk (*) у кожній діаграмі взаємодій UML повинна бути протестована хоча б один раз.

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

Критерій покриття послідовностей активізацій: кожна послідовність активізацій mk=(tg1,l1, tg2,l2)k (*) у кожній діаграмі взаємодії повинна бути протестована хоча б один раз.

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

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

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

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

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

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

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

Нехай

а .

Введемо булеву змінну:

Тоді задача оптимізації вартості, при обмеженнях на час проведення тестування буде мати вигляд:

де K – кількість виділених груп об’єктів тестування, Jk – множина елементів функціональності, які мають бути протестовані для k-ої групи об’єктів тестування.

Обмеження:

1. На час (враховуючи можливість паралельного тестування):

,

де Тk –час, виділений на тестування кожної з груп об’єктів

2. Групового вибору (тести для різних типів елементів функціональності різних груп об’єктів не перетинаються, і необхідно вибрати один тест для кожного елементу):

, Æ,

якщо , , - множина всіх елементів функціональності.

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

Четвертий розділ присвячено практичному дослідженню розроблення та функціонування модуля управління надійністю як складової частини системи автоматизованого проектування інформаційних систем (ІС).

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

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

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

Експериментальне дослідження модуля високорівневого тестування було здійснено з використанням спроектованої компонентно-базованої системи віддаленої взаємодії користувача, авіакомпанії, туристичного агентства і банку – “Base - IT.Com”. В ході тестування було виявлено ряд помилок у структурі спроектованої компонентно-базованої системи, які могли б призвести до значних фінансових втрат та були пов’язані з паралельним виконанням послідовностей операцій.