Page History
...
| Navitabs | ||||
|---|---|---|---|---|
|
Manuel test af LPR3 evidenskilde
Fremgangsmåde
Testen er udført efter nedenstående fremgangsmåde.
- Test cases er beskrevet og dokumenteret.
- Der er genereret DTG testpersoner.
- Der er manuelt lavet LPR3 data der anvender genererede testpersoner samt SOR og SHAK koder fremfundet jvf. krav i test cases.
- LPR3 data indlæst af Netic.
- Via FMK-Online er der logget ind som læge på den afdeling der er beskrevet i testcases.
- Der er lavet opslag på testpersons medicinkort.
- Arosii har fremsendt BRS logfiler.
- Logfiler er analyseret for testresultat.
Testcases
...
LPR3 indberetning på patient med forløbselement kontakt.
BRS registrering i samme tidsinterval som LPR3 indberetningen og shak kode matcher SOR kode i LPR3 indberetningen.
Det vil sige sundhedsfaglig er "ansat" på samme afdeling som indberetningen er lavet.
...
LPR3 indberetning på patient med forløbselement kontakt.
BRS registrering i andet tidsinterval end LPR3 indberetningen og shak kode matcher SOR kode i LPR3 indberetningen.
Det vil sige sundhedsfaglig er "ansat" på samme afdeling som indberetningen er lavet men at indberetningen til LPR3 indeholder andet tidsinterval end den registrering der er lavet i BRS.
...
LPR3 indberetning på patient med forløbselement opholdsadresse.
BRS registrering i samme tidsinterval som LPR3 indberetningen og shak kode matcher SOR kode i LPR3 indberetningen. Det vil sige sundhedsfaglig er "ansat" på samme afdeling som indberetningen er lavet.
...
Der findes ikke nogen LPR3 indberetning på patient.
BRS registrering på patient der ikke findes nogen LPR3 indberetning på.
...
LPR3 indberetning på patient med forløbselement kontakt.
BRS registrering i samme tidsinterval som LPR3 indberetningen og shak kode der ikke matcher SOR kode i LPR3 registrering. Dog er de på samme sygehus.
Det vil sige sundhedsfaglig er ansat på samme sygehus som indberetningen er lavet. Den sundhedsfaglige er ikke ansat på samme afdeling eller en afdeling der ligger over LPR3 registreringen.
...
LPR3 indberetning på patient med forløbselement kontakt.
BRS registrering i samme tidsinterval som LPR3 indberetningen og shak kode der ligger over SOR koden i LPR3 indberetningen.
Det vil sige sundhedsfaglig er "ansat" på en afdeling der ligger over den anvende SOR kode i LPR3 indberetningen.
...
LPR3 indberetning på patient med forløbselement kontakt.
BRS registrering i andet tidsinterval end LPR3 indberetningen og shak kode der ligger over SOR koden i LPR3 indberetningen.
Det vil sige sundhedsfaglig er "ansat" på en afdeling der ligger over den anvende SOR kode i LPR3 indberetningen. Indberetningen til LPR3 er lavet med et andet tidsinterval end det der er avendt i BRS registreringen.
...
Formål
Denne side beskriver omfang af den automatiserede regressionstest f.s.v.a BRS komponenten.
Testgenstand
BRS testen dækker både kald direkte til servicen med organisationscertifikat samt kald, der sker automatisk ved kald af DDS servicen.
Kun de sorte pile er implementeret. De røde udestår.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Testomfang
Regressionstesten omfatter på nuværende tidspunkt kun test af Sikrede register samt sygesikringsregister (SSR), da det ikke er muligt at generere øvrige evidenskilder på testmiljøet.
Regressionstesten indeholder ikke automatiseret test af notifikationer.
Testcases for Sikrede er skrevet med udgangspunkt i dette flow: BRS - Design- og Arkitekturbeskrivelse - NSP services - Global Site (nspop.dk)
Testcases for sygesikring SSR er skrevet med udgangspunkt i dette flow: BRS - Design- og Arkitekturbeskrivelse - NSP services - Global Site (nspop.dk)
Testdesignteknikker (TDT)
Der er anvendt ækvivalensklassepartitionering ift tidsperioder, så der testes relation både før, under og efter den forespurgte periode.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Der er anvendt beslutningstabeller ift den aktuelle behandlingsrelation.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Der anvendes ligeledes beslutningstabeller i forhold til at validere værdierne for tilstrækkelig relation og opfølgning ift. den acceptable relation.
Dette gøres dog kun med stikprøver, ikke alle kombinationer testes i nuværende testdybde. Kombinationerne af tilstrækkelig relation og opfølgning testes i Scenario Outlines.
Testcases for BRS:
Herunder ses nuværende testcases for BRS service samt deres sidste afviklingsstatus.
Bemærk at for scenario outlines gælder, at hvis bare eet af scenarierne fail'er mens de øvrige pass'er, så står testissuet til FAIL. I Jira kan man under Test Execution se, hvilke scenarier der går godt og hvilke, der fejler:
| Table Filter | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
| Jira | ||||||
|---|---|---|---|---|---|---|
|
Årsagen til de fejlede testcases kan findes i Jira ved at se på den sidste testkørsel samt de relaterede RFC'er for det enkelte testscenarie.
Testdata
...
Test resultat
...
I SDS-3733 findes der logfiler fra testen.