Стратегија за автоматизација на тестот за агилни проекти

Овој пример за стратегија за автоматизација на тестот претпоставува модел на континуирана испорака со повеќе агилни тимови.

Во претходните написи, сеопфатен Стратегија за агилен тест документ, како и како да поставите функција за квалитет од почеток за агилен проект и како автоматското тестирање е една од клучните ставки во првичното поставување.

Во овој пример за Стратегија за автоматизација на тестот, ги набројувам клучните точки што треба да се разгледаат за да се извлече максимумот од обидот за тест автоматизација.

Извршно резиме

Автоматското тестирање е основна активност на која било методологија за агилен развој. Како што се движиме кон континуирано распоредување, автоматската тест станува сè поважна поради брзата реакција на повратни информации што му ја дава на тимот за развој за здравјето на апликацијата.

Со цел да се добијат овие брзи повратни информации, автоматските тестови треба да се извршуваат постојано, треба да бидат брзи и резултатите од тестовите да бидат конзистентни и сигурни.

За да се постигнат овие, поголемиот дел од верификациите треба да се направат како дел од развојот на нови карактеристики. Со други зборови, развојот и тестирањето треба да бидат кохерентна активност, а квалитетот треба да се „испече“ уште од самиот почеток со тоа што ќе се осигури дека она што се развива функционира и дека не ја нарушило постојната функционалност.

Ова бара „превртување на пирамидата за автоматизација на тестот“ со притискање на тестовите за GUI за кои треба да се изврши долго време, до пониски нивоа, на пр. API слој што може да работи директно по единичните тестови како дел од изградбата за да се обезбеди почетното ниво на доверба.

Поврзано:

• Како да изберете кои тестови да се автоматизираат?
• Каде да започнете тест-автоматизација за постоечка веб-страница?
• Дали тест-автоматизацијата треба да ја изврши одделен посветен тим?

Преглед на стратегијата за автоматизација на тестот

Превенција наместо откривање - иако сите напори треба да се потрошат на спречување на воведување на дефекти во апликацијата, техниките и методите за тоа се надвор од опсегот на овој пост. Тука, методологиите се дефинирани за да овозможат брзо откривање на грешките кога тие се воведени во системот и повратни информации за развојот.

Треба да се фаворизира квалитетот пред квантитетот. Во повеќето случаи, подобро е да се ослободи со една карактеристика која е цврста карпа, отколку со повеќе одлики кои се ронливи. Како минимален критериум за ослободување, секоја новоразвиена карактеристика не требаше да воведува дефекти на регресија.

Како што веќе споменавме, брзата повратна информација за здравјето на апликацијата е од огромно значење за поддршка на континуираната достава, затоа се формулира процес и механизам со кој можеме брзо да добиеме повратна информација.

Еден начин да добиете брзи повратни информации е со зголемување на бројот на тест единици, тестови за интеграција и тестови на API. Овие тестови на ниско ниво ќе обезбедат безбедносна мрежа за да се осигури дека кодот работи како што е предвидено и помага да се избегнат дефекти што ќе избегаат во другите слоеви на тестирање.

Единичките тестови ги формираат основите за автоматска тест на повисоки нивоа.

Вториот елемент на подобрување е почесто извршување на регресивни тестови и усогласен со процесот на континуирана интеграција, видете подоцна. Тестирањето за автоматизација не треба да се гледа како изолирана задача, туку повеќе како кохерентна активност вградена во SDLC.

Дефиниција на пакети за регресија

Тестовите за автоматска регресија се јадрото на Стратегијата за автоматизација на тестот.

Пакет за регресија на чад

Регресивните пакети служат како разумна проверка дали апликацијата може да се вчита и да се пристапи до неа. Исто така, треба да се извршат само неколку клучни сценарија за да се осигурате дека апликацијата е сè уште функционална.

Целта на пакетот за испитување на чад е да се фатат најочигледните проблеми, како што е апликацијата што не се вчитува, или заеднички проток на корисник не може да се изврши; од оваа причина, тестовите за чад не треба да траат подолго од 5 минути да се даде брз фидбек во случај нешто големо да не работи.

Пакетот за тест за чад работи на секое распоредување и може да биде мешавина од тестови за API и / или GUI.

Функционални пакети за регресија , Што треба да ја провери функционалноста на апликацијата подетално отколку тестот за чад.

Повеќе пакети за регресија ќе постојат за различни цели. Ако има повеќе тимови кои работат на различни делови од апликацијата, тогаш идеално би требало да има различни падови на регресија кои можат да бидат насочени кон областа на која работи тимот.

Овие пакети треба да можат да работат во која било околина, како и кога е потребно, под услов однесувањето на одликите да остане доследно на целата околина. Тие се извршуваат повеќе пати на ден и не треба да траат подолго од 15 до 30 минути.

Бидејќи овие функционални тестови се подетални, тогаш ќе биде потребно подолго време да се извршат, затоа е важно да имаме мнозинство на функционални тестови во API слојот каде тестовите можат да се извршат побрзо за да можеме да бидеме во рамките на 15 до 30 минути временски рок.

Пакет за регресија од крај до крај, што ја тестира целата апликација како целина. Целта на овие тестови е да се осигура дека различните делови од апликацијата што се поврзуваат со разни бази на податоци и апликации од трети страни работат правилно.

Тестовите од крај до крај немаат за цел да ги тестираат сите функционалности бидејќи тие се веќе тестирани во пакетите за функционална регресија, сепак, овие тестови се „мала тежина“ кои само ги проверуваат транзициите од една во друга состојба и неколку од најважните сценарија или патувања на корисниците.

Овие тестови главно се извршуваат преку GUI, бидејќи проверуваат како корисниците би го користеле системот. Времето потребно за извршување на овие може да варира од една до друга апликација, но тие обично се извршуваат еднаш на ден или ноќ.

Стратегија за автоматизација на тестот за повеќе агилни тимови

Тестови за автоматска единица

Тест-автоматизацијата започнува на ниво на единица. Тестовите за единици треба да бидат напишани од развивачите за секоја нова карактеристика што е развиена. Овие единици тестови ја формираат основата на поголема практика за автоматизација која се протега сè до тестовите за GUI на системот.

Одговорност на развивачите е да осигурат дека за секоја нова функција што е развиена, се напишани збир на кохерентни и солидни единици за да се докаже дека кодот работи како што е предвидено и ги исполнува барањата.

Единичките тестови обезбедуваат најголема рентабилност на тимот бидејќи се извршуваат многу брзо, лесни за одржување и модифицирање (бидејќи нема зависности) и кога има грешки во кодот, тој брзо се враќа на инвеститорот.

Тестовите за единици се извршуваат на машината на инвеститорот, како и на околината на КИ.

Тестови за автоматска интеграција / API или услуга

Додека единиците за тестирање се темелат на тестирање на функциите во рамките на една класа, тестовите за интеграција го формираат следното ниво од единиците за тестирање за да ги тестираат класи кои колективно ја сочинуваат компонентата за да обезбедат дел од функционалноста. Овие тестови се извршуваат само кога единиците тестови се извршени и положени.

Тестовите за услуги природно се извршуваат на API слој без интервенција на веб-интерфејсот GUI; па тестовите ќе можат да ја потврдат функционалноста во чиста форма и бидејќи тестовите зборуваат директно со компонентите, тие брзо се извршуваат и ќе бидат дел од изградбата.

Каде што е потребно, потсмевања како што се жичен мок ќе се користи за да се факторизира зависноста на другите 3^23-тапартиски системи и кога низводните системи не се достапни за да ги обезбедат податоците потребни за тестирање.

Тестовите за интеграција и / или тестовите за услуги може да се извршат и на машината на развивачот и да бидат дел од конструкцијата, но ако тие почнат да траат долго, тогаш најдобро е да се извршувате во околината на КИ.

Алатки како што е SoapUI може да се користат за тестови на услуги.

Тестирање на апликации

Типична апликација за е-трговија може да се подели на различни апликации или „апликации“ кои обезбедуваат различни функционалности. Концептот на „Тестирање апликации“ е таму каде што група тестови што ја тестираат функционалноста на една апликација се организираат заедно и се спротивставуваат на посакуваната апликација. Овој пакет ќе биде корисен во случаи кога тим сака да објави индивидуална апликација и би сакал да знае дали таа работи правилно.

Тестовите за апликација обично бараат интерфејс за да комуницираат со различните компоненти, затоа се очекува овие тестови да се извршуваат преку прелистувач на GUI.

Целта на тестирање апликации е да се осигура дека функциите на апликацијата се функционално точни. Бидејќи тестовите се организирани на начин да обезбедат доверба во здравјето на одредена апликација, овие тестови обично се нарекуваат Вертикални тестови, бидејќи тие извршуваат „долу“ на одредена апликација. Тестовите се многу темелни, а опфатот е голем.

Селен веб-возач може да се користи за извршување на овие автоматски тестови против прелистувачот. Оваа алатка е најпопуларна за тестовите за автоматизација на прелистувачот и обезбедува богат API што овозможува сложени верификации.

Тестови на сценарио од крај до крај

Автоматизираните тестови GUI кои се против системот, служат како типични кориснички текови, патувања или сценарија од крај до крај. Поради проблеми со овој вид тестови (дискутирани подолу), тие ќе бидат сведени на минимум. Сценаријата од крај до крај се вклучени во пакетот за ноќна регресија.

Превртување на пирамидата за автоматска тест

Како дел од Стратегијата за автоматизација на тестот, треба да осигуриме да го минимизираме бројот на автоматски тестови што се извршуваат на GUI слој.

Додека извршувате автоматски тестови преку GUI обезбедува добри и значајни тестови во однос на симулирање на интеракцијата на корисникот со апликацијата, тој е склон кон многу проблеми наведени подолу:

Кршливи

Бидејќи тестовите се потпираат на локаторите на HTML за да идентификуваат веб-елементи со кои треба да комуницирате, штом се смени идентификацијата, тестовите не успеваат, затоа тие носат многу трошоци за одржување.

Ограничено тестирање

GUI може да ја ограничи можноста на тестерот за целосна проверка на некоја карактеристика бидејќи GUI може да не ги содржи сите детали од веб-одговорот за да дозволи верификација.

Бавно

Бидејќи тестовите се извршуваат преку GUI, времето на вчитување на страницата може значително да го зголеми целокупното време на тестирање и како такво, повратните информации за развивачите се релативно бавни.

Најмалку рентабилност

Поради горенаведените проблеми, автоматските тестови со GUI обезбедуваат најмалку рентабилност.

Тестовите за автоматизација на прелистувачот ќе бидат сведени на минимум и ќе се користат за симулирање на однесувањето на корисникот, вклучително вообичаени кориснички текови и сценарија од крај до крај, каде што се спроведува системот како целина.