Domänversion: 2.1.13
Detta dokument beskriver testsviten för GetCareDocumentation 2.1. Testsviten innehåller ett antal testfall som kan användas för att verifiera implementationen innan integrationen med den nationella tjänsteplattformen.
Testsviten innehåller ett antal testfall som kan användas för att samla in information om anslutande system. Denna information kan sedan ligga till grund för ett underlag för godkännande.
Ett testfall med ej förväntat utfall ska med andra ord ses som en informationskälla för den avvikelse som ska rapporteras i självdeklarationen.
I dessa fall rekommenderas mer omfattande tester och en utförlig dokumentation av vad man observerat, för att informationen redan i första granskningsrundan skall vara tillräcklig för beslut.
Detta underlag för godkännande kommer att granskas av ICC på Inera som rapporterar avvikelser. Dessa granskas därefter av Ineras avvikelsegrupp. Utkomsten av denna granskning kan leda till en eller flera avvikelser av tre olika typer där en avvikelse kan anses vara:
Om man kör version 2.0 av tjänstekontraktet GetCareDocumentation så måste man kommentera bort följande rader i constraints.xml filen (se nedan). Sök upp raderna och kommentera ut hela raden med testet. Detta gör att man tar bort kollen om elementet nullified och nulliefiedReason skickas med i svaret.
<iso:assert test="not(urn1:nullified)">Element careDocumentationHeader must not contain 'nullified'.</iso:assert><iso:assert test="not(urn1:nullifiedReason)">Element careDocumentationHeader must not contain 'nullifiedReason'.</iso:assert>
Kommentera ut genom att sätta följande starttecken <!-- och sluttecken --> runtom elementen. När du kommenterat bort testeterna för 'nullified' och 'nullifiedReason' ska det se ut enligt nedan.
<!--<iso:assert test="not(urn1:nullified)">Element careDocumentationHeader must not contain 'nullified'.</iso:assert>--><!--<iso:assert test="not(urn1:nullifiedReason)">Element careDocumentationHeader must not contain 'nullifiedReason'.</iso:assert>-->
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å Nationellt reservID. Ersätt patientId med det NRID som du vill filtrera på.
Testfalls-specifika parametrar
För bra testning på dessa punkter är en varierad testdata avseende tidpunkter viktig.
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.
Verifierar att responsen är ett SOAP Fault.
Detta testfall kräver att tjänsteproducenten skapar förutsättningar för ett internt fel att uppstå, t.ex. att man stänger av kopplingen mot en databas.
OBS! Manuell kontroll av svarsmeddelandet krävs för att säkerställa att meddelandet inte innehåller personuppgifter och att medföljande log-id inte är spårbart till patienten.
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.
Testa att lägga in strängen åäö<>><& för att säkerställa att källsystemet kan kapsla in specialtecken på rätt sätt.
Testa olika varianter på var denna sträng kan ligga; löpande text, mallrubriker, sökord m.m.
Testa även olika varianter på strängen, gärna med specialtecken som ofta förekommer i er verksamhet.
OBS! Detta är ett manuellt testfall, där responsen behöver kontrolleras manuellt. SoapUI kommer att ge ett "grönt testfall" även fast strängen är korrupt.
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. Ta värdet som visas i sista raden i kolumn "avg" och dela med antal anrop (oftast 2). Ange sedan värdet 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.
Filtrering. Verifierar att tjänsteproducenten kan filtrera resultatet baserat på tjänstekonsumentHSAId (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ört bortfiltrering av vårdenhet,
antalet poster skall i det senare svaret vara färre och parametern filterString skall då inte finnas i det filtrerade svaret. Testfallet är ej applicerbart för system som inte implementerat denna typ av filtrering.
Filtrering. Verifierar att tjänsteproducenten returnerar tomt svar för bortfiltrerat tjänstekonsumentHSAId (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ört bortfiltrering av konsument,
Testfallet är ej applicerbart för system som inte implementerat denna typ av filtrering.
Verifierar att tjänsteproducenten returnerar samma svar oavsett vilket tjänstekonsumentHSAId (HTTP-headern "x-rivta-original-serviceconsumer-hsaid") som anges, observera dock att testfallet endast räknar antal poster och jämför dessa mellan response 1 och 2. Bör även testas manuellt.