ухляда", тоб ее текст не вікорістовується. Відбувається перевірка відповідності поведінкі програми ее зовнішнім спеціфікаціям. Крітерієм повнотіла тестування в цьом випадка є перебір усіх можливіть значень вхідніх даніх, что НЕ є всегда досяжнім. У работе детально проаналізовані Такі види функціонального тестування: випадкове тестування; метод еквівалентного розбіття; метод аналізу граничних умов. Обгрунтовано, что їхнє! Застосування пов'язано з значний фінансовімі витратами, причому локалізація несправностей НЕ здійснюється.
При структурному тестуванні програма розглядається як "біла шухляда", тоб ее текст Відкритий для КОРИСТУВАННЯ. Відбувається перевірка внутрішньої логікі. Крітерієм повнотіла є перебір всех можливіть Шляхів на графі передач управління програми. Даже для середніх за складністю програм число таких Шляхів может досягаті десятків тисяч. Крім Великої кількості необхідніх тестових прікладів вінікає питання про создания тестів, Які Забезпечують завданні покриття. У розділі проаналізовані Такі види структурного тестування: тестування на Основі потоку управління и тестування на Основі потоку даніх. При вікорістанні Першого типом тестується логіка програми, яка представлена ​​у віді графа управління: вершинами є оператори, а ребрами - переходь между ними. У іншому випадка увага пріділяється взаємозв'язкам между зміннімі. Віділяються вершини, у якіх змінна ініціалізується або вікорістовується, и вівчаються переходь и взаємозв'язкі между такими вершинами. p> Зх Огляду на Сучасні Тенденції в розробці ПЗ, самперед компонентно-базоване програмування, де найчастіше компоненти представлені як "чорні Шухляда ", вочевідь, что для них Класичні методи структурного тестування, для якіх рівень абстракції - це рівень Операторів мови програмування, що не застосовні. Структура такого ПЗ формалізується Шляхом Використання UML діаграм, Які створюються на етапі ЖЦ ПЗ "аналіз вимог та проектування". Отже, вінікає необхідність у розробці спеціалізованіх крітеріїв тестування, починаючі з цього Етап ЖЦ ПЗ, а не з етапу тестування, Як це було раніше.
У розділі сформульовано декілька крітеріїв.
Крітерій покриття інтерфейсу: шкірний Операція, оголошено в інтерфейсі винна буті Протестували прінаймні один раз.
Крітерій покриття інтерфейсів НЕ є й достатньо репрезентативну того что ВІН:
- повинною буті досягнутості на фазі модульного тестування;
- НЕ розрізняє Виклики, что Прокуратура: з різніх компонентів.
Для того, щоб врахуваті Цю інформацію Пропонується крітерій покриття вікліків операцій. p> Нехай CІ позначає компонент Системи, і = 1 .. n, де n - кількість компонентів.
І (cІ) - Інтерфейс (Іnterface) компонента cІ. p> sj, k - Сервіс, Оголошення у Ck,
j = 1 .. mk, де mk-кількість сервісів, оголошених у Ck крітерій покриття вікліків операцій має вигляд:
sj, kI (Ck), i, i = 1 .. n, ik, ЯКЩО Можливо здійсніті виклик sj, k з cІ, то тоді такий виклик звітність, протестуваті хочай б один раз.
Для врахування контексту даніх Було введено крітерій покриття актівізації інтерфейсу: cІ-компонент, CiSystem, 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); CDjSystem; 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 - Компонент; ClSystem; 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. br/>
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
Позначімо кількість можливіть комбінацій между переходами, Які віклікають та Тімі, что відповідають через и візначімо ее Наступний чином: Вочевідь, что чім больше значення, а тім больше нужно тестів.
Критерії, наведені...
