Automatic testing method and device, equipment and storage medium

Abstract

The invention relates to an automatic testing method and device, equipment and a storage medium. The method comprises the steps that physical device configuration and a test script corresponding to a test task are obtained, the physical device configuration comprises a protocol type of a physical device application, and the test script comprises an abstract function calling code of an abstract device instance corresponding to a physical device; reading and analyzing the test script line by line, identifying an abstract device instance, an operation function and a function parameter corresponding to a current abstract function calling code under the condition that the current analysis behavior abstract function calling code is determined, and determining a protocol type corresponding to the operation function according to the abstract device instance and physical device configuration; according to the protocol type, determining a protocol instruction template correspondingly bound with the operation function; and generating a target protocol instruction based on the protocol instruction template and the function parameters. By adopting the method, the test efficiency can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automation testing, and in particular to an automation testing method, device, equipment and storage medium. BACKGROUND

[0002] In the field of automation testing, especially in functional circuit test (FCT) testing, a software system is usually required to control multiple instruments and devices to work cooperatively to complete a complex testing process.

[0003] The current automation testing system is mainly realized through a direct instruction script. A test engineer directly writes protocol instructions for communicating with a specific device in a script language or in a test platform. For example, to control a power supply, a Standard Commands for Programmable Instruments (SCPI) instruction string such as "VOLT 5.0" is directly included in the script and sent to a corresponding serial port or network port through a Virtual Instrument Software Architecture (VISA) library. The test logic and protocol implementation are completely coupled in the script. Once a power supply with the same function but different protocols is replaced, almost all related test scripts need to be rewritten, and the testing efficiency is low. SUMMARY

[0004] Therefore, it is necessary to provide an automation testing method, device, equipment, storage medium and computer program product capable of improving testing efficiency.

[0005] In a first aspect, the present application provides an automation testing method, comprising:

[0006] obtaining a physical device configuration and a test script corresponding to a testing task, wherein the physical device configuration comprises a protocol type applied by a physical device, and the test script comprises abstract function call codes of abstract device instances corresponding to the physical device;

[0007] reading and parsing the test script line by line, identifying an abstract device instance, an operation function and function parameters corresponding to a current abstract function call code in a case where the current abstract function call code is determined, and determining a protocol type corresponding to the operation function according to the abstract device instance and the physical device configuration;

[0008] determining a protocol instruction template bound to the operation function according to the protocol type, and generating a target protocol instruction based on the protocol instruction template and the function parameters.

[0009] In a second aspect, the present application further provides an automatic testing device, which comprises:

[0010] an acquisition module, configured to acquire a physical device configuration and a test script corresponding to a test task, wherein the physical device configuration comprises a protocol type applied by a physical device, and the test script comprises abstract function call codes of an abstract device instance corresponding to the physical device;

[0011] a recognition configuration module, configured to read and parse the test script line by line, in a case where it is determined that the current parsed abstract function call code, recognize an abstract device instance, an operation function and function parameters corresponding to the current abstract function call code, and determine a protocol type corresponding to the operation function according to the abstract device instance and the physical device configuration;

[0012] an instruction generation module, configured to determine a protocol instruction template bound to the operation function according to the protocol type, and call a corresponding protocol implementation component to perform format processing based on the protocol instruction template and the function parameters, to generate a target protocol instruction.

[0013] In a third aspect, the present application further provides an automatic testing device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the method according to the first aspect when executing the computer program.

[0014] In a fourth aspect, the present application further provides a computer readable storage medium, which stores a computer program, and the computer program implements the method according to the first aspect when executed by a processor.

[0015] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, and the computer program implements the method according to the first aspect when executed by a processor.

[0016] The automatic test method, device, equipment, storage medium and computer program product can obtain a physical device configuration corresponding to a test task and a test script, the physical device configuration including a protocol type applied by a physical device, and the test script including an abstract function call code of an abstract device instance corresponding to the physical device; the test script is read and parsed line by line, in a case where it is determined that the abstract function call code is parsed, an abstract device instance, an operation function and a function parameter corresponding to the abstract function call code are identified, and a protocol type corresponding to the operation function is determined according to the abstract device instance and the physical device configuration; a protocol instruction template bound to the operation function is determined according to the protocol type; and a target protocol instruction is generated based on the protocol instruction template and the function parameter. Through the scheme, the physical device configuration (including the protocol type) corresponding to the test task and the test script (including the abstract function call code of the abstract device instance) are obtained, the abstract device instance, the operation function and the function parameter corresponding to the abstract function call code are identified when the script is parsed line by line, the protocol type corresponding to the operation function is determined in combination with the physical device configuration, the bound protocol instruction template is matched according to the protocol type, and finally the target protocol instruction is generated based on the template and the function parameter, thereby solving the problem that the test logic and the protocol are completely coupled in the traditional FCT automatic test. Since the devices with different protocols but the same function need to be rewritten in the traditional scheme, the test script needs to be modified in the scheme, and only the physical device configuration and the corresponding protocol instruction template need to be adjusted, thereby greatly reducing the repeated labor of the test engineers, reducing the cost of manually writing and maintaining the protocol instruction, and significantly improving the test efficiency; meanwhile, the scheme supports the access of physical devices of multiple protocol types, can enable the test system to quickly adapt to instruments and devices of different models and different protocols, and effectively enhances the flexibility and adaptation capability of the test system in the complex and variable FCT test scene. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the embodiments or the related art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0018] Figure 1A A schematic diagram of an automatic test system applied to an embodiment automatic test method;

[0019] Figure 1B A flowchart of an embodiment automatic test method;

[0020] Figure 2A flowchart of a method for determining the protocol instruction template corresponding to the binding of the operation function in an embodiment;

[0021] Figure 3 A flowchart of another automated testing method in an embodiment;

[0022] Figure 4 A flowchart of an automated testing device in an embodiment;

[0023] Figure 5 An internal structure diagram of a computer device in an embodiment. DETAILED DESCRIPTION

[0024] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application.

[0025] The current automated testing system is mainly realized by a direct instruction script. Among them, a test engineer directly writes protocol instructions for communicating with a specific device using a script language or in a test platform. For example, to control a power supply, a Standard Commands for Programmable Instruments (SCPI) instruction string such as "VOLT 5.0" is directly included in the script and sent to the corresponding serial port or network port through a Virtual Instrument Software Architecture (VISA) library. The test logic and protocol implementation are completely coupled in the script. Once a power supply with the same function but different protocols needs to be replaced, almost all related test scripts need to be rewritten, and the testing efficiency is low.

[0026] To solve the above problems, the embodiment of the application provides an automatic test method, which can obtain a physical device configuration (including a protocol type) corresponding to a test task and a test script (including abstract function calling code of an abstract device instance), identify an abstract device instance, an operation function and function parameters corresponding to the abstract function calling code after parsing the script line by line, determine a protocol type corresponding to the operation function in combination with the physical device configuration, match a bound protocol instruction template according to the protocol type, and finally generate a target protocol instruction based on the template and the function parameters, thereby solving the problem of complete coupling between test logic and protocols in traditional FCT automatic testing. Since the traditional scheme needs to rewrite a large number of related test scripts when replacing devices with different protocols but the same function, the scheme does not need to modify the test scripts, only needs to adjust the physical device configuration and the corresponding protocol instruction template, greatly reduces the repeated labor of test engineers, reduces the cost of manually writing and maintaining protocol instructions, and significantly improves the test efficiency; meanwhile, the scheme supports access of physical devices of multiple protocol types, can enable the test system to quickly adapt to instruments and devices of different models and different protocols, and effectively enhances the flexibility and adaptation capability of the test system in complex and variable FCT test scenarios.

[0027] The automatic test method provided in the embodiment of the application can be applied to an automatic test device or an automatic test equipment. The automatic test device can be a functional module or a functional entity for implementing the automatic test method in the automatic test equipment.

[0028] For example, the automatic test equipment can include but is not limited to the following:

[0029] (1) FCT function test fixture (with integrated control system), which is the most common device in the electronic manufacturing industry. For example, when testing a mobile phone charging mainboard, instruments such as power supply, multimeter and signal generator are connected to the fixture. The integrated control system can run the automatic test method, and does not need to write specific SCPI (Standard Commands for Programmable Instruments) instructions in the script. When replacing power supplies of different brands (protocols are different but functions are power supply), only the device configuration and the protocol template need to be updated, and the corresponding instructions can be automatically generated to complete the test of the charging voltage and current of the mainboard.

[0030] (2) Automated Test Workstation. Automated test workstations are commonly used in industrial or automotive electronics testing scenarios. For example, when testing an automotive Electronic Control Unit (ECU), the workstation connects to various devices such as an oscilloscope, a Controller Area Network (CAN) bus analyzer, and an analog signal generator. Through the above methods, the test script only describes abstract functions such as "reading the ECU speed signal" and "outputting a simulated throttle signal," and then automatically generates instructions based on the specific device protocols, avoiding the need to rewrite the script after changing to a different model of analyzer.

[0031] (3) Multi-channel instrument testing platform. Multi-channel instrument testing platforms are common in the field of chip or sensor testing. For example, when testing a pressure sensor, the platform needs to control a high-precision power supply, a pressure simulator, and a data acquisition card simultaneously. After adopting this solution, the platform's control system can be compatible with acquisition cards of different protocols (such as USB protocol and Ethernet protocol). Test engineers only need to maintain one set of abstract test scripts to adapt to the testing needs of different hardware configurations.

[0032] The automated testing method provided in this application can be applied to functional circuit testing (FCT) scenarios and is adaptable to devices that achieve functional verification through multi-instrument collaborative control and rely on specific communication protocols. Exemplary examples include, but are not limited to, the following types of devices:

[0033] Functional testing fixtures and related equipment in the electronics manufacturing industry include DC power supplies, multimeters, signal generators, and oscilloscopes used in mobile phone / computer motherboard testing. These devices need to work together to complete tasks such as motherboard power supply, signal input, and parameter measurement.

[0034] Control and measurement equipment in the industrial electronics / automotive electronics field: such as CAN bus analyzers, analog signal sources, and on-board sensor simulators in automotive electronic control unit (ECU) testing, and input / output (IO) modules and communication gateways in industrial PLC (programmable logic controller) testing.

[0035] High-precision testing equipment in the chip / sensor field, such as pressure simulators and high-precision data acquisition cards in pressure sensor testing, and power modules and timing signal generators in chip testing, require precise parameter control and the acquisition of feedback data.

[0036] The content that can be tested for the above-mentioned equipment may include: equipment function control and state switching, equipment operating parameter acquisition and verification, and multi-device collaborative logic verification.

[0037] In one exemplary embodiment, the above-described automated testing method is based on Figure 1A The automated testing system implementation shown is as follows:Figure 1A The automatic test system can include an intent layer, a logic layer, a physical implementation layer, and a physical layer. The intent layer is used to implement the design and configuration of user interaction. The logic layer is a core processing engine. The physical implementation layer is used to manage resources and implementation, and stores the binding relationship of test scripts or device definitions, operation functions, and protocol instructions, as well as protocols. The physical layer includes physical devices. Each layer can further include, but is not limited to, the following modules shown:

[0038] A device abstraction definition module 101, which is a visual configuration interface or data template. Users can create and manage abstract devices here, and the process does not involve any protocol or hardware information. For example, a user creates an abstract device named “DC Power Supply” and adds multiple abstract functions to it, as shown in Table 1 below:

[0039] Table 1

[0040]

[0041] It should be noted that the above Table 1 is described by adding three abstract functions “set voltage”, “read current”, and “output switch enable” as an example. In actual application, there can be more possibilities.

[0042] A test script editor 102, in which users can write test scripts. The syntax of the script only faces abstract devices and abstract functions, which is very intuitive. For example, the test script content can be “DC Power Supply. Set Voltage (Voltage = 5.0)”. The test script writer does not need to care about what brand of device the DC power supply is and what protocol is used.

[0043] A protocol management module 103, in which users can manage protocols and can directly import or create protocols. Protocol managers do not need to pay attention to any abstract devices and test scripts, but only need to focus on the protocols used by the devices. For example, the above protocols can include Modbus protocol, SCPI protocol, etc.

[0044] Modbus protocol is a commonly used serial communication protocol in the field of industrial automation, mainly used to connect various industrial devices (such as sensors and controllers) to realize data transmission and control between devices, has strong adaptability, and is widely used in industrial control scenarios. SCPI protocol, which stands for Standard Commands for Programmable Instruments, is a general communication protocol for programmable instruments (such as power supplies and oscilloscopes). It realizes unified control of different brands of instruments through standardized instruction format, simplifying the operation and integration of test equipment.

[0045] The binding relationship configuration module 104 is a bridge connecting the logical layer and the physical layer. In the module, a user can select a defined abstract device (such as "DC power supply"), select a specific protocol implementation (such as "SCPI_V1"), and then establish a mapping relationship. For example, the "set voltage" function of the DC power supply can be bound to the instruction template "VOLT {0}" of the SCPI_V1 protocol, and the write parameter "voltage (floating point number)" is specified to correspond to the placeholder "{0}".

[0046] For example, in the binding relationship configuration module 104, the "read current" function of the DC power supply can be bound to the instruction template "MEAS:CURR?" of the SCPI_V1 protocol.

[0047] The dynamic parsing executor 105 is the core brain of the system, and its workflow is the key of the automatic test method provided by the embodiment of the application. Before running, the executor initialization operation can be performed according to the script / device definition and the binding relationship; and then in the process of running the test script, the protocol implementation library and the communication interface layer can be dynamically called to realize the execution control, reading and other functions of the script logic.

[0048] The protocol implementation library 106 is an extensible plug-in code library. Each protocol (such as Modbus and SCPI) is implemented as an independent component. Each component includes loading the corresponding protocol file and converting the standard data type (such as a number and a string) into the protocol-specific byte stream (instruction message) and the logic of parsing the returned byte stream.

[0049] The communication interface 107 is responsible for managing physical communication channels such as a serial port, a Transmission Control Protocol (TCP) / Internet Protocol (IP) socket, and a CAN card. It provides standardized Send(bytes) and Receive() interfaces for upper-layer calls. The Send(bytes) interface is a data sending interface, and the Receive() interface is a data receiving interface.

[0050] The physical device (such as a DUT) 108 is an external actual hardware device used by the test system and an actual hardware device (such as a DTU) to be tested.

[0051] In an exemplary embodiment, as shown in Figure 1B An automatic test method is provided, which includes:

[0052] 11. Obtain the physical device configuration and test script corresponding to the test task.

[0053] The test script can be written in the test script editor 102 as shown in the figure. The test script contains a set of instructions of abstract function call code. The "abstract device instance" is a logical abstraction of a physical device (such as "DC power supply" and "oscilloscope"), and the "abstract function call code" describes the operation of the abstract device (such as "DC power supply sets voltage 5.0V"), without involving specific protocol instructions. Figure 1A

[0054] The physical device configuration can refer to the parameter settings of the actual hardware device related to the test task, and the core includes the "protocol type" (such as Modbus and SCPI) used by the device, and can also include communication interface information.

[0055] In step 11, the physical device configuration preset for the current test task can be loaded from the database or configuration file, and the test script written by the user through the script editor is read, to prepare for subsequent parsing and execution. By separating the physical device configuration and the test script, it avoids directly embedding hardware details and protocol instructions in the test script, lays a foundation for decoupling the test logic and protocol implementation, and enables the test script to be reused across devices.

[0056] 12. Read and parse the test script line by line, and in the case of determining that the current parsing behavior is abstract function call code, identify the abstract device instance, operation function, and function parameter corresponding to the current abstract function call code.

[0057] The abstract function call code can refer to the operation instruction of the abstract device in the script.

[0058] For example, "read current ()", "output switch enable (ON)", etc., which contain information such as operation object (such as abstract device instance), specific action (such as operation function), and parameter (such as function parameter).

[0059] In step 12, the dynamic parsing executor can scan the test script line by line, determine whether each line is abstract function call code (non-call code such as comments and logical judgment statements are skipped), and if so, extract the abstract device instance (such as "DC power supply"), operation function (such as "set voltage"), and function parameter (such as "5.0V") through syntax analysis. Among them,

[0060] In some embodiments, in the process of reading and parsing the test script line by line in the automatic test method, if it is determined that the current parsing line is not abstract function call code, the next action of the test script is continued to be parsed until all lines are parsed. ​

[0061] In the implementation of the above step 12, the resolution of the abstracted function call code is focused on, so as to ensure that the system only processes instructions related to device operation and improve the resolution efficiency. Meanwhile, the abstracted identification mode makes the script irrelevant to specific device protocols, thereby reducing the complexity of script writing.

[0062] 13. Determine the protocol type corresponding to the operation function according to the abstract device instance and the physical device configuration.

[0063] The physical device configuration obtained in step 11 is a set of hardware parameters associated with the test task, which needs to be associated with the abstract device instance in the test script to specify the physical device configuration for the abstract device instance (such as "DC power supply") in this test, and extract the preset protocol type (such as SCPI_V1) from the physical device configuration. The protocol type is the protocol that the current operation function needs to match, so as to ensure that the subsequent instruction generation conforms to the communication rules of the physical device.

[0064] In some embodiments, after obtaining the physical device configuration corresponding to the test task and the test script, the abstract device instance included in the test script can be specified with a corresponding physical device configuration before the test script is read and parsed line by line, so as to determine the association relationship between the abstract device instance and the physical device configuration.

[0065] After obtaining the physical device configuration of the test task and the test script, the operator specifies the physical device configuration corresponding to this test for each abstract device instance in the script through the initialization configuration interface of the "dynamic resolution executor". For example, it is clear that the DC power supply in the test script corresponds to the actual use of brand A power supply, which uses SCPI protocol and communicates through COM3, so as to establish the association relationship between the abstract device instance and the physical device configuration, and prepare for matching the protocol type when parsing the script later.

[0066] In the above embodiment, the association between abstract logic and physical hardware is converted from script hard coding to configuration setting, which avoids the problem of binding the test script to a specific device.

[0067] In some embodiments, the corresponding physical device configuration can also be queried based on the abstract device instance corresponding to the identified abstract function call code according to the association relationship established by the abstract device instance;

[0068] And from the physical device configuration, the protocol type associated with the abstract device instance is extracted, which is determined as the protocol type corresponding to the operation function.

[0069] Since the same abstract function needs to interact with the hardware through the protocol of the associated physical device to ensure that the instruction format conforms to the device communication rules, we can first query the established association between the abstract device instance and the physical device configuration based on the identified abstract device instance ("DC power supply") to find the corresponding physical device configuration (such as "SCPI protocol configuration of brand A power supply"); then directly extract the preset "protocol type" (such as "SCPI_V1") from the physical device configuration and determine it as the protocol type corresponding to the operation function of the current voltage setting.

[0070] 14. Based on the protocol type, determine the protocol instruction template corresponding to the operation function; based on the protocol instruction template and the function parameters, generate the target protocol instruction.

[0071] The aforementioned protocol instruction template can be stored in the above-mentioned... Figure 1A The binding relationship configuration module 104 in the system shown uses a protocol instruction template as a mapping carrier between abstract functions and protocol instructions. For example, a protocol instruction such as "DC power supply. Set voltage" can be bound to the "VOLT{0}" template of the SCPI protocol. This protocol instruction template can be retrieved by querying the protocol type.

[0072] The above Figure 1A In the system shown, the protocol implementation library 106 can convert protocol instruction templates and function parameters into a byte stream that can be recognized by the physical device.

[0073] In step 14, based on the protocol type determined in step 13, the binding relationship between the preset abstract function and the protocol instruction template in the binding relationship configuration module 14 can be queried, and the corresponding protocol component (such as the SCPI component) in the protocol implementation library 106 can be called. The "functional parameter" (such as 5.0) identified in step 12 is substituted into the template placeholder (such as {0}) to generate a specific protocol instruction string (such as "VOLT5.0").

[0074] The protocol implementation library 106 further converts the string into a byte stream that the physical device can receive, ultimately generating a complete target protocol instruction.

[0075] The introduction of the conversion action of the protocol implementation library 106 can ensure that the target protocol instruction conforms to the underlying communication format of the physical device (such as byte stream), solving the problem that instruction strings cannot be sent directly; at the same time, based on the mapping of binding relationships, the automatic conversion from abstract functions to specific instructions is realized.

[0076] In some embodiments, the physical device configuration further includes communication interface information, which includes communication interface type and interface configuration parameters. The communication interface type includes at least one of serial port, TCP or IP socket, and CAN card. The interface configuration parameters include at least one of port number and baud rate.

[0077] In some embodiments, after generating the target protocol instruction, the above-described automated testing method may further convert the target protocol instruction into a byte stream and send the byte stream to the corresponding physical device through the communication interface in the physical device configuration.

[0078] Among them, it can be achieved through Figure 1A The protocol implementation library 106 in the system, after generating the target protocol instruction (such as "VOLT5.0" of the SCPI protocol), calls the corresponding protocol implementation component (such as the SCPI component) to convert the text-formatted target protocol instruction into a byte stream (i.e., binary data) recognizable by the physical device. This is because the hardware device can only receive binary signals and cannot directly parse text instructions. Subsequently, through the communication interface preset in the physical device configuration (such as the COM3 serial port), the standardized interface of communication interface 107 is called to send the byte stream to the corresponding physical device (DUT or test instrument), completing the instruction transmission from the logic layer to the physical layer.

[0079] In some embodiments, in the above automated testing method, after sending the byte stream to the corresponding physical device, a return byte stream can also be received through the communication interface, and the corresponding protocol implementation component can be called to parse the return byte stream and update the script context based on the parsed information.

[0080] After receiving and executing the command, the physical device will return response data through the same communication interface (such as the "voltage setting successful" signal returned by the power supply, and the measurement data returned by the oscilloscope). This data also exists in the form of a byte stream. Figure 1A The system shown needs to receive the returned byte stream through the communication interface 107, and then call the protocol implementation component (such as Modbus component, SCPI component) that matches the protocol type to parse the byte stream.

[0081] For example, the returned byte stream of the Modbus protocol can be converted into readable data such as "current = 2.5A"; finally, the parsed information is updated to the script context (i.e. the runtime environment of the test script) for subsequent script logic judgment, ensuring the continuity and accuracy of the test process.

[0082] The above-mentioned automatic test method, by obtaining the physical device configuration (including protocol type) corresponding to the test task and the test script (including the abstract function calling code of the abstract device instance), after parsing the script line by line and identifying the abstract device instance, operation function and function parameter corresponding to the abstract function calling code, combining the physical device configuration to determine the protocol type corresponding to the operation function, and then matching the bound protocol instruction template according to the protocol type, finally generating the target protocol instruction based on the template and the function parameter, solves the problem of complete coupling of test logic and protocol in traditional FCT automatic test. Since the traditional scheme needs to rewrite a large number of related test scripts when replacing devices with different protocols but the same function, and this scheme does not need to modify the test script, only needs to adjust the physical device configuration and the corresponding protocol instruction template, greatly reduces the repeated labor of test engineers, reduces the cost of manual writing and maintaining protocol instructions, and significantly improves the test efficiency; at the same time, it supports the access of physical devices of multiple protocol types, can make the test system quickly adapt to different types and different protocols of instruments and equipment, and effectively enhances the flexibility and adaptation ability of the test system in complex and variable FCT test scenes.

[0083] In an exemplary embodiment, as shown in Figure 2 A method for determining the protocol instruction template corresponding to the operation function is provided, and the method comprises:

[0084] 21. According to the protocol type, query the pre-established binding relationship between the abstract function and the protocol instruction template.

[0085] Among them, the binding relationship is the mapping configuration data of the abstract function and the protocol instruction template under different protocol types.

[0086] In the system shown in Figure 1A The pre-established binding relationship between the abstract function and the protocol instruction template can be stored in the binding relationship configuration module 104. The essence is to establish one-to-one or many-to-many association between the abstract function of the abstract device (such as the "set voltage" function of "direct current power supply") and the specific protocol instruction template under different protocol types (such as the "VOLT{0}" template of SCPI protocol and the "01 03 00 01 00 01 CRC" template of Modbus protocol), and these binding relationships exist in the form of independent configuration data, supporting flexible modification and addition.

[0087] 22. Determine the protocol instruction template corresponding to the operation function based on the binding relationship.

[0088] If the same abstract function is configured with only one instruction template under a protocol type (for example, "set voltage" corresponds to "VOLT{0}" under SCPI_V1 protocol), the template is directly determined as the target template of the current operation function. If the same abstract function has multiple templates under a protocol type (for example, multiple templates are configured for different device models under the same protocol type), the instruction template that is completely adapted to the current physical device is further matched in combination with additional information such as the device model in the physical device configuration, to ensure that the subsequent generated protocol instruction can be accurately recognized by the physical device.

[0089] In the above embodiment, on the one hand, the association of the abstract function and the protocol instruction template is stored in the form of independent configuration data, so that the test script only needs to focus on the abstract function call and does not need to include any protocol details. When the physical device protocol is replaced later, the script does not need to be modified, and only the template mapping under the corresponding protocol type needs to be updated, which greatly reduces the maintenance cost and realizes the decoupling of the logical layer and the physical layer. On the other hand, the same abstract function can be bound to multiple protocols and multiple templates, supporting the access of physical devices of different brands and different protocols. Only the protocol type needs to be switched during initialization to automatically match the template, which significantly improves the adaptation flexibility of the test system to diversified hardware and avoids the problem of rewriting the script for new devices in the prior art. At the same time, centralized management of the protocol instruction template allows protocol maintenance work to be handled by a small number of experienced engineers, without the need for all test personnel to master complex protocol details, which reduces the skill threshold and improves test asset reusability and reduces maintenance complexity.

[0090] In one exemplary embodiment, as shown in FIG. 1, another automated testing method is provided, which defines a configuration phase and an execution phase, and the method comprises: Figure 3

[0091] S1, defining and configuring phase (offline preparation).

[0092] In the above S1 phase, the following steps S101 to S104 are included but not limited thereto.

[0093] S101, creating an abstract device and an abstract function.

[0094] In the above S101, one or more abstract devices and their functions can be created using a device abstraction definition module 101.

[0095] S102, writing a test script for an abstract device.

[0096] In the above S102, a test script that only includes a call to an abstract device function can be written using a test script editor 102.

[0097] S103, importing or creating a specific protocol actually used. ​

[0098] Wherein, the protocol management module 103 can be used to create or import the device or instrument protocol actually required to be used. For example, the import of the Adex DC power supply SCPI protocol is SCPI_V1.

[0099] S104, the binding relationship between the abstract function and the specific protocol instruction is established.

[0100] Wherein, the binding relationship configuration module 104 can be used to specify one or more protocol implementation modes for each abstract device function. For example, the "set voltage" function of the "DC power supply" can have both the SCPI binding mode and the Modbus binding mode.

[0101] S2, execution phase (online running).

[0102] Wherein, the above S2 phase includes but is not limited to the following steps S201 to S204.

[0103] S201, initialize the executor.

[0104] Wherein, when starting the test, the operator configures this test task. For example, the abstract device instance DC power supply in the script is specified to have its actual corresponding physical device configuration, including: the protocol binding used in this run (for example, select SCPI_V1 binding), and the communication interface 107 used in this run (for example, COM3, baud rate 9600).

[0105] S202, load and parse the script line by line.

[0106] Wherein, the dynamic analysis executor 105 reads the test script line by line.

[0107] S203, determine whether it is an abstract function call.

[0108] Wherein, the dynamic analysis executor 105 reads the line and determines whether it is a function call of the abstract device. If it is a function call of the abstract device, jump to S204, if it is not a function call of the abstract device, jump to S202.

[0109] S204, dynamically analyze and query the binding relationship.

[0110] Wherein, when a line of code calling an abstract function is parsed (for example, DC power supply. Set voltage (voltage = 5.0)), the executor performs a key dynamic conversion, which can include but is not limited to:

[0111] (1) Identify the operation object as the DC power supply, the operation function as the set voltage, and the parameter as the voltage = 5.0.

[0112] (2) Query the initialization configuration to learn that the direct current power supply currently should use the "SCPI_V1" protocol binding.

[0113] (3) Find the mapping relationship between the set voltage function and the "SCPI_V1" protocol in the binding relationship.

[0114] S205, dynamically call the protocol implementation library to generate a specific protocol instruction.

[0115] Among them, the SCPI component in the protocol implementation library 106 is called, the SCPI_V1 protocol, the mapping relationship, and the parameter 5.0 format are input, the final instruction string "VOLT5.0" is generated, and is converted into a byte stream.

[0116] S206, receive and transmit data through the specified communication interface.

[0117] Among them, the executor sends the generated instruction byte stream from the configured communication interface (COM3) to the physical device 108 (such as DUT) through the communication interface 107.

[0118] S207, parse the returned data to update the script context.

[0119] Among them, if the instruction needs the device to return data, the returned byte stream is received through the communication interface, and the corresponding protocol library is called for parsing, and the result is returned to the script context for subsequent logical judgment.

[0120] After the above step S207, it can also be judged whether the script is executed. If the script is executed, it is ended, otherwise it jumps to step S202 to parse the next action of the script, until the script is executed.

[0121] The automatic test method provided by the embodiment of the application can achieve the following beneficial effects, including but not limited to:

[0122] 1. The test logic and the physical implementation are completely decoupled: the test script is only related to the stable "abstract device" model. When the underlying physical device and the DUT or its communication protocol are changed, the test script does not need to be modified. Only the new protocol needs to be imported or added, and a mapping rule needs to be modified or added, so that the new device can be adapted, and the portability and life cycle of the test asset are greatly improved.

[0123] 2. The maintenance cost and complexity are significantly reduced: when a device is added, instead of writing a new driver or modifying the script, a one-time "binding" configuration is performed. The system knowledge base can be centralized and structured, and the maintenance workload is reduced by orders of magnitude.

[0124] 3. Greatly improve the test development efficiency and reusability: the abstract device model and related test scripts for a type of device (such as power supply, oscilloscope) can be used as standard templates, which can be quickly reused in different projects and different production lines, avoiding repeated actions, and allowing the test engineers to focus on more valuable test scenario design.

[0125] 4. Reduce the skill barriers for test personnel. Among them, the engineers responsible for writing test cases do not need to be protocol experts anymore. They can use abstract functions with natural language or graphical interfaces to develop scripts, while the implementation and configuration of the protocol can be completed by a few senior engineers, reducing the implementation difficulty.

[0126] It should be understood that although each step in the flowchart involved in each embodiment as described above is displayed in sequence according to the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified herein, there is no strict order limitation for the execution of these steps, and these steps can be executed in other orders. Moreover, at least part of the steps in the flowchart involved in each embodiment as described above can include multiple steps or stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but can be alternately executed with at least part of other steps or steps or stages in other steps.

[0127] Based on the same inventive concept, the embodiments of the present application also provide an automated testing device for implementing the above-mentioned automated testing method. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so the specific limitations in one or more automated testing device embodiments provided below can refer to the limitations of the automated testing method described above, which will not be repeated here.

[0128] In an exemplary embodiment, as shown in Figure 4 An automated testing device is provided, comprising:

[0129] The acquisition module 401 acquires the physical device configuration corresponding to the test task and the test script, wherein the physical device configuration includes the protocol type applied by the physical device, and the test script includes the abstract function call code of the abstract device instance corresponding to the physical device;

[0130] The identification configuration module 402 is configured to read and parse the test script line by line, identify the abstract device instance, the operation function and the function parameter corresponding to the current abstract function call code in the case of determining the current abstract function call code, and determine the protocol type corresponding to the operation function according to the abstract device instance and the physical device configuration.

[0131] The instruction generation module 403 is configured to determine the protocol instruction template bound to the operation function according to the protocol type, and call the corresponding protocol implementation component for format processing based on the protocol instruction template and the function parameter to generate a target protocol instruction.

[0132] In some embodiments, the apparatus further includes a configuration module configured to, before the identification configuration module 402 reads and parses the test script line by line after the acquisition module 401 acquires the physical device configuration and the test script corresponding to the test task, specify the corresponding physical device configuration for the abstract device instance contained in the test script to determine the association relationship between the abstract device instance and the physical device configuration; and the identification configuration module 402 is specifically configured to query the established association relationship of the abstract device instance based on the identified abstract device instance corresponding to the abstract function call code to determine the corresponding physical device configuration, and extract the protocol type associated with the abstract device instance from the physical device configuration to determine the protocol type corresponding to the operation function.

[0133] In some embodiments, the physical device configuration further includes communication interface information, and the communication interface information includes a communication interface type and an interface configuration parameter, the communication interface type includes at least one of a serial port, a TCP or IP socket, and a CAN card, and the interface configuration parameter includes at least one of a port number and a baud rate.

[0134] In some embodiments, the transmission module is configured to, after the instruction generation module 403 generates the target protocol instruction, convert the target protocol instruction into a byte stream, and send the byte stream to the corresponding physical device through the communication interface in the physical device configuration.

[0135] In some embodiments, the transmission module is further configured to, after sending the byte stream to the corresponding physical device, receive a return byte stream through the communication interface.

[0136] The apparatus further includes an analysis module configured to call the corresponding protocol implementation component to analyze the return byte stream, and update the script context based on the analyzed information.

[0137] In some embodiments, the identification configuration module 402 is specifically configured to: according to the protocol type, query a pre-established binding relationship between the abstract function and the protocol instruction template, the binding relationship being mapping configuration data of the abstract function and the protocol instruction template under different protocol types;

[0138] determine the protocol instruction template corresponding to the operation function based on the binding relationship.

[0139] In some embodiments, the identification configuration module 402 is further configured to: in the process of reading and parsing the test script line by line, if it is determined that the current parsed line is not the abstract function calling code, continue to parse the next action of the test script.

[0140] The above-mentioned various modules in the automatic test device can be realized by software, hardware and combinations thereof in whole or in part. The above-mentioned various modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so as to be called and executed by the processor to perform the operations corresponding to the above-mentioned various modules.

[0141] In an exemplary embodiment, a computer device is provided, and an internal structure diagram of the computer device can be as shown in Figure 5 The computer device includes a processor, a memory, an input / output interface (I / O) and a communication interface. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The database of the computer device is configured to store data. The input / output interface of the computer device is configured to exchange information between the processor and external devices. The communication interface of the computer device is configured to communicate with external terminals through network connection. The computer program is executed by the processor to implement an automatic test method.

[0142] Those skilled in the art can understand that Figure 5 the structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0143] In an example embodiment, a computer device is provided, comprising a memory and a processor, the memory storing a computer program, and the processor implementing the automatic testing method provided in the above method embodiments when executing the computer program.

[0144] In an example embodiment, a computer readable storage medium is provided, storing a computer program, and the computer program implementing the automatic testing method provided in the above method embodiments when executed by a processor.

[0145] In an example embodiment, a computer program product is provided, comprising a computer program, and the computer program implementing the automatic testing method provided in the above method embodiments when executed by a processor.

[0146] A person of ordinary skill in the art can understand that all or part of the processes in the above method embodiments can be completed by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above method embodiments. Any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of a non-volatile and volatile memory. The non-volatile memory can include a read-only memory (ROM), a magnetic tape, a floppy disk, a flash memory, an optical storage, a high-density embedded non-volatile memory, a resistive memory (ReRAM), a magnetoresistive random access memory (MRAM), a ferroelectric memory (FRAM), a phase change memory (PCM), a graphene memory, etc. The volatile memory can include a random access memory (RAM) or an external cache memory, etc. As an illustration but not limitation, the RAM can be in various forms, such as a static random access memory (SRAM) or a dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a blockchain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without being limited thereto.

[0147] Any combination of the technical features in the above embodiments can be made. For the sake of brevity, the foregoing description has not described all possible combinations of the technical features in the above embodiments. However, as long as the combination of the technical features does not contradict, it should be considered within the scope of the present disclosure.

[0148] The above embodiments only express several implementation manners of the present application, and the description is relatively specific and detailed, but it should not be understood as a limitation on the patent scope of the present application. It should be pointed out that, for ordinary skilled persons in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. An automated testing method, characterized by, The method comprises: obtaining a physical device configuration and a test script corresponding to a test task, wherein the physical device configuration comprises a protocol type applied by a physical device, and the test script comprises abstract function call code of an abstract device instance corresponding to the physical device; reading and parsing the test script line by line, in a case where it is determined that the current parsed abstract function call code, identifying an abstract device instance, an operation function, and function parameters corresponding to the current abstract function call code, and determining a protocol type corresponding to the operation function according to the abstract device instance and the physical device configuration; determining a protocol instruction template to which the operation function is bound according to the protocol type; generating a target protocol instruction based on the protocol instruction template and the function parameters.

2. The method of claim 1, wherein, After the obtaining of the physical device configuration and the test script corresponding to the test task, and before the reading and parsing of the test script line by line, the method further comprises: specifying a corresponding physical device configuration for an abstract device instance contained in the test script, to determine an association relationship between the abstract device instance and the physical device configuration; the determining of the protocol type corresponding to the operation function according to the abstract device instance and the physical device configuration comprises: querying an association relationship established by the abstract device instance according to the abstract device instance identified by the abstract function call code, to determine a corresponding physical device configuration; extracting a protocol type associated with the abstract device instance from the physical device configuration, and determining the protocol type as the protocol type corresponding to the operation function.

3. The automated testing method of claim 1, wherein, The physical device configuration further comprises communication interface information, and the communication interface information comprises a communication interface type and interface configuration parameters, wherein the communication interface type comprises at least one of a serial port, a TCP or IP socket, and a CAN card, and the interface configuration parameters comprise at least one of a port number and a baud rate.

4. The automated testing method of claim 3, wherein, After the generation of the target protocol instruction, the method further comprises: converting the target protocol instruction into a byte stream, and sending the byte stream to the corresponding physical device through a communication interface in the physical device configuration.

5. The automated testing method of claim 4, wherein, After the sending of the byte stream to the corresponding physical device, the method further comprises: receiving a return byte stream through the communication interface, calling a corresponding protocol implementation component to parse the return byte stream, and updating a script context based on parsed information.

6. The automated testing method of claim 1, wherein, The determining of the protocol instruction template to which the operation function is bound according to the protocol type comprises: querying a binding relationship between an abstract function and a protocol instruction template according to the protocol type, wherein the binding relationship is mapping configuration data of the abstract function and the protocol instruction template under different protocol types; and determining the protocol instruction template corresponding to the operation function based on the binding relationship.

7. The automated testing method of claim 1, wherein, In the process of reading and parsing the test script line by line, if it is determined that the current parsed line is not abstract function call code, the method continues to parse a next action of the test script.

8. An automated test device, characterized by, The device comprises: An acquisition module acquires a physical device configuration corresponding to a test task and a test script, the physical device configuration including a protocol type applied by a physical device, and the test script including an abstract function call code of an abstract device instance corresponding to the physical device; An identification configuration module is configured to read and parse the test script line by line, identify an abstract device instance, an operation function and a function parameter corresponding to a current abstract function call code in a case where the current abstract function call code is determined, and determine a protocol type corresponding to the operation function according to the abstract device instance and the physical device configuration; An instruction generation module is configured to determine a protocol instruction template bound to the operation function according to the protocol type, call a corresponding protocol implementation component for format processing based on the protocol instruction template and the function parameter, and generate a target protocol instruction.

9. An automated test equipment, characterized by, comprising: a memory and a processor, the memory storing a computer program, and the processor implementing the method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, a computer program stored thereon, the computer program being executed by a processor to implement the method according to any one of claims 1 to 7.

Images