Patent Application
20060150026
The present invention relates to a method and system for testing computer software. More specifically, the present invention is directed to a method and system for module testing of Web Service protocols.
The problem of writing error-free computer programs has plagued programmers since the very beginning. Sophisticated schemes for automatically discovering program errors and bugs of all kinds, including lexical, syntactic, semantic and logical, have been developed. However, these schemes have generally been directed to enforcing adherence to concrete programming standards inherent in the definition of the programming language itself and not to more extrinsic quality-related concerns, such as language modularity, portability, testing costs and communications between different program modules in networked and distributed environments.
Web service is a term that has emerged to describe a software module deployed on the Web and intended for use as a component of one or more applications distributed across the Internet. A Web service inherently exists as part of a larger system. It is the servicing of these other components that gives Web services their name. Thus, a primary consideration in the design of a Web service is the protocols that will be used to communicate with other components of the system.
The first relevant protocol is the transport layer, which is typically HTTP or HTTPS. Other transport protocols, such as Java's Remote Method Invocation (RMI), CORBA's Internet Inter-Orb Protocol (IIPO), or DCOM's Distributed Computing Environment Remote Procedure Call (DCE RPC) can enable distributed applications, but such applications are not considered Web services because they are not deployed on the Web.
A second relevant protocol is the packaging layer. This layer defines how content is wrapped up into messages that are sent over the transport layer. The emerging standard in this area is called SOAP. SOAP, originally stood for “Simple Object Access Protocol”, but it now refers to a more generalized protocol for any service oriented protocol. SOAP is currently an XML-based messaging framework for exchanging structured and typed information between peers in a decentralized, distributed environment. Extensible Markup Language (XML) is a meta-markup language for describing data objects. The specifications defining both SOAP and XML are produced by the World Wide Web Consortium (W3C). SOAP is typically implemented in XML and relies on XML namespaces and XML schemas to define document types that describe messages. SOAP describes a simple messaging (request/response) mechanism (for example, Remote Procedure Calls (RPC)). That is, a SOAP client sends a request (e.g., a RPC request) to a SOAP server. The SOAP server then replies by sending a response (e.g., a RPC response) to the SOAP client.
Web Services Description Language (WSDL), also typically implemented in XML, is used to describe the types of requests accepted by a particular Web service. It is used to communicate meta-information about the Web service and, as such, is not strictly necessary for invoking the Web service itself.
Since XML is a meta-markup language, it provides mechanisms for defining languages that are implemented in XML. There are two basic mechanisms for defining these languages: Document Type Definition (DTD) and XML Schema. DTDs provide mechanisms for expressing which elements are allowed and what the composition of each element can be. Allowable attributes can be defined per element type, and allowable attribute values can be defined per attribute. However, DTDs have some shortcomings. They do not provide the capability to extend types, they do not have provisions for namespaces, and competency in DTD writing requires learning a syntax that seems obscure to those outside the SGML world. To address these issues, XML schemas were introduced. Like DTDs, schemas define a set of authorized elements, attributes, and attribute values. However, schemas are namespace-aware and are more type-oriented than DTDs. Also, schemas themselves are an XML-based language, so learning schemas does not require learning a new syntax.
The development of high quality web services requires testing at multiple levels. This is a difficult and time consuming task, both to exercise the web services and to confirm that the messages conform to requirements regarding features such as well-formedness, validity, fault handling, and application-specific business logic. Therefore, there is a need to a system and method to automate testing of SOAP-based Web services.
Accordingly, the present invention enables the above problems to be overcome by providing a method and system for automating the testing of Web services that use SOAP as a wire protocol. The invention provides an easy interface for exercising Web services and testing their functionality. The invention helps users confirm the responses to SOAP messages with such features as fault detection, textual comparisons, XML validation by DTDs or XML Schemas, and the ability to express and flag complex patterns in XML. The invention lets the users validate responses that require application-specific verification (such as business logic validation) by plugging in their own code. The invention also provides the capability to perform regression testing of web services. In one embodiment, the invention automatically creates regression test controls from SOAP responses. Alternatively, users can create their own regression tests. In one embodiment, for testing XML, the invention includes a built-in Extensible Style Sheet Language Transformation (XSLT) processor, XML parser, and an editor.
In one aspect the invention is directed to a method for automatic testing of a web service software including SOAP comprising: identifying the web service; creating one or more test cases for exercising behavior of the identified web service; executing the created one or more test cases for obtaining results for the behavior of the identified web service; and analyzing the results. In another aspect, the invention is directed to a method for automatic testing of a SOAP client comprising: identifying a web service interface to the client; creating behavior of the identified interface; exercising the client to invoke the web service and for obtaining results for the behavior of the identified interface; and analyzing the results.
Still other embodiments of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein is shown and described only embodiments of the invention by way of illustration of the best modes contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments and its several details are capable of modification in various obvious respects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
The present invention is a module testing tool for Web services. In one embodiment, the present invention automates the testing of Web services that use SOAP as a wire protocol and a transport protocol such as Standard Mail Transfer Protocol (SMTP), Hypertext Transfer Protocol (HTTP), HTTP over Secure Socket Layer (HTTPS), and the like. The invention provides an easy interface for exercising Web services, performing black box testing, and testing SOAP clients. In addition, the invention can be used to confirm the responses to SOAP messages with features such as fault detection, textual comparisons, XML validation by DTDs or XML schemas. Responses requiring application-specific verification such as business logic validation are supported through scripting. The invention also performs regression testing of Web services, including automatic creation of regression test controls from SOAP responses. In the case of XML, one embodiment of the invention includes a built-in XSLT processor, XML parser, and editor.
In one embodiment, the invention is capable of automatic creation of GUI elements to input custom, complex data types. This means that when a custom, complex data type is specified in a WSDL document, the invention generates controls for the specific elements which make up the data type in order to allow the user to easily specify complex parameters. The invention creates an internal representation of the metadata for the Web service, which includes information such as the service name, number of parameters, parameter types, and return type, which is incorporated into the generated test case. From this internal representation, the invention produces a graphical user interface representation that visually represents a test case. This visual representation of the test case enables users to both analyze and manipulate the test cases directly. The parameter instance generation and manipulation are not limited to the GUI, but the presence of the GUI facilitates this work in the cases where it is most helpful. This is particularly true when very complex types are used and users may want to directly express specific instances of the complex parameters so as to exercise known portions of the Web service implementation.
The GUI representation is a composite of complex and primitive components. The primitive components are based on a mapping of primitive XML types to primitive GUI components. For example, strings are represented with text boxes, boolean values are represented with check-boxes, arrays are represented with tables, enumerations are represented with combo boxes. The primitive XML types are mapped to primitive GUI components. This mapping enables arbitrarily complex data types to be represented in the GUI by decomposing the data types into their constituent primitive types, translating these constituent parts into their corresponding GUI components, and composing a complex GUI component that parallels the composition of the original data types. An exemplary process is depicted below:
In addition to working as a client to test Web services, the invention can be used as a server to test clients. When the invention is used in this way, it serves as a platform on which Web services are deployed. A good reason for deploying a service in the invention is that the same verification tools used to test SOAP responses can be used to verify SOAP requests.
As an example, consider the manipulation of items in a shopping cart in an Online Grocer application. Normally, the shopping cart would be manipulated via the Web interface. However, manipulating the application programmatically might also be desirable. For instance, say that the Online Grocer forges a partnership with another online service and that other service wants to purchase items for their customers. This is a business opportunity for the Online Grocer to gain some extra purchases from its partner's customers. It is also a business opportunity for the partner if the Online Grocer provides a commission for each purchase that comes through this means. However, this type of tight integration requires that the partner be able to place orders programmatically. Services required could include:
Deploying these services in this embodiment of the invention is simple. First, we choose View>Show Web Services. A Web Services tab appears in the left window of the GUI. We select the Web Services root node within the Web Services tab and set the port number to the port on which we want to publish these services. Now, we can add services and define methods for SOAP RPC calls.
For example, to add the getCartTotal ( ) service, we right-click the main Web Services node and select Add Output>Web Service. A node labeled undefined method is added to the Web Services tree. After we select the new service by clicking it, a method parameters panel appears in the right frame of the GUI. Here we can determine how the invention unmarshalls parameters and marshalls return values. If we select Automatically, the invention will unmarshall parameters and marshall return values for us. In this case, the function signature should exactly match the RPC method that will be requested. If we select Manually, we ourselves can unmarshall the parameters and marshall the return values. We choose the automatic marshalling option here for simplicity. Methods in the invention may be implemented in Java, Python, or JavaScript. A simple implementation of the getCartTotal( ) method in Python looks like:
def getCartTotal(cart_id):
The input parameter cart_id is ignored, and the constant total of $123.45 is hardcoded.
In one embodiment, the invention is capable of Web Service deployment in multiple languages including: Java, JavaScript, Jython (Java-based Python), Jacl, Jscheme, and the like. These multiple languages include native services as well. In this case, the invention behaves as a server in order to test the client. In this embodiment, a variety of implementation languages are supported, where the user specifies both which implementation language they are using as well as what actual implementation to use, which is specified in their language of choice. Alternatively, the user can specify the implementation language, but allow the invention to generate an implementation that conforms to a specified interface. These methods are not mutually exclusive because an implementation that is automatically generated may then be modified by the user. Examples of implementation languages that the user may specify include Java, Javascript, Python, and the like.
In one embodiment, the invention includes the ability to check response time of Web Services. The invention is also capable of load testing for Web services. It provides a flexible infrastructure that lets users create and run a wide variety of tests on their Web services. This can be done in multiple ways. An assertion that the response time must be within a certain range can be expressed in the test case itself. It can also be deferred to a post-execution analysis phase. In either case, a timer is used to determine the total time from the time the request message is sent to the time the response message is received. This information can then be correlated with other data to disambiguate network traffic time from server processing time. One such scheme is for the invention to simply periodically ping the server to acquire an estimate of the network travel time. Another scheme is for the invention to communicate with monitors on the server to deduce a finer grained picture of how much time is spent in each component. Another sub-item here is to record how the response time changes as the server is placed under load, and to create a report of this for further analysis.
In one embodiment, the invention contains a library of tools that can be used as primary testing tools and/or as tools that perform operations on the output of other tests. By combining and chaining the available tools, complex and specific tests can be created.
The first step in testing a Web service with the present invention is to create a test suite. The test suite defines all the tests needed to perform on the service. A Graphical User Interface (GUI) includes a Test menu containing the option Create Test Suite. Selecting this option causes a tree-view graphical representation of the new test suite to appear on the left side of the GUI. Right-clicking the test suite node provides a menu for adding tests to the test suite. Each test has an associated tool and an associated input. Examples of some available tools include SOAP Client, XSLT, Validate XML, RuleEnforcer, and so on.
The following is a typical process for creating a test suite.
When the invention runs test cases, it performs all operations specified by selected tests and output parameters. A SOAP client test involves sending a request, receiving the response, and verifying the response by applying other tools. Creating a SOAP client test requires selecting the SOAP Client tool and specifying the call information. The SOAP Client tool behaves as a client in order to exercise the server. In one embodiment, the invention includes automatic serializers, enabling a simple way to complete values in the GUI. Specify the URL to a WSDL to enable the invention to extract information such as the RPC Router, the methods contained in the service, and the target URIs and signatures of each method.
To run all test cases in the test suite:
In one embodiment, the invention runs all available test cases, then report the outcome of each test (success or failure) and the test suite's overall success rate, as depicted in
The results of a particular tool can be accessed by choosing that tool's name in the View Selector (in the bottom right corner of the GUI) or by clicking the appropriate node of the Results tab in the left side of the GUI, as shown in
To run a single test case:
You can access the results of a particular tool by choosing that tool's name in the View Selector (in the bottom right corner of the GUI) or by clicking the appropriate node of the Results tab in the left side of the GUI.
Regression test provides an easy way to determine whether any functionality of the Web service changes. The invention can automatically create regression controls for your SOAP Client and Rule Enforcer test cases. When prompted to do so, it creates Diff controls with the current outcomes of the selected test cases, then adds these Diff controls to the appropriate test cases. To automatically create a regression test control based on existing outputs, right-click the node representing a single test or the node representing the entire test suite, and choose Create Regression Control from the shortcut menu. The invention then adds a Diff tool to all selected tests. Each time this tool is used, it compares the results of the control test to the current test run.
The following is a typical way to have the invention automatically create regression controls for the test suite:
To have the invention automatically create a regression control for a specific test suite:
The next time the invention runs a test case with a Diff control, it will compare the actual outcomes with the outcome specified in the Diff controls. If you ran the entire Test Suite, failed regression tests will be reported in the main test results. You can always access the results of a particular regression test by choosing the appropriate Diff tool's name in the View Selector (in the bottom right corner of the GUI) or by clicking the appropriate Diff node of the Results tab in the left side of the GUI.
If a user wants to perform regression testing on a test case, but does not want to use the current outcome as the comparison value, preferably the user needs to define her own Diff control for that test case.
To define a Diff control for a test case:
The next time the invention runs this test case, it will compare the actual outcome with the outcome specified in the Diff control. If you ran the entire Test Suite, failed regression tests will be reported in the main test results. You can always access the results of a particular regression test by choosing the appropriate Diff tool's name in the View Selector (in the bottom right corner of the GUI) or by clicking the appropriate Diff node of the Results tab in the left side of the GUI.
If you want to repeat a test suite after you are done with testing, you should save it so that you can easily re-open and re-run it.
To save a test suite:
The invention will then save the current test suite in the specified location.
To close a test suite:
The invention will then close the current test suite and remove the appropriate tab from the left side of the GUI.
To open an existing test suite:
Table 1 includes some exemplary tools available for tests and/or outputs.
You can use most of the above tools as tool tests. Some SOAP tests use the SOAP RPC as the foundation of the test, then add other tools to process the results.
For example, if you wanted to test if a certain SOAP remote procedural call always returned the same output for a given input, you might create a SOAP Client test, then use a Diff control as its output. Alternatively, if you wanted to test whether a Web service returned values in a correct format, you might create a SOAP Client test, then use a Rule Enforcer to apply a set of rules that checked if the output matched a certain required pattern. If it did, you could attach a regression control to the Rule Enforcer; the invention would then alert you if the Web service failed to match that required pattern in subsequent tests.
Check Well-Formedness tool checks whether XML files are well-formed. A well-formed document should preferably conform to the following guidelines:
This tool can be used as part of a test case, or it can be applied to a file or set of files opened in the Project tree.
Before you run this tool as a tool test in a test case, you need to specify what the tool should check. (If you use this tool as an output, the invention assumes that you want it to check the result of the test or output to which it is attached). You can specify this in the Check Well-Formedness Parameters panel. To open this panel, select the Test: Check Well-Formedness node in your Test Suite tree.
Create XML Dictionary tool creates a dictionary that you can use to create custom rules and queries. The dictionary created by this tool contains a library of the elements used in the file from which it was created.
Before you run this tool as a tool test in a test case, you need to specify what file or text the invention should base the dictionary on. (If you use this tool as an output, the invention assumes that you want it to use the result of the test or output to which it is attached). You can specify this in the Create XML Dictionary Parameters panel. To open this panel, select the Test: Create XML Dictionary node in your Test Suite tree.
Diff tool compares two files or outcomes and reports what (if any) differences there are between the two files or outcomes. If you are using this tool as an output, you need to specify the reference value against which you want to compare the input value. You can specify this value in the Diff Parameters panel. To open this panel, select the Output: Diff node in your Test Suite tree.
If you are using this tool as a tool test, you need to specify the input value and the reference value against which you want to compare the input value. You can specify both of these values in the Diff Parameters panel. To open this panel, select the Test: Diff node in your Test Suite tree. In the Diff Parameters panel, specify the file or text you want to check in the Input portion of the panel, then specify the reference value in the Tool portion of the panel.
Editor tool sends data to internal editor. This tool is primarily used to provide a way to access the files that the File Writer tool creates. To modify Editor settings, choose Editor> Preferences. This will open an Editor panel that you can use to modify the following options:
External tool let users include an external tool in their test cases. Before you run this tool as part of a test case, you need to provide the invention with information about how to access and use it. You can specify this in the External Tool panel. To open this panel, select the External Tool node in your Test Suite tree.
In the panel, you can specify the following parameters:
File Writer tool can convert other output data to files. The Editor tool is often used in conjunction with this tool because it provides a means to view the files that the File Writer creates. If you are using this tool as an output, you need to specify how you want this tool to name and save files. You can specify these parameters in the File Writer Parameters panel. To open this panel, select the Output: File Writer node in your Test Suite tree. You can then specify the following parameters:
If you are using this tool as a tool test, you need to specify what data the File Writer should write to a file as well as information about how you want this tool to name and save files. You can specify these parameters in the File Writer Parameters panel. To open this panel, select the Test: File Writer node in your Test Suite tree. You can then specify the parameters as described above.
Java Method tool lets you send output to a public static Java method. This is useful if you want to perform application-specific checks that cannot be expressed with a rule (for example, if you want to check if a given output matches a record in a database). The method used should have a single parameter of type ‘Object’ and a return type of ‘boolean’. It should return “true” for passed tests and return “false” for failed tests. To use this tool, you need to specify the name of the class containing this method and the name of this method. You can specify this in the Java Method Parameters panel. To open this panel, select the Output: Java Method node in your Test Suite tree.
Rule Enforcer tool applies the customized rules that you have created and associated with a particular enforcer. The Rule Enforcer's actions are determined by the nature of the associated rule(s). Rules can look for problems in the data returned by your Web service, check whether its responses always match certain general patterns, or simply query your Web service. You can check whether a Rule Enforcer produces consistent results by attaching a regression control or Diff output to that Rule Enforcer.
If you are using this tool as an output, you need to specify what rule or rule set it should enforce. You can specify both of these values in the Rule Enforcer Parameters panel. To open this panel, select the Output: Rule Enforcer Parameters node in your Test Suite tree.
If you are using this tool as a tool test, you need to specify what rule or rule set it should enforce as well as what file or text it should apply this rule to. You can specify both of these parameters in the Rule Enforcer Parameters panel. To open this panel, select the Test: Rule Enforcer node in your Test Suite tree. In the Rule Enforcer Parameters panel, specify the file or text you want to check in the Input portion of the panel, then specify the rule or rule set in the reference value in the Tool portion of the panel.
SOAP Client tool is used to perform SOAP messaging. This tool is the foundation of most test cases. To perform a SOAP Client test, you need to tell the invention how to execute the call. This involves specifying the following parameters in the SOAP RPC Parameters panel (this can be accessed by selecting the Test: SOAP RPC node in your Test Suite tree):
After you run a test, the output of the test will be displayed in the Output window at the bottom of this panel. If the MIME type of the output is not text/plain, you need to select the proper MIME type value from the drop-down list in order to have your output reported correctly.
Transmit tool lets you transmit and receive over a socket connection. It is used for communicating directly with a specific port of a host. It can also be used to listen at a particular port if you are expecting something sent to some specific port on your machine.
You can use this tool to perform a lower level of testing than SOAP Client allows because it looks at the socket connection, which is handled by HTTP and sits one layer below the SOAP call. It is also useful if you have applications communicating through XML over a socket connection; it can be used to perform functional and regression testing of components that communicate using socket-based protocols. This tool can be used as part of a test case, or it can be applied to a file or set of files opened in the Project tree.
If you are using this tool as an output, you need to specify your host machine and the port number that you want to use. You can specify this information in the Transmit Parameters panel. To open this panel, select the Output: Transmit node in your Test Suite tree. If you are using this tool as a tool test, you need to specify what information it should transmit as well as your host machine and the port number that you want to use. You can specify this information in the Transmit Parameters panel. To open this panel, select the Test: Transmit node in your Test Suite tree.
To listen using the transmit tool, right-click the Transmit Test Suite tree node, then choose Start Listening from the shortcut menu that opens. Typically, you do not need a host specified in the Transmit parameters panel if you want to listen; the host parameter is only required if you want to transmit. To stop listening, right-click the Transmit Test Suite tree node, then choose Stop Listening from the shortcut menu that opens. To close the connection to the host, right-click the Transmit Test Suite tree node, then choose Close Connection from the shortcut menu that opens.
Transmit tool supports some output options. These options include:
XSLT tool transforms XML files using the style described in the specified XSL file. This tool can be used as part of a test case, or it can be applied to a file or set of files opened in the Project tree. If you are using this tool as an output, you need to specify what XSL file it should use to transform the XML it receives. You can specify this in the XSLT Parameters panel. To open this panel, select the Output: XSLT node in your Test Suite tree. In this panel, you can also specify whether you want this tool to store information in using relative paths (instead of absolute paths) and the MIME type of the transformed document.
If you are using this tool as a tool test, you need to specify what XML you want to transform as well as what XSL file it should use to transform the specified XML. You can specify both of these parameters in the XSLT Parameters panel. To open this panel, select the Test: XSLT node in your Test Suite tree. In the XSLT Parameters panel, specify the file or text you want to transform in the Input portion of the panel, then specify the XSL files that you want to use in the Tool portion of the panel. In the Tool portion of the tab, you can also specify whether you want this tool to store information in using relative paths (instead of absolute paths) and the MIME type of the transformed document.
An Editor output is added to this tool by default. Preferably, the FileWriter is used as an output so that the invention writes the output to files.
Validate XML tool checks whether XML files are valid. An invalid XML file does not contain a proper document type declaration and/or does not obey the constraints of that declaration (correct elements, nesting, attributes, attribute values, etc.). This tool can be used as part of a test case, or it can be applied to a file or set of files opened in the Project tree. Before you run this tool as a tool test in a test case, you need to specify what file the invention should check. (If you use this tool as an output, the invention assumes that you want it to use the result of the test or output to which it is attached). You can specify this in the Validate XML Parameters panel. To open this panel, select the Test: Validate XML node in your Test Suite tree.
Test results are displayed in the right side of the GUI. If you tested with a single tool, any problems found will be displayed in the Results panel (in the right side of the GUI). If you ran a test suite or single test case, you can access individual error messages by either:
Some of the tools (such as Rule Enforcers, Validate XML, and Check Well-Formedness) report output in tree or table format. When results are reported in this format, the following options are available:
Additional options may be available; the options that are available depend on the specific to the type of error message you are viewing, as well as the format in which you are viewing results. If your results are displayed in tree format, you can quickly expand the entire Results tree by right-clicking the unused area of the Results panel, then choosing Expand All from the shortcut menu.
You can change the way that the invention displays results in the Results panel to suit your personal preferences and the nature of your current task. Typical options include:
Typically, table vs. tree tends to be a personal preference: trees are more structured than tables, but tables consume less window space. Whether you want to see your results listed by file or by location usually depends on what task you are trying to accomplish.
To change the way that results are displayed:
Results will then be displayed in the format that you selected. The invention will continue displaying errors in the selected manner until you configure it to do otherwise.
You can suppress error messages that you do not want to see using the suppression feature of the invention. For example, you may want to suppress a particular error as soon as you have corrected it; this will make it easier for you to see what errors still need to be corrected. You could also suppress errors that are not relevant to your project.
When you suppress an error message, you are given a choice between suppressing the error message permanently or temporarily. A message that is suppressed permanently will be suppressed for all future test runs, until you remove the permanent suppression option. Temporary suppressions will automatically be removed the next time that you run the tool that produced the error.
To suppress a particular error message:
To suppress all errors that occur in a file:
You can also suppress all errors that are caused by the same file or “rule.” For example, you could suppress all errors related to (but not in) junk.htm, a file that you are going to remove from your site, or you could suppress errors relating to a specific type of test or rule.
To suppress all errors that have the same cause as a selected error:
If you later decide that you want to see results that you have permanently suppressed:
This suppression will then be removed. Errors that were previously suppressed by this suppression will be reported in future test runs. You can use the suppression counter to keep track of how many times the invention has encountered a specific error or type of error that you suppressed permanently. To view the number of hits for each suppression, choose View> View Suppressions, then look at the number of hits displayed next to each suppression. If you want to reset the number of hits for a certain suppression to zero, select the suppression whose hits you want to reset, then click Reset Hits.
When you add a suppression, it is applied only to files in the site from which you created the suppression. Such suppressions are called site-specific suppressions. If you want certain permanent suppressions to apply to all sites that you test in the invention, you should change the suppression to a user-specific suppression. To change a suppression from site-specific to user-specific (or vice versa):
You can customize many preferences in the Preferences panel. To access this panel, choose File> Customize Preferences. Once this panel is open, you can modify the following settings.
You can customize settings related to the tools in the invention tool bar by modifying options in the Preferences panel's Tools tab, as shown in
In one embodiment, the invention is configured to work with any RCS-based source control: if you have your source control set up correctly, you can check files in and out of your source code repository by right-clicking the Project tree node that represents the file that you want to check in or check out, then choosing the appropriate Check in or Check out option from the shortcut menu that opens.
To integrate your source control system:
When you browse Web files, the invention will open them in your system's default browser unless you customize the browser settings in the Preferences panel, as shown in
The invention works with proxy servers. To configure it to work with your proxy server, customize the settings in the Preferences panel's Proxy tab illustrated in
The exemplary MIME Types tab of
You can map public XML identifiers to system XML identifiers in the Preferences panel's XML Identifiers tab, as shown in
By default, the invention saves the WSDL URIs that are used in created test cases. The list of WSDL URIs used is contained in the Preferences panel's WSDL tab. If you do not want the invention to save these WSDL URIs, clear this panel's Add from Test Suite check box, as shown in
Additionally, the invention includes an internal editor you can use to view and edit files. An exemplary Editor screen is illustrated in
Other conventional editor commands (such as revert, copy, paste, etc.) are also available in the Editor menu and from the shortcut menu that can be opened by right-clicking the any area of the Editor panel. To customize the editor, choose Editor> Preferences. You can then modify tab and end-of-line marker settings in the Editor dialog box that opens. You can also access the menu options from the Editor menu by right-clicking the Editor panel.
If you want to test or transform a set of files (such as a group of files in a certain directory or the files that are on a Web server) you might want to create a project that contains all of your files. You can then apply the Validate XML, Check Well-Formedness, Rule Enforcer, Transmit or XSLT tool to all files, files in a certain directory, or a single file.
A preferred way to work with a set of files is to create a project. A project is a file that can contain one or more site files. Each site contains information about how to access a source. For example, if you are working on two different XML-based Web applications, you might want to create one project file that contains two site files (one for each application you are working on).
Project files provide you with a central place to access and work different groups of files. To create a project file:
You can add multiple sets of files (sites) to a project file. To add a set of files to the Project:
If want to add files from other directories/sources to the current site, you will need to add them using indirect links. You should only use indirect links to add a small set of files related the current site; if the files that you want to add are not closely related to the files in the current site, you might want to add an additional site for those files.
To use an indirect link to source files to a site:
The files/directories referenced in the indirect links will then be added to your Project tree. To save the current project and site files, choose Project> Save.
When you open a project file, all associated site files will also be opened. To open a previously saved project files and the site files it contains, choose Project> Open Site/Project, then choose the .wkj file that represents your project. Before you can test or transform files in a project, preferably, you should have a project open.
To apply Validate XML, Check Well-Formedness, or any Rule Enforcer tool to all project files, a certain directory, or a certain file:
The invention will then apply the selected tool and report errors found in the right side of the GUI.
Before you apply the Transmit tool to transmit files in your Project tree, you need to configure it. To do this:
To transmit a single file or all files in (and below) and certain directory, select the Project tree node associated with the file or set of files you want to transmit, then click the appropriate Transmit button. You can also “listen” to socket connections by clicking the appropriate Transmit button. Before you listen, right-click the Transmit tool bar button with the busy receiver, choose Configure Transmit from the shortcut menu, then specify the port you want to use in the Configure Transmit window that opens.
To apply the XSLT tool to all project files, a certain directory, or a certain file:
The invention will then transform the indicated file(s).
If you want to configure the XSLT tool bar button to always use a certain XSL file or if you want your transformed documents to have a MIME type other than text/xml, right-click the XSLT tool bar button, choose Configure XSLT from the shortcut menu, then change the parameters in the Configure XSL window that opens.
When the invention finds an XML file that does not contains a proper document type declaration and/or does not obey the constraints of that declaration (correct elements, nesting, attributes, attribute values, etc.), it reports an XML Validation error. The reason for rule is because XML files that are not valid might not be parsed and processed correctly.
For example, the following file is not valid because the NAME element is not declared in the DTD.
The file and/or the DTD is then corrected so that the file references a DTD and conforms to that DTD.
When the invention finds an XML document that does not follow the syntax of XML (i.e., a document that is not “well-formed”), it reports an XML Not Well-Formed error.
A Well-formed document typically conforms to the following guidelines.
The reason for rule is because XML files that are not well-formed might not be parsed and processed correctly.
It will be recognized by those skilled in the art that various modifications may be made to the illustrated and other embodiments of the invention described above, without departing from the broad inventive scope thereof. It will be understood therefore that the invention is not limited to the particular embodiments or arrangements disclosed, but is rather intended to cover any changes, adaptations or modifications which are within the scope of the appended claims. For example, SOAP originally stood for Simple Object Access Protocol, but is now merely a name. In fact, there is a movement to expand the meaning of the acronym to “Service Oriented Architecture Protocol.” Therefore, the term SOAP, as used in the specification and the claims, is not limited to Simple Object Access Protocol, but it covers any service oriented protocol. Furthermore, the claimed invention is not limited to XML implementations. Other implementations using similar languages also fall within the scope of the invention.
This patent application is a continuation of U.S. patent application Ser. No. 10/214,209, filed Aug. 7, 2002, which claims the benefit of the filing date of U.S. Provisional Patent Application Ser. No. 60/312,010, filed Aug. 13, 2001 and entitled “MODULE TESTER FOR WEB SERVICES”, the entire content of which is hereby expressly incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60312010 | Aug 2001 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10214209 | Aug 2002 | US |
| Child | 11350371 | Feb 2006 | US |
