Какво е Test Harness? (Примери)

Тестова система за тестване на софтуер

Тестова система за тестване на софтуер е колекция от мъничета, драйвери и други поддържащи инструменти, необходими за автоматизиране на изпълнението на теста. Test harness изпълнява тестове с помощта на тестова библиотека и генерира тестови отчети. Тестовият пакет съдържа цялата информация, необходима за компилиране и изпълнение на тест, като тестови случаи, целеви порт за разполагане (TDP), изходен файл в процес на тестване, мъничета и т.н.

Казано по-просто, хардуер (сглобка) обгръща компонента, който искате да проверите, в контролирана среда. Съседните модули, които липсват, се заменят с малки фиктивни програми, входните данни постъпват от фиксиран набор от данни и всеки резултат се записва в лог, вместо да се чете от екрана. Следващите раздели обясняват защо екипите изграждат такъв, от какво е направен, как работи и къде се вписва.

Защо да използвате Test Harness?

Съществува система, която да елиминира чакането от тестовия цикъл. Тъй като симулира всичко, което все още не е готово, тестване на софтуер Екипът може да започне да проверява поведението още в първия спринт, а не след финалната интеграция. Диаграмата по-долу показва къде се намира свързващият елемент между тестовите скриптове и тестваното приложение.

• Автоматизирайте процеса на тестване
• Изпълнете тестови пакети от тестови случаи
• Генериране на асоциирани доклади от тестове
• Поддръжка за отстраняване на грешки
• За записване на резултатите от теста за всеки един от тестовете
• Помага на разработчиците да измерват покритието на кода на ниво код
• Увеличете производителността на системата чрез автоматизация
• Подобрете качеството на софтуерните компоненти и приложението
• Да се ​​справят със сложните условия, които тестерите трудно симулират

Тези ползи са най-важни при кратки цикли на пускане на код. Когато кодът се пуска няколко пъти седмично, дефект, който оцелява до етапа на интеграция, струва много повече на tracповече от един, хванат за кочан в деня, в който е написан. Тази награда обаче идва само когато сбруята е сглобена от правилните части.

Ключови компоненти на тестовия сноп

Сноубордът не е отделна програма, а съвкупност от части, всяка от които премахва по едно препятствие, което иначе би попречило на теста да се изпълнява без надзор.

• Тестови скриптове: Автоматизирани инструкции, посочващи стъпките за изпълнение и очаквания резултат, написани съгласно тестов скрипт конвенции.
• Механизъм за изпълнение на тестове: Изпълняващият модул, който чете скриптовете по ред, разрешава зависимости и задейства последователно или паралелно изпълнение.
• Хранилище за тестови данни: Входни стойности, съхранявани извън скрипта в CSV, JSON, XML или база данни със семена, често попълнени от инструменти за генериране на тестови данни.
• драйвери: Фиктивни извикващи модули, които извикват тествания компонент, когато истинският горен слой, като например потребителски интерфейс, е недовършен.
• Мънички: Модулите, наречени „фиктивни“, връщат шаблонни отговори, например платежна услуга, която отговаря „Плащането е успешно“, без да се свързва с банка.
• Валидатор на изхода: Логика на твърдение, която сравнява действителния резултат с очакваната стойност и маркира всеки случай като успешен или неуспешен.
• Слой за регистриране и отчитане: Временни отпечатъци, екранни снимки, конзолен изход и обобщение на изпълнението, които правят всеки неуспех tracвъзможно след това.

Премахнете която и да е част и сбруята престава да бъде автоматична, защото тогава нещо трябва да се подава ръчно при всяко бягане.

Как работи тестовият колан?

Сбруята повтаря един и същ цикъл при всяко изпълнение. Познаването на този цикъл ви казва точно къде се намира вашият собствен тестване за автоматизация активите се включват и коя стъпка е неуспешна, когато дадено изпълнение стане червено.

1. Подгответе средата: Снопът разрешава конфигурацията на средата, отваря връзки и зарежда устройства, така че всяко изпълнение започва от едно и също известно състояние.
2. Заредете тестовите скриптове: Скриптове, параметри и очаквани резултати се четат от хранилището. Нищо не се въвежда по време на изпълнение, което прави второто изпълнение сравнимо с първото.
3. Заменете липсващите модули: Драйверите заместват повикващи, които все още не съществуват, а „stubs“-ите заместват услуги, които са недовършени, нестабилни или скъпи за обаждане.
4. Извикайте тестваното приложение: Изпълнителният механизъм задейства работния процес, описан от скрипта, независимо дали това е извикване на метод, API заявка или взаимодействие с браузъра.
5. Заснемете действителния резултат: Върнатите стойности, полезните товари на отговорите, редовете от базата данни, редовете от лога и състоянието на екрана се записват, когато се генерират.
6. Сравнете с очакваните резултати: Валидаторът на изхода прави проверка за всяка заснета стойност. Всяко несъответствие маркира случая като неуспешен и записва както очакваната, така и наблюдаваната стойност.
7. Дневник и отчет: Сбруята записва времеви отпечатък tracна изпълнението и генерира отчет за успешно/неуспешно изпълнение, който разработчикът може да прочете, без да изпълнява нищо отново.
8. Разглобяване: Временните данни, връзките и състоянието на заключителните елементи се изчистват, така че следващият случай не може да наследи остатък от този.

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

Разработен пример прави цикъла конкретен. Да предположим, че страницата за плащане е готова, но платежният шлюз не е. Драйверът задейства заявката, която интерфейсът обикновено би изпратил, stub отговаря първо с „Плащане успешно“ и след това с timeout, а валидаторът потвърждава поръчката в единия случай и подканя за повторен опит в другия. И двата пътя се проверяват, преди екипът на шлюза да напише ред код.

Има два контекста, в които се използва Test Harness

Същият механизъм служи на две различни цели, а речникът се променя леко в зависимост от това в коя от тях се намирате.

1. Тестване на автоматизацията: Той съдържа тестови скриптове, параметри, необходими за изпълнение на тези скриптове и събиране на резултати за анализирането им
2. Интеграционно тестване: Използва се за сглобяване на две единици код или модул, които взаимодействат помежду си, за да проверят дали комбинираното поведение е според очакванията или не

Да разгледаме модул за вход и модул за профил, които трябва да обменят потребителски токен. В контекста на интеграцията, драйвер симулира успешно влизане и предава токена на логиката на профила, така че картата на даннитеping, проверката на разрешенията и рендирането на екрана могат да бъдат проверени, преди да е завършена истинската услуга за удостоверяване. В контекста на автоматизацията, същата двойка случаи се добавя към пакет и се изпълнява отново при всяка компилация, без никой да я докосва отново.

Видове тестови колани

Тъй като софтуерът е изграден на слоеве, хардуерът обикновено е специализиран за слоя, който проверява. Четири вида обхващат почти всеки проект.

A тестов сноп за модули изпълнява най-малките части код, като например една функция или метод, като всяка зависимост се заменя със заключващ елемент (stub). Той е най-бързият за изпълнение и най-евтиният за поддръжка, поради което модулно тестване Пакетите обикновено са първият инструмент, който екипът изгражда. Тестването на данъчно изчисление без докосване на модула за фактуриране е типична употреба.

An тестов сноп за интеграция проверява дали два или повече модула си сътрудничат правилно и е слоят, където се появяват несъответствия в данните и неуспешни повиквания. Това е системата, описана в интеграционно тестване контекста по-горе, например проверка дали услуга за поръчки предава правилния полезен товар на платежна услуга.

A системен тестов кабелен сноп управлява цялостен поток от край до край между интерфейс, услуга и база данни, така че системно тестване може да потвърди, че бизнес правилата са валидни, след като всеки слой е наличен. A сноп за регресионен тест след това изпълнява отново натрупания пакет след всяка промяна, което е това, което прави регресионно тестване практично, когато няколкостотин сценария трябва да се повторят при всяко сливане.

Инструменти за тестови снопове

Всеки от тези типове обикновено се изгражда върху съществуващ инструмент, а не от нулата. Двата класически варианта остават рамките на ниво модул:

• Джунит: Инструмент, използван при използване Java
• единица: Инструмент, използван за използване .Net рамка

Освен тези две, повечето екипи добавят инструменти, които разширяват възможностите до браузъра, API слоя или профила на натоварване. Таблицата по-долу съпоставя често срещаните опции с ролята, която всяка от тях играе.

Независимо коя комбинация изберете, снопът се изплаща само след като работи без надзор, така че го свържете към... непрекъсната интеграция работа в началото. По-широк каталог с опции е посочен в Guru99 инструменти за тестване закръгляване. Едно разграничение все още предизвиква объркване и си струва да го уредите, преди да изберете каквото и да било.

Тестова система срещу тестова рамка

Обхващащата система (harness) и рамката за автоматизация често се третират като едно и също нещо, но те отговарят на различни въпроси: обхващащата система е това, което изпълнява тест, докато рамката е структурата, в която са проектирани тестовете. Таблицата по-долу ги поставя една до друга.

Въпроси и Отговори