Software testing method and device, electronic equipment and storage medium
Through a software testing method, using test buried points and event trigger scripts, efficient automation of software testing is achieved, solving the problem of low software testing efficiency in the existing technology and improving software stability and user experience.
Patent Information
- Application Number
- CN202411500557.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-25
- Publication Date
- 2025-03-04
AI Technical Summary
The prior art is difficult to efficiently detect defects and vulnerabilities in programs in software testing, resulting in poor software stability and user experience.
Provide a software testing method. After obtaining test instructions, it obtains the test point information and stage identification of the software to be tested, generates prompt information based on the stage or obtains event trigger scripts, triggers events manually or automatically, collects data and detects matching, and generates test results.
Discover software problems in a timely manner during the development stage, reduce problems in the test version before launch, improve software testing efficiency, and reduce the risk of release delays.
Smart Images

Figure CN119557206A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a software testing method, device, electronic device and storage medium. Background Art
[0002] Before the software is launched, it is necessary to test all functions of the software to timely discover defects and loopholes in the program and ensure the stability of the program. This will help improve the user experience of using the program and enhance the user's trust in the program.
[0003] Therefore, a software testing solution is needed. Summary of the invention
[0004] The purpose of the embodiments of the present application is to provide a software testing method, device, electronic device and storage medium to efficiently test the software. The specific technical solution is as follows:
[0005] In a first aspect of an embodiment of the present application, a software testing method is provided, which is applied to a testing platform, and the method includes:
[0006] In response to obtaining the test instruction, obtaining the test tracking point information for the software to be tested and the stage identifier of the stage in which the software to be tested is located, wherein the test tracking point information includes: a first event identifier of an event that triggers the test tracking point to collect data and a first field attribute of the data to be collected;
[0007] If the stage identifier indicates that the software to be tested is in the development stage, a first prompt message is generated and displayed on a display interface, wherein the first prompt message is used to prompt a tester to manually trigger an event indicated by the first event identifier on a first test device, wherein the first test device is: a device running a development process version of the software to be tested;
[0008] If the stage identifier indicates that the software to be tested is in the pre-launch test stage, then obtaining an event triggering script of the event indicated by the first event identifier, running the pre-launch test version of the software to be tested on the second test device, and instructing the second test device to run the event triggering script;
[0009] Acquire the collected data collected by the test embedding point uploaded by the test device and the second event identifier of the event that triggers the test embedding point to collect data, wherein the test device is the first test device or the second test device;
[0010] The matching identifier of the second event identifier is searched in the first event identifier, and it is detected whether the acquired collected data matches the first field attribute corresponding to the found matching identifier, and a test result is generated based on the detection result.
[0011] In a possible implementation manner, after obtaining the test tracking point information for the software to be tested and the stage identifier of the stage in which the software to be tested is located, the method further includes:
[0012] Parsing the tracking configuration document of the test version of the software to be tested, and obtaining the second field attribute of the data to be collected recorded in the tracking configuration document;
[0013] For each test tracking point, determine the matching tracking point of the test tracking point in the tracking points recorded in the tracking point configuration document, and detect whether the first field attribute corresponding to the test tracking point is recorded in the second field attribute corresponding to the determined matching tracking point;
[0014] If the first field attributes corresponding to each test tracking point are all recorded in the second field attributes corresponding to the matching tracking points of each test tracking point, then the step of generating a first prompt message if the stage identifier indicates that the software to be tested is in the development stage is executed, or the step of obtaining an event trigger script for the event represented by the first event identifier is executed if the stage identifier indicates that the software to be tested is in the pre-online testing stage.
[0015] In a possible implementation manner, after parsing the tracking configuration document of the test version of the software to be tested to obtain the second field attribute of the data to be collected recorded in the tracking configuration document, the method further includes:
[0016] Matching the second field attribute with a preset sensitive field attribute to determine whether a sensitive field attribute exists in the second field attribute;
[0017] If there is a sensitive field attribute in the second field attribute, generate second prompt information based on the sensitive field attribute in the second field attribute, and display the second prompt information on the display interface, wherein the second prompt information is used to prompt the tester that there is a sensitive field attribute in the second field attribute;
[0018] If there is no sensitive field attribute in the second field attribute, execute the steps of determining the matching buried point of the test buried point among the buried points recorded in the buried point configuration document for each test buried point, and detecting whether the first field attribute corresponding to the test buried point is recorded in the second field attribute corresponding to the determined matching buried point.
[0019] In a possible implementation, the tracking configuration document includes: comments recorded in the implementation code of the test version and / or a parameter configuration file of the test version.
[0020] In a possible implementation manner, the event triggering script of the event represented by the first event identifier is generated in the following manner:
[0021] Capturing the operation performed by the first test device during the process in which the tester manually triggers the event indicated by the first event identifier;
[0022] Based on the captured operation, an event triggering script of the event represented by the first event identifier is generated.
[0023] In a possible implementation manner, the test point information is obtained by:
[0024] Obtain the tracking requirement document for the software to be tested;
[0025] According to the background color of the fields recorded in the embedding point requirement document, locate the first storage area for recording the test embedding point information in the embedding point requirement document, determine the first event identifier of the event that triggers the test embedding point to perform data collection and the first field attribute of the data to be collected from the first storage area, and / or search the embedding point information field in the embedding point requirement document, locate the second storage area for recording the test embedding point information based on the embedding point information field, and determine the first event identifier of the event that triggers the test embedding point to perform data collection and the first field attribute of the data to be collected from the second storage area.
[0026] In a possible implementation manner, the test instruction is generated by triggering a software code update operation of the software to be tested; or, the test instruction is generated according to a set period.
[0027] In a second aspect of an embodiment of the present application, a software testing device is provided, which is applied to a testing platform, and the device includes:
[0028] An acquisition module is used to obtain test tracking information for the software to be tested and a stage identifier of the stage in which the software to be tested is located in response to obtaining a test instruction, wherein the test tracking information includes: a first event identifier of an event that triggers the test tracking to collect data and a first field attribute of the data to be collected;
[0029] a prompt module, configured to generate a first prompt message if the stage identifier indicates that the software to be tested is in a development stage, and display the first prompt message on a display interface, wherein the first prompt message is used to prompt a tester to manually trigger an event indicated by the first event identifier on a first test device, wherein the first test device is a device running a development process version of the software to be tested;
[0030] A first acquisition module is used for acquiring an event triggering script of the event represented by the first event identifier if the stage identifier represents that the software to be tested is in a pre-launch test stage, and running the pre-launch test version of the software to be tested on a second test device, and instructing the second test device to run the event triggering script;
[0031] A second acquisition module, used to acquire the collected data collected by the test embedding point uploaded by the test device and a second event identifier of the event that triggers the test embedding point to collect data, wherein the test device is the first test device or the second test device;
[0032] The detection module is used to search for a matching identifier of the second event identifier in the first event identifier, detect whether the acquired collected data matches a first field attribute corresponding to the found matching identifier, and generate a test result based on the detection result.
[0033] In a possible implementation manner, the device further includes:
[0034] A parsing module is used to parse the test tracking point configuration document of the test version of the software to be tested after obtaining the test tracking point information for the software to be tested and the stage identifier of the stage in which the software to be tested is located, and obtain the second field attribute of the data to be collected recorded in the tracking point configuration document;
[0035] The detection module is further used to determine, for each test buried point, a matching buried point of the test buried point in the buried points recorded in the buried point configuration document, and detect whether a first field attribute corresponding to the test buried point is recorded in a second field attribute corresponding to the determined matching buried point;
[0036] The prompt module is further configured to generate a first prompt message if the first field attributes corresponding to each test embedding point are all recorded in the second field attributes corresponding to the matching embedding points of each test embedding point, and the stage identifier indicates that the software to be tested is in the development stage;
[0037] The first acquisition module is also used to obtain the event trigger script of the event represented by the first event identifier if the first field attributes corresponding to each test embedding point are recorded in the second field attributes corresponding to the matching embedding points of each test embedding point, and the stage identifier indicates that the software to be tested is in the pre-online testing stage.
[0038] In a possible implementation manner, the detection module is further configured to, after parsing the tracking configuration document of the test version of the software to be tested and obtaining the second field attribute of the data to be collected of the tracking recorded in the tracking configuration document, match the second field attribute with a preset sensitive field attribute to determine whether there is a sensitive field attribute in the second field attribute;
[0039] The prompt module is further used for generating second prompt information based on the sensitive field attributes in the second field attributes if there are sensitive field attributes in the second field attributes, and displaying the second prompt information on the display interface, wherein the second prompt information is used to prompt the tester that there are sensitive field attributes in the second field attributes;
[0040] The detection module is also used to determine, for each test embedding point, a matching embedding point of the test embedding point in the embedding points recorded in the embedding point configuration document if there is no sensitive field attribute in the second field attribute, and detect whether the first field attribute corresponding to the test embedding point is recorded in the second field attribute corresponding to the determined matching embedding point.
[0041] In a possible implementation, the tracking configuration document includes: comments recorded in the implementation code of the test version and / or a parameter configuration file of the test version.
[0042] In a possible implementation manner, the event triggering script of the event represented by the first event identifier is generated in the following manner:
[0043] Capturing the operation performed by the first test device during the process in which the tester manually triggers the event indicated by the first event identifier;
[0044] Based on the captured operation, an event triggering script of the event represented by the first event identifier is generated.
[0045] In a possible implementation manner, the test point information is obtained by:
[0046] Obtain the tracking requirement document for the software to be tested;
[0047] According to the background color of the fields recorded in the embedding point requirement document, locate the first storage area for recording the test embedding point information in the embedding point requirement document, determine the first event identifier of the event that triggers the test embedding point to perform data collection and the first field attribute of the data to be collected from the first storage area, and / or search the embedding point information field in the embedding point requirement document, locate the second storage area for recording the test embedding point information based on the embedding point information field, and determine the first event identifier of the event that triggers the test embedding point to perform data collection and the first field attribute of the data to be collected from the second storage area.
[0048] In a possible implementation manner, the test instruction is generated by triggering a software code update operation of the software to be tested; or, the test instruction is generated according to a set period.
[0049] In a third aspect of an embodiment of the present application, an electronic device is provided, which is deployed with a test platform, wherein the electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;
[0050] Memory, used to store computer programs;
[0051] The processor is used to implement the steps of any method described in the first aspect when executing the program stored in the memory.
[0052] In a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the steps of any method described in the first aspect are implemented.
[0053] Beneficial effects of the embodiments of the present application:
[0054] The software testing method provided by the embodiment of the present application performs manually triggered tracking point testing on the development process version of the software to be tested during the development stage, so as to promote the front-end of the test node, timely discover the problems of the software to be tested during the development stage, and then make timely adjustments, thereby reducing the problems existing in the software to be tested before going online. The software to be tested is further tested in the pre-online test stage to ensure the accuracy of the software functions. In this way, when the software to be tested is subjected to automated tracking point testing in the pre-online test stage, the number of tracking points and the number of tests will also be reduced. However, the automated tracking point testing is more complicated and takes longer time than the manually triggered tracking point testing process because it requires the construction of a test environment. Reducing the number of tracking points and the number of tests in the automated tracking point testing can reduce the cost of automated tracking point testing on the one hand, and greatly shorten the time required for automated tracking point testing on the other hand, which greatly shortens the time required for the entire software testing process, thereby improving the software testing efficiency and reducing the risk of delayed release of the software to be tested.
[0055] Of course, implementing any product or method of the present application does not necessarily require achieving all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS
[0056] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application, and for ordinary technicians in this field, other embodiments can also be obtained based on these drawings.
[0057] Figure 1 A first flow chart of the software testing method provided in the embodiment of the present application;
[0058] Figure 2 A second flowchart of the software testing method provided in the embodiment of the present application;
[0059] Figure 3 A third flow chart of the software testing method provided in the embodiment of the present application;
[0060] Figure 4 A flow chart of a method for generating an event-triggered script provided in an embodiment of the present application;
[0061] Figure 5 A flow chart of a method for obtaining test tracking point information provided in an embodiment of the present application;
[0062] Figure 6 A flowchart of an example of a software testing method provided in an embodiment of the present application;
[0063] Figure 7 A schematic diagram of the structure of a software testing device provided in an embodiment of the present application;
[0064] Figure 8 A schematic diagram of the structure of a test platform provided in an embodiment of the present application. DETAILED DESCRIPTION
[0065] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field based on the present application belong to the scope of protection of the present application.
[0066] Before the software is launched, it is necessary to test all functions of the software to timely discover defects and loopholes in the program and ensure the stability of the program. This will help improve the user experience of using the program and enhance the user's trust in the program.
[0067] Therefore, a software testing solution is needed.
[0068] The present application embodiment provides a software testing method, which is applied to a testing platform, such as Figure 1 As shown, the method includes the following steps S101-S106.
[0069] The test platform can be deployed on electronic devices such as desktop computers, laptops or servers. The test platform can be integrated with a point scanning test tool to implement the subsequent software testing process.
[0070] Step S101, in response to obtaining a test instruction, obtain test tracking information for the software to be tested and a stage identifier of the stage in which the software to be tested is located.
[0071] Among them, the test tracking point information includes: the first event identifier of the event that triggers the test tracking point to collect data and the first field attribute of the data to be collected.
[0072] A test tracking point is a section of code added to the implementation code of the software to be tested, which is used to collect specific data output by the software to be tested when specific events occur during the operation of the software to be tested.
[0073] The events that trigger the test tracking point for data collection may include: operations performed on the software to be tested, or scenarios triggered in the software to be tested. The operations performed on the software to be tested may include: click operations, selection operations, input operations, etc. The scenario triggered in the software to be tested may be a collection of the above operations. For example, the scenario triggered in the software to be tested may be a login scenario, and the login scenario may be a collection of the following operations: selecting an account and password login method, entering an account and password, and clicking a login button.
[0074] The first event identifier may be a label or event name pre-set for the event that triggers the test point to collect data.
[0075] The data to be collected is the data that needs to be collected when the event indicated by the first event identifier occurs.
[0076] The first field attribute represents the type of data to be collected. For example, the data to be collected includes: city name, distance, and duration, wherein the first field attribute corresponding to the city name is text, and the first field attributes corresponding to the distance and duration are both numerical values.
[0077] The test instruction is used to instruct the test platform to start the tracking test process for the software to be tested, that is, to obtain the test tracking information for the software to be tested and the stage identifier of the software to be tested.
[0078] The phases of the software to be tested include the development phase and the pre-launch test phase. A correspondence between the phase identifier and the two phases can be established, and different phase identifiers can be used to represent different phases. For example, the correspondence between the phase identifier and the phase of the software to be tested can be: when the software to be tested is in the development phase, the corresponding phase identifier is 0; when the software to be tested is in the pre-launch test phase, the corresponding phase identifier is 1.
[0079] The test instructions obtained by the test platform can be generated according to the following method 1 or method 2.
[0080] Method 1: The test instruction is generated by triggering a software code update operation of the software to be tested.
[0081] The test platform can monitor the software code update status of the software to be tested in the code library. When the developer uploads the new version of the software code to be tested through CI (Continuous Integration), it can trigger the device where the code library is located to generate test instructions for the software to be tested. The device where the code library is located will then send the generated test instructions to the test platform, and the test platform can receive the test instructions from the device where the code library is located.
[0082] Method 2: Test instructions are generated according to a set cycle.
[0083] The test platform can generate test instructions for the software to be tested according to the set cycle. The test platform can then obtain the test instructions it has generated.
[0084] To obtain the test tracking information, the test platform may send a request message to a storage device storing the test tracking information of the software to be tested based on the software identifier of the software to be tested, requesting the test tracking information for the software to be tested.
[0085] For obtaining the phase identification of the software to be tested, the testing platform can determine the phase identification of the software to be tested from the pre-stored phase identifications of various software. The testing platform can also display a prompt box on the display interface to prompt the tester to input the phase identification of the software to be tested or select the phase identification of the software to be tested.
[0086] Step S102, determining the stage of the software to be tested represented by the stage identifier. If it is determined that the software to be tested is in the development stage, step S103 is executed; if it is determined that the software to be tested is in the pre-launch testing stage, step S104 is executed.
[0087] The test platform can determine the stage of the software to be tested corresponding to the acquired stage identifier according to the acquired stage identifier and the pre-established correspondence between the stage identifier and the stage of the software to be tested.
[0088] Step S103: Generate first prompt information, and display the first prompt information on the display interface.
[0089] The first prompt information is used to prompt the tester to manually trigger the event indicated by the first event identifier on the first test device, and the first test device is: a device running the software development process version to be tested.
[0090] When the test platform determines that the software to be tested is in the development stage, the first prompt information can be generated by combining the device identification of the first test device and the text information generated by the first event identification. Specifically, the first prompt information can be generated in the form of "triggering the event indicated by the first event identification on the first test device indicated by the device identification". For example, the device identification of the first test device is "device b", and the first event identification is the event name "click the login button", then the test platform can combine "device b" and "click the login button" to generate the first prompt information "Please click the login button on device b".
[0091] The test platform may display the first prompt information in the form of a message pop-up box on the display interface of the test platform.
[0092] After the tester sees the first prompt information displayed on the display interface of the test platform, he can perform corresponding operations on the first test device according to the first prompt information to manually trigger the event indicated by the first event identifier. The event can trigger the test tracking point in the development process version of the software to be tested running in the first test device to collect data, and then the first test device can upload the collected data collected by the test tracking point.
[0093] Step S104: obtaining an event triggering script of the event represented by the first event identifier, running a pre-launch test version of the software to be tested on the second test device, and instructing the second test device to run the event triggering script.
[0094] When the testing platform determines that the software to be tested is in the pre-online testing stage, it can send a request message to a storage device storing an event trigger script according to the first event identifier, requesting an event trigger script for the event represented by the first event identifier.
[0095] The second test device is installed with a pre-launch test version of the software to be tested. The test platform can send a running instruction and the acquired event trigger script to the second test device, instructing the second test device to run the pre-launch test version of the software to be tested and run the event trigger script.
[0096] After receiving the running instructions and event triggering script sent by the test platform, the second test device can run the pre-launch test version of the software to be tested according to the running instructions and run the event triggering script. The event triggered by the event triggering script can further trigger the test tracking points in the pre-launch test version of the software to be tested running in the second test device to collect data, and then the second test device can upload the collected data collected by the test tracking points.
[0097] Step S105, obtaining the collected data collected by the test embedding point uploaded by the test device and the second event identifier of the event that triggers the test embedding point to perform data collection.
[0098] The test device is the first test device or the second test device. Specifically, when the event is triggered according to step S103, the test device is the first test device; when the event is triggered according to step S104, the test device is the second test device.
[0099] After triggering the event according to step S103 or step S104, the triggering of these events can further trigger the test points in the software to be tested run by the test device to perform data collection. The test device can upload the collected data and the second event identifier of the event that triggers the test point to perform data collection to the test platform, and then the test platform can obtain the collection data and the second event identifier uploaded by the test device.
[0100] In a possible implementation, in order to facilitate the management of the tracking point test service and enhance the real-time, accuracy and completeness of the collected data, the test platform can obtain the collected data and the second event identifier uploaded by the test device from the tracking point service center. The tracking point service center is a server that manages the collected data uploaded by the test device.
[0101] In this case, after the test platform triggers an event according to step S103 or step S104, it can wait for a preset time, and after the test point completes data collection and upload, it can send a data acquisition request to the point service center one by one according to each first event identifier, and obtain the collected data collected by the test point triggered by the event indicated by each first event identifier. In this way, the collected data collected by the test point service center is uniformly managed, which can ensure the real-time, accuracy, and completeness of the acquired collected data, and improve the coverage of the point test.
[0102] The tracking point service center can search for an identifier that matches the first event identifier in the second event identifier uploaded by the test device, and return the matching identifier found and the collected data triggered by the event corresponding to the matching identifier to the test platform. The test platform can then obtain the collected data and the second event identifier returned by the tracking point service center.
[0103] Step S106, searching the first event identifier for a matching identifier of the second event identifier, detecting whether the acquired collected data matches the first field attribute corresponding to the found matching identifier, and generating a test result based on the detection result.
[0104] The test platform can match the second event identifier with the first event identifier to determine the matching identifier in the first event identifier that matches the second event identifier. Then the test platform can match the field attributes of the acquired data corresponding to the second event identifier with the first field attributes corresponding to the found matching identifier to determine whether the two match. For example, determine whether the field attributes of the acquired data corresponding to the second event identifier are consistent with the first field attributes, whether they are missing, etc.
[0105] After obtaining the test results, the test platform can combine the test results to generate test results including the above test results, error information, and suggested improvement measures and other prompt information. For example, in the case of missing field attributes, the test platform can list the prompt information of the incomplete software code corresponding to the location of the field attribute in the test results, and then the developer can supplement the software code according to the prompt information.
[0106] The software testing method provided by the embodiment of the present application performs manually triggered tracking point testing on the development process version of the software to be tested during the development stage, so as to promote the front-end of the test node, timely discover the problems of the software to be tested during the development stage, and then make timely adjustments, thereby reducing the problems existing in the software to be tested before going online. The software to be tested is further tested in the pre-online test stage to ensure the accuracy of the software functions. In this way, when the software to be tested is subjected to automated tracking point testing in the pre-online test stage, the number of tracking points and the number of tests will also be reduced. However, the automated tracking point testing is more complicated and takes longer time than the manually triggered tracking point testing process because it requires the construction of a test environment. Reducing the number of tracking points and the number of tests in the automated tracking point testing can reduce the cost of automated tracking point testing on the one hand, and greatly shorten the time required for automated tracking point testing on the other hand, which greatly shortens the time required for the entire software testing process, thereby improving the software testing efficiency and reducing the risk of delayed release of the software to be tested.
[0107] The above step S102 or step S103 is a dynamic black box test process triggered by an event on the software to be tested. Before the dynamic test, the test platform can also first perform a white box test on the software to be tested, analyze the code, and detect whether the output port of the software code at the location of the tracking point exists, so as to more comprehensively ensure the accuracy of the test tracking point. In view of this situation, the embodiment of the present application also provides a software testing method, such as Figure 2 As shown, the method includes the following steps S201-S208.
[0108] Step S201, in response to obtaining the test instruction, obtain the test tracking information for the software to be tested and the stage identifier of the stage of the software to be tested, which is the same as the above step S101.
[0109] Step S202, parse the tracking configuration document of the test version of the software to be tested, and obtain the second field attribute of the data to be collected of the tracking recorded in the tracking configuration document.
[0110] The tracking configuration document includes: comments recorded in the implementation code of the test version and / or the parameter configuration file of the test version. The parameter configuration file can be a JSON (lightweight data exchange format) file, an INI (simple text configuration file format) file, or an XML (Extensible Markup Language) file.
[0111] When the stage identifier indicates that the software to be tested is in the development stage, the test version is the development process version of the software to be tested; when the stage identifier indicates that the software to be tested is in the pre-launch test stage, the test version is the pre-launch test version of the software to be tested. The test platform can obtain the implementation code and / or parameter configuration file of the test version of the software to be tested.
[0112] The test platform can extract the comments recorded in the implementation code of the test version, so as to determine the field attributes of the data to be collected of the tracking point recorded in the comments as the second field attribute.
[0113] The test platform may also parse the parameter configuration file of the test version to determine the field attribute of the data to be collected of the tracking point recorded in the annotation as the second field attribute.
[0114] Step S203, for each test embedding point, determine the matching embedding point of the test embedding point in the embedding points recorded in the embedding point configuration document, and detect whether the first field attribute corresponding to the test embedding point is recorded in the second field attribute corresponding to the determined matching embedding point.
[0115] For each test tracking point, the test platform can match the first field attribute corresponding to the test tracking point with the second field attribute corresponding to the determined matching tracking point one by one, and detect whether the first field attribute is recorded in the second field attribute.
[0116] Step S204: If the first field attributes corresponding to each test tracking point are all recorded in the second field attributes corresponding to the matching tracking points of each test tracking point, the stage of the software to be tested represented by the stage identifier is determined. If it is determined that the software to be tested is in the development stage, step S205 is executed; if it is determined that the software to be tested is in the pre-launch test stage, step S206 is executed.
[0117] If the first field attributes corresponding to each test tracking point are all recorded in the second field attributes corresponding to the matching tracking points of each test tracking point, it means that there is an output port in the software code of the test version for the data that needs to be collected for each test tracking point in the test tracking point information. The test platform can determine the stage of the software to be tested represented by the stage identifier, and further execute step S205 or step S206 to perform dynamic black box testing on the software to be tested, that is, use the test tracking points to collect the data output by the software to be tested, and detect whether the field attributes of the data output by the software to be tested meet the requirements, that is, whether the functions of the software to be tested are complete.
[0118] Step S205, generating first prompt information, and displaying the first prompt information on the display interface, which is the same as the above step S103.
[0119] Step S206, obtaining an event triggering script for the event represented by the first event identifier, running the pre-launch test version of the software to be tested on the second test device, and instructing the second test device to run the event triggering script, which is the same as the above step S104.
[0120] Step S207, obtaining the collected data collected by the test embedding point uploaded by the test device and the second event identifier of the event that triggers the test embedding point to collect data, which is the same as the above step S105.
[0121] Step S208, searching for a matching identifier of the second event identifier in the first event identifier, detecting whether the acquired collected data matches the first field attribute corresponding to the found matching identifier, and generating a test result based on the detection result, which is the same as the above step S106.
[0122] The above-mentioned step of detecting the tracking configuration document of the test version of the software to be tested can be performed by the tracking test tool integrated on the test platform. The tracking scanning test tool can assist in verifying whether the test tracking in the software to be tested is set as expected. By analyzing the test tracking information and the tracking configuration document, it can detect and verify the setting of the test tracking in the software to be tested, thereby ensuring the accuracy and completeness of the test tracking data collected.
[0123] Since the detection process of the tracking configuration document in the above steps S202-S204 is low in cost and time, it can be integrated into each node in the software development process. For example, the detection process can be integrated into the process of developers submitting code to CI each time, or the detection process can be integrated into the software code packaging process of devops (interaction between developers and operation and maintenance personnel), or the detection process can be executed regularly. The above static detection of the tracking configuration document can further promote the advance of test nodes, so that problems can be discovered and solved as early as possible, which further reduces the risk of delayed release of the software to be tested.
[0124] Apply the above Figure 2 According to the method shown, before the dynamic test triggered by an event, the test platform first detects the tracking configuration document of the test version of the software to be tested to determine whether there is an output port for the data required to be collected for each test tracking point in the test tracking information in the software code of the test version; and then, if there is an output port for the data required to be collected for each test tracking point in the software code of the test version, the software to be tested is dynamically tested, thereby avoiding the situation where the test tracking point cannot collect data when the output port of the software code of the test version is not completed, thereby reducing the waste of computing resources.
[0125] In addition, in a possible implementation, after parsing the second field attribute of the data to be collected recorded in the tracking configuration document, the test platform can first perform compliance detection on the parsed second field attribute to determine whether the data collected by the test tracking in the software to be tested contains non-compliant collected data in the field where the software to be tested is applied. Figure 3 As shown, in this case, the embodiment of the present application also provides a software testing method, which includes the following steps S301-S310.
[0126] Step S301, in response to obtaining the test instruction, obtains the test tracking information for the software to be tested and the stage identifier of the stage of the software to be tested, which is the same as the above-mentioned step S101 and step S201.
[0127] Step S302, parsing the tracking configuration document of the test version of the software to be tested, and obtaining the second field attribute of the data to be collected of the tracking recorded in the tracking configuration document, which is the same as the above step S202.
[0128] Step S303, match the second field attribute with the preset sensitive field attribute to determine whether the second field attribute contains a sensitive field attribute. If the second field attribute contains a sensitive field attribute, execute step S304; if the second field attribute contains no sensitive field attribute, execute step S305.
[0129] The test platform may store pre-set sensitive field attributes. Sensitive field attributes are field attributes of non-compliant collected data in the field where the software to be tested is applied. They may be pre-set according to the field where the software to be tested is applied. The fields where the software to be tested is applied may include finance, shopping, education, sports, etc., which are only examples here and do not have a limiting effect.
[0130] For example, if the software to be tested is used in the financial field, the sensitive field attributes of the software to be tested can be derived from the product compliance rules in the financial field. In this way, for software products in the financial field, introducing a financial compliance check mechanism for the data collected by the tracking points in the software during the testing phase can effectively reduce the potential risks and uncertainties of the tracking points in the software in terms of financial compliance, improve the security of the software products, and provide guarantees for subsequent software operations.
[0131] The test platform can match the parsed second field attributes with the preset sensitive field attributes. If any field attribute in the second field attributes matches any field attribute in the sensitive field attributes, the test platform can determine that the sensitive field attributes exist in the second field attributes; if any field attribute in the second field attributes does not match any field attribute in the sensitive field attributes, the test platform can determine that the sensitive field attributes do not exist in the second field attributes.
[0132] In one example, the test platform can also first copy the parsed second field attribute to a specified path where a sensitive field attribute detection tool is deployed, and configure a detection event in the sensitive field attribute detection tool of the specified path, and then run the sensitive field attribute detection tool to trigger a detection event to detect whether there is a sensitive field attribute in the second field attribute. After obtaining the detection result, the test platform can display the detection result on the display interface of the test platform.
[0133] If there are sensitive field attributes in the second field attributes, the test platform can execute step S304 to prompt the tester so that the tester can adjust the test points of the collected data including sensitive field attributes; if there are no sensitive field attributes in the second field attributes, the test platform can execute step S305 and continue to execute the subsequent software testing process.
[0134] Step S304: Generate second prompt information based on the sensitive field attributes in the second field attributes, and display the second prompt information on the display interface.
[0135] The second prompt information is used to prompt the tester that there are sensitive field attributes in the second field attributes.
[0136] If there are sensitive field attributes in the second field attributes, the test platform can generate a second prompt information based on the sensitive field attributes in the second field attributes determined in the above matching process. Specifically, the second prompt information can be generated in the form of "the field attributes of the data collected by the test tracking point in the software to be tested contain the following sensitive field attributes: ..."
[0137] The test platform may display the second prompt information in the form of a message pop-up box on the display interface of the test platform.
[0138] After seeing the second prompt information displayed on the display interface of the test platform, the tester can adjust the test points in the test version of the software to be tested, such as deleting or modifying the test points whose collected data have sensitive field attributes.
[0139] Step S305, for each test embedding point, determine the matching embedding point of the test embedding point in the embedding points recorded in the embedding point configuration document, and detect whether the first field attribute corresponding to the test embedding point is recorded in the second field attribute corresponding to the determined matching embedding point, which is the same as the above step S203.
[0140] If there is no sensitive field attribute in the second field attribute, it means that the data collected by the test tracking points in the test version of the software to be tested are all compliant collected data within the field where the software to be tested is applied. The test platform can continue to execute subsequent steps. For each test tracking point, the matching tracking point of the test tracking point is determined in the tracking points recorded in the tracking point configuration document, and the first field attribute corresponding to the test tracking point is detected whether it is recorded in the second field attribute corresponding to the determined matching tracking point.
[0141] Step S306: If the first field attributes corresponding to each test tracking point are all recorded in the second field attributes corresponding to the matching tracking points of each test tracking point, the stage of the software to be tested represented by the stage identifier is determined. If it is determined that the software to be tested is in the development stage, step S307 is executed; if it is determined that the software to be tested is in the pre-launch testing stage, step S308 is executed. The same as the above step S204.
[0142] Step S307, generating first prompt information, and displaying the first prompt information on the display interface, which is the same as the above-mentioned step S103 and step S205.
[0143] Step S308, obtaining an event triggering script for the event represented by the first event identifier, running the pre-launch test version of the software to be tested on the second test device, and instructing the second test device to run the event triggering script, which is the same as the above steps S104 and S206.
[0144] Step S309, obtaining the collected data collected by the test embedding point uploaded by the test device and the second event identifier of the event that triggers the test embedding point to collect data, which is the same as the above-mentioned step S105 and step S207.
[0145] Step S310, searching for a matching identifier of the second event identifier in the first event identifier, detecting whether the acquired collected data matches the first field attribute corresponding to the found matching identifier, and generating a test result based on the detection result, which is the same as the above steps S106 and S208.
[0146] Using the above Figure 3 According to the method shown, after parsing the second field attribute of the data to be collected from the tracking point recorded in the tracking point configuration document, the test platform first performs a compliance check on the second field attribute in the tracking point configuration file to determine whether there is non-compliant data collected by the test tracking point in the software to be tested. Then, if the data collected by the test tracking point is compliant, subsequent tracking point testing can be performed to avoid the risks and uncertainties brought about by non-compliant data collected by the test tracking point.
[0147] In a possible implementation manner, the event triggering script of the event represented by the first event identifier used in the above step S104 can be as follows: Figure 4 The method shown in the figure may include the following steps S401-S402. For the convenience of explanation, the execution subject of the generation method is called a generation device. The generation device and the first test device may be the same device or different devices.
[0148] Step S401 : capturing operations performed by a first testing device when a tester manually triggers an event indicated by a first event identifier.
[0149] The operations performed by the first test device include operations performed by various components in the first test device.
[0150] If the generating device and the first testing device are the same device, the generating device can directly capture the operations performed by the components in the first testing device during the process in which the tester manually triggers the event indicated by the first event identifier.
[0151] If the generating device and the first testing device are different devices, the generating device may also request the first testing device to capture operations performed by components in the first testing device during a process in which the tester manually triggers the event indicated by the first event identifier.
[0152] Step S402: Generate an event triggering script for the event represented by the first event identifier based on the captured operation.
[0153] The generating device may generate an event triggering script based on the captured operations performed by each component in the first test device.
[0154] In this way, an event trigger script is generated based on the operations performed by the first test device captured during the manual triggering of the tracking test by the tester, and used for subsequent automated tracking tests. On the one hand, it can reduce the workload of the tester in manually triggering events, and on the other hand, it can speed up the generation of event trigger scripts, further shortening the time required for automated tracking tests, and thus further shortening the time required for the entire software testing process, thereby further improving software testing efficiency and further reducing the risk of delayed release of the software to be tested.
[0155] In a possible implementation manner, the test point information in the above step S101 can also be obtained by Figure 5 The acquisition method is shown, and the acquisition method includes the following steps S501-S502.
[0156] Step S501, obtaining a tracking requirement document for the software to be tested.
[0157] The tracking point requirement document can be a table document, a text document, etc. The tracking point requirement document describes in detail the triggering events corresponding to the test tracking points that need to be embedded in the software to be tested, as well as the data to be collected by the test tracking points. Specifically, the tracking point requirement document may include the first event identifier of the triggering event corresponding to the test tracking point, that is, the first event identifier of the event that triggers the test tracking point to collect data. The tracking point requirement document may also include the first field attribute of the data to be collected that the test tracking point needs to collect.
[0158] The tracking requirement document can be provided by the tester or developer and stored on a designated storage device. The test platform can send a request message to the designated storage device storing the tracking requirement document to request the latest version of the tracking requirement document for the software to be tested.
[0159] Step S502: locate the first storage area for recording the test burying point information in the burying point requirement document according to the background color of the field recorded in the burying point requirement document, determine the first event identifier of the event that triggers the test burying point for data collection and the first field attribute of the data to be collected from the first storage area, and / or search the burying point information field in the burying point requirement document, locate the second storage area for recording the test burying point information based on the burying point information field, and determine the first event identifier of the event that triggers the test burying point for data collection and the first field attribute of the data to be collected from the second storage area.
[0160] The fields in the tracking requirement document that record the test tracking information can be set with a specified background color. For example, the fields that record the test tracking information are set to a red background color, and other contents are set to the default white background color.
[0161] The test platform can first determine the location of the field with the specified background color according to the background color of the field recorded in the tracking requirement document, and then locate the first storage area for recording the test tracking information in the tracking requirement document. For example, in the tracking requirement document, the test platform can first determine that the field with a red background color in the tracking requirement document is the first storage area for the test tracking information.
[0162] Furthermore, the test platform can determine the first event identifier of the event that triggers the test point to collect data and the first field attribute of the data to be collected from the first storage area based on the field attributes of each field in the first storage area.
[0163] For example, the tracking point requirement document is a table, the header of each column in the table is the first event identifier, and the field below the header of each column is the first field attribute of the data to be collected when the event indicated by the first event identifier is triggered. After determining that the first storage area is the 2nd to 5th columns, the test platform can determine that the content in the header of the 2nd to 5th columns is the first event identifier, and the content in the field below the header is the first field attribute of the data to be collected.
[0164] The fields in the tracking requirement document that record the test tracking information can also be marked as tracking information fields. For example, the fields that record the test tracking information are marked separately in the specified area, and each field that records the test tracking information has a tracking information field mark.
[0165] The test platform can locate the second storage area for recording the test embedding information based on whether each field has a embedding information field mark, and then determine the first event identifier of the event that triggers the test embedding for data collection and the first field attribute of the data to be collected from the second storage area according to the field attributes.
[0166] In addition to the above-mentioned background color and tracking information field marks, testers or developers can also use other special marks to mark the tracking information fields in the tracking requirement document, which is not limited here.
[0167] In this way, the test platform can determine the test point information faster and more accurately.
[0168] In order to more clearly illustrate the above software testing method, the present application embodiment also provides the following Figure 6 A flowchart of a complete example is shown in Figure .
[0169] Figure 6 In the paper, the entire software testing process is divided into static scanning process and dynamic scanning process.
[0170] For the static scanning process, the embedded point scanning test tool integrated on the test platform first reads the embedded point requirement document to obtain the event field description, that is, the first event identifier and the first field attribute in the test embedded point information, such as the above step S201.
[0171] The test platform then parses the second field attribute of the data to be collected from the project configuration manager, i.e., the storage device, which stores the tracking configuration document of the test version of the software to be tested, as shown in the above step S202.
[0172] Then, the static result checker in the test platform detects whether the first field attribute corresponding to each test point is recorded in the corresponding second field attribute, such as step S203 above.
[0173] The static result checker can also generate test results and output test reports based on the detection results.
[0174] For the dynamic scanning process, the tracking point scanning test tool integrated on the test platform first reads the tracking point requirement document to obtain the event field description, that is, the first event identifier and the first field attribute in the test tracking point information; the test platform can also obtain the time range of the software, that is, the stage identifier, from the project configuration manager that stores the tracking point configuration document, such as step S101 or step S201 above.
[0175] The testing platform can also obtain the device identification of the test device on which the software to be tested is deployed from the project configuration manager, and then prompt the tester to manually trigger a tracking event on the test device, or instruct the test device to run an event trigger script (not shown in the figure), such as steps S103 and S104, or steps S205 and S206 mentioned above.
[0176] After the test device triggers a point-of-care event and then triggers the point-of-care data collection, the test device uploads the collected data to the point-of-care data collection server, i.e., the point-of-care service center. The server data assistant in the test platform can request the point-of-care data collection server to upload the collected data and the second event identifier of the test device within a specified time range; the point-of-care data collection server returns the collected data, the second event identifier, the device identifier, and the time range to the server data assistant, as described in step S105 above. The server data assistant then sends the collected event field descriptions, collected data, second event identifier, and other information to the dynamic result checker.
[0177] Then, the dynamic result checker in the test platform searches for the matching identifier of the second event identifier in the first event identifier, detects whether the acquired collected data matches the first field attribute corresponding to the found matching identifier, and generates a test result based on the detection result, and then generates and outputs a more detailed test report including the detection results of each buried point, error information and suggested improvement measures, as shown in the above step S106.
[0178] In addition, the dynamic result checker can also organize the acquired second event identifier, collected data, device identifier, time range and other detailed information and output the embedded event detail file so that testers can quickly locate and solve problems.
[0179] By applying the technical solution provided in the embodiment of the present application, the manually triggered and automatically triggered dynamic tracking point testing methods are integrated, and the manually triggered tracking point testing can be performed in the development stage before the automation script is output by the test team, rather than only in the final acceptance stage of the software product. This promotes the node advancement of software testing, so that problems in the software are exposed earlier, so that problems can be solved as early as possible, speeding up software testing efficiency, and avoiding delays in software release progress due to failure to discover problems in time. In addition, in the embodiment of the present application, the above-mentioned dynamic tracking point testing process is combined with static testing, and the tracking point configuration document is first white-box tested before running the software to be tested to ensure that data can be collected at the tracking point location.
[0180] In the above scheme, a manually triggered test method is used in the testing phase to provide instant feedback on problems in the software during the development process. Before going online, that is, in the final acceptance phase, an automatically triggered test method is used to ensure that the functions of the software to be tested can be correctly implemented, so as to detect problems missed in the development phase and improve the quality of the software product after going online. The use of manual and automatic switching test methods can meet the testing requirements of different stages in the software development process, and while ensuring the efficiency of software testing, it also takes into account the accuracy of software testing.
[0181] In addition, the above software testing method does not limit the systems used by the test equipment, test platform and other equipment used in the above test process, and has high universality. Moreover, most of the above test processes are based on equipment automation. Testers only need to perform the operations prompted by the test platform when receiving prompt information to obtain the test report output by the test platform and the detailed files of buried event, which greatly reduces the complexity and time cost of manual operation.
[0182] Testers can also adjust the tracking requirement documents. The test platform obtains the requirement documents updated by testers to perform tracking tests to meet the different testing requirements of testers.
[0183] In addition, components such as the tracking test scanning tool in the above-mentioned test platform can be integrated with other test tools or platforms, and have good scalability to adapt to the ever-changing tracking requirements.
[0184] The software testing method provided by the above embodiment can more comprehensively detect possible problems in the software to be tested, thereby providing reliable support for testers to analyze the data obtained from the test and for developers to optimize the software products to be tested. Testers can perform software testing work more efficiently, and developers can also perform software development work more efficiently.
[0185] Corresponding to the above software testing method, the present application embodiment also provides a software testing device, such as Figure 7 As shown, the device is applied to a test platform and comprises:
[0186] The acquisition module 701 is used to obtain the test tracking information for the software to be tested and the stage identifier of the stage of the software to be tested in response to the acquisition of the test instruction, wherein the test tracking information includes: the first event identifier of the event that triggers the test tracking to collect data and the first field attribute of the data to be collected;
[0187] The prompt module 702 is used to generate a first prompt message if the stage identifier indicates that the software to be tested is in the development stage, and display the first prompt message on the display interface, wherein the first prompt message is used to prompt the tester to manually trigger the event indicated by the first event identifier on the first test device, and the first test device is: a device running a development process version of the software to be tested;
[0188] The first acquisition module 703 is used to obtain the event triggering script of the event represented by the first event identifier if the stage identifier represents that the software to be tested is in the pre-launch test stage, and run the pre-launch test version of the software to be tested on the second test device, and instruct the second test device to run the event triggering script;
[0189] The second acquisition module 704 is used to acquire the collected data collected by the test tracking point uploaded by the test device and the second event identifier of the event that triggers the test tracking point to collect data, wherein the test device is the first test device or the second test device;
[0190] The detection module 705 is used to search for a matching identifier of the second event identifier in the first event identifier, detect whether the acquired collected data matches the first field attribute corresponding to the found matching identifier, and generate a test result based on the detection result.
[0191] The software testing method provided by the embodiment of the present application performs manually triggered tracking point testing on the development process version of the software to be tested during the development stage, so as to promote the front-end of the test node, timely discover the problems of the software to be tested during the development stage, and then make timely adjustments, thereby reducing the problems existing in the software to be tested before going online. The software to be tested is further tested in the pre-online test stage to ensure the accuracy of the software functions. In this way, when the software to be tested is subjected to automated tracking point testing in the pre-online test stage, the number of tracking points and the number of tests will also be reduced. However, the automated tracking point testing is more complicated and takes longer time than the manually triggered tracking point testing process because it requires the construction of a test environment. Reducing the number of tracking points and the number of tests in the automated tracking point testing can reduce the cost of automated tracking point testing on the one hand, and greatly shorten the time required for automated tracking point testing on the other hand, which greatly shortens the time required for the entire software testing process, thereby improving the software testing efficiency and reducing the risk of delayed release of the software to be tested.
[0192] In a possible implementation manner, the software testing device may further include:
[0193] A parsing module is used to parse the test tracking configuration document of the test version of the software to be tested after obtaining the test tracking information for the software to be tested and the stage identifier of the stage in which the software to be tested is located, and obtain the second field attribute of the data to be collected recorded in the tracking configuration document;
[0194] The detection module 705 may also be used to determine, for each test buried point, a matching buried point of the test buried point in the buried points recorded in the buried point configuration document, and detect whether the first field attribute corresponding to the test buried point is recorded in the second field attribute corresponding to the determined matching buried point;
[0195] The prompt module 702 may also be used to generate a first prompt message if the first field attributes corresponding to each test tracking point are all recorded in the second field attributes corresponding to the matching tracking points of each test tracking point, and the stage identifier indicates that the software to be tested is in the development stage;
[0196] The first acquisition module 703 can also be used to obtain the event trigger script of the event represented by the first event identifier if the first field attributes corresponding to each test embedding point are recorded in the second field attributes corresponding to the matching embedding points of each test embedding point, and the stage identifier indicates that the software to be tested is in the pre-online testing stage.
[0197] In a possible implementation manner, the detection module 705 may also be used to parse the tracking configuration document of the test version of the software to be tested, obtain the second field attribute of the data to be collected of the tracking recorded in the tracking configuration document, match the second field attribute with the preset sensitive field attribute, and determine whether there is a sensitive field attribute in the second field attribute;
[0198] The prompt module 702 may also be used to generate second prompt information based on the sensitive field attributes in the second field attributes if there are sensitive field attributes in the second field attributes, and display the second prompt information on the display interface, wherein the second prompt information is used to prompt the tester that there are sensitive field attributes in the second field attributes;
[0199] The above-mentioned detection module 705 can also be used to determine the matching buried point of the test buried point in the buried points recorded in the buried point configuration document for each test buried point if there is no sensitive field attribute in the second field attribute, and detect whether the first field attribute corresponding to the test buried point is recorded in the second field attribute corresponding to the determined matching buried point.
[0200] In a possible implementation, the tracking configuration document may include: comments recorded in the implementation code of the test version and / or a parameter configuration file of the test version.
[0201] In a possible implementation manner, the event triggering script of the event represented by the first event identifier may be generated in the following manner:
[0202] Capturing the operation performed by the first test device during the process in which the tester manually triggers the event indicated by the first event identifier;
[0203] Based on the captured operation, an event triggering script of the event represented by the first event identifier is generated.
[0204] In a possible implementation, the test tracking information can be obtained in the following way:
[0205] Obtain the tracking requirement document for the software to be tested;
[0206] According to the background color of the field recorded in the embedding point requirement document, locate the first storage area for recording the test embedding point information in the embedding point requirement document, determine the first event identifier of the event that triggers the test embedding point for data collection and the first field attribute of the data to be collected from the first storage area, and / or search the embedding point information field in the embedding point requirement document, locate the second storage area for recording the test embedding point information based on the embedding point information field, and determine the first event identifier of the event that triggers the test embedding point for data collection and the first field attribute of the data to be collected from the second storage area.
[0207] In a possible implementation manner, the test instruction may be generated by triggering a software code update operation of the software to be tested; or
[0208] Test instructions can be generated according to a set period.
[0209] The present application also provides an electronic device, which is equipped with the above-mentioned test platform, such as Figure 8 As shown, the electronic device includes a processor 801 , a communication interface 802 , a memory 803 and a communication bus 804 , wherein the processor 801 , the communication interface 802 , and the memory 803 communicate with each other via the communication bus 804 .
[0210] Memory 803, used for storing computer programs;
[0211] The processor 801 is used to implement the steps of any of the above-mentioned software testing methods when executing the program stored in the memory 803.
[0212] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.
[0213] The communication interface is used for communication between the above electronic device and other devices.
[0214] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.
[0215] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.
[0216] In another embodiment provided in the present application, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned software testing methods are implemented.
[0217] In another embodiment provided by the present application, a computer program product including instructions is also provided, which, when executed on a computer, enables the computer to execute any software testing method in the above embodiments.
[0218] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive Solid State Disk (SSD)), etc.
[0219] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.
[0220] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, electronic device, and storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.
[0221] The above description is only a preferred embodiment of the present application and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application are included in the protection scope of the present application.
Claims
1. A software testing method, characterized in that: Applied to a test platform, the method comprises: In response to obtaining the test instruction, obtaining the test tracking point information for the software to be tested and the stage identifier of the stage in which the software to be tested is located, wherein the test tracking point information includes: a first event identifier of an event that triggers the test tracking point to collect data and a first field attribute of the data to be collected; If the stage identifier indicates that the software to be tested is in the development stage, a first prompt message is generated and displayed on a display interface, wherein the first prompt message is used to prompt a tester to manually trigger an event indicated by the first event identifier on a first test device, wherein the first test device is: a device running a development process version of the software to be tested; If the stage identifier indicates that the software to be tested is in the pre-launch test stage, then obtaining an event triggering script of the event indicated by the first event identifier, running the pre-launch test version of the software to be tested on the second test device, and instructing the second test device to run the event triggering script; Acquire the collected data collected by the test embedding point uploaded by the test device and the second event identifier of the event that triggers the test embedding point to collect data, wherein the test device is the first test device or the second test device; The matching identifier of the second event identifier is searched in the first event identifier, and it is detected whether the acquired collected data matches the first field attribute corresponding to the found matching identifier, and a test result is generated based on the detection result.
2. The method according to claim 1, characterized in that After obtaining the test tracking point information for the software to be tested and the stage identifier of the stage in which the software to be tested is located, the method further includes: Parsing the tracking configuration document of the test version of the software to be tested, and obtaining the second field attribute of the data to be collected recorded in the tracking configuration document; For each test tracking point, determine the matching tracking point of the test tracking point in the tracking points recorded in the tracking point configuration document, and detect whether the first field attribute corresponding to the test tracking point is recorded in the second field attribute corresponding to the determined matching tracking point; If the first field attributes corresponding to each test tracking point are all recorded in the second field attributes corresponding to the matching tracking points of each test tracking point, then the step of generating a first prompt message if the stage identifier indicates that the software to be tested is in the development stage is executed, or the step of obtaining an event trigger script for the event represented by the first event identifier is executed if the stage identifier indicates that the software to be tested is in the pre-online testing stage.
3. The method according to claim 2, characterized in that After parsing the tracking configuration document of the test version of the software to be tested to obtain the second field attribute of the data to be collected recorded in the tracking configuration document, the method further includes: Matching the second field attribute with a preset sensitive field attribute to determine whether a sensitive field attribute exists in the second field attribute; If there is a sensitive field attribute in the second field attribute, generate second prompt information based on the sensitive field attribute in the second field attribute, and display the second prompt information on the display interface, wherein the second prompt information is used to prompt the tester that there is a sensitive field attribute in the second field attribute; If there is no sensitive field attribute in the second field attribute, execute the steps of determining the matching buried point of the test buried point among the buried points recorded in the buried point configuration document for each test buried point, and detecting whether the first field attribute corresponding to the test buried point is recorded in the second field attribute corresponding to the determined matching buried point.
4. The method according to claim 2 or 3, characterized in that: The tracking configuration document includes: comments recorded in the implementation code of the test version and / or a parameter configuration file of the test version.
5. The method according to claim 1, characterized in that The event triggering script of the event represented by the first event identifier is generated in the following manner: Capturing the operation performed by the first test device during the process in which the tester manually triggers the event indicated by the first event identifier; Based on the captured operation, an event triggering script of the event represented by the first event identifier is generated.
6. The method according to claim 1, characterized in that The test point information is obtained in the following way: Obtain the tracking requirement document for the software to be tested; According to the background color of the fields recorded in the embedding point requirement document, locate the first storage area for recording the test embedding point information in the embedding point requirement document, determine the first event identifier of the event that triggers the test embedding point to perform data collection and the first field attribute of the data to be collected from the first storage area, and / or search the embedding point information field in the embedding point requirement document, locate the second storage area for recording the test embedding point information based on the embedding point information field, and determine the first event identifier of the event that triggers the test embedding point to perform data collection and the first field attribute of the data to be collected from the second storage area.
7. The method according to any one of claims 1-3, 5-6, characterized in that: The test instruction is generated by triggering a software code update operation of the software to be tested; or The test instructions are generated according to a set period.
8. A software testing device, characterized in that: Applied to a test platform, the device comprises: An acquisition module is used to obtain test tracking information for the software to be tested and a stage identifier of the stage in which the software to be tested is located in response to obtaining a test instruction, wherein the test tracking information includes: a first event identifier of an event that triggers the test tracking to collect data and a first field attribute of the data to be collected; a prompt module, configured to generate a first prompt message if the stage identifier indicates that the software to be tested is in a development stage, and display the first prompt message on a display interface, wherein the first prompt message is used to prompt a tester to manually trigger an event indicated by the first event identifier on a first test device, wherein the first test device is a device running a development process version of the software to be tested; A first acquisition module is used for acquiring an event triggering script of the event represented by the first event identifier if the stage identifier represents that the software to be tested is in a pre-launch test stage, and running the pre-launch test version of the software to be tested on a second test device, and instructing the second test device to run the event triggering script; A second acquisition module, used to acquire the collected data collected by the test embedding point uploaded by the test device and a second event identifier of the event that triggers the test embedding point to collect data, wherein the test device is the first test device or the second test device; The detection module is used to search for a matching identifier of the second event identifier in the first event identifier, detect whether the acquired collected data matches a first field attribute corresponding to the found matching identifier, and generate a test result based on the detection result.
9. An electronic device, equipped with a test platform, characterized in that: The electronic device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; Memory, used to store computer programs; A processor, for implementing the steps of the method according to any one of claims 1 to 7 when executing a program stored in a memory.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.