WO2018184420A1 - Procédé de test de logiciel, appareil, dispositif électronique et support - Google Patents

Procédé de test de logiciel, appareil, dispositif électronique et support Download PDF

Info

Publication number
WO2018184420A1
WO2018184420A1 PCT/CN2018/074874 CN2018074874W WO2018184420A1 WO 2018184420 A1 WO2018184420 A1 WO 2018184420A1 CN 2018074874 W CN2018074874 W CN 2018074874W WO 2018184420 A1 WO2018184420 A1 WO 2018184420A1
Authority
WO
WIPO (PCT)
Prior art keywords
buried point
data
software
buried
mongodb database
Prior art date
Application number
PCT/CN2018/074874
Other languages
English (en)
Chinese (zh)
Inventor
陈奕玲
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2018184420A1 publication Critical patent/WO2018184420A1/fr

Links

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/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program
    • 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/362—Software debugging
    • G06F11/3644—Software debugging by instrumenting at runtime
    • 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/362—Software debugging
    • G06F11/366—Software debugging using diagnostics

Definitions

  • 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.
  • 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.
  • special analysis software such as Python software
  • the dedicated analysis software such as Python software
  • the professional training can complete the software testing process, and there is a problem of high labor costs.
  • 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.
  • 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 includes at least one function module, and each function module is provided with at least one buried point;
  • the buried point on the software to be tested 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:
  • Running the software to be tested on the client includes at least one function module, and each function module is provided with at least one buried point;
  • the buried point on the software to be tested 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 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:
  • Running the software to be tested on the client includes at least one function module, and each function module is provided with at least one buried point;
  • the buried point on the software to be tested 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 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.
  • 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.
  • 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.
  • Embodiment 1 is a flow chart of a software testing method in Embodiment 1 of the present application.
  • FIG. 2 is a schematic block diagram of a software testing device in Embodiment 2 of the present application.
  • Embodiment 3 is a schematic diagram of an electronic device in Embodiment 3 of the present application.
  • 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.
  • the software testing method includes the following steps:
  • 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.
  • 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.
  • 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.
  • a financial product APP including a user login module, a product inquiry module, an upload product, and a payment module
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • RBS Resource decomposition structure
  • 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.
  • OBS Organizational Breakdowm Structure
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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 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.
  • a financial product APP including a user login module, a product inquiry module, an upload product, and a payment module
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • RBS Resource decomposition structure
  • 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.
  • OBS Organizational Breakdowm Structure
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the software testing device 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 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.
  • 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.
  • 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.
  • 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 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.
  • the query result obtaining module 70 is configured to obtain 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.
  • 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.
  • the software testing device 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.
  • 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.
  • FIG. 3 is a schematic diagram of an electronic device according to an embodiment of the present application.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a computer readable 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. .

Landscapes

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

Abstract

La présente invention concerne un procédé de test de logiciel, un appareil, un dispositif électronique et un support, destinés à être utilisés dans le domaine technique du traitement d'informations d'ordinateur, le procédé consistant à : exécuter un logiciel à tester sur un terminal client, le logiciel à tester comprenant au moins un module de fonction, chaque module de fonction étant pourvu d'au moins un point enfoui ; lorsqu'un point enfoui sur le logiciel à tester est déclenché, générer des données de point enfoui et envoyer les données de point enterrées à une base de données MongoDB ; les données de point enterrées comprennent un ID de point enfoui, un code de vérification de test et des informations de paramètre ; la réalisation d'un script Awk configuré sur la base de données MongoDB acquiert le code de vérification de test en tant que données de point enfoui en échec, et déterminer celles-ci en tant que données à analyser ; et, à l'aide d'un algorithme d'analyse prédéfini, analyser les informations de paramètre dans les données à analyser afin d'acquérir des résultats d'analyse de la cause de l'échec du test de point enfoui. La présente solution utilise une base de données MongoDB pour stocker des données de point enfoui, et est donc plus flexible ; l'utilisation d'un script Awk pour analyser des données de point enfoui afin d'acquérir des données à analyser présente les avantages d'un faible seuil, d'un positionnement simple et d'une efficacité de traitement rapide de données.
PCT/CN2018/074874 2017-04-06 2018-01-31 Procédé de test de logiciel, appareil, dispositif électronique et support WO2018184420A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710221079.4 2017-04-06
CN201710221079.4A CN107688530B (zh) 2017-04-06 2017-04-06 软件测试方法及装置

Publications (1)

Publication Number Publication Date
WO2018184420A1 true WO2018184420A1 (fr) 2018-10-11

Family

ID=61152357

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/074874 WO2018184420A1 (fr) 2017-04-06 2018-01-31 Procédé de test de logiciel, appareil, dispositif électronique et support

Country Status (2)

Country Link
CN (1) CN107688530B (fr)
WO (1) WO2018184420A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110401899A (zh) * 2019-07-25 2019-11-01 厦门盈趣科技股份有限公司 音频测试方法及相关装置
CN111190807A (zh) * 2018-11-14 2020-05-22 杭州萤石软件有限公司 一种埋点测试方法及设备

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108664401B (zh) * 2018-05-11 2021-10-12 创新先进技术有限公司 埋点合理性的评估方法及装置
CN109101414B (zh) * 2018-06-14 2021-10-15 挖财网络技术有限公司 基于埋点数据的海量ui测试生成方法及其装置
CN109684155B (zh) * 2018-08-27 2022-11-15 平安科技（深圳）有限公司 监控配置方法、装置、设备及可读存储介质
CN110875858B (zh) * 2018-08-31 2023-06-27 北京京东尚科信息技术有限公司 应用测试数据抓取方法、系统、设备及存储介质
CN111506489B (zh) * 2019-01-30 2023-05-30 斑马智行网络(香港)有限公司 测试方法、系统、设备、服务器及存储介质
CN109960651A (zh) * 2019-02-13 2019-07-02 北京达佳互联信息技术有限公司 埋点测试方法、系统、装置和计算机可读存储介质
CN110515830A (zh) * 2019-07-15 2019-11-29 平安普惠企业管理有限公司 操作轨迹可视化方法、装置、设备及存储介质
CN110674048B (zh) * 2019-09-27 2023-09-22 北京新氧科技有限公司 一种埋点测试特征获取方法及相关装置
CN111090592A (zh) * 2019-12-20 2020-05-01 上海品顺信息科技有限公司 埋点的自动化测试方法、终端及可读存储介质
CN111813698A (zh) * 2020-08-27 2020-10-23 江苏洲际软件有限公司 一种软件测试装置及测试方法
CN112286834B (zh) * 2020-12-31 2021-04-16 智道网联科技(北京)有限公司 多设备软件测试方法、测试装置、电子设备及存储介质
CN113485889B (zh) * 2021-06-29 2023-08-15 平安银行股份有限公司 埋点数据校验方法、装置、电子设备及存储介质
CN113688031B (zh) * 2021-07-15 2024-03-26 上海浦东发展银行股份有限公司 一种基于字节码增强技术的测试定位方法
CN113673997A (zh) * 2021-08-27 2021-11-19 深圳鼎盛电脑科技有限公司 一种资金计算引擎的可视化处理方法、装置、设备及介质
CN114168430A (zh) * 2022-01-06 2022-03-11 携程旅游网络技术（上海）有限公司 前端异常告警配置方法、系统、设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102053906A (zh) * 2009-10-30 2011-05-11 国际商业机器公司 用于收集程序运行时信息的系统和方法
CN103778244A (zh) * 2014-02-11 2014-05-07 五八同城信息技术有限公司 一种基于用户行为日志的自动化报表分析方法
CN104915296A (zh) * 2015-06-29 2015-09-16 北京金山安全软件有限公司 埋点测试方法、数据的查询方法及装置
CN106294091A (zh) * 2016-08-11 2017-01-04 福建富士通信息软件有限公司 一种无侵入式日志拦截性能分析方法及系统
US9600405B1 (en) * 2008-10-03 2017-03-21 Federal Home Loan Mortgage Corporation (Freddie Mac) Systems and methods for testing a software application

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7865704B2 (en) * 2006-03-29 2011-01-04 Freescale Semiconductor, Inc. Selective instruction breakpoint generation based on a count of instruction source events
CN101201787A (zh) * 2006-12-12 2008-06-18 英业达股份有限公司 软件程序的调试系统及方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9600405B1 (en) * 2008-10-03 2017-03-21 Federal Home Loan Mortgage Corporation (Freddie Mac) Systems and methods for testing a software application
CN102053906A (zh) * 2009-10-30 2011-05-11 国际商业机器公司 用于收集程序运行时信息的系统和方法
CN103778244A (zh) * 2014-02-11 2014-05-07 五八同城信息技术有限公司 一种基于用户行为日志的自动化报表分析方法
CN104915296A (zh) * 2015-06-29 2015-09-16 北京金山安全软件有限公司 埋点测试方法、数据的查询方法及装置
CN106294091A (zh) * 2016-08-11 2017-01-04 福建富士通信息软件有限公司 一种无侵入式日志拦截性能分析方法及系统

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111190807A (zh) * 2018-11-14 2020-05-22 杭州萤石软件有限公司 一种埋点测试方法及设备
CN111190807B (zh) * 2018-11-14 2023-08-18 杭州萤石软件有限公司 一种埋点测试方法及设备
CN110401899A (zh) * 2019-07-25 2019-11-01 厦门盈趣科技股份有限公司 音频测试方法及相关装置

Also Published As

Publication number Publication date
CN107688530B (zh) 2020-04-10
CN107688530A (zh) 2018-02-13

Similar Documents

Publication Publication Date Title
WO2018184420A1 (fr) Procédé de test de logiciel, appareil, dispositif électronique et support
US11314574B2 (en) Techniques for managing and analyzing log data
US10372600B2 (en) Systems and methods for automated web performance testing for cloud apps in use-case scenarios
CN109302522B (zh) 测试方法、装置以及计算机系统和介质
WO2018113385A1 (fr) Procédé et système de suivi dynamique d'application de client, client et serveur
US11227221B2 (en) Framework management method and apparatus
US9569325B2 (en) Method and system for automated test and result comparison
US20180349254A1 (en) Systems and methods for end-to-end testing of applications using dynamically simulated data
WO2018120721A1 (fr) Procédé et système pour tester une interface utilisateur, dispositif électronique et support de stockage lisible par ordinateur
US20160283348A1 (en) Testing of application service versions on live data
US20180260201A1 (en) Intelligent software deployment on an iaas platform
CN112910945A (zh) 请求链路跟踪方法和业务请求处理方法
WO2014150562A1 (fr) Plate-forme de gestion de paramètres et dispositifs
US20140089477A1 (en) System and method for monitoring storage machines
CN110750458A (zh) 大数据平台测试方法、装置、可读存储介质及电子设备
US11526431B2 (en) Systems and methods for automated provisioning of a virtual mainframe test environment
EP3168748A1 (fr) Système et procédé de surveillance des performances d'applications
WO2021120975A1 (fr) Procédé et appareil de surveillance
CN110737594A (zh) 自动生成测试用例的数据库标准符合性测试方法及装置
CN111177113A (zh) 数据迁移方法、装置、计算机设备和存储介质
US9158641B2 (en) Cloud auto-test system, method and non-transitory computer readable storage medium of the same
US11144440B1 (en) Implementing device-specific libraries for validation testing
CN112596723B (zh) 数据库脚本生成方法、装置、设备及介质
CN112882948A (zh) 一种应用的稳定性测试方法、装置、系统及存储介质
WO2015039585A1 (fr) Procédé et dispositif pour tester la fiabilité d'un logiciel

Legal Events

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

Ref document number: 18780320

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 15.01.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18780320

Country of ref document: EP

Kind code of ref document: A1