WO2018184420A1

WO2018184420A1 - Software testing method, apparatus, electronic device, and medium

Info

Publication number: WO2018184420A1
Application number: PCT/CN2018/074874
Authority: WO
Inventors: 陈奕玲
Original assignee: 平安科技（深圳）有限公司
Priority date: 2017-04-06
Filing date: 2018-01-31
Publication date: 2018-10-11
Also published as: CN107688530B; CN107688530A

Abstract

Provided in the present solution are a software testing method, an apparatus, an electronic device, and a medium, for use in the technical field of computer information processing, the method comprising: running software to be tested on a client terminal, the software to be tested comprising at least one function module, each function module being provided with at least one buried point; when a buried point on the software to be tested is triggered, generating buried point data and sending the buried point data to a MongoDB database; the buried point data comprises buried point ID, a testing verification code, and parameter information; making an awk script configured on the MongoDB database acquire the test verification code as failed buried point data, and determine same as data to be analysed; and, using a preset analysis algorithm, analysing the parameter information in the data to be analysed in order to acquire analysis results of the cause of the buried point test failure. The present solution uses a MongoDB database to store buried point data, and is therefore more flexible; using an awk script to analyse buried point data in order to acquire data to be analysed has the advantages of a low threshold, simple positioning, and rapid data processing efficiency.

Description

Software testing method, device, electronic device and medium

The present application claims the priority of the Chinese Patent Application, the entire disclosure of which is hereby incorporated by reference.

Technical field

The present application belongs to the field of computer information processing technologies, and in particular, to a software testing method, device, electronic device and medium.

Background technique

With the rapid development of computer technology, various softwares with functions such as text editing, image processing, voice chat, and playing audio and video are emerging one after another. In order to ensure that all functional modules of the software can work normally, it is necessary to implement various functional modules of the software before the software is released. carry out testing. In the existing software testing method, at least one buried point is respectively set on each functional module of the software. When the user uses a certain functional module, the buried point preset in the functional module is triggered, and the buried point data is generated and sent. The server and the server collect and analyze the corresponding buried point data to find out the function modules that are error-prone during the running of the software, and improve them to achieve the purpose of perfecting the software.

In the existing software testing method, the number of buried data received by the server is large and repeated, and the developer performs fixed point searching and analysis. The testing process is cumbersome and the workload is large, and the testing time is long and the labor cost is high. If special analysis software (such as Python software) is used to analyze the buried data, although the workload of the test process is reduced to a certain extent, the dedicated analysis software (such as Python software) needs to be cumbersomely installed and configured, and requires strong code capability. The professional training can complete the software testing process, and there is a problem of high labor costs.

technical problem

In view of this, the present application provides a software testing method, device, electronic device and medium to solve the problem of cumbersome work and large workload in the existing software testing process.

Technical solution

A first aspect of the embodiments of the present application provides a software testing method, including:

Running the software to be tested on the client, the software to be tested includes at least one function module, and each function module is provided with at least one buried point;

When the buried point on the software to be tested is triggered, generating buried point data, and transmitting the buried point data to a MongoDB database; the buried point data includes a buried point ID, a test check code, and parameter information. ;

The awk script configured on the MongoDB database obtains the buried data of the test verification code as a failure, and is determined as the data to be analyzed;

The parameter information in the data to be analyzed is analyzed by using a preset analysis algorithm to obtain an analysis result that causes the buried point test to fail.

A second aspect of the embodiments of the present application provides a software testing apparatus, including:

a software running module, configured to run the software to be tested on the client, where the software to be tested includes at least one functional module, and each functional module is provided with at least one buried point;

a buried point data generating module, configured to generate buried point data when the buried point on the software to be tested is triggered, and send the buried point data to a MongoDB database; the buried point data includes a buried point ID , test verification code and parameter information;

The data analysis module to be analyzed is configured to enable the awk script configured on the MongoDB database to obtain the buried data of the test verification code as a failure, and determine the data to be analyzed;

The analysis result obtaining module is configured to analyze the parameter information in the data to be analyzed by using a preset analysis algorithm, and obtain an analysis result that causes the buried point test to fail.

A third aspect of the embodiments of the present application provides an electronic device including a memory and a processor, wherein the memory stores computer readable instructions executable on the processor, the processor executing the computer The following steps are implemented when reading the instruction:

A fourth aspect of the embodiments of the present application provides a computer readable storage medium storing computer readable instructions that, when executed by a processor, implement the following steps:

Beneficial effect

In the embodiment of the present application, the MongoDB database is used to store the embedded data triggered by the client running the software to be tested. The MongoDB database is an open source document-oriented database, and the stored buried point data is not limited by the storage table, and the flexibility is Stronger. Then the awk script configured on the MongoDB database analyzes the buried data to obtain all the buried data that failed the test verification code as the data to be analyzed. The awk script has the advantages of low threshold, simple positioning and fast data processing efficiency. Direct operation of buried data in the MongoDB database without cumbersome installation and configuration. Then, the preset analysis algorithm is used to analyze the parameter information in the analysis data to obtain the analysis result that causes the buried point test to fail, and the analysis result can visually display the influence of each parameter information on the test failure of the function module of the buried point, so as to facilitate Improve the software to be tested.

DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings used in the embodiments or the prior art description will be briefly described below. Obviously, the drawings in the following description are only the present application. For some embodiments, other drawings may be obtained from those of ordinary skill in the art in light of the inventive workability.

1 is a flow chart of a software testing method in Embodiment 1 of the present application.

2 is a schematic block diagram of a software testing device in Embodiment 2 of the present application.

3 is a schematic diagram of an electronic device in Embodiment 3 of the present application.

Embodiments of the invention

In the following description, for purposes of illustration and description However, it will be apparent to those skilled in the art that the present invention may be practiced in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the application.

In order to explain the technical solutions described in the present application, the following description will be made by way of specific embodiments.

Example 1

FIG. 1 shows a flow chart of a software testing method in this embodiment. The software test method is coordinated by the client and the server to complete the testing process of the software to be tested. The client and the server may be connected through a wireless network such as a WiFi network, a 3G network, or a 4G network, or may be connected through a wired network. The client can be a terminal that can be connected to the server, such as a smartphone, a notebook, a tablet, a PAD, or a desktop computer, to which the software to be tested is installed. As shown in FIG. 1, the software testing method includes the following steps:

S10: Running the software to be tested on the client, the software to be tested includes at least one function module, and each function module has at least one buried point.

Specifically, the software to be tested is installed and run on the client, and the software to be tested is provided with at least one function module, and each function module is provided with at least one buried point, and when the client runs the corresponding software to be tested When the function module is used, the buried point on the function module is triggered.

S20: When the buried point on the software to be tested is triggered, the buried point data is generated, and the buried point data is sent to the MongoDB database; the buried point data includes the buried point ID, the test check code, and the parameter information.

Specifically, when the buried point on the software to be tested is triggered, the generated buried point data can reflect the test result, so as to analyze and improve based on the buried point data, and improve the user's satisfaction with the software to be tested. For example, in a financial product APP, including a user login module, a product inquiry module, an upload product, and a payment module, and the user login module includes a user registration, a login interface, a retrieval of a user name, or a password recovery, etc., Program codes such as user registration, login interface, retrieving user name or retrieving passwords are provided with a buried point. When the user runs the software to be tested through the client, and performs user registration, login interface, retrieved user name or retrieved password, etc. In the corresponding operation, the client generates the buried point data and sends the buried point data to the MongoDB database.

The buried point ID is used to uniquely identify the identifier of the buried point, and the identifier is numbered according to a preset numbering rule. In this embodiment, the number of the function module ID + serial number may be numbered. For example, in the above-mentioned wealth management product APP, if the function module ID of the user login module is X1, and the function module ID registered by the user is X101, the available X10101 indicates the first buried point set in the user registration program code.

The test verification code is used to mark whether the program code test corresponding to the buried point is successful, including two test verification codes, success and failure. In this embodiment, the test verification code can be represented by two letters Y and N, respectively, and can also be represented by other codes. The test verification code distinguishes whether the program code test corresponding to the buried point is successful. Based on the test verification code, all the buried point data can be divided into two types, and the buried check data of the test is verified by the test verification code, without special Regular troubleshooting by developers can reduce the workload of the testing process to a certain extent, reduce testing time and save labor costs.

The parameter information is used to objectively reflect the operating environment of the program code where the buried point is located, which is closely related to the success of the software test to be tested. Specifically, the parameter information includes at least one of a device model, a device configuration, a trigger time, a network type, a network bandwidth, and a network bandwidth time delay product.

In this embodiment, the device model is an internal number of the client on which the software to be tested is installed, and the device model is associated with the performance of the client. Taking smart phones as an example, each smart phone manufacturer distinguishes different versions of smart phones, such as iphone4 and iphone5, by the device model when producing the corresponding brand of smart phones. The device configuration may be an operating system installed on the client, such as an Android system, an IOS operating system, a Windows system, a Linux system, or the like, or may be a processor or other hardware model installed on the client, such as an i5 or i7 processor. . The triggering time may be the time for running the software to be tested, and the triggering time is related to the running network of the client. Generally, the failure rate of the software to be tested at the peak of the network is higher than the failure rate of the software to be tested under the low peak of the network. . The network type is the network used by the client to communicate with the server, and may be a wired network, or a wireless network such as a WiFi network, a 3G network, or a 4G network. Network bandwidth is the amount of data transmitted per unit time, that is, the data transmission rate. The network bandwidth time delay product is the maximum number of bits on the link.

Further, the buried point data sent by the client is directly stored in the MongoDB database, and the MongoDB database is an open source and document-oriented database, which is more flexible than the relational database stored in a table structure such as SQL. The analysis of the buried point data stored in the MongoDB database is implemented.

S30: The awk script configured on the MongoDB database obtains the test verification code as the failed buried point data, and determines the data to be analyzed.

Among them, awk script is a powerful text analysis tool, which can read all the buried data stored in the MongoDB database line by line, and then separate the buried data with spaces or other default separators, and separate the separated content. Analytical processing. In this embodiment, the awk script configured on the MongoDB database is used to analyze all the buried data, and the test verification code is the failed buried point data, and the data is determined as the data to be analyzed, so as to determine the buried point based on the data to be analyzed. The reason for the failure of the program code test is to improve the software to be tested based on the cause of the failure. It can be understood that the awk script can be used to directly determine the test verification code as the data to be analyzed as the data to be analyzed without installing other operating environments, and has the advantages of low threshold, simple positioning, and fast data processing efficiency. The cumbersome installation and configuration also eliminates the need for professionals with strong code capabilities to complete the test, further reducing the labor cost of the software testing process under test.

S40: The parameter analysis information in the analysis data is analyzed by using a preset analysis algorithm, and the analysis result that causes the buried point test to fail is obtained.

Specifically, the awk script configured on the MongoDB database first determines all the buried data that failed the test verification code as the data to be analyzed, and does not require a dedicated developer to periodically check the workload, which can reduce the workload during the test to a certain extent. , saving labor costs. Using the preset analysis algorithm to analyze the parameter information in all the data to be analyzed, the reason for the failure of the program code corresponding to the buried point can be obtained, so as to form the analysis result, the analysis process is automated, and the configuration expert is not required to analyze, which is beneficial to the analysis. Reduce the cost of analysis.

Specifically, the preset analysis algorithm includes a work breakdown structure algorithm, a resource decomposition structure algorithm, or an organization decomposition structure algorithm. Work Breakdown Structure (Work Breakdowm Structure, referred to as WBS) algorithm is a deliverable-oriented grouping of project elements. It summarizes and defines the entire scope of work of the project. Each drop represents a more detailed definition of the project work. Resource decomposition structure (Resouree Breakdowm Structure (RBS) algorithm is a resource hierarchy structure according to the type and form of resources. It is a kind of project decomposition structure, through which it can make schedules on the details of resource requirements, and can be aggregated to higher levels. One layer summarizes resource requirements and resource availability. Organizational decomposition structure (Organizational Breakdowm Structure (OBS) algorithm is an extraordinary form of project organization chart. It describes the specific organizational unit responsible for each project activity. It is a project that links work packages to relevant departments or units in a hierarchical and systematic manner. Organize the graphics.

In this embodiment, the Work Breakdow Structure (WBS) algorithm divides all parameter information into device model, device configuration, trigger time, network type, network bandwidth, and network bandwidth delay according to a certain classification principle. Product and other major categories, then subdivide each major class into several sub-categories, and then further subdivide each sub-category into several groups... and so on, to divide all parameter information into non-reclassifiable categories. The category is then determined whether the parameter information of each classification category is associated with the test failure of the software to be tested, and the purpose thereof is clear, so as to avoid missing relevant parameter information that affects the success or failure of the corresponding functional module test of the software under test during the analysis. Specifically, each non-re-divided classification category corresponds to a category ID; the control variable method may be used to determine whether the parameter information corresponding to each classification category ID is associated with the test failure of the software to be tested, to determine the impact on the successful operation of the software to be tested. Phase difference parameter information.

In the software testing method provided by the embodiment, the MongoDB database is used to store the buried point data triggered by the client running the software to be tested, and the MongoDB database is an open source document-oriented database, and the stored buried point data is not stored in the table. The restrictions are more flexible. Then the awk script configured on the MongoDB database analyzes the buried data to obtain all the buried data that failed the test verification code as the data to be analyzed. The awk script has the advantages of low threshold, simple positioning and fast data processing efficiency. Direct operation of buried data in the MongoDB database without cumbersome installation and configuration. Then, the preset analysis algorithm is used to analyze the parameter information in the analysis data to obtain the analysis result that causes the buried point test to fail, and the analysis result can visually display the influence of each parameter information on the test failure of the function module of the buried point, so as to facilitate Improve the software to be tested.

In a specific implementation manner, when the buried point data on the software to be tested is triggered, the embedded point data generated by the trigger needs to be sent to the corresponding MongoDB database, and corresponding configuration is needed to ensure that the buried point data is directly sent to MongoDB. The database and the awk script analyze the buried data in the MongoDB database. Therefore, in the software testing method, before step S10, the following steps are further included:

S01: Install the MongoDB database on the server, complete the information configuration of the MongoDB database and the server, so that the MongoDB database can monitor and acquire the buried data in real time.

Specifically, run the MongoDB database installer on the server and run the mongod command to install the MongoDB database on the server. Then create a data directory on the server and start the server, waiting for the server to connect to the client. Mongod generally defaults to the data directory /data/db without parameters. If it does not exist, it will fail to start. In this embodiment, the data directory is created as mkdir-p/data/db. Then configure the 27017 port of the MongoDB database to listen to the server, configure the port 28017 to listen for HTTP requests, and when the client accesses http://server address 28017, the client and server are connected.

In step S01, the information configuration between the MongoDB database and the server is completed. Since the MongoDB database supports storing data of relatively complex data types, the MongoDB database can monitor the http request received by the server in real time, when the client uploads the buried data server. Can be stored directly in the MongoDB database, no need to convert to a storage table structure and then store.

S02: Set the awk script to periodically obtain the test verification code as the failed buried point data.

Specifically, the awk script is preset to obtain the test verification code as the failed buried point data to determine the data to be analyzed, and the awk script has the advantages of low threshold and simple positioning, and does not require special test personnel to check the point, which is beneficial to improve the test. effectiveness. The awk script periodically acquires the test verification code as the failed buried point data and analyzes it by using a preset analysis algorithm, and can obtain the analysis result periodically; without manual monitoring.

In a specific embodiment, the software testing method further includes the following steps:

S50: Receive a query instruction sent by the client to the server through the client, and the query instruction includes a buried point ID.

Specifically, the client (such as a tester or a developer) may input a query instruction to the client, and after receiving the query instruction, the client sends the query command to the server. The query instruction may include only one buried point ID to query parameter information of a program code that affects a specific buried point, or may be a function module ID, and the function module includes at least one buried point ID to query parameters affecting a specific function module. information.

S60: Acquire a query result corresponding to the buried point ID based on the query instruction.

The query result is an analysis result corresponding to the buried point ID. Specifically, after receiving the query instruction, the MongoDB database on the server may obtain an analysis result that analyzes all data to be analyzed corresponding to the buried point ID in the query instruction by using a preset analysis algorithm, and uses the analysis result as a query. The result is output. The client displays the query result, so that the client can improve the program code or function module corresponding to the buried point ID based on the query result.

It can be understood that, in the software testing method provided by the embodiment, the document-oriented MongoDB database and the awk script that is good at processing the document row and column can cooperate to directly filter, compare, and count all the buried data uploaded to the MongoDB database. , timing output or loop output operations. Moreover, the software testing method can be based on the original development environment of the client, without changing the running environment of the client, realizing uploading the buried data to the real-time or batch in batch without sacrificing the user experience and delaying the data request. The server's MongoDB database is lightweight, simple, and portable.

Example 2

FIG. 2 shows a schematic block diagram of the software testing device in this embodiment. The software testing device includes a client and a server, and cooperates with the client and the server to complete the testing process of the software to be tested. The client and the server may be connected through a wireless network such as a WiFi network, a 3G network, or a 4G network, or may be connected through a wired network. The client can be a terminal that can be connected to the server, such as a smartphone, a notebook, a tablet, a PAD, or a desktop computer, to which the software to be tested is installed. As shown in FIG. 2, the software testing device includes a software running module 10, a buried point data generating module 20, a data to be analyzed determining module 30, an analysis result obtaining module 40, an information configuration module 50, a query instruction receiving module 60, and a query result acquisition. Module 70.

The software running module 10 is configured to run the software to be tested on the client. The software to be tested includes at least one functional module, and each functional module is provided with at least one buried point.

The buried point data generating module 20 is configured to generate buried point data when the buried point on the software to be tested is triggered, and send the buried point data to the MongoDB database; the buried point data includes a buried point ID, a test check code, and a parameter. information.

The to-be-analyzed data determining module 30 is configured to enable the awk script configured on the MongoDB database to obtain the test verification code as the failed buried point data, and determine the data to be analyzed.

The analysis result obtaining module 40 is configured to analyze the parameter information in the analysis data by using a preset analysis algorithm, and obtain an analysis result that causes the buried point test to fail.

In the software testing device provided by the embodiment, the MongoDB database is used to store the embedded data triggered by the client running the software to be tested. The MongoDB database is an open source document-oriented database, and the stored buried point data is not stored in the table. The restrictions are more flexible. Then the awk script configured on the MongoDB database analyzes the buried data to obtain all the buried data that failed the test verification code as the data to be analyzed. The awk script has the advantages of low threshold, simple positioning and fast data processing efficiency. Direct operation of buried data in the MongoDB database without cumbersome installation and configuration. Then, the preset analysis algorithm is used to analyze the parameter information in the analysis data to obtain the analysis result that causes the buried point test to fail, and the analysis result can visually display the influence of each parameter information on the test failure of the function module of the buried point, so as to facilitate Improve the software to be tested.

In a specific implementation manner, when the buried point data on the software to be tested is triggered, the embedded point data generated by the trigger needs to be sent to the corresponding MongoDB database, and corresponding configuration is needed to ensure that the buried point data is directly sent to MongoDB. The database and the awk script analyze the buried data in the MongoDB database. Therefore, the software testing device also includes an information configuration module 50.

The information configuration module 50 is configured to install the MongoDB database on the server, complete the information configuration of the MongoDB database and the server, so that the MongoDB database monitors and acquires the buried point data in real time.

The information configuration module 50 can complete the information configuration between the MongoDB database and the server. Since the MongoDB database supports storing data of relatively complex data types, the MongoDB database can monitor the http request received by the server in real time, and the client uploads the buried data server. It can be stored directly in the MongoDB database without being converted to a storage table structure for storage.

The information configuration module 50 is further configured to set the awk script to periodically acquire the test verification code as the failed buried point data.

In a specific embodiment, the software testing device further includes a query instruction receiving module 60 and a query result obtaining module 70.

The query instruction receiving module 60 is configured to receive a query instruction sent by the client to the server through the client, and the query instruction includes a buried point ID.

The query result obtaining module 70 is configured to obtain a query result corresponding to the buried point ID based on the query instruction.

It can be understood that the software testing device provided in this embodiment adopts a document-oriented MongoDB database and an awk script that is good at processing document rows and columns, and can directly filter, compare, and count all buried data uploaded to the MongoDB database. , timing output or loop output operations. Moreover, the software testing device can be based on the original development environment of the client, without changing the operating environment of the client, realizing uploading the buried data to the real-time or batch in batch without sacrificing the user experience and delaying the data request. The server's MongoDB database is lightweight, simple, and portable.

Example 3

FIG. 3 is a schematic diagram of an electronic device according to an embodiment of the present application. As shown in FIG. 3, the electronic device 3 of this embodiment includes a processor 30 and a memory 31 in which are stored computer readable instructions 32, such as software test programs, executable on the processor 30. The processor 30 executes the computer readable instructions 32 to implement the steps in the various software test method embodiments described above, such as steps 10 through 40 shown in FIG. Alternatively, when the processor 30 executes the computer readable instructions 32, the functions of the modules/units in the various apparatus embodiments described above are implemented, such as the functions of the modules 10 to 70 shown in FIG.

Illustratively, the computer readable instructions 32 may be partitioned into one or more modules/units that are stored in the memory 31 and executed by the processor 30, To complete this application. The one or more modules/units may be a series of computer readable instruction segments capable of performing a particular function, the instruction segments being used to describe the execution of the computer readable instructions 32 in the electronic device 3.

The electronic device 3 can be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server. The electronic device may include, but is not limited to, the processor 30, the memory 31. It will be understood by those skilled in the art that FIG. 3 is merely an example of the electronic device 3 and does not constitute a limitation on the electronic device 3, and may include more or less components than those illustrated, or combine some components, or different components. For example, the electronic device may further include an input and output device, a network access device, a bus, and the like.

The so-called processor 30 can be a central processing unit (Central Processing Unit, CPU), can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. The general purpose processor may be a microprocessor or the processor or any conventional processor or the like.

The memory 31 may be an internal storage unit of the electronic device 3, such as a hard disk or a memory of the electronic device 3. The memory 31 may also be an external storage device of the electronic device 3, such as a plug-in hard disk equipped on the electronic device 3, a smart memory card (SMC), and a secure digital (SD). Card, flash card (Flash Card) and so on. Further, the memory 31 may also include both an internal storage unit of the electronic device 3 and an external storage device. The memory 31 is configured to store the computer readable instructions and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or is about to be output.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application, in essence or the contribution to the prior art, or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium. A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes. .

The above embodiments are only used to explain the technical solutions of the present application, and are not limited thereto; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still The technical solutions described in the embodiments are modified, or the equivalents of the technical features are replaced by the equivalents. The modifications and substitutions of the embodiments do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

A software testing method, comprising:

Running the software to be tested on the client, the software to be tested includes at least one function module, and each function module is provided with at least one buried point;

When the buried point on the software to be tested is triggered, generating buried point data, and transmitting the buried point data to a MongoDB database; the buried point data includes a buried point ID, a test check code, and parameter information. ;

The awk script configured on the MongoDB database obtains the buried data of the test verification code as a failure, and is determined as the data to be analyzed;

The parameter information in the data to be analyzed is analyzed by using a preset analysis algorithm to obtain an analysis result that causes the buried point test to fail.
The software testing method according to claim 1, wherein the running the software to be tested on the client further comprises:

Installing the MongoDB database on the server, completing information configuration of the MongoDB database and the server, so that the MongoDB database monitors and acquires the buried point data in real time;

The awk script is set to periodically acquire the test verification code as a failed buried point data.
The software testing method according to claim 1, wherein the parameter information comprises at least one of a device model, a device configuration, a trigger time, a network type, a network bandwidth, and a network bandwidth time delay product.
The software testing method according to claim 1, wherein the preset analysis algorithm comprises a work breakdown structure algorithm, a resource decomposition structure algorithm or an organization decomposition structure algorithm.
The software testing method according to any one of claims 1 to 4, further comprising:

Receiving, by the client, a query instruction sent by the client to the server, where the query instruction includes the buried point ID;

And obtaining a query result corresponding to the buried point ID based on the query instruction.
A software testing device, comprising:

a software running module, configured to run the software to be tested on the client, where the software to be tested includes at least one functional module, and each functional module is provided with at least one buried point;

a buried point data generating module, configured to generate buried point data when the buried point on the software to be tested is triggered, and send the buried point data to a MongoDB database; the buried point data includes a buried point ID , test verification code and parameter information;

The data analysis module to be analyzed is configured to enable the awk script configured on the MongoDB database to obtain the buried data of the test verification code as a failure, and determine the data to be analyzed;

The analysis result obtaining module is configured to analyze the parameter information in the data to be analyzed by using a preset analysis algorithm, and obtain an analysis result that causes the buried point test to fail.
The software testing device according to claim 6, further comprising:

An information configuration module, configured to install the MongoDB database on the server, complete information configuration of the MongoDB database and the server, so that the MongoDB database monitors and acquires the buried point data in real time;

The information configuration module is further configured to set the awk script to periodically acquire the buried verification data of the test verification code as a failure.
The software testing device according to claim 6, wherein the parameter information comprises at least one of a device model, a device configuration, a trigger time, a network type, a network bandwidth, and a network bandwidth time delay product.
The software testing device according to claim 6, wherein the preset analysis algorithm comprises a work breakdown structure algorithm, a resource decomposition structure algorithm or an organization decomposition structure algorithm.
The software testing device according to any one of claims 6-9, further comprising:

a query instruction receiving module, configured to receive a query instruction sent by the client to the server by using the client, where the query instruction includes the buried point ID;

The query result obtaining module is configured to obtain a query result corresponding to the buried point ID based on the query instruction.
An electronic device, comprising: a memory and a processor, wherein the memory stores computer readable instructions executable on the processor, and the processor implements the following steps when the computer readable instructions are executed :

Running the software to be tested on the client, the software to be tested includes at least one function module, and each function module is provided with at least one buried point;

When the buried point on the software to be tested is triggered, generating buried point data, and transmitting the buried point data to a MongoDB database; the buried point data includes a buried point ID, a test check code, and parameter information. ;

The awk script configured on the MongoDB database obtains the buried data of the test verification code as a failure, and is determined as the data to be analyzed;

The parameter information in the data to be analyzed is analyzed by using a preset analysis algorithm to obtain an analysis result that causes the buried point test to fail.
The electronic device according to claim 11, wherein the processor further implements the following steps when the computer readable instructions are executed:

Installing the MongoDB database on the server, completing information configuration of the MongoDB database and the server, so that the MongoDB database monitors and acquires the buried point data in real time;

The awk script is set to periodically acquire the test verification code as a failed buried point data.
The electronic device according to claim 11, wherein the parameter information comprises at least one of a device model, a device configuration, a trigger time, a network type, a network bandwidth, and a network bandwidth time delay product.
The electronic device according to claim 11, wherein the preset analysis algorithm comprises a work breakdown structure algorithm, a resource decomposition structure algorithm or an organization decomposition structure algorithm.
The electronic device according to any one of claims 11 to 14, wherein when the processor executes the computer readable instructions, the following steps are further implemented:

Receiving, by the client, a query instruction sent by the client to the server, where the query instruction includes the buried point ID;

And obtaining a query result corresponding to the buried point ID based on the query instruction.
A computer readable storage medium storing computer readable instructions, wherein the computer readable instructions, when executed by at least one processor, implement the following steps:

Running the software to be tested on the client, the software to be tested includes at least one function module, and each function module is provided with at least one buried point;

When the buried point on the software to be tested is triggered, generating buried point data, and transmitting the buried point data to a MongoDB database; the buried point data includes a buried point ID, a test check code, and parameter information. ;

The awk script configured on the MongoDB database obtains the buried data of the test verification code as a failure, and is determined as the data to be analyzed;

The parameter information in the data to be analyzed is analyzed by using a preset analysis algorithm to obtain an analysis result that causes the buried point test to fail.
The computer readable storage medium of claim 16, wherein the computer readable instructions are executed by at least one processor to implement the following steps:

Installing the MongoDB database on the server, completing information configuration of the MongoDB database and the server, so that the MongoDB database monitors and acquires the buried point data in real time;

The awk script is set to periodically acquire the test verification code as a failed buried point data.
The computer readable storage medium of claim 16, wherein the parameter information comprises at least one of a device model number, a device configuration, a trigger time, a network type, a network bandwidth, and a network bandwidth time delay product.
The computer readable storage medium according to claim 16, wherein the preset analysis algorithm comprises a work breakdown structure algorithm, a resource decomposition structure algorithm or an organization decomposition structure algorithm.
A computer readable storage medium according to claim 19, wherein when said computer readable instructions are executed by at least one processor, the steps of:

Receiving, by the client, a query instruction sent by the client to the server, where the query instruction includes the buried point ID;

And obtaining a query result corresponding to the buried point ID based on the query instruction.