Door SUPERP

Testautomatisering van de SAP WebUI & Selenium Webdriver

Regelmatig komen vragen bij klanten naar voren of het mogelijk is om de SAP WebUI schermen te automatiseren voor testdoeleinden. Vaak eindigt dit vraagstuk in de ‘door de markt bewezen’ licentie gebaseerde tools. Echter in de webwereld wordt voor front end automatisering veelal gebruikt gemaakt van open source tools. Een van de meeste gebruikte tools hiervoor is de Selenium Webdriver. Echter binnen de SAP-wereld is dit nog onontgonnen terrein. De SAP WebUI oogt als een reguliere webpagina… De vraag is dus of dit een goede match is of niet?

 

In deze blog wordt een uiteenzetting gegeven van de mogelijkheden en de moeilijkheden van het automatiseren van de ‘front end’ van de SAP WebUI met behulp van Selenium Webdriver.

 

Uitgangspunten Selenium Webdriver

Voor een succesvolle implementatie van Selenium Webdriver is het relevant dat er een scheiding wordt gemaakt tussen de pagina’s en de geschreven testen. Een goede manier om dit te bereiken is het toepassen van het Page Object Model.

 

Een tweede succesfactor is de “Selector Strategy” voor het identificeren van de web elementen op de pagina. Voor de eenduidigheid, flexibiliteit en betrouwbaarheid is gekozen om de web-elementen aan te roepen middels xpath-expressies.

 

Aandachtspunten automatiseren SAP WebUI-schermen

Gedurende het automatiseren van de SAP WebUI zijn er drie opvallende kenmerken van de SAP WebUI te onderscheiden:

 

     1. Frames op de webpagina;

     2.Laadschermen

     3.Dynamische elementen & attributen

 

Dit maakt het automatiseren niet onmogelijk, maar er moet wel rekening mee worden gehouden bij het opbouwen van de Page Object Models en het benaderen van elementen.

 

Omgaan met de frames van de WebUI-schermen

Door het gebruik van frames wordt de lay-out van de SAP WebUI opgebouwd. Hierdoor kan het voorkomen dat een “selector strategy” waarmee een specifiek element wordt gevonden, op meerdere plekken in de pagina voorkomt. Selenium zoekt daarbij in eerste instantie alleen in de webpagina en niet de frames. Daarom is het van belang om te analyseren of een element in een frame van de SAP WebUI zit. Om elementen in frames te benaderen moeten deze eerst worden geopend. Uit analyse is gebleken dat bijna alle belangrijke elementen van de SAP WebUI binnen een dergelijk frame zitten, dus het is belangrijk om hier op een correcte manier mee om te gaan. Hiervoor moet de hiërarchie van het element en de bijhorende frames goed doorgrond worden.

 

In het volgende voorbeeld wordt uitgelegd op welke wijze dit gedaan kan worden.  Als er gebruik wordt gemaakt van de “element inspector” van Google Chrome (f12) is hiërarchie te zien. Dit betreft de hiërarchie van het zoekveld in de SAP CRM Webui om een account te zoeken.

 

In de frame zitten de belangrijke elementen voor het testen van de SAP WebUI. Voor de beheerbaarheid en overzichtelijkheid van de code is het daarom aan te raden een functie te schrijven voor het openen van deze frames. Een andere tip is om het diepste frame (WorkAreaFrame1) in een losse functie te verwerken. De reden hiervan is dat verschillende menubalken en andere elementen zich in een andere frame bevinden.

De volgende methodes voor het openen van de frames kunnen worden gebruikt:

 

protected void openSapUIFrames() {

       driver.switchTo().defaultContent();

       driver.switchTo().frame(By.xpath("//iframe[@id=\"CRMApplicationFrame\"]"));

       driver.switchTo().frame(By.xpath("//iframe[contains(@id, \"ZIC_AGENT\")]"));

       driver.switchTo().frame(By.xpath("//iframe[@id=\"CRMApplicationFrame\"]"));

       driver.switchTo().frame(By.xpath("//iframe[@id=\"FRAME_APPLICATION\"]"));

}

 

protected void openWorkareaFrame() {

       openSapUIFrames();

       driver.switchTo().frame(By.xpath("//frame[@id=\"WorkAreaFrame1\"]"));

}

 

Na het openen van de frames kunnen de elementen worden aangeroepen met behulp van de reguliere Selenium Webdriver API.

 

Hoe om te gaan met laadschermen

Gedurende het navigeren door de SAP WebUI zijn er veel laadschermen actief. Deze schermen zijn geen onderdeel van standaard HTML, maar worden toegevoegd via JavaScript. De achterliggende reden waarom deze schermen actief zijn, is om een fraaier uiterlijk van de SAP WebUI te realiseren. Het probleem waar je gedurende het automatiseringstraject tegenaan loopt is dat Selenium geen onderscheid kan maken tussen een dergelijke laadscherm en een volledig geladen pagina. Tijdens deze laadschermen zet de WebUI een zogenaamd “freezeShield” voor de volledige pagina die het benaderen van elementen tegen gaat. Het gevolg is dat wanneer we een specifiek element willen aanroepen de actie in dit “freezeShield’ kan belanden met een Selenium exceptie als gevolg. Daarom moet bij het automatiseren een controle worden geïmplementeerd die verifieert of er geen “freezeShield” meer actief is op de pagina. Als oplossing kan de volgende time-out worden ingebouwd:

 

(new WebDriverWait(driver, 15)).until(new ExpectedCondition<Boolean>() {

public Boolean apply(WebDriver d) {

try{

WebElement freezeShield = driver.findElement(By.xpath("//div[@id=\"th_freezeShield\"]"));

return !freezeShield.isDisplayed();

} catch (NoSuchElementException e){}

return true;

}

});

 

Hoe om te gaan met dynamische attributen van elementen

Een ander punt om rekening mee te houden bij het automatiseren van de SAP WebUI zijn de dynamische attributen van elementen op de pagina. Dit zijn attributen van elementen die dus niet statisch zijn, maar steeds een ander vorm aannemen. Deze attributen kunnen bijvoorbeeld wijzigen bij het verversen van een webpagina, het opnieuw inloggen van een gebruiker, na het aanpassen van de applicatie, etc.

Het is soms lastig vast te stellen of een attribuut dynamisch is. Vaak valt dit op door steeds falende testen. Echter, onder het motto “voorkomen is beter dan genezen” vallen er al heel wat maatregelen te nemen om direct te constateren of een element dynamische attributen heeft. De meest effectieve manier is om bij ieder attribuut dat wordt meegenomen het volgende af te vragen: “zou dit door een programmeur zijn bedacht of door een computer zijn gegenereerd”. Engelse woorden zoals “CRMApplicationFrame” en “FRAME_APPLICATION” zijn duidelijk door een mens bedacht en dus niet dynamisch. Binnen de SAP WebUI blijken heel veel dynamische attributen te bestaan, die voor een gedeelte “statisch” zijn. Het is daarom van belang om hier gebruik van te maken bij de Selector Strategy. Door gebruik te maken van de juiste x-path expressies kunnen de meeste velden op een solide manier geïdentificeerd worden.

 

Dit is zo ook het geval bij het deel “ZIC_AGENT” van de frame die wel een dynamisch onderdeel bevat. Echter, het deel van dit id die volgt op “ZIC_AGENT” ziet er wel uit alsof het is gegenereerd (het zijn namelijk willekeurige getallen en letters). Door in ons x-path “contains(@id, “ZIC_AGENT”)” op te nemen voorkomen we het gebruik van een dynamisch deel van dit id.

 

webui

In de afbeelding hierboven is de weergave te zien die in de Google Chrome Developer Tools te zien is wanneer een invoervak in de WebUI wordt gekozen (dit is het vak voor het invoeren van de naam van een contactpersoon). Om deze te benaderen kan het “id” attribuut van dit element bij voorkeur worden gebruikt. Bij het in de afbeelding weergegeven element is dit het volgende:

 

C3_W18_V19_V21_searchcontact_struct.mc_name2

 

Bijna ieder element in de WebUI heeft dezelfde opbouw: een aantal letter-getal combinaties gevolgd door een leesbare naam. Deze letter-getal combinaties vormen dan ook het dynamische deel van dit “id”. Er moet daarom gecontroleerd worden of het “id” het deel “searchcontact_struct.mc_name2” bevat, gezien dat het leesbare gedeelte is. Hierdoor kan het volgende x-path worden opgesteld:

 

driver.findElement(By.xpath("//input[contains(@id, \"searchcontact_struct.mc_name2\")]");

 

Conclusie

De SAP WebUI is geen eenvoudige website voor testautomatisering. De hoofdreden is de complexe en gesloten structuur van de SAP WebUI pagina zelf. De moeilijkheden die worden ervaren met Selenium Webdriver, bestaan ook bij de andere oplossingen met betrekking tot testautomatisering (betaalde varianten). Gelukkig biedt Selenium enorm veel vrijheid en handvatten om deze problemen op te lossen.

De uitdagingen van de SAP WebUI zijn:


     - Gebruik van frames;
     - Gebruik van laadpagina’s (het “freezeShield”);
     - Gebruik van dynamische attributen van elementen.

 

Echter door een goede analyse en implementatie van het Page Object Model door de Test Consultant zijn deze uitdagingen te overwinnen.  

De in deze blog toegelichte oplossingen zijn:


     - Een methode in de test voor het openen van de frames;
     - Een methode in het Page Object Model voor de “freezeShield”;
     - Juiste toepassing van de xpath-selector strategy voor de (half) dynamische attributen.

 

Indien bovenstaande oplossingen op een juiste manier worden geïmplementeerd is de SAP WebUI een webpagina als alle anderen en prima te automatiseren met Selenium Webdriver.

Top