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

1.

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

2.

ТЕСТУВАННЯ, ЯК ЕТАП ПРОЦЕСУ РОЗРОБКИ ПЗ
Тестування - дуже важливий і трудомісткий етап процесу
розробки програмного забезпечення, так як правильне тестування
дозволяє виявити переважна більшість помилок, допущених при
складанні програм.
Стандарт ANSI/IEEE Std. 610.12: 1990 визначає термін testing в
самому його широкому сенсі як будь-яка дія з аналізу ПЗ
(включаючи методи як динамічної, так і статичної перевірки).
Г. Майерс визначає цей термін в найвужчому сенсі: «тестування процес виконання програми (або її частини) з метою виявлення
помилок ... Налагодження (debugging) - діагностування точної
природи відомих помилок і їх виправлення».
Слово "testing" може бути переведено не тільки як тестування, а й
як випробування (як це зроблено в стандартах ДСТУ 2844-94,
ДСТУ 2853-94).
Процес розробки програмного забезпечення передбачає три стадії
тестування: автономне, комплексне і системне, кожна з яких
відповідає завершенню відповідної частини системи.
2

3.

"ІСТОРИЧНІ ПЕРІОДИ" ПРОЦЕСУ ТЕСТУВАННЯ
період до 1956 року - орієнтація на налагодження;
період з 1957 по 1978 рр. - орієнтація на
встановлення відповідності ПЗ вихідним вимогам;
період з 1979 по 1982 рр. - орієнтація на
виявлення дефектів, що залишилися після
реалізації;
період з 1983 по 1987 рр. - орієнтація на аналіз,
перевірку та тестування з метою оцінки якості ПЗ на
всіх стадіях розробки;
період з 1988 по 1995 рр. - інтеграція дій з
перевірки та тестування в життєвий цикл ПЗ з
метою запобігання появи дефектів на всіх стадіях
розробки (з охопленням всіх дій по верифікації,
3
валідації та тестування).

4.

У SWEBOK ГАЛУЗЬ ЗНАНЬ «ТЕСТУВАННЯ ПЗ»
4

5.

ТЕРМІНОЛОГІЯ ТЕСТУВАННЯ
Наступні слова є ключовими для тестування:
динамічне: тестування завжди передбачає
виконання програми;
кінцеве: навіть для невеликої програми
теоретично можливо створити таку кількість
тестів, для виконання яких можуть знадобитися
роки;
обраних: з проблемою адекватності тестування
пов'язана проблема вибору обмеженого безлічі
тестів;
очікувана поведінка: потрібно вміти
визначати, чи правильні отримані результати
виконання програми, чи відповідає що
спостерігається виконання очікуванням
5
користувача або специфікаціям.

6.

КЛЮЧОВІ ПИТАННЯ ТЕСТУВАННЯ
До ключових питань тестування в SWEBOK віднесені наступні:
Критерії вибору тестів / Критерії адекватності тестів (або правила припинення
тестування). Ці критерії можуть застосовуватися як для створення набору тестів, так і для
перевірки, наскільки вибрані тести адекватні важливість справ (тестування), а також
допомагають визначити, коли можна або необхідно припинити тестування.
Ефективність тестування / Цілі тестування. Тестування - це спостереження за
поведінкою програми, що виконується з метою тестування із заданими параметрами, за
заданим сценарієм або з іншими заданими початковими умовами або цілями тестування.
Ефективність тесту може бути визначена тільки в контексті заданих умов.
Тестування для виявлення дефектів. У тестуванні для виявлення дефектів
застосовується деструктивний підхід, а успішним вважається тест, який виявляє дефект. Цей
підхід принципово відрізняється від іншого підходу, коли тести запускаються для
демонстрації того, що програма задовольняє пропонованим до неї вимогами і, відповідно, тест
вважається успішним, якщо не знайдено дефектів.
Проблема оракула. «Оракул» в тестуванні - це будь-який агент (людина або програма), що
оцінює поведінку програми і формує висновок про результат тесту (тест пройдено чи ні). Цей
висновок істотно залежить від трактування поняття «відмова» і «дефект» в конкретному
контексті.
Теоретичні та практичні обмеження тестування. Обмеження обумовлені
неможливість вичерпного тестування і його економічну недоцільність для конкретних ПС.
Тестування повинне проводитися з урахуванням ризику відмови ПЗ і грунтуватися на таких
стратегіях тестування, які отримали поширення в сучасних методологіях розробки, як
тестування, засноване на ризику (risk-based testing), і кероване ризиком тестування
(riskdriven testing), які коротко розглянуті в цьому розділі .
Проблема нездійсненних шляхів. Нездійсненні шляхи - це напрями потоку управління
програми, які не можуть бути виконані за жодних вхідних параметрах. Це дуже складна
проблема тестування шляхів і особливо його автоматизації.
Тестопригодність. Цей термін має два різних значення. Перше - це ступінь легкості опису
критеріїв тестового покриття для ПЗ, друге - ймовірність, що виконання програми при
6
тестуванні призведе до її відмови, при наявності дефекту.

7.

ВИДИ КОНТРОЛЮ ЯКОСТІ РОЗРОБЛЮВАНОГО ПЗ
(а)
(б)
Залежність ймовірностей правильного виправлення помилок (а)
та його вартість від етапу розробки (б)
7

8.

ВИДИ КОНТРОЛЮ ЯКОСТІ РОЗРОБЛЮВАНОГО ПЗ
Тестування - це процес виконання програми, метою якого є
виявлення помилок.
Ніяке тестування не може довести відсутність помилок в
програмному забезпеченні. Для такого програмного
забезпечення виконання повного тестування, тобто завдання
всіх можливих комбінацій вихідних даних, стає можливим, а
отже, завжди є ймовірність того, що в програмному
забезпеченні залишилися невиділені помилки. Однак
дотримання основних правил тестування і науково
обґрунтований підбір тестів може зменшити їх кількість.
Процес розробки програмного забезпечення передбачає три
стадії тестування:
• автономне тестування компонентів програмного
забезпечення;
• комплексне тестування програмного забезпечення, що;
• системне або оцінне тестування на відповідність основним
критеріям якості.
8

9.

ВИДИ КОНТРОЛЮ ЯКОСТІ РОЗРОБЛЮВАНОГО ПЗ
Для підвищення якості тестування рекомендується
дотримуватися таких основних принципів.
• передбачувані результати повинні бути
відомі до тестування;
• слід уникати тестування програми автором;
• необхідно досконально вивчати результати
кожного тесту;
• необхідно перевіряти дії програми на
невірних даних;
• необхідно перевіряти програму на
несподівані побічні ефекти на невірних
даних.
9

10.

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

11.

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

12.

ЗВ'ЯЗОК ТЕСТУВАННЯ З ІНШИМИ ВИДАМИ ДІЯЛЬНОСТІ
Тестування має багато спільного з
процесами верифікації та валідації (V & V).
Спільність процесу тестування з процесами V & V
полягає в єдності складу та структури планів,
(IEEE Std.829), а також об'єктів і застосовуваних методів.
Відмінність цих процесів полягає в умовах їх
застосування.
Тестування - основний процес в ЖЦ, що виконується
завжди, для всіх об'єктів ПЗ системи незалежно від її
критичності.
Процеси V & V, в сучасному трактуванні стандартів IEEE
Std.1012 і ISO/IEC12207 - підтримують процеси, які
можуть застосовуватися до вибраних об'єктів тестування
для перевірки планів їх тестування і підтвердження того,
що виконане тестування адекватно рівню критичності
ПС. По відношенню до процесу тестування V & V виконує
контрольну функцію і підтверджує відповідність об'єктів
встановленим вимогам.
12

13.

ВИДИ І РІВНІ ТЕСТУВАННЯ
Структурування процесу тестування ПЗ за
рівнями зазвичай зв'язується або
з видами об'єктів, що тестуються, (модуль,
система або її частини),
з цілями якості ПЗ,
що перевіряються (функціональність, безпека,
надійність і ін.).
13

14.

РІВНІ ТЕСТУВАННЯ ЗА ВИДАМИ ОБ'ЄКТІВ
Традиційно виділяється три рівні тестування ПЗ:
автономне або модульне (unit testing; «блокове
тестування»),
інтеграційне (integrating testing; «комплексні
випробування»)
системне (system testing).
14

15.

РІВНІ ТЕСТУВАННЯ ЗА ВИДАМИ ОБ'ЄКТІВ
15

16.

V-ПОДІБНА МОДЕЛЬ ТЕСТУВАННЯ
16

17.

ВИДИ ВИПРОБУВАНЬ ПРОГРАМНОЇ СИСТЕМИ
17

18.

ВИДИ ТЕСТУВАННЯ ХАРАКТЕРИСТИК ПС
18

19.

РУЧНИЙ КОНТРОЛЬ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Ручний контроль, як зазначено вище, зазвичай
використовують на ранніх етапах розробки.
При статичному підході аналізують
структуру, керуючі та інформаційні зв'язки
програми, її вхідні і вихідні дані.
При динамічному - виконують ручне
тестування, тобто вручну моделюють процес
виконання програми на заданих вихідних даних.
19

20.

РУЧНИЙ КОНТРОЛЬ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Вихідними даними для таких перевірок є:
технічне завдання,
специфікації,
структурна і функціональна схеми програмного
продукту,
схеми окремих компонентів і т. д.,
для більш пізніх етапів - алгоритми і тексти
програм, а також тестові набори.
20

21.

РУЧНИЙ КОНТРОЛЬ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Основними методами ручного контролю є:
• інспекції вихідного тексту,
• наскрізні перегляди,
• перевірка за столом,
• оцінки програм.
21

22.

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

23.

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

24.

ПЕРЕВІРКА ЗА СТОЛОМ
Історично цей метод ручного тестування з'явився першим, так як він
не вимагає наявності групи фахівців.
Це - перевірка вихідного тексту або наскрізні перегляди, що
виконуються однією людиною, який читає текст програми, перевіряє
його на наявність можливих помилок за спеціальним списком
розповсюджених помилок і «пропускає» через програму тестові дані.
Виходячи з принципів тестування, перевірку за столом повинен
проводити людина, нt є автором програми.
Метод найменш результативним, так як перевірка являє собою
повністю невпорядкований процес, при ній відсутній обмін думками і
здорова конкуренція.
24

25.

ОЦІНКА ПРОГРАМ
Метод безпосередньо не
пов'язаний з тестуванням, але
його використання також
покращує якість
програмування.
Його використовують для
анонімної оцінки програми в
термінах се загальної якості,
простоти експлуатації і
ясності.
Мета методу - забезпечити
порівняно об'єктивну оцінку і
самооцінку програмістів.
25

26.

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