Funktionella tester
Syftet med de funktionella testerna är att verifiera reglerna i tjänstekontraktet Engagemangsindex. Testerna är implementerade i ett SOAP-UI projekt. Testerna dokumenteras endast i SOAP-UI projektet.
Begränsningar
Det finns inte automatiserade tester för att verifiera att notfieringar skickas korrekt efter uppdateringar med Update och ProcessNotification. Detta steg måste göras manuellt enligt instruktionerna nedan.
Instruktioner för att genomföra testerna
Förberedelser
För att kunna köra både request och tester behöver man anpassa miljön för om man ska köra testerna mot utvecklingsmiljön (MuleStudio) eller mot exempelvis QA-miljön:
- Hämta SoapUI-projektet med namnet SKLTP-EI-soapui-project.xml
- HSA-ID. I projektinställningarna ("Custom properties") finna möjligheten att välja HSA_ID_QA och HSA_ID_DEV för inställningen HSA_ID.
- Endpoints. För varje tjänst behöver man uppdatera vilken endpoints som ska användas. I och med att testerna återanvänder alla tre tjänster behöver således uppdatera endpointen för alla tre tjänster.
Exempel på metod för att välja QA som endpoint:
Dubbelklicka på UpdateResponderBinding, välj "Service Endpoints".
Välj "https://qa.esb.ntjp.sjunet.org:20000/vp/Update/1/rivtabp21" och tryck knappen "Assign.".
Välj alternativet "All requests och TestRequests" och tryck på ok. - Upprepa detta för FindContentWSBeanServiceSoapBinding samt ProcessNotificationResponderBinding.
Köra tester
Nu är det klart att köra testerna. Testerna kan köras en och en eller alla.
För att köra alla test, högerklicka på projektet (SKLTP-EI) -> Launch Testrunner. Välj "All" i TestCase och TestSuite.
Tryck sedan till sist på "Launch".
Manuella Tester
Test EI.1: Verifiera att ProcessNotification fungerar vid Update
Verifiera att Process Notification anropas vid Update. Än så länge finns det inte funktionalitet på plats för
att göra det automatiskt. Så nu blir man tvungen att göra det manuellt genom att kolla på loggar. Beskrivningen
beskriver stegen att göra det i QA men det går att göra i test respektive utvecklingsmiljön. Det viktiga är att det finns
åtminstone 1 aktiv subsciber.
- Verifiera att finns åtminstone en aktiv subscriber. Görs enklast genom att kolla i admingränssnittet i ActiveMQ.
- Logga in på en qa-noden som mule-användaren. Gå till logg-katalogen (/home/mule/tp/mule-enterprise-standalone-3.3.1/logs)
- tail -f mule-app-ei.log
- Gör ett Update-anrop med SoapUI. Förslagsvis körs testet "Update - OK - valid request"
Om testet gått igenom, kolla att det finns en msg-in, req-out samt en resp-in för en subsciber. Exempel på en hel logg från process-steget:
Test EI.2: Verifiera att ProcessNotification anrops vid ProcessNotification
Detta test är i princip samma som för beskrivningen för Update förutom att man gör ett testanrop med
ett ProcessNotification-test istället. Testet ProcessNotification - OK - valid request är ett lämpligt val.
Dokumentation av testresultat
Det ska dokumenteras att testerna utförts samt på vilken mjukvaruversion man kört dem. Fyll i denna tabellen och spara den under EI Testrapporter.
AUTOMATISERADE TESTER
Datum | EI version | VP version | Alla / Vissa tester utförda | Tester utförda av | Resultat |
|---|---|---|---|---|---|
| Kommentar: | <eventuellt någon kommentar om resultatet> |
|---|
MANUELLA TESTER
Datum | EI version | VP version | Tester utförda av |
|---|---|---|---|
Test | Resultat | Kommentar |
|---|---|---|
| Test EI.1 | ||
| Test EI.2 |
EI-Filter testfall
Sätta upp en ProcessNotification producent med netcat
Netcat på port 2345
echo -e "HTTP/1.1 200 OK\n\n $(cat processnotification-response.xml)" | nc -l 2345
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header/>
<soap:Body>
<ns2:ProcessNotificationResponse xmlns="urn:riv:itintegration:engagementindex:1" xmlns:ns2="urn:riv:itintegration:engagementindex:ProcessNotificationResponder:1" xmlns:ns3="urn:riv:itintegration:registry:1">
<ns2:ResultCode>OK</ns2:ResultCode>
</ns2:ProcessNotificationResponse>
</soap:Body>
</soap:Envelope>
Sätta upp testdata i TAK
Testproducent
Testproducent som pekar på porten exponerad av netcat, beskrivet ovan.
HSA-ID: NETCAT
Adress: http://localhost:2345
Beskrivning NETCAT testproducent
Logisk adressat
HSA-ID: NETCAT
Beskrivning: En logisk adress som används för tester mot en ändpunkt exponerad av NETCAT
Logisk adress
Anropsbehörighet
Exempel konsument, sätt korrekt för testerna som skall utföras
För varje ändring av filter krävs:
1, Uppdatera i TAK
2, Reset cache i VP
3, Starta om EI (touch på mule.xml i backend)
Testfall: Inga filter definierade
| Filter i TAK | Testdata i Update | ||
|---|---|---|---|
| Subscriber1 | har inget filter definierat | Skall få en notifiering | Servicedomain: TEST-DOMAIN1 |
Testfall: Filter som matchar
| Testdata i Update | |||
|---|---|---|---|
| Subscriber1 | ett filter definierat med domän: TEST-DOMAIN1 | Skall få en notifiering | Servicedomain: TEST-DOMAIN1 |
Testfall: Filter som inte matchar
| Testdata i Update | |||
|---|---|---|---|
| Subscriber1 | ett filter definierat med domän: TEST-DOMAIN-UNKNOWN | Skall inte få en notifiering | Servicedomain: TEST-DOMAIN1 |
Testfall: Filter och kategori som matchar
| Testdata i Update | |||
|---|---|---|---|
| Subscriber1 | ett filter definierat med domän: TEST-DOMAIN1, Category: TEST-CATEGORY1, TEST-CATEGORY2 | Skall få en notifiering | Servicedomain: TEST-DOMAIN1, Category: TEST-CATEGORY1 |
Testfall: Kategorier matchar inte
| Testdata i Update | |||
|---|---|---|---|
| Subscriber1 | ett filter definierat med domän: TEST-DOMAIN1, Category: TEST-CATEGORY-UNKNOWN | Skall inte få en notifiering | Servicedomain: TEST-DOMAIN1, Category: TEST-CATEGORY1 |
Testfall: Flera engagemangsposter, varav ett filtreras bort
| Testdata | |||
|---|---|---|---|
| Subscriber1 | ett filter definierat med domän: TEST-DOMAIN1 | Skall få en notifiering | 2 engagemangsposter med TEST-DOMAIN1 och TEST-DOMAIN-UNKNOWN |