Detta dokument beskriver testsviten för GetCareServices 2.0. Testsviten innehåller ett antal testfall som kan användas för att verifiera implementationen innan integrationen med den nationella tjänsteplattformen.
Testsviten använder SoapUI för att verifiera implementationen. Dokumentation om SoapUI hittas här: www.soapui.org.
Klicka på den här länken för att ladda hem en gratisversion av SoapUI. Installera enligt anvisning.
Innan man kör testfallen i SoapUI så måste den data som skickas med i anropen anpassas utifrån det system som man vill testa. Detta görs genom att ändra i filen data.xml enligt nedan.
Filen är i XML-format och i början finns en sektion som heter "globaldata". Här anger man den konfiguration som kommer att användas av alla testfall.
Varje element i "globaldata" kan omdefinieras för ett specifikt testfall vid behov. Följande element är globala:
De parametrar man anger för ett specifikt testfall kompletterar och/eller omdefinierar de parametrar som anges i "globaldata".
Det betyder att både parametrar från "globaldata" och det specifika testfallets sektion i filen används för det aktuella testfallet.
OBS! Om en parameter med samma namn definieras både i "globaldata" och specifikt för testfallet, så kommer värdet från testfalls-sektionen att användas.
Ett exempel kan vara "patientId". Denna definieras i "globaldata", eftersom det är troligt att det mesta av testdatan kommer att röra samma patient.
Men för vissa testfall vill man kunna använda en annan patient och för dessa testfall definierar man detta genom att ta bort kommentars-markeringen runt parametern "patientId" i testfallets sektion.
Glöm inte att spara data.xml efter att du har ändrat i den.
Filtrering. Verifierar att resultatet endast innehåller poster för given patient.
Filtrering. Testfall för filtrering på samordningsnummer. Ersätt patientId med det samordningsnummer som du vill filtrera på.
Testfalls-specifika parametrarFiltrering. Testfall för filtrering på reservnummer. Ersätt patientId med det reservnummer som du vill filtrera på och ersätt patientIdType med lokalt definierat OID för reservnummer.
Testfalls-specifika parametrar
För bra testning på dessa punkter är en varierad testdata avseende tidpunker viktig.
Om möjligt bör vårdtjänster med följande egenskaper vara registrerade:
Filtrering. Verifierar att resultatet endast innehåller poster för given vårdenhet.
Testfalls-specifika parametrarFiltrering. Verifierar att resultatet endast innehåller poster för givet källsystem.
Filtrering. Verifierar att resultatet endast innehåller poster för given vårdkontakt.
careContactId är vårdkontaktens unika id.
Filtrering. Verifierar att tjänsteproducenten kan filtrera resultatet baserat på HTTP-headern x-rivta-original-serviceconsumer-hsaid.
Undersök och jämför det ofiltrerade svaret från producenten med det senare svaret vars begäran använt ett tjänstekonsumentHSAId på vilket producenten utför filtrering,
parametern filterString skall då inte finnas i det filtrerade svaret. Testfallet är ej applicerbart för system som inte implementerat denna typ av filtrering.
Verifierar att resultatet är ett SOAP Exception. Detta testfall kräver att tjänsteproducenten skapar förutsättningar för ett internt fel att uppstå.
Exempel kan vara att man stänger av kopplingen mot databas.
Verifierar att
Verifierar att responsen innehåller en sträng med specialtecken.
Denna sträng behöver läggas upp på en post i källsystemet och bör innehålla så många specialtecken som möjligt.
Verifierar att alla returnerade poster innehåller elementen healthcareProfessionalCareUnitHSAId och healthcareProfessionalCareGiverHSAId, som krävs för PDL-loggning.
Verifierar att en av de returnerade posterna innehåller tidpunkt då informationen registrerades. Element authorTime.
Verifierar att tjänsteproducenten kan returnera en post som talar om att informationen får delas till patient. Element approvedForPatient.
Verifierar att tjänsteproducenten kan returnera en post som talar om att informationen inte får delas till patient. Element approvedForPatient.
Verifierar att tjänsteproducenten kan returnera en signerad post. Element legalAuthenticator.
Verifierar att tjänsteproducenten kan returnera en osignerad post. Element legalAuthenticator.
Verifierar att tjänsteproducenten kan returnera en post som har låsts av systemet efter att en viss tid har förflutit utan att någon har signerat den. Element legalAuthenticator.
6.1.1 Grund
Syftet med testet är dels att verifiera att systemet kan hantera minst 10 samtidiga trådar, dels att skapa sig en bild av systemets prestanda. Testet är designat att ta max 3 minuter.
I SLA-kapitlet i självdeklarationen, under "Övrig kommentar", ange genomsnittlig responstid som visas i sista raden i kolumn "avg" med enhet millisekunder (ms).
6.1.2 Uthållighet
Syftet med testet är att undersöka prestanda hos systemet över längre tid (30 minuter). I SLA-kapitlet i självdeklarationen, under "Övrig kommentar", notera om testet gick att genomföra utan problem. Om inte, notera hur lång tid det var möjligt att köra.
6.2.1 Återhämtning
Syftet med testet är att utsätta systemet för maximal last och att verifiera att systemet automatiskt återhämtar sig. För att kontrollera att systemet har kunnat återhämta sig efter maximal last så rekommenderas att köra testfall "1.1.1 Personnummer" för att se att systemet svarar. I SLA-kapitlet i självdeklarationen, under "Övrig kommentar", notera om systemet kunde återhämta sig efter att ha utsatts för maximal last. Ange även hur många trådar som testet avslutades med.