Test Case Development

VI.4.1.1 Abstract Test Suite

The abstract test case consists of a test assertion, test procedure and test environment. The test assertion is developed from requirements in the standard specification. In the information mapping test, the objective is to verify whether a target message is semantically same with the predefined BOD instance, which is derived from the schema in the OAGIS-AIAG Kanban specification. Therefore, the BOD instance itself can be considered as a requirement. Figure VI-5 is a sample test assertion for the information mapping test. It is developed for a specific BOD instance (IMT_NIST_SSS_001.xml) and has two Cause/Effect forms for input and output tests. In the RAMP messaging test, requirements are described in a profile document. Figure VI-6 is a test assertion for ‘R1010’ requirement in the RAMP specification. R1010 is triggered when the message contains ‘wsrm:Sequence’ and then checks whether header block has ‘SOAP:mustUnderstand’.

Figure VI-5 Sample of test assertion for Information Mapping Test

Figure VI-6 Sample of test assertion for R1010 requirement in the RAMP test

We implement a conformance testing for the IV&I scenario, so that we need two test procedures: for customer and supplier parties. Figure VI-7 is a test procedure for the IV&I customer. It is processed simultaneously with both the information mapping test and the RAMP messaging test. In the information mapping test, the output test is executed, so that the testbed should send a initiate message to the customer with SyncShipmentSchedule information, which will be sent by the customer. The test assertion for the information mapping test is executed when this SyncShipmentSchedule message is arrived. In the RAMP messaging test, the IV&I testbed simulates the supplier role. Whenever a message is arrived from the customer, the IV&I testbed executes test assertions related with requirements with the RAMP profile.

Figure VI-7 Test procedure for IV&I Customer

Figure VI-8 is a test procedure for the IV&I supplier. It is also processed simultaneously with both the information mapping test and the RAMP messaging test. The input test is executed for the information mapping test. After the testbed sends the syncShipmentSchedule message, the testbed should verify that the supplier receives, parses and transforms it into a proprietary data format. For the RAMP messaging test, the IV&I testbed simulates the customer role. Whenever a message is arrived from the supplier, the IV&I testbed executes test assertions related with requirements with the RAMP profile.

Figure VI-8 Test procedure for IV&I Supplier

Figure VI-9 shows a test environment for the IV&I scenarios. The customer and the supplier are involved as target SUTs. Each application has several services according to the scenario. For the information mapping test, the customer should have an ‘initiate’ service. The testbed can receive and response any kind of messages if it is defined at the test case.

Figure VI-9 Test Environment for IV&I Scenario ７０

VI.4.1.2 Executable Test Suite

The testing engineer should develop the executable test cases on the basis of the abstract test cases. ATF proposed to use the ETSL test script as the executable test case. Figure VI-10 is a part of an ETSL test case to verify the supplier. In this script, the testbed sends a ‘createSequence’ message to the SUT at step 1. Next after 2 seconds, step 3 retrieves the ‘createSequenceResponse’ message from the message store that is an internal data store of the testbed. From step 5, relevant test assertions are executed to verify the ‘createSequenceResponse’ message.

<monitor label="VerifySupplier">

<!--========== step 1: send the CreateSequence message-->

<call adapter="kr.ac.postech.korbit.ramptb.transport.SimpleSOAPTransport" step="step1" type="event"> <param arg="1">

<template document="createSequence.xml"> <set value="UUID();" var="CS_MessageId" /> <set value="TBIP();" var="From" /> <set value="TargetIP();" var="To" /> </template>

</param> </call>

<!-- ========== step 2: wating for the CreatResponse message--> <sleep duration="2" step="step2" />

<!--========== step 3: retrieve CreatResponse message from Events Board--> <find get="last" step="step3">

<selector> <ns prefix="SOAP">http://schemas.xmlsoap.org/soap/envelope/</ns> <ns prefix="wsa">http://schemas.xmlsoap.org/ws/2004/08/addressing</ns> <ns prefix="wsrm">http://schemas.xmlsoap.org/ws/2005/02/rm/</ns> <ns prefix="xsd">http://www.w3.org/2001/XMLSchema</ns> <ns prefix="xsi">http://www.w3.org/2001/XMLSchema-instance</ns> <xpath>Events/event/content/SOAP:Envelope[SOAP:Header/wsa:RelatesTo='%CS_MessageId%']</xpath> </selector> </find>

<!--========== step 4: Store Sequence Identifier in the CreatResponse message-->

<set step="step4" value="$output/SOAP:Envelope/SOAP:Body/wsrm:CreateSequenceResponse/wsrm:Identifier" var="Identifier"> <ns prefix="SOAP">http://schemas.xmlsoap.org/soap/envelope/</ns> <ns prefix="wsa">http://schemas.xmlsoap.org/ws/2004/08/addressing</ns> <ns prefix="wsrm">http://schemas.xmlsoap.org/ws/2005/02/rm/</ns> <ns prefix="xsd">http://www.w3.org/2001/XMLSchema</ns> <ns prefix="xsi">http://www.w3.org/2001/XMLSchema-instance</ns> </set>

<!-- ========== step 5: Test Assertion [R3002] --> <cad step="step4"> <ns prefix="SOAP">http://schemas.xmlsoap.org/soap/envelope/</ns> <ns prefix="wsa">http://schemas.xmlsoap.org/ws/2004/08/addressing</ns> <ns prefix="wsrm">http://schemas.xmlsoap.org/ws/2005/02/rm/</ns> <ns prefix="xsd">http://www.w3.org/2001/XMLSchema</ns> <ns prefix="xsi">http://www.w3.org/2001/XMLSchema-instance</ns> <condition>output/SOAP:Envelope</condition> <do>

<post evtype="verifyMessage" step="step8"> <evproperties>

<property name="result">Success</property> <property name="req_Id">[R3002]</property>

<property name="description">SOAP:Envelope is basic packaging</property> </evproperties>

<content>Supplier's CreateResponse Message is satisfied [R3002]</content> <!-- other evt attributes automatically set -->

</post> </do> … </monitor>

Figure VI-10 A part of ETSL test case to verify supplier