Розділ 2 функціональне тестування програмного забезпечення

Тема 2.1 Спосіб тестування діаграм причин-наслідків

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

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

Кроки способу:

1)для кожного модуля перераховуються причини (умови введення або класи еквівалентності умов введення) і наслідки (дії або умови виводу). Кожній причині й наслідку привласнюється свій ідентифікатор;

2) розробляється граф причинно-наслідкових зв'язків;

3) граф перетвориться в таблицю рішень;

4) стовпці таблиці рішень перетворяться в тестові варіанти.

Зобразимо базові символи для запису графів причин і наслідків (cause-effect graphs).

Зробимо попередні зауваження:

1) причини будемо позначати символами сi, а наслідку — символами еi;

2)кожний вузол графа може перебувати в стані 0 або 1 (0 — стан відсутній, 1 — стан присутній).

Функція тотожність (мал. 2.1) установлює, що якщо значення с1 є 1, то й значення е1 є 1; у противному випадку значення е1 є 0.

Мал. 2.1 Функція тотожність

Функція не (мал. 2.2) встановлює, що якщо значення с1 є 1, то значення e1 є 0; у противному випадку значення е1 є 1.

Мал. 2.2. Функція не

Функція або (мал. 2.3) встановлює, що якщо с1 або с2 є 1, то е1 є 1, у противному випадку e1 є 0.

Мал. 2.3 Функція або

 

Функція і (мал. 2.4) встановлює, що якщо й с1 і с2 є 1, то е1 є 1, у противному випадку е1 є 0.

Часто певні комбінації причин неможливі через синтаксичні або зовнішні обмеження. Використаються перераховані нижче позначення обмежень.

Мал. 2.4 Функція і

Обмеження Е (виключає, Exclusive, мал. 2.5) встановлює, що Е повинне бути істинним, якщо хоча б одна із причин — а або b — приймає значення 1 (а і b не можуть приймати значення 1 одночасно).

Мал. 2.5. Обмеження Е (виключає, Exclusive)

Обмеження I (включає, Inclusive, мал. 2.6) встановлює, що принаймні одна з величин, а, b, або с, завжди повинна бути рівної 1 (а, b і с не можуть приймати значення 0 одночасно).

Мал. 2.6. Обмеження I (включає, Inclusive)

Обмеження О (одне й тільки одне, Only one, мал. 2.7) встановлює, що одна й тільки одна з величин а або b повинна дорівнювати 1.

Мал. 2.7. Обмеження О (одне й тільки одне, Only one)

Обмеження R (вимагає, Requires, мал. 2.8) встановлює, що якщо а приймає значення 1, то й b повинна приймати значення 1 (не можна, щоб а було рівне 1, a b - 0).

Мал. 2.8. Обмеження R (вимагає, Requires)

 

Часто виникає необхідність в обмеженнях для наслідків. Обмеження М (приховує, Masks, мал. 2.9) встановлює, що якщо наслідок а має значення 1, то наслідок b повинне прийняти значення 0.

Мал. 2.9. Обмеження М (приховує, Masks)

 

Контрольні запитання:

1. Дайте визначення діаграм причин – наслідків.
2. Які кроки побудови діаграм причин-наслідків?
3. Які обмеження використовуютьс при побудові діаграм причин – наслідків?

 

Тема 2.2 Тестування елементів

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

Об'єктом тестування елементів є найменша одиниця проектування ПС - модуль. Для виявлення помилок у рамках модуля тестуються його найважливіші керуючі шляхи. Відносна складність тестів і помилок визначається як результат обмежень області тестування елементів. Принцип тестування - «білий ящик», крок може виконуватися для набору модулів паралельно.

Тестуванню піддаються:

- інтерфейс модуля;

- внутрішні структури даних;

- незалежні шляхи;

- шляхи обробки помилок;

- граничні умови.

Інтерфейс модуля тестується для перевірки правильності вводу-виводу тестової інформації. Якщо немає впевненості в правильному вводі-виводі даних, нема рації проводити інші тести.

Дослідження внутрішніх структур даних гарантує цілісність даних, що зберігаються.

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

Найбільш загальними помилками обчислень є:

1) неправильний або незрозумілий пріоритет арифметичних операцій;

2) змішана форма операцій;

3) некоректна ініціалізація;

4) непогодженість у поданні точності;

5) некоректне символічне подання виражень.

Джерелами помилок порівняння й неправильних потоків керування є:

1) порівняння різних типів даних;

2) некоректні логічні операції й пріоритетність;

3)очікування еквівалентності в умовах, коли помилки точності роблять еквівалентність неможливої;

4) некоректне порівняння змінних;

5) неправильне припинення циклу;

6) відмова у виході при відхиленні ітерації;

7) неправильна зміна змінних циклу.

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

1) повідомлення про помилку незрозуміло;

2) текст повідомлення не відповідає, виявленій помилці;

3) втручання системних засобів реєстрації аварії відбулося до обробки помилки в модулі;

4) обробка виняткової умови некоректна;

5) опис помилки не дозволяє визначити її причину.

І, нарешті, перейдемо до граничного тестування. Модулі часто відмовляють на «границях». Це означає, що помилки часто відбуваються:

1) при обробці n-го елемента n-елементного масиву;

2) при виконанні m-ї ітерації циклу з m проходами;

3) з появою мінімального (максимального) значення.

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

Мал. 2.10 Програмне середовище для тестування модуля

 

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

Мал.2.11 Алгоритм роботи драйвера тестування

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

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

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

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

 

Контрольні запитання:

1. Що є предметом тестування елементів?

2. Який принцип використовується при тестуванні елементів?

3. Які елементи тестуються?

4. Дайте поняття програмного середовища для тестування.

5. Наведіть алгоритм роботи тестового драйвера.

6. Що розуміють під заглушками та драйверами?

Тема 2.3 Переваги та недоліки низхідного та висхідного тестування

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

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

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

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

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

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

Наприклад, порядок тестування комплексу K при спадному тестуванні може бути таким, як показано в прикладі, де тестовий набір, розроблений для модуля Mi, позначений як XYi = (X, Y)i. Можливий порядок тестів при спадному тестуванні

1) K->XYK

2) M1->XY1

3) M11->XY11

4) M2->XY2

5) M22->XY22

6) M21->XY21

7) M12->XY12

Недоліки спадного тестування:

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

2) Складність організації й розробки середовища для реалізації виконання модулів у потрібній послідовності

3) Паралельна розробка модулів верхніх і нижніх рівнів приводить до не завжди ефективної реалізації модулів через підстроювання (спеціалізації) ще не тестованих модулів нижніх рівнів до вже відтестованих модулів верхніх рівнів

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

Наприклад, порядок тестування комплексу K при висхідному тестуванні може бути наступним. Можливий порядок тестів при висхідному тестуванні

1) M11->XY11

2) M12->XY12

3) M1->XY1

4) M21->XY21

5) M2(M21, Stub(M22))->XY2

6) K(M1, M2(M21, Stub(M22)) ->XYK

7) M22->XY22

8) M2->XY2

9) K->XYK

Недоліки висхідного тестування:

1)Запізнювання перевірки концептуальних особливостей комплексу, що тестується.

2) Необхідність у розробці й використанні драйверів

Порівняння спадного й висхідного тестування інтеграції

Спадне тестування:

1) основний недолік— необхідність заглушок і пов'язані з ними труднощі тестування;

2) основне достоїнство — можливість раннього тестування головних керуючих функцій.

Висхідне тестування:

1) основний недолік — система не існує як об'єкт доти, поки не буде доданий останній модуль;

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

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

Контрольні запитання:

1. Поняття монолітного та інкрементного тестування.

2. Порівняльна характеристика низхідного та висхідного тестування.

Тема 2.4 Стресове тестування та тестування виробності

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

 

На попередніх кроках тестування способи «білого» і «чорного ящиків» забезпечували повну оцінку нормальних програмних функцій і якості функціонування. Стресові тести проектуються для нав'язування програмам ненормальних ситуацій. По суті, проектувальник стресового тесту запитує, як сильно можна розхитати систему, перш ніж вона відмовить?

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

Приклади:

генерується 10 переривань у секунду (при середній частоті 1,2 переривання в секунду);

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

формуються варіанти, що вимагають максимуму пам'яті й інших ресурсів;

генеруються варіанти, що викликають переповнення віртуальної пам'яті;

проектуються варіанти, що викликають надмірний пошук даних на диску.

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

Тестування продуктивності.

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

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

Контрольні запитання:

1. Суть стресового тестування
2. Суть тестування виробності (продуктивності).

Тема 2.5 Переваги та недоліки різних методів відлагодження

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

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

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

1. Видача значень змінних у зазначених точках.

2. Трасування змінних (видача їхніх значень при кожній зміні).

3. Трасування потоків керування (імен викликуваних процедур, міток, на які передається керування, номерів операторів переходу).

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

Недолік експериментальних методів налагодження — у програму вносяться зміни, при виключенні яких можуть з'явитися помилки. Втім, деякі системи програмування створюють спеціальний отладочный екземпляр програми, а в основний екземпляр не втручаються.

 

 

Контрольні запитання:

1. Які переваги та недоліки має застосування аналітичних методів налагодження?

2. Які переваги та недоліки має застосування експериментальних методів налагодження?

 

РОЗДІЛ 3 ОБ ' ЄКТНО – ОРІЄНТОВАНЕ ТЕСТУВАННЯ

Тема 3.1 Особливості інтеграційного тестування для об’єктно-орієнтованого програмування

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

Тестування об'єктно-орієнтованих програмних засобів (ООПЗ) має ряд істотних відмінностей від класичного тестування:

-розширення області застосування тестування;

-зміна методики тестування;

-облік особливостей ООП при проектуванні тестових варіантів.

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

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

Критерії тестування моделей. Моделі розроблювальної системи повинні задовольняти критеріям:

-синтаксичної й семантичної правильності,

-повноти,

-погодженості.

Правильність моделі. Синтаксична правильність пов'язана з коректним використанням нотацій язика опису моделей.

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

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

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

Найменшим елементом об'єктно-орієнтованого ПЗ, що тестується, є не процедура, а клас. Оскільки клас містить набір властивостей і методів, що утворюють єдину сутність, ізольоване тестування методів не має змісту.

Методи повинні тестуватися в контексті приватних властивостей і операцій класу.

Тестування класів

Автономне тестування класу припускає розробку драйвера, що буде:

-створювати екземпляри классу, що тестується;

-викликати методи классу, що тестується, й передавати їм фактичні параметри з тестових варіантів;

-приймати результати виконання методів, що тестуються.

Екземпляри окремих класів активно взаємодіють між собою.

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

Рішення про автономне тестування класу приймається з урахуванням наступних факторів:

-ролі класу в системі;

-складності класу, вимірюваної числом станів, операцій і зв'язків з іншими класами;

-обсягу трудозатрат, пов'язаних з розробкою тестового драйвера.

Види взаємодії класів:

1. Метод одного класу містить у списку своїх формальних параметрів імена інших класів.

2. Метод одного класу створює екземпляр іншого класу як частину своєї реалізації

3. Метод одного класу посилається на глобальний екземпляр іншого класу

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

Особливості методики інтеграційного тестування об'єктно-орієнтованих систем. Тестування кластерів і потокове тестування. Тестування інтеграції

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

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

Основне завдання - виділення підмножини взаємодіючих класів.

Види взаємодії класів:

1. Метод одного класу містить у списку своїх формальних параметрів імена інших класів.

2. Метод одного класу створює екземпляр іншого класу як частину своєї реалізації

3.Метод одного класу посилається на глобальний екземпляр іншого класу

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

-тестування, засноване на потоках;

-кластерное тестування.

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

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

Розмір кластера. При малих розмірах кластера неможливе відтворення в повному обсязі ефекту інтеграції (системного ефекту).

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

Середовище тестування. Тестування кластерів можна проводити:

- безпосередньо в середовищі додатка (потрібно виділяти результати тестування із загальних інформаційних потоків у програмній системі; результати тестування відповідають реальним умовам експлуатації);

- у середовищі, спеціально створеному тестуючим драйвером (результати тестування виходять в «чистому» вигляді; відповідність результатів тестування реальним умовам експлуатації залежить від ступеня адекватності цим умовам створеної драйвером середовища тестування).

 

Контрольні запитання:

1. Критерії тестування моделей ООПЗ.
2. Дайте поняття тестування класів.
3. Які фактори впливають на рішення про автономне тестування класів?
4. Які види взаємодії класів використовуються?
5. Дайте поняття тестуванню ООПЗ, заснованого на потоках.
6. Дайте визначення та призначення тестування кластерів.

Тема 3.2 Переваги та недоліки системного та регресійного тестування

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

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

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

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

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

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

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

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

- функціональне тестування;

- тестування продуктивності;

- навантажувальне або стресове тестування;

- тестування конфігурації;

- тестування безпеки;

- тестування надійності й відновлення після збоїв;

- тестування зручності використання.

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

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

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

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

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

 

Контрольні запитання:

1. Для чого призначені системні тести?
2. Які характеристики перевіряються на етапі системного тестування?
3. Який недолік має системне тестування?
4. Які види системного тестування розрізняють?
5. Для чого використовується регресійне тестування?
6. Які типи дефектів знаходять з допомогою регресійного тестування?
7. Чому регресіне тестування є коштовним?
8. Яка мета регресійного тестування?

 

Тема 3.3 Тестування поверхневої та поглибленої структури системи

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

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

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

Як базис для тестування глибинної структури використаються моделі аналізу й проектування. Наприклад, розроблювач досліджує діаграму взаємодії (невидиму ззовні) і запитує: «чи Перевіряє тест співробітництво, відзначене на діаграмі?»

Діаграми класів забезпечують розуміння структури спадкування, що використається в тестах, заснованих на помилках. Розглянемо операцію ОБРОБИТИ (Посилання_на_Родительскийкласс). Що відбудеться, якщо у виклику цієї операції вказати посилання на дочірній клас? Є чи розходження в поводженні, які повинні відбиватися в операції ОБРОБИТИ? Ці питання ініціюють створення конкретних тестів.

 

Контрольні запитання:

1. Поняття поверхневої структури об'єктно-орієнтованої системи та особливості її тестування.
2. Поняття глибинної структури об'єктно-орієнтованої системи та особливості її тестування.

 

Тема 3.4 Тестування взаємодії класів

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

 

Для тестування співробітництва класів можуть використатися різні способи:

- стохастичне тестування;

- тестування розбивок;

- тестування на основі сценаріїв;

- тестування на основі станів.

Як приклад розглянемо програмну модель банківської системи, до складу якої входять класи Банк, Банкомат, ІнтерфейсБанкомата, Рахунок, Робота з готівкою, ПідтвердженняПравильності, що мають наступні операції:

Банк:
ПроверитьСчет();	ЗапросДепозита ();	РазрешитьКарту();
ПроверитьРIN();	ИнфоСчета();	СнятьРазрешен();
ПроверитьПолис();	ОткрытьСчет();	ЗакрытьСчет().
ЗапросСнятия();	НачальнДепозит();
Банкомат:
КартаВставлена();	Покласти();	СостояниеСчета();
Пароль();	Зняти();	Завершити().
ИнтерфейсБанкомата:
ПроверитьСостояние();	ВыдатьНаличные();	ЧитатьИнфоКарты();
СостояниеПоложить();	ПечатьСостСчета();	ПолучитьКолвоНалич().
Счет:
ОграничКредит();	Залишок));	Покласти();
ТипСчета();	Зняти();	Закрити().
ПодтверждениеПравильности:
ПодтвРIN();	ПодтвСчет().

 

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

Мал. 3.1. Діаграма співробітництва банківської системи

Стохастичне тестування

Стохастичні тестові варіанти генеруються наступною послідовністю кроків.

Для створення тестів використають списки операцій кожного класу-клієнта. Операції будуть посилати повідомлення в класи-сервери.

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

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

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

Як приклад приведемо послідовність операцій для класу Банк, викликуваних класом Банкомат:

ПроверитьСчет ►ПроверитьРIN ►[[ПроверитьПолис ►

ЗапросСнятия]●ЗапросДепозита●ИнфоСчета]ⁿ.

ПРИМІТКА

Тут прийняті наступні позначення: стрілка означає операцію проходження, крапка - операцію І/АБО, пара квадратних дужок - угруповання операцій класів, показник ступеня - кількість повторень угруповання з операцій класів.

Випадковий тестовий варіант для класу Банк може мати вигляд

Тестовий варіант N: ПроверитьСчет ►ПроверитьРШ ►ЗапросДепозита.

Для виявлення співробітників, включених у цей тест, розглядаються повідомлення, пов'язані з кожною операцією, записаної у ТВ N. Для виконання завдань Проверитьсчет і ПроверитьРТМ Банк повинен співробітничати із класом ПодтверждениеПравильности. Для виконання завдання ЗапросДепозита Банк повинен співробітничати із класом Счет. Звідси новий ТВ, що перевіряє відзначені співробітництва:

Тестовий варіант М:

ПроверитьСчетБанк►(ПодтвСчетПодтвПрав)►ПроверитьРINБанк ►(ПодтвРШПодтвПрав) ►ЗапросДепозитаБанк ►(ПоложитьСчет).

У цій послідовності операції класів-співробітни