Какво е adhoc тестване? Типове с пример

Какво е Ad Hoc тестване?

Ad Hoc тестване е спонтанен намлява гъвкав начин за тестване на софтуер, без да се следва определен план или документация. Вместо да подготвяте тестови случаи предварително, вие се потапяте директно и започвате да изследвате приложението. Терминът „по предварителна заявка“ означава „за конкретна цел“ или „непланирано“, което наистина отразява този стил на тестване.

Нека го кажа просто. Представете си, че току-що съм инсталирал ново приложение на устройството си. Вместо да отмятам списък със стъпки за тестване, започвам да докосвамping наоколо. Може да опитам да въведа странни данни, да използвам приложението по неочаквани начини или дори да се опитам да прекъсна потока му нарочно. Целта ми тук е да видя как приложението се справя реална, непредсказуема употреба– не само идеалните сценарии.

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

Въпреки че ad-hoc тестването може да изглежда неформално, истинската му стойност идва от експертния опит и способността на тестващия да... мисли нестандартноЧесто се разглежда като вид тестване на черна кутия тъй като се фокусира върху това как софтуерът се държи на пръв поглед, а не върху това как е изграден отвътре. Използвано заедно със структурираното тестване, Adhoc тестването помага да се осигури по-ефективно надежден намлява лесен за употреба продукт.

Следващото видео ви показва как да направите Adhoc тестване.

Кликнете тук ако видеото не е достъпно

Кога да се извършват ad hoc тестове?

Познаването на най-доброто време за извършване на Ad Hoc тестване може да окаже голямо влияние върху качеството на вашия софтуер. През годините научих, че времето е ключово за този гъвкав и спонтанен подход към тестването. Ad Hoc тестването се вписва идеално, когато трябва бързо да проверите за проблеми, които структурираните тестови случаи може да пропуснат. Нека разгледаме основните ситуации, в които Ad Hoc тестването е най-ценно:

• В ранен етап на развитие: Работи добре, когато официалните тестови случаи все още не са готови. Можете бързо да забележите грешки в новите функции, преди да бъдат създадени официалните тестови планове.
• Преди началото на официалното тестване: Използвайте Ad Hoc тестване като бързо сканиране, за да се уверите, че основните неща работят. Това помага да се избегне загубата на време за счупени компилации по време на официални тестови цикли.
• След завършване на официалното тестване: Дори след като са изпълнени всички тестови случаи, някои грешки все още могат да се промъкнат. Ad Hoc тестването ви позволява да търсите дефекти, които структурираното тестване може да пропусне, особено тези извън документираните изисквания.
• Когато нямате много време: Понякога просто няма достатъчно време за пълен кръг от тестове. В такива случаи опитните тестери могат да използват Ad Hoc тестване, за да открият бързо най-важните проблеми.
• За да проучите дадена функция задълбочено: Ако искате наистина да разберете как се държи определена част от софтуера, Ad Hoc тестването ви позволява да изследвате свободно, без да се придържате към скрипт.
• За проверки на използваемостта: Можете да се поставите на мястото на потребителя, за да видите дали има объркващи или фрустриращи части от софтуера. Това помага за подобряване на цялостното изживяване.
• По време на бета тестване: Много бета тестери естествено използват Ad Hoc тестване, тъй като изпробват софтуера в реални ситуации, разкривайки проблеми, които се появяват само при реална употреба.

Видове ad hoc тестове

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

• Buddy Тестване: Този метод свързва разработчик и тестер, които работят рамо до рамо. Разработчикът обяснява как е била създадена функцията. Междувременно тестерът я изследва от гледна точка на потребителя. Тази комбинация от знания за кодиране и умения за тестване помага за ранно откриване на проблеми, често веднага след края на кодирането.
• Тестване на двойки: Двама тестери работят заедно на едно и също устройство. Единият изследва приложението, докато другият предлага различни входни данни и наблюдава поведението. Те се редуват и споделят бележки. Това сътрудничество в реално време стимулира креативността и често открива повече дефекти, отколкото самостоятелното тестване.
• Тестване на маймуни: Това е най-непредсказуемият подход. Тестер или инструмент произволно кликва, пише или навигира в приложението. Целта е системата да се натоварва, докато се счупи. Макар че това може да изглежда хаотично, това е чудесен начин за откриване на сривове или слаби места. Само не забравяйте, че възпроизвеждането на открити по този начин грешки може да бъде сложно.

Всеки от тези подходи има своите силни страни. Изборът на правилния зависи от нуждите на вашия проект, динамиката на екипа и колко бързо е необходима обратна връзка. От това, което съм виждал, комбинирането на тези методи може да извлече най-доброто от Ad Hoc тестването – разкривайки проблеми, които скриптовото тестване може да пропусне.

Предимства на Ad-Hoc тестването

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

• Разкрива скрити грешки: Без ограниченията на предварително дефинираните тестови случаи, той изследва неочаквани пътища, където често се крият грешки.
• Бърза и лесна настройка: Няма нужда от подробни планове за тестване или документация, което спестява много време, когато е необходима бърза обратна връзка.
• Рентабилно, когато времето е ограничено: Идеално за ситуации, в които ресурсите са ограничени, но все пак е необходимо бързо откриване на критични грешки.
• Прозрения от реални потребители: Тъй като тестерите се държат като крайни потребители, процесът на тестване може да подчертае недостатъци в използваемостта, които формалните тестове биха могли да пропуснат.
• Използва интуицията на тестера: Опитните тестери могат да разчитат на своя опит, за да открият фини дефекти, които инструментите или скриптовете биха могли да пропуснат.
• Подобрява формалното тестване: Това не замества официалното тестване. Вместо това, добавя още един слой увереност, като разширява обхвата на теста.
• Незабавна обратна връзка: Особено полезно в гъвкави системи, където грешките трябва да бъдат открити и отстранени бързо, за да се поддържа плавността на процеса.

Недостатъци на Ad-Hoc тестването

Ad Hoc тестването е свързано с няколко ограничения, които могат да повлияят както на качеството на тестването, така и на крайния резултат. Нека ги обясня ясно от моя опит в тестването.

• Трудно възпроизводими бъгове: Тъй като няма структуриран подход или подробен запис, възпроизвеждането на проблем може да бъде сложно. Това прави отстраняването му по-трудно за разработчиците.
• Разчита на опита на тестващия: Успехът на този метод зависи много от това колко умел или запознат е тестерът с продукта. Начинаещ може да пропусне важни недостатъци, които опитен тестер би забелязал.
• Няма пълно покритие на теста: Ad Hoc тестването не следва планиран път. Това означава, че някои важни области може да останат непроверени, без никой да забележи, докато не стане твърде късно.
• Липсва Tracking и показатели: Без никакви тестови случаи или лог файлове е трудно да се измери напредъкът, да се идентифицират модели или да се разбере какво е тествано. Това намалява видимостта за екипите и заинтересованите страни.
• Не е подходящ за приложения с висок риск: Проектите в здравеопазването, банковото дело или критичните за безопасността системи изискват щателна документация и валидиране. Само Ad Hoc тестването не отговаря на тези строги стандарти.
• Може да губи време без фокус: Ако тестерът няма поне неформални цели, той може да прекара твърде много време в проучване на функции с нисък приоритет. Това забавя цялостния цикъл на тестване.

Най-добри практики за ефективно ad hoc тестване

За да увеличите максимално ползите от Ad Hoc тестването, въпреки неформалния му характер, помислете за тези практики, които преодоляват разликата между неструктурираното проучване и надеждното откриване на дефекти. tracцар:

1) Добри бизнес познания

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

2) Тестови ключови модули

Ключовите бизнес модули трябва да бъдат идентифицирани и насочени към Ad-Hoc тестване. Критичните за бизнеса модули трябва да бъдат тествани първо, за да се получи увереност в качеството на системата.

3) Дефекти в записа

Всички дефекти трябва да бъдат записани или написани в бележник. Дефектите трябва да бъдат възложени на разработчиците за отстраняване. За всеки валиден дефект трябва да бъдат написани съответните тестови случаи и те трябва да бъдат добавени към планираните тестови случаи.

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

4) Сдвояване

Както се вижда в Buddy или Двойно тестване, сътрудничеството може да донесе различни перспективи и да подобри откриването на дефекти.

Примери за Adhoc тестове

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

• Стрес тест за функцията за вход: Тестер многократно влиза и излиза с различни идентификационни данни, някои от които неправилни, за да види дали системата се срива или реагира странно.
• Необичаен потребителски вход: Въвеждане на символи, изключително дълги низове или неочаквани файлови формати, за да се провери как реагира системата. Това помага да се установи колко добре се обработва валидирането на входа.
• Случайни кликвания и навигация: Тестерът кликва през приложението на случаен принцип – скочиping между страниците, задействайки бутони в непоследователност – за да се забележат неочаквани поведения.
• Хаос при качване на файлове: Качване на неподдържани типове файлове или повредени файлове за тестване на надеждността на функцията за качване.
• Тестване на прекъсвания: Прекъсване на процес (като затваряне на раздел по време на запазване или прекъсване на интернет връзката), за да се види как системата се възстановява.

Сравнителен анализ с проучвателно тестване

Въпреки че често се смесват, Ad Hoc и Exploratory Testing показват различни оперативни параметри:

Характеристика	Ad Hoc тестване	Проучвателно тестване
документация	Само след изпълнението	Непрекъснат запис
Планиране	None	Леки чартърни полети
Структура на сесията	Напълно неструктуриран	Итерации с ограничено време
Възпроизвеждане на дефекти	33% възпроизводимост	78% възпроизводимост
Интеграция на автоматизацията	Ограничена приложимост	42% вграждане на инструменти

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