Конспект лекцій для студентів напряму підготовки 050102 «Комп’ютерна інженерія» денної та заочної форм навчання



Сторінка2/4
Дата конвертації09.04.2017
Розмір0.59 Mb.
1   2   3   4

ТЕМА: МОДУЛЬНЕ ТЕСТУВАННЯ

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



Структура середовища модульного тестування

На рівні модульного тестування простіше всього знайти дефекти, пов'язані з алгоритмічними помилками і помилками кодування алгоритмів, пов’язані з умовами (if, switch) і лічильниками циклів, а також з використанням локальних змінних. Помилки, пов'язані з невірним трактуванням даних, некоректною реалізацією інтерфейсів, сумісністю, продуктивністю звичайно пропускаються на рівні модульного тестування і виявляються на наступних стадіях тестування.

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

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

Призначення драйверів і заглушок

Драйвери (drivers) і заглушки (stubs)

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

Виклик модуля, що тестується

1 + передача в модуль вхідних значень і прийом результатів

2 + виведення результатів

3 + протоколювання процесу тестування і ключових точок програми
Заглушки можуть виконувати наступні функції:

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

2. Виводити повідомлення про те, що заглушка була викликана

3. 1 + виводити повідомлення із значеннями параметрів, переданих у функцію

4. 2 + повертати значення, наперед задане у вхідних параметрах тесту

5. 3 + виводити значення, наперед задане у вхідних параметрах тесту


Для тестування програмного коду, написаного на процедурних мовах програмування використовуються програмні драйвери, що мають точку входу (наприклад, функція main()), функцію запуску модуля, що тестується, і функцію аналізу результатів. Найпростіший драйвер має як мінімум одну функцію – точку входу, якій передається управління при його виклику.

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

Приклад тестового драйверу.

#include

#include

using namespace std;

double Power (int x, int n) {

double res = x;

for (int i = 1; i < n; i++)

res *= x;

return res;

//return powl(x, n);

}
void main () {

int x, n;

double res;
cout << " X to the power N" << endl << " x = [1..100]; n = [0..50]\n" << endl;

cout << " x = ";

cin >> x;

cout << " n = ";

cin >> n;
if (x > 0 && x <= 100) {

if (n >=0 && n <=50) {

res = Power (x,n);

cout << " res = ";

cout << res << endl;

} else {


cout << "\n\tError! \n N must be in [0..50]\n" << endl;

}

} else {



cout << "\n\t Error! \n X must be in [1..100]\n" << endl;

}

}


ЛЕКЦІЯ № 4
ТЕМА: ТЕСТУВАННЯ ОБ'ЄКТНО-ОРІЄНТОВАНИХ ПРОГРАМ
Специфіка тестування ООП пов'язана, в першу чергу, з:

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

керованою подіями природою ОПП, що вимагає тестування не лише структури програми, але і її поведінки.

На модульному рівні виконується автономне тестування класів: їх структури і методів (функцій-членів) традиційними методами, базованими на коді.

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

На рівні системи застосовується тестування за сценаріями використання (прецедентами) – починаючи з аналізу вимог і проектування ПС.


Особливості середовища тестування ООП

Середовище тестування для об'єктно-орієнтованих програм (ООП) виконує ті самі функції, що і для структурних програм (на процедурних мовах). Проте, воно має деякі особливості, зв'язані з використанням наслідування і інкапсуляції.

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

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

За цих причин модульне тестування ООП складніше ніж структурних.

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

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

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

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

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

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

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

Таким чином, ієрархія класів може тестуватися зверху вниз, починаючи від базового класу. Середовище тестування при цьому може мінятися для кожної конфігурації класів, що тестуються.
ЛЕКЦІЯ № 5
ТЕМА: ФУНКЦІОНАЛЬНЕ ТЕСТУВАННЯ
Методи функціонального тестування відносять до стратегій чорного ящика (без доступу до коду). Вони застосовуються для тестування зовнішніх і внутрішніх функцій програми і потребують наявності специфікації (формальної або не формальної), використовуваної як еталон. Методи тестування відрізняються між собою підходами до вибору тестових даних з множини входів (вхідного простору) функцій.

Методи функціонального тестування не є альтернативою методам, базованим на коді. Вони доповнюють один одного і призначені для виявлення іншого класу помилок, а саме:



  • некоректних або відсутніх функцій;

  • помилок інтерфейсу;

  • помилок в зовнішніх структурах даних або в доступі до зовнішньої бази даних;

  • помилок характеристик (необхідна місткість пам'яті і т. д.);

  • помилок ініціалізації і завершення.

Подібні категорії помилок методами, базованими на коді не виявляються.

Методи функціонального тестування орієнтовані на рішення наступних задач:

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

- виявлення класів помилок, а не окремих помилок.



Метод еквівалентного розбиття

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

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

Клас еквівалентності — набір даних з однаковими властивостями. Обробляючи різні елементи класу, програма повинна поводитися однаково.

Віднесення групи тестів до одного класу еквівалентності може ґрунтуватися на наступних практичних критеріях:


  • тести включають значення одних і тих самих вхідних даних;

  • при запуску тестів виконуються одні й ті самі операції;

  • від виконання тестів очікуються однакові результати;

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

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

Після побудови класів еквівалентності розробляються тести. Тест вибирається так, щоб перевірити відразу найбільшу кількість властивостей класу еквівалентності.

Тести розробляються спочатку для допустимих класів еквівалентності, а потім – для неприпустимих:

- для допустимих: по одному тесту всередині класу і по одному на границях класу (наприклад, якщо параметр програми містить список, потрібно із списку вибрати перший, останній і будь-який проміжний елемент, а для числових значень в діапазоні від 1 до 100, вибрати 1, 100 і будь-яке число всередині діапазону);

для неприпустимих: по одному тесту для кожного класу (наприклад, для числових значень з наведеного прикладу - вибрати 0 і 101, пробіл і нечисловий символ).

Аналіз граничних значень

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

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

Різниця між цим методом і методом еквівалентного розбиття полягає в наступному:

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

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

Правила аналізу граничних значень.

1. Якщо вхідна умова задає діапазон п...т, то тести повинні бути побудовані:

для значень п і т;

для значень зліва п і зліва т на числовій осі.

2. Якщо вхідна умова задає дискретну множину значень, то створюються тести:

для перевірки мінімального і максимального значень;

для значень трохи менше мінімуму і трохи більше максимуму.

Так, якщо вхідний файл може містити від 1 до 255 записів, то створюються тести для 0, 1, 255, 256 записів.

3. Правила 1 і 2 застосовуються до умов області виведення.

Методика виконання тестів еквівалентності:

Виконати 1 тест з допустимого класу.

Виконати тести на границях класу (2 тести).

Виконати тести поза границь (в кожному з неприпустимих класів).

Приклад:


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

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

2. Перевірити, що у тому випадку, коли довжина імені файла перевищує 11 символів система видає повідомлення про помилку

3. Перевірити, що система не розрізняє регістр символів імені при відкритті файла.

4. Перевірити, що при відкритті файлів з іменами, що не суперечать вимогам 1-3, система відкриває файл.

Вхідними значеннями тесту є різні імена файлів

вихідними – реакція системи (помилка або успішне відкриття).

Можна виділити наступні класи еквівалентності:

По довжині імені:


  • Довжина імені менше 11 символів

  • Довжина імені рівна 11 символам

  • Довжина імені більше 11 символів

  • По символах:

  • Ім'я, що складається з цифр і букв змішаного регістра

  • Ім'я, що складається з цифр і букв нижнього регістра

  • Ім'я, що складається з цифр і букв верхнього регістра

  • Ім'я, що складається тільки з цифр

  • Ім'я, що складається тільки з букв

  • Ім'я, що включає розділові знаки (не буквено-цифрові символи)

  • Ім'я, що включає управляючі символи (не буквено-цифрові символи)

Практично для будь-яких даних, навіть текстових, можна визначити «мінімальні» і «максимальні» допустимі значення.

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

Послідовність дій, необхідних для тестування.

1. Аналіз специфікації.

Специфікація програми.

Метод обчислення функції y=x^n.

На вхід програма приймає два параметри:

х - число, n – ступінь. Результат обчислення виводиться на консоль.

Значення числа і ступеня повинні бути цілими.

Значення числа, що підноситься до ступеня, повинні лежати в діапазоні – [0..999].

Значення ступеня повинні лежати в діапазоні – [1..100].

Якщо вхідні дані лежать за межами вказаних діапазонів, то повинне видаватися повідомлення про помилку.

2. Визначення області еквівалентності вхідних параметрів.

Для х – числа, що підноситься до ступеня, визначимо класи можливих значень:

1) х < 0 (помилкове)

2) х > 999 (помилкове)

3) х - не число (помилкове)

4) 0 < х < 999 (коректне)

Для n – ступеня числа:

5) n < 1 (помилкове)

6) n > 100 (помилкове)

7) n - не число (помилкове)

8) 1 < n <100 (коректне)

3. Аналіз тестових ситуацій

1. Вхідні значення: (х = 2, n = 3) (покривають класи 4, 8).

Очікуваний результат: Power n х is 8.

2. Вхідні значення: {(х = -1, n = 2)(х = 1000, n = 5 )} (покривають класи 1, 2).

Очікуваний результат: Error : х must be in [0..999].


3. Вхідні значення: {(х = 100, n = 0)(х = 100, n = 200)} (покривають класи 5,6).

Очікуваний результат: Error : n must be in [1..100].

4. Вхідні значення:(х = ADS n = ASD) (покривають класи еквівалентності 3, 7).

Очікуваний результат: Error : Please enter numeric argument.

5. Перевірка на граничні значення:

5.1 Вхідні значення: (х = 999 n = 1). Очікуваний результат: Power n х is 999.

5.2 Вхідні значення: х = 0 n = 100. Очікуваний результат: Power n х is 0.
3. Виконання тестів

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

4. Оцінка результатів виконання програми на тестах

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


1. Специфікація програми

На вхід програма приймає два параметри:

х – число (значення кута в радіанах), n – ступінь. Результат обчислення присвоїти змінній y та вивести на консоль.

Значення 0<=х<=1,570796.

Значення n >0 – ціле число. Знайти верхню границю n (наприклад, n=150), після якої виникає переповнення розрядної сітки.
2. Розробка тестів – на основі специфікацій методом розбиття на класи еквівалентності. Для порівняння отриманих значень з очікуваними використовується функція sin(x)

Для х – числа, що підноситься до ступеня, визначимо класи можливих значень:

1) 0<=х<=1,570796 (pi/2) (коректне). При великих значеннях х ряд розходиться

2) х - не число (помилкове)

3) х <0 – Порушення специфікації: очікується x>0

4) x>1,57 – Порушення специфікації: очікується x>1,57

Для n – кількості членів ряду.

5) 0<=n<=150 (коректне)

6) n – не число (помилкове)

7) n <0 (помилкове)

8) n>150 (неприпустиме - можливе переповнення)

9) n – не ціле (неприпустиме)

Аналіз тестових ситуацій

1. Вхідні значення: (х = 0, n = 0) (покривають класи 1, 5). Очікуваний результат: sin(x)=0, y = 0

2. Вхідні значення: (х = 1.570796, n = 150). Очікуваний результат:

sin(x)=1, y = 0,999

3) Вхідні значення: (х = 0.5236, n = 150). Очікуваний результат:

sin(x)=0.5, y = 0.478

4) Вхідні значення: (х = aa, n = bb) (покривають класи 2,6)

Очікуваний результат: Помилка. Очікується число

5) Вхідні значення (х <0, n = <0); (x=0,n<0), (x<0,n>1) (покривають класи 3,7)

Очікуваний результат: Помилка. Очікується значення > 0

6) Вхідні значення (x>1,57, n>0) (покривають клас 4).

Очікуваний результат: Попередження. Порушення специфікації.

7) Вхідні значення (x>1,57, n>151) (покривають клас 8). Очікуваний результат: Помилка. Значення x повинне бути <1,57.

ЛЕКЦІЯ № 6
ТЕМА: МЕТОДИ ТЕСТУВАННЯ ГРАФІЧНОГО ІНТЕРФЕЙСУ КОРИСТУВАЧА

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

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

Для тестування динамічних характеристик інтерфейсу краще всього підходить метод тестування переходів між станами.

Припущення про помилки і контрольні списки

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

Інший популярний підхід – контрольні списки. Допомагають впорядкувати процес тестування і не пропустити важливі категорії тестів.

Отже, можливе використання контрольних списків двох типів.

1 Перелік типових помилок, виявлених у ході тестування попередніх проектів, даного проекту чи з інших джерел (такі каталоги доступні в Інтернет). Тестери з досвідом ведуть власні каталоги таких помилок.

2. Перелік вимог, які повинні перевірятися.

Прикладом списків другого типу є тестування узгодженості інтерфейсу користувача між комплексами Автоматизованої системи (АС) та на відповідність стандарту Windows.
Загальні вимоги -

При розробці ПК (виборі кольору ) повинні використовуватися пастельні тони.

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



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

Функціональні можливості, що незастосовні в поточному режимі,

повинні бути неактивні




Головне вікно

Повинно бути присутнім системне меню (Control Box)

Повинний бути присутнім рядок заголовка

Повинна бути присутнім кнопка мінімізації

Повинна бути присутнім кнопка максимізації

Повинна бути присутнім кнопка відновлення розміру

Повинний бути присутнім рядок меню

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

Кнопка системного меню

Повинна бути присутньою команда (Восстановить) Поновити

Повинна бути присутньою команда (Переместить) Перемістити

Повинна бути присутньою команда (Размер) Розмір

Повинна бути присутньою команда (Свернуть) Згорнути

Повинна бути присутньою команда (Развернуть) Розгорнути

Повинна бути присутньою команда (Закрыть) Закрити

При необхідності, повинні бути передбачені для кожної команди системного меню відповідні клавіші-акселератори

Натискання комбінації клавіш Alt+F4 повинне викликати закриття форми.

Блок діалогу

Блок діалогу повинний бути переміщуваний

Блок діалогу повинний мати системне меню (блок керування )

У системному меню повинна бути команда Перемістити

У системному меню повинна бути команда Закрити

Блок діалогу не повинний мати кнопки Згорнути і Розгорнути

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

На екранних формах обробки помилок, повинний виводитися ознака серйозності помилки

Загальні відомості

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

Форма повинна розміщатися по центру екрана

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

Кнопки на екранній формі повинні задовольняти вимогам приведеним у розділі "Командні кнопки на формах"

Інформація в довідниках, виведена користувачеві, повинна задовольняти вимогам приведеним у розділі "Інформація (довідники)"


Обробка помилок

На екранній формі обробки помилок повинна бути присутня кнопка контекстної допомоги

Повинні виводитися рекомендації користувачеві про подальші дії

Повинні виводитися підказки про призначення кнопок на формі

Повинна існувати кнопка "Відмінити" (для форм, що включають багато дій)

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

Ліворуч від повідомлення повинна відображатися піктограма з буквою "І"

Тестування переходів між станами

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

набір тестів повинен охоплювати найбільш ймовірні послідовності дій користувачів;

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

окремі тести слід проектувати також для перевірки неприпустимих переходів між станами (для виявлення можливих небажаних побічних ефектів);

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

При проектуванні тестів добре використовувати таблиці переходів станів або діаграми.

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


ЛЕКЦІЯ № 7
1   2   3   4


База даних захищена авторським правом ©lecture.in.ua 2016
звернутися до адміністрації

    Головна сторінка