Innehållsförteckning

Revisionshistorik

1. Inledning

Detta dokument innehåller testinstruktioner för användarorganisationer som ska genomföra anslutningstester i SDK Testbädd (QA). Anslutningstesterna utgör underlag för ifyllnad av SDK Självdeklaration i enlighet med SDK Anslutningsprocess (se ref. R1).

Testinstruktionen förutsätter att användarorganisationens tjänst är ansluten till SDK Testbädd (QA) och att användarorganisationen har access till SDK Adressbok (se ref. R2) och SDK Testklient (se ref. R5).

Testinstruktionen beskriver konfiguration som är nödvändig i SDK Adressbok för genomförande av anslutningstesterna.

Anslutningstesterna består av:

• Integrationstester som genomförs när användarorganisationen ansluter till SDK Testbädd (QA) (för ytterligare info, se kap. 3)

• Systemtester som genomförs när användarorganisationen har en stabil miljö ansluten till SDK Testbädd (QA) (för ytterligare info, se kap. 4)

1.1 Referenser

I följande avsnitt anges länkar till ytterligare relevant dokumentation och en sammanställning av samtliga referenser som förekommer i dokumentet.

1.1.1 Stödjande externa dokument

2. Testdata

2.1 Användarorganisationens organisationsinformation i SDK Adressbok

SDK-federationsoperatör ansvarar för att lägga upp användarorganisationen i SDK Adressbok tillsammans med behörighet för användarorganisationen att redigera sin organisations uppgifter, samt söka i andra organisationers uppgifter.

Följande ska konfigureras upp i SDK Adressbok för att kunna genomföra anslutningstester (sedan finns många fler frivilliga fält där användarorganisationen styr hur dessa fylls i för att kunna genomföra verksamhetslika tester):

2.2 Användarorganisationens organisationsinformation i SDK Testbädd (QA)

Inera ansvarar för flera fiktiva användarorganisationer som är del av konfigurationen i SDK Testbädd (QA) och som anslutande användarorganisationer kan genomföra tester emot.

2.2.1 Organisation#1 (SDK Testbädd)

En organisation som är upplagd i SDK Adressbok och som huvudsakligen används under testerna.

2.2.4 Organisation#2 (ej kontaktbar)

En organisation som är upplagd i SDK Adressbok, men som är okontaktbar.
Den EndpointURI som är kopplad till organisationen i SMP pekar på en felaktig URI.

3 Integrationstest

Anslutningstesterna består av integrationstester som genomförs innan systemtesterna. 

Integrationstester genomförs för att säkra anslutningen till SDK Testbädd (QA). Testfallen verifierar endast grundläggande funktionalitet.

SDK Testklients transportlager (AP)

• Verifierar alltid förseglingen, kontrollerar dokumenttyp och skickar avslutningsvis en transportkvittens på inkommande meddelanden med följsamhet till regelverk specificerade i eDelivery miljöspecifikation (se ref. R7),

SDK Testklients meddelandelager (MT)

• Kontrollerar duplikat

• Verifierar mottagna XHE meddelandens signatur

• Schema- och schematron-validerar alltid mottagna XHE meddelanden

• Schema- och schematron-validerar alltid mottagna SDK meddelanden och meddelandekvittenser

• Meddelanden och meddelandekvittenser som helt bryter mot grundläggande xml struktur loggas internt i SDK Testklient.

• SDK Testklient returnerar meddelandekvittens på mottaget meddelande som bryter mot schema eller schematron, med beskrivning på det först påträffade regelbrottet.

• SDK Testklient vidarebefordrar (om möjligt) felaktiga meddelanden vidare till användarorganisationens funktionsbrevlåda där användare kan ta del av samtliga regelbrott i meddelandet

SDK Testklients verksamhetslager (MK) ger användaren möjlighet att

• Ta del av meddelanden/meddelandekvittenser för sin användarorganisations funktionsbrevlåda

• Felsöka baserat på de stateförändringar och eventuella fel som presenteras i SDK Testklient

Användarorganisation ska i första hand kontakta användarorganisationens AP-operatör som i sin tur kontaktar DIGG om det finns behov för vidare felsökning som rör transportlagret (accesspunkten).
Användarorganisationen kan kontakta Inera (SDK federationsoperatör) om det finns behov för vidare felsökning som rör meddelande- eller verksamhetslager (anslutande system), t.ex. om meddelanden eller meddelandekvittenser som förväntas komma fram till SDK Testklient, helt enkelt inte visas i användargränssnittet  för SDK Testklient.

3.1 Förutsättningar

• Användarorganisationens AP-operatörs accesspunkt är ansluten till DIGGs SDK-QA

• Användarorganisationens AP-operatörs accesspunkt är följsam till DIGGs specifikationer (se ref. R8):

  • eDelivery - Kuverteringsprofil XHE

  • eDelivery - Transportmodell - Utökad Bas

  • eDelivery - Meddelandespecifikation - Meddelandekvittens

• Användarorganisationen är konfigurerad som deltagare i SMP (av användarorganisationens AP-operatör)

• Användarorganisationen har skickat in SDK anslutningsblankett till Inera för anslutning till SDK Testbädd(QA) (se ref. R1).

• Användarorganisationen har fått användare med rollen som organisationsadministratör och med behörighet till den egna användarorganisationen i SDK Adressbok
  (gör det möjligt för användarorganisationen att själva redigera organisationsuppgifter och registrera funktionsadresser under den egna användarorganisationen)

• Användarorganisationen har fått användare till SDK Testklient (se ref. R5)
  (gör det möjligt att skicka och ta emot meddelanden och meddelandekvittenser)

• Användarorganisationen har registrerat funktionsadresser för den egna användarorganisationen i SDK Adressbok (se ref. R2).

3.3 Meddelandetjänst (meddelandelagret)

TF 2.0.1 - INTEGRATIONSTEST - Meddelandetjänsten tar del av meddelande från SDK Testklient

Syfte

Kontrollera hur användarorganisationens meddelandetjänst hanterar ett inkommande meddelande och vidarebefordrar meddelandet till meddelandeklienten.

Teststeg

1. Skicka ett meddelande från SDK Testklient adresserat till en funktion i den egna användarorganisationen.

2. Användarorganisationens meddelandetjänst validerar meddelandet och genererar en meddelandekvittens automatiskt.

3. Meddelandeklienten tar del av meddelandet på ett korrekt sätt

4. Kontrollera att innehållet stämmer överens med vad som angivits i SDK Testklient

5. Kontrollera att SDK Testklient tagit emot en meddelandekvittens

Kommentar

Användarorganisationens meddelandetjänst förväntas validera utgående meddelandekvittenser.

TF 2.0.2 - INTEGRATIONSTEST - Meddelandetjänsten skickar meddelande till SDK Testklient

Syfte

Kontrollera att meddelandeklienten kan skicka meddelande via användarorganisationens meddelandetjänst till SDK Testklient och att att paketering av meddelandet genomförs på ett korrekt sätt.

Teststeg

1. Meddelandeklienten skickar ett meddelande via användarorganisationens meddelandetjänst till SDK Testklient.

2. SDK Testklient tar emot meddelandet

3. Kontrollera resultatet i SDK Testklient

4. Kontrollera att meddelandekvittensen når meddelandeklienten

Kommentar

Användarorganisationens meddelandetjänst förväntas validera utgående meddelanden.

Här har användarorganisationen stor frihet att bygga upp meddelanden på olika sätt som de skickar för att kunna forcera andra beteenden är det normala (utforskande testning).

3.4 Meddelandeklient (verksamhetslagret)

TF 3.0.1 - INTEGRATIONSTEST - Meddelandeklienten tar del av meddelande från SDK Testklient

Syfte

Kontrollera hur användarorganisationens meddelandeklienten hanterar ett inkommande meddelande som är adresserat till en funktion i den egna användarorganisationen.

Teststeg

1. Skicka ett meddelande från SDK Testklient adresserat till en funktion i den egna användarorganisationen

2. Användare av meddelandeklienten tar del av meddelandet på ett korrekt sätt

3. Kontrollera att innehållet stämmer överens med vad som angivits i SDK Testklient (angivna fält presenteras, samtliga bilagor är nåbara och att formateringen är korrekt)

TF 3.0.2 - INTEGRATIONSTEST - Meddelandeklienten skickar meddelande till SDK Testklient

Syfte

Kontrollera att användare av meddelandeklienten kan skicka meddelande via användarorganisationens meddelandeklient till SDK Testklient och att en funktion kan adresseras genom att hämta uppgifter från SDK Adressbok.

Teststeg

1. Användare av meddelandeklienten skickar SDK meddelande via användarorganisationens meddelandeklient till SDK Testklient och användarorganisationens egna funktionsbrevlåda genom att adressera funktionen Funktion#1 (under Organisation#1) som hämtas från SDK Adressbok

2. SDK Testklient tar emot meddelandet

3. Kontrollera resultatet i SDK Testklient

4 Systemtest

Anslutningstesterna består även av systemtester som genomförs efter integrationstesterna.

Systemtester genomförs för att verifiera funktionaliteten mer ingående.

SDK Testklient verifierar meddelanden och meddelandekvittenser på samma sätt som i integrationstesterna (se kap. 3).

4.1 Förutsättningar

• Integrationstester genomförda för de lager som ska systemtestas.

4.3 Meddelandetjänst (meddelandelagret)

TF 2.1.1 - Meddelandetjänsten tar del av meddelande från SDK Testklient (minimal)

Syfte

Kontrollera hur användarorganisationens meddelandetjänst hanterar ett inkommande meddelande med enbart de element som är obligatoriska (inga frivilliga element inkluderas) enligt innehållsspecifikation - Meddelande (se ref. R3).

Teststeg

1. Skicka ett meddelande (minimal) från SDK Testklient adresserat till en funktion i den egna användarorganisationen

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt

3. Meddelandeklienten tar del av meddelandet på ett korrekt sätt

4. Kontrollera att innehållet stämmer överens med vad som angivits i SDK Testklient

5. Kontrollera att SDK Testklient tagit emot en meddelandekvittens

Kommentar

För exempel på minimalt meddelande, se ref. R6 och motsvarande testfall.

TF 2.1.2 - Meddelandetjänsten tar del av meddelande från SDK Testklient (maximal)

Syfte

Kontrollera hur användarorganisationens meddelandetjänst hanterar ett inkommande meddelande där samtliga frivilliga element inkluderas enligt innehållsspecifikation - Meddelande (se ref. R3).
Meddelandet innehåller flera bilagor och den totala storleken på meddelandet är strax under 30 MB.

Teststeg

1. Skicka ett meddelande (maximal) från SDK Testklient adresserat till en funktion i den egna användarorganisationen

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt

3. Meddelandeklienten tar del av meddelandet på ett korrekt sätt

4. Kontrollera att innehållet stämmer överens med vad som angivits i SDK Testklient

5. Kontrollera att SDK Testklient tagit emot en meddelandekvittens

Kommentar

För exempel på maximalt meddelande, se ref. R6 och motsvarande testfall.

TF 2.2.1 - Mottaget meddelande innehåller okänd referens till meddelande

Syfte

Kontrollera att användarorganisationens meddelandetjänst även returnerar ACCEPTED om ett mottaget meddelande kan valideras, men innehåller en referens ('RefToMessageId') till ett meddelande som inte finns.

Teststeg

1. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med ett 'RefToMessageId' till ett meddelande (med 'messageId') som inte finns.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med 'Kvittenskod' ACCEPTED

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.3.1 - Meddelande som ska skickas överskrider storleksbegränsning

Syfte

Kontrollera att användarorganisationens meddelandetjänst kan returnera fel om ett mottaget meddelande från meddelandeklienten överskrider storleksbegränsningen på 30 MB.

Teststeg

1. I Meddelandeklient, skicka SDK meddelande till SDK Meddelandeklient med bilaga som överskrider 30 MB

2. Användarorganisationens meddelandeklient och/eller meddelandetjänst genererar felstatus och meddelandet skickas inte vidare till mottagare

3. Slutanvändare i Meddelandeklient blir informerad om meddelandestatus och anledning varför meddelandet inte kunde skickas

4. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.4.1 - Felhantering - Schemavalidering på mottaget meddelande som innehåller felaktig datatyp

Syfte

Kontrollera att användarorganisationens meddelandetjänst kan returnera REJECTED om ett mottaget meddelande innehåller felaktig datatyp (felaktigt datumformat).
Användarorganisationens Meddelandetjänst ska validera och fånga felaktigheten.

Teststeg

1. Exempel på SDK meddelande för motsvarande testfall finns i 'Testdata: SDK-meddelanden, test av valideringsprinciper' (se ref. R6)

2. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med felaktig datatyp.

3. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

   2. Orsakskod: SV

   3. Detaljkod: structure

   4. Detaljtext: cvc-datatype-valid.1.2.1: '3 Sept. 2019' is not a valid value for 'dateTime'

4. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.4.2 - Felhantering - Schematronvalidering på mottaget meddelande innehåller felaktigt kodverk för elementet 'senderId'

Syfte

Kontrollera att användarorganisationens meddelandetjänst kan returnera REJECTED om ett mottaget meddelande innehåller felaktigt kodverk.
(kodverket för 'Message/messageHeader/sender/senderId/root' sätts till 'Icke godkänt kodverk' istället för 'iso6523-actorid-upis')

Teststeg

1. Exempel på SDK meddelande för motsvarande testfall finns i 'Testdata: SDK-meddelanden, test av valideringsprinciper' (se ref. R6)

2. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen där felaktigt kodverk används för 'senderId'.

3. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. 'Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: invariant

      Detaljtext: In ns:root should be set to 'iso6523-actorid-upis' but was 'Icke godkänt kodverk'. | {path till element}

4. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.4.4 - Felhantering - Mottagna meddelandets identitet är ej unikt

Syfte

Kontrollera att användarorganisationens meddelandetjänst kan returnera REJECTED om ett mottaget meddelande i meddelandelagret inte är unikt ('messageId').

Teststeg

1. I intern utvecklingsmiljö, skicka ett första meddelande adresserat till en funktion i den egna användarorganisationen

2. Kontrollera att meddelandet hanteras korrekt

3. I intern utvecklingsmiljö, skicka ett andra meddelande adresserat till en funktion i den egna användarorganisationen där 'messageId' är identiskt med föregående meddelande

4. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: multiple-matches

      Detaljtext: MessageId duplicate detected, send new message with new message-id

5. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.4.5 - Felhantering - Mottaget meddelande innehåller felaktig funktionsadress

Syfte

Kontrollera att användarorganisationens meddelandetjänst kan returnera REJECTED om ett mottaget meddelande är adresserat till en felaktig funktion i den egna användarorganisationen.

Teststeg

1. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med felaktig funktionsadress (funktionsadress som inte finns i SDK Adressbok)

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: not-found

      Detaljtext: Wrong or unknown ns:subOrganization/ns:organizationId

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.4.6 - Felhantering - Mottaget meddelande kan inte dirigeras vidare

Syfte

Kontrollera att användarorganisationens meddelandetjänst agerar på förväntat sätt om ett mottaget meddelande är adresserat till en funktion i den egna användarorganisationen som för tillfället inte är nåbar.

Teststeg

1. Säkerställ att meddelandeklienten inte är nåbar från användarorganisationens meddelandetjänst

2. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med funktionsadress som pekar på den ej nåbara meddelandeklienten

3. Användarorganisationens meddelandetjänst hanterar meddelandet på ett korrekt och förväntat sätt (beteende kan skilja sig åt mellan olika lösningar av MT beroende på hur och om meddelandet läggs i kö)

4. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt ('Kvittenskod' ACCEPTED om meddelandet köas upp, annars 'Kvittenskod' REJECTED)

5. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

6. Testare återansluter meddelandeklienten till användarorganisationens meddelandetjänst 

7. Kontrollera loggar (om meddelandet buffrades, tar meddelandeklienten del av meddelandet på ett korrekt sätt)

Kommentar

Se ref. R3 (transient.exception eller timeout).

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.4.8 - Felhantering - Mottaget meddelande överskrider storleksbegränsning

Syfte

Kontrollera att användarorganisationens meddelandetjänst kan returnera REJECTED om ett mottaget meddelande överskrider storleksbegränsningen på 30 MB.

Teststeg

1. Exempel på SDK meddelande för motsvarande testfall finns i 'Testdata: SDK-meddelanden, test av valideringsprinciper' (se ref. R6)

2. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen som överskrider storleksbegränsningen i SDK (30 MB).

3. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: too-long

      Detaljtext: Message size to large.

4. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.4.9 - Felhantering - Mottaget meddelande har XHE kuvert som inte speglar adresseringen i SDK meddelandets header

Syfte

Kontrollera att användarorganisationens meddelandetjänst kan returnera REJECTED om avsändande part i XHE ('FromParty/PartyIdentification/ID') inte överensstämmer med avsändande part i SDK (MessageProperties/Property/originalSender).

Teststeg

1. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen där avsändande part i SDK meddelandet förändrats så att det inte överensstämmer med avsändande part i XHE-kuvertet.
   (Både XHE-kuvert och SDK header behöver vara korrekt för att meddelandet ska kunna adresseras på ett korrekt sätt till mottagaren)

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: security

      Detaljtext: Wrong or unknown sender-id

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.5.1 - Felhantering - Utgående meddelande kan inte skickas till otillgänglig deltagare

Syfte

Kontrollera att användarorganisationens meddelandetjänst hanterar meddelande som skickas till en okontaktbar organisation på ett korrekt sätt.

Teststeg

1. Meddelandeklienten skickar ett meddelande via användarorganisationens meddelandetjänst till en okontaktbar organisation (Organisation#2)
   (accesspunkten får ingen transportkvittens)

2. Kontrollera hur meddelandestatus presenteras (och eventuella omsändningsrutiner) när meddelandet inte kan skickas

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Se ref. R3 (transient.exception eller timeout).

TF 2.5.2 - Felhantering - Utgående meddelande kan inte skickas till användarorganisationens accesspunkt

Syfte

Kontrollera att användarorganisationens meddelandetjänst hanterar meddelande som inte kan skickas till användarorganisationens accesspunkt på ett korrekt sätt.

Teststeg

1. Meddelandeklienten skickar ett meddelande via användarorganisationens meddelandetjänst, men användarorganisationens accesspunkt är okontaktbar.

2. Kontrollera hur meddelandestatus presenteras (och eventuella omsändningsrutiner) när meddelandet inte kan skickas

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.6.2 - Felhantering - Meddelandekvittens REJECTED (maximal)

Syfte

Kontrollera att användarorganisationens meddelandetjänst kan hantera meddelandekvittenser där samtliga optionella element inkluderas (cac:LineResponse, cbc:StatusReasonCode) och med “rik” detaljinformation (flera cac:LineResponse element).

Teststeg

1. Meddelandeklienten skickar ett meddelande via användarorganisationens meddelandetjänst till intern utvecklingsmiljö (Organisation#1, Funktion#2)

2. I intern utvecklingsmiljö, returnera en meddelandekvittens (kvittenskod REJECTED) med maximalt innehåll (samtliga optionella element används och elementen håller mycket information

3. Kontrollera hur meddelandestatus presenteras (och eventuella omsändningsrutiner) när meddelandet inte kan skickas

4. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.6.3 - Felhantering - Meddelandekvittens saknas

Syfte

Kontrollera att användarorganisationens meddelandetjänst agerar korrekt när transportkvittens (OK) tagits emot men meddelandekvittens saknas.

Teststeg

1. Meddelandeklienten skickar ett meddelande via användarorganisationens meddelandetjänst till intern utvecklingsmiljö (Organisation#1, Funktion#3)
   (meddelandekvittens kommer INTE returneras)

2. Kontrollera hur meddelandestatus presenteras (och eventuella omsändningsrutiner) när meddelandet inte kvitterats

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.6.4 - Felhantering - Signatur på inkommande meddelande kan inte verifieras på grund av att cert-pub inte kan nås

Syfte

Kontrollera felhanteringen i användarorganisations meddelandetjänst när publikt certifikat inte kan hämtas ifrån cert-pub tjänst

Teststeg

1. Konfigurera meddelandetjänstens SML zone för cert-pub tjänst till en onåbar URL.

2. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen.

3. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: SIG

      Detaljkod: security

      Detaljtext: Sender signature not validated, public key not found / cert-pub unreachable

4. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.6.5 - Felhantering - Signering på inkommande meddelande stämmer inte med publik nyckel

Syfte

Kontrollera felhanteringen i användarorganisations meddelandetjänst när mottaget meddelande har en signatur som inte kan verifieras med publik nyckel.

Teststeg

1. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen där signaturen inte är korrekt.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: SIG

      Detaljkod: security

      Detaljtext: Sender signature not validated

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.6.6 - Felhantering av inkommande krypterat meddelande där meddelande inte kan dekrypteras:

Syfte

Kontrollera felhanteringen i användarorganisations meddelandetjänst när meddelandets nyttolast är krypterat på ett sätt som gör att mottagaren inte kan dekryptera det på förväntat sätt

Teststeg

1. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med en SDK payload som är förvanskad efter kryptering men signerad på ett korrekt sätt.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: security

      Detaljtext: Message could not be decrypted

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.6.7 - Felhantering av inkommande okrypterat meddelande:

Syfte

Kontrollera felhanteringen i användarorganisations meddelandetjänst när meddelandets nyttolast är okrypterad.

Teststeg

1. I intern utvecklingsmiljö, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med en SDK payload som är okrypterad och XHE attributet InstanceEncryptionIndicator satt till false

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: security

      Detaljtext: Unencrypted message not allowed

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast att utföra som en del av interna utvecklingstester.

4.4 Meddelandeklient (verksamhetslagret)

TF 3.1.1 - Meddelandeklienten tar del av meddelande från SDK Testklient (minimal)

Syfte

Kontrollera hur användarorganisationens meddelandeklient hanterar ett inkommande meddelande med enbart de element som är obligatoriska (inga frivilliga element inkluderas) enligt innehållsspecifikation - Meddelande (se ref. R3).

Teststeg

1. Skicka ett meddelande (minimal) från SDK Testklient adresserat till en funktion i den egna användarorganisationen.

2. Användare av meddelandeklienten tar del av meddelandet på ett korrekt sätt

3. Kontrollera att innehållet stämmer överens med vad som angivits i SDK Testklient

Kommentar

SDK Testklient gör ingen skillnad på TF 2.1.1 och detta testfall. Skillnaden ligger i att användarorganisationen nu har ett verksamhetslager ovanpå meddelandetjänsten som också ska kunna hantera ett minimalt meddelandeinnehåll.

TF 3.1.2 - Meddelandeklienten tar del av meddelande från SDK Testklient (maximal)

Syfte

Kontrollera hur användarorganisationens meddelandeklient hanterar ett inkommande meddelande där samtliga frivilliga element inkluderas enligt innehållsspecifikation - Meddelande (se ref. R3).
Meddelandet innehåller flera bilagor och den totala storleken på meddelandet är strax under 30 MB.

Teststeg

1. Skicka ett meddelande (maximal) från SDK Testklient adresserat till en funktion i den egna användarorganisationen.

2. Användare av meddelandeklienten tar del av meddelandet på ett korrekt sätt

3. Kontrollera att innehållet stämmer överens med vad som angivits i SDK Testklient

Kommentar

SDK Testklient gör ingen skillnad på TF 2.1.2 och detta testfall. Skillnaden ligger i att användarorganisationen nu har ett verksamhetslager ovanpå meddelandetjänsten som också ska kunna hantera ett maximalt meddelandeinnehåll.

TF 3.1.3 - Meddelandeklienten tar del av ett sekretessmarkerat meddelande från SDK Testklient

Syfte

Kontrollera hur användarorganisationens meddelandeklient hanterar ett inkommande meddelande som är sekretessmarkerat.

Teststeg

1. Skicka ett meddelande (sekretessmarkerat) från SDK Testklient adresserat till en funktion i den egna användarorganisationen.

2. Användare av meddelandeklienten tar del av meddelandet på ett korrekt sätt och det syns tydligt att meddelandet är sekretessmarkerat

TF 3.2.1 - Meddelandeklienten besvarar mottaget meddelande

Syfte

Kontrollera att meddelandeklienten kan besvara meddelanden på ett korrekt sätt genom att använda 'conversationId' från det mottagna meddelandet.

Teststeg

1. Skicka ett meddelande från SDK Testklient adresserat till en funktion i den egna användarorganisationen

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt.

3. Meddelandeklienten tar del av mottaget meddelandet på ett korrekt sätt

4. Meddelandeklienten besvarar mottaget meddelande ('conversionId' hämtas från mottaget meddelande)

5. SDK Testklient tar emot svaret, kontrollerar 'conversationId' och skickar en meddelandekvittens

6. Kontrollera att svaret presenteras tillsammans med ursprunglig meddelande i SDK Testklient

7. Kontrollera att meddelandekvittensen på svaret når meddelandeklienten

TF 3.2.2 - Meddelandeklienten tar del av besvarat meddelande

Syfte

Kontrollera att meddelandeklienten kan hantera svar på tidigare skickade meddelanden på ett korrekt sätt genom att inkludera meddelandet till en konversation.

Teststeg

1. Meddelandeklienten skickar ett meddelande via användarorganisationens meddelandetjänst till SDK Testklient

2. SDK Testklient tar emot meddelandet

3. Besvara det senast mottagna meddelande i SDK Testklient

4. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt på det mottagna svaret

5. Meddelandeklienten tar del av svaret på ett korrekt sätt

6. Kontrollera att svaret presenteras tillsammans med ursprungligt meddelande för användare

7. Kontrollera att SDK Testklient tagit emot en meddelandekvittens på det skickade svaret

TF 3.3.1 - Meddelandeklienten kompletterar skickat meddelande

Syfte

Kontrollera att meddelandeklienten kan komplettera ett skickat meddelande på ett korrekt sätt genom att använda 'conversationId' från ett skickat meddelande.

Teststeg

1. Meddelandeklienten skickar ett meddelande via användarorganisationens meddelandetjänst till SDK Testklient

2. SDK Testklient tar emot meddelandet

3. Meddelandeklienten kompletterar tidigare skickat meddelande ('conversionId' hämtas från skickat meddelande)

4. SDK Testklient tar emot kompletteringen, kontrollerar 'conversationId' och skickar en meddelandekvittens

5. Kontrollera att kompletteringen presenteras tillsammans med ursprungligt meddelande i SDK Testklient

6. Kontrollera att meddelandekvittensen på kompletteringen når meddelandeklienten

TF 3.3.2 - Meddelandeklienten tar del av kompletterat meddelande

Syfte

Kontrollera att meddelandeklienten kan hantera kompletteringar på tidigare mottagna meddelanden på ett korrekt sätt genom att inkludera meddelandet till en konversation.

Teststeg

1. Skicka ett meddelande från SDK Testklient adresserat till en funktion i den egna användarorganisationen

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt

3. Komplettera genom att använda svarafunktionen på det senast skickade meddelande i SDK Testklient

4. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt på den mottagna kompletteringen

5. Meddelandeklienten tar del av kompletteringen på ett korrekt sätt

6. Kontrollera att kompletteringen presenteras tillsammans med ursprungligt meddelande för användare

7. Kontrollera att SDK Testklient tagit emot en meddelandekvittens på den skickade kompletteringen