Що таке Test Harness? (Приклади)

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

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

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

Навіщо використовувати Test Harness?

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

• Автоматизуйте процес тестування
• Виконайте набори тестів тестів
• Створення відповідних звітів про тестування
• Підтримка налагодження
• Для запису результатів кожного з тестів
• Допомагає розробникам вимірювати покриття коду на рівні коду
• Підвищення продуктивності системи за рахунок автоматизації
• Підвищення якості програмних компонентів і програм
• Щоб впоратися зі складною умовою, яку тестувальникам важко змоделювати

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

Ключові компоненти випробувального джгута

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

• Тестові скрипти: Автоматизовані інструкції, що вказують кроки, які потрібно виконати, та очікуваний результат, написані відповідно до тестовий скрипт конвенції.
• Механізм виконання тестів: Виконавець, який зчитує скрипти по порядку, вирішує залежності та запускає послідовне або паралельне виконання.
• Сховище тестових даних: Вхідні значення, що зберігаються поза скриптом у CSV, JSON, XML або базі даних з початковим значенням, часто заповнюються засоби генерації тестових даних.
• драйвери: Фіктивні модулі виклику, які викликають тестований компонент, коли справжній верхній рівень, такий як інтерфейс користувача, ще не завершений.
• Заглушки: Модулі, що повертають шаблонні відповіді, називаються фіктивними, наприклад, платіжна служба, яка відповідає «Платіж успішний» без звернення до банку.
• Валідатор виводу: Логіка твердження, яка порівнює фактичний вихід із очікуваним значенням і позначає кожен випадок як пройдений або не пройдений.
• Рівень ведення журналу та звітності: Мітки часу, знімки екрана, вивід консолі та зведення про виконання, які роблять кожну помилку tracможливо згодом.

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

Як працює тестовий ремінь безпеки?

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

1. Підготуйте середовище: Обладнання вирішує конфігурацію середовища, відкриває з'єднання та завантажує фікстури, тому кожен запуск починається з одного й того ж відомого стану.
2. Завантажте тестові скрипти: Скрипти, параметри та очікувані результати зчитуються з репозиторію. Під час виконання нічого не вводиться, що робить другий запуск порівнянним з першим.
3. Замініть відсутні модулі: Драйвери замінюють абонентів, яких ще не існує, а заглушки замінюють послуги, які є незавершеними, нестабільними або дорогими для виклику.
4. Викличте тестовану програму: Механізм виконання запускає робочий процес, описаний скриптом, незалежно від того, чи це виклик методу, API запит або взаємодія браузера.
5. Зафіксуйте фактичний результат: Повернені значення, корисні навантаження відповідей, рядки бази даних, рядки журналу та стан екрана записуються в міру їх створення.
6. Порівняйте з очікуваними результатами: Валідатор виводу стверджує кожне отримане значення. Будь-яка невідповідність позначає випадок як невдалий та записує як очікуване, так і спостережуване значення.
7. Журнал та звіт: Джгут записує мітку часу tracзапуску та генерує звіт про успішний/неуспішний результат, який розробник може прочитати без повторного запуску.
8. Зняти: Тимчасові дані, з'єднання та стан заглушки очищуються, тому наступний випадок не може успадкувати залишок від цього.

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

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

Існує два контексти, у яких використовується Test Harness

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

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

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

Типи випробувальних джгутів

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

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

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

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

Інструменти тестування джгутів

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

• Юніт: інструмент, що використовується під час використання Java
• Одиниця: Інструмент, який використовується для використання .Net framework

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

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

Тестовий джгут проти тестової рамки

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

Поширені запитання