Типи тестування
Тип тестування — це група тестових дій, спрямованих на перевірку конкретних характеристик програмної системи або частини системи на основі конкретних цілей тестування. Такі цілі можуть включати:
- Оцінка характеристик функціональної якості, таких як повнота, правильність і відповідність
- Оцінка нефункціональних характеристик якості, таких як надійність, продуктивність, безпека, сумісність і зручність використання
- Оцінка того, чи структура або архітектура компонента чи системи є правильною, повною та відповідає вимогам
- Оцінка наслідків змін, як-от підтвердження того, що дефекти виправлено (підтверджувальне тестування) та пошук ненавмисних змін у поведінці внаслідок змін програмного забезпечення чи середовища (регресійне тестування)
Функціональне тестування
Функціональне тестування системи включає тести, які оцінюють функції, які система повинна виконувати. Функціональні вимоги можуть бути описані в робочих продуктах, таких як специфікації бізнес-вимог, епіки, історії користувачів, варіанти використання або функціональні специфікації, або вони можуть бути незадокументованими. Функції – це «те, що» повинна робити система.
Функціональні тести слід виконувати на всіх рівнях тестування (наприклад, тести для компонентів можуть базуватися на специфікації компонентів), хоча фокус на кожному рівні різний.
Функціональне тестування розглядає поведінку програмного забезпечення, тому методи чорної скриньки можуть бути використані для отримання умов тестування та тестових випадків для функціональності компонента чи системи.
Ретельність функціонального тестування можна виміряти за допомогою функціонального покриття. Функціональне покриття – це ступінь, до якого певна функціональність була використана тестами, і виражається у відсотках від типу покритого елемента. Наприклад, використовуючи відстежуваність між тестами та функціональними вимогами, можна розрахувати відсоток цих вимог, які охоплюються тестуванням, потенційно виявивши прогалини в покритті.
Розробка та виконання функціональних тестів може вимагати спеціальних навичок або знань, таких як знання конкретної бізнес-проблеми, яку вирішує програмне забезпечення (наприклад, програмне забезпечення для геологічного моделювання для нафтової та газової промисловості).
Нефункціональне тестування
Нефункціональне тестування системи оцінює характеристики систем і програмного забезпечення, такі як зручність використання, ефективність продуктивності або безпека. Нефункціональне тестування — це перевірка того, «наскільки добре» поводиться система.
Всупереч поширеній помилковій думці, нефункціональне тестування можна і часто потрібно проводити на всіх рівнях тестування, і робити це якомога раніше. Пізнє виявлення нефункціональних дефектів може бути надзвичайно небезпечним для успіху проекту.
Методи чорної скриньки можуть бути використані для отримання умов тестування та тестових кейсів для нефункціонального тестування. Наприклад, аналіз граничних значень можна використовувати для визначення умов напруги для тестування продуктивності.
Ретельність нефункціонального тестування можна виміряти за допомогою нефункціонального покриття. Нефункціональне покриття – це ступінь, до якого певний тип нефункціонального елемента перевіряється тестами, і виражається у відсотках від типу покритого елемента. Наприклад, використовуючи відстеження між тестами та підтримуваними пристроями для мобільної програми, можна обчислити відсоток пристроїв, які розглядаються тестуванням на сумісність, потенційно виявивши прогалини в охопленні.
Розробка та виконання нефункціонального тесту може включати спеціальні навички чи знання, такі як знання притаманних недоліків дизайну чи технології (наприклад, уразливості безпеки, пов’язані з певними мовами програмування) або конкретної бази користувачів (наприклад, персоналії користувачів системи управління закладом охорони здоров’я).
Тестування білої скриньки
Тестування білої скриньки виводить тести на основі внутрішньої структури або реалізації системи. Внутрішня структура може включати код, архітектуру, робочі процеси або потоки даних у системі.
Ретельність тестування білої скриньки можна виміряти через структурне покриття. Структурне покриття — це ступінь, до якого певний тип структурного елемента перевірено тестами, і виражається у відсотках від типу охопленого елемента.
На рівні тестування компонентів охоплення коду базується на відсотку перевіреного коду компонента та може вимірюватися з точки зору різних аспектів коду (елементів охоплення), таких як відсоток виконуваних операторів, протестованих у компоненті, або відсоток перевірених результатів рішення. Ці типи покриття разом називають покриттям коду. На рівні тестування інтеграції компонентів тестування білої скриньки може ґрунтуватися на архітектурі системи, наприклад на інтерфейсах між компонентами, а структурне покриття може вимірюватися у відсотках інтерфейсів, які перевіряються тестами.
Розробка та виконання тесту «білої скриньки» може включати спеціальні навички чи знання, наприклад спосіб створення коду, спосіб зберігання даних (наприклад, для оцінки можливих запитів до бази даних), а також те, як використовувати інструменти покриття та правильно інтерпретувати їхні результати.
Тестування пов’язане зі змінами
Коли в систему вносяться зміни або для виправлення дефекту, або через нову чи змінену функціональність, слід провести тестування, щоб підтвердити, що зміни виправили дефект або реалізували функціональні можливості належним чином і не спричинили жодних непередбачуваних несприятливих наслідків.
Підтверджуюче тестування: після усунення дефекту програмне забезпечення можна перевірити за допомогою всіх тестових кейсів, які не пройшли через дефект, які слід повторно виконати на новій версії програмного забезпечення. Програмне забезпечення також може бути перевірено за допомогою нових тестів, щоб охопити зміни, необхідні для усунення дефекту. Щонайменше кроки для відтворення помилок, викликаних дефектом, необхідно виконати повторно в новій версії програмного забезпечення. Метою підтверджувального тесту є підтвердження того, чи було успішно виправлено початковий дефект.
Регресійне тестування: можливо, що зміна, внесена в одну частину коду, будь то виправлення чи зміна іншого типу, може випадково вплинути на поведінку інших частин коду, незалежно від того, в межах того самого компонента, в інших компонентах тій же системі або навіть в інших системах. Зміни можуть включати зміни в середовищі, такі як нова версія операційної системи або системи керування базами даних. Такі ненавмисні побічні ефекти називаються регресією. Регресійне тестування передбачає виконання тестів для виявлення таких небажаних побічних ефектів.
Особливо в ітераційних і поетапних життєвих циклах розробки (наприклад, Agile), нові функції, зміни існуючих функцій і рефакторинг коду призводять до частих змін коду, що також вимагає тестування, пов’язаного зі змінами. Через те, що система розвивається, підтверджуюче та регресійне тестування є дуже важливими. Це особливо важливо для систем Інтернету речей, де окремі об’єкти (наприклад, пристрої) часто оновлюються або замінюються.
Набори регресійних тестів виконуються багато разів і, як правило, розвиваються повільно, тому регресійне тестування є сильним кандидатом на автоматизацію. Автоматизацію цих тестів слід починати на ранніх стадіях проекту.
Тестові типи та тестові рівні
Можна виконати будь-який із зазначених вище типів тестів на будь-якому рівні тестування. Для ілюстрації приклади функціональних, нефункціональних, і тестів білої скриньки, пов’язаних зі змінами, будуть наведені на всіх рівнях тестування для банківської програми, починаючи з функціональних тестів:
- Для тестування компонентів тести розроблені на основі того, як компонент має обчислювати складні відсотки.
- Для тестування інтеграції компонентів тести розроблені на основі того, як інформація облікового запису, отримана в інтерфейсі користувача, передається до бізнес-логіки.
- Для тестування системи тести розроблені на основі того, як власники рахунків можуть подати заявку на отримання кредитної лінії на своїх поточних рахунках.
- Для тестування інтеграції системи тести розроблено на основі того, як система використовує зовнішній мікросервіс для перевірки кредитної оцінки власника облікового запису.
- Для перевірки приймання тести розроблені на основі того, як банкір розглядає схвалення або відхилення кредитної заявки.
Нижче наведено приклади нефункціональних тестів:
- Для тестування компонентів тести продуктивності призначені для оцінки кількості циклів процесора, необхідних для виконання складного розрахунку сумарних відсотків.
- Для тестування інтеграції компонентів тести безпеки призначені для вразливості переповнення буфера через дані, що передаються від інтерфейсу користувача до бізнес-логіки.
- Для тестування системи тести переносимості призначені для перевірки того, чи рівень презентації працює на всіх підтримуваних браузерах і мобільних пристроях.
- Для тестування системної інтеграції тести надійності призначені для оцінки надійності системи, якщо мікросервіс кредитної оцінки не відповідає.
- Для приймального тестування тести на зручність використання призначені для оцінки доступності інтерфейсу банківської обробки кредитів для людей з обмеженими можливостями.
Нижче наведено приклади тестів білої скриньки:
- Для тестування компонентів тести розроблені для досягнення повного охоплення операторів і рішень для всіх компонентів, які виконують фінансові розрахунки.
- Для тестування інтеграції компонентів тести призначені для визначення того, як кожен екран в інтерфейсі браузера передає дані на наступний екран і в бізнес-логіку.
- Для тестування системи тести призначені для охоплення послідовностей веб-сторінок, які можуть з’являтися під час подачі заявки на кредитну лінію.
- Для тестування системної інтеграції тести розроблені для виконання всіх можливих типів запитів, надісланих до мікросервісу кредитних оцінок.
- Для приймального тестування тести розроблено для охоплення всіх підтримуваних структур файлів фінансових даних і діапазонів значень для міжбанківських переказів.
Нижче наведено приклади тестів, пов’язаних зі змінами:
- Для тестування компонентів автоматизовані регресійні тести створюються для кожного компонента та включаються в структуру безперервної інтеграції.
- Для тестування інтеграції компонентів тести призначені для підтвердження виправлень пов’язаних з інтерфейсом дефектів, коли виправлення перевіряються в сховищі коду.
- Для тестування системи всі тести для даного робочого циклу виконуються повторно, якщо будь-який екран цього робочого процесу змінюється.
- Для тестування системної інтеграції тести програми, яка взаємодіє з мікросервісом оцінки кредитоспроможності, повторно виконуються щодня в рамках безперервного розгортання цього мікросервісу.
- Для приймального тестування всі попередньо невдалі тести виконуються повторно після усунення дефекту, виявленого під час приймального тестування.
Хоча в цьому розділі наведено приклади кожного типу тесту на кожному рівні, для всього програмного забезпечення необов’язково мати кожен тип тесту на кожному рівні. Однак важливо запускати відповідні типи тестів на кожному рівні, якомога раніше.
Типи тестування (версія 4.0)
Існує багато типів тестування, які можна застосовувати в проєктах. У цьому сілабусі розглядаються наступні чотири типи тестів: функціональне тестування, нефункціональне тестування, тестування чорної скриньки, тестування білої скриньки.
Функціональне тестування оцінює функції, які повинен виконувати компонент або система. Функції – це «те, що» повинен робити тестовий об’єкт. Основною метою функціонального тестування є перевірка функціональної повноти, функціональної правильності та функціональної відповідності.
Нефункціональне тестування оцінює атрибути, відмінні від функціональних характеристик компонента або системи. Нефункціональне тестування — це перевірка того, «наскільки добре поводиться система». Основною метою нефункціонального тестування є перевірка характеристик якості нефункціонального програмного забезпечення. Стандарт ISO/IEC 25010 надає таку класифікацію характеристик якості нефункціонального програмного забезпечення:
- Ефективність виконання
- Сумісність
- Зручність використання
- Надійність
- Безпека
- Ремонтопридатність
- Портативність
Іноді нефункціональне тестування доцільно розпочинати на ранніх стадіях життєвого циклу (наприклад, як частину перевірки та тестування компонентів або тестування системи). Багато нефункціональних тестів є похідними від функціональних тестів, оскільки вони використовують ті самі функціональні тести, але перевіряють, що під час виконання функції виконується нефункціональне обмеження (наприклад, перевірка того, що функція виконується протягом заданого часу, або функція може перенести на нову платформу). Пізнє виявлення нефункціональних дефектів може становити серйозну загрозу для успіху проєкту. Для нефункціонального тестування іноді потрібне дуже специфічне тестове середовище, наприклад лабораторія зручності використання для тестування зручності використання.
Тестування чорної скриньки базується на специфікаціях і одержує тести з документації щодо об’єкта тестування. Основна мета тестування чорної скриньки — перевірити поведінку системи на відповідність її специфікаціям.
Тестування білої скриньки базується на структурі та виводить тести з реалізації або внутрішньої структури системи (наприклад, коду, архітектури, робочих процесів і потоків даних). Основна мета тестування білої скриньки — охопити базову структуру тестами до прийнятного рівня.
Усі чотири вищезазначені типи тестування можна застосовувати до всіх рівнів тестування, хоча фокус буде різним на кожному рівні. Різні методи тестування можуть бути використані для отримання тестових умов і тестових випадків для всіх згаданих типів тестування.
Тестування і зміни (v 4.0)
Зміни, як правило, вносяться до компонента чи системи, щоб або покращити його, додавши нову функцію, або виправити це, усунувши дефект. Тоді тестування має також включати тестування на підтвердження та регресійне тестування.
Підтверджувальне тестування підтверджує, що початковий дефект було успішно виправлено. Залежно від ризику можна протестувати виправлену версію програмного забезпечення кількома способами, зокрема:
- виконання всіх тестових прикладів, які раніше були невдалими через дефект, або також через
- додавання нових тестів для покриття будь-яких змін, необхідних для усунення дефекту
Однак, коли для усунення дефектів бракує часу або грошей, перевірка підтвердження може бути обмежена простим виконанням кроків, які повинні відтворити збій, викликаний дефектом, і перевіркою того, що збій не виникає.
Регресійне тестування підтверджує відсутність несприятливих наслідків через зміни, включаючи виправлення, яке вже пройшло підтверджувальне тестування. Ці несприятливі наслідки можуть вплинути на той самий компонент, де було внесено зміни, інші компоненти в тій же системі або навіть інші підключені системи. Регресійне тестування може не обмежуватися самим тестовим об’єктом, але також може бути пов’язане з навколишнім середовищем. Бажано спочатку виконати аналіз впливу, щоб оптимізувати обсяг регресійного тестування. Аналіз впливу показує, на які частини програмного забезпечення це може вплинути.
Набори регресійних тестів виконуються багато разів, і зазвичай кількість регресійних тестів зростатиме з кожною ітерацією або випуском, тому регресійне тестування є сильним кандидатом на автоматизацію. Автоматизацію цих тестів слід починати на ранніх стадіях проєкту. Там, де використовується CI, наприклад у DevOps, доцільно також включити автоматизовані регресійні тести. Залежно від ситуації це може включати регресійні тести на різних рівнях.
Підтверджувальне тестування та регресійне тестування об’єкта тестування необхідно на всіх рівнях тестування, якщо на цих рівнях тестування виправлено дефекти або внесено зміни.
В цьому відео починаємо працювати з секцією 2.3.
00:00:43 Типи тестування
00:03:12 Функціональне тестування
00:07:18 Нефункціональне тестування
00:12:15 Тестування білої скриньки
00:17:04 Тестування пов’язане зі змінами
00:24:35 Типи тестування та Рівні тестування
00:37:39 Типи тестування (v 4.0)