Тема. Види тестування

План

1.   Рівні і види тестування.

2.   Цілі тестування.

1.   Рівні і види тестування

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

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

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

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

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

Інтеграційне тестування або тестування взаємодій (integration testing) — контроль взаємодії між частинами системи (модулями, компонентами, підсистемами).

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

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

Альфа і бета тестування

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

Альфа—тестування (alpha testing) — використання майже готової версії продукту (як правило, програмного або апаратного забезпечення) штатними програмістами (розробниками і тестерами) з метою виявлення помилок в його роботі для їх подальшого усунення перед бета-тестуванням.

По закінченню тестування альфи, розробка входить в стадію бети.

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

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

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

Тестування, що засноване на вимогах (Requirement based testing) — тестування кожного припущення з певного документу (документи технічної підтримки, посібники та інша документація користувача).

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

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

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

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

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

 

2.    Цілі тестування

(Objectivies of Testing)

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

Тестові сценарії можуть розроблятися як для перевірки функціональних вимог (відомі як функціональні тести), так і для оцінки нефункціональних вимог. При цьому, існують такі тести, коли кількісні параметри та результати тестів можуть лише опосередковано говорити про задоволення цілей тестування (наприклад, "usability" — легкість, простота використання, в більшості випадків, не може бути явно описана кількісними характеристиками). Можна виділити наступні, найбільш поширені і обгрунтовані цілі (а, відповідно, види) тестування:

Приймальні та кваліфікаційні випробування

(Acceptance / qualification testing)

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

 Інсталяційне тестування

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

Функціональне тестування (Conformance testing / Functional testing / Correctness testing)

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

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

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

У завдання функціонального тестування входять:

Ø ідентифікація функціональних вимог:

o    ідентифікація зовнішніх функцій і побудова послідовностей функцій відповідно до їх використанням у ПЗ;

o   ідентифікація безлічі вхідних даних кожної функції і визначення областей їх зміни;

Ø  побудова тестових наборів та сценаріїв тестування функцій;

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

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

Досягнення та оцінка надійності (Reliability achievement and evaluation).

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

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

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

 Навантажувальне та стресс-тестування (Stress testing)

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

Порівняльне тестування (Back—to—back testing)

Одиничний набір тестів, що дозволяють порівняти дві версії системи.

 Тестування спроможності системи на відновлення (Recovery testing).

Мета — перевірка можливостей рестарту системи у випадку непередбаченої  катастрофи (disaster), що впливає на функціонування операційного середовища, в якому виконується система.

 Конфігураційне тестування (Configuration testing)

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

 Тестування зручності і простоти використання (Usability testing)

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

 

 

Питання для самоконтролю:

1.       Назвіть рівні тестування (Test Levels).

2.       Над чим проводяться тести?

3.       Навести типові цілі тестування (Objectives for testing).

4.       Приймальне тестування (Acceptance / qualification testing)

5.  Пояснити, навіщо використовують альфа і бета-тестування (Alpha and beta testing), хто його проводить, навести приклади.

6.       Функціональні тести / тести відповідності (Conformance testing / Functional testing / Correctness testing).

7.       Проаналізувати процес регресійного тестування (Regression testing).

8.       Проаналізувати процес навантажувального тестування (Stress testing).

9. Проаналізувати процес порівняльного тестування (Back-to-back testing), обґрунтувати доцільність його проведення.

10.    Тестування спроможності системи на відновлення (Recovery testing).

11.   Проаналізувати процес конфігураційного тестування (Configuration testing), обґрунтувати доцільність і умови його проведення.

12. Описати основні етапи тестування зручності і простоти використання (Usability testing), обґрунтувати доцільність проведення такого тестування.