Introduktion

...

• Hver testcase er implementeret som en metode i den relevante testklasse
• Testcasen er navngivet, så det tydeligt fremgår, hvad formålet med testen er
• Kommentarer i testcasen inddeler tydeligt i præcondition (Given), udførsel (When), tjek (Then) som beskrevet f.eks. Martin Fowler: Given-When-Then

Unittests er implementeret vha JUnit og kan eksekveres af Mavens standard testplugin SureFire.

...

Det kræves at følgende properties angives ved afvikling af integrationstesten

For nemheds skyld er der angivet følgende profiler (kan angives med -P), med variabeldefinitioner for et givent miljø

F.eks.

mvn -Pdevelopment test

Testrapporter kan genereres i HTML med kommandoer:   mvn surefire-report:report; mvn site -DgenerateReports=false

...

Testen deles op i to dele. En del hvor der verificeres at notifikationer ikke går tabt og det er de rigtige notifkationer der leveres til de enkelte pull points. Den anden del er en verifikation ved hjælp af en integrationstest. Den test har til formål at verificere at det er muligt at udføre alle de user stories der er beskrevet i afsnit 3.1. 

Verifikations test

...

Verifikationstesten har til formål at :

• bevise at der ikke går notifikationer tabt

...

• .
• det er de rigtige notifikationer der

...

• leveres til de enkelte pull points når systemet belastes med mange notifikationer. 
• sikre robusthed ved belastning
• leverancesikkerhed as adviser i forhold til publish/subscribe ved belastning

I NAS2 projektet er der udviklet et selvstændigt program der kan kalde de forskellige services. Udfra en input fil kan det styres hvilke subscriptions, id lister osv. der skal oprettes samt hvor mange notifikationer der skal sendes. Programmet logger også hvilke adviser der er sendt samt hvilke der er hentet ud via pull point servicen. . 

Aflevering af adviser

Aflevering af adviser sker med tanke på at få verificeret at adviser kan afleveres til NAS2 uden at der returneres fejl. 

Nedenstående beskriver mønstret på de adviser der afleveres til NAS2. Der afleveres et total på 5000 adviser. Inden programmet til at aflevere adviser afvikles skal relevante topics være oprettet samt subscriptions osv. skal være oprettet. Det vil sige dem som FMK anvender. Disse Inden FMK afvikler deres performance test skal de oplyse hvilke topics der sendes notifikationer på. Disse er dokumenteret på https://wiki.fmk.netic.dk/doku.php?id=fmk:advis:topic.

Fra NAS' side udvikles der et selvstændigt program med nedenstående egenskaber. 

Ovenstående vil teste alle muligheder i form af af at der kun sendes et advis pr id, mange adviser pr id, der leveres til forskellige topics og der veksles mellem forskelligt indhold i adviserne. 

Afhentning af adviser

Afhentning af adviser sker med tanke på at få verificeret nedenstående.

1. At alle adviser der er afleveret også kan hentes via pull point. Det sker ved oprettelse af pull points og subscriptions uden ID-lister. 
2. At der kun retureneres de adviser der svarer til den ID-liste der er til en subscription. Det sker ved at der oprettes en række pull points med hver deres ID-liste.
3. At der kan returneres adviser fra forskellige topics på det samme pull point.
4. At adviser ikke forvanskes i NAS2. Dette sker ved sammenligning af det afsendte advis med det modtagne advis. 

For at understøtte ovenstående skal der oprettes følgende pull points og subscriptions. 

Program til understøttelse af ovenstående

I nas udvikles der et program der understøtter ovenstående krav. Det vil sige at det skal have nedenstående funktionalitet. 

1. Programmet skal generere en liste med ID'er der skal anvendes når NotificationBroker kaldes. 
2. Programmet skal kalde NotificationBroker med de ID'er der er genereret i step 1. Topic og indhold skal være det som beskrevet under aflevering af adviser. 
3. Programmet skal oprette pull points svarende til Programmet skal oprette pull points svarende til det antal topics der er. Der skal oprettes en subscription på hvert topic og der skal ikke være nogen ID liste tilknyttet. 
4. Programmet skal oprette X pull points for hvert topic. For hvert af disse pull points skal der oprettes en subscription med en tilhørende ID liste. Hver enkelt ID listerne skal ikke have nogle ID'er tilknyttet.  Programmet skal have mulighed for at opdatere en eksisterende ID listeliste skal indeholde et subset af de ID'er der er anvendt i forbindelse med aflevering af adviser. 
5. Programmet skal kalde GetMessages på de pull points der er oprettet indtil der ikke er flere beskeder. Hver besked skal logges til en fil. 
6. Det skal være muligt at afvikle ovenstående 3 5 steps selvstændigt. 

Step 1 og 2 skal afvikles inden FMK må gennemføre deres test. Efter step 3 er afviklet og alle beskeder er hentet skal nedenstående udføres. 

...

Når ovenstående er udført skal de loggede data sammenlignes så det verificeres at der ikke er gået beskeder tabt, at det er de rigtige adviser der er leveret til de oprettede pull points og at indholdet af adviserne ikke er forvansket. Det sker ved at sammenligne de beskeder der er afleveret til NotificationBroker samt de beskeder der er hentet ud ved kald til GetMessages servicen. 

NAS integrationstest

For verifikation af at det er muligt at udføre de enkelte user stories er der oprettet en integrations test der hedder NasAnvenderScenarieTest. Denne test udfører nedenstående. Testen afvikles når integrationstesten afvikles mod NAS systemet.

...

Nedenstående tidsplan tager udgangspunkt i at NS2 er klar i test2 miljøet i uge 38. Hvis NAS2 ikke er tilgængelig i test2 miljøet skubbes tidsplanen tilsvarende. 

Funktionstest - Gammel udgave

...

1. Oprettelse og/eller opdatering af ID liste.
   mvn -Pverification -Dverification.mode=idlist -Dverification.idlist.endpoint=http://localhost:8090/idlist -Dverification.input=/path/to/file/idlist.txt
   Indholdet i verification.input filen skal være som nedenstående. 
   /*
   * Id list filen den skal være formateret som nedenstående.
   *
   * navn:idliste_navn:id_type
   * id:id_no_1
   * id:id_no_2
   * navn:en_anden_liste
   * id:id_no_4
   * id:id_no_5
   */
2. Oprettelse af pull point og subscription.
   mvn -Pverification -Dverification.mode=subscribe -Dverification.subscriptionmanager.endpoint=http://localhost:8090/subscriptionmanager -Dverification.pullpointfactory.endpoint=http://localhost:8090/pullpointfactory -Dverification.input=/path/to/input/subscription.txt -Dverification.output=/path/to/output/subscription_output.txt
   Indholdet i verification.input skal være som nedenstående. Output filen indeholder liste med pull point id'er. 
   /**
   * Input filen skal være formateret som nedenstående
   * subid:topic:id_liste_navn
   *
   * Id liste navn er optional og hvis det er udeladt oprettes der en subscription uden tilknyttet id liste.
   */
3. Aflevering af adviser. 
   mvn -Pverification -Dverification.mode=notify -Dverification.input=/home/jonas/input.txt -Dverification.notificationbroker.endpoint=http://localhost:8090/notificationbroker
4. Afhentning af adviseringer. 
   mvn -Pverification -Dverification.mode=getmessages -Dverification.pullpoint.endpoint=http://localhost:8090/pullpoint -Dverification.input=/path/to/input/pullpoint.txt -Dverification.output=/path/to/output/pullpoint_output.txt
5. Indholdet i verification.input være et pull point id pr. linie. Output filen indeholder en linie pr afhentet advisering med ID og pull point id. 
   
   

...