Test case editing scheme for automatic testing industry

Abstract

The invention discloses a test case editing scheme oriented to the automatic test industry, and the scheme realizes efficient editing, analysis and execution of test cases through layered architecture design. The scheme comprises the following steps: (1) dividing a test case into a measurement abstraction layer and a hardware abstraction layer; (2) in the measurement abstraction layer, constructing a test index sequence and a corresponding index operation sequence to form a test process file; (3) in the hardware abstraction layer, establishing a mapping relation between the operation keyword and the underlying instrument driver, and forming an instrument configuration file; and (4) the test process file and the instrument configuration file are converted into objectified description, so that flexible editing and automatic script conversion of the test case are realized. The method has the beneficial effects that (1) the readability and editing efficiency of the test case are improved, and the workload of manual script conversion is reduced; (2) the generalization ability of the test scheme is enhanced, and the method is suitable for various test devices and test scenes; and (3) flexible configuration and efficient reuse of test resources are realized through a layered architecture and a standardized file format.

Description

Technical Field

[0001] A test case editing solution for the automated testing industry Background Art

[0002] A test case is a key concept in the automated testing industry. It refers to a set of clearly defined test procedures and expected results, encompassing the entire lifecycle of a software or hardware product, from requirements analysis to product design, manufacturing, and runtime fault detection. In automated testing scenarios, test cases serve as the bridge between the upper-level test plan and the underlying programmable device drivers. During the requirements analysis and design phase, developers translate product requirements into specific test conditions and expected results based on the product's functionality and expected performance. They then develop detailed test cases and submit them for review to ensure consistency with product requirements and their feasibility. During the test execution phase, these test cases are typically rewritten or directly converted into automated test scripts to drive the automated test system to perform test tasks and record test results. Test cases must describe the test object, test method, and result evaluation criteria in simple, easy-to-understand natural language for easy reading and editing by testers, and they must also be convertible into executable program scripts to drive the underlying hardware devices to complete the test.

[0003] However, currently, existing test case editing solutions in China struggle to balance both test case readability and script conversion convenience. A significant number of automated testing companies still rely on manual methods to convert test cases into test scripts. While some companies have their own test case writing formats and automated script conversion methods, these applications are often specialized and lack the flexibility to accommodate multiple test devices, test conditions, and test logic, making it difficult to migrate across multiple test conditions. Therefore, the automated testing industry currently requires a test case editing solution with strong generalization capabilities that balances high test case readability with efficient script conversion. Summary of the Invention

[0004] The automated testing industry's process for converting test cases into executable scripts suffers from low script conversion efficiency and weak generalization capabilities. This invention addresses these issues by providing a universal test case editing solution. By summarizing the two key aspects of test solution design and underlying hardware drivers, this invention develops a test case editing solution based on the measurement abstraction layer and the hardware abstraction layer, enabling flexible test case editing and automated script conversion.

[0005] The described test case editing solution can be applied to automated test platforms and plays a vital role in test development. The implementation steps of this solution are as follows: The test case hierarchy is divided into basic information, a measurement abstraction layer, and a hardware abstraction layer. In the measurement abstraction layer, a correspondence is established between test indicators and instrument operation sequences. The test indicators are arranged in sequence to form a test sequence. In the hardware abstraction layer, a mapping relationship is established between instrument operation names and actual instrument driver methods. By integrating the measurement abstraction layer and the hardware abstraction layer, a test case editing program and an instrument driver wrapper are developed.

[0006] The characteristics of the present invention are:

[0007] (1) Good versatility: The solution has good heterogeneous compatibility and flexible instrument driver packaging. At the same time, various measurement indicators, instrument operations, and instrument parameters can be flexibly added and modified as needed. It can adapt to test scenarios with multiple test objects, multiple test indicators, and multiple test logics.

[0008] (2) Strong decoupling: Test cases and instrument configuration information are stored in independent JSON files. After a standard parsing process, executable underlying instrument operation sequences are formed. The test process and underlying code are completely decoupled, allowing for flexible test case storage and migration.

[0009] (3) Cloud publishing is possible: Test case editing can be implemented on the cloud server, and test cases and configuration files can be distributed to edge workstations for parsing and execution. This effectively separates the test plan development and test execution processes, forming an integrated test design-execution-management system. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 The overall framework of the test case.

[0011] Figure 2 The specific composition of the test case.

[0012] Figure 3 Test case program object structure.

[0013] Figure 4 Instrument driver packaging solution.

[0014] Figure 5 Instrument driver object structure.

[0015] Figure 6 Example instrument configuration file.

[0016] Figure 7 Complete test case parsing example. DETAILED DESCRIPTION

[0017] The following describes in detail a test case editing solution for the automatic testing industry provided by the present invention in conjunction with the accompanying drawings.

[0018] This method divides the test case main structure into measurement abstraction layer and hardware abstraction layer, such as Figure 1 As shown in the figure, the measurement abstraction layer generates the test process file, and the hardware abstraction layer generates the instrument configuration file. This hierarchical division can establish a clear correspondence between the test indicators and test operations of the test case and the underlying instrument driver. At the same time, it facilitates the flexible encapsulation of test resources and the programmatic design of the overall solution. The overall method implementation is divided into five steps, which are described in detail below.

[0019] Step 1: Divide the measurement abstraction layer into three main parts: test case basic information, test sequence, and instrument operation sequence. Figure 2 As shown, the basic information for a test case includes basic information describing the test scenario and test object, such as the test case name, product type, and test phase. This information facilitates subsequent test case management and screening. The test sequence contains various test indicators. Each test indicator includes a basic description and an instrument operation sequence. Each instrument operation corresponds to a specific instrument model or logical operation, and corresponding operation parameters can be set. The collection of these test indicators and indicator operations forms the test flow file.

[0020] Step 2: Convert the test process file into an object-oriented description that is easy to implement. Figure 2 As shown, each test flow file corresponds to a TestCase class in the program, which contains two subclasses: TestSequence and TestCaseInfo. TestCaseInfo stores basic test case information, such as the test case name and product model. TestSequence stores the test sequence, which contains TestIndex subclasses for each test indicator. In addition to indicator descriptions, TestIndex also contains indicator action sequences, called Actions. Subclasses within Actions store instrument types and parameters. Based on the object-oriented description of the test flow, test flow editing tools can be developed to enable free editing of each test step.

[0021] Step 3: Build an instrument resource expansion plan, establish a mapping relationship between indicator operations and actual instrument drivers, and form a hardware abstraction layer. Figure 4As shown, the indicator operation keywords in the measurement abstraction layer need to correspond to the actual hardware driver method, so that the test case can be converted into an actual executable instrument operation sequence. The mainstream instrument drivers on the market can be divided into VISA standard I / O, reflective assembly I / O, and universal standard I / O. VISA standard I / O mainly controls the instrument through universal instrument instructions. For this type of driver, a mapping between operation keywords and instrument instructions can be established. Reflective assembly I / O mainly controls the instrument by calling the standard program interface. For this type of driver, a mapping between operation keywords and program interface calling methods can be established. Universal standard I / O mainly controls the instrument by sending data packets through standard serial ports or TCP / IP protocols. For this type of driver, a mapping relationship between operation keywords, communication protocols, and data packet contents can be established. The collection of the above operation keywords and instrument drivers forms the instrument configuration file.

[0022] Step 4: Convert the instrument configuration file into an object-oriented description that is easy to implement. Figure 5 As shown, each instrument driver corresponds to an Instrument class, which contains the instrument name, InstrumentName, and the instrument model subclass, Models. The instrument model subclass contains a description of the instrument driver type and interface location, allowing programs to determine the correct instrument driver category and driver method. Furthermore, the instrument operation subclass, Operations, stores the mapping between operation keywords and the instrument's underlying driver methods. This object-oriented description allows programs to uniquely identify the instrument driver method based on basic instrument information and operation keywords, and also facilitates the creation of standardized instrument configuration files that can be parsed by programs. Figure 6 This is an example of an instrument configuration file. Different instruments correspond to different driver modes. Each instrument specifies the correspondence between instrument operations and the instrument's underlying driver methods.

[0023] Step 5: Integrate the measurement abstraction layer and the hardware abstraction layer to build a complete test case editing and parsing process. Figure 7This is a complete example of test case editing and parsing. The test flow file for the measurement abstraction layer includes electrical performance indicators such as startup time, startup overshoot, and output ripple. Taking the output ripple test as an example, it includes operations such as setting the protection voltage, setting the input voltage, switching the fixture, and acquiring ripple. The fixture switching operation uses a 4644 test fixture as the test fixture type, and the command sent is S00. The instrument connection test determines the fixture serial port location, and in the instrument configuration file, it can be determined that S00 refers to sending the string 0x03. Similarly, the instrument type for the ripple acquisition operation is an oscilloscope. A connection test determines the oscilloscope model to be DSO-X 3012B, and then determines the general instrument control command referred to by the "acquire ripple" keyword. All other operation sequences can follow the same process, ultimately forming the underlying instrument driver sequence to execute the correct instrument operation.

Claims

1. A test case editing solution for the automatic testing industry, characterized in that: The following steps are involved: Divide the test cases into two levels: measurement abstraction layer and hardware abstraction layer; In the measurement abstraction layer, a test indicator sequence is constructed. Each test indicator contains an indicator operation sequence and basic indicator information. The indicator operation sequence is an abstract description of the instrument operation, referring to a certain instrument operation with practical significance. The combination of test indicators and test operations forms a test process file. Convert test process files into object-oriented descriptions to facilitate program implementation; In the hardware abstraction layer, a mapping is constructed between indicator operation keywords and underlying instrument drivers. Instrument driver types are divided into VISA standard I / O, reflective assembly I / O, and universal standard I / O. Each type of driver has a different communication method, and the process of locating operation keywords to the underlying driver is different. The combination of operation keywords and underlying instrument drivers forms the instrument configuration file. Convert instrument configuration files into object-oriented descriptions to facilitate program implementation; The test process file and instrument configuration file constitute a complete executable test case. The program can convert the test indicator sequence into a logical underlying instrument operation sequence through layer-by-layer mapping, making the test case parseable and executable.

2. According to claim 1, the test case editing solution for the automatic testing industry is characterized in that: Build a measurement abstraction layer, including: The measurement abstraction layer is divided into three levels: test case basic information, test indicator sequence, and indicator operation sequence. The test case basic information is a general description of the test case, which is used to screen and manage test cases. The test indicator sequence is a description of the electrical performance indicators of the object under test. Each test indicator contains a corresponding indicator operation sequence. The indicator operation corresponds to the actual instrument operation that needs to be performed. The element collection in the measurement abstraction layer forms a test process file.

3. According to claim 1, the test case editing solution for the automatic testing industry is characterized in that: Describe the test process file in an object-oriented form, including: The test process file is divided into an object-oriented description form of parent class and child class, which is conducive to the program implementation of test process editing. Each test process file corresponds to a parent class in the program, which contains two subclasses: test indicator sequence and test case basic information. The test indicator contains two subclasses: basic information and indicator operation. The indicator operation stores the relevant instrument type and instrument parameters.

4. According to claim 1, the test case editing solution for the automatic testing industry is characterized in that: Build a hardware abstraction layer, including: Instrument drivers are divided into VISA standard I / O, reflective assembly I / O, and universal standard I / O. The mapping between VISA standard I / O operation keywords and instrument instructions is constructed, the mapping between reflective assembly I / O operation keywords and program interface calling methods is constructed, and the mapping between universal standard I / O operation keywords and communication protocols and data packet contents is constructed. The collection of the above operation keywords and instrument drivers forms an instrument configuration file.

5. According to claim 1, the test case editing solution for the automatic testing industry is characterized in that: Describe the instrument configuration file in an object-oriented form, including: The driver of an instrument model corresponds to a parent class, which contains the instrument name and instrument model subclass. The instrument model subclass contains a description of the instrument driver type and interface location, and also includes an instrument operation subclass. The instrument operation subclass stores the correspondence between the operation keywords and the instrument's underlying driver methods.

6. According to claim 1, the test case editing solution for the automatic testing industry is characterized in that: Comprehensive test process files and instrument configuration files implement test case parsing and execution, including: The test indicators are mapped to indicator operation sequences layer by layer, and the indicator operations are mapped to the underlying instrument driving methods, ultimately converting the abstract test process into a logical underlying instrument control instruction set to achieve automated program-controlled testing.

Images