Medio ambiente - Informe de calidad de vida de Medellín, 2010

13 Schematron, http://www.schematron.com/ 14 JESS, http://herzberg.ca.sandia.gov/jess/ ３６

IV.4.1.1 Test Main Component (TMC)

The test main component (TMC) is the underpinning to the proposed test execution model and stationary over various types of testings. Briefly, TMC dynamically constructs a testbed according to a test-specific configuration profile referenced by the abstract test case given, and uniformly controls the overall procedure of any testings by executing an executable test case. The test configuration engine (TCE) and the test sequence engine (TSE) are responsible for undertaking these respective roles. We adopt the concepts of component- and service-orientation to design a reconfigurable and loosely coupled testbed. TCE is the key enabler to this approach, in that it is responsible for finding and composing necessary test interfaces to configure a testbed. The configuration process is a series of interpretation, discovery, and binding. In the interpretation step, TCE reads the configuration profile extracted from the abstract test case. Figure IV-2 demonstrates a fragment of a sample configuration profile encapsulated in an exemplary executable test suite. This information is assumed to be available via a public UDDI15 registry. The binding information to discover the instances of test interfaces associated with the configuration information is also available via the registry. The figure below, for example, illustrates that a TVI is defined by an XPATH validation instance and its service is accessible via the URL http://localhost/testbed/verifier/xpath specified in overviewURL.

<?xml version="1.0" encoding="UTF-8"?> < ExecutableTC >

<name>Test Validation Interface-XPATH</name>

<description xml:lang="en">The interface definition of the XPATH verifier</description> <overviewDoc>

<description xml:lang="en">XPATH verifier for ATF Test Validation Interface</description> <overviewURL>http://localhost/testbed/verifier/xpath</overviewURL>

</overviewDoc> <categoryBag>

</tModel>

<businessEntity businessKey=""> …

</businessEntity>

<businessService serviceKey="" businessKey="00EB06FC-3C45-42B8-B394-1F7F35602B2E"> …

</businessService> </uddi-entity> </Interface>

<Interface name="MessageEngine" id="me004"> …

</Interface>

Figure IV-2 Part of exemplary configuration information in an abstract test suite

Universal Description, Discovery and Integration (UDDI), http://www.uddi.org/ ３７

The discovery step is a matchmaking process between tModel entities in the configuration profile and the UDDI registry, and further between businessService entities in both. To do that, TCE plays the role of a UDDI client that searches the UDDI registry for appropriate interface instances having matched key-values (e.g., businessKey) of businessService and tModel entities. For each discovered interface instance, TCE will further inquire about its details through a series of follow-up queries. The final output is the URL of the WSDL16 that describes the interface instance. Figure IV-3 gives a sample code to retrieve a tModel key from a list of properties of the XPATH validation instance. Executing this code creates a tModelBag structure, which is an unordered collection of tModels. Then, TCE sorts out the tModels matched to those in the configuration profile.

TModelBag tmb = new TModelBag(); TModelKey tmk = new TModelKey();

File testFile = new File("XPATH_Verifier.properties"); if (testFile.exists()){

FileInputStream propStream = new FileInputStream(testFile); props.load(propStream);

propStream.close(); }

tmk.setText(props.getProperty("TModelKey"); Vector tModelKeys = newVector();

tModelKeys.add(tmk);

tmb.setTModelKeyVector(tModelKeys);

Figure IV-3 Sample code to retrieve a key value from XPATH validation properties

After that, TCE retrieves a list of all the BusinessService objects referenced by the matched tModels. Under an assumption of correct matchmaking, TCE takes the first businessService object, finds its bindingTemplates, and accordingly gets the corresponding WSDL URL. This process is implemented as shown in Figure IV-4.

ServiceList sl = proxy.find_service("", null, null, tmb, null, 0); Vector serviceInfoVector = sl.getServiceInfos().getServiceInfoVector();

String serviceKey = ((ServiceInfo)(serviceInfoVector. elementAt(0)).getServiceKey(); BindingDetail bd = proxy.find_binding(null, serviceKey, tmb, 0);

Vector bindingTemplates = bd.getBindingTemplateVector();

BindingTemplate bt = (BindingTemplate)bindingTemplates.elementAt(0); AccessPoint ap = bt.getAccessPoint();

Vector tModels = bt.getTModelInstanceDetails().getTModelInstanceInfoVector(); TModelInstanceInfo tmii = (TModelInstanceInfo)tModels.elementAt(0); InstanceDetails id = tmii.getInstanceDetails();

OverviewDoc od = id.getOverviewDoc(); OverviewURL ou = od.getOverviewURL();

Figure IV-4 Code to retrieve the key value of the WSDL URL

To compose a testbed using the discovered instances of test interfaces, we specify those instances and their invocation order in a process mode. For a demonstration purpose, we use WS-BPEL, which is a

Web Services Description Language (WSDL) 1.1, http://www.w3.org/TR/wsdl ３８

practical implementation of web services orchestration. The use of WS-BPEL is two folds: 1) to set up a dynamic and reconfigurable testbed and 2) to execute tests. The first use to configure a testbed is clear, in that the core part of a testbed is an organized package of various test interfaces. As discussed, TMC plays the supervisory role to manage other test-specific interface instances and to invoke them as specified in the test case. WS-BPEL is capable of capturing such test interface instances and their relationships, i.e., invocation order, necessary to form a testbed. The second use of test execution is a distinguished feature of the proposed approach. Unlike existing test frameworks that are dependent on a strict and fixed design of test suites, the proposed framework can flexibly use various types of test suites with proper support of an interpreter. In the dissertation, we will show the way to use a WS- BPEL as an internal process language. Executing a test case is a sequence of test step executions such as message sending, message receiving, and message validation. Such a test step execution is indeed an invocation of an associated test interface instance. For example, sending and receiving a message is invoking an MEI instance, and validating a message is invoking a TVI instance. In the same way, reporting test results means invoking an appropriate TUI instance.

The procedure to create a configuration profile is basically same as the way to define a WS-BPEL instance, as follows:

1) Specify test interface instances to be plugged in TMC; 2) Specify input and output messages for each instance;

3) Relate the communication and invocation orders between TMC and interface instances; and 4) Additionally, set fault and event handlers.

In the first step, the test components and test interface instances are declared using the partnerLink element. Named partners are defined, each of which is characterized by the partnerLinkType in the WSDL. Additionally, myRole and partnerRole attributes indicate roles the orchestration and the partners will play, respectively. The second step lists variables (i.e., variable) used to specify input and output messages for each instance. In this step, correlations, if any available, are optionally stated to designate alternative messages for each message. The third and most important step specifies activities (using receive, invoke, reply, etc) and their sequence (using sequence, switch, while, pick and flow). The configuration may also have error-handling and roll-back mechanisms (i.e., faultsHandler, compensationHandler).

Figure IV-5, for example, demonstrates a fragmentation of a sample testbed configuration profile (or an executable test case). The testbed has three interface instances (i.e., messaging engine, validation engine, and report engine) and consists of ordered activities of receiving a SOAP message from an SUT (i.e., invoke Message_engine – Receive operation), validating the message (i.e. invoke Validation_engine – Validation operation), and composing a report (i.e., invoke Report_engine – Report operation). Note that TMC is used as the orchestral conductor for this configuration. TSE interprets this WS-BPEL test case and executes each invoke activity by calling an action in the test service.

<?xml version="1.0" encoding="UTF-8"?> <process …namespaces…>

<invoke partnerLink="Messaging_engine" operation="Receive" … /> <invoke partnerLink="Validation_engine"

portType="ValidateTestMessagePT" operation="Validation"

inputVariable="valdationRule" outputVariable="TestResult" />

</sequence> </process>

Figure IV-5 Part of exemplary internal process script as WS-BPEL

IV.4.1.2 Test Service

The test service plays the role of an event handler both in the testbed and in the SUT that coordinates every incoming and outgoing message. A test service is defined by a set of actions, which include both pre-defined actions (for common events) and user-defined actions (for test/SUT-specific events). An action corresponds with an executable test step. Once again, ATF provides 9 primary actions as follows:

- START action starts a new test process, either synchronously to the current process or asynchronously.

- WAIT action makes the current test process suspended until a specified date/time or for specified duration.

- JUMP action pursues the execution thread at a (labeled) step in the process. - EXIT action terminates the current process.

- POST action generates a log message and posts it on an internal persistent message store. - FIND action selects data in the internal persistent message store.

- SET action assigns a value or data to a variable or to a constant. For unused variables or constants, the action automatically declares and allocates a default value.

- CAD (check-and-do) action verifies a predicate on the result of one or more previous steps, does a single action in the case of positive verification, and then possibly branches to another labeled step.

- CALL action invokes either an instance or an external service. This action uses one or more input data as argument(s) and one output data as a return.

IV.4.1.3 Interpreter

Given an executable test case and abstract test case, the interpreter separates it into configuration information, a test procedure, and test assertions. As described earlier, the configuration information captures only the necessary test interfaces, in UDDI data structure, to form a testbed. Later, the configuration information is represented in a process model, WS-BPEL for example, with discovered

test interface instances and their invocation orders. The test procedure describes various possible sequences of test steps from initiation to termination. Last, a test assertion is a predicate (i.e., a true- false statement) placed in the SUT to indicate whether or not a test requirement is always true in a given domain. A combination of a test sequence and test assertions forms an executable test case.

In document Informe de calidad de vida de Medellín, 2010 (página 53-60)