Тествайте стратегия за автоматизация за гъвкави проекти
Какво пишат в блоговете
Буболечки и дупки
• Визуални илюстрации на възможни сценарии с програмен код.
Прост масив
Онлайн обучения
Присъствени обучения
Конференции
Какво пишат в блоговете (EN)
Раздели на портала
Относно инструментите
Най-добри работни места
Използването на автоматизирано тестване предоставя големи възможности и може значително да повиши надеждността на кода и сигурността на приложението. Следователно, разработването на големи и сложни системи със сигурност ще изисква участието на специалисти в областта на автоматизираното тестване. От друга страна, автоматизираното тестване е доста сложен процес както от гледна точка на писане на код, така и от гледна точка на методология и организация на процесите в екип. Предлагаме на вашето внимание превода на статия за изграждането на автоматизирано тестване на Agile проекти.
Стратегията за автоматизиране на тестовете, описана в тази статия, предполага модел на непрекъснато доставяне с множество Agile екипи.
В този пример ще изброя ключовите точки, които трябва да имате предвид, за да извлечете максимума от провеждането на автоматизирани тестове.
Автоматизираното тестване е ключов процес на разработка, използващ методологията Agile. С преминаването към непрекъснато разгръщане автоматизацията на тестовете става още по-важна поради способността бързо да информира разработчиците за състоянието на приложението. За да се осигури постоянен поток от обратна връзка, автоматизираните тестове трябва да се провеждат непрекъснато ибързо, а резултатите им трябва да са надеждни и достоверни.
За да се гарантира, че тези условия са изпълнени, повечето от тестовете трябва да се извършват като част от разработването на нова функционалност. С други думи, разработката и тестването трябва да са неразривно свързани и осигуряването на качеството трябва да бъде вградено от самото начало на разработката, така че новите функции да не нарушават съществуващата функционалност.
Това изисква „обръщане на пирамидата за автоматизация на тестовете“ от GUI тестове, които отнемат много време за тестване на по-ниски нива, като например API, където автоматизираните тестове могат да се изпълняват веднага след единични тестове като част от компилация, за да осигурят базова линия на надеждност.
Общ преглед на стратегията за автоматизация на тестовете
Превенция вместо откриване – Разбира се, трябва да се положат всички усилия, за да се предотврати появата на дефекти, но техниките и методите, които се използват за това, не са предмет на тази статия. Тук се интересуваме от това как можем да открием грешки веднага щом се появят в системата и незабавно да прехвърлим информация на разработчиците.
Качеството трябва да е над количеството. В по-голямата част от случаите е по-добре да се пусне една функция, надеждна като камък, вместо няколко полуизпечени функции наведнъж. Минималният критерий за издание трябва да бъде пълната липса на регресионни дефекти, тоест новите функции не трябва да нарушават работата на съществуващата функционалност.
Както споменахме, информирането на разработчиците за състоянието на дадено приложение е от съществено значение за непрекъснатата доставка, така че трябва да се намери механизъм, който да позволява бърза обратна връзка. Един от начините е да се увеличи броят на единиците тестове,интеграционни тестове и API тестове. Тези тестове на ниско ниво формират предпазна мрежа, която помага да се гарантира, че приложението работи по предназначение и помага за предотвратяване на възникването на дефекти на други нива на тестване. Единичните тестове служат като основа за тестване на автоматизация на по-високи нива.
Втората възможност за подобряване на производителността е да се изпълняват регресионни тестове по-често и успоредно с непрекъсната доставка, повече за това по-късно.Автоматизираното тестване не трябва да бъде изолирана задача, а постоянен процес, който е неразделна част от жизнения цикъл на софтуера.
Регресионно тестване
Автоматизираните регресионни тестове са гръбнакът на стратегията за автоматизиране на тестовете.
Пакетът за регресионен тест "дим"е необходим, за да се провери дали приложението се зарежда и работи. Той също така включва няколко ключови скрипта, за да се гарантира, че приложението все още работи.
Целта на този тестов пакет е да улови най-очевидните проблеми, като например незареждане на приложението или основния поток на взаимодействие на потребителя с приложението. Следователно димните тестове не трябва да продължават повече от5 минути, тяхната цел е да докладват, че нещо ключово не работи.
Тези тестове се изпълняват при всяко внедряване на приложението и могат да съдържат както API, така и GUI тестове.
Необходим е функционален регресионен тестов пакетза проверка на производителността на приложението по-подробно, отколкото позволяват димните тестове.
Необходимо е да се създадат няколко функционални пакета за различни цели. Ако има няколко екипа, работещи върху различни раздели на приложението, тогава в идеалния случай се нуждаете от пакети за регресия, които покриват обхвата на работата на всеки екип.
Тезипакетите трябва да се изпълняват в различни среди според нуждите и да гарантират, че поведението на приложението остава същото независимо от средата. Такива тестове се правят няколко пъти на ден и не трябва да продължават повече от 15-30 минути.
Тъй като тези тестове са по-подробни и отнемат повече време, важно е да преместите повечето от функционалните тестове в API слоя, където тестването е по-бързо. Това е необходимо, за да не се надхвърли времевата рамка от15-30 минути.
Пълният набор от регресионни тестовеви позволява да тествате приложението си като цяло. Целта на този тестов пакет е да провери дали различните части на приложението, които имат достъп до различни бази данни и други приложения, работят правилно.
Този пакет от тестове не е предназначен да тества всички функции на приложението, тъй като те вече са тествани от пакети за функционална регресия. Във всеки случай тези тестове са по-„лесни“ и проверяват преходите от едно състояние към друго или няколко от най-популярните сценарии или потребителски пътища.
Такива тестове се провеждат най-вече с помощта на GUI, тъй като тестват как потребителят ще взаимодейства със системата. Времето, необходимо за изпълнението им, може да варира в зависимост от приложението, но тези тестове обикновено се изпълняват веднъж на ден или нощ.
Тествайте стратегия за автоматизация за множество гъвкави екипи
Автоматизирани единични тестове
Автоматизацията на тестовете започва на ниво тест на единица. Тези тестове трябва да се създават за всяка нова функция в разработка. Те формират основата на по-широка практика за автоматизация до системни GUI тестове. Разработчиците трябва да гарантират, че за всекинова функционалност, разработен е пълен набор от надеждни модулни тестове, за да се провери дали кодът работи по предназначение и отговаря на всички изисквания. Единичните тестове са най-печеливши по отношение на ROI, защото са кратки за писане, лесни за поддръжка и промяна (поради факта, че няма зависимости), така че ако има грешка в кода, тогава разработчикът бързо научава за това. Единичните тестове трябва да се изпълняват както на машината на разработчика, така и в непрекъсната интеграционна среда.
Автоматична интеграция / API тестове или сервизни тестове
Докато модулните тестове се основават на тестване на функционалността в рамките на клас, интеграционните тестове формират следващата стъпка към тестване на класовете, които съставляват компонента, който е част от новата функционалност. Такива тестове се провеждат само след успешно завършване на теста на модула.
Тестовете на услугата обикновено се изпълняват на ниво API, без да се включва GUI, така че тестовете са предназначени да тестват чиста функционалност и тъй като тестовете имат директен достъп до компонентите, те се изпълняват бързо и могат да бъдат част от компилацията. Ако трябва да тествате взаимодействие с външни услуги, ако външни услуги не са налични или не могат да гарантират предоставянето на данни, които отговарят на условията за тестване, можете да използвате емулатори на външни услуги, като WireMock. Тестовете на API и/или сервизните тестове могат да се изпълняват на машината на разработчика или като част от компилация, но ако започнат да отнемат много време, най-добре е да се изпълняват в непрекъсната интеграционна среда. За тестове на услуги можете да използвате инструменти като SoapUI.
Тестове за приложение
На практика голямо приложение, като например система за електронна търговия, може да бъде счупенов няколко приложения, предоставящи различни възможности. Концепцията за "тестване на приложение" е, че групи от тестове, които разглеждат възможностите на едно приложение, се комбинират и изпълняват за това приложение. Този пакет може да се използва, когато екип планира да пусне персонализирано приложение и иска да провери дали всичко работи правилно.
За да тествате приложение като цяло, обикновено се нуждаете от интерфейс за взаимодействие между различните му компоненти, което означава, че тестването се извършва най-добре с помощта на браузър или GUI. Целта на тези тестове е да се уверят, че приложението работи правилно. Такива тестове се наричат "вертикални", защото те са насочени към проверка на здравето на конкретно приложение или компонент, а не на цялата система. Тези тестове се отличават с дълбочина на изследване и голям обем.
Selenium WebDriver може да се използва за изпълнение на такива тестове в браузъра. Този инструмент е най-популярният за автоматизирано тестване в браузъри и предоставя богат API за комплексни проверки.
Пълни тестове на сценария
Автоматизирани GUI тестове, които се изпълняват в цялата система, се използват като типични потребителски пътища или пълни сценарии за взаимодействие. Поради проблемите с този тип тестове (описани по-долу), най-добре е броят на тестовете да бъде сведен до минимум. Пълните сценарии са включени в пакетите за нощна регресия.
Обръщане на пирамидата за автоматизация на тестовете
Като част от стратегията за автоматизация на тестовете трябва да минимизираме броя на автоматизираните тестове на ниво GUI.
Въпреки че автоматизираното GUI тестване осигурява добри и значими резултати по отношение насимулация на взаимодействие на потребителя с приложението, има и редица недостатъци:
- Нестабилност —Тестовете използват html локатори, за да определят с кои уеб елементи да взаимодействат, така че щом уникалният идентификатор на който и да е интерфейсен елемент се промени, тестовете спират да работят и това води до значителни разходи за поддръжка.
- Ограничено тестване —GUI може да не позволи на тестера да тества напълно функционалността, защото не винаги съдържа всички подробности за уеб отговора, необходими за проверка.
- Бавна скорост —Тъй като тестовете се провеждат през GUI, времето за зареждане на страницата значително увеличава общото време за тестване, а обратната връзка с разработчиците е много по-късно.
- Най-малко ROI —Всички изброени по-горе проблеми правят GUI тестовете най-малко финансово жизнеспособни.
Автоматичното тестване в браузъра трябва да бъде сведено до минимум и да се използва за симулиране на потребителско поведение в основните потоци на взаимодействие и пълните сценарии, при които се използва системата като цяло.