Тестування комплексів програм. Лекція 7

1.

ЛЕКЦІЯ 7
Тестування комплексів програм

2.

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

3.

ДОСЛІДНИЦЬКЕ ТЕСТУВАННЯ
Завдання кроку:
Формування списку функцій (ієрархії функцій).
Розбиття функцій на основні та другорядні.
Виявлення областей можливої нестійкості
продукту (схильних до відмов функцій і даних).
3

4.

ПРИКЛАД РОЗБИТТЯ ФУНКЦІЙ НА ОСНОВНІ ТА
ДРУГОРЯДНІ
Визначення
Критерії віднесення
Функції, які є визначальними для
використання продукту за призначенням.
Основна функція - будь-яка зовнішня
Функції, часто використовувані
функція (видима користувачу), відмови в
звичайними користувачами в сеансі
якій означають невідповідність продукту
роботи.
своїм призначенням.
Функції, які можуть використовуватися
рідко, але їх відмови призводять до
значних негативних наслідків.
Другорядна функція - функція, без якої
продукт може використовуватися.
Рідко використовувані функції, відмови
при виконанні яких не можуть мати
істотних наслідків.
4

5.

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

6.

ДОСЛІДНИЦЬКЕ ТЕСТУВАННЯ
Приклади областей можливої нестійкості при обробці
даних:
документи: довгі, багато одночасно відкритих;
записи: довгі, багато записів, порожні, складні;
списки: довгі, порожні або багатоколонкові;
поля: введення великої кількості символів; дуже великі значення
числових полів;
об'єкти: багато, великі, складні і ін.
6

7.

ДОСЛІДНИЦЬКЕ ТЕСТУВАННЯ
Крок 2. Проектування тестів. Визначення стратегій виконання
тестів і критеріїв оцінювання результатів.
Приклад критеріїв проходження тестів
начення цілі
Функціональність здатність продукту
виконувати
необхідні функції.
Критерій пріходу
Критерій відмови
Функція виконується відповідно до її
призначення.
Хоча б одна функція не
виконується відповідно до її
призначення.
Неправильне виконання
Будь-яке неправильне виконання функції не
призводить до серйозних
призводить до серйозних наслідків при
наслідків навіть при коректному
коректному використанні.
використанні.
Стійкість Робота продукту при підвищених
Робота продукту руйнує
здатність продукту навантаженнях не приводить до руйнування
Windows. Робота продукту може
функціонувати без Windows. Робота продукту не приводить до
призвести до втрати даних,
відмов при
втрати даних, зависання, відмови. При
зависання, відмови. При 7
підвищених
тестуванні не було виявлено відмов або
тестуванні хоч однієї з основних
навантаженнь (за будь-яких дефектів при виконанні основних
функцій спостерігалися відмови.
часом, пам'яті).
функцій.

8.

ДОСЛІДНИЦЬКЕ ТЕСТУВАННЯ
Крок 3. Виконання тестів. Виконання тестів, спостереження і
фіксація результатів і використання цієї інформації для
формування думки про роботу продукту.
Завдання кроку:
тестування всіх основних функцій;
тестування ідентифікованих областей потенційної нестійкості;
вибіркове тестування другорядних функцій;
реєстрація відмов;
фіксація будь-яких виявлених проблем (для подальшого вивчення).
8

9.

ДОСЛІДНИЦЬКЕ ТЕСТУВАННЯ
Крок 4. Побудова евристик. Евристики представляють
неформальні правила (засновані на досвіді тестувальника і
здоровому глузді) прийняття рішення про те, чи вважати роботу
продукту прийнятною чи ні, і як далі продовжувати тестування.
Крок 5. Визначення критерію покриття. У цій процедурі
використовується наступний критерій покриття:
протестовані всі основні функцій;
протестовані вибрані другорядні функції;
протестовані вибрані області можливої нестійкості (слід вибрати від
п'яти до десяти функцій і протестувати їх на тестових даних, які
можуть привести до нестійкої роботи продукту).
Рекомендоване розподіл часу тестування: 80% часу - на основні
функції, 10% - на другорядні і 10% - на області потенційної
нестійкості. Процедура тестування з даного методу виконується
циклічно.
9

10.

ЕКВІВАЛЕНТНЕ РОЗБИТТЯ
Суть методу еквівалентного розбиття полягає в тому, що вся
множина тестів, які теоретично можна побудувати для тестування
програми, що реалізує функцію, розбивається на підмножини
тестів, що утворюють «класи еквівалентності», з яких для
виконання вибираються тільки найбільш представницькі (з
найбільшою ймовірністю виявлення помилки).
Віднесення групи тестів до одного класу еквівалентності може
ґрунтуватися на наступних практичних умовах:
тести містять значення одних і тих же вхідних даних;
при запуску тестів виконуються одні й ті ж операції;
від виконання тестів очікуються однакові результати;
або жоден з тестів не викликає виконання блоку обробки помилок,
або всі тести викликають виконання цього блоку (в припущенні, що
програма взагалі містить блоки обробки помилок).
10

11.

ЕКВІВАЛЕНТНЕ РОЗБИТТЯ
Класи еквівалентності поділяються на допустимі класи
еквівалентності, що представляють правильні вхідні дані і
вхідні події (події-входи), і неприпустимі класи
еквівалентності, які відображають всі інші дані або події.,
Приклад опису класів еквівалентності
Вхідні події
Введення числа
Введення першої
літери прізвища
Допустимі класи
еквівалентності
Числа від 0 до 9000
Перший символ
повинен бути великою
літерою
Неприпустимі класи
еквівалентності
•Числа менше 0 і числа більше 9000
•Пропуск
•Нечислові символи
•Обчислюється вираз, результат
обчислення якого знаходиться поза
допустимого інтервалу
•Перший символ мала літера
•Перший символ - не буква
11

12.

ЕКВІВАЛЕНТНЕ РОЗБИТТЯ
При виділенні класів еквівалентності можна керуватися
поруч загальних правил:
якщо подія-вхід асоціюється з областю значень, то визначається
один допустимий клас еквівалентності і ряд неприпустимих (в
таблиці їх п'ять);
якщо подія-вхід асоціюється зі значенням, що представляє кількість
яких-небудь (наприклад, від 1 до 20), то визначається один
допустимий клас еквівалентності (1<= X<= 20) і ряд неприпустимих
(X<1 і X>20);
якщо для параметра програми допускається тільки певний перелік
значень (наприклад, перелік конкретних найменувань чого-небудь,
що зберігаються в базі даних), то визначається один допустимий
клас еквівалентності для значень з цього переліку і один
неприпустимий (наприклад, для значень, відсутніх в переліку). В
цьому випадку граничні значення не визначаються;
будь-який елемент списку параметрів програми або об'єктів
(списки, меню, кнопки панелі інструментів) представляє окремий
клас еквівалентності.
12

13.

ЕКВІВАЛЕНТНЕ РОЗБИТТЯ
Тести розробляються спочатку для допустимих класів
еквівалентності, а потім - для неприпустимих:
для допустимих: по одному тесту всередині класу і по одному на
межах класу (наприклад, якщо параметр програми містить список,
потрібно зі списку вибрати перший, останній і будь-який
проміжний елемент, а для числових значень в діапазоні від 1 до
100, вибрати 1, 100 і будь-яке число в межах діапазону);
для неприпустимих: по одному тесту для кожного класу
(наприклад, для числових значень в наведеному вище прикладі вибрати 0 і 101, пробіл і нечислової символ).
13

14.

АНАЛІЗ ГРАНИЧНИХ ЗНАЧЕНЬ
За цим методом тести розробляються для
направленого тестування меж класів еквівалентності.
При цьому аналізуються також всі вихідні класи
еквівалентності - очікувані результати тестів. Якщо очікувані
результати представляють значення з безперервного діапазону
значень, то вхідні дані для їх отримання вибираються так, щоб
отримати значення, що знаходяться на верхній і нижній межах
допустимого діапазону.
Відмінність даного методу від методу еквівалентного розбиття полягає
в наступному:
при аналізі граничних значень вибираються тільки такі елементи в
класі еквівалентності, які дозволяють перевірити тестом кожну
кордон цього класу;
при розробці тестів розглядаються не тільки вхідні значення, а й
очікувані результати.
14

15.

РОЗБИТТЯ ВХІДНОГО ПРОСТОРУ НА КАТЕГОРІЇ
15

16.

РОЗБИТТЯ ВХІДНОГО ПРОСТОРУ НА КАТЕГОРІЇ
Цей метод має переваги:
дозволяє охопити відразу обидва основні аспекти
тестування - перевірку повноти реалізації функцій і
виявлення різних класів дефектів в найбільш
уразливих частинах програми;
функціональний аналіз є невід'ємною частиною методу
і виконується паралельно зі специфікацією
функціональних вимог (або відразу після),
забезпечуючи своєчасне усунення дефектів
специфікацій;
хоча специфікація тесту повинна охоплювати всі
можливі категорії інформації та варіанти поєднання
альтернатив, - застосовуючи механізм обмежень і
керуючись практичними міркуваннями, можна
управляти об'ємом тестування;
процес перебору альтернатив і «відсіювання»
неможливих або небажаних їх поєднань може бути
16
автоматизований, що позбавить тестувальника від
рутинної роботи.

17.

ТЕСТУВАННЯ ПЕРЕХОДІВ МІЖ СТАНАМИ
За цим методом тести проектуються для перевірки переходів
між станами програми (наприклад, зміни зображення на
екрані, зміни складу і активності елементів меню та ін.).
При проектуванні тестів слід керуватися практичними
міркуваннями:
набір тестів повинен охоплювати найбільш ймовірні
послідовності дій користувачів;
якщо є залежні стану і синхронізуються події, для кожного з
них повинні розроблятися окремі тести;
окремі тести слід проектувати також для перевірки
неприпустимих переходів між станами (для виявлення
можливих небажаних побічних ефектів);
після виконання мінімального набору тестів слід провести
набір випадкових тестів (вибираючи довільні режими і сценарії
виконання).
Як інструменти при проектуванні тестів використовують:
діаграми переходів в стан (State-transition diagram);
таблиці переходів в стан (State-transition tables).
17

18.

ТЕСТУВАННЯ ПЕРЕХОДІВ МІЖ СТАНАМИ
Діаграма переходу в стан відображає безліч
станів в даному контексті, події, які викликають
переходи між станами, і можливі дії.
18

19.

ТЕСТУВАННЯ ПЕРЕХОДІВ МІЖ СТАНАМИ
Структура таблиці переходів станів
Стан
Подія
Дія
Наступний стан
Цей метод спочатку призначався для тестування
програм реального часу, але згодом почали
застосовувати при проектуванні тестів для
інтерактивних програм: тестування станів меню
(активно, неактивно, вибрано), навігації між
вікнами, синхронізації елементів інтерфейсу в
діалогових вікнах.
19

20.

ТЕСТУВАННЯ, ЗАСНОВАНЕ НА МОДЕЛЯХ ПРОГРАМНОЇ СИСТЕМИ
Як самостійний напрям тестування на базі
моделей (model-based testing (MBT)) оформилося до
середини 90-х років минулого століття в зв'язку з
автоматизацією розробки тестів. Хоча, по суті, всі
методи тестування застосовують моделі, для даного
напрямку характерно наступне:
модель представлена в формальному вигляді;
модель застосовується для генерації тестів або еталона.
Тести в цілому утворюють набір,
іменований абстрактним набором
тестів (abstract test suite), який безпосередньо не
може застосовуватися для тестування, а служить
основою для створення набору тестів, що виконуються,
та генерується (виведеного) за моделлю. Розробка ж
самої моделі робиться паралельно з розробкою ПС або
безпосередньо для існуючої ПС.
20

21.

ТЕСТУВАННЯ WEB-ДОДАТКІВ
Web-додатки можна розглядати як клієнт/серверні
додатки, в яких функціональність реалізується як на
серверної, так і на стороні клієнта, а призначений для
користувача інтерфейс має стандартизовану архітектуру, в
якій:
для взаємодії з користувачем використовується Web-браузер;
взаємодія з користувачем чітко розділяється на етапи,
протягом яких браузер працює з одним описом інтерфейсу, а
ці етапи, в свою чергу, поділяються однозначно
локалізуються зверненнями від браузера до додатка;
для опису інтерфейсу застосовується стандартне уявлення;
взаємодія між браузером і додатком здійснюється по
стандартному протоколу (HTTP) і чітко формалізована;
функціональність Web-додатки розподілена між віддаленим
сервером і клієнтськими комп'ютерами користувачів.
21

22.

ТЕСТУВАННЯ WEB-ДОДАТКІВ
1. Ідентифікація оточення Web-додатки. Включає
аналіз інформації про мови скриптів, що використовуються,
Web-сервері, операційній системі.
2. Тестування прихованих елементів форм і
розкриття вихідних текстів. Включає перевірку всіх
вихідних текстів сторінок на наявність будь-якої корисної
інформації, ненавмисно залишеної розробником - це можуть
бути фрагменти скриптів, розташованих усередині HTMLкоду, посилання на які підключаються або пов'язані
скрипти, неправильно роздані права доступу до критичних
файлів з вихідним текстом. Повинна бути перевірена
наявність кожної програми і скрипта, посилання на які були
знайдені.
3. Визначення механізмів аутентифікації. Необхідно
перевірити, як обраний механізм застосовується до кожного
ресурсу, що використовується Web-додатком. Для цього слід
спробувати отримати доступ до всіх ресурсів через кожну
точку входу.
22

23.

ТЕСТУВАННЯ WEB-ДОДАТКІВ
Деякі особливості тестування Web-додатків
пов'язані з процесом розробки. Як правило, для
створення Web-додатків використовуються
методи «прискореної» розробки, в яких:
тестування вбудовано в ЖЦ і виконується паралельно
з розробкою;
невеликі проектні групи (або один Web-дизайнер);
активну участь замовника (не завжди можливо);
дуже стислі терміни розробки версій обмежують час на
ретельне планування і виконання тестування;
фаза інтеграції Web-додатків зазвичай відсутня (немає
інтеграційного тестування), тому основна увага
приділяється функціональному тестуванню додатків в
середовищі, що моделюється, і системному - в
реальному середовищі;
стадія супроводу і розвитку - невід'ємна частина ЖЦ,
23
отже, потрібне постійне регресійне тестування.

24.

ОСОБЛИВОСТІ ВИКОНАННЯ ТЕСТУВАННЯ В МОДЕЛЯХ ЖЦ
Каскадна модель
Підходи, що застосовувані до тестування
Ключова особливість моделі: Каскадна модель з
циклами зворотнього зв'язку, моделюванням або
прототіпірованії. Тестування починається після
завершення кодування.
Основні методи/підходи:
1.
Передача коду групі тестування після його
готовності.
2.
Користувачі залучаються до тестування на етапі
приймальних випробувань.
3.
Після випуску продукту проводиться додаткове
тестування (дослідна експлуатація).
Примітка: Поліпшення тестування можливо в кінці
проекту, що збільшує час для можливості поліпшення
процесу і тільки в наступних проектах.
24

25.

ОСОБЛИВОСТІ ВИКОНАННЯ ТЕСТУВАННЯ В МОДЕЛЯХ ЖЦ
Спіральна модель
Підходи, що застосовувані до тестування
Ключова особливість моделі: використовує прототипування та
перепланування з постійним оцінюванням ризиків і обмежень в
рамках кожного прототипу.
Основні методи/підходи:
1.
Тестування, засноване на оцінці ризику (risk-driven testing).
Тестування застосовується для ідентифікації ризиків. Аналіз
дефектів служить ключем для ідентифікації «вузьких» місць в ПЗ.
2.
Тестування починається на ранніх стадіях ЖЦ.
3.
Критерій завершення тестування, ґрунтується на оцінці ризиків.
Тестове покриття - не основна мета. Стратегія тестування
формується з урахуванням ризиків потенційно залишилися
дефектів і допомагає прийняти рішення про перехід до наступного
витка спіралі.
Примітки: 1. В рамках стадії ЖЦ в одному витку спіралі тестування
виконується так само, як і в каскадної моделі, але на меншому обсязі ПС і
менш тривало.
Загальний час тестування в рамках ЖЦ більше, оскільки більший
проміжок часу між його початком і випуском ПС
25

26.

ОСОБЛИВОСТІ ВИКОНАННЯ ТЕСТУВАННЯ В МОДЕЛЯХ ЖЦ
Personal Software Process (PSP)
Підходи, що застосовувані до тестування
Ключова особливість моделі: Навчання розробників методам
ідентифікації, аналізу та поліпшення власних процесів. Мета дати можливість кожному поліпшити власну продуктивність і
досягти встановлених цілей якості.
Основні методи/підходи:
1.
Методи верифікації (інспекції, персональні перегляди, колективні
перевірки).
2.
Раннє усунення дефектів. Розробники заохочуються за раннє
усунення дефектів; фіксацію і управління дефектами, регулярний
аналіз дефектів.
3.
Прагнення до постійного поліпшення процесу.
Примітка:
Персональне управління дефектами (фіксація своїх дефектів
відразу після їх внесення, персональні перевірки проекту та коду
за встановленими посібникам і контрольним вопросникам).
26

27.

ОСОБЛИВОСТІ ВИКОНАННЯ ТЕСТУВАННЯ В МОДЕЛЯХ ЖЦ
Моделі прискореної розробки
Підходи, що застосовувані до тестування
Ключова особливість моделі: Ітеративний підхід, постійне
автоматизоване тестування розробниками, тісний контакт, мінімум
документації (в тому числі з тестування).
Основні методи/підходи:
1.
Керована тестами розробка (test-driven development). Розробники
пишуть тести до кодування і (при необхідності) оновлюють їх для
підвищення корисності
2.
Автоматизація. Коли тести «стабільні», вони автоматизуються,
переважно групами так, щоб їх можна було асоціювати з модулем
або проектом системи.
3.
Принцип «мати добру якість». Достатність зв'язується зі
складністю ПС, критичністю її функцій, терпимості замовника до
помилок і ін.
4.
Тестування розглядається як стратегія зниження ризику відмови.
5.
Приймальні тести зазвичай розробляються замовником і повинні
бути готові до початку проектування і кодування.
27

28.

ДЯКУЮ ЗА УВАГУ!
28