Buried point test method, computing device, storage medium and program product

Abstract

The embodiment of the invention provides a buried point testing method, computing equipment, a computer readable storage medium and a computer program product. The buried point test method comprises the following steps: receiving a test task for a target buried point sent by a client; in response to the test task, determining a target application program corresponding to the target burying point; searching a target test script corresponding to the target application program in a first mapping relationship between the application program and the test script; sending the target test script to a target test terminal; acquiring burying point test data; generating a test result of the target burying point based on standard burying point data and the burying point test data; and sending the test result to the client. According to the technical scheme provided by the embodiment of the invention, the buried point testing efficiency can be improved.

Description

Technical Field

[0001] Embodiments of the present application relate to the field of testing technologies, and in particular, to a method for buried point testing, a computing device, a computer-readable storage medium, and a computer program product. Background Art

[0002] Buried point is a technology for collecting user behavior data by implanting code markers in an application program. Buried point testing is a key link for verifying the accuracy and integrity of buried point data.

[0003] In related technologies, buried point testing is mainly completed by manual operations. Testers usually need to write test scripts for the buried points to be tested, plan various test scenarios and steps to simulate the behaviors of real users. They also need to manually start the application program where the buried points to be tested are located, run the test scripts, and manually judge the accuracy and integrity of the buried point data by comparing the actually collected buried point data with the expected results.

[0004] The inventor found in the process of implementing the concept of the present application that this manual buried point testing method often has low testing efficiency. Summary of the Invention

[0005] Embodiments of the present application provide a method for buried point testing, a computing device, a computer-readable storage medium, and a computer program product.

[0006] In a first aspect, an embodiment of the present application provides a method for buried point testing, which is applied to a server, and the method includes:

[0007] Receiving a test task for a target buried point sent by a client;

[0008] In response to the test task, determining a target application program corresponding to the target buried point;

[0009] Looking up a target test script corresponding to the target application program in a first mapping relationship between the application program and the test script;

[0010] Sending the target test script to a target test terminal, so that the target test terminal uses the target test script to run the target application program to trigger the target buried point to generate buried point test data;

[0011] Obtaining the buried point test data;

[0012] Generating a test result of the target buried point based on standard buried point data and the buried point test data;

[0013] Sending the test result to the client.

[0014] Second aspect, an embedding point testing method is provided in an embodiment of the present application, which is applied to a client. The method includes:

[0015] Sending a test task for a target embedding point to a server, so that the server determines a target application corresponding to the target embedding point in response to the test task; looking up a target test script corresponding to the target application in a first mapping relationship between the application and the test script; sending the target test script to a target test terminal, so that the target test terminal runs the target application by using the target test script to trigger the target embedding point to generate embedding point test data; obtaining the embedding point test data; generating a test result of the target embedding point based on standard embedding point data and the embedding point test data;

[0016] Receiving the test result sent by the server.

[0017] Third aspect, an embedding point testing method is provided in an embodiment of the present application, which is applied to a test terminal. The method includes:

[0018] Obtaining a target test script sent by a server, where the target test script is determined from a first mapping relationship between an application and a test script after the server receives a test task for a target embedding point sent by a client and determines a target application corresponding to the target embedding point in response to the test task;

[0019] Running the target application by using the target test script to trigger the target embedding point to generate embedding point test data, so that the server obtains the embedding point test data, generates a test result of the target embedding point based on standard embedding point data and the embedding point test data, and sends the test result to the client.

[0020] Fourth aspect, an embedding point testing device is provided in an embodiment of the present application, which is applied to a server. The device includes:

[0021] A first receiving module, configured to receive a test task for a target embedding point sent by a client;

[0022] A first determining module, configured to determine a target application corresponding to the target embedding point in response to the test task;

[0023] A first inserting and looking-up module, configured to look up a target test script corresponding to the target application in a first mapping relationship between the application and the test script;

[0024] A first sending module, configured to send the target test script to a target test terminal, so that the target test terminal runs the target application by using the target test script to trigger the target embedding point to generate embedding point test data;

[0025] A first acquisition module, configured to acquire the buried point test data;

[0026] A first generation module, configured to generate a test result of the target buried point based on standard buried point data and the buried point test data;

[0027] A second sending module, configured to send the test result to the client.

[0028] In a fifth aspect, an embodiment of the present application provides a buried point test device, which is applied to a client, and the device includes:

[0029] A third sending module, configured to send a test task for a target buried point to a server, so that the server, in response to the test task, determines a target application corresponding to the target buried point; in a first mapping relationship between an application and a test script, look up a target test script corresponding to the target application; send the target test script to a target test terminal, so that the target test terminal runs the target application by using the target test script to trigger the target buried point to generate buried point test data; acquire the buried point test data; generate a test result of the target buried point based on standard buried point data and the buried point test data;

[0030] A second receiving module, configured to receive the test result sent by the server.

[0031] In a sixth aspect, an embodiment of the present application provides a buried point test device, which is applied to a test terminal, and the device includes:

[0032] A first acquisition module, configured to acquire a target test script sent by a server, where the target test script is determined from a first mapping relationship between an application and a test script after the server receives a test task for a target buried point sent by a client and, in response to the test task, determines a target application corresponding to the target buried point;

[0033] A first running module, configured to run the target application by using the target test script to trigger the target buried point to generate buried point test data, so that the server acquires the buried point test data, generates a test result of the target buried point based on standard buried point data and the buried point test data, and sends the test result to the client.

[0034] In a seventh aspect, an embodiment of the present application provides a computing device, including a processing component and a storage component;

[0035] The storage component stores a computer program; the computer program is used to be called and executed by the processing component to implement the buried point test method provided by the embodiment of the present application.

[0036] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processing component, the method for buried point testing provided by the embodiment of the present application is implemented.

[0037] In a ninth aspect, an embodiment of the present application provides a computer program product, including a computer program or instruction. When the computer program or instruction is executed by a processing component, the method for buried point testing provided by the embodiment of the present application is implemented.

[0038] In the embodiment of the present application, by adopting: receiving a test task for a target buried point sent by a client; in response to the test task, determining a target application program corresponding to the target buried point; looking up a target test script corresponding to the target application program in a first mapping relationship between the application program and the test script; sending the target test script to a target test terminal so that the target test terminal runs the target application program by using the target test script to trigger the target buried point to generate buried point test data; obtaining the buried point test data; generating a test result of the target buried point based on standard buried point data and the buried point test data; and sending the test result to the client, an automated process from receiving the test task to generating the test result and feeding it back to the client is realized, reducing manual intervention and improving test efficiency.

[0039] These aspects or other aspects of the present application will be more clearly understood in the following description of the embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The drawings described herein are used to provide a further understanding of the present application and form a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation to the present application. In the drawings:

[0041] Figure 1 A system architecture diagram in which a technical solution of an embodiment of the present application can be applied is shown;

[0042] Figure 2 It is a flowchart of an embodiment of a method for buried point testing provided by the present application;

[0043] Figure 3 It is a flowchart of another embodiment of a method for buried point testing provided by the present application;

[0044] Figure 4 It is a flowchart of another embodiment of a method for buried point testing provided by the present application;

[0045] Figure 5 It is a schematic diagram of the method for buried point testing provided by the embodiment of the present application;

[0046] Figure 6 Block diagram of a point embedding test device provided by an embodiment of the present application;

[0047] Figure 7 Block diagram of a point embedding test device provided by another embodiment of the present application;

[0048] Figure 8 Block diagram of a point embedding test device provided by another embodiment of the present application;

[0049] Figure 9 Block diagram of a computing device provided by an embodiment of the present application. Detailed implementation manners

[0050] To make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below in conjunction with specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0051] It should be noted that in the case where the embodiments of the present application involve user information, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the embodiments of the present application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entrances are provided for the user to select authorization or rejection. In addition, various models (including but not limited to language models or large models) involved in the present application comply with relevant laws and standards.

[0052] In addition, it should be noted that in the case where the embodiments of the present application involve user interaction operations or trigger operations, the user interaction operations or trigger operations involved in the embodiments of the present application include but are not limited to: interaction operations in various ways such as touch operations, gesture operations, voice operations, head movement operations, eye movement operations, etc.; among them, touch operations include but are not limited to: click operations, double-click operations, long-press operations, swipe operations, pinch operations or mouse hover operations, etc. Swipe operations include but are not limited to: linear swipes, curved swipes, etc.

[0053] Point embedding is a technology for collecting user behavior data by implanting code markers in an application program. Point embedding testing is a key link for verifying the accuracy and integrity of point embedding data.

[0054] In related technologies, buried point testing mainly relies on manual operations to complete. Testers usually need to write test scripts for the buried points to be tested, plan various test scenarios and steps to simulate the behaviors of real users. They also need to manually start the application where the buried point to be tested is located, run the test script, and manually judge the accuracy and integrity of the buried point data by comparing the actually collected buried point data with the expected results.

[0055] In the process of implementing the concept of this application, the inventor found that this manual buried point testing method often has low testing efficiency.

[0056] In view of the technical problem that the existing manual buried point testing method often has low testing efficiency, an embodiment of this application provides a solution. The basic idea is: receiving a test task for a target buried point sent by a client; in response to the test task, determining the target application corresponding to the target buried point; in the first mapping relationship between the application and the test script, looking up the target test script corresponding to the target application; sending the target test script to a target test terminal so that the target test terminal uses the target test script to run the target application to trigger the target buried point to generate buried point test data; obtaining the buried point test data; generating a test result for the target buried point based on the standard buried point data and the buried point test data; and sending the test result to the client. Through the above technical solution, an automated process from receiving the test task to generating the test result and feeding it back to the client is realized, reducing manual intervention and improving the testing efficiency.

[0057] Next, the technical solutions in the embodiments of this application will be described clearly and completely with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of protection of this application.

[0058] Figure 1 A system architecture diagram in which the technical solution of an embodiment of this application can be applied is shown. The system architecture may include a client 101 and a server 102.

[0059] Among them, a connection can be established between the client 101 and the server 102 through a network. The network provides a medium for the communication link between the client 101 and the server 102. The network can include various connection types, such as wired, wireless or fiber optic cables, etc. The client 101 can interact with the server 102 through the network to receive or send messages, etc.

[0060] Among them, the client 101 can be a browser, an APP (Application), or a web application such as an H5 (HyperText Markup Language 5) application, or a light application (also known as a mini-program, a lightweight application) or a cloud application, etc. The client 101 can be deployed in an electronic device and needs to rely on the device or certain apps in the device to run, etc. The electronic device can, for example, have a display screen and support information browsing, etc., such as a personal mobile terminal such as a mobile phone, a tablet computer, a personal computer, a desktop computer, a smart speaker, a smart watch, etc. For the sake of easy understanding, Figure 1 in which the client is mainly represented by the image of the device. Various other types of applications can usually be configured in the electronic device, such as human-computer dialogue applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc. The electronic device can refer to a device used by a user and having functions such as computing, Internet access, and communication required by the user. For example, it can be a mobile phone, a tablet computer, a personal computer, a wearable device, etc. The electronic device usually can include at least one processing component and at least one storage component. The electronic device may also include basic configurations such as a network card chip, an IO (input / output) bus, and audio-video components. This application does not limit this. Optionally, according to the implementation form of the electronic device, some peripheral devices may also be included, such as a keyboard, a mouse, a stylus, a printer, etc. This application does not limit this.

[0061] The server 102 can include servers that provide various services, such as a server for background training that provides support for the models used on the client 101, or a server that processes the interaction information sent by the client, etc.

[0062] It should be noted that the server 102 can be implemented as a distributed server cluster composed of multiple servers, or can be implemented as a single server. The server can also be a server of a distributed system, or a server combined with a blockchain. The server can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, Content Delivery Network (CDN), and big data and artificial intelligence platforms, or an intelligent cloud computing server or an intelligent cloud host with artificial intelligence technology.

[0063] It should be noted that the data point testing method provided in the embodiments of the present application is generally executed by the server 102, and the corresponding data point testing device is generally set in the server 102. However, in other embodiments of the present application, the client 101 may also have a similar function to the server 102, so as to execute the data point testing method provided in the embodiments of the present application.

[0064] It should be understood that Figure 1 the numbers of the client and the server in

[0065] are merely illustrative. According to the implementation requirements, any number of clients and servers may be provided.

[0066] Figure 2 FIG. is a flowchart of an embodiment of a data point testing method provided by the present application. The technical solution of this embodiment can be applied to the server.

[0067] Figure 2 The data point testing method shown may include the following steps:

[0068] 201: Receive a test task for a target data point sent by the client.

[0069] 202: In response to the test task, determine the target application corresponding to the target data point.

[0070] When the client has a test requirement for a target data point, it may send a test task to the server.

[0071] After receiving the test task, the server may parse the task content of the test task, determine the target data point information included therein, and then determine the target application corresponding to the target data point. In a possible implementation manner, the server may obtain an associated database, and the associated database may store the data point information included in each application. Then the server may perform query matching based on the associated database to determine the target application corresponding to the target data point.

[0072] 203: In the first mapping relationship between the application and the test script, find the target test script corresponding to the target application.

[0073] The server may find the target test script according to the first mapping relationship between the target application and the test script. Among them, the first mapping relationship may be stored in the database of the server, for example, using a relational database, with the unique identifier (such as the application name) of the target application as the key, and the corresponding test script storage path or script content as the value. The server may quickly find the target test script corresponding to the target application by querying the database.

[0074] 204: Send the target test script to the target test terminal so that the target test terminal can use the target test script to run the target application to trigger the target data point to generate data point test data.

[0075] After determining the target test script, the server can send the target test script to the target test terminal. Among them, the target test terminal can be a device installed with a corresponding test environment, such as a mobile phone, computer, etc. with a specific operating system and test framework. After receiving the target test script, the target test terminal can use the test framework to run the target application. For example, if the target test terminal is a mobile phone, the test program on the mobile phone can start the target application, and then trigger the target data point during the running of the application according to the instructions in the target test script, so as to obtain the data point test data of the target data point.

[0076] 205: Obtain the data point test data.

[0077] 206: Generate the test result of the target data point based on the standard data point data and the data point test data.

[0078] In an embodiment of the present application, after the target test terminal uses the target test script to run the target application to trigger the target data point to generate data point test data, it can obtain the data point test data and send the data point test data back to the server. Thus, the server can obtain the data point test data sent by the target test terminal.

[0079] In another embodiment of the present application, after the server distributes the target test script to the target test terminal, it can detect the execution status of the target test script. When the server detects that the target test script has been executed, it can obtain the data point test data reported by the target data point from the data point collection system. Among them, the data point collection system can be used to store the data point data reported by the data points it manages.

[0080] After the server obtains the data point test data, it can compare and analyze the data point test data with the pre-set standard data point data. The standard data point data can be the data that the target data point should collect under ideal conditions, including the standard definitions in aspects such as data format, data content, and data range.

[0081] The server can write a special comparison algorithm to compare the standard data point data and the data point test data field by field and condition by condition, and generate the test result of the target data point according to the comparison result. For example, if the format of the data point test data is correct, the content is complete and conforms to the standard definition, the test result is determined to pass; on the contrary, if there are problems such as data missing, format error, or data value not conforming to the standard, the test result is determined to fail, and the specific error information is recorded.

[0082] 207: Send the test result to the client.

[0083] After generating the test result, the server can send the generated test result to the client.

[0084] After the client receives the test result, it can display the test result to the tester on the interface so that the tester can further analyze and optimize the target buried point according to the test result.

[0085] In the embodiment of the present application, by adopting: receiving a test task for a target buried point sent by a client; in response to the test task, determining a target application corresponding to the target buried point; in a first mapping relationship between an application and a test script, looking up a target test script corresponding to the target application; sending the target test script to a target test terminal so that the target test terminal runs the target application by using the target test script to trigger the target buried point and obtain buried point test data of the target buried point; receiving the buried point test data sent by the target test terminal; generating a test result of the target buried point based on standard buried point data and the buried point test data; and sending the test result to the client, an automated process from receiving the test task to generating the test result and feeding it back to the client is realized, manual intervention is reduced, and the test efficiency is improved.

[0086] For different applications and different versions of the same application, there are often different startup methods. Testers often need to manually configure the startup process according to each application and its corresponding version, which not only consumes a lot of time and energy but also is prone to errors. To further improve the efficiency of buried point testing, the method may further include:

[0087] Determine a target startup script corresponding to the target application.

[0088] The server can obtain the target startup script corresponding to the target application from the established script database. Among them, multiple application startup script resources can be stored in the script database. The startup scripts can be classified and associated for storage according to different applications, application versions, and client types. For example, for a social mobile application, the startup scripts corresponding to different versions of Android and iOS (iPhone Operating System, an operating system) are stored in the database respectively, and each script details the steps required to start the application.

[0089] In some embodiments, before sending the target test script to the target test terminal, the method may further include:

[0090] Send the target startup script to the target test terminal so that the target test terminal can run the target startup script to start the target application on the test terminal according to the startup process described in the target startup script.

[0091] After determining the target startup script corresponding to the target application, the server can send the target startup script to the target test terminal. During the process of sending the target startup script, to ensure the integrity and accuracy of the data, a transmission protocol such as the TCP (Transmission Control Protocol) protocol can be used. At the same time, the server can also monitor the sending process. If a transmission failure occurs, it will automatically perform a retransmission operation until the target startup script is successfully delivered to the target test terminal.

[0092] After receiving the target startup script, the target test terminal can use the test execution software installed on the target test terminal to be responsible for parsing and executing the target startup script. Taking an Android test terminal as an example, the test execution software may be a specialized tool customized based on the Android development framework, which has the ability to parse script instructions and interact with the Android system.

[0093] During the process of the test execution software gradually executing the startup operation according to the instructions in the target startup script, first, it can check whether the system environment of the test terminal meets the startup requirements of the target application according to the script instructions, such as checking whether the Android system version meets the minimum application requirements and whether the necessary dependent libraries have been installed. If the environment does not meet the requirements, the test execution software will automatically perform environment configuration operations according to the prompt information in the script, such as downloading and installing the required dependent libraries.

[0094] In some embodiments of the present application, the test execution software can load the resource files of the target application according to the script instructions of the target startup script, including the application's code files, picture resources, configuration files, etc. During the loading process, integrity verification of the resource files will be performed to ensure that the resource files are not damaged or lost. The test execution software can also configure the required permissions for the target application according to the permission setting instructions in the script, such as permissions to access the network, read the storage device, etc. After the configuration is completed, the test execution software can call the startup interface of the Android system to start the target application according to the parameters set in the script. During the startup process, the test execution software will monitor the startup status of the application in real time. If a startup exception occurs, such as the application crashing or the startup timing out, it will record the relevant error information and feedback this information to the server.

[0095] By determining the target startup script and then using the test terminal to execute the target startup script to start the target application, the automation of the target application startup process is realized, reducing the errors caused by manual intervention and improving the accuracy and efficiency of the buried point test.

[0096] As an example, the process of the target test terminal running the target startup script to start the target application can be as follows: The test terminal finds the corresponding application in the test terminal according to the name of the target application. For example, the application can be found through the application management system of the test terminal or the application search function of the automated test script.

[0097] After finding the application, the test terminal can check whether the application is the latest version. If it is not the latest version, the application update process will be automatically triggered, and the application will be updated through the application store or by simulating the user's operations in the application store. After the update is completed, the application will be automatically started for testing. After the application is started, it can wait for the application to fully start and enter the main interface, and then start the data tracking test operation.

[0098] In some embodiments, determining the target startup script corresponding to the target application can be specifically implemented as:

[0099] Obtain the application description information of the target application from the test task, where the application description information includes the application version and client type of the target application;

[0100] Find the target startup script corresponding to the target application from the second mapping relationship between the application description information and the startup script.

[0101] After the server receives the test task for the target data tracking sent by the client, the server can parse the test task to obtain the application description information.

[0102] The server can identify the information related to the target application included in the test task, so as to extract the application description information such as the application version and client type of the target application. For example, if the test task is for data tracking of a short video application, the server can extract the version number of the short video application as v3.5.0 and the client types as mini programs, mobile applications, web applications, etc. from the test task.

[0103] After determining the application description information, the server can search according to the extracted application description information in the second mapping relationship between the application description information and the startup script established in advance. The second mapping relationship can be stored in the database of the server and organized in a structured form. In this database, a detailed mapping table can be established for each application, and the mapping table records the corresponding relationships between different combinations of application versions and client types and the corresponding startup scripts. For example, for the above-mentioned short video application, in the mapping table of the database, for the web application of the mini program with version v3.5.0, a series of operation steps required to start the application can be recorded in detail.

[0104] In a possible implementation manner of the present application, when the server searches for the second mapping relationship, it can perform matching according to a specific algorithm. Taking the data in the database as an example, it is possible to first locate the corresponding application mapping table according to the application name, and then find the corresponding startup script record in the table through the exact matching of the application version and the client type.

[0105] In some embodiments, before sending the target test script to the target test terminal, the method may further include:

[0106] Determine at least one second test terminal in an idle state from multiple first test terminals;

[0107] Determine, from the at least one second test terminal, the test terminal installed with the target application as the target test terminal.

[0108] The server is usually connected to a large number of first test terminals, and these first test terminals can be devices such as mobile phones, tablets, and computers of different brands and models, and are installed with different operating systems and test environments.

[0109] The server can regularly send status query instructions to all connected first test terminals, and the status query instructions are transmitted to each first test terminal through the network. After receiving the instructions, the first test terminal can run the built-in status detection program to collect the running status information of the test terminal by using the status detection program, including CPU usage rate, memory occupancy rate, and whether other test tasks are running. Then, the first test terminal can feedback this status information to the server.

[0110] The server can screen out the second test terminals in an idle state according to the received status information. The criteria for determining that the test terminal is idle can be set, for example, that the CPU usage rate is lower than a certain threshold (such as 30%), the memory occupancy rate is lower than a specific ratio (such as 60%), and no other test tasks are running. For example, at a certain moment, the server receives the status feedback of 100 first test terminals. After screening, it is determined that 30 of the first test terminals are in an idle state. Therefore, these 30 first test terminals can be determined as the second test terminals.

[0111] Next, the server can further check which of these second test terminals have the application installed. This checking process can be achieved through an application management program pre-installed on each test terminal. The application management program reports the list of installed applications on the test terminal to the server regularly, and the server stores these lists in the database, so that the second test terminals with the target application installed can be determined as target test terminals by querying the database. Suppose among the above 30 second test terminals, it is found through querying the database that 10 second test terminals have the target application installed. At this time, the target test terminals can be randomly determined from these 10 second test terminals.

[0112] Thus, by combining the method of filtering based on the test terminal status and the precise matching of the startup script, the accuracy and efficiency of selecting the target test terminal are improved, and the problem of test failure caused by using inappropriate test terminals is avoided.

[0113] In some embodiments, the method may further include:

[0114] Providing a test script management page;

[0115] Receiving a script upload operation triggered by the test client based on the test script management page, where the script upload operation is used to upload a test script for a specific application;

[0116] Responding to the script upload operation, generating a first mapping relationship.

[0117] The server can, for example, build and provide a test script management page through a Web server. The script management page can be designed using front-end technologies such as HTML (HyperText Markup Language), CSS (Cascading Style Sheets), and JavaScript (a scripting language running in the browser), and has a simple and intuitive user interface for the convenience of testers to operate. The script management page can display a navigation bar, an upload area, and a prompt message area. Among them, the navigation bar can be used to guide testers to perform various operations, the upload area can be provided with an obvious "Upload Script" button and a file selection box, and the prompt message area can display the feedback information of the operation in real time, such as upload progress, error prompt, etc.

[0118] When testers need to upload test scripts for a specific application, they can open a browser and enter the URL (Uniform Resource Locator) of the test script management page in the address bar to enter the script management page. On the script management page, testers can first select the locally stored test script files in the file selection box. These test script files may be written by testers according to the functions and data point requirements of the application using professional test script writing tools such as Selenium (a tool for automated testing), Airtest (an open-source automated testing framework), etc., and are named according to certain naming specifications to identify their corresponding applications and test scenarios.

[0119] After selecting the file, the tester clicks the "Upload Script" button to trigger the script upload operation. At this time, the browser can send the selected test script file to the server in the form of an HTTP (HyperText Transfer Protocol) request. During the sending process, to ensure the integrity and accuracy of the data, the file can be processed in chunks and verification information such as the file's hash value can be added.

[0120] After receiving the test script file, the server can first verify the file. By comparing the hash value of the received file with the hash value calculated by the sending end, it is ensured that the file has not been damaged or lost during transmission. If the verification passes, the server can parse the test script file and extract the identification information about the application, such as the name and version number of the application. These identification information can be defined in the header comment part of the test script or through a specific configuration file.

[0121] Then, the server can store the test script in the specified storage location. The storage location can be organized according to the classification of the application. For example, a folder named after the application name can be created in the server's file system, and the test scripts corresponding to the application are stored in this folder, and the directory can be further subdivided according to the version number, test scenario, etc. for easy management and search.

[0122] After the storage is completed, the server can generate the first mapping relationship between the application and the test script in the database according to the extracted application identification information.

[0123] Through the test script management page provided by the embodiments of this application, the upload process of the test script can be simplified, improving the work efficiency of testers. At the same time, the automatically generated first mapping relationship makes the association between the application and the test script clear and definite, facilitating the server to quickly and accurately search for and call the test script during the data point testing process.

[0124] In some embodiments, in response to a test task, determining the target application corresponding to the target buried point can be specifically implemented as follows:

[0125] In response to a test task, determine the target application corresponding to the target buried point, and the application installation link corresponding to the target application.

[0126] In some embodiments, the method may further include:

[0127] Send the application installation link to the target test terminal so that the target test terminal can install the target application based on the application installation link.

[0128] In a software development and testing scenario, especially for development versions and internal testing versions of applications, since they have not passed the application store review or are only used for internal testing, it is impossible to obtain the installation method from the regular application store. At this time, testers can provide the application installation link of the target application to meet the test requirements.

[0129] Testers can first store the installation package of the development version of the application on the enterprise's internal file server or cloud storage platform. When storing, it can be classified and stored according to dimensions such as application name, version number, and development branch. For example, create a directory of “ / dev-apps / e-commerce App / v2.3-beta / ” on the file server and store the corresponding Android APK installation package or iOS IPA installation package in it.

[0130] Testers can submit the application installation link when generating a test task.

[0131] After the server receives the application installation link, when processing the buried point test task, if it determines that the target application is of a type that cannot be installed from the application store, such as a development version, it can directly use the application installation link submitted by the tester. Subsequently, the server can send the application installation link to the target test terminal. After receiving the link, the built-in test proxy program of the target test terminal can automatically parse the link and call the corresponding installation mechanism according to the link type.

[0132] Figure 3 It is a flowchart of another embodiment of a buried point test method provided by this application. The technical solution of this embodiment can be applied to the client.

[0133] Figure 3 The buried point test method shown may include the following steps:

[0134] 301: Send a test task for the target buried point to the server, so that the server determines the target application corresponding to the target buried point in response to the test task; look up the target test script corresponding to the target application in the first mapping relationship between the application and the test script; send the target test script to the target test terminal, so that the target test terminal runs the target application using the target test script to trigger the target buried point to generate buried point test data; obtain the buried point test data; generate a test result for the target buried point based on the standard buried point data and the buried point test data.

[0135] 302: Receive the test result sent by the server.

[0136] The detailed implementation manners and beneficial effects of the steps in the method of this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated herein.

[0137] Figure 4 This is a flowchart of another embodiment of a buried point test method provided by this application. The technical solution of this embodiment can be applied to a test terminal.

[0138] Figure 4 The buried point test method shown may include the following steps:

[0139] 401: Obtain the target test script sent by the server, where the target test script is determined from the first mapping relationship between the application and the test script after the server receives the test task for the target buried point sent by the client and determines the target application corresponding to the target buried point in response to the test task.

[0140] 402: Run the target application using the target test script to trigger the target buried point to generate buried point test data, so that the server obtains the buried point test data, generates a test result for the target buried point based on the standard buried point data and the buried point test data, and sends the test result to the client.

[0141] In some embodiments, the method may further include:

[0142] Receive the target startup script sent by the server;

[0143] Before running the target application using the target test script, the method further includes:

[0144] Run the target startup script to start the target application according to the startup process described in the target startup script.

[0145] The detailed implementation manners and beneficial effects of the steps in the method of this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated herein.

[0146] Figure 5 Schematic diagram of the buried point testing method provided by an embodiment of this application.

[0147] As Figure 5 shown, the testing user can use the client 501 to send a testing task for the target buried point to the server 502. Among them, the testing task may include the target buried point identification information submitted by the testing user, the target application where the target buried point is located, and the application description information of the target application.

[0148] The server 502 queries the target test script corresponding to the target application from the first mapping relationship, and queries the target startup script corresponding to the application description information of the target application from the second mapping relationship.

[0149] After querying the target test script and the target startup script, the server 502 can send the target test script and the target startup script to the target test terminal 503, so that the target test terminal 503 first runs the target startup script to start the target application, and then runs the target test script to run the target application, triggering the target buried point to generate buried point test data.

[0150] After the server sends the target test script to the target test terminal, it can detect the execution status of the target test script. When the server detects that the target test script has been executed, it can obtain the buried point test data reported by the target buried point from the buried point data collection system (not shown in the figure).

[0151] After obtaining the buried point test data, the server can generate a test result for the target buried point based on the standard buried point data and the buried point test data, and send the test result to the client 501.

[0152] In the embodiment of this application, during the process of the target test terminal starting the target application, it can monitor the startup status in real time. If the target application fails to start successfully within the preset time, for example, there are situations such as application crashes, unresponsiveness, or inability to load, the target test terminal can capture this abnormal information and send it to the server. The abnormal information may include, for example, error codes in the system log, key event records during the application startup process, etc. The server can organize this abnormal information into a detailed abnormal report and change the status of the testing task to "abnormal". At the same time, the server can record the key information in the abnormal report, such as the abnormal type, occurrence time, possible reasons, etc., in the fields associated with this testing task in the database. Then, terminate the current testing process and exit the program to avoid unnecessary resource waste.

[0153] If the test application is successfully launched, the target test terminal can execute the target test script. When executing the target test script, the server can update the status of the test task to "In progress" and display this status in real time on the system interface, facilitating the test user to understand the task progress at any time.

[0154] The server can monitor the execution progress of the target test terminal. For example, it can send a query request to the target test terminal every 5 seconds to obtain information such as the number of the target test script currently being executed, the number of test cases that have been executed, and the number of successfully and failed executed test cases. This information will be updated in the database in real time and presented to the test user in the form of intuitive charts and lists on the system interface.

[0155] After all the target test scripts under the target test application are executed, the target test terminal can send a notification of execution completion to the server. After receiving the notification, the server can extract detailed information such as the execution status, error information, and logs of each test script from the database, and organize this information into a comprehensive test report. At the same time, the server updates the status of the test task to "Execution completed" and highlights this status on the system interface, prompting the test user to view the test report.

[0156] During the execution of the target test script, the target test terminal may encounter various abnormal situations. For example, the target test script may encounter problems such as network request timeouts or element location failures during execution. When such exceptions occur, the target test script can capture the exception information and record the detailed information of the exception, such as the exception type, the location where the exception occurred, and the relevant variable values, in the log file. At the same time, the target test script will automatically trigger an alarm mechanism and feedback the test results to the test user in various ways. The server can change the status of the test task to "Execution failed" and record the exception information in the fields associated with this test task in the database. The test user can monitor the test progress in real time through the system interface and view information such as the execution status, error information, and logs of each test case. Based on this information, the test user can promptly discover abnormal situations and quickly adjust the test strategy.

[0157] Figure 6 The block diagram of a data tracking and testing device provided by an embodiment of the present application. This device can be applied to the server, as Figure 6 shown. This device can include:

[0158] A first receiving module 601, configured to receive a test task for a target data tracking sent by a client;

[0159] A first determining module 602, configured to determine a target application program corresponding to the target data tracking in response to the test task;

[0160] The first search module 603 is configured to search for the target test script corresponding to the target application in the first mapping relationship between the application and the test script;

[0161] The first sending module 604 is configured to send the target test script to the target test terminal, so that the target test terminal runs the target application by using the target test script to trigger the target data point to generate data point test data;

[0162] The first acquisition module 605 is configured to acquire data point test data;

[0163] The first generation module 606 is configured to generate a test result of the target data point based on the standard data point data and the data point test data;

[0164] The second sending module 607 is configured to send the test result to the client.

[0165] In some embodiments, the apparatus may further include:

[0166] The second determination module is configured to determine a target startup script corresponding to the target application;

[0167] In some embodiments, before sending the target test script to the target test terminal, the apparatus may further include

[0168] The fifth sending module is configured to send the target startup script to the target test terminal, so that the target test terminal runs the target startup script to start the target application on the test terminal according to the startup process described in the target startup script.

[0169] In some embodiments, the second determination module is specifically configured to:

[0170] Obtain the application description information of the target application from the test task, where the application description information includes the application version and the client type of the target application;

[0171] Search for the target startup script corresponding to the target application from the second mapping relationship between the application description information and the startup script.

[0172] In some embodiments, before sending the target test script to the target test terminal, the apparatus may further include:

[0173] The third determination module is configured to determine at least one second test terminal in an idle state from multiple first test terminals;

[0174] A fourth determination module, configured to determine, from at least one second test terminal, a test terminal installed with the target application as the target test terminal.

[0175] In some embodiments, the apparatus may further include:

[0176] A first providing module, configured to provide a test script management page;

[0177] A fourth receiving module, configured to receive a script upload operation triggered by a test client based on the test script management page, where the script upload operation is used to upload a test script for a specific application;

[0178] A second generating module, configured to generate the first mapping relationship in response to the script upload operation.

[0179] In some embodiments, the first determination module 602 is specifically configured to:

[0180] In response to the test task, determine the target application corresponding to the target buried point, and the application installation link corresponding to the target application;

[0181] In some embodiments, the apparatus may further include:

[0182] A sixth sending module, configured to send the application installation link to the target test terminal, so that the target test terminal installs the target application based on the application installation link.

[0183] Figure 6 The described buried point testing apparatus may execute Figure 2 The buried point testing method described in the illustrated embodiment, and its implementation principle and technical effects will not be elaborated further. For the buried point testing apparatus in the above embodiments, the specific manners in which each module and unit perform operations have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0184] Figure 7 The block diagram of a buried point testing apparatus provided in another embodiment of the present application. The apparatus may be applied to a client, such as Figure 7 As shown, the apparatus may include:

[0185] A third sending module 701 is configured to send a test task for a target buried point to a server, so that in response to the test task, the server determines a target application corresponding to the target buried point; look up a target test script corresponding to the target application in a first mapping relationship between applications and test scripts; send the target test script to a target test terminal, so that the target test terminal runs the target application by using the target test script to trigger the target buried point to generate buried point test data; obtain the buried point test data; generate a test result of the target buried point based on standard buried point data and the buried point test data;

[0186] A second receiving module 702 is configured to receive the test result sent by the server.

[0187] Figure 7 The described buried point testing device can execute Figure 3 the buried point testing method described in the illustrated embodiment, and its implementation principle and technical effects will not be elaborated further. For the buried point testing device in the above embodiment, the specific manners in which each module and unit perform operations have been described in detail in the embodiment related to the method, and will not be elaborated here in detail.

[0188] Figure 8 The block diagram of a buried point testing device provided in another embodiment of the present application. This device can be applied to a test terminal, such as Figure 8 shown, and this device may include:

[0189] A first obtaining module 801 is configured to obtain a target test script sent by a server. The target test script is determined from a first mapping relationship between applications and test scripts after the server receives a test task for a target buried point sent by a client and in response to the test task, determines a target application corresponding to the target buried point;

[0190] A first running module 802 is configured to run the target application by using the target test script to trigger the target buried point to generate buried point test data, so that the server obtains the buried point test data, generates a test result of the target buried point based on standard buried point data and the buried point test data, and sends the test result to the client.

[0191] In some embodiments, the device may further include: <0,

[0192] A fourth receiving module is configured to receive a target start script sent by the server;

[0193] In some embodiments, before running the target application by using the target test script, the device may further include:

[0194] The first running module is used to run the target startup script to start the target application according to the startup process described in the target startup script.

[0195] Figure 8 The described buried point testing device can execute Figure 4 The buried point testing method described in the illustrated embodiment, its implementation principle and technical effects will not be elaborated further. For the buried point testing device in the above embodiment, the specific ways in which each module and unit perform operations have been described in detail in the embodiment related to the method, and will not be elaborated here in detail.

[0196] It should be noted that the technical solution of the embodiment of the present application is applicable to a network virtual environment. The users described generally refer to "virtual users". Real users can register user accounts on the server through the registration method to obtain user identities in the network environment. The same user account can be logged in to the server through different types of user terminals, enabling the server to identify the same user.

[0197] The interaction operations between the server and the user can be implemented based on the user account. The corresponding data received or sent by the server to the user is also implemented based on the user account. Actually, it is the user terminal corresponding to the user account that receives or sends the corresponding data to the server. In addition, through the user account, communication between users can also be achieved. Among them, the user can refer to an individual or an organization, such as an enterprise, etc. The present application does not make specific restrictions on this.

[0198] It should be noted that in some of the processes described in the above embodiments and the accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations can be executed not in the order in which they appear in this article or in parallel. The operation numbers such as 201, 202, etc. are only used to distinguish different operations, and the numbers themselves do not represent any execution order. In addition, these processes can include more or fewer operations, and these operations can be executed in sequence or in parallel. It should be noted that the descriptions such as "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a sequence, nor do they limit that "first" and "second" are of different types.

[0199] Figure 9 This is a schematic structural diagram of an embodiment of a computing device provided by the present application. As Figure 9 shown, in practice, the computing device may include: a storage component 901 and a processing component 902.

[0200] A storage component 901 is configured to store computer programs and can be further configured to store various other data to support operations on a computing device. Examples of such data include instructions for any application or method operating on the computing device, data structures, contact data, phone book data, messages, pictures, videos, and the like.

[0201] A processing component 902 is coupled to the storage component 901 and is configured to execute the computer programs in the storage component 901 to implement the buried point testing method provided by the embodiments of the present application.

[0202] The above-mentioned processing component includes one or more processors to execute computer instructions to complete all or part of the steps in the above method. Of course, the processing component can also be implemented by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components for executing the above method.

[0203] The above storage component can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read only memory (EEPROM), erasable programmable read only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disks or optical discs.

[0204] The above communication component is configured to facilitate communication between the device where the communication component is located and other devices in a wired or wireless manner. The device where the communication component is located can access a wireless network based on a communication standard, such as a mobile communication network, or a combination thereof. In an exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0205] The above display component may include a screen, and the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also detect the duration and pressure associated with the touch or swipe operation.

[0206] The above power supply component supplies power to various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device where the power supply component is located.

[0207] The above audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), and when the device where the audio component is located is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive external audio signals. The received audio signals can be further stored in the memory or sent via the communication component. In some embodiments, the audio component further includes a speaker for outputting audio signals.

[0208] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to be able to implement the steps in the above method embodiments. Among them, the computer-readable storage medium can be implemented by a volatile or non-volatile or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, Phase-change Random Access Memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), flash memory or other memory technologies, Compact Disc Read Only Memory (CD-ROM), Digital Video Disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices or any other non-transmission medium

[0209] Correspondingly, an embodiment of the present application further provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the processor can implement each step in the above method embodiments. It should be understood that each process or a combination of multiple processes in the above method flow can be implemented by the computer program or instructions. In addition, these computer programs or instructions can be applied to the processors of general-purpose computers, special-purpose computers, embedded processors, or other programmable data processing devices, so that the processors of general-purpose computers, special-purpose computers, embedded processors, or other programmable data processing devices can be used as devices to implement the corresponding functions in the above method embodiments.

[0210] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0211] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements not only includes those elements but also includes other elements not explicitly listed, or further includes elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of another identical element in the process, method, commodity or device including the element.

[0212] Finally, it should be noted that the above are only embodiments of the present application and are not used to limit the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A method for buried point testing, characterized in that, Applied to the server side, the method includes: Receiving a test task for a target buried point sent by a client; In response to the test task, determining a target application corresponding to the target buried point; Looking up a target test script corresponding to the target application in a first mapping relationship between the application and the test script; Sending the target test script to a target test terminal so that the target test terminal runs the target application by using the target test script to trigger the target buried point to generate buried point test data; Obtaining the buried point test data; Generating a test result of the target buried point based on standard buried point data and the buried point test data; Sending the test result to the client.

2. The method according to claim 1, wherein The method further includes: Determining a target start script corresponding to the target application; Before sending the target test script to the target test terminal, the method further includes: Sending the target start script to the target test terminal so that the target test terminal runs the target start script to start the target application on the test terminal according to the start process described in the target start script.

3. The method according to claim 2, wherein The determining the target start script corresponding to the target application includes: Obtaining application description information of the target application from the test task, where the application description information includes the application version and client type of the target application; Looking up the target start script corresponding to the target application from a second mapping relationship between the application description information and the start script.

4. The method according to claim 1, wherein Before sending the target test script to the target test terminal, the method further includes: Determining at least one second test terminal in an idle state from multiple first test terminals; Determining a test terminal with the target application installed among at least one second test terminal as the target test terminal.

5. The method according to claim 1, characterized in that, The method further includes: Providing a test script management page; Receiving a script upload operation triggered by a test client based on the test script management page, where the script upload operation is used to upload a test script for a specific application; In response to the script upload operation, generating the first mapping relationship.

6. The method according to claim 1, characterized in that, The responding to the test task and determining the target application corresponding to the target buried point includes: Responding to the test task, determining the target application corresponding to the target buried point, and an application installation link corresponding to the target application; The method further includes: Sending the application installation link to the target test terminal so that the target test terminal installs the target application based on the application installation link.

7. A method for buried point testing, characterized in that, Applied to the client side, the method includes: Send a test task for a target data point to the server so that the server, in response to the test task, determines the target application corresponding to the target data point; look up the target test script corresponding to the target application in the first mapping relationship between the application and the test script; send the target test script to the target test terminal so that the target test terminal runs the target application using the target test script to trigger the target data point to generate data point test data; obtain the data point test data; generate a test result for the target data point based on the standard data point data and the data point test data; Receive the test result sent by the server.

8. A buried point testing method, characterized in that Applied to a test terminal, the method includes: Obtain a target test script sent by the server, where the target test script is determined from the first mapping relationship between the application and the test script after the server receives a test task for a target data point sent by the client and, in response to the test task, determines the target application corresponding to the target data point; Run the target application using the target test script to trigger the target data point to generate data point test data so that the server obtains the data point test data, generates a test result for the target data point based on the standard data point data and the data point test data, and sends the test result to the client.

9. The method according to claim 8, characterized in that The method further includes: Receive a target startup script sent by the server; Before running the target application using the target test script, the method further includes: Run the target startup script to start the target application according to the startup process described in the target startup script.

10. A computing device, characterized in that, Includes a processing component and a storage component; The storage component stores a computer program; the computer program is used to be called and executed by the processing component to implement the data point test method according to any one of claims 1 to 6, or to implement the data point test method according to claim 7, or to implement the data point test method according to any one of claims 8 to 9.

11. A computer-readable storage medium, characterized in that, On which a computer program is stored, and when the computer program is executed by the processing component, it implements the data point test method according to any one of claims 1 to 6, or to implement the data point test method according to claim 7, or to implement the data point test method according to any one of claims 8 to 9.

12. A computer program product, characterized in that, Includes a computer program or instruction, and when the computer program or instruction is executed by the processing component, it implements the data point test method according to any one of claims 1 to 6, or to implement the data point test method according to claim 7, or to implement the data point test method according to any one of claims 8 to 9.

Images