Меню

Какво е тестова сбруя и как е приложима за нас, тестери

what is test harness

Опитайте Нашия Инструмент За Премахване На Проблемите

Не съм голям фен на етикетите. Ето какво имам предвид под това.

Ако трябва да проверя няколко аспекта, преди да определя дали QA може да бъде стартиран, просто ще направя списък и ще извърша действието. Според мен няма значение дали официално го наричам операция „Преглед на готовността за тестване“ или не - стига да правя това, което трябва да направя, мисля, че няма нужда да го наричам конкретно име или етикет .

Какво представлява тестовата сбруя

Но аз съм поправен. Наскоро в моя клас преподавах Agile-scrum модел за разработка на софтуер. Имаше въпрос „ как се извършва тестване в Agile метод? „Обяснявах два метода - единият е, когато се опитваме да го включим във всеки спринт, а другият е най-добрата практика, която научих от първа ръка, а именно да изоставам в QA спринта по отношение на този за развитие.

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

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

Следователно днес ще направим точно това: Научете процеса, който стои зад термина „Тест на сбруя“.

Както споменах преди в някои от предишните си статии: много може да се разбере от буквалното значение на името. Така че, проверете в речника си за значението на „Harness“ и голямото разкриване дали това се отнася или не, в този случай е нещо, което ще видим в края.

Има два контекста за това къде се използва тестовата сбруя:

  1. Тестване за автоматизация
  2. Тестване на интеграцията

Нека започнем с първата:

Какво ще научите:

Контекст # 1: Тестови снопове в тестовата автоматизация

В на тестване за автоматизация свят, Тестът се отнася до рамката и софтуерните системи, които съдържат тестовите скриптове, параметрите, необходими (с други думи, данни), за да стартират тези скриптове, да съберат резултатите от теста, да ги сравнят (ако е необходимо) и да наблюдават резултатите.

Ще се опитам да направя това по-опростено с помощта на пример.

Пример:

Ако говорих за проект, който използва HP Quick Test Professional (сега UFT) за функционално тестване, HP ALM е свързан за организиране и управление на всички скриптове, стартирания и резултати, а данните се избират от база данни на MS Access - Следното ще бъде тестовата система за този проект:

c ++ код за сортиране на вмъкване
  • Самият софтуер QTP (UFT)
  • Скриптовете и физическото местоположение, където се съхраняват
  • Тестовите набори
  • MS Access DB за предоставяне на параметри, данни или различни условия, които трябва да бъдат предоставени на тестовите скриптове
  • HP ALM
  • Резултатите от теста и сравнителните атрибути за наблюдение

Тествайте сбруя в автоматизацията

Както можете да видите, софтуерните системи (автоматизация, управление на тестове и т.н.), данни, условия, резултати - всички те стават неразделна част от тестовия колан - единственото изключение е самият AUT.

Контекст # 2: Тествайте снопове при тестване на интеграция

Сега е време да проучим какво означава тестовата сбруя в контекст на „Интеграционно тестване“ .

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

В идеалния случай, интеграционното тестване на два модула трябва и би било възможно да се извърши, когато и двата са 100% готови, тествани и готови за работа.

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

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

Пример: За да обясня допълнително това, позволете ми да използвам сценарий

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

Единица A, ако 100% е налична, а единица B не е, тогава разработчикът може да напише код, който е ограничен в своите възможности (това означава, че Unit B, ако има 10 функции, само 2 или 3, които са важни за интеграцията с А) ще бъде разработен и се използва за интеграция. Това се нарича a STUB.

Сега интеграцията ще бъде: Единица A-> Stub (заместване на B)

От друга страна, ако блок A е на разположение 0% и блок B е на 100%, симулацията или проксито трябва да бъде блок A тук. Следователно, когато извикващата функция е заменена от спомагателен код, тогава тя се нарича ШОФЬОР .

В този случай интеграцията би била : ШОФЬОР (заместващ A) -> Блок B

Цялата рамка: Процесът на планиране, създаване и използване на заглушки и / или драйвери за извършване на теста за интеграция се нарича Test Harness.

Забележка : горният пример е ограничен и сценарият в реално време може да не е толкова прост или толкова ясен като този. Приложенията в реално време имат сложни и съставни точки за интеграция.

В заключение:

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

Речникът на моя смартфон ми казва, че „Harness“ е (погледнете под контекста на глагола):

„Да се ​​приведат в условия за ефективно използване; получаване на контрол над за определен край; „

Следвайки това и адаптирайки това към тестване:

„Тестът е просто да създаде правилната рамка и да я използва (и всички нейни съставни елементи), за да контролира цялата дейност, за да се възползва максимално от ситуацията - независимо дали автоматизация или интеграция. „

Там почиваме нашия случай.

Още няколко неща, преди да завършим:

Въпрос: Какви са предимствата на тестовия колан?

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

Въпрос: Каква е разликата между тестовия колан и тестовата рамка ?

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

Въпрос: Има ли инструменти за тестване на сбруя ?

Тестовият сбруя включва инструменти - като софтуер за автоматизация, софтуер за управление на тестове и др. Въпреки това, няма конкретни инструменти за прилагане на тестов сбруя. Всички или всякакви инструменти могат да бъдат част от тестовия сноп: QTP, JUnit, HP ALM - всички те могат да бъдат съставни инструменти на всеки тестов сноп.

За автора: Тази статия е написана от член на екипа на STH Swati S.

И винаги с определения, винаги има различия в мненията. Приветстваме вашите мнения и обичаме да чуем какво мислите. Моля, не се колебайте да оставите коментар, въпроси или предложения по-долу.

Препоръчително четене

^