SOA test - Utmaningar

Speciellt att ta hänsyn till vid test av SOA är :

Systemet kommer att anropas av många olika system.

  • Detta innebär att bra prestanda är mycket viktigt. SOA lösningen blir central för många system och dålig prestanda och långa svarstider kommer att innebära problem för många andra system att skapa god kundnöjdhet.
  • Dessa system som anropar SOA lösningen kan vara byggda i många olika programmeringsspråk och vara av många olika typer: portalapplikatoner, BI system, affärssystem. För att de på ett enkelt sätt ska kunna bygga integrationer med SOA lönsingen måste den ha ett standardiserat gränssnitt.
  • Eftersom dessa system hela tiden kommer att vara beroende av SOA lösningen krävs det att den har bra driftsäkerhet.


Om något av de system som anropar SOA lösningen har höga krav på tex att datan alltid är helt korrekt så ärver SOA lösningen detta krav.

Det går alltså inte att bara hantera krav för SOA systemet för sig självt utan det krävs att krav för anropande system tas i beaktande.

 

SOA systemet i sig är beroende av andra system därifrån källdatan kommer.

Data kan exempelvis hämtas från en redan befintlig databas, från ekonomisystemet, från personalsystemet etc. Problem som dessa system har kommer att påverka driftsäkerheten i SOA systemet. Därför är det viktigt att det finns bra felhantering och larmsystem i SOA lösningen för att hantera olika sorters fel.


Det finns inget GUI utan all test kräver att man har verktyg att arbeta med.

Dessa verktyg kräver en bra kunskap hos testpersonalen samt en bra verktygsstrategi kring testarbetet. Man behöver från början fundera på hur verktyget kan stödja dig i de funktionella testerna, hur dessa script kan användas i tex regressionstest och prestandatest.


I tester av webservices så är det ofta väldigt många parametrar som man behöver kontrollera i testerna.

Ska en webtjänst returnera 30 utparametrar är det en utmaning att dels kontrollera att samtliga parametrar returneras. Dessutom ska det kontrolleras att värdena även är korrekta. Och det kan ofta vara en blandning av interna parametrar som ska användas av tex logiken av ett webbgränssnitt och av parametrar som ska visas för slutkonsumenten av tjänsten via tex ett webbgränssnittet.

 

Sammanbyggda eller atomiska webbtjänster

En dimension att se på webbtjänster är om de är sammanbyggda eller atomiska. Webtjänsterna kan vara atomiska, dvs i sig stå för hela logiken. Ett exempel kan vara att en intern databas kan anropas via en intern webbtjänst. Alternativet är sammanbyggda webbtjänster tex med hjälp av BPEL som kopplar ihop flera webbtjänster för att skapa den sammanbyggda tjänsten. En annan dimension är att organisatorisk - webtjänsterna kan vara tillhandahållna helt internt, dvs det är den egna organistaionen eller projektet som har full kontroll över webbtjänsten. Det kan också vara externa, dvs något annat företag tillhandahåller webbtjänsten som ditt projekt använder sig av för att skapa en sammanbyggd tjänst. . I det första fallet (intern webbtjänst) har den som testar full möjlighet att använda sig av webbtjänsten i sin testmiljö. I det andra fallet finns ofta problem med att ha tjänsten tillgänglig för tester.