Een eenvoudige aanpak om storingen in testautomatisering op te lossen

Het was 8 uur ’s ochtends tijdens een van de kritieke release-regressietijden, onze SDET kwam naar kantoor en ontdekte dat 60% van zijn tests mislukte vanwege wijzigingen in de gebruikersinterface (element-ID’s gewijzigd, nieuwe elementen geïntroduceerd, elementen verwijderd enz.). Het is een suite van ongeveer 2000 tests, kunnen we al deze 1200 mislukte tests in de komende uren analyseren en de redenen vinden? Hoe gemakkelijk is het om ze te repareren? Moeten we ze echt repareren? Kan wat astrologie helpen?

Toen kwam het idee om een Application Change Identifier en Application Change Predictor te bouwen

Identificatie en voorspeller van toepassingswijziging

Identificatie en voorspeller van toepassingswijziging

Een Page Depot is waar de elementen op pagina’s in de applicatie worden opgeslagen op een kaart met hun locatieparameters zoals ID, naam, xpath, ook hun toegankelijkheidsparameters zoals zichtbaar, ingeschakeld enz. Elke keer dat de uitvoering wordt uitgevoerd, wordt het opgeslagen paginadepot vergeleken met het nieuw gegenereerde depot (Objecten op de pagina) en wordt het oudere vervangen door nieuw. Dit helpt bij het identificeren van fouten in de testautomatisering als gevolg van wijzigingen in de gebruikersinterface, wijzigingen in de locator, enz.

Application Change Predictor loopt door de laatste Verscheidene Commits in de SCM en identificeert de betrokken modules/pagina’s. Kiest de tests die overeenkomen met deze pagina’s en voert de wijzigings-ID van de toepassing uit.

Blijf op de hoogte voor onze code op GitHub

Wil je met ons samenwerken? Schrijf naar sales@zucisystems.com

Benodigde vaardigheden: Selenium, Core Java, out-of-box denken