IV. EXECUTION MODEL FOR AGILE TESTING
IV.5.2 Quality of Schema Design
The second test, namely a Quality of Schema Design (QoD) test, is to validate the design consistency of an XML schema document. The purpose of the QoD test is to ensure the XML schema compliance to organizational guidelines and best practices on design such as NDRs (Naming and Design Rules). The guideline includes design conventions and regulations to promote interoperability when an XML
schema is used to express and exchange data between enterprise applications. Each regulation could be implemented to a test assertion. In this QOD testbed, the validation rules are specified in different test script languages such as Schematron, JESS, and XPath. In short, Schematron is an XML representation of rules based on XPath/XSLT expressions; the XPath by itself is a procedural language, while JESS (Java Expert System Shell script) is a first order representation based on the CLIPS syntax. These languages have their own strengths. The Schematron and XPath being an XML native language makes it easier to encode validation rules against an XML schema, while JESS provides more expressivity due to the capability to embed native Java classes and methods.
The QoD testbed requires a simple test procedure to verify a schema document. The test execution procedure is identical as follows: 1) to upload an XML schema document into the QoD testbed, 2) to execute selected test assertions with the document, and consequently 3) to make a report. An abstract QoD test case includes a list of test assertions and a list of reference to necessary interface instances, but not a test sequence. Figure IV-9 (A) shows an abstract test case, which implements the design convention “do not use anonymous types” in the Schematron script and in the JESS script, respectively. The interpreter makes an internal process script in WS-BPEL as shown in Figure IV-9 (B). In addition to the necessary interface instances, the executable test case contains a list of references to the test assertions.
(A)
<?xml version="1.0" encoding="UTF-8"?> <QODTC>
<case id="#210201" type="Schematron">
<schema xmlns="http://www.ascc.net/xml/schematron"> <ns prefix="xs" uri="http://www.w3.org/2001/XMLSchema"/> <pattern name="OAGI-150: Check for improper use of anaymous type"> <rule context="xs:complexType | xs:simpleType">
<assert test="name(..)='xs:schema'">OAGI-150 [Anonymous Type]: > value-of select="@name"< element is locally typed within an element. It cannot be referenced outside of that element definition; hence, it cannot be reused.
</assert> </rule> </pattern> </schema> </case>
<case id="#102031" type="JESS"> ;OAGI-150
;Check for Anonymous types (deffunction isType (?x)
(if (or (str-index complexType ?x) (str-index simpleType ?x)) then (return TRUE) else (return FALSE) ) ) (defrule oagi-150
(element (id ?e-id) (name ?e-name &: (isType ?e-name))) (relation (type element) (parent ?p-id) (child ?e-id))
(element (id ?p-id) (name ?e-name2 &: (not (str-index schema ?e-name2)))) (relation (type attribute) (parent ?e-id) (child ?a-id))
(attribute (id ?a-id) (name name) (value ?a-val) (valuePrefix nil)) =<
(bind ?str (str-cat "" "OAGI-150 [Anonymous Type]: The '" ?a-val "' type is locally defined within an element. This is not recommended, since it cannot be referenced outside of that element definition; hence it cannot be reused."))
(printout t ?str crlf)
(call ?vt addElement (new java.lang.String ?str)) )
</case> </QODTC>
(B) <?xml version="1.0" encoding="UTF-8"?> <process …namespaces…> <partnetLinks> <partnerLink name="SchematronEngine" partnerLinkType="SchematronEngineLT" … /> </partnerLinks> <sequence> <Start/> <Find targetSchema=""…/> <Call operation="Upload" … /> <Set case = "#102031_assertion"> <Set case = "#102031_assertion"> <loof>
<switch … >
<case condition="getVariableProperty (validationRule, ruleType) = Schematron"> <Call partnerLink="SchematronEngine" operation="Validation" … /> </case>
<case condition="getVariableProperty (validationRule, ruleType) = Jess"> <Call partnerLink="JessEngine" … /> </case> <otherwise> <throw faultName="UnknownRuleType"/> <otherwise> </switch> </loof> <Report partnerLink="QOD_Report_Engine" … /> </sequence> </process>
Figure IV-9 (A) Sample QOD executable test cases and (B) Internal process script
The QoD testbed has two different types of TVI instances – a Schematron engine and a JESS engine. Note that in this case study we did not use the XPath validation engine. The QoD testbed also needs a TUI instance – a QoD result engine. Since the QoD test is not to test an application, it does not need an MEI instance to interact with the application. TCE is responsible for discovering these instances and composing them as a testbed. Figure IV-10 shows the QoD testbed. The QoD test service also uses the nine primary actions only. TSE selectively invokes either the Schematron engine or the JESS engine according to the representation type of a test assertion used. Finally, the QoD report engine summarizes the test results and reports it to the user. As shown in the figure below, the QoD testbed shares many test components and interface instances with the RAMP testbed. Therefore, a RAMP testbed developer can agilely implement the QoD testbed, vice versa, by reusing/reconfiguring existing test components (i.e., TMC, test service actions) and interface instances (e.g., XPath validation engine) with minor modifications and new additions, if required.
Figure IV-10 QOD Testbed Implementation
IV.6.
Chapter Summary
This chapter has shown a light-weighted reusable and reconfigurable testbed implemented on the base of the proposed agile execution model (AEM). AEM provides highly reusable modules and their interactions for rapidly forming a testbed. AEM consists of various test components and interfaces. The test components provide a testbed with the capstone and frames; while the test interfaces are building blocks embedded in the test components. Among them, the test main component (TMC) is the underpinning and independent of any tests. TMC has two important roles of testbed configuration and test execution management, for each of which the test configuration engine (TCE) and test sequence engine (TSE), respectively, are responsible. Other test components, i.e., a test service and an interpreter, may need minor modifications depending on the test type, even though their underlying structures and roles are invariant. In particular, we define nine primary actions for the test service. On the other hand, the test interfaces define high-level functionalities and requirements about their instances. In other words, one may implement a test interface in various ways. Important interfaces are a test validation interface (TVI), a messaging engine interface (MEI), and a test user interface (TUI). With help of the web service technologies, such as WSDL, UDDI, and WS-BPEL, we can flexibly use various interface instances on demand of testing. The case studies demonstrate that ATF versatile and agilely constructs testbeds: the RAMP conformance testbed is to ensure web service applications’ conformance to RAMP, while the QoD testbed is to check an XML schema document’s compliance to organizational guidelines and best practices on schema design.
Future works include building an intelligent test driver that can autonomously configure a testbed by
taking choreographies among test components and interface instances and then dynamically discovering and composing them. A precondition to this is that these components are described in a semantic rich manner. In addition, for more robust testing, we need to closely investigate the test suites and further regulate such standard message formats exchanged among test components.