Тестування програмного забезпечення

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

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

Зазвичай, поняття якості обмежується такими поняттями як коректність, надійність, практичність, безпечність, але може містити більше технічних вимог, котрі описані у стандарті ISO 9126. Склад та зміст супутньої документації процесу тестування визначається стандартом IEEE 829—1998 Standard for Software Test Documentation. Існує багато підходів до тестування програмного забезпечення, але ефективне тестування складних продуктів — це по суті дослідницький та творчий процес, а не тільки створення та виконання рутинної процедури.

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

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

На початку 1970-х тестування ПЗ розглядалося як «процес, спрямований на демонстрацію коректності продукту» або як «діяльність із підтвердження правильності роботи ПЗ». У програмній інженерії, яка в той час зароджувалася, верифікація ПЗ визначалася як «доказ правильності». Хоча концепція була теоретично перспективною, на практиці вона вимагала багато часу й не охоплювала всі аспекти тестування. Було вирішено, що доказ правильності — неефективний метод тестування ПЗ. Однак, у деяких випадках демонстрація правильної роботи використовується і в наші дні, наприклад, приймально-здавальні випробування. У другій половині 1970-х тестування представлялося як виконання програми з наміром знайти помилки, а не довести, що вона працює. Успішний тест — це тест, який виявляє раніше невідомі проблеми. Цей підхід цілком протилежний попередньому. Зазначені два визначення являють собою «парадокс тестування», в основі якого лежать два протилежних твердження: з одного боку, тестування дозволяє переконатися, що продукт працює добре, а з іншого — виявляє помилки у ПЗ, показуючи, що продукт не працює. Друга мета тестування є продуктивнішою з точки зору поліпшення якості, оскільки не дозволяє ігнорувати недоліки ПЗ.

У 1980-х тестування розширилося таким поняттям як запобіганням дефектам. Проєктування тестів — найефективніший із відомих методів запобігання помилок. В цей же час почали висловлюватися думки, що необхідна методологія тестування, зокрема, що тестування повинно включати перевірки впродовж усього циклу розроблення, при цьому це має бути керований процес. В ході тестування треба перевірити не тільки зібрану програму, але й вимоги, код, архітектуру, самі тести. «Традиційне» тестування, яке існувало до початку 1980-х, відносилося тільки до скомпільованої, готової системи (зараз це зазвичай називається системне тестування), але надалі тестувальники стали залучатися в усі аспекти життєвого циклу розроблення. Це дозволяло раніше знаходити проблеми у вимогах та архітектурі й тим самим скорочувати терміни та бюджет розроблення. У середині 1980-х з'явилися перші інструменти для автоматизованого тестування. Передбачалося, що комп'ютер зможе виконати більше тестів, ніж людина, причому зробить це більш надійно. Спочатку ці інструменти були вкрай простими й не мали можливості написання сценаріїв на скриптових мовах.

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

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

Тестування — це одна з технік контролю якості, що охоплює

• Планування робіт (Test Management)
• Проєктування тестів (Test Design)
• Виконання тестування (Test Execution)
• Аналіз отриманих результатів (Test Analysis).

Верифікація (Verification) — це процес оцінки системи або її компонентів із метою визначити чи задовольняють результати поточного етапу розробки умовам, сформованим на початку цього етапу. Тобто чи виконуються цілі, те��міни, завдання з розробки проєкту, визначені на початку поточної фази. Валідація (Validation) — це визначення відповідності розроблюваного програмного забезпечення очікуванням і потребам користувача, вимогам до системи.

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

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

Тестовий випадок (Тест кейс/Test Case) — це документ, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації тестованої функції або її частини.

Баг/Дефект Репорт (Bug Report) — це документ, що описує ситуацію або послідовність дій (Steps), що призвела до некоректної роботи об'єкта тестування (Misbehavior), із зазначенням причин та очікуваного результату (Expected Result).

Тестове Покриття (Test Coverage) — це одна з метрик оцінки якості тестування, що представляє із себе щільність покриття тестами вимог або коду, що виконується.

Деталізація Тест Кейсів (Test Case Specification) — це рівень деталізації опису тестових кроків і необхідного результату, при якому забезпечується розумне співвідношення часу проходження до тестового покриття.

Час Проходження Тест Кейса (Test Case Pass Time) — це час від початку проходження кроків тест кейса до отримання результату тесту.

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

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

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

Відома: внутрішня структура програми.
Досліджуються: внутрішні елементи програми і зв'язки між ними.

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

Особливості тестування «білої скриньки»

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

У цьому випадку формуються тестові варіанти, в яких:

• Гарантується перевірка всіх незалежних маршрутів програми.
• Знаходяться гілки True, False для всіх логічних рішень.
• Виконуються всі цикли (у межах їхніх кордонів та діапазонів).
• Аналізується правильність внутрішніх структур даних.

Недоліки тестування «білої скриньки»:

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

Переваги тестування «білої скриньки» пов'язані з тим, що принцип «білої скриньки» дозволяє врахувати особливості програмних помилок:

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

Кожна з цих причин є аргументом для проведення тестування за принципом «білої скриньки». Тести «чорної скриньки» не зможуть реагувати на помилки таких типів.

Відомі: функції програми.

Досліджується: робота кожної функції на всій області визначення.

Основне місце програми тестів «чорної скриньки» — інтерфейс ПЗ.

Ці тести демонструють:

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

При тестуванні «чорної скриньки» розглядаються системні характеристики програм, ігнорується їхня внутрішня логічна структура. Вичерпне тестування, як правило, неможливе. Наприклад, якщо в програмі 10 вхідних величин і кожна приймає по 10 значень, то кількість тестових варіантів становитиме 10¹⁰. Тестування «чорної скриньки» не реагує на багато особливостей програмних помилок.

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

• Набір, утворений такими вхідними даними, які призводять до аномалій у поведінці програми (назвемо його IT);
• Набір, утворений такими вхідними даними, які демонструють дефекти програми (назвемо його OT).

Будь-який спосіб тестування «чорної скриньки» повинен:

• Виявити такі вхідні дані, які з високою ймовірністю належать набору IT;
• Сформулювати такі очікувані результати, які з високою імовірністю є елементами набору OT.

Принцип «чорної скриньки» не альтернативний принципу «білої скриньки». Скоріше це доповнює підхід, який виявляє інший клас помилок.

Тестування «чорної скриньки» забезпечує пошук наступних категорій помилок:

• Некоректних чи відсутніх функцій;
• Помилок інтерфейсу;
• Помилок у зовнішніх структурах даних або в доступі до зовнішньої бази даних;
• Помилок характеристик (необхідна ємність пам'яті і т. д.);
• Помилок ініціалізації та завершення.

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

За ступенем автоматизації:

• Ручне тестування (manual testing)
• Автоматизоване тестування (automated testing)
• Напівавтоматизоване тестування (semiautomated testing)

За ступенем підготовленості до тестування:

• Тестування по документації (formal testing)
• Тестування ad hoc або інтуїтивне тестування (ad hoc testing) — тестування без тест плану та документації, що базується на методиці передбачення помилки на власному досвіді тестувальника.

За знанням системи:

• Тестування чорної скриньки (black box)
• Тестування білої скриньки (white box)
• Тестування сірої скриньки (grey box)

За ступенем ізольованості компонентів:

• Компонентне (модульне) тестування (component/unit testing)
• Інтеграційне тестування (integration testing)
• Системне тестування (system/end-to-end testing)

За часом проведення тестування:

• Альфа-тестування (alpha testing)
  • Тестування при прийманні або Димове тестування (smoke testing)
  • Тестування нової функціональності (new feature testing)
  • Регресивне тестування (regression testing)
  • Тестування при здачі (acceptance testing)
• Бета-тестування (beta testing)

За об'єктом тестування:

• Функціональне тестування (functional testing)
• Тестування продуктивності (performance testing)
  • Навантажувальне тестування (load testing)
  • Стрес-тестування (stress testing)
  • Тестування стабільності (stability/endurance/soak testing)
• Тестування зручності використання або Юзабіліті-тестування (usability testing)
• Тестування інтерфейсу користувача (UI testing)
• Тестування безпеки (security testing)
• Тестування локалізації (localization testing)
• Тестування сумісності (compatibility testing)

За ознакою позитивності сценаріїв:

• Позитивне тестування (positive testing)
• Негативне тестування (negative testing)

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

Основною метою якого є перевірка коректної роботи продукту в певному середовищі. Середовище може включати в себе наступні елементи:

• Апаратна платформа
• Мережеві пристрої
• Периферія (принтери, CD/DVD-приводи, вебкамери та ін.);
• Операційна система (Unix, Windows, MacOS, …)
• Бази даних (Oracle, MS SQL, MySQL, …)
• Системне програмне забезпечення (вебсервер, фаєрвол, антивірус, …)
• Браузери (Internet Explorer, Firefox, Opera, Chrome, Safari)

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

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

Регресивне тестування (за деякими джерелами) включає:

• new bug-fix — перевірка виправлення знайдених дефектів;
• old bug-fix — перевірка, що виявлені раніше й виправлені дефекти не відтворюються в системі знову;
• side-effect — перевірка того, що не порушилася працездатність працюючої раніше функціональності, якщо її код міг бути зачеплений під час виправлення деяких дефектів в іншій функціональності.

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

Функціональні вимоги включають у себе:

• Функціональна придатність
• Точність
• Можливість до взаємодії
• Відповідність стандартам та правилам
• Захищеність

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

• Всі види тестування продуктивності:
  • навантажувальне тестування
  • стресове тестування
  • тестування стабільності та надійності
  • об'ємне тестування
• Інсталяційне тестування
• Тестування зручності користування
• Тестування на «відмову» та відновлення
• Конфігураційне тестування

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

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

В тестуванні швидкодії виділяють такі напрямки:

• навантажувальне
• стрес
• тестування стабільності
• конфігураційне

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

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

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

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

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

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

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

Рівні інтеграційного тестування:

• компонентний інтеграційний рівень (Component Integration testing). Перевіряється взаємодія між компонентами системи після проведення компонентного тестування;

• системний інтеграційний рівень (System Integration Testing). Перевіряється взаємодія між різними системами після проведення системного тестування.

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

• знизу вгору (Bottom Up Integration). Усі низькорівневі модулі, процедури або функції збираються воєдино і потім тестуються. Після чого збирається наступний рівень модулів для проведення інтеграційного тестування. Цей підхід вважається корисним, якщо всі або практично всі модулі розроблюваного рівня готові. Також цей підхід допомагає визначити за результатами тестування рівень готовності додатків;
• зверху вниз (Top Down Integration). У першу чергу тестуються компоненти верхнього рівня ієрархії об'єктів із використанням заглушок замість компонентів нижчого рівня;
• великий вибух («Big Bang» Integration). Усі або практично усі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини й потім проводиться інтеграційне тестування. Такий підхід дуже хороший для збереження часу. Проте, якщо тест кейси та їхні результати записані неправильно, то сам процес інтеграції дуже ускладниться, що стане перепоною для команди тестування при досягненні основної мети інтеграційного тестування.

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

• Альфа-тестування — імітація реальної роботи з системою штатними розробниками або реальна робота з системою потенційними користувачами/замовником. Найчастіше альфа-тестування проводиться на ранній стадії розробки продукту, але у деяких випадках може застосовуватися для закінченого продукту як внутрішнього приймального тестування. Іноді альфа-тестування виконується під відлагоджувачем або з використанням середовища, яке допомагає швидко виявляти знайдені помилки. Виявлені помилки можуть бути передані тестувальникам для додаткового дослідження у середовищі, подібному тому, в якому буде використовуватися програма.
• Бета-тестування — у деяких випадках виконується поширення версії з обмеженнями (за функціональністю або часом роботи) для певної групи осіб, з тим щоб переконатися, що продукт містить достатньо мало помилок. Іноді бета-тестування виконується для того, щоб отримати зворотний зв'язок про продукт від його майбутніх користувачів.

Часто для вільного/відкритого ПЗ стадія альфа-тестування характеризує функціональне наповнення коду, а бета-тестування — стадію виправлення помилок. При цьому, як правило, на кожному етапі розробки проміжні результати роботи доступні кінцевим користувачам.

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

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

Як правило, інструменти та бібліотеки, які використовуються для отримання покриття коду, вимагають значних витрат продуктивності та/або пам'яті, неприпустимих при нормальному функціонуванні ПЗ. Тому вони можуть використовуватися тільки в лабораторних умовах.

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

Приймальне тестування виконується на основі набору типових тестових випадків та сценаріїв, розроблених на основі вимог до цього додатку. Рішення про проведення приймального тестування приймається тоді, коли: продукт досяг необхідного рівня якості; замовник ознайомлений із Планом приймальних Робіт (Product Acceptance Plan) або іншим документом, де описаний набір дій, пов'язаних із проведенням приймального тестування, дата проведення, відповідальні тощо.

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

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

Життєвий цикл програмного забезпечення (SDLC — Software Development Life Cycle) — період часу, який починається з моменту прийняття рішення про необхідність створення програмного продукту і закінчується в момент його повного вилучення з експлуатації. Цей цикл — процес побудови і розвитку програмного забезпечення.

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

Ця фаза розрахована для підготовки набору вимог. Потім йде етап узгодження вимог. Як результат ми маємо отримати узгоджений документ з вимогами.

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

Охоплює програмування і отримання кінцевого продукту (бібліотеки, білди, документація).

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

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

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

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

Процес тестування об'єднує різні способи тестування в сплановану послідовність кроків, які приводять до успішної побудови програмної системи (ПС) [3] [13] [64] [69]. Методика тестування ПС може бути представлена у вигляді спіралі, що розгортається

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

Охарактеризуємо кожен крок процесу тестування.

1.Тестування елементів. Мета — індивідуальна перевірка кожного модуля. Використовуються способи тестування «білого ящика».

2.Тестування інтеграції. Мета — тестування збірки модулів в програмну систему. Здебільшого застосовують способи тестування «чорного ящика».

3.Тестування правильності. Мета — перевірити реалізацію в програмній системі всіх функціональних і поведінкових вимог, а також вимоги ефективності. Використовуються суто способи тестування «чорного ящика».

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

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

На практиці зазвичай застосовують статистичний критерій: «Можна з 95%-ю впевненістю сказати, що проведено достатнє тестування, якщо імовірність безвідмовної роботи ПП протягом 1000 годин складає щонайменше 0,995».

Науковий підхід при відповіді на це питання полягає в застосуванні математичної моделі відмов. Наприклад, для логарифмічної моделі Пуассона формула розрахунку поточної інтенсивності відмов має вигляд:

де λ (t) — поточна інтенсивність програмних відмов (кількість відмов в одиницю часу);

λ0 — початкова інтенсивність відмов (на початку тестування); р — експоненціальне зменшення

інтенсивності відмов за рахунок помилок, що виявляються і усуваються; t — тривалість тестування. За допомогою рівняння можна передбачити зниження помилок в ході тестування, а також

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

• Якість програмного забезпечення
• Технологія розробки програмного забезпечення
• Зворотне семантичне трасування
• JUnit
• Багтрекер
• Альфа-тестування
• Забезпечення якості
• Headless браузер
• Псевдолокалізація

• Лайза Криспин, Джанет Грегори. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. — М. : «Вильямс», 2010. — 464 с. — (Addison-Wesley Signature Series) — 1000 прим. — ISBN 978-5-8459-1625-9.
• Канер Кем, Фолк Джек, Нгуен Енг Кек. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. — Киев : ДиаСофт, 2001. — 544 с. — ISBN 9667393879.
• Калбертсон Роберт, Браун Крис, Кобб Гэри. Быстрое тестирование. — М. : «Вильямс», 2002. — 374 с. — ISBN 5-8459-0336-X.
• Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. — М. : БИНОМ, 2008. — 368 с. — ISBN 978-5-94774-825-3.
• Савин Роман. Тестирование DOT COM или Пособие по жестокому обращению с багами в интернет-стартапах — М.: Дело, 2007. — 312 c. — ISBN 978-5-7749-0460-0.
• The Test Management Guide — A to Z and FAQ Knowledgebase (англ.)Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. — СПб. : Питер, 2004. — 320 с. — ISBN 5-94723-698-2.

• IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004 (англ.)
• Текст лекцій до курсу «Технології розробки і тестування програм» Дідковська М. В.
• Quality Assurance Group — Навчання, Перекваліфікація, Підвищення рівня кваліфікацій в сфері Забезпечення Якості, Контролю Якості та Тестування ПЗ(укр.)
• Львівська Школа тестування Програмного Забезпечення(укр.)