Testfall för meddelandesystem

2.2.2 SDK testklient - 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.

Organisationsidentifierare:
0203:org002.sdk-testclient.open-test.digg.se

• Funktionsadresser:
  testfunktion. 0203:org002.sdk-testclient.open-test.digg.se
• Funktionsnamn:
  Federationsägarens testfunktion
• Funktionsbeskrivning: Funktion används endast för adressering, se TF 2.5.1. Funktionen är okontaktbar.

2.2.3 SDK testklient - Organisation#3 (utgånget O2O-certifikat)

En organisation som är upplagd i SDK adressbok, med ett publikt O2O-certifikatet i SMP som är utgånget.

Organisationsidentifierare:
0203:org003.sdk-testclient.open-test.digg.se

• Funktionsadresser:
  testfunktion. 0203:org003.sdk-testclient.open-test.digg.se
• Funktionsnamn:
  Federationsägarens testfunktion
• Funktionsbeskrivning:
  Funktion används endast för adressering, se TF 2.5.1. Funktionen är okontaktbar.

2.2.4 SDK testklient - Organisation#4 (felaktigt AS4-certifikat)

En organisation som är upplagd i SDK adressbok, med ett felaktigt AS4-certifikat i accesspunkten. Den EndpointURI som är kopplad till organisationen i SMP pekar mot en testaccesspunkt med ett AS4-certifikat för fel federation och som är utgånget.

Organisationsidentifierare:
0203:org004.sdk-testclient.open-test.digg.se

• Funktionsadresser: testfunktion. 0203:org004.sdk-testclient.open-test.digg.se
• Funktionsnamn: Federationsägarens testfunktion
• Funktionsbeskrivning: Funktion används endast för adressering, se TF 2.7.2. Felaktigt AS4-certifikat).

2.2.5 SDK testklient - Organisation#5 (utgånget TLS-certifikat)

En organisation som är upplagd i SDK adressbok, med ett utgånget TLS-certifikat på transportlagernivå. Den EndpointURI som är kopplad till organisationen i SMP pekar mot en extern server (expired.badssl.com ).

Organisationsidentifierare: 0203:org005.sdk-testclient.open-test.digg.se

• Funktionsadresser: testfunktion. 0203:org005.sdk-testclient.open-test.digg.se
• Funktionsnamn: Federationsägarens testfunktion
• Funktionsbeskrivning: Funktion används endast för adressering, se TF 2.7.3. Funktionen är okontaktbar).

2.2.6 SDK testklient - Organisation#6 (felaktig CA i TLS-certifikat)

En organisation som är upplagd i SDK adressbok, med ett TLS-certifikat med felaktig CA på transportlagernivå. Den EndpointURI som är kopplad till organisationen i SMP pekar mot en extern server (untrusted.badssl.com ).

Organisationsidentifierare: 0203:org006.sdk-testclient.open-test.digg.se

• Funktionsadresser: testfunktion. 0203:org006.sdk-testclient.open-test.digg.se
• Funktionsnamn: Federationsägarens testfunktion
• Funktionsbeskrivning: Funktion används endast för adressering, se TF 2.7.4. Funktionen är okontaktbar.

3 Integrationstester

Integrationstester genomförs av leverantören för att verifiera dess anslutning till miljön OPEN-TEST. Testfallen verifierar endast grundläggande funktionalitet.

SDK testklients transportlager (AP)

Verifierar alltid förseglingen, kontrollerar dokumenttyp och skickar avslutningsvis en transportkvittens på inkommande meddelanden enligt plattform för eDelivery regelverk.

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 av det först påträffade regelbrottet.
• SDK testklient vidarebefordrar (om möjligt) felaktiga meddelanden vidare till organisationens 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 organisations funktionsbrevlåda.
• Felsöka baserat på de stateförändringar och eventuella fel som presenteras i SDK testklient.
• Leverantören ska i första hand kontakta sin AP-operatör som i sin tur kontaktar Digg om det finns behov för vidare felsökning som rör transportlagret (accesspunkten).

Leverantören kan kontakta federationsägaren (sdk.digg.se) 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 inte visas i användargränssnittet för SDK testklient.

3.1 Förutsättningar

• Leverantörens AP-operatör är ansluten till Diggs miljö OPEN-TEST.
• Leverantören är konfigurerad som deltagare i SMP (av leverantörens AP-operatör).
• Leverantören har skickat in SDK anslutningsblankett till federationsägare för anslutning till OPEN-TEST.
• Leverantören har fått en användare med rollen som användaradministratör med behörighet till den egna organisationen i SDK adressbok. Det gör det möjligt för leverantören att själva skapa användare och redigera sina organisationsuppgifter och registrera funktionsadresser under den egna organisationen.
• Leverantören har registrerat funktionsadresser för den egna organisationen i SDK adressbok.
• Leverantören har fått en användare till SDK testklient som gör det möjligt att skicka och ta emot meddelanden och meddelandekvittenser.
  

3.2 Testfall för meddelandetjänst (meddelandelagret)

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

Syfte

Kontrollera hur leverantörens 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 organisationen.
2. Leverantörens 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.

Testfallet finns automatiserat i SDK testklient (skickar meddelande, kontrollerar meddelandekvittens).

Leverantörens meddelandetjänst ska validera utgående meddelandekvittenser.

3.2.2 TF 2.0.2 - INTEGRATIONSTEST - Meddelandetjänsten skickar meddelande till SDK testklient

Syfte

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

Teststeg

1. Meddelandeklienten skickar ett meddelande via leverantörens meddelandetjänst till SDK testklient.
2. SDK testklient tar emot meddelandet.
3. Kontrollera resultatet i SDK testklient.
4. Kontrollera att meddelandekvittensen når meddelandeklienten.

Leverantörens meddelandetjänst ska validera utgående meddelanden. Här har leverantören stor frihet att bygga upp meddelanden på olika sätt som denne skickar för att kunna forcera andra beteenden är det normala (utforskande testning).

3.3 Testfall för meddelandeklient (verksamhetslagret)

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

Syfte

Kontrollera hur leverantörens meddelandeklienten hanterar ett inkommande meddelande som är adresserat till en funktion i den egna organisationen.

Teststeg

1. Skicka ett krypterat och signerat meddelande från SDK testklient adresserat till en funktion i den egna organisationen.
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 formateringen är korrekt.

3.3.2 TF 3.0.2 - INTEGRATIONSTEST - Meddelandetjänsten skickar meddelande till SDK testklient

Syfte

Kontrollera att användare av meddelandeklienten kan skicka meddelande via leverantörens 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 leverantörens meddelandeklient till SDK testklient och organisationens egna funktionsbrevlåda genom att adressera funktionen ‘Digg i OPEN-TEST, under organisationen 'SDK OPEN-TEST – Digg, som hämtas från SDK adressbok.
2. SDK testklient tar emot meddelandet.
3. Kontrollera resultatet i SDK testklient.

Kommentar

Leverantören ska även skicka ett meddelande till Digg och SDK-förvaltningens funktionsbrevlåda.

4. Systemtester

Systemtesterna genomförs efter integrationstesterna. Systemtester genomförs av leverantören för att verifiera funktionaliteten mer ingående och utgör underlag för leverantören att fylla i testrapporten. SDK testklient verifierar meddelanden och meddelandekvittenser på samma sätt som i integrationstesterna, se avsnitt 3 ovan.

4.1 Meddelandetjänst (meddelandelagret)

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

Syfte

Kontrollera hur deltagarorganisationens meddelandetjänst hanterar ett inkommande meddelande med enbart de element som är obligatoriska (inga frivilliga element inkluderas) enligt innehållsspecifikation – Meddelande.

Teststeg

1. Från SDK testklient, skicka ett meddelande (minimal) adresserat till en funktion i den egna deltagarorganisationen.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens.
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.

Testfallet finns automatiserat i SDK testklient; skickar meddelande, kontrollerar meddelandekvittens.

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

Syfte

Kontrollera hur deltagarorganisationens meddelandetjänst hanterar ett inkommande meddelande där samtliga frivilliga element inkluderas enligt Innehållsspecifikation – Meddelande.

Meddelandet innehåller flera bilagor och den totala storleken på meddelandet är strax under 30 MB.

Teststeg

1. Från SDK testklient, skicka ett meddelande (maximal) adresserat till en funktion i den egna deltagarorganisationen.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens.
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.

4.1.3 TF 2.1.3 - Meddelandetjänsten tar del av meddelande från SDK testklient (maximal, små bilagor)

Syfte

Kontrollera hur deltagarorganisationens meddelandetjänst hanterar ett inkommande meddelande där samtliga frivilliga element inkluderas enligt Innehållsspecifikation – Meddelande.

Meddelandet innehåller flera små bilagor.

Teststeg

1. Från SDK testklient, skicka ett meddelande (maximal, små bilagor) adresserat till en funktion i den egna deltagarorganisationen.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens.
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.

Testfallet finns automatiserat i SDK testklient; skickar meddelande, kontrollerar meddelandekvittens.

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

Syfte

Kontrollera att deltagarorganisationens 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. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen där 'RefToMessageId' refererar till ett meddelande ('messageId') som inte finns.
2. Deltagarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med 'Kvittenskod' ACCEPTED.
3. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer inom SDK och bilaga för IT-säkerhet inom SDK.

Testfallet finns automatiserat i SDK testklient (skickar meddelande, kontrollerar meddelandekvittens).

4.1.5 TF 2.3.1 - Meddelandetjänsten tar del av meddelande från SDK testklient (minimal)

Syfte

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

Teststeg

1. Från deltagarorganisationens meddelandeklient, skicka ett SDK-meddelande adresserat till extern part (SDK testklient) där bilagornas storlek överskrider 30 MB.
2. Deltagarorganisationens meddelandeklient och/eller meddelandetjänst genererar felstatus och meddelandet skickas inte vidare till mottagaren.
3. Meddelandeklienten blir informerad om meddelandestatus och anledningen till varför meddelandet inte kunde skickas.
4. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer inom SDK.

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

Syfte

Kontrollera att deltagarorganisationens meddelandetjänst kan returnera REJECTED om ett mottaget meddelande innehåller felaktig datatyp (felaktigt datumformat) i meddelandestrukturen.

Deltagarorganisationens meddelandetjänst ska validera och fånga felaktigheten.

Teststeg

1. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen med felaktig datatyp i meddelandestrukturen.
2. Deltagarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

1. Kvittenskod: REJECTED
2. Orsakskod: SV
3. Detaljkod: structure
4. Detaljtext: <beskrivning av problemet>
5. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet (Länk).

Testfallet finns automatiserat i SDK testklient (skickar meddelande, kontrollerar meddelandekvittens).

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

Syfte

Kontrollera att deltagarorganisationens 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. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen där felaktigt kodverk används för 'senderId'.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens med:

1. Kvittenskod: REJECTED
2. Orsakskod: BV
3. Detaljkod: invariant

1. Detaljtext: <beskrivning av problemet>

1. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

Testfallet finns automatiserat i SDK testklient (skickar meddelande, kontrollerar meddelandekvittens).

4.1.8 TF 2.4.3 - Felhantering - Schemavalidering på mottaget meddelande som innehåller felaktig datatyp i XHE

Syfte

Kontrollera att deltagarorganisationens meddelandetjänst kan returnera REJECTED om ett mottaget meddelande innehåller felaktig datatyp (felaktigt datumformat) i XHE. Deltagarorganisationens meddelandetjänst ska validera och fånga felaktigheten.

Teststeg

1. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen med felaktig datatyp i XHE.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens med:

1. Kvittenskod: REJECTED
2. Orsakskod: SV
3. Detaljkod: structure
4. Detaljtext: <beskrivning av problemet>
5. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

Testfallet finns automatiserat i SDK testklient (skickar meddelande, kontrollerar meddelandekvittens).

4.1.9 TF 2.4.4 - Meddelandetjänsten tar del av meddelande från SDK testklient (minimal)

Syfte

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

Teststeg

1. Förberedande: Skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen och kontrollera att meddelandet hanteras korrekt.
2. Skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen där 'messageId' är identiskt med tidigare meddelande.
3. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens med:

1. Kvittenskod: REJECTED
2. Orsakskod: BV
3. Detaljkod: multiple-matches

1. Detaljtext: <beskrivning av problemet>

1. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

SDK testklient saknar stöd, lämpligast att utföra som en del av interna utvecklingstester.

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

Syfte

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

Teststeg

1. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen med felaktig funktionsadress (funktionsadressen är inte upplagd i SDK adressbok).
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens med:

1. Kvittenskod: REJECTED
2. Orsakskod: BV
3. Detaljkod: not-found

1. Detaljtext: <beskrivning av problemet>

1. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

Testfallet finns automatiserat i SDK testklient (skickar meddelande, kontrollerar meddelandekvittens).

4.1.11 TF 2.4.6 - Felhantering - Mottaget meddelande kan inte dirigeras vidare

Syfte

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

Teststeg

1. Förberedande: Säkerställ att meddelandeklienten inte är nåbar från deltagarorganisationens meddelandetjänst.
2. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen med funktionsadress som pekar på den ej nåbara meddelandeklienten.
3. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens (kvittenskod: ACCEPTED).
4. Deltagarorganisationens meddelandetjänst buffrar meddelandet i gränssnittet mot meddelandeklienten.
5. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.
6. Återställ: Återanslut meddelandeklienten till deltagarorganisationens meddelandetjänst.
7. Kontrollera loggar och att meddelandeklienten tar del av det tidigare buffrade meddelandet på ett korrekt sätt.

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

Syfte

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

Teststeg

1. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen som överskrider storleksbegränsningen i SDK (30 MB).
2. Deltagarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

1. Kvittenskod: REJECTED
2. Orsakskod: BV
3. Detaljkod: too-long
4. Detaljtext: <beskrivning av problemet>
5. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

Stöd finns i SDK testklient att skicka meddelanden med bilagor där sammanlagd storlek är något över 30 MB (max 35 MB).

4.1.13 TF 2.4.9 - Felhantering - Mottaget meddelande har XHE med avsändare som ej överensstämmer med avsändare i AS4

Syfte

Kontrollera att deltagarorganisationens meddelandetjänst returnerar REJECTED på ett mottaget SDK-meddelande där avsändande part i XHE ('FromParty/PartyIdentification/ID') inte överensstämmer med avsändande part i AS4 originalSender ('PMode.BusinessInfo.Properties - originalSender'). Se kapitel 2.2.3 i bilaga Kuverteringsprofil XHE Länk till annan webbplats..

Teststeg

1. Från SDK testklient, skicka ett SDK-meddelande adresserat till en funktion i den egna deltagarorganisationen där avsändande part i XHE-delen av meddelandet förändrats så det inte överensstämmer med originalSender i AS4-delen av meddelandet.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens med:

1. Kvittenskod: REJECTED
2. Orsakskod: BV
3. Detaljkod: security
4. Detaljtext: <beskrivning av problemet>
5. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

Testfallet finns automatiserat i SDK testklient (skickar meddelande, kontrollerar meddelandekvittens).

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

Syfte

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

Teststeg

1. Meddelandeklienten skickar ett meddelande via deltagarorganisationens meddelandetjänst till en okontaktbar organisation (Organisation#2), accesspunkten får ingen transportkvittens.
2. Kontrollera hur meddelandestatus och eventuella omsändningsrutiner presenteras när meddelandet inte kan skickas.
3. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

4.1.15 TF 2.5.2 - Felhantering - Utgående meddelande kan inte skickas till deltagarorganisationens accesspunkt

Syfte

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

Teststeg

1. Förberedande: Bryt anslutningen mellan meddelandetjänst och accesspunkt.
2. Meddelandeklienten skickar ett meddelande via deltagarorganisationens meddelandetjänst, men deltagarorganisationens accesspunkt är okontaktbar.
3. Kontrollera hur meddelandestatus och eventuella omsändningsrutiner presenteras när meddelandet inte kan skickas.
4. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.
5. Återställ: Återanslutning mellan meddelandetjänst och accesspunkt.

4.1.16 TF 2.6.1 - Felhantering - Meddelandekvittens REJECTED (filtyp stöds ej)

Syfte

Kontrollera att deltagarorganisationens meddelandetjänst kan hantera meddelandekvittens REJECTED då bilagan inte accepterats (filtyp stöds ej) av mottagande MT.

Teststeg

1. Meddelandeklienten skickar ett meddelande med en valfri bilaga med filtypen .exe via deltagarorganisationens meddelandetjänst till SDK testklient (organisation ‘SDK testklient - Digg, Funktionsnamn#1).
2. Från SDK testklient returneras en meddelandekvittens (kvittenskod REJECTED, orsakskod ‘Not-supported’).
3. Kontrollera hur meddelandestatus presenteras när meddelandet inte accepterats.
4. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

4.1.17 TF 2.6.2 - Felhantering - Meddelandekvittens REJECTED (maximal)

Syfte

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

Teststeg

1. Meddelandeklienten skickar ett meddelande via deltagarorganisationens meddelandetjänst till SDK testklient (organisation ‘SDK QA - Digg, Funktionsnamn#2).
2. Från SDK testklient returneras en meddelandekvittens (kvittenskod REJECTED) med maximalt innehåll, samtliga valbara element används och elementen håller mycket information.
3. Kontrollera hur meddelandestatus och eventuella omsändningsrutiner presenteras när meddelandet inte accepterats.
4. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

4.1.18 TF 2.6.3 - Felhantering - Meddelandekvittens saknas

Syfte

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

Teststeg

1. Meddelandeklienten skickar ett meddelande via deltagarorganisationens meddelandetjänst till SDK testklient (organisation ‘SDK QA- Digg, Funktionsnamn#3), meddelandekvittens kommer INTE att returneras.
2. Kontrollera hur meddelandestatus och eventuella omsändningsrutiner presenteras när meddelandet inte har kvitterats.
3. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

4.1.19 TF 2.6.4 - Felhantering - Signatur på inkommande meddelande kan inte verifieras på grund av att certifikatspubliceringstjänsten inte kan nås

Syfte

Kontrollera felhanteringen i deltagarorganisations meddelandetjänst när publikt certifikat inte kan hämtas ifrån certifikatspubliceringstjänsten.

Teststeg

1. Förberedande: Konfigurera meddelandetjänstens SML zone för certifikatspubliceringstjänsten till en onåbar URL.
2. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen.
3. Deltagarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

1. Kvittenskod: REJECTED
2. Orsakskod: SIG
3. Detaljkod: security
4. Detaljtext: <beskrivning av problemet>
5. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.
6. Återställ: Konfigurera meddelandetjänstens SML zone för certifikatspubliceringstjänsten till korrekt URL.

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

Syfte

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

Teststeg

1. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen där signaturen inte är korrekt.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens med:

1. Kvittenskod: REJECTED
2. Orsakskod: SIG
3. Detaljkod: security
4. Detaljtext: <beskrivning av problemet>
5. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

Testfallet finns automatiserat i SDK testklient (skickar meddelande, kontrollerar meddelandekvittens).

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

Syfte

Kontrollera felhanteringen i deltagarorganisations 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. Skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen med en SDK nyttolast som är förvanskad efter kryptering men signerad på ett korrekt sätt.
2. Deltagarorganisationens meddelandetjänst ska inte generera meddelandekvittens, vilket resulterar i en timeout i SDK testklient .
3. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

SDK testklient saknar stöd, lämpligast att utföra som en del av interna utvecklingstester.

4.1.22 TF 2.6.7 - Felhantering av inkommande okrypterat meddelande

Syfte
Kontrollera felhanteringen i deltagarorganisations meddelandetjänst när meddelandets nyttolast är okrypterad.

Teststeg

1. Från SDK testklient, skicka ett meddelande adresserat till en funktion i den egna deltagarorganisationen med en SDK payload som är okrypterad och XHE attributet InstanceEncryptionIndicator satt till false.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens med:

1. Kvittenskod: REJECTED
2. Orsakskod: BV eller SIG
3. Detaljkod: security
4. Detaljtext: <beskrivning av problemet>
5. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

Testfallet finns automatiserat i SDK testklient (skickar meddelande, kontrollerar meddelandekvittens).

4.1.23 TF 2.7.1 - Felhantering - Utgående meddelande kan inte skickas till deltagarorganisation med utgånget O2O-certifikat

Syfte

Kontrollera felhanteringen i deltagarorganisationens meddelandetjänst när ett meddelande skickas till en organisation med utgånget O2O-certifikat.

Teststeg

1. Meddelandeklienten skickar ett meddelande via deltagarorganisationens meddelandetjänst till en organisation med utgånget O2O-certifikat (Organisation#3). Meddelandetjänsten upptäcker att mottagarens O2O-certifikat är utgånget.
2. Kontrollera hur meddelandestatus presenteras när meddelandet inte kan skickas.
3. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

4.1.24 TF 2.7.2 - Felhantering - Utgående meddelande kan inte skickas till deltagarorganisation med felaktigt AS4-certifikat

Syfte

Kontrollera felhanteringen i deltagarorganisationens meddelandetjänst när ett meddelande skickas till en organisation med en accesspunkt som använder ett felaktigt, utgånget, AS4-certifikat.

Teststeg

1. Meddelandeklienten skickar ett meddelande via deltagarorganisationens meddelandetjänst till en organisation med ett felaktigt AS4-certifikat (Organisation#4). Accesspunkten upptäcker att mottagarens AS4-certifikat är felaktigt.
2. Kontrollera hur meddelandestatus presenteras när meddelandet inte kan skickas.
3. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

4.1.25 TF 2.7.3 - Felhantering - Utgående meddelande kan inte skickas till deltagare med utgånget TLS-certifikat

Syfte

Kontrollera felhanteringen i deltagarorganisationens meddelandetjänst när ett meddelande skickas till en organisation med en accesspunkt som använder ett utgånget TLS-certifikat (endpointURI i SMP pekar på expired.badssl.com ).

Teststeg

1. Meddelandeklienten skickar ett meddelande via deltagarorganisationens meddelandetjänst till en organisation med utgånget TLS-certifikat (Organisation#5). Accesspunkten upptäcker att mottagarens TLS-certifikat är revokerat.
2. Kontrollera hur meddelandestatus presenteras när meddelandet inte kan skickas.
3. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

4.1.26 TF 2.7.4 - Felhantering - Utgående meddelande kan inte skickas till deltagare med felaktig CA i TLS-certifikatet

Syfte

Kontrollera felhanteringen i deltagarorganisationens meddelandetjänst när ett meddelande skickas till en organisation med en accesspunkt som använder en felaktig CA i TLS-certifikatet (endpointURI i SMP pekar på untrusted-root.badssl.com).

Teststeg

1. Meddelandeklienten skickar ett meddelande via deltagarorganisationens meddelandetjänst till en organisation med utgånget TLS-certifikat (Organisation#6). Accesspunkten upptäcker att mottagarens TLS-certifikat är revokerat.
2. Kontrollera hur meddelandestatus presenteras när meddelandet inte kan skickas.
3. Kontrollera att loggarna stämmer och är följsamma till SDK:s krav på spårbarhet. Se regelverk för deltagarorganisationer.

4.2 Meddelandetjänst (meddelandelagret)

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

Syfte

Kontrollera hur deltagarorganisationens meddelandeklient hanterar ett inkommande meddelande med enbart de element som är obligatoriska, dvs inga frivilliga element inkluderas, enligt innehållsspecifikation – Meddelande. Se Innehållsspecifikation – Meddelande.

Teststeg

1. Från SDK testklient, skicka ett meddelande (minimal) adresserat till en funktion i den egna deltagarorganisationen.
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.

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

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

Syfte
Kontrollera hur deltagarorganisationens meddelandeklient hanterar ett inkommande meddelande där samtliga frivilliga element inkluderas enligt innehållsspecifikation – Meddelande, se Innehållsspecifikation – Meddelande. Meddelandet innehåller flera bilagor och den totala storleken på meddelandet är strax under 30 MB.

Teststeg

1. Från SDK testklient, skicka ett meddelande (maximal) adresserat till en funktion i den egna deltagarorganisationen.
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.

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

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

Syfte

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

Teststeg

1. Från SDK testklient, skicka ett sekretessmarkerat meddelande adresserat till en funktion i den egna deltagarorganisationen.
2. Användare av meddelandeklienten tar del av meddelandet på ett korrekt sätt och det syns tydligt att meddelandet är sekretessmarkerat.

4.2.4 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. Från SDK testklient, skicka ett meddelande (fråga) adresserat till en funktion i den egna deltagarorganisationen.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens.
3. Användare av meddelandeklienten tar del av mottaget meddelandet på ett korrekt sätt.
4. Användare av 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 i SDK testklient att den skickade frågan och det mottagna svaret presenteras i samma konversation.
7. Kontrollera att meddelandeklienten tagit emot en meddelandekvittens för det skickade svaret.

Testfallet finns automatiserat i SDK testklient; skickar meddelande (1), kontrollerar meddelandekvittens (2), kontrollerar svar (5 och 6), samt skickar meddelandekvittens på svar (7). Användaren behöver i steg 4 skicka ett svar på meddelandet som skickades i steg 1 från egen systemlösning.

4.2.5 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. Användare av meddelandeklienten skickar ett meddelande (fråga) via deltagarorganisationens meddelandeklient till SDK testklient.
2. SDK testklient tar emot meddelandet.
3. Besvara det senast mottagna meddelande i SDK testklient.
4. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens på det mottagna svaret.
5. Användare av meddelandeklienten tar del av svaret på ett korrekt sätt.
6. Kontrollera i meddelandeklienten att den skickade frågan och det mottagna svaret presenteras i samma konversation.
7. Kontrollera att SDK testklient tagit emot en meddelandekvittens på det skickade svaret.

4.2.6 TF 3.2.3 - Meddelandeklienten tar emot svar på svaret

Syfte

Kontrollera att meddelandeklienten kan ta emot “svar på svar” på ett korrekt sätt inom en konversation.

Teststeg

1. Genomför TF 3.2.1, meddelandeklienten tar emot fråga och skickar svar inom samma konversation.
2. Från SDK testklient, skicka ett meddelande i samma konversation (“svar på svar”).
3. Användare av meddelandeklienten tar del av svaret (“svar på svar”) på ett korrekt sätt.
4. Kontrollera i SDK testklient att skickade frågan, mottagna svaret och skickade “svar på svar” presenteras i samma konversation.
5. Kontrollera i meddelandeklienten att mottagna frågan, skickade svaret och mottagna “svar på svar” presenteras i samma konversation.

4.2.7 TF 3.2.4 - Meddelandeklienten skickar svar på svaret

Syfte

Kontrollera att meddelandeklienten kan skicka “svar på svar” på ett korrekt sätt inom en konversation.

Teststeg

1. Genomför TF 3.2.2 (meddelandeklienten skickar fråga och tar emot svar inom samma konversation).
2. Användare av meddelandeklienten skickar ett meddelande i samma konversation (“svar på svar”) via deltagarorganisationens meddelandeklient till SDK testklient.
3. SDK testklient tar emot meddelandet.
4. Kontrollera i SDK testklient att mottagna frågan, skickade svaret och mottagna “svar på svar” presenteras i samma konversation.
5. Kontrollera i meddelandeklienten att skickade frågan, mottagna svaret och skickade “svar på svar” presenteras i samma konversation.

4.2.8 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. Användare av meddelandeklienten skickar ett meddelande (fråga) via deltagarorganisationens meddelandeklient till SDK testklient.
2. SDK testklient tar emot meddelandet.
3. Användare av 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 i SDK testklient att mottagna frågan och mottagna kompletteringen presenteras i samma konversation.
6. Kontrollera att meddelandeklienten tagit emot en meddelandekvittens på den skickade kompletteringen.

4.2.9 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. Från SDK testklient, skicka ett meddelande (fråga) adresserat till en funktion i den egna deltagarorganisationen.
2. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens.
3. Från SDK testklient, komplettera genom att använda kompletterafunktionen på det tidigare skickade meddelande i SDK testklient.
4. Deltagarorganisationens meddelandetjänst genererar automatiskt en meddelandekvittens på den mottagna kompletteringen.
5. Användare av meddelandeklienten tar del av kompletteringen på ett korrekt sätt.

1. Kontrollera i meddelandeklienten att mottagna frågan och mottagna kompletteringen presenteras i samma konversation.
2. Kontrollera att SDK testklient tagit emot en meddelandekvittens på den skickade kompletteringen.

5 Övriga tester

Federationsägare förbehåller sig rätten att i samband med granskning av inlämnat testprotokoll begära att få genomföra ett eller flera testfall på nytt tillsammans med ansvarig testare för meddelandesystemet.