CN113407438B - Module testing method, computer device, and storage medium - Google Patents
Module testing method, computer device, and storage medium Download PDFInfo
- Publication number
- CN113407438B CN113407438B CN202110503674.3A CN202110503674A CN113407438B CN 113407438 B CN113407438 B CN 113407438B CN 202110503674 A CN202110503674 A CN 202110503674A CN 113407438 B CN113407438 B CN 113407438B
- Authority
- CN
- China
- Prior art keywords
- test
- test case
- unexecuted
- module
- initial
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
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)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
The application relates to a module testing method, a computer device and a storage medium. The method comprises the following steps: starting a daemon process, wherein the daemon process is used for determining whether an unexecuted test case for testing a module to be tested exists or not based on the stored execution result of the test case; when the unexecuted test case exists, starting a test main process; executing the unexecuted test case through the test main process, and storing an execution result of executing the unexecuted test case; and when the unexecuted test case executed by the test main process is the test case needing equipment restarting, returning to the step of starting the daemon process after the equipment restarting until the unexecuted test case for testing the module to be tested does not exist, and outputting the test result. By adopting the method of the embodiment of the application, the process of the test tool can be compatible with the test case needing equipment restarting, and the automatic test can still be continued after the equipment restarting, so that the test efficiency of the module is effectively improved.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a module testing method, a computer device, and a storage medium.
Background
In order to ensure that the modules in the device can implement the corresponding functions, the modules need to be tested. The module is typically and based on a test tool in the operating system of the device subjected to a series of test operations. For example, human interface operation is simulated, background naming is issued, service monitoring, port monitoring and the like.
The test case of the test tool may include an operation of restarting the device. However, the test tool is directly deployed on the device for automatic execution, after the device is restarted, the process of the test tool no longer exists, and the unexecuted test case cannot be executed due to the shutdown of the test tool in the operating system. Therefore, for the test cases requiring device restart, the test cases can only be executed one by one or manually, thereby affecting the test efficiency of the module.
Disclosure of Invention
In view of the above, it is necessary to provide a module testing method, a computer device, and a storage medium capable of effectively improving the module testing efficiency.
A method of testing a module, the method comprising:
starting a daemon process, wherein the daemon process is used for determining whether an unexecuted test case for testing a module to be tested exists or not based on a stored execution result of the test case;
when the unexecuted test case exists, starting a test main process;
executing the unexecuted test case through the test main process, and storing an execution result of executing the unexecuted test case;
and when the unexecuted test case executed by the test main process is a test case needing equipment restarting, returning to the step of starting the daemon process after the equipment is restarted until the unexecuted test case for testing the module to be tested does not exist, and outputting a test result.
In one embodiment, the test case is associated with a test status bit, and the test status bit is used for identifying an execution status of the test case.
In one embodiment, before the starting the daemon, the method further comprises:
obtaining each test case of the module to be tested;
adding an associated initial test state bit for each test case, wherein the initial test state bit is used for identifying each test case as an initial unexecuted test case;
and creating an initial dictionary object, wherein the initial dictionary object is used for storing each test case according to the execution sequence of each test case and the initial test state bit.
In one embodiment, after the creating the initial dictionary object, the method further includes:
starting an initial test main process;
executing the test case according to the initial dictionary object through the initial test main process;
after the test case is executed, updating an initial test state bit of the executed test case, and determining a test result of the executed test case;
and creating a temporary dictionary object, wherein the temporary dictionary object is used for storing the updated initial test state bit of the executed test case and the corresponding test result.
In one embodiment, after determining that the unexecuted test case executed by the test host process is a test case requiring device restart, before the device restart, the method further includes:
and carrying out format conversion on the temporary dictionary object to obtain a dictionary object, and storing the dictionary object.
In one embodiment, the daemon process is used for analyzing the dictionary object, comparing the initial dictionary object with the analyzed dictionary object, and determining whether an unexecuted test case for testing the module to be tested exists based on the comparison result.
In one embodiment, the daemon process is configured to obtain a host process parameter of the device, and determine whether the test host process is in a start state based on the host process parameter.
In one embodiment, the daemon process is configured to send a start command when an unexecuted test case for testing the module to be tested exists and the test host process is determined to be in a closed state based on the host process parameter, where the start command is used to start the test host process.
A computer device comprising a memory storing a computer program and a processor implementing the steps of the method described above when executing the computer program.
A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the above-mentioned method.
According to the module testing method, the computer equipment and the storage medium, the daemon process is started, and is used for determining whether an unexecuted test case for testing a module to be tested exists or not based on the execution result of the stored test case; when the unexecuted test case exists, starting a test main process; executing the unexecuted test case through the test main process, and storing an execution result of executing the unexecuted test case; and when the unexecuted test case executed by the test main process is the test case needing equipment restarting, returning to the step of starting the daemon process after the equipment restarting until the unexecuted test case for testing the module to be tested does not exist, and outputting the test result. By adopting the method of the embodiment, the process of the test tool can be compatible with the test case needing equipment restarting, and the automatic test can still be continued after the equipment restarting, so that the test efficiency of the module is effectively improved.
Drawings
FIG. 1 is a diagram of an application environment of a method for testing a module in one embodiment;
FIG. 2 is a flow diagram illustrating a method for testing modules in one embodiment;
FIG. 3 is a schematic diagram of a method of testing a module in one embodiment;
FIG. 4 is a block diagram of the test apparatus of the module in one embodiment;
FIG. 5 is a diagram of the internal structure of a computer device in one embodiment;
fig. 6 is an internal structural diagram of a computer device in another embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
In one embodiment, the module testing method provided by the present application can be applied to the application environment shown in fig. 1, where the application environment can involve both the terminal 102 and the server 104. Wherein the terminal 102 may communicate with the server 104 via a network or other communication means. The module to be tested may be an internal module in the terminal 102 or an external module connected to the terminal 102. Taking the module to be tested as an internal module in the terminal 102 as an example, the server 104 may send a test case to the terminal 102 to test the module to be tested. Specifically, the server 104 starts a daemon process, and the daemon process is used for determining whether an unexecuted test case for testing the module to be tested exists or not based on the execution result of the stored test case; when the unexecuted test case exists, starting a test main process; executing the unexecuted test case through the test main process, and storing an execution result of executing the unexecuted test case; when the unexecuted test case executed by the test main process is the test case needing equipment restarting, the equipment refers to the server 104 at this moment, after the equipment restarting, the step of starting the daemon process is returned until the unexecuted test case for testing the module to be tested does not exist, and the test result is output.
In one embodiment, the application environment of the module testing method provided by the present application may only relate to the terminal 102. The module to be tested may be an internal module in the terminal 102, or an external module connected to the terminal 102. Specifically, the terminal 102 starts the test main process by starting the daemon process, when the unexecuted test case exists, and when the unexecuted test case executed by the test main process is a test case requiring device restart, the device refers to the terminal 102 at this time, and after the device restart, the step of starting the daemon process is returned until the unexecuted test case for testing the module to be tested does not exist, and the test result is output.
In one embodiment, the application environment of the module testing method provided by the present application may only relate to the server 104. The module to be tested may be an internal module in the server 104, or may be an external module connected to the server 104. Specifically, the server 104 starts the test main process by starting the daemon process, when the unexecuted test case exists, and when the unexecuted test case executed by the test main process is a test case requiring device restart, the device refers to the server 104 at this time, and after the device restart, the step of starting the daemon process is returned until the unexecuted test case for testing the module to be tested does not exist, and the test result is output.
The module to be tested may be, but is not limited to, various wireless wide area network modules, wireless communication modules, and the like, the terminal 102 may be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the server 104 may be implemented by an independent server or a server cluster formed by a plurality of servers.
In one embodiment, as shown in fig. 2, a module testing method is provided, which is described by taking the method as an example applied to the terminal 102 and/or the server 104 in fig. 1, and includes the following steps:
step S202, a daemon process is started, and the daemon process is used for determining whether an unexecuted test case for testing a module to be tested exists or not based on the stored execution result of the test case.
The daemon process is a special process running in the background and used for executing specific system tasks. The daemon process may start at system boot and run until the system is shut down. The daemon process can also be started when needed and automatically ended after the task is completed. The module to be tested is a module for testing, and may be an internal module in the device, or an external module connected to the device, and specifically may include a wireless wide area network module, a wireless communication module, and the like.
In one embodiment, the operating system of the test device may be a Windows operating system, a Linux operating system, or the like. The test tool for testing may be a test tool on a test device of a Windows operating system, or may be a test tool on a test device of a Linux operating system. Specifically, the test tool may be automated test software based on a Python3.4.3+ PyQt4 program and a Python base database, so that a test case requiring device restart may be compatible when the test case is executed, thereby ensuring automated testing and continuous execution of the test case. Python is a computer programming language that can be used for scripting and application development.
In one embodiment, the daemon process is started after the device is started or restarted. The daemon process can be used for determining whether an unexecuted test case for testing the module to be tested exists or not based on the execution result of the stored test case. And when the unexecuted test case does not exist, the daemon process is ended, and the test case cannot be continuously executed.
In one embodiment, the test case correspondence is associated with a test status bit. The test state bit is used for identifying the execution state of the test case. The test status bit may be located after the name of the test case, and the test status bit may be represented by a character, a string, an array, or a word. The daemon process can determine whether an unexecuted test case for testing the module to be tested exists or not by reading the test state bit of the test case based on the stored execution result of the test case.
And step S204, when the unexecuted test case exists, starting the test main process.
The process refers to the operation of a program in a computer, is a basic unit for resource allocation and scheduling of a system, and is the basis of an operating system structure. The process of the test tool executing the test case is a test main process, and the test main process can be understood as a main function. In the test main process, a process for sending each test case is called a test subprocess, and the test subprocess can be understood as a wait function.
In one embodiment, the daemon process is used for acquiring the main process parameters of the equipment and judging whether the test main process is in a starting state or not based on the main process parameters. The main process parameter may be an operation parameter of the function. When the unexecuted test case exists, the test main process needs to be in an open state. The daemon process is also used for sending a starting command when an unexecuted test case for testing the module to be tested exists and the test main process is judged to be in a closed state based on the main process parameters, and the starting command is used for starting the test main process.
And step S206, executing the unexecuted test case through the test main process, and storing the execution result of the executed unexecuted test case.
In one embodiment, when the unexecuted test case exists, the unexecuted test case is executed through the test host process. After the test case is executed, the test state bit of the executed test case is updated from the unexecuted state to the executed state. And meanwhile, storing the execution result of the unexecuted test case. The execution result may include a test status bit of the executed status, and a test result of a test success or a test failure.
In one embodiment, the execution result of executing the unexecuted test case may be stored in the form of a dictionary object. The dictionary object can be understood as a two-dimensional array, the first column of the two-dimensional array is a Key, the Key column has unique non-repeatability, the second column of the two-dimensional array is an Item, and the Item column can store various types of variables including numerical values, characters, dates or objects. Specifically, the unexecuted test cases may be used as a first column of the dictionary object, and the updated test status bits and the test results may be stored as a second column of the dictionary object.
And S208, when the unexecuted test case executed by the test main process is the test case needing equipment restarting, returning to the step of starting the daemon process after the equipment is restarted until the unexecuted test case for testing the module to be tested does not exist, and outputting a test result.
In one embodiment, whether the test case is a test case requiring device restart may be determined according to the field of the test case. When the unexecuted test case executed by the test main process is the test case needing equipment restarting, after the equipment restarting, returning to the step of starting the daemon process until the unexecuted test case for testing the module to be tested does not exist, at the moment, the test main process is finished, the daemon process is finished, and the test result of the module to be tested is output.
In one embodiment, a test report may be formed and output according to the test result. Specifically, the test report mainly includes an overview of the test tasks and test details. The test task overview can include the number of test cases, the number of successes, the number of failures, the total test duration and the like, and the test details can include the number of times of executing each test case, the result of each execution and the execution duration. When the test fails, the test case also comprises key codes such as failure reasons, failed code line numbers and the like, and partial special test cases also can store screenshots when the test fails.
In one embodiment, when a tester goes out to execute a test, the problem of test source code leakage can be caused. For this reason, a set of encryption and authorization schemes are currently implemented on the test tools. Encryption means encryption of core code logic of the test tool, and authorization means limitation of a test equipment host and a test use date. Each test equipment host can generate a unique serial number, a Key is generated by the server according to the serial number and the authorization deadline, and the test equipment host can obtain a core code to be tested only after the Key is correctly configured. The Key can only take effect on a specified test equipment host, cannot be copied to other machines for use, and the Key is invalid due to the fact that an operating system is reinstalled. The core code is compiled into a dynamic link library file which can be directly called by Python, the file is a binary file and can be called only through a Key, and therefore the secrecy of the core code is achieved.
In the module testing method, a daemon process is started, and the daemon process is used for determining whether an unexecuted test case for testing a module to be tested exists or not based on the stored execution result of the test case; when the unexecuted test case exists, starting a test main process; executing the unexecuted test case through the test main process, and storing an execution result of executing the unexecuted test case; and when the unexecuted test case executed by the test main process is the test case needing equipment restarting, returning to the step of starting the daemon process after the equipment restarting until the unexecuted test case for testing the module to be tested does not exist, and outputting the test result. By adopting the method of the embodiment, the process of the test tool can be compatible with the test case needing equipment restarting, and the automatic test can still be continued after the equipment restarting, so that the test efficiency of the module is effectively improved.
In one embodiment, before the daemon process is started in step S202, the following steps S302 to S306 are further included:
step S302, obtaining each test case of the module to be tested.
Specifically, before the test tool executes the test, the user may select at least one test case on the interactive interface of the automated test tool according to the function to be tested of the module to be tested, so as to determine each test case. And then, the equipment acquires each test case of the module to be tested.
And step S304, adding associated initial test state bits for each test case, wherein the initial test state bits are used for identifying each test case as an initial unexecuted test case.
Before the test tool executes the test, each test case is in an unexecuted state. In order to subsequently distinguish the unexecuted test case from the executed test case, before the test tool executes the test, a relevant test state bit is added to each obtained test case of the module to be tested, at this time, the test state bit is called as an initial test state bit, and the initial test state bit is used for identifying each test case as an initial unexecuted test case.
Step S306, an initial dictionary object is created, and the initial dictionary object is used for storing each test case according to the execution sequence and the initial test state bit of each test case.
In one embodiment, test cases of a module to be tested are stored. The dictionary object created before the test tool performs the test is referred to as an initial dictionary object. And storing the test cases of the module to be tested in the initial dictionary object according to the selection sequence of the test cases selected by the user, namely the execution sequence of the test cases and the initial test state bit.
In one embodiment, after the initial dictionary object is created in step S306, the following steps S402 to S408 are further included:
step S402, the initial test main process is started.
After determining each test case of the module to be tested and creating an initial dictionary object, starting a test main process, wherein the test main process is called an initial test main process at the moment.
And S404, executing a test case according to the initial dictionary object through the initial test main process.
And sequentially executing the test cases through the initial test main process according to the execution sequence of the test cases in the created initial dictionary object.
Step S406, after the test case is executed, updating the initial test state bit of the executed test case, and determining the test result of the executed test case.
After the test case is executed, updating the initial test state bit of the executed test case, namely updating the initial test state bit of the executed test case, updating the unexecuted state into the executed state, and determining the test result of the executed test case, wherein the test result is test success or test failure.
Step S408, a temporary dictionary object is created, and the temporary dictionary object is used for storing the updated initial test state bit of the executed test case and the corresponding test result.
In one embodiment, the execution results of the executed test cases are stored. Specifically, a temporary dictionary object is created, and the updated initial test state bits of the executed test cases and the corresponding test results are stored in the temporary dictionary object. Wherein the temporary dictionary object is a temporary file of the system.
In one embodiment, after determining that the unexecuted test case executed by the test host process is a test case requiring device restart, before the device restart, the method further includes: and carrying out format conversion on the temporary dictionary object to obtain a dictionary object, and storing the dictionary object. Specifically, before executing a test case requiring device restart, the temporary dictionary object is converted into a binary file to obtain a dictionary object, and the dictionary object is stored in a memory of the device so as to be called after the device restart. The dictionary objects may be device readable and writable files, and the format may be, but is not limited to, word, TXT, and the like.
In one embodiment, after the device is restarted, the daemon process is used for analyzing the dictionary object, comparing the initial dictionary object with the analyzed dictionary object, and determining whether an unexecuted test case for testing the module to be tested exists or not based on the comparison result. Specifically, the daemon process analyzes the dictionary object, and determines whether an unexecuted test case for testing the module to be tested exists or not by reading and comparing the test state bit of the test case.
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is further described in detail below with reference to the accompanying drawings and one embodiment thereof. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
Fig. 3 is a schematic diagram illustrating a module testing method in one embodiment, which includes the following steps:
1. starting the equipment, starting an interactive interface of the automatic testing tool, selecting at least one test case by a user according to the functions to be tested of the module to be tested, determining each test case, and creating an initial dictionary object for storing each test case;
2. starting an initial test main process, executing each test case through the initial test main process and the initial dictionary object, creating a temporary dictionary object for storing the execution result of the executed test case, converting the temporary dictionary object into the dictionary object and storing the dictionary object when the test case executed by the initial test main process is the test case needing equipment restarting, and restarting the equipment after the execution of the test case needing equipment restarting is finished;
3. after the equipment is restarted, starting a daemon process, wherein the daemon process determines whether an unexecuted test case for testing a module to be tested exists or not based on the initial dictionary object and an execution result of the test case stored in the dictionary object;
4. when the unexecuted test case for testing the module to be tested does not exist, ending the daemon process, and executing the step 8;
5. when an unexecuted test case for testing the module to be tested exists, starting a test main process, and executing the step 6;
6. executing the unexecuted test case through the test main process, and storing an execution result of executing the unexecuted test case;
7. when the unexecuted test case executed by the test main process is the test case needing equipment restarting, after the equipment restarting, returning to the step 3 until the unexecuted test case for testing the module to be tested does not exist, ending the test main process and ending the daemon process;
8. and outputting a test result.
It should be understood that, although the steps in the flowchart of fig. 2 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not limited to being performed in the exact order illustrated and, unless explicitly stated herein, may be performed in other orders. Moreover, at least a portion of the steps in fig. 2 may include multiple steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, which are not necessarily performed in sequence, but may be performed in turn or alternately with other steps or at least a portion of the other steps or stages.
In one embodiment, as shown in fig. 4, there is provided a module testing apparatus including: the system comprises a daemon starting module 410, a test main process starting module 420, a test case execution module 430 and a test result output module 440, wherein:
the system comprises a daemon process starting module, a daemon process and a test module, wherein the daemon process starting module is used for starting a daemon process, and the daemon process is used for determining whether an unexecuted test case for testing a module to be tested exists or not based on a stored execution result of the test case;
the test main process starting module is used for starting the test main process when the unexecuted test case exists;
the test case execution module is used for executing the unexecuted test case through the test main process and storing an execution result of the unexecuted test case;
and the test result output module is used for returning to the step of starting the daemon process after the equipment is restarted when the unexecuted test case executed by the test main process is a test case needing equipment restarting until the unexecuted test case for testing the module to be tested does not exist, and outputting a test result.
In one embodiment, the module testing apparatus further includes the following units:
and the execution state identification unit is used for determining that the test case is correspondingly associated with a test state bit, and the test state bit is used for identifying the execution state of the test case.
The test case acquisition unit is used for acquiring each test case of the module to be tested;
an unexecuted state identification unit, configured to add an associated initial test state bit to each test case, where the initial test state bit is used to identify each test case as an initial unexecuted test case;
and the initial dictionary object creating unit is used for creating an initial dictionary object, and the initial dictionary object is used for storing each test case according to the execution sequence of each test case and the initial test state bit.
An initial test main process starting unit, which is used for starting the initial test main process;
the test case execution unit is used for executing the test case according to the initial dictionary object through the initial test main process;
the test result determining unit is used for updating the initial test state bit of the executed test case and determining the test result of the executed test case after the test case is executed;
and the temporary dictionary object creating unit is used for creating a temporary dictionary object, and the temporary dictionary object is used for storing the updated initial test state bit of the executed test case and the corresponding test result.
And the format conversion unit is used for carrying out format conversion on the temporary dictionary object to obtain a dictionary object and storing the dictionary object before restarting the equipment after determining that the unexecuted test case executed by the test main process is a test case needing equipment restarting.
In one embodiment, the daemon starting module comprises the following units:
and the unexecuted test case determining unit is used for enabling the daemon process to be used for analyzing the dictionary object, comparing the initial dictionary object with the analyzed dictionary object, and determining whether an unexecuted test case for testing the module to be tested exists or not based on the comparison result.
In one embodiment, the test host process start module includes the following elements:
and the test main process determining unit is used for enabling the daemon process to be used for acquiring main process parameters of the equipment and judging whether the test main process is in a starting state or not based on the main process parameters.
And the test main process starting unit is used for enabling the daemon to be used for sending a starting command when an unexecuted test case for testing the module to be tested exists and the test main process is judged to be in a closed state based on the main process parameters, and the starting command is used for starting the test main process.
For the specific definition of the module testing device, reference may be made to the above definition of the module testing method, which is not described herein again. The respective modules in the testing device of the above modules may be wholly or partially implemented by software, hardware, and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.
In one embodiment, a computer device is provided, which may be a server, and the internal structure thereof may be as shown in fig. 5. The computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile 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 operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing the test data of the module. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a method of testing a module.
In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as shown in fig. 6. The computer device includes a processor, a memory, a communication interface, a display screen, and an input device connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program to run on the non-volatile storage medium. The communication interface of the computer device is used for communicating with an external terminal in a wired or wireless manner, and the wireless manner can be realized through WIFI, an operator network, NFC (near field communication) or other technologies. The computer program is executed by a processor to implement a method of testing a module. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on a shell of the computer equipment, an external keyboard, a touch pad or a mouse and the like.
It will be appreciated by those skilled in the art that the configurations shown in fig. 5-6 are only block diagrams of some configurations relevant to the present disclosure, and do not constitute a limitation on the computing devices to which the present disclosure may be applied, and a particular computing device may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
In one embodiment, a computer device is provided, comprising a memory and a processor, the memory having a computer program stored therein, the processor implementing the steps of the method for testing the module described above when executing the computer program.
In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method for testing a module as described above.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database or other medium used in the embodiments provided herein can include at least one of non-volatile and volatile memory. Non-volatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical storage, or the like. Volatile Memory can include Random Access Memory (RAM) or external cache Memory. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM), among others.
All possible combinations of the technical features in the above embodiments may not be described for the sake of brevity, but should be considered as being within the scope of the present disclosure as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is specific and detailed, but not to be understood as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, and these are all within the scope of protection of the present application. Therefore, the protection scope of the present patent application shall be subject to the appended claims.
Claims (10)
1. A method of testing a module, the method comprising:
acquiring each test case of a module to be tested;
adding an associated initial test state bit for each test case, wherein the initial test state bit is used for identifying each test case as an initial unexecuted test case;
creating an initial dictionary object, wherein the initial dictionary object is used for storing each test case according to the execution sequence of each test case and the initial test state bit;
starting an initial test main process;
executing the test case according to the initial dictionary object through the initial test main process;
after the test case is executed, updating an initial test state bit of the executed test case, and determining a test result of the executed test case;
creating a temporary dictionary object, wherein the temporary dictionary object is used for storing the updated initial test state bit of the executed test case and a corresponding test result;
starting a daemon process, wherein the daemon process is used for determining whether an unexecuted test case for testing a module to be tested exists or not by reading a test state bit of the test case based on a stored execution result of the test case; the test case is correspondingly associated with a test state bit; the test state bit is used for identifying the execution state of the test case; when the unexecuted test case exists, starting a test main process;
executing the unexecuted test case through the test main process, and storing an execution result of executing the unexecuted test case;
determining whether the unexecuted test case is a test case needing equipment restarting according to the field of the test case;
and when the unexecuted test case executed by the test main process is a test case needing equipment restarting, returning to the step of starting the daemon process after the equipment is restarted until the unexecuted test case for testing the module to be tested does not exist, and outputting a test result.
2. The method of claim 1, wherein the execution result comprises a test status bit of the executed status and at least one of a test success or a test failure test result.
3. The method of claim 1, after determining that the unexecuted test case executed by the test host process is a test case requiring device reboot, before the device reboot, further comprising:
and carrying out format conversion on the temporary dictionary object to obtain a dictionary object, and storing the dictionary object.
4. The method of any one of claims 1 to 3, wherein the daemon is configured to parse the dictionary object, compare the initial dictionary object with the parsed dictionary object, and determine whether there are unexecuted test cases for testing the module to be tested based on the comparison result.
5. The method according to claim 1, wherein the daemon process is configured to obtain a host process parameter of the device, and determine whether the test host process is in a startup state based on the host process parameter.
6. The method as claimed in claim 5, wherein the daemon is configured to send a start command when there is an unexecuted test case for testing the module to be tested and it is determined that the test host process is in an off state based on the host process parameters, and the start command is used to start the test host process.
7. An apparatus for testing a module, the apparatus comprising:
the test case acquisition unit is used for acquiring each test case of the module to be tested;
an unexecuted state identification unit, configured to add an associated initial test state bit to each test case, where the initial test state bit is used to identify each test case as an initial unexecuted test case;
an initial dictionary object creating unit, configured to create an initial dictionary object, where the initial dictionary object is used to store each test case according to an execution order of each test case and the initial test state bit;
an initial test main process starting unit, which is used for starting the initial test main process;
the test case execution unit is used for executing the test case according to the initial dictionary object through the initial test main process;
the test result determining unit is used for updating the initial test state bit of the executed test case and determining the test result of the executed test case after the test case is executed;
a temporary dictionary object creating unit, configured to create a temporary dictionary object, where the temporary dictionary object is used to store the updated initial test state bits of the executed test cases and corresponding test results;
the system comprises a daemon starting module, a daemon judging module and a judging module, wherein the daemon starting module is used for starting a daemon, and the daemon is used for determining whether an unexecuted test case for testing a module to be tested exists or not by reading a test state bit of the test case based on a stored execution result of the test case; the test case is correspondingly associated with a test state bit; the test state bit is used for identifying the execution state of the test case;
the test main process starting module is used for starting the test main process when the unexecuted test case exists;
the test case execution module is used for executing the unexecuted test case through the test main process and storing an execution result of the unexecuted test case; determining whether the unexecuted test case is a test case needing equipment restarting according to the field of the test case;
and the test result output module is used for returning to the step of starting the daemon process after the equipment is restarted when the unexecuted test case executed by the test main process is a test case needing equipment restarting until the unexecuted test case for testing the module to be tested does not exist, and outputting a test result.
8. The apparatus of claim 7, wherein the daemon launching module comprises the following elements:
and the unexecuted test case determining unit is used for enabling the daemon process to be used for analyzing the dictionary object, comparing the initial dictionary object with the analyzed dictionary object, and determining whether an unexecuted test case for testing the module to be tested exists or not based on the comparison result.
9. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method of any of claims 1 to 6.
10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110503674.3A CN113407438B (en) | 2021-05-10 | 2021-05-10 | Module testing method, computer device, and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110503674.3A CN113407438B (en) | 2021-05-10 | 2021-05-10 | Module testing method, computer device, and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113407438A CN113407438A (en) | 2021-09-17 |
| CN113407438B true CN113407438B (en) | 2022-12-20 |
Family
ID=77678398
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110503674.3A Active CN113407438B (en) | 2021-05-10 | 2021-05-10 | Module testing method, computer device, and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113407438B (en) |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7392149B2 (en) * | 2003-10-14 | 2008-06-24 | Hewlett-Packard Development Company, L.P. | Automatic software testing |
| US8645341B2 (en) * | 2010-03-31 | 2014-02-04 | Salesforce.Com, Inc. | Method and system for automatically updating a software QA test repository |
| CN104915291B (en) * | 2015-05-27 | 2019-05-14 | 惠州Tcl移动通信有限公司 | Terminal restarts verification method and system |
| US10175657B2 (en) * | 2016-06-27 | 2019-01-08 | Webomates LLC | Method and system for determining mapping of test case(s) to code snippets of computer program |
| CN106210886A (en) * | 2016-06-28 | 2016-12-07 | 深圳市九洲电器有限公司 | A kind of network set-top box test method and system |
| CN112416747A (en) * | 2020-01-21 | 2021-02-26 | 上海哔哩哔哩科技有限公司 | Test case execution method, device, equipment and medium |
-
2021
- 2021-05-10 CN CN202110503674.3A patent/CN113407438B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN113407438A (en) | 2021-09-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110990020A (en) | Software compiling method and device, electronic equipment and storage medium | |
| CN108427613B (en) | Abnormal interface positioning method and device, computer equipment and storage medium | |
| CN111124440A (en) | Chip software burning method, chip software burning data processing method and device | |
| CN109933521A (en) | Automated testing method, device, computer equipment and storage medium based on BDD | |
| CN110995825B (en) | Intelligent contract issuing method, intelligent node equipment and storage medium | |
| CN109408261B (en) | Application program crash processing method and device, computer equipment and storage medium | |
| CN112433944A (en) | Service testing method, device, computer equipment and storage medium | |
| CN112068852B (en) | Method, system, equipment and medium for installing open-source software based on domestic server | |
| CN116166525A (en) | Method and device for generating test script | |
| CN115934503A (en) | Program testing method, device, equipment and storage medium | |
| CN113742224A (en) | Test system, method, device, computer equipment and storage medium | |
| CN112181388B (en) | Initializing method and device of SDK (software development kit) component, storage medium and control terminal | |
| CN113407438B (en) | Module testing method, computer device, and storage medium | |
| CN113961199A (en) | Model deployment system, method, device and storage medium | |
| CN110806891B (en) | Method and device for generating software version of embedded device | |
| CN117435483A (en) | Form tool-based simulation verification excitation generation method, device, medium and terminal | |
| CN112491799B (en) | Remote repair method and device for communication module, computer equipment and storage medium | |
| CN115757099A (en) | Automatic test method and device for platform firmware protection recovery function | |
| CN113010199B (en) | Application updating method and device, computer equipment and storage medium | |
| CN111045891B (en) | Monitoring method, device, equipment and storage medium based on java multithreading | |
| CN113568834A (en) | SDK code compatibility detection method, device, computer equipment and medium | |
| CN113778485A (en) | System operation method and device of electronic chip, electronic chip and storage medium | |
| CN112162743A (en) | Driver generation method, device, computer equipment and storage medium | |
| CN111159123A (en) | Embedded reliable parameter storage file system and method | |
| CN110187658B (en) | Chip processing method and device, chip and elevator outbound board |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |