Test Levels
Рівні тестування – це групи тестових дій, які організовуються та керуються разом. Кожен рівень тестування — це екземпляр процесу тестування, що виконується стосовно програмного забезпечення на даному рівні розробки, від окремих одиниць або компонентів до повних систем. Рівні тестування пов’язані з іншими діями в рамках життєвого циклу розробки програмного забезпечення. Виділяють такі рівні тестування:
- Тестування компонентів
- Інтеграційне тестування
- Тестування системи
- Приймальне тестування
Рівні тесту характеризуються такими ознаками:
- Конкретні цілі
- Основа тестування, на яку посилаються для отримання тестових випадків
- Тестовий об’єкт (тобто те, що тестується)
- Типові дефекти та збої
- Специфічні підходи та відповідальність
Для кожного рівня тестування потрібне відповідне тестове середовище. Наприклад, під час приймального тестування ідеальним є тестове середовище, схоже на робоче, тоді як у компонентному тестуванні розробники зазвичай використовують власне середовище розробки.
Component Testing
Цілі компонентного тестування
Тестування компонентів (також відоме як модульне або юніт тестування) зосереджується на компонентах, які можна тестувати окремо. Цілі тестування компонентів включають:
- Зменшення ризику
- Перевірка того, чи функціональна та нефункціональна поведінка компонента відповідає специфікації
- Побудова впевненості в якості компонента
- Виявлення дефектів у компоненті
- Запобігання виходу дефектів на вищі рівні тестування
У деяких випадках, особливо в поетапних і ітеративних моделях розробки (наприклад, Agile), де тривають зміни коду, автоматизовані регресійні тести компонентів відіграють ключову роль у зміцненні впевненості в тому, що зміни не пошкодили існуючі компоненти.
Тестування компонентів часто виконується ізольовано від решти системи, залежно від моделі життєвого циклу розробки програмного забезпечення та системи, для чого можуть знадобитися макетні об’єкти, віртуалізація служб, джгути, заглушки та драйвери. Тестування компонентів може охоплювати функціональні можливості (наприклад, правильність обчислень), нефункціональні характеристики (наприклад, пошук витоків пам’яті) і структурні властивості (наприклад, тестування рішень).
Тестова база
Приклади робочих продуктів, які можна використовувати як тестову базу для тестування компонентів, включають:
- Детальний дизайн
- Код
- Модель даних
- Характеристики компонентів
Об’єкти тестування
Типові тестові об’єкти для тестування компонентів включають:
- Компоненти, вузли або модулі
- Код і структури даних
- Класи
- Модулі бази даних
Дефекти, як правило, усуваються відразу після їх виявлення, часто без офіційного управління дефектами. Однак коли розробники повідомляють про дефекти, це надає важливу інформацію для аналізу першопричини та вдосконалення процесу.
Конкретні підходи та відповідальність
Тестування компонентів зазвичай виконує розробник, який написав код, але для цього принаймні потрібен доступ до тестованого коду. Розробники можуть чергувати розробку компонента з пошуком і виправленням дефектів. Розробники часто пишуть і виконують тести після написання коду для компонента. Однак, особливо в гнучкій розробці, написання автоматизованих тестових випадків компонентів може передувати написанню програмного коду.
Наприклад, розглянемо розробку, керовану тестуванням (TDD). Розробка, орієнтована на тестування, є високоітеративною та базується на циклах розробки автоматизованих тестових випадків, потім створення та інтеграції невеликих фрагментів коду, а потім виконання тестів компонентів, виправлення будь-яких проблем і рефакторинг коду. Цей процес триває до тих пір, поки компонент не буде повністю зібрано та всі компоненти не пройдуть тестування. Розробка, орієнтована на тестування, є прикладом підходу «спочатку тестування». Хоча розробка, керована тестуванням, виникла в eXtreme Programming (XP), вона поширилася на інші форми Agile, а також на послідовні життєві цикли.
Integration Testing
Цілі інтеграційного тестування
Інтеграційне тестування фокусується на взаємодії між компонентами або системами. Цілі інтеграційного тестування включають:
- Зменшення ризику
- Перевірка того, чи функціональна та нефункціональна поведінка інтерфейсів відповідає дизайну та специфікаціям
- Побудова впевненості в якості інтерфейсів
- Пошук дефектів (які можуть бути в самих інтерфейсах або всередині компонентів чи систем)
- Запобігання виходу дефектів на вищі рівні тестування
Як і у випадку з тестуванням компонентів, у деяких випадках автоматизовані регресійні тести інтеграції забезпечують впевненість у тому, що зміни не порушили існуючі інтерфейси, компоненти чи системи.
Виділяють два різних рівня інтеграційного тестування, яке можна проводити на об’єктах тестування різного розміру, як описано нижче:
- Тестування інтеграції компонентів фокусується на взаємодії та інтерфейсах між інтегрованими компонентами. Тестування інтеграції компонентів виконується після тестування компонентів і, як правило, автоматизоване. При ітераційній та поетапній розробці тести інтеграції компонентів зазвичай є частиною процесу безперервної інтеграції.
- Тестування системної інтеграції фокусується на взаємодії та інтерфейсах між системами, пакетами та мікросервісами. Тестування системної інтеграції також може охоплювати взаємодію із зовнішніми організаціями (наприклад, веб-сервісами) та інтерфейси, які надаються ними. У цьому випадку організація-розробник не контролює зовнішні інтерфейси, що може створювати різні проблеми для тестування (наприклад, забезпечення усунення дефектів блокування тесту в коді зовнішньої організації, організація тестових середовищ тощо). Тестування системної інтеграції може проводитися після тестування системи або паралельно з поточними діями з тестування системи (як у послідовному, так і в ітеративному та поетапному розвитку).
Тестова база
Приклади робочих продуктів, які можна використовувати як тестову основу для інтеграційного тестування, включають:
- Проєктування програмного забезпечення та системи
- Діаграми послідовності
- Специфікації інтерфейсу та протоколу зв’язку
- Варіанти використання
- Архітектура на рівні компонентів або системи
- Робочі процеси
- Визначення зовнішнього інтерфейсу
Об’єкти тестування
Типові тестові об’єкти для інтеграційного тестування включають:
- Підсистеми
- Бази даних
- Інфраструктура
- Інтерфейси
- API
- Мікросервіси
Типові дефекти та збої
Приклади типових дефектів і несправностей для тестування інтеграції компонентів включають:
- Неправильні дані, відсутні дані або неправильне кодування даних
- Неправильна послідовність або час викликів інтерфейсу
- Невідповідність інтерфейсу
- Збої в зв’язку між компонентами
- Необроблені або неправильно оброблені збої зв’язку між компонентами
- Неправильні припущення щодо значення, одиниць або меж даних, що передаються між компонентами
Приклади типових дефектів і збоїв для тестування системної інтеграції включають:
- Неузгоджені структури повідомлень між системами
- Неправильні дані, відсутні дані або неправильне кодування даних
- Невідповідність інтерфейсу
- Збої в зв’язку між системами
- Необроблені або неправильно оброблені збої зв’язку між системами
- Неправильні припущення щодо значення, одиниць або меж даних, що передаються між системами
- Недотримання обов’язкових правил безпеки
Конкретні підходи та відповідальність
Тести інтеграції компонентів і тести інтеграції системи повинні зосереджуватися на самій інтеграції. Наприклад, у разі інтеграції модуля A з модулем B тести повинні зосереджуватися на зв’язку між модулями, а не на функціональності окремих модулів, оскільки це повинно бути розглянуто під час тестування компонентів. У разі інтеграції системи X із системою Y тести повинні зосереджуватися на зв’язку між системами, а не на функціональності окремих систем, оскільки це повинно бути розглянуто під час тестування системи. Застосовуються функціональні, нефункціональні та структурні типи випробувань.
Тестування інтеграції компонентів часто є обов’язком розробників. Тестування системної інтеграції зазвичай є обов’язком тестувальників. В ідеалі тестувальники, які виконують тестування інтеграції системи, повинні розуміти архітектуру системи та впливати на планування інтеграції.
Якщо інтеграційні тести та стратегія інтеграції плануються до створення компонентів або систем, ці компоненти або системи можна створювати в порядку, необхідному для найбільш ефективного тестування. Стратегії системної інтеграції можуть базуватися на архітектурі системи (наприклад, «зверху вниз» і «знизу вгору»), функціональних завданнях, послідовності обробки транзакцій або деяких інших аспектах системи чи компонентів. Щоб спростити ізоляцію дефектів і виявити дефекти на ранній стадії, інтеграція, як правило, повинна бути поступовою (тобто невелика кількість додаткових компонентів або систем одночасно), а не «великий вибух» (тобто інтеграція всіх компонентів або систем за один крок) . Аналіз ризиків найскладніших інтерфейсів може допомогти зосередити інтеграційне тестування.
Чим ширший обсяг інтеграції, тим важче стає ізолювати дефекти певного компонента чи системи, що може призвести до збільшення ризику та додаткового часу для усунення несправностей. Це одна з причин того, що безперервна інтеграція, коли програмне забезпечення інтегрується покомпонентно (тобто функціональна інтеграція), стала звичайною практикою. Така безперервна інтеграція часто включає автоматичне регресійне тестування, в ідеалі на кількох рівнях тестування.
Системне тестування
Цілі системного тестування
Тестування системи зосереджується на поведінці та можливостях усієї системи або продукту, часто враховуючи наскрізні завдання, які система може виконувати, і нефункціональну поведінку, яку вона демонструє під час виконання цих завдань. Цілі тестування системи включають:
- Зменшення ризику
- Перевірка того, чи функціональна та нефункціональна поведінка системи відповідає розробленим і специфікованим
- Перевірка того, що система повна і працюватиме належним чином
- Формування впевненості в якості системи в цілому
- Пошук дефектів
- Запобігання виходу дефектів на вищі рівні тестування або виробництва
Для певних систем перевірка якості даних також може бути метою. Подібно до тестування компонентів і тестування інтеграції, у деяких випадках автоматичні регресійні тести системи дають впевненість, що зміни не порушили існуючі функції чи наскрізні можливості. Тестування системи часто створює інформацію, яка використовується зацікавленими сторонами для прийняття рішень про випуск. Тестування системи також може задовольняти законодавчі чи нормативні вимоги або стандарти.
Тестове середовище в ідеалі має відповідати кінцевому цільовому або робочому середовищу.
Тестова база
Приклади робочих продуктів, які можна використовувати як тестову основу для тестування системи, включають:
- Специфікації вимог до системи та програмного забезпечення (функціональні та нефункціональні)
- Звіти про аналіз ризиків
- Варіанти використання (Use cases)
- Епіки та історії користувачів
- Моделі поведінки системи
- Діаграми стану
- Системні інструкції та посібники користувача
Об’єкти тестування
Типові тестові об’єкти для тестування системи включають:
- Додатки
- Апаратні/програмні системи
- Операційні системи
- Система, яка тестується (SUT – System under test)
- Конфігурація системи та конфігураційні дані
Типові дефекти та збої
Приклади типових дефектів і збоїв для тестування системи включають:
- Неправильні розрахунки
- Неправильна або несподівана функціональна або нефункціональна поведінка системи
- Неправильний контроль і потоки даних у системі
- Нездатність належним чином і повністю виконувати наскрізні функціональні завдання
- Збій належної роботи системи в системному середовищі
- Помилка роботи системи, порівняно з тим як описано в системній документації чи посібниках користувача
Конкретні підходи та відповідальність
Тестування системи має зосереджуватися на загальній наскрізній поведінці системи в цілому, як функціональної, так і нефункціональної. Тестування системи має використовувати найбільш відповідні методи для аспектів системи, що тестуються. Наприклад, може бути створена таблиця рішень, щоб перевірити, чи відповідає функціональна поведінка, як описано в бізнес-правилах.
Тестування системи зазвичай проводиться незалежними тестувальниками, які значною мірою покладаються на специфікації. Дефекти в специфікаціях (наприклад, відсутність історій користувачів, неправильно сформульовані бізнес-вимоги тощо) можуть призвести до нерозуміння або розбіжностей щодо очікуваної поведінки системи. Такі ситуації можуть спричинити хибні спрацьовування та хибні негативні результати, що витрачає час і знижує ефективність виявлення дефектів відповідно. Раннє залучення тестувальників до вдосконалення історій користувача або діяльності статичного тестування, наприклад оглядів, допомагає зменшити кількість таких ситуацій.
Приймальне тестування
Приймальне тестування, як і тестування системи, зазвичай зосереджується на поведінці та можливостях усієї системи чи продукту. Цілі приймального тестування включають:
- Встановлення впевненості в якості системи в цілому
- Перевірка того, що система повна і працюватиме належним чином
- Перевірка того, що функціональна та нефункціональна поведінка системи відповідає специфікаціям
Приймальні випробування можуть дати інформацію для оцінки готовності системи до розгортання та використання замовником (кінцевим користувачем). Дефекти можуть бути виявлені під час приймального тестування, але виявлення дефектів часто не є метою, а виявлення значної кількості дефектів під час приймального тестування в деяких випадках може вважатися великим ризиком проєкту. Приймальне тестування також може перевіряти відповідність правовим чи нормативним вимогам або стандартам.
Загальні форми приймального тестування включають наступні:
- Користувацьке приймальне тестування
- Операційне приймальне тестування
- Контрактне та регулятивне приймальне тестування
- Альфа- і бета-тестування
Користувацьке приймальне тестування (UAT). Перевірка прийнятності системи для користувача зазвичай зосереджена на перевірці придатності системи для використання запланованими користувачами в реальному або змодельованому робочому середовищі. Основною метою є створення впевненості в тому, що користувачі можуть використовувати систему для задоволення своїх потреб, виконання вимог і виконання бізнес-процесів з мінімальними труднощами, витратами та ризиком.
Операційне приймальне тестування (OAT)
Приймальні випробування системи операторами цієї системи або системними адміністраторами, зазвичай їх виконують у (модельованому) виробничому(робочому) середовищі. Тести зосереджуються на робочих аспектах і можуть включати:
- Тестування резервного копіювання та відновлення
- Встановлення, видалення та оновлення
- Аварійне відновлення
- Керування користувачами
- Завдання з технічного обслуговування
- Завдання завантаження та міграції даних
- Перевірка наявності вразливостей у безпеці
- Тестування продуктивності
Основна мета операційної приймальної перевірки полягає в зміцненні впевненості в тому, що оператори або системні адміністратори можуть підтримувати належну роботу системи для користувачів у робочому середовищі, навіть за виняткових або складних умов.
Контрактне та нормативне приймальне тестування
Тестування прийнятності за контрактом виконується відповідно до критеріїв прийнятності контракту для виробництва програмного забезпечення, розробленого на замовлення. Критерії прийняття повинні бути визначені, коли сторони погоджуються на контракт. Контрактне приймальне тестування часто виконується користувачами або незалежними тестувальниками.
Нормативні приймальні випробування проводяться на відповідність будь-яким нормам, яких необхідно дотримуватися, наприклад державним, правовим нормам або нормам безпеки. Регуляторне приймальне тестування часто виконується користувачами або незалежними тестувальниками, іноді результати перевіряються або перевіряються регуляторними органами.
Основна мета тестування прийнятності за контрактами та нормативними документами полягає в зміцненні впевненості в тому, що було досягнуто відповідності договірним або нормативним вимогам.
Альфа і бета тестування
Альфа- та бета-тестування зазвичай використовують розробники комерційного готового програмного забезпечення (COTS), які хочуть отримати відгуки від потенційних або наявних користувачів, клієнтів та/або операторів до того, як програмний продукт буде випущено на ринок. Альфа-тестування виконується на сайті організації-розробника не командою розробників, а потенційними чи існуючими клієнтами та операторами чи незалежною командою тестування. Бета-тестування виконується потенційними чи існуючими клієнтами та операторами на їхніх власних місцях. Бета-тестування може відбуватися після альфа-тестування або може відбуватися без будь-якого попереднього альфа-тестування.
Однією з цілей альфа- та бета-тестування є формування впевненості серед потенційних або існуючих клієнтів або операторів у тому, що вони можуть використовувати систему в звичайних повсякденних умовах і в робочому середовищі для досягнення своїх цілей з мінімальними труднощами, витратами, і ризиком. Іншою метою може бути виявлення дефектів, пов’язаних з умовами та середовищем, у яких буде використовуватися система, особливо коли ці умови та середовище важко відтворити групі розробників.
Тестова база
Приклади робочих продуктів, які можна використовувати як тестову базу для будь-якої форми приймального тестування, включають:
- Бізнес-процеси
- Вимоги користувача або бізнесу
- Норми, юридичні договори та стандарти
- Варіанти використання та історії користувачів
- Системні вимоги
- Документація щодо системи або користувача
- Процедури встановлення
- Звіти про аналіз ризиків
Крім того, в якості тестової бази для отримання тестових прикладів для операційної приймальної перевірки можна використовувати один або кілька з наступних робочих продуктів:
- Процедури резервного копіювання та відновлення
- Процедури аварійного відновлення
- Нефункціональні вимоги
- Операційна документація
- Інструкції з розгортання та встановлення
- Цільові показники
- Пакети баз даних
- Стандарти або правила безпеки
Типові тест-об’єкти
Типові тестові об’єкти для будь-якої форми приймального тестування включають:
- Система, яка тестується
- Конфігурація системи та конфігураційні дані
- Бізнес-процеси для повністю інтегрованої системи
- Системи відновлення (для безперервності бізнесу та тестування аварійного відновлення)
- Процеси експлуатації та обслуговування
- Форми
- Звіти
- Існуючі та перетворені виробничі дані
Типові дефекти та збої
Приклади типових дефектів для будь-якої форми приймального тестування включають:
- Системні робочі процеси не відповідають вимогам бізнесу чи користувача
- Бізнес-правила реалізовані неправильно
- Система не відповідає договірним або нормативним вимогам
- Нефункціональні збої, як-от вразливість системи безпеки, недостатня продуктивність під час високих навантажень або неправильна робота на підтримуваній платформі
Конкретні підходи та відповідальність
Приймальне тестування часто є обов’язком клієнтів, бізнес-користувачів, власників продуктів або операторів системи, а також можуть бути залучені інші зацікавлені сторони.
Приймальне тестування часто розглядається як останній рівень тестування в послідовному життєвому циклі розробки, але воно також може відбуватися в інший час, наприклад:
- Приймальні тестування програмного продукту COTS можуть відбуватися після його встановлення або інтеграції
- Перед тестуванням системи може проводитися приймальне тестування нового функціонального вдосконалення
При ітераційній розробці команди проєкту можуть використовувати різні форми приймального тестування під час і в кінці кожної ітерації, наприклад ті, які зосереджені на перевірці нової функції за її критеріями прийнятності, і ті, які зосереджені на перевірці того, що нова функція задовольняє потреби користувачів. Крім того, альфа-тести та бета-тести можуть відбуватися в кінці кожної ітерації, після завершення кожної ітерації або після серії ітерацій. Користувацьке приймальне тестування, операційне приймальне тестування, нормативне приймальне тестування також можуть відбуватися наприкінці кожної ітерації, після завершення кожної ітерації або після серії ітерацій.
Тестові рівні (версія 4.0)
У сілабусі описано наступні п’ять рівнів тестування:
- Тестування компонентів (також відоме як модульне тестування) зосереджується на тестуванні компонентів окремо. Для цього часто потрібна спеціальна підтримка, наприклад тестові пакети або фреймворки модульного тестування. Тестування компонентів зазвичай виконується розробниками у своїх середовищах розробки.
- Тестування інтеграції компонентів (також відоме як тестування інтеграції модулів) зосереджується на тестуванні інтерфейсів і взаємодії між компонентами. Тестування інтеграції компонентів значною мірою залежить від підходів стратегії інтеграції, таких як «знизу вгору», «зверху вниз» або «великий вибух».
- Тестування системи зосереджується на загальній поведінці та можливостях усієї системи або продукту, часто включаючи функціональне тестування наскрізних завдань і нефункціональне тестування характеристик якості. Для деяких нефункціональних характеристик якості бажано тестувати їх на повній системі в репрезентативному тестовому середовищі (наприклад, зручність використання). Також можливе використання моделювання підсистем. Тестування системи може виконуватися незалежною групою тестувальників і пов’язане зі специфікаціями системи.
- Тестування системної інтеграції зосереджено на тестуванні інтерфейсів тестованої системи та інших систем і зовнішніх служб. Тестування системної інтеграції вимагає відповідних тестових середовищ, бажано подібних до робочого середовища.
- Приймальне тестування зосереджено на перевірці та демонстрації готовності до розгортання, що означає, що система відповідає бізнес-потребам користувача. В ідеалі приймальне тестування має виконуватися цільовими користувачами. Основними формами приймального тестування є: приймальне тестування користувача (UAT), операційне приймальне тестування, договірне та нормативне приймальне тестування, альфа-тестування та бета-тестування.
Рівні тестування розрізняються за таким невичерпним списком атрибутів, щоб уникнути дублювання тестових дій:
- Тестовий об’єкт
- Цілі тестування
- Тестова база
- Дефекти та збої
- Підхід та відповідальність
В цьому відео починаємо працювати з секцією 2.2.
00:01:05 Рівні тестування
00:04:27 Тестування компонентів
00:14:38 Інтеграційне тестування
00:35:59 Системне тестування
00:51:33 Приймальне тестування
01:17:05 Рівні тестування (версія 4.0)