WO2014101383A1 - 一种测试驱动程序的方法及系统 - Google Patents

一种测试驱动程序的方法及系统 Download PDF

Info

Publication number
WO2014101383A1
WO2014101383A1 PCT/CN2013/078794 CN2013078794W WO2014101383A1 WO 2014101383 A1 WO2014101383 A1 WO 2014101383A1 CN 2013078794 W CN2013078794 W CN 2013078794W WO 2014101383 A1 WO2014101383 A1 WO 2014101383A1
Authority
WO
WIPO (PCT)
Prior art keywords
output
driver
response frame
preset response
test
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2013/078794
Other languages
English (en)
French (fr)
Inventor
刘思伟
邱彦卿
汤飞
王全胜
王庆华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GRG Banking Equipment Co Ltd
Original Assignee
GRG Banking Equipment Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GRG Banking Equipment Co Ltd filed Critical GRG Banking Equipment Co Ltd
Publication of WO2014101383A1 publication Critical patent/WO2014101383A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis

Definitions

  • This invention relates to the field of program testing and, more particularly, to a method and system for testing a driver.
  • the driver is a program implemented by the host computer (PC side), and sends a command to the lower computer with a certain communication protocol (the lower computer is referred to as hardware in the present invention, and the lower computer processing program is hereinafter referred to as a hardware program) to reach the control hardware.
  • the driver is usually provided to the upper-level user in the form of an interface (function).
  • the driver test mainly tests the function of the host computer (PC side) program to control the hardware device, and whether it can provide the upper layer user with the control program with correct function and superior performance.
  • Step one the input to the test: the input parameters of the interface, the (initial or in-execution) state of the hardware;
  • Step 2 check if the expected output is met: the output parameters and return values of the interface, the final state of the hardware, the hardware performance (action, output, etc.).
  • Step 1 Input parameters of the incoming interface: Print string "abed” ; Set the input of the hardware status: The paper source is sufficient and the device is normal.
  • Step 2 check whether it is consistent with the expected output.
  • Hardware output Output a piece of paper, "abed” is printed on the first line of the page, and the interface parameter content is output: The interface is successfully called, there is no fault information.
  • FIG. 1 shows a general driver test system and its data flow, including the following steps:
  • the driver packages the instructions translated by the upper layer into instructions understood by the hardware program, and presses The hardware program is issued by the handshake method specified in the agreement;
  • the initial or in-execution state of the hardware affects the result of the hardware program processing instructions
  • the hardware output information (hardware real-time status and actual execution result) is fed back to the hardware program;
  • the hardware program generates an execution result of the instruction according to the feedback information of the hardware and the information generated by the internal execution process, and the data frame format and the handshake mode that have been agreed upon are transmitted back to the driver;
  • the driver receives the command response data frame returned by the hardware program in the same handshake mode, parses the response information into the upper layer according to the protocol, and finally outputs the interface output parameter and the return value.
  • the focus of the tester is on the interface and hardware performance, and between the input and output, the data stream is complexly converted, and the general test does not completely cover the process.
  • a large black box is generated between the input and the desired output.
  • the processing flow of the intermediate data stream is correct. It cannot be accurately tested only through the interface and hardware output check. During the actual test, all input and output conditions are traversed. The efficiency is very low, and the uncertainty of the internal state of the hardware causes the tester to not be able to traverse all hardware state inputs.
  • embodiments of the present invention provide a method and system for testing a driver.
  • the embodiments of the present invention provide the following technical solutions:
  • a method of testing a driver including:
  • the driver error is output when the actual output does not meet the desired output.
  • the expected output is specifically outputting the device status abnormality.
  • the expected output is specifically outputting the device status as normal.
  • the expected output is specifically an error in the format of outputting the preset response frame.
  • the desired output is specifically formatted to output the preset response frame.
  • the expected output is specifically an error in the handshake protocol timing of outputting the preset response frame.
  • the expected output is specifically correct for the handshake protocol timing of outputting the preset response frame.
  • a test system comprising:
  • a first sending module configured to send a test parameter to the driver
  • a receiving module configured to receive a command frame sent by the driver according to the test parameter
  • a second sending module configured to send a preset response frame to the driver, where the preset response frame corresponds to a desired output, where The expected output is a result output after the preset response frame is processed if the driver is correct
  • An obtaining module configured to obtain an actual output that is output by the driver according to the preset response frame
  • a determining module configured to determine whether the actual output meets the expected output
  • an output module configured to: when the actual output meets the expected output, output the driving program is correct; when the actual output does not meet the expected output, output the driving program error.
  • the technical solution provided by this embodiment has the following advantages and features:
  • the present invention simulates the trueness of the hardware output by preset response frames and can simulate a scenario that cannot be implemented by the hardware by using a preset response frame, thereby comprehensively testing the driver and eliminating the test process.
  • the limitation brought by the operation hardware reduces the workload of manually inputting the test parameters and comparing the test results. Therefore, the solution provided by the present invention can comprehensively test the driver and improve the test efficiency.
  • FIG. 1 is a flowchart of a conventional driver test system and a data flow chart thereof provided by the present invention
  • FIG. 2 is a flowchart of a method for testing a driver provided by the present invention
  • FIG. 3 is a flow chart of another method for testing a driver provided by the present invention
  • FIG. 4 is a block diagram of a test system provided by the present invention
  • FIG. 5 is a flowchart of still another method for testing a driver according to the present invention
  • FIG. 6 is a schematic diagram of a normal handshake sequence provided by the present invention
  • FIG. 7 is a schematic diagram of an abnormal handshake sequence according to the present invention.
  • FIG. 8 is a flowchart of still another method for testing a driver according to the present invention
  • FIG. 9 is a schematic diagram of a protocol format of a command frame or a response frame provided by the present invention.
  • Figure 10 is a block diagram of another test system provided by the present invention.
  • Embodiments of the present invention provide a method for testing a driver to comprehensively test a driver Order, and improve test efficiency. Since there are various ways to implement the above method of testing the driver, the following detailed description is given by way of specific embodiments:
  • FIG. 2 shows a method for testing a driver, which is applied to a test system, including:
  • Step S21 Send test parameters to the driver.
  • test system mentioned in this embodiment is a virtual system for simulating real hardware, and belongs to test software.
  • the following embodiment will describe the test system in detail.
  • test system can pre-store all test parameters in a database or table, such as an Excel spreadsheet.
  • a database or table such as an Excel spreadsheet.
  • test parameters the test parameters need to be read from the database or table in the order of storage, and then the test system sends the test parameters just read to the driver.
  • Test parameters the test inputs mentioned in the background, the input parameters of the interface, the hardware (initial or in-execution) state, and the input of each test parameter is a new test case.
  • Step S22 Receive a command frame sent by the driver according to the test parameter; wherein, after receiving the test parameter, the driver needs to analyze the test parameter, and the driver sends a command frame to the test system according to the test parameter.
  • Step S23 Send a preset response frame to the driver, where the preset response frame corresponds to a desired output, and the expected output is output after the preset response frame is processed in a case where the driver is correct.
  • the preset response frame is a response frame sent by the test system to simulate real hardware.
  • the preset response frame passes through the automated test tool, enumerates all possible response frames of the hardware, and can even completely simulate the real hardware.
  • the expected output is the result of outputting the preset response frame after the driver is correct, so the expected output can be understood as the result that should be output after the driver receives the preset response frame if the driver is correct. , so expect the output to be the result of an ideal driver output. Then the preset response frame is in a corresponding relationship with the desired output.
  • the test system also adjusts the preset response frame accordingly. For example, for the test driver to analyze the accuracy of the hardware response frame content
  • the content of the preset response frame can be set to abnormal or normal device state, then the content expected to be output is abnormal or normal, so that by comparing the expected output with the actual output, it can be determined whether the driver can An abnormality or normal status of the device was identified.
  • the content of the preset response frame can be set to the handshake protocol timing, then the expected output content is the handshake protocol timing is correct or incorrect, thereby comparing the expected output with the actual output.
  • the preset response frame can be set to the correct or incorrect data frame format, then the desired output content is the data frame format is correct or incorrect, thereby comparing the expected output with the actual output result. It can be judged whether the driver can recognize the accuracy of the data frame format. The following will be explained by specific examples.
  • Step S24 Acquire an actual output that is output by the driver according to the preset response frame; wherein, the actual output is a result of the real output of the driver after receiving the preset response frame, and the actual output may be the same as the expected output. It may also be different.
  • Step S25 When the actual output meets the expected output, outputting the driving program is correct
  • the expected output is the output of the driver under ideal conditions, and when designing the driver, it is hoped that the driver can output the desired output when receiving the preset response frame, so if the actual output and expected output When it matches, it means that the driver is correct.
  • Step S26 When the actual output does not meet the expected output, the driver error is output.
  • step S25 if the actual output does not meet the expected output, then the driver is wrong.
  • the real response of the hardware output is simulated by the preset response frame, and the scenario that the hardware cannot implement is simulated by the preset response frame, so that the driver can be tested comprehensively, and the test process operation is eliminated.
  • the limitations brought by the hardware reduce the workload of manually inputting the test parameters and comparing the test results. Therefore, the solution provided by the present invention can fully test the drive. Programs and improve test efficiency.
  • Embodiment 2
  • FIG. 3 shows a method for testing a driver, which is applied to a test system, specifically for testing the accuracy of analyzing the hardware response frame content of the driver.
  • test of this implementation can also be directly implemented by hardware testing, but the input of the hardware initial or execution state can only be realized by manual operation of external hardware, and the manual operation cannot cover all the instructions in the communication protocol. Responding to the content of the data set, so the test of real hardware is not effective.
  • the testing method provided in this embodiment includes the following steps:
  • Step S31 Pass the input parameters required by the test case to the driver interface, and execute the driver interface function.
  • Step S32 According to the requirements of the use case, the tester modifies the response frame content returned by the virtual device to the driver.
  • Step S33 Check whether the output result of the driver conforms to the expected result of the use case. If yes, the processing of the response data by the driver is performed accurately according to the communication protocol and the instruction set; otherwise, the analysis of the response data by the driver is flawed.
  • Step S34 in conjunction with the automated test script, enumerates all possible response frames of the hardware, including normal data and abnormal data, and executes the test cases in large quantities.
  • the test system includes a driver 12, a virtual communication module 13, a virtual device 14, and an automated test script 11, and the virtual device 14 is used for simulation. Real hardware.
  • the automated test script which is implemented by QTP (Quick Test Professional) script, plays the role of control input and evaluation result in the system. It undertakes three main tasks and passes the input parameters of the driver.
  • the virtual device determines the data to be returned by the hardware device, and compares the difference between the actual output and the expected result to determine whether the use case execution is passed.
  • a virtual device which is another process that is completely independent of the driver. It must have the following functions. First, it automatically receives data sent from the driver and automatically sends data to the driver. Third, the user can set the time interval for data return through the software interface.
  • a virtual communication module which establishes a bridge between the virtual device and the driver, and can use the critical section resource to access the mutually exclusive manner to realize inter-process communication.
  • test run by this test system is shown in Table 1.
  • the specific test process is:
  • Step 1 Save all test cases in an Excel spreadsheet, such as the Test Print (char* string) interface.
  • step two the QTP script reads the first line of the table, passes the input parameters to the driver interface, and executes the driver interface function.
  • Step 3 After the virtual device is commanded by the driver, the QTP script controls the virtual device to return the required value to the driver according to the value in the table.
  • Step 4 After the interface is executed, the QTP script compares the expected result with the actual output value to determine whether the use case passes.
  • Step 5 The QTP script loops through the use cases in the Excel table, and proceeds to step one to begin execution of the next use case until all use cases have been executed.
  • Step 3 can fully simulate the situation where the actual hardware device cannot be simulated by hand.
  • the virtual device only simulates the content of the response frame data field, ignoring the handshake protocol abnormal situation simulation, and the communication between the virtual device and the driver defaults to the normal handshake. In progress.
  • the virtual device in the second embodiment cannot test the handshake protocol of the driver. Therefore, in this embodiment, on the basis of the driving device test system proposed in the second embodiment, another driving test method is further proposed, and the four module structures of the test system are used: the driver to be tested, the virtual communication module software, the virtual device, And the automated test script, just redesigned the virtual device part, so that the virtual device simulates the hardware communication handshake protocol layer.
  • FIG. 5 shows a method for testing a driver, which is applied to a test system, specifically for testing the accuracy of a handshake protocol at a communication link layer.
  • the testing method provided in this embodiment includes the following steps:
  • Step S41 executing the driver interface function according to the test case requirement.
  • Step S42 After receiving the command frame sent by the driver, the virtual device requests the test case, and the virtual device sends a response frame to the driver.
  • Step S43 observing the output result of the driver.
  • Step S44 in conjunction with the automated test script, execute the use cases in batches, enumerate various response timings of the hardware communication handshake protocol layer for the virtual device, and test whether the driver completely covers the processing of various normal and abnormal response timings.
  • FIG. 6 is a schematic diagram of a normal handshake timing
  • FIG. 7 is a schematic diagram of an abnormal handshake timing.
  • the test run by the test system is shown in the table:
  • the specific test process is as follows: Step one, all the cases are stored in the table. Different from the second embodiment, the parameters of the virtual device setting one column become the response frames.
  • the timing of the table, in which the use case in the table is specifically the use case of the abnormal timing in FIG.
  • step two the QTP script reads the input data and executes the interface.
  • step 3 The virtual device receives a sequence of command frames sent by the driver, and the QTP script returns to the driver according to the response frame timing of the "virtual device setting".
  • step four the QTP script compares the output with the expected result and determines whether the use case is executed.
  • step 5 The QTP script loops through the use cases in the Excel table, and proceeds to step one to begin execution of the next use case until all use cases have been executed.
  • step three the execution process of step three is as follows.
  • the virtual device When the virtual device receives the command frame for the first time, it returns NAK. The expected result is that the driver resends the command frame. If the driver has no defects, go to (2), otherwise, go to step 4.
  • the virtual device receives the command frame for the second time and still returns NAK.
  • the expected result is that the driver resends the command frame. If the driver has no defects, go to (3), otherwise, go to step 4.
  • the virtual device returns ACK when receiving the command frame for the third time.
  • the expected result is that the driver sends ENQ. If the driver has no defects, go to (4), otherwise, go to step 4.
  • the virtual device only simulates the content of the response frame data field, ignoring the abnormal situation simulation of the command frame and the response frame format, and the communication between the virtual device and the driver is performed by default in the handshake process under normal conditions.
  • the virtual device in the second embodiment cannot test the driver's handshake protocol. Therefore, based on the driving device test system proposed in the second embodiment, the present embodiment continues to propose another driving test method, which follows the four module structures of the test system: the driver to be tested, the virtual communication module software, the virtual device, and The automated test script simply redesigns the virtual device part to enable the virtual device to emulate the hardware's communication handshake protocol layer.
  • FIG. 8 shows a method for testing a driver, which is applied to a test system, and is specifically used to parse the accuracy of a hardware return response frame.
  • the testing method provided in this embodiment includes the following steps:
  • Step S51 executing the driver interface function according to the test case requirement.
  • Step S52 the virtual device returns a response frame of a normal or abnormal format to the driver according to the normal timing specified by the handshake protocol.
  • step S53 the output result of the driver is observed.
  • step S54 the use case is executed in batch with the automated test script, and the virtual device traverses the response frame of various normal or abnormal formats to the driver, and tests whether the driver parses the frame format to have a defect.
  • the protocol format of the command frame or the response frame is generally as shown in FIG. 9. Specifically, for example, the protocol specifies that the actual length of the data field in the format of the response frame must be consistent with the data length. If the actual length of the data field is inconsistent with the data length, the driver It is necessary to determine that the response frame is illegal. For another example, the check value of the response frame must match the content of the data field. If some byte data in the data frame is tampered with, the calculated check value is inconsistent with the saved check value, and the response frame is also considered illegal. .
  • test run by this test system is shown in Table 3.
  • the specific test process is:
  • Step one save all the cases in the table, "Virtual device settings" column
  • step two the QTP script reads the input data and executes the interface.
  • Step 3 After the virtual device receives the command frame, the QTP script sets the response frame of the virtual device according to the content requirement of the “virtual device setting” and returns it to the driver.
  • Step 4 The QTP script compares the output and the expected result to determine whether the use case is executed.
  • Step 5 The QTP script loops through the use cases in the Excel table, and proceeds to step one to begin execution of the next use case until all use cases have been executed.
  • Step 3 the execution process of Step 3 is as follows.
  • FIG. 10 shows a test system 2, which includes:
  • a first sending module 21 configured to send test parameters to the driver 3;
  • the receiving module 22 is configured to receive a command frame sent by the driver 3 according to the test parameter;
  • a second sending module 23 configured to send a preset response frame to the driver 3, where the preset response frame corresponds to a desired output, and the expected output is processed after the driver 3 is correct The result of the output after the preset response frame;
  • the obtaining module 24 is configured to obtain an actual output that is output by the driver 3 according to the preset response frame;
  • a determining module 25 configured to determine whether the actual output meets the expected output
  • an output module 26 configured to: when the actual output meets the expected output, output the driver 3 correctly; when the actual output When the desired output is not met, the driver 3 error is output.
  • the method and the test system for testing a driver proposed by the present invention simulate a hardware communication mode by software, and simulate a scenario that cannot be realized by real hardware.
  • the system can simulate any hardware to return any conventional or abnormal data.
  • to meet the test sufficiency requirements for communication between the driver and the hardware device, and according to the characteristics of the three independent parts of the device driver test system, apply the corresponding test method, so that the test more comprehensively covers the key content of the driver code Excludes the limitations of the operating hardware of the test process.
  • the system simultaneously applies automated test methods to reduce the workload of manually inputting test data and comparing test results, greatly improving the sufficiency and efficiency of device driver testing.
  • FIG. 1 to FIG. 10 are only preferred embodiments introduced by the present invention.
  • those skilled in the art can design more embodiments on this basis, and therefore will not be described here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了一种测试驱动程序的方法及系统，包括：向驱动程序发送测试参数；接收驱动程序根据测试参数发送的命令帧；向驱动程序发送预设响应帧，预设响应帧对应有期望输出，期望输出为在驱动程序正确的情况下处理完预设响应帧后输出的结果；获取驱动程序根据预设响应帧所输出的实际输出；当实际输出符合期望输出时，则输出驱动程序正确；当实际输出不符合期望输出时，则输出驱动程序错误。本发明可以通过预设响应帧来模拟硬件无法实现的场景，从而可以全面的对驱动程序进行测试，排除了测试过程操作硬件带来的局限，减少人工输入测试参数及比对测试结果的工作量，因此，本发明提供的方案可以全面的测试驱动程序，并提高测试效率。

Description

一种测试驱动程序的方法及系统 本申请要求于 2012 年 12 月 27 日提交中国专利局、 申请号为 201210581467.0、 发明名称为 "一种测试驱动程序的方法及系统" 的中国 专利申请的优先权， 其全部内容引用在本申请中。
技术领域
本发明涉及程序测试领域， 更具体的说， 涉及一种测试驱动程序的方 法及系统。
背景技术
驱动程序， 是上位机（PC端）实现的程序， 以一定的通讯协议发送命 令给下位机（下位机在本发明中称为硬件， 下位机处理的程序下文称作硬 件程序）， 达到控制硬件输出的目的。 驱动程序一般以接口 （函数）的方式 提供给上层用户调用。
驱动程序测试， 主要是测试上位机（ PC端）程序控制硬件设备的功能 性， 是否能为上层用户提供功能正确、 性能优越的控制程序。
现在的驱动程序测试的一般方法是：
步骤一， 测试的输入： 接口的输入参数， 硬件的 （初始或执行中）状 态；
步骤二， 检查是否符合期望输出结果： 接口的输出参数和返回值， 硬 件的最终状态， 硬件的表现（动作、 输出等等）。
例如， 测试打印机在正常状态下的打印功能， 需要如下步骤： 步骤一， 传入接口输入参数： 打印字符串 "abed" ; 设置硬件状态的输 入： 纸源充足， 设备正常。
步骤二， 检查是否与期望输出一致， 硬件输出： 输出一张纸， "abed" 在页面首行打印，接口参数内容输出： 本次接口调用成功， 没有故障信息。
请参见图 1所示，图 1所示的为一般的驱动程序测试系统及其数据流， 包括如下步骤：
1、 上层理解的指令下发给驱动程序；
2、驱动程序将上层理解的指令翻译打包成硬件程序理解的指令，并按 协议规定的握手方式下发各硬件程序；
3、 硬件的初始或执行中的状态会影响到硬件程序处理指令的结果；
4、硬件程序处理指令， 完成控制硬件的目的， 硬件最终通过一定的状 态、 动作和输出表现；
5、硬件的输出信息（硬件实时状态和实际执行结果）反馈给硬件程序；
6、硬件程序根据硬件的反馈信息和内部执行过程产生的信息，生成指 令的执行结果， 已协规定的数据帧格式和握手方式回传给驱动程序；
7、 驱动程序按相同的握手方式接收硬件程序返回的命令响应数据帧， 按照协议解析成上层理解的响应信息， 最终以接口输出参数和返回值的形 式输出。
在对现有技术的研究和实践过程中， 本发明的发明人发现现有技术存 在以下问题：
从输入和期望输出内容分析， 测试人员重点关注的地方集中在接口和 硬件表现， 而在输入和输出之间， 数据流是经过复杂的转换的， 一般测试 并不能全面覆盖这个过程的， 此时在输入和期望输出之间产生了一个大黑 盒， 中间数据流的各个处理流程是否正确， 只通过接口和硬件的输出检查 是不能准确测试的， 在实际测试过程中， 遍历所有输入和输出情况的效率 是很低的， 而且硬件内部状态的不确定性导致测试人员无法遍历所有硬件 状态的输入。
因此， 提出一种测试效率高， 测试全面的驱动程序的方法和测试系统 是非常必要的。
发明内容
有鉴于此， 本发明实施例提供了一种测试驱动程序的方法及系统。 为了实现上述目的， 本发明实施例提供了以下技术方案：
一种测试驱动程序的方法， 包括：
向驱动程序发送测试参数；
接收所述驱动程序根据所述测试参数发送的命令帧；
向所述驱动程序发送预设响应帧， 所述预设响应帧对应有期望输出， 所述期望输出为在所述驱动程序正确的情况下处理完所述预设响应帧后输 出的结果；
获取所述驱动程序根据所述预设响应帧所输出的实际输出； 当所述实 际输出符合所述期望输出时， 则输出所述驱动程序正确；
当所述实际输出不符合所述期望输出时， 则输出所述驱动程序错误。 优选地， 当所述预设响应帧的内容为设备状态异常时， 则所述期望输 出具体为输出所述设备状态异常。
优选地， 当所述预设响应帧的内容为设备状态正常时， 则所述期望输 出具体为输出所述设备状态正常。
优选地， 当所述预设响应帧的格式错误时， 则所述期望输出具体为输 出所述预设响应帧的格式出现错误。
优选地， 当所述预设响应帧的格式正确时， 则所述期望输出具体为输 出所述预设响应帧的格式正确。
优选地， 当所述预设响应帧的握手协议时序错误时， 则所述期望输出 具体为输出所述预设响应帧的握手协议时序出现错误。
优选地， 当所述预设响应帧的握手协议时序正确时， 则所述期望输出 具体为输出所述预设响应帧的握手协议时序正确。
一种测试系统， 包括：
第一发送模块， 用于向所述驱动程序发送测试参数；
接收模块， 用于接收所述驱动程序根据所述测试参数发送的命令帧； 第二发送模块， 用于向所述驱动程序发送预设响应帧， 所述预设响应 帧对应有期望输出， 所述期望输出为在所述驱动程序正确的情况下处理完 所述预设响应帧后输出的结果；
获取模块， 用于获取所述驱动程序根据所述预设响应帧所输出的实际 输出；
判断模块， 用于判断所述实际输出是否符合所述期望输出；
输出模块， 用于当所述实际输出符合所述期望输出时， 则输出所述驱 动程序正确； 当所述实际输出不符合所述期望输出时， 则输出所述驱动程 序错误。
与现有技术相比， 本实施例提供的技术方案具有以下优点和特点： 在本发明提供的方案中， 本发明通过预设响应帧来模拟硬件输出的真 而且可以通过预设响应帧来模拟硬件无法实现的场景， 从而可以全面的对 驱动程序进行测试， 排除了测试过程操作硬件带来的局限， 减少人工输入 测试参数及比对测试结果的工作量， 因此， 本发明提供的方案可以全面的 测试驱动程序， 并提高测试效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对 实施例或现有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员 来讲， 在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的附 图。
图 1为本发明所提供的现有驱动程序测试系统及其数据流程图； 图 2为本发明所提供的一种测试驱动程序的方法的流程图；
图 3为本发明所提供的另一种测试驱动程序的方法的流程图； 图 4为本发明所提供的一种测试系统的模块图；
图 5为本发明所提供的又一种测试驱动程序的方法的流程图； 图 6为本发明所提供的正常的握手时序示意图；
图 7为本发明所提供的异常的握手时序示意图；
图 8为本发明所提供的又一种测试驱动程序的方法的流程图； 图 9为本发明所提供的命令帧或响应帧的协议格式示意图。
图 10为本发明所提供的另一种测试系统的模块图。
具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进 行清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没 有做出创造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的 范围。
本发明实施例提供了一种测试驱动程序的方法， 以全面的测试驱动程 序， 并提高测试效率。 由于上述测试驱动程序的方法的具体实现存在多种 方式， 下面通过具体实施例进行详细说明：
实施例一
请参见图 2所示， 图 2所示的为一种测试驱动程序的方法， 应用于测 试系统， 包括：
步骤 S21、 向所述驱动程序发送测试参数；
其中， 本实施例中提到的测试系统为用于模拟真实硬件的虚拟系统， 属于测试软件， 下面的实施例会对该测试系统做详细说明。
测试系统可以预先将所有的测试参数存放在数据库或表格中， 例如 Excel表格中。在测试系统发送测试参数时，需要从数据库或表格中按照存 储的顺序来读取测试参数， 然后测试系统再向驱动程序发送刚刚读取到的 测试参数。 测试参数， 为背景技术中提到的测试输入， 接口的输入参数， 硬件的 （初始或执行中）状态， 每一次测试参数的输入都为一个新的测试 用例。
步骤 S22、 接收所述驱动程序根据所述测试参数发送的命令帧； 其中， 驱动程序在接收到测试参数后， 需要对测试参数进行分析， 驱 动程序根据测试参数来向测试系统发送命令帧。
步骤 S23、 向所述驱动程序发送预设响应帧， 所述预设响应帧对应有 期望输出， 所述期望输出为在所述驱动程序正确的情况下处理完所述预设 响应帧后输出的结果；
预设响应帧是为测试系统模拟真实硬件所发出响应帧， 预设响应帧通 过自动化测试工具， 枚举硬件所有可能返回的响应帧， 而且， 甚至可以完 全模拟真实硬件无法通过手工模拟操作硬件状态的情况。 期望输出是在驱 动程序正确的情况下处理完预设响应帧后输出的结果， 所以期望输出可以 理解为如果驱动程序是正确无误的， 那么在驱动程序收到预设响应帧后应 该输出的结果， 所以期望输出是一个理想状态下驱动程序输出的结果。 那 么预设响应帧与期望输出是相对应的关系。
对于需要测试驱动程序的不同方面， 那么测试系统也会对预设响应帧 进行对应的调整。 例如， 对于测试驱动程序分析硬件响应帧内容的准确性 方面， 可以将预设响应帧的内容设置为设备状态异常或正常， 那么期望输 出的内容就为设备状态异常或正常， 从而通过对比期望输出和实际输出的 结果， 就可判断出驱动程序是否能够识别出设备状态的异常或正常。 对于 测试通讯链路层的握手协议时序的准确性， 可以将预设响应帧的内容设置 为握手协议时序， 那么期望输出的内容就为握手协议时序正确或错误， 从 而通过对比期望输出和实际输出的结果， 就可判断出驱动程序是否能够识 别出握手协议时序的正确或错误。 对于测试响应帧格式解析的准确性， 可 以将预设响应帧设置为数据帧格式正确或错误， 那么期望输出的内容就为 数据帧格式正确或错误， 从而通过对比期望输出和实际输出的结果， 就可 判断出驱动程序是否能够识别出数据帧格式的准确性。 下文将会通过具体 的实例进行说明。
步骤 S24、获取所述驱动程序根据所述预设响应帧所输出的实际输出； 其中， 实际输出为驱动程序在接收了预设响应帧后真实输出的结果， 这个实际输出与期望输出可能相同， 也可能不同。
步骤 S25、 当所述实际输出符合所述期望输出时， 则输出所述驱动程 序正确；
其中， 期望输出为驱动程序在理想状态下的输出结果， 而且在设计驱 动程序的时候， 就是希望驱动程序能够在接收预设响应帧的情况下来输出 期望输出， 所以如果实际输出的结果与期望输出相符合时， 则可以说明驱 动程序是正确的。
步骤 S26、 当所述实际输出不符合所述期望输出时， 则输出所述驱动 程序错误。
其中， 基于步骤 S25中的理由， 如果实际输出不符合期望输出， 那么 说明驱动程序是错误的。
在图 2所示的实施例中， 通过预设响应帧来模拟硬件输出的真实响应 通过预设响应帧来模拟硬件无法实现的场景， 从而可以全面的对驱动程序 进行测试， 排除了测试过程操作硬件带来的局限， 减少人工输入测试参数 及比对测试结果的工作量， 因此， 本发明提供的方案可以全面的测试驱动 程序， 并提高测试效率。 实施例二
请参见图 3所示， 图 3所示的为一种测试驱动程序的方法， 应用于测 试系统， 具体用于测试驱动程序的分析硬件响应帧内容的准确性。
本实施的测试也可直接通过对硬件测试实现， 但是硬件初始或执行中 状态的输入， 只能通过人工操作外在的硬件实现， 而这种人工式的操作是 无法覆盖通讯协议中所有指令的响应数据集的内容， 所以采用对真实硬件 进行测试的效果不佳。
具体的， 本实施例提供的测试方法包括以下步骤：
步骤 S31、 向驱动程序接口传入测试用例要求的输入参数， 执行驱动 程序接口函数。
步骤 S32、 按照用例的要求， 测试人员修改虚拟设备返回给驱动程序 的响应帧内容。
步骤 S33、 检查驱动程序的输出结果是否符合用例的期望结果， 若是， 驱动程序对响应数据的处理是准确按照通信协议和指令集执行的， 否则， 驱动程序对响应数据的分析存在缺陷。
步骤 S34、 配合自动化测试脚本， 枚举硬件所有可能返回的响应帧， 包括正常数据和异常数据， 大批量地执行测试用例。
下面通过具体实例来详细的说明图 3所示的方案。
请参见图 4所示， 图 4所示的为本实施例提到的测试系统， 该测试系 统包括驱动程序 12、虚拟通信模块 13、虚拟设备 14和自动化测试脚本 11 , 虚拟设备 14用于模拟真实硬件。
在图 4所示的方案中， 自动化测试脚本， 这里选用 QTP ( Quick Test Professional )脚本实现， 在系统中担任控制输入和评价结果的角色， 共承 担三个主要任务， 传递驱动程序的输入参数， 通过虚拟设备确定硬件设备 需返回的数据， 比对实际输出和期望结果的差异判断用例执行是否通过。
虚拟设备， 它是完全独立于驱动程序的另一个进程， 必须拥有以下功 能， 第一， 自动接收从驱动程序下发的数据， 自动向驱动程序发送数据； 第三， 用户可通过软件的界面设定数据返回的时间间隔。
虚拟通讯模块， 它建立起虚拟设备和驱动程序两个进程之间通讯的桥 梁， 可采用临界区资源访问互斥的方式， 实现进程间通讯。
表 1
Figure imgf000010_0001
本测试系统运行的测试用例如表 1所示， 具体的测试过程为:
步骤一，将所有测试用例保存在 Excel表格中，如测试 Print(char* string) 接口。
步骤二， QTP脚本读取表的第一行内容， 将输入参数传给驱动程序接 口， 执行驱动程序接口函数。
步骤三， 虚拟设备受到驱动程序的命令后， QTP脚本根据表格中的值 控制虚拟设备向驱动程序返回需要的值。
步骤四， 接口执行完成后， QTP脚本对比期望结果和实际输出的值， 判别该用例是否通过。
步骤五， QTP脚本循环读取 Excel表格中的用例， 转至步骤一， 开始 执行下一个用例， 直到所有用例执行完毕。
具体的， 以表 1中测试用例为例， 步骤三虚拟设备收到驱动程序的命 令帧后， 根据用例中要求的值 "缺纸传感器 = 1 " , 将打印机缺纸的信息 以及 Print接口执行情况的信息组帧，返回给驱动程序。 步骤三可完全模拟 实际硬件设备无法通过手工模拟的情况。 实施例三
在实施例二中， 虚拟设备只模拟响应帧数据域的内容， 忽略了握手协 议异常情况模拟， 虚拟设备与驱动之间的通讯默认在正常情况下的握手过 程中进行。 实施例二中的虚拟设备无法对驱动程序的握手协议进行测试。 所以本实施例在实施例二提出的驱动设备测试系统的基石出上， 继续提出另 一种驱动测试方法， 沿用测试系统的四大模块结构： 待测试驱动程序， 虚 拟通信模块软件， 虚拟设备， 及自动化测试脚本， 只是对虚拟设备部分重 新设计， 令虚拟设备模拟硬件的通讯握手协议层。
请参见图 5所示， 图 5所示的为一种测试驱动程序的方法， 应用于测 试系统， 具体用于测试通讯链路层的握手协议的准确性。 本实施例提供的 测试方法包括以下步骤：
步骤 S41 , 按测试用例要求， 执行驱动程序接口函数。
步骤 S42, 虚拟设备收到驱动程序发过来的命令帧后， 按测试用例要 求， 虚拟设备向驱动程序发送响应帧。
步骤 S43 , 观察驱动程序的输出结果。
步骤 S44, 配合自动化测试脚本批量执行用例， 对虚拟设备枚举硬件 通讯握手协议层的各种应答时序， 测试驱动程序是否完全覆盖对各种正常 及异常应答时序的处理。
下面通过具体实例来详细的说明图 5所示的方案。
请参见图 6和图 7所示， 图 6所示的为正常的握手时序示意图， 图 7 所示的为异常的握手时序示意图。
表 2
Figure imgf000011_0001
本测试系统运行的测试用例如表：所示， 具体的测试过程为： 步骤一， 将所有案例存入表格中， 与实施例二不同的是， 虚拟设备设 置一列的参数变成了各响应帧的时序 , 其中， 表中的用例具体为图 7中异 常时序的用例。
步骤二， QTP脚本读取输入数据, 执行接口。 步骤三， 虚拟设备接收到驱动程序下发的一序列命令帧， QTP脚本按 照 "虚拟设备设置" 的响应帧时序， 返回给驱动程序。
步骤四， QTP脚本比较输出和期望结果， 判断用例是否执行通过。 步骤五， QTP脚本循环读取 Excel表格中的用例， 转至步骤一， 开始 执行下一个用例， 直到所有用例执行完毕。
具体的， 针对表中的案例， 步骤三的执行过程如下，
(1)虚拟设备第一次收到命令帧时返回 NAK, 期望结果是驱动程序重 发命令帧， 如果驱动程序没有缺陷， 转至 (2), 否则， 转至步骤四，
(2)虚拟设备第二次收到命令帧仍返回 NAK, 期望结果是驱动程序重 发命令帧， 如果驱动程序没有缺陷， 转至 (3), 否则， 转至步骤四，
(3)虚拟设备第三次收到命令帧时返回 ACK, 期望结果是驱动程序发 送 ENQ, 如果驱动程序没有缺陷， 转至 (4) ， 否则， 转至步骤四，
(4)虚拟设备收到 ENQ后， 返回硬件程序执行结果的响应帧， 转至步 骤四。 实施例四
在实施例二中， 虚拟设备只模拟响应帧数据域的内容， 忽略了命令帧 和响应帧格式的异常情况模拟， 虚拟设备与驱动之间的通讯默认在正常情 况下的握手过程中进行。 实施例二中的虚拟设备无法对驱动程序的握手协 议进行测试。所以本实施例在实施例二提出的驱动设备测试系统的基础上， 继续提出另一种驱动测试方法， 沿用测试系统的四大模块结构： 待测试驱 动程序， 虚拟通信模块软件， 虚拟设备， 及自动化测试脚本， 只是对虚拟 设备部分重新设计， 令虚拟设备模拟硬件的通讯握手协议层。
请参见图 8所示， 图 8所示的为一种测试驱动程序的方法， 应用于测 试系统， 具体用于解析硬件返回响应帧的准确性。 本实施例提供的测试方 法包括以下步骤：
步骤 S51 , 按测试用例要求， 执行驱动程序接口函数。
步骤 S52, 按照握手协议规定的正常时序， 虚拟设备向驱动程序返回 正常或异常格式的响应帧。 步骤 S53 , 观察驱动程序的输出结果。
步骤 S54, 配合自动化测试脚本批量执行用例， 虚拟设备向驱动程序 遍历各种正常或异常格式的响应帧， 测试驱动程序对帧格式的解析是否存 在缺陷。
下面通过具体实例来详细的说明图 8所示的方案。
命令帧或响应帧的协议格式一般如图 9, 具体地， 例如， 协议规定， 响应帧的格式中数据域的实际长度与数据长度必须保持一致， 如果数据域 的实际长度与数据长度不一致， 驱动需判定该响应帧非法。 又例如， 响应 帧的校验值必须与数据域的内容相符， 如果数据帧中的某些字节数据被篡 改， 导致计算的校验值与保存的校验值不一致， 也认为该响应帧非法。
表 3
Figure imgf000013_0001
本测试系统运行的测试用例如表 3所示， 具体的测试过程为:
步骤一， 将所有案例存入表格中， "虚拟设备设置" 一列的
与帧格式相关的参数值。
步骤二， QTP脚本读取输入数据， 执行接口。
步骤三， 虚拟设备收到命令帧后， QTP脚本根据 "虚拟设备设置" 的 内容要求， 设置虚拟设备的响应帧， 并返回给驱动程序。
步骤四， QTP脚本比较输出和期望结果判断用例是否执行通过。
步骤五， QTP脚本循环读取 Excel表格中的用例， 转至步骤一， 开始 执行下一个用例， 直到所有用例执行完毕。
具体的， 针对表 3中的案例， 步骤三的执行过程如下，
(1) 响应帧的数据长度域的值设为 10, 而数据域的内容只填入 "abed" 四个字符， 响应帧的其他数据按协议正确设置； (3) 进入步骤四。 实施例五
请参见图 10所示， 图 10所示的为一种测试系统 2, 该测试系统 2包 括：
第一发送模块 21 , 用于向驱动程序 3发送测试参数；
接收模块 22, 用于接收所述驱动程序 3根据所述测试参数发送的命令 帧；
第二发送模块 23 , 用于向所述驱动程序 3发送预设响应帧， 所述预设 响应帧对应有期望输出， 所述期望输出为在所述驱动程序 3正确的情况下 处理完所述预设响应帧后输出的结果；
获取模块 24, 用于获取所述驱动程序 3根据所述预设响应帧所输出的 实际输出；
判断模块 25 , 用于判断所述实际输出是否符合所述期望输出； 输出模块 26, 用于当所述实际输出符合所述期望输出时， 则输出所述 驱动程序 3正确； 当所述实际输出不符合所述期望输出时， 则输出所述驱 动程序 3错误。
由于图 10所示的实施例中的测试系统 2的各个模块的功能与实施例一 的方法相对应，所以关于各个模块的具体功能请与实施例一相互参见即可。
综上所述， 本发明提出的一种测试驱动程序的方法和测试系统， 是通 过软件方式模拟硬件的通讯方式、 模拟真实硬件无法实现的场景， 该系统 可模拟硬件返回任意常规或异常的数据， 满足了测试有关驱动程序和硬件 设备之间通讯的充分性要求， 并根据设备驱动程序测试系统三个独立部分 的特性， 应用相应的测试方法， 使测试更全面地覆盖驱动程序代码的关键 内容， 排除了测试过程操作硬件带来的局限， 该系统同时应用自动化测试 方法， 减少人工输入测试数据及比对测试结果的工作量， 极大程度地提升 了设备驱动程序测试的充分性和效率。
需要说明的是，图 1至图 10所示的实施例只是本发明所介绍的优选实 施例， 本领域技术人员在此基石出上， 完全可以设计出更多的实施例， 因此 不在此处贅述。
对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见 的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下， 在其它实施例中实现。 因此， 本发明将不会被限制于本文所示的这些实施 例， 而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

权 利 要 求
1、 一种测试驱动程序的方法， 其特征在于， 包括：
向驱动程序发送测试参数；
接收所述驱动程序根据所述测试参数发送的命令帧；
向所述驱动程序发送预设响应帧， 所述预设响应帧对应有期望输出， 所述期望输出为在所述驱动程序正确的情况下处理完所述预设响应帧后输 出的结果；
获取所述驱动程序根据所述预设响应帧所输出的实际输出； 当所述实际输出符合所述期望输出时， 则输出所述驱动程序正确； 当所述实际输出不符合所述期望输出时， 则输出所述驱动程序错误。
2、根据权利要求 1所述的测试驱动程序的方法， 其特征在于， 当所述 预设响应帧的内容为设备状态异常时， 则所述期望输出具体为输出所述设 备状态异常。
3、根据权利要求 1所述的测试驱动程序的方法， 其特征在于， 当所述 预设响应帧的内容为设备状态正常时， 则所述期望输出具体为输出所述设 备状态正常。
4、根据权利要求 1所述的测试驱动程序的方法， 其特征在于， 当所述 预设响应帧的格式错误时， 则所述期望输出具体为输出所述预设响应帧的 格式出现错误。
5、根据权利要求 1所述的测试驱动程序的方法， 其特征在于， 当所述 预设响应帧的格式正确时， 则所述期望输出具体为输出所述预设响应帧的 格式正确。
6、根据权利要求 1所述的测试驱动程序的方法， 其特征在于， 当所述 预设响应帧的握手协议时序错误时， 则所述期望输出具体为输出所述预设 响应帧的握手协议时序出现错误。
7、根据权利要求 1所述的测试驱动程序的方法， 其特征在于， 当所述 预设响应帧的握手协议时序正确时， 则所述期望输出具体为输出所述预设 响应帧的握手协议时序正确。
8、 一种测试系统， 其特征在于， 包括： 第一发送模块， 用于向驱动程序发送测试参数；
接收模块， 用于接收所述驱动程序根据所述测试参数发送的命令帧； 第二发送模块， 用于向所述驱动程序发送预设响应帧， 所述预设响应 帧对应有期望输出， 所述期望输出为在所述驱动程序正确的情况下处理完 所述预设响应帧后输出的结果；
获取模块， 用于获取所述驱动程序根据所述预设响应帧所输出的实际 输出；
判断模块， 用于判断所述实际输出是否符合所述期望输出；
输出模块， 用于当所述实际输出符合所述期望输出时， 则输出所述驱 动程序正确； 当所述实际输出不符合所述期望输出时， 则输出所述驱动程 序错误。
+
PCT/CN2013/078794 2012-12-27 2013-07-04 一种测试驱动程序的方法及系统 Ceased WO2014101383A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201210581467.0A CN103019939B (zh) 2012-12-27 2012-12-27 一种测试驱动程序的方法及系统
CN201210581467.0 2012-12-27

Publications (1)

Publication Number Publication Date
WO2014101383A1 true WO2014101383A1 (zh) 2014-07-03

Family

ID=47968564

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/078794 Ceased WO2014101383A1 (zh) 2012-12-27 2013-07-04 一种测试驱动程序的方法及系统

Country Status (2)

Country Link
CN (1) CN103019939B (zh)
WO (1) WO2014101383A1 (zh)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103019939B (zh) * 2012-12-27 2015-07-22 广州广电运通金融电子股份有限公司 一种测试驱动程序的方法及系统
CN103279106B (zh) * 2013-05-30 2015-07-08 莱诺斯科技(北京)有限公司 一种仪器设备监视与控制系统
CN104699594A (zh) * 2013-12-05 2015-06-10 北汽福田汽车股份有限公司 一种测试方法和测试设备
CN106371962B (zh) * 2016-08-30 2019-01-01 广州广电运通金融电子股份有限公司 一种跨平台的驱动测试方法、装置及系统
CN107219472A (zh) * 2017-06-08 2017-09-29 杭州茂力半导体技术有限公司 一种自动测试稳压器的方法和系统
CN110046084A (zh) * 2018-01-17 2019-07-23 北京京东尚科信息技术有限公司 测试数据产品的方法和装置
CN109144036B (zh) * 2018-10-22 2023-11-21 江苏艾科半导体有限公司 一种基于fpga芯片的机械手模拟测试系统及测试方法
CN109542774B (zh) * 2018-11-02 2023-10-17 深圳平安医疗健康科技服务有限公司 脚本编码格式批量检测方法、装置、终端及可读存储介质
CN109634867B (zh) * 2018-12-18 2022-02-11 宁夏隆基宁光仪表股份有限公司 基于数据模拟系统下的软件测试方法、装置及存储介质
CN110175050B (zh) * 2019-05-29 2022-10-14 深圳创龙智新科技有限公司 外围设备控制方法、装置、系统、电子设备及存储介质
CN110825617B (zh) * 2019-09-27 2023-09-08 福建星云电子股份有限公司 一种用于模拟设备间通讯交互的方法及装置
CN112272063B (zh) * 2020-10-26 2022-06-03 哈尔滨诺信工大测控技术有限公司 适用于卫星设备测试用的模拟器
CN112286833B (zh) * 2020-12-31 2021-04-16 中国电力科学研究院有限公司 智能电能表实时操作系统驱动测试方法及装置
CN115408007A (zh) * 2022-09-06 2022-11-29 清华大学 虚拟设备生成、驱动程序测试方法、装置、设备及介质
CN116541229B (zh) * 2023-07-07 2023-10-31 西安羚控电子科技有限公司 一种数据驱动的通信调试方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101521899A (zh) * 2009-03-31 2009-09-02 大连海事大学 用于移动应用程序的机上测试系统和方法
CN102662828A (zh) * 2012-03-14 2012-09-12 浪潮(北京)电子信息产业有限公司 一种实现软件自动测试的方法及装置
CN103019939A (zh) * 2012-12-27 2013-04-03 广州广电运通金融电子股份有限公司 一种测试驱动程序的方法及系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1755643A (zh) * 2004-09-27 2006-04-05 华为技术有限公司 一种软件测试的方法
CN102541734B (zh) * 2011-12-27 2014-12-17 Tcl集团股份有限公司 基于android平台的设备的压力测试方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101521899A (zh) * 2009-03-31 2009-09-02 大连海事大学 用于移动应用程序的机上测试系统和方法
CN102662828A (zh) * 2012-03-14 2012-09-12 浪潮(北京)电子信息产业有限公司 一种实现软件自动测试的方法及装置
CN103019939A (zh) * 2012-12-27 2013-04-03 广州广电运通金融电子股份有限公司 一种测试驱动程序的方法及系统

Also Published As

Publication number Publication date
CN103019939A (zh) 2013-04-03
CN103019939B (zh) 2015-07-22

Similar Documents

Publication Publication Date Title
WO2014101383A1 (zh) 一种测试驱动程序的方法及系统
CN114138644B (zh) Bmc调试方法及监控方法、系统、装置、设备、介质
CN103984612B (zh) 一种基于hpl工具的无人值守压力测试的方法
US20090204924A1 (en) Method, system and computer program product for failure analysis implementing automated comparison of multiple reference models
WO2018036273A1 (zh) 模拟测试方法、服务器、设备及计算机可读存储介质
CN104246714A (zh) 软件缺陷验证
CN103744784A (zh) 手机应用自动化测试方法及系统
CN113032246B (zh) Ssd固件运行方法、装置、可读存储介质及电子设备
CN110377244A (zh) 一种日志打印方法、装置、设备及存储介质
US20240296110A1 (en) Apparatuses, Devices, Methods and Computer Program for Performing Unit Tests on Firmware Code
CN107908538A (zh) 一种服务器系统性能的自动化测试方法及系统
CN112770108B (zh) 性能的测试方法、装置、系统及计算机可读存储介质
CN118445210A (zh) 基于har文件格式解析自动生成接口测试用例的方法与系统
JP2010256997A (ja) フィールドトラブルのエラー再現システム、エラー再現調査方法およびシナリオ実行プログラム
CN114385132B (zh) 一种断言代码生成方法、装置、设备及介质
CN115061840A (zh) 一种片上系统的测试方法、装置、设备及介质
CN113037526B (zh) 一种安全检测方法、终端、系统及存储介质
CN107885487A (zh) 一种信息物理融合系统的测试及需求满足性检验的方法
US20230305938A1 (en) Method and device for determining coverage in hil testing, and storage medium
JP2009104490A (ja) プログラムのテスト装置
CN106656684B (zh) 一种网格资源可靠性监控方法及装置
CN115098387A (zh) 一种服务器bios自动测试系统、方法、装置及存储介质
CN115758963A (zh) 芯片eda仿真中打印信息的处理装置、方法及系统
CN106681899A (zh) 基于Jmeter的安卓UI自动化测试方法及系统
CN109032880B (zh) 一种协同bios自检的硬件调测方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13867250

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13867250

Country of ref document: EP

Kind code of ref document: A1