Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

Innehållsförteckning

Funktionella tester

Beskrivning av de funktionella testerna och hur de kan köras:
I SoapUI-projektet finns det exempelrequest för Update, FindContent och
ProcessNotification. Förutom dessa request finns även tester som verifierar
majoriteten av de regler som finns beskrivna i tjänstekontraktet.

Status

De tester som ej är implementerade är sådant som rör huruvida notfieringar
skickas korrekt efter uppdateringar med Update och ProcessNotification.

Tillsvidare görs heller inga verfieringer att tester som förväntar sig
SoapFaults har korrekta felmeddelande. Anledningen till detta är att det finns ett fel som gör
att VP inte returnerar felmeddelandet hela vägen tillbaka till klienten.

Instruktioner gör att genomföra testerna

För att kunna köra både request och tester behöver man anpassa miljön för om man
ska köra testerna mot utvecklingsmiljön (MuleStudio) eller mot exempelvis
QA-miljön:

1. HSA-ID. I projektinställningarna ("Custom properties") finna möjligheten att
välja HSA_ID_QA och HSA_ID_DEV för inställningen HSA_ID.

2. Endpoints. För varje tjänst behöver man uppdatera vilken endpoints som ska
användas. I och med att testerna återanvänder alla tre tjänster behöver således
uppdatera endpointen för alla tre tjänster.

Exempel på metod för att välja QA som endpoint:

Dubbelklicka på UpdateResponderBinding, välj "Service Endpoints". Välj
"https://qa.esb.ntjp.sjunet.org:20000/vp/Update/1/rivtabp21" och tryck knappen
"Assign.". Välj alternativet "All requests och TestRequests" och tryck på ok.

Uppdatera detta för FindContentWSBeanServiceSoapBinding samt
ProcessNotificationResponderBinding.

Nu är det klart att köra testerna. Testerna kan köras en och en eller alla. För
att köra alla test, högerklicka på projektet -> Launch Testrunner. Välj "All" i
TestCase och TestSuite. Tryck sedan till sist på "Launch".

Övrigt

För att aktivera de inaktiverade antagandena för testning i exempelvis
utvecklingsmiljön behöver man göra följande för de testcase som innehåller
"incomplete" i testnamnet:

1. Öppna testcaset genom att dubbelklicka på det
2. Dubbelklicka på det relevanta teststeget. Detta är inte nödvändigtvis
självklart så man kan behöva kolla assertions för alla teststeg.
3. Högerklicka på den asseration som är inakiverat i asserationslistan.
4. Klicka på "Enable" för att aktivera.

Lasttester

Körning av de existerande lasttesterna

Alla lasttestfunktionalitet finns just nu i https://code.google.com/p/skltp/source/browse/tp/ei/trunk/modules/intsvc/

SoapUI

Jag har skapat ett version av soapui-projektet där jag lagt tester för Update
och FindContent.

Projektet heter SKLTP-EI-loadtests-soapui-project.xml
Detta gör det rimligt enkelt att köra enskilda lasttester inifrån SoapUI. De
testr som finns är:

Update med 1, 10, 100, 1000 engangemang
FindContent med 2 eller alla element.

För att testa med olika anrop med sekund är man tvungen att köra med olika
samtidiga klienter (trådar). För att få detta någotlunda enkelt så jag har varit tvungen att skapa fasta
alternativ av antalet trådar. (Det finns en lösning runt detta när man kör från terminalen men jag har inte hunnit skapa detta.)

Det är viktigt att ställa in rätt endpoints för varje tjänst om testerna inte
ska köra mot qa1. Detta görs på följande sätt:

Dubbelklicka på UpdateResponderBinding, välj 'Service Endpoints'. Välj
exempelvis 'https://qa.esb.ntjp.sjunet.org:20000/vp/Update/1/rivtabp21' och tryck knappen 'Assign'.
Välj alternativet 'All requests och TestRequests' och tryck på ok.

Uppdatera detta för FindContentWSBeanServiceSoapBinding samt
ProcessNotificationResponderBinding.

Köra lasttester i SoapUI.

För att köra ett simpelt test i klicka TestCaset och sedan Loadtests.
Dubbellklicka för att få fram ett fönster där högerpilen finns längst upp på
fönstret.

Som resultat ser man antal test per sekund, genomsnittlig svarstid o.s.v.

Köra lasttester i SoapUI från terminalen

För att köra lasttesterna från SoapUI behöver följande göras

  • Hämta skript och installera soapUI samt Ruby om maskinen inte kör på osx
  • Gå in i katalogen loadtest_runner och öppna filen run.sh. Sätt variablerna soapUIpath (sökväg till soapui-katalogen)
    samt remote_host som är adressen som cpu-monitoreringen körs mot. För att kunna köra ssh-monitorering
    krävs antingen extisterande sshanslutningen ControlMaster eller att anslutningen använder nycklar.
    För att verifiera att det fungerar, skriv ssh ADDRESS_TILL_REMOTE_HOST i terminalen och verifiera att
    det går att logga in utan att ange lösenord.
  • Kör ./run.sh från terminalen. Tar idag cirka 60 minuter att slutföra

Resultat från skriptet

Från skriptet kommer man se statistik kring svarstider för de olika testerna,
antal tester per sekund samt last och cpuinfo.

JMeter

Då SoapUI inte verkar kunna hantera keep-alive syns ingen märkbar skillnad i
svarstiderna när keep-alive är på och när det är avstängt. Har därför porterat
några av lasttesterna till JMeter för där på ett korrekt sätt kunna göra tester
med keep-alive.

Köra lasttester med JMeter

  • Öppna SKLTP-EI-loadtests-jmeter.jmx med JMeter
  • I menyn, välj SSL-manager ange certifikatet som ska användas. (Jag har använt
    tk_qa_auth.p12)
  • Aktivera den eller de threadgroups som ska köras och tryck sedan på kör.
  • Resultatet visas som helhelt för den aktuella trådgruppen samt för varje
    soaprequest i trådgruppen.

Tänk på att de olika trådgrupperna har olika inställningar för antal
samtidiga klienter och körlängder. Detta ställs in i trådgruppsinställningarna
(klicka på den valfri Thread Group).

 

 

 

 

 

 

På denna sidan finns instruktioner för hur EI ska testas . Testrapporter från EI tester hittar ni här. <LÄNK>

Funktionella tester

Beskrivning av de funktionella testerna och hur de kan köras:
I SoapUI-projektet finns det exempelrequest för Update, FindContent och
ProcessNotification. Förutom dessa request finns även tester som verifierar
majoriteten av de regler som finns beskrivna i tjänstekontraktet.

Status

Testbeskrivning

Syftet med de funktionella testerna är att verifiera reglerna i tjänstekontraktet. I SAD:en beskrivs de tester som måste har implementerats för att verifiera reglerna i Engagemangsindex.

Utöver dessa tester finns <VAD FINNS MER?>

Begränsningar

De tester som ej är implementerade är sådant som rör huruvida notfieringar
skickas korrekt efter uppdateringar med Update och ProcessNotification.  Varför ej? tidsbrist eller anses ej nödvändigt?

Tillsvidare görs heller inga verfieringer att tester som förväntar sig
SoapFaults har korrekta felmeddelande. Anledningen till detta är att det finns ett fel som gör
att VP inte returnerar felmeddelandet hela vägen tillbaka till klienten. Bör vi göra detta? Detta fel är väl åtgärdat nu?

Instruktioner gör att genomföra testerna

Förberedelser

För att kunna köra både request och tester behöver man anpassa miljön för om man
ska köra testerna mot utvecklingsmiljön (MuleStudio) eller mot exempelvis
QA-miljön:

1. HSA-ID. I projektinställningarna ("Custom properties") finna möjligheten att 
välja HSA_ID_QA och HSA_ID_DEV för inställningen HSA_ID.

2. Endpoints. För varje tjänst behöver man uppdatera vilken endpoints som ska
användas. I och med att testerna återanvänder alla tre tjänster behöver således
uppdatera endpointen för alla tre tjänster.

Exempel på metod för att välja QA som endpoint:

Dubbelklicka på UpdateResponderBinding, välj "Service Endpoints". Välj
"https://qa.esb.ntjp.sjunet.org:20000/vp/Update/1/rivtabp21" och tryck knappen
"Assign.". Välj alternativet "All requests och TestRequests" och tryck på ok.

Uppdatera detta för FindContentWSBeanServiceSoapBinding samt
ProcessNotificationResponderBinding.

Köra tester

Nu är det klart att köra testerna. Testerna kan köras en och en eller alla. För
att köra alla test, högerklicka på projektet -> Launch Testrunner. Välj "All" i
TestCase och TestSuite. Tryck sedan till sist på "Launch". Är det uppenbart var de finns? Antar det?

Dokumentation av tester

Det ska dokumenteras att testerna utförts samt på vilken mjukvaruversion man kört dem. Fyll i denna tabellen och spara den under "EI Testrapporter" <LÄNK>

DatumEI versionVP versionTester utförda avResultat
     
Kommentar:<eventuellt någon kommentar om resultatet>

Övrigt

För att aktivera de inaktiverade antagandena för testning i exempelvis   Vad menas med det?
utvecklingsmiljön behöver man göra följande för de testcase som innehåller
"incomplete" i testnamnet:

1. Öppna testcaset genom att dubbelklicka på det
2. Dubbelklicka på det relevanta teststeget. Detta är inte nödvändigtvis
självklart så man kan behöva kolla assertions för alla teststeg.
3. Högerklicka på den asseration som är inakiverat i asserationslistan.
4. Klicka på "Enable" för att aktivera.

Lasttester

Körning av de existerande lasttesterna

 

Testbeskrivning

Syftet med lasttesterna är att belasta systemet för att verifiera xxxx

SoapUI

Jag har skapat ett version av soapui-projektet där jag lagt tester för Update
och FindContent.

Det finns ett projektet som heter SKLTP-EI-loadtests-soapui-project.xml med tester för Update och Find Content.
Detta gör det rimligt enkelt att köra enskilda lasttester inifrån SoapUI. De
tester som finns är:

  • Update med 1, 10, 100, 1000 engangemang
  • FindContent med 2 eller alla element.

För att testa med olika anrop med sekund är man tvungen att köra med olika flera? samtidiga klienter (trådar). För att få detta någotlunda enkelt så jag har varit tvungen att skapa Det finns fasta

alternativ av antalet trådar. (Det finns en lösning runt detta när man kör från terminalen men jag har inte hunnit skapa detta.)

Förberedelser

Det är viktigt att ställa in rätt endpoints för varje tjänst om testerna inte
ska köra mot qa1. Detta görs på följande sätt:

Menar du detta?

 

Testerna är förkonfigurerade att köra mot QA1. Om man ska köra mot någon annan nod måste man ställa in rätt endpoints för varje tjänst.  Detta görs på följande sätt:

 

Dubbelklicka på UpdateResponderBinding, välj 'Service Endpoints'. Välj
exempelvis 'https://qa.esb.ntjp.sjunet.org:20000/vp/Update/1/rivtabp21' och tryck knappen 'Assign'. 
Välj alternativet 'All requests och TestRequests' och tryck på ok.

Uppdatera detta för FindContentWSBeanServiceSoapBinding samt
ProcessNotificationResponderBinding.

Köra tester

Alla lasttestfunktionalitet finns just nu i https://code.google.com/p/skltp/source/browse/tp/ei/trunk/modules/intsvc/

Köra lasttester i SoapUI.

För att köra ett simpelt test i klicka TestCaset och sedan Loadtests.
Dubbellklicka för att få fram ett fönster där högerpilen finns längst upp på
fönstret.

Som resultat ser man antal test per sekund, genomsnittlig svarstid o.s.v.

Köra lasttester i SoapUI från terminalen

För att köra lasttesterna från SoapUI behöver följande göras

  • Hämta skript och installera soapUI samt Ruby om maskinen inte kör på osx
  • Gå in i katalogen loadtest_runner och öppna filen run.sh. Sätt variablerna soapUIpath (sökväg till soapui-katalogen) 
    samt remote_host som är adressen som cpu-monitoreringen körs mot. För att kunna köra ssh-monitorering 
    krävs antingen extisterande sshanslutningen ControlMaster eller att anslutningen använder nycklar. 
    För att verifiera att det fungerar, skriv ssh ADDRESS_TILL_REMOTE_HOST i terminalen och verifiera att 
    det går att logga in utan att ange lösenord.
  • Kör ./run.sh från terminalen. Tar idag cirka 60 minuter att slutföra

Resultat från skriptet

Från skriptet kommer man se statistik kring svarstider för de olika testerna,
antal tester per sekund samt last och cpuinfo.

JMeter

Då SoapUI inte verkar kunna hantera keep-alive syns ingen märkbar skillnad i
svarstiderna när keep-alive är på och när det är avstängt. Har därför porterat
några av lasttesterna till JMeter för där på ett korrekt sätt kunna göra tester
med keep-alive.

Köra lasttester med JMeter

  • Öppna SKLTP-EI-loadtests-jmeter.jmx med JMeter
  • I menyn, välj SSL-manager ange certifikatet som ska användas. (Jag har använt
    tk_qa_auth.p12)
  • Aktivera den eller de threadgroups som ska köras och tryck sedan på kör.
  • Resultatet visas som helhelt för den aktuella trådgruppen samt för varje
    soaprequest i trådgruppen.

Tänk på att de olika trådgrupperna har olika inställningar för antal 
samtidiga klienter och körlängder. Detta ställs in i trådgruppsinställningarna
(klicka på den valfri Thread Group).

Testdokumentation

 Testrapport ska fyllas i och sparas bland testrapporter för Engagemangsindexefter deploy i QA miljö. Utöver dessa tester utförs automatiserade tester då EI byggs. Dessa finns på sidan EI - Översikt automatiserade tester.

Tre typer av tester är utförda och instruktioner för hur man testerna utförs hittas under respektive länk:

Testrapporter från EI tester hittar ni här.