System and method for software testing with extensible markup language and extensible stylesheet language

[0001] Embodiments of the present invention relate to the field of software testing. More particularly, embodiments of the present invention relate to a system and method for using Extensible Markup Language as scripting language, and Extensible Stylesheet Language (XSL) stylesheets to drive a software test.

[0002] Generally, the speed of execution of interactive programs is largely limited by the rate at which a user inputs data and commands, and not by the execution of the commands by the system on which the software is running. At the user level, macro commands and scripts may be used to increase the speed of execution of tasks that involve many commands.

[0003] For large or frequently used command sequences, scripts may be used in conjunction with a scripting engine that interprets the script and controls the execution of a program. For example, a web browser may have a scripting engine using JAVASCRIPT or VBSCRIPT (JAVASCRIPT is a registered trademark of Sun Microsystems Inc. Palo Alto, Calif.). Scripting engines are usually associated with a particular language that is a programming language or a subset of a programming language.

[0004] One area in which scripts are particularly useful is in the testing of software programs. Thorough testing of a software program typically requires the repeated application of large sets of commands.

[0005] Although a script and scripting engine based upon a particular programming language may mesh well with a program that is written in the same programming language, the content of the script may be difficult to associate with the commands that a user would input to the program, such as menu selections made from a graphical user interface. In this case, the script writing requires a level of familiarity with the code underlying the graphical user interface. The user interface of a software application is usually tailored towards natural language. Commands such as “cut” and “paste” are descriptive of their actions even though the executable source code is not.

[0006] A markup language such as Extensible Markup Language (XML) is not a programming language per se, but combines text and information concerning the text in a document that may be used by another program. Markup languages are less abstract and bear a closer resemblance to natural language than programming languages, and thus have the potential to be more user friendly.

[0007] Accordingly, embodiments of the present invention provide a system and method for software testing that use a markup language as a scripting language. Extensible Markup Language (XML), including Extensible Stylesheet Language (XSL) stylesheets are used to define a new markup language for developing scripts that can be used by a test control processor to test another software program.

[0008] A system and method for using Extensible Markup Language (XML) as a scripting language to drive testing of a software program are disclosed. XML is used to define a markup language in a script that provides commands that are interpreted by a test control processor. The test control processor may include an XML processor for processing the script. Using the script, the test control processor submits instructions to a software program and extracts the behavior of the software program. The software program behavior is tested by submitting multiple sets of instructions and comparing the results. Information regarding the software program behavior and test results is written to an output log file by the test control processor.

[0009] In one embodiment, an automation interface may be employed between the tester system and the application to be tested. In another embodiment, the application to be tested may be an integrated design environment program providing graphical user interfaces for the implementation of a design on a programmable device, such as a microcontroller. In this embodiment, an output of the application is a ROM image file that may be compared against a known file.

[0010] The tester can be pointed to a project in which case the test is run on the project to generate the ROM image file used to program the circuit device. In another embodiment, the tool can be directed to a library of user modules. The results generated by the application in this case would be assembly and C language projects for each user module. A ROM image file may also be generated.

[0022] In the following detailed description of the present invention, a system and method for software testing with Extensible Markup; numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one skilled in the art that the present invention may be practiced without these specific details. In other instances well known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present invention.

[0023] Some portions of the detailed descriptions which follow are presented in terms of procedures, logic blocks, processing and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, logic block, process, etc., is here, and generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0024] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the disclosure of the present invention, terms such as “processing” or “computing” or “calculating” or “computing” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's registers or memories or other such information storage, transmission or display devices.

[0025] Refer to FIG. 1A which illustrates a computer system 112. In general, computer systems 112 used by the preferred embodiment of the present invention comprise a bus 100 for communicating information, a central processor 101 coupled with the bus for processing information and instructions, a random access memory 102 coupled with the bus 100 for storing information and instructions for the central processor 101, a read only memory 103 coupled with the bus 100 for storing static information and instructions for the processor 101, a data storage device 104 such as a magnetic or optical disk and disk drive coupled with the bus 100 for storing information and instructions, a display device 105 coupled to the bus 100 for displaying information to the computer user, an alphanumeric input device 106 including alphanumeric and function keys coupled to the bus 100 for communicating user input information and command selections to the central processor 101, cursor control device 107 coupled to the bus for communicating user input information and command selections to the central processor 101, and a communications port 108 coupled to the bus 100 communication with the system 112. The port 108 may be coupled to printer.

[0026] The display device 105 of FIG. 1A utilized with the computer system of the present invention may be a liquid crystal device, cathode ray tube or other display device suitable for creating graphic images and alphanumeric characters recognizable to the user. The cursor control device 107 allows the computer user to dynamically signal the two dimensional movement of a visible symbol (pointer) on a display screen of the display device 105. Many implementations of the cursor control device are known in the art including a trackball, mouse, joystick or special keys on the alphanumeric input device 105 capable of signaling movement of a given direction or manner of displacement. It is to be appreciated that the cursor means 107 also may be directed and/or activated via input from the keyboard using special keys and key sequence commands. Alternatively, the cursor may be directed and/or activated via input from a number of specially adapted cursor directing devices.

[0027] The computer system 112 of FIG. 1A may be used with an integrated design environment (IDE). An example of an IDE is PSOC DESIGNER software, available from Cypress MicroSystems, Inc., of Bothell, Wash. PSOC DESIGNER software contains three subsystems; a DEVICE EDITOR subsystem, an Application Editor subsystem, and a Debugger subsystem. The interface is split into several active windows that differ depending on which subsystem the user is in. The PSOC DESIGNER software is an example of a program with a graphical user interface that may be automated and tested in an embodiment of the present invention.

[0028] The advent of programmable integrated circuits and computer-aided design (CAD) tools has reduced the number of individuals required to carry a concept from design to productization. The development of the integrated design environment (IDE) has made it possible for individual engineers to configure a programmable integrated circuit.

[0029] The IDE has made it feasible for a single designer to configure sophisticated integrated circuits with dozens of pins and many possible inputs and outputs. An example of such integrated circuits is the programmable microcontroller. A programmable microcontroller may include a microprocessor, memory, and digital and other programmable hardware resources.

[0030] The PSOC DESIGNER DEVICE EDITOR subsystem of FIG. 1B is used for selection, placement and configuration of User Modules. FIG. 1B shows a DEVICE EDITOR interface 120 in selection mode. Shown in FIG. 1B are a User Module Selection Window 121, User Module Window 122, User Information Windows 123, and a Resource Manager Window 124.

[0031] An example of an integrated circuit that can be configured using PSOC DESIGNER software is the Cypress MicroSystems CY8C25122A microcontroller. The CY8C25122A is a member of the CY8C25xxx/26xxx family of PSOC™ microcontrollers that replaces many MCU-based system components with one single-chip, programmable device. A single PSOC microcontroller offers a fast core, Flash program memory, and SRAM data memory with configurable analog and digital peripheral blocks in a range of convenient pin-outs and memory sizes. The driving force behind this innovative integrated circuit comes from user configurability of analog and digital arrays of programmable system blocks. The programmable system blocks are analog and digital peripheral blocks that may be customized by the placement and configuration of User Modules.

[0032] The interface 120 is used to configure the target device. User Modules (represented by icons) may be selected from the User Module Window 122, which causes an icon to appear in the User Module Selection window 121. In this example a pulse width modulator PWM16_1 125 is shown as selected. Information regarding the PWM16_1 125 is shown in the User Information Windows 123. The Resource Manager Window shows the target device resources that are used by the PWM 16_1.

[0033] FIG. 1C shows the interface 120 in placement mode, with a Placement Window 130, a Global Resources Window 131, and a User Module Parameters Window 132. User Modules shown in the User Module Selection window 121 are placed in the Placement Window 130. The placement of the PWM 16_1 125 is indicated by the two digital blocks 133 and 134 shown in the Placement Window 130. Parameters and resources shown in the Global Resources Window 131 and User Module Parameters Window 132 are available for configuration by the designer.

[0034] FIG. 1D shows the interface 120 with expanded Global Resources Window 131 and User Module Parameter Window in which resources and parameters have been set. For example, in the Global Resources Window 131, the CPU_Clock has been set with a frequency of 12 MHz and the Sleep Timer has been set with a frequency of 512 Hz. In the User Module Parameters Window the period has been set at 134 and the Pulse Width has been set at 92.

[0035] FIG. 1E shows a configuration interface of an integrated design environment used for deploying module connections. Interconnections can be specified on the device in the placement mode of the interface. User Module interconnections consist of connections to surrounding configurable blocks, output bus, input bus, internal system clocks and references, external pins, and analog output buffers. Multiplexors may also be configured to route signals throughout the configurable block architecture.

[0036] Referring again to FIG. 1E, a Pinout Window 140 and a Pinout Parameters Window 141 are shown. The Pinout window includes a diagram of the pin layout of the target device (e.g., the Cypress MicroSystems CY8C25122A). The Pinout Window accepts input specifying the connections for the configurable blocks to the pins. In this example, there is only one User Module present, and thus there are no interconnections specified between multiple User Modules. Typically, there may be multiple User Modules with designer specified interconnects which would be stored in the project database. Some interconnects are designer specified, whereas others are generated automatically (e.g., the interconnection of blocks of a selected User Module).

[0037] Further details regarding integrated circuits that are configurable from within an integrated design environment are described in a U.S. patent application titled “Programmable Microcontroller Architecture.”by W. Snyder, filed on Oct. 22, 2001; the whole of which is incorporated herein by reference. Additionally, an integrated design environment in or with which the present invention may be practiced is described in U.S. patent applications Ser. No. 09/972,003 (filed Oct. 5, 2001), Ser. No. 09/972,133 (filed Oct. 5, 2001), and Ser. No. 09/998,848 (filed Nov. 15, 2001); which are incorporated herein by reference.

[0038] Generally, Extensible Markup Language (XML) can be used as a human-readable, machine-understandable, general syntax for describing hierarchical data. XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form the character data in the document, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure. A software module called an XML processor is used to read XML documents and provide access to their content and structure.

[0039] Unlike HTML, element names in XML have no intrinsic presentation semantics. Extensible Stylesheet Language (XSL) is used to prepare stylesheets to handle presentation of XML data. XSL is capable of transforming XML to HTML.

[0040] FIG. 2A shows a general computer implemented system 200 for testing a software program 210 using an XML script 215 that includes data that serves as commands for the test control processor 205, and also data for input to the software program 210. The test control processor 215 includes an XML processing capability and is used to process the XML script 215 to produce a set of instructions that are executed by the software program 210. The test control processor 205 functions at two levels.

[0041] On the first level, the test control processor controls the execution of the software program by issuing instructions and arguments or data to the software program. This control may be exercised through an interface such as a Component Object Model (COM) interface. COM is a software architecture that allows the components made by different vendors to be combined into a variety of applications. COM defines a standard for interoperability and is not dependent on any particular programming language. COM provides mechanisms for communications between components, error and status reporting, and dynamic loading of components. The COM interface may be included in the software program 210 in order to achieve automation.

[0042] On the second level, the test control processor extracts the behavior of the software program by evaluating its output and comparing the output to standard references or expected results. The overall process of testing the software program 210 thus comprises the execution of the software program at the first level, and extraction of the behavior of the software program at the second level.

[0043] The results of the testing of the software program may be written to output log file 220 in an XML format, or may be written to output log file 225 in an HTML format. The XML format is convenient for storing results for subsequent access by a program that has an XML processing capability. The HTML format is useful for dissemination of results as it is accessible by a web browser.

[0044] FIG. 2B shows a system 230 for testing an integrated design environment 284. The integrated design environment includes a configuration subsystem 287, a Debugger subsystem 291, an Application Editor subsystem 289, and User Modules 293. The integrated design environment also includes a COM Automation Interface 285 that accepts instructions 260 from the test control processor 236.

[0045] The instructions 260 are prepared by the application driver 240 using the XML script 270. The XML script is interpreted by the XML processor 250 and the results made available to the application driver 240. The XML Script may include pointers to a Library 235 for data and other files that may be incorporated into the instructions 236 by the application driver 240.

[0046] Output 265 from the integrated design environment 284 may include a ROM image and/or error and status messages generated by the integrated design environment 284. The Output 265 is passed to an Evaluator that compares the output (e.g., a ROM file) to expected results that may be stored in the Library 235. The Evaluator may also process error messages and status messages.

[0047] The execution history of the integrated design environment software, the instructions 260, and the results produced by the Evaluator 245 may be captured in an XML log file 275 or an HTML log file 280. The test control processor may include an XSL stylesheet 255 to format the output log files.

[0048] FIGS. 3A, 3B, 3C, 3D, 3E, and 3F show an example of an XML formatted script 215 used for testing the software program in accordance with an embodiment of the present claimed invention. A Test Suite, defined by start tag 300S in FIG. 3A and end tag 300E in FIG. 3F, is the root element of the script. Elements nested with the root element contain instructions for the test control processor 205 and data for the software program. The script may include elements for any of the commands that a user would enter from a graphical user interface (GUI) or command line associated with the application.

[0049] The Test Suite defined by start tag 300S in FIG. 3A and end tag 300E in FIG. 3F, may be used to test the functionality of the software program in its entirety, or it may tailored to focus on specific functions. Due to the large amount of time required to test large programs, it is desirable to be able to do focused partial testing of particular parts of a large program. During the long term development of complex programs in which the test focus is constantly changing and test scripts must be constantly revised, the use of XML as a scripting language reduces the overall effort for testing.

[0050] The GENSOC_TEST_LIST defined by start tag 305S and end tag 305E is an element containing a class of comprehensive tests. Shown within GENSOC_TEST_LIST is a specific test defined by the empty element tag 306. Attributes within tag 306 provide the test control processor with locations of files necessary for execution control (e.g., GenSoc.xml), and data for the software program. The test creates assembly and C language projects for each User Module and makes a call to every Application Program Interface (API). The test also generates a ROM file that is compared to a reference ROM file (GoldenROMfile).

[0051] The GENSOC_UM_SPECIAL_HANDLING_LIST defined by start tag 307S and end tag 307E is an element containing a class of modifications to the basic GENSOC_TEST of element 306. Elements with in this class, such as element 308, can modify the basic test by excluding specific test operations.

[0052] The UM_TEST_LIST defined by start tag 310S in FIG. 3A and end tag 310E in FIG. 3C, is an element containing a class of tests directed to individual User Modules within the software program. For example, element 311 is a test directed to an A/D converter “ADCINC12_0.”

[0053] Start tag 315S and end tag 315E in FIG. 3C define a class of tests directed to projects within the software program. FIG. 3C also shows an HTM_TEST_LIST defined by start tag 320S and end tag 320E. In this particular example, the element is empty and HTM tests are not applied. The SOCKET_TEST_LIST element defined by start tag 325S in FIG. 3C and end tag 325E in FIG. 3D, and the DEBUG_TEST_LIST defined by start tag 330S in FIG. 3D and end tag 330E in FIG. 3F contain additional classes of tests that may be applied to the software program.

[0054] In testing the software program, an object that is evaluated for success or failure is the ROM file. The ROM file is a binary image that is used to program the non-volatile memory (e.g., ROM) in a programmable microcontroller as described above. Output ROM files produced by the software program during testing are compared to known valid ROM files. When a discrepancy is observed, the output ROM file the execution behavior of the software program is examined to determine the cause, and/or the output ROM file is verified.

[0055] A discrepancy may be caused by a defect in the software program, such as an error during the build process. In this case, the software program or project associated with the ROM file is debugged. Alternatively, the output ROM file may be verified by testing independent of the software program with respect to its intended use to determine correct functionality. When such a ROM file is independently verified, it may itself be adopted as a reference for subsequent tests, augmenting or replacing existing reference ROM files.

[0056] FIG. 4 shows an example of portions of an XML formatted output log file in accordance with an embodiment of the present claimed invention. Element 400 reports the success or failure of selecting a user module, in this case, an A/D converter (ADCINC12_0). Element 405 reports the success or failure of placing the User Module. Element 410 reports the success or failure of accessing a parameter list for the A/D converter, and element 415 reports the success or failure of selecting a parameter from the list, in this case the TMR Clock parameter. The element block 420 shows the results for the selection of parameter values for the TMR Clock.

[0057] Each User Module may tested using a combination of placement, parameter selection, and parameter values in the manner shown above for the A/D converter. Element 430 reports the success or failure of the source code generation for a User Module configuration.

[0058] Element 435 reports on the success or failure of another placement of the User Module, selected from the possible placements. Elements 440, 445, and 450 report results similar to elements 405, 410, and 415, for the new placement. The example of FIG. 4 illustrates how complex the testing of the software program can be when all User Modules, placement options, parameters, parameters, and source code generation are taken into account. The use of an XML formatted output log file is an efficient way to manage the collection and presentation of the large amount of output data produced by testing. XSL stylesheets provide many options for rendering visible output of the data for examination.

[0059] FIG. 5 shows an example of portions of an HTML formatted output log file as rendered by a browser. The HTML output log file may be used to provide test results in a format that is close to natural language. The header 501 indicates the type of test results being reported, in this case, the results of 84 project tests. Block 505 having lines 4 through 21 shows the successful results for a project test related to an A/D converter.

[0060] Block 510 of FIG. 5 having lines 1421 through 1438, shows the report for the test of another User Module in which an error is reported at lines 1434 and 1435. Label 515 indicates the end of the project test report block.

[0061] FIG. 6 shows a computer implemented flowchart 600 for a method of using XML as a scripting language to test a software program in accordance with an embodiment of the present claimed invention.

[0062] In step 605, an XML script is accessed by a test control processor which may be implemented as a software tool. XML is used in the script to define a scripting language that is intelligible to the test control processor.

[0063] In step 610, The script is interpreted to produce a set of instructions to be applied to the software program that is being tested.

[0064] In step 615, the execution of the software program is controlled using the set of instructions generated from the script. Data from the script (or derived from pointers in the script) may also be passed to the software program being tested. In this instance, an automation interface (COM) may be employed to apply the instructions to the application under test

[0065] In step 620, after the application executes the instructions using internal routines, the test control processor extracts the behavior of the software program. The output of the software program is examined and compared to reference or expected results to check for discrepancies. The reference may be a previously verified ROM file. Error messages and status messages received from the software program may also be evaluated.

[0066] In step 625, the test results are captured in an output file. The results may be formatted in XML or HTML as desired. The content and format of one or more output files may vary, depending upon its intended use (e.g., archive or examination). The output file may contain the commands issued to the application, error reports, and the results of comparison checks with expected results.

[0067] The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.