A test method and device of an application program, an electronic device and a storage medium

Abstract

This disclosure provides a method, apparatus, electronic device, and storage medium for testing an application, comprising: in response to a test event for a target application, acquiring at least one device configuration information, wherein the device configuration information is used to simulate the operation of the target application in the operating environment of a type of terminal device; creating a corresponding target simulation device based on at least one preset simulation device and the device configuration information, wherein the target simulation device is used to provide the operating environment of a type of terminal device; acquiring at least one test task, and testing the target application in the operating environment simulated by each target simulation device based on the test cases of the test task; and generating test logs corresponding to each target simulation device based on the data generated by each target simulation device during the test. This disclosure significantly improves the comprehensiveness and effectiveness of target application testing and ensures the operational stability of the target application on various types of terminal devices.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically to a method, apparatus, electronic device, and storage medium for testing applications. Background Technology

[0002] With the continuous development of computer communication technology and the widespread application of terminal devices such as smartphones, smart TVs, and computers, terminals are becoming increasingly diversified and personalized, becoming indispensable in people's lives and work. To meet people's pursuit of spiritual enrichment, user-friendly applications that can operate on terminal devices have emerged. Users can use these applications on their devices; for example, on a smart TV, a user can use a music application to play songs or listen to audiobooks.

[0003] Currently, to ensure that applications running on terminal devices can function properly, maintain full functionality, and provide a consistent user experience across different usage scenarios, compatibility testing of applications on terminal devices has become an indispensable and crucial step before application launch. However, due to the existence of different device brands and models, under current technology, testers can typically only conduct compatibility testing on a subset of mainstream devices and system versions. This results in incomplete coverage of compatibility testing, potentially leading to adaptation issues on terminal devices after application launch, and consequently, poor application stability. Summary of the Invention

[0004] This disclosure provides a testing method, apparatus, electronic device, and storage medium for an application, which effectively expands the testing coverage of the target application, significantly improves the comprehensiveness and effectiveness of the target application testing, effectively avoids compatibility issues on terminal devices after the target application is launched, and thus ensures the operational stability of the target application on various terminal devices after its launch.

[0005] In a first aspect, embodiments of this disclosure provide a method for testing an application, comprising: In response to a test event for a target application, at least one device configuration information is acquired, wherein the device configuration information is used to simulate the target application running in the operating environment of a type of terminal device; A corresponding target simulation device is created based on at least one preset simulation device and the configuration information of each device, wherein one of the target simulation devices is used to provide a type of terminal device operating environment; Obtain at least one test task, and test the target application in a simulated operating environment of each of the target simulation devices based on the test cases of the test task; Based on the data generated by each target simulation device during the test, test logs corresponding to each target simulation device are generated.

[0006] Secondly, embodiments of this disclosure provide an application testing apparatus, comprising: A response unit is configured to, in response to a test event for a target application, acquire at least one device configuration information, wherein one of the device configuration information is used to simulate the target application running in the operating environment of a type of terminal device; A creation unit is used to create a corresponding target simulation device based on at least one preset simulation device and the configuration information of each device, wherein one of the target simulation devices is used to provide a type of terminal device operating environment; An acquisition unit is configured to acquire at least one test task and test the target application in a simulated operating environment of each of the target simulation devices based on the test cases of the test task. The generation unit is used to generate test logs corresponding to each of the target simulation devices based on the data generated by each target simulation device during the test.

[0007] Thirdly, embodiments of this disclosure also provide an electronic device, including a memory storing a plurality of instructions; a processor loading instructions from the memory to execute the steps of a testing method for any application provided in embodiments of this disclosure.

[0008] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to perform the steps of a testing method for any application provided in embodiments of this disclosure.

[0009] Fifthly, embodiments of this disclosure also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in the testing method for any application provided in embodiments of this disclosure.

[0010] The solution adopted in this disclosure can create multiple target simulation devices by using preset device configuration information and preset simulation devices to simulate the operation of the target application in the operating environment of various types of terminal devices and perform testing based on test cases of test tasks. This effectively expands the test coverage of the target application, significantly improves the comprehensiveness and effectiveness of the target application test, effectively avoids the problem of compatibility anomalies on terminal devices after the target application is launched, and thus ensures the stability of the target application on various terminal devices after it is launched. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of a scenario for a testing system for an application provided in this embodiment of the disclosure; Figure 2 This is a schematic flowchart of an embodiment of the testing method for the application provided in this disclosure. Figure 3 This is a schematic diagram of the structure of the testing device for the application provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0013] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure. Furthermore, in the description of the embodiments of this disclosure, the terms "first," "second," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance. Therefore, features defined with "first" or "second" may explicitly or implicitly include one or more features. In the description of the embodiments of this disclosure, "multiple" means two or more, unless otherwise explicitly specified.

[0014] This disclosure provides a method, apparatus, electronic device, and computer-readable storage medium for testing applications. Specifically, this embodiment will be described from the perspective of an application testing apparatus, which can be integrated into an electronic device. That is, the application testing method of this disclosure can be executed by an electronic device. Optionally, the electronic device may include a terminal device. The terminal device may be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, or personal computer (PC), etc.

[0015] The application testing method provided in this disclosure can be applied to interactive systems, such as terminal devices and servers. The terminal can be a device that includes both receiving and transmitting hardware, i.e., a device with receiving and transmitting hardware capable of performing bidirectional communication over a bidirectional communication link. The terminal device and the server can communicate bidirectionally via a network.

[0016] Optionally, the server can be a standalone server, or a server network or server cluster, including but not limited to computers, network hosts, single network servers, multiple network server sets, or cloud servers composed of multiple servers. Cloud servers consist of a large number of computers or network servers based on cloud computing.

[0017] In one embodiment of this disclosure, the application testing method can run on a local terminal device or a server. When the game interaction method runs on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and a client device.

[0018] Please see Figure 1 , Figure 1This is a schematic diagram of a testing system for an application provided in this embodiment. The system may include at least one terminal, at least one server, at least one database, and a network. A user's terminal can connect to different servers via the network. The terminal is any device with computing hardware capable of supporting and executing software products corresponding to model generation. Furthermore, when the system includes multiple terminals, multiple servers, and multiple networks, different terminals can connect to each other through different networks and servers. The network can be a wireless network or a wired network, such as a wireless local area network (WLAN), local area network (LAN), cellular network, 2G network, 3G network, 4G network, 5G network, etc. Additionally, different terminals can also connect to other terminals or servers using their own Bluetooth networks or hotspot networks. For example, multiple users can connect online through different terminals via appropriate networks and synchronize with each other to support multi-user use. Furthermore, the system may include multiple databases coupled to different servers, and information related to the operating environment can be continuously stored in the databases while different users are using the system online.

[0019] The following detailed description is provided in conjunction with the accompanying drawings. In this embodiment, the execution subject is a terminal device as an example. It should be noted that the order of description in the following embodiments is not intended to limit the preferred order of the embodiments. Although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown in the accompanying drawings.

[0020] Please see Figure 2 , Figure 2 This is a schematic flowchart of one embodiment of the application testing method provided in this disclosure. The specific flow of the application testing method can be as follows: steps 101 to 104, wherein: Step 101: In response to a test event for the target application, obtain at least one device configuration information, wherein the device configuration information is used to simulate the target application running in the operating environment of a type of terminal device.

[0021] The terminal device can be a television terminal device (referred to as TV terminal), and the target application can be a music application, video application, e-book application, etc., suitable for television terminal devices. This is just an example, and more examples will not be elaborated here.

[0022] In one embodiment, the device configuration information includes runtime environment parameters and the application installation file of the target application. The runtime environment parameters are used to simulate the runtime environment of the terminal device. Specifically, the runtime environment parameters include device configuration parameters and system environment parameters. The device configuration parameters include core hardware such as device brand, device model, CPU architecture, memory size, storage space, resolution, screen size, and remote control interaction logic. The system environment parameters include system configuration items such as system version (e.g., Android 9 / 11 / 14), brand adaptation parameters, system permission policies, and manufacturer-customized adaptation parameters.

[0023] In this embodiment, emulator configuration templates can be stored in a database. These templates are standardized configuration sets for the TV emulator's runtime environment, representing a set of reusable parameters. They can include core hardware and system configuration items such as system version, brand compatibility parameters, resolution, memory, CPU architecture, and remote control interaction logic. Multiple emulators (i.e., simulated devices) can be quickly generated in batches using these templates. Specifically, multiple emulator instances with identical configurations can be cloned with a single click, avoiding repetitive manual configuration and improving the efficiency of test environment setup. Each emulator configuration template includes a template ID, system version, brand compatibility parameters, resolution, memory, and other configuration parameters, supporting simulation compatibility parameters for multiple brands and models. For example, an emulator configuration template might include: Template ID = EMU_TV_001 (Android 14, 1920×1080, parameters adapted to a mainstream TV brand).

[0024] Step 102: Create a corresponding target simulation device based on at least one preset simulation device and the configuration information of each device, wherein one of the target simulation devices is used to provide a type of terminal device operating environment.

[0025] In this embodiment, the preset simulation device can be an emulator, specifically an Android TV / smart TV system emulator. This emulator is a virtual environment developed on a server or locally, used to simulate the hardware environment and system behavior of a smart TV (i.e., a TV terminal device). The emulator is based on mature Android emulator technologies (such as Android Studio Emulator, Genymotion, etc.) and customized for the TV side, adapting to features such as remote control input, large-screen display, and TV system APIs. This embodiment uses preset emulator configuration templates for multiple brands / models (including parameters such as system version, resolution, CPU architecture, and hardware characteristics) to quickly clone and generate emulator instances (i.e., simulated devices) of different specifications. The emulators are deployed in a server cluster in a containerized / virtual machine format, supporting batch creation, startup, destruction, and elastic scaling. Each emulator instance runs independently, possesses a complete TV system environment, and can install target test applications (i.e., target applications) and perform automated operations.

[0026] In one specific embodiment, multiple different target simulation devices can be created one-to-one based on multiple preset simulation devices and multiple device configuration information. The different target simulation devices have different brands and / or system versions. For example, multiple target simulation devices with the same brand but different system versions can be created, or multiple target simulation devices with different brands but the same system version can be created, or multiple target simulation devices with different brands and different system versions can be created, and so on.

[0027] Step 103: Obtain at least one test task, and test the target application in the simulated operating environment of each target simulation device based on the test cases of the test task.

[0028] In the embodiments of this application, a test task can be obtained, and each target simulation device can be controlled to simultaneously test the target application based on the test cases of the same test task in the simulated running environment of each target simulation device.

[0029] In another embodiment, multiple test tasks can be acquired, and each target simulation device can be controlled to test the target application in the simulated operating environment of each target simulation device using test cases of the same or different test tasks.

[0030] In one specific embodiment, the step "obtaining at least one test task, and testing the target application in a simulated runtime environment of each of the target simulation devices based on the test cases of the test task" includes: Obtain at least one test task; Based on a preset algorithm, the target test tasks that each target simulation device can currently process are determined from the test tasks; The target simulation devices are controlled to test the target application in the simulated operating environment of each target simulation device based on the test cases of the corresponding target test task.

[0031] In this embodiment, a dedicated scheduling algorithm based on a greedy strategy can be designed to achieve batch creation / destruction of simulators through a scheduling engine. Simultaneously, test tasks are intelligently allocated according to task priority and resource utilization, supporting parallel testing across multiple system versions. Idempotency and rollback mechanisms are also designed to ensure the stability of the testing process. The preset algorithm is a greedy algorithm, which is an algorithmic approach that makes what appears to be the optimal choice at each step in order to ultimately obtain the globally optimal solution.

[0032] Optionally, the preset algorithm may also include a round-robin scheduling algorithm and a weighted load balancing scheduling algorithm. Round-robin scheduling, a type of fair allocation scheduling algorithm, sequentially distributes test tasks to various target simulation devices, repeatedly executing the allocation action to ensure all devices are used equally. The weighted load balancing algorithm uses device performance, current resource occupancy, and device load weight as the core allocation criteria, configuring differentiated weight values ​​for different target simulation devices. It prioritizes allocating test tasks to devices with high weights and sufficient remaining resources, taking into account both device hardware capabilities and real-time load status to achieve rational resource allocation.

[0033] For example, embodiments of this disclosure can employ round-robin scheduling with resource load threshold constraints, balancing allocation fairness and device operational stability. Specifically, resource load thresholds such as CPU, memory, and concurrent task count for the target simulation devices can be pre-set. The scheduling engine monitors the load of each target simulation device in real time, only including those whose load does not exceed the threshold in the round-robin queue. Then, test tasks are distributed sequentially according to the queue order, with round-robin allocation to avoid task backlog on a single device. During operation, the load can be dynamically monitored; if a target simulation device is overloaded, it is removed from the queue, and if the load decreases, it is re-enqueued.

[0034] For example, a fixed weight can be pre-configured for each target simulation device based on its hardware performance, operating system version, and concurrent capacity. Then, the scheduling engine collects the CPU, memory, and other resource utilization rates of each target simulation device in real time and calculates a comprehensive allocation coefficient based on the pre-set weights. Finally, based on the comprehensive allocation coefficient, the target test tasks to be processed are preferentially allocated to the target simulation devices with higher coefficients and lower loads. Finally, the load changes of the target simulation devices are dynamically monitored, and the allocation tendency is adjusted in real time. At the same time, the scheduling engine works together to complete the batch start and stop of the simulators to achieve parallel testing of multiple versions of applications.

[0035] Furthermore, each test task is assigned a task priority; the step "determining the target test tasks that the target simulation device can currently process from the test tasks based on a preset algorithm" includes: Obtain the current resource information of each of the target simulation devices; The preset algorithm is used to determine the target test tasks that the target simulation devices can currently process from the test tasks based on the task priority of each test task and the resource information of each target simulation device.

[0036] In this embodiment, different test tasks have different priorities, and the scheduling engine allocates resources according to priority, with higher-priority tasks being executed first. Different simulators can execute different test tasks separately without waiting for all simulators to complete the same test task before switching. For example, taking resource utilization as an example, suppose there is a simulator cluster including simulator A, simulator B, and simulator C. At this time, simulator A has a resource utilization rate of 10% (i.e., idle), simulator B has a resource utilization rate of 30% (i.e., light load), and simulator C has a resource utilization rate of 80% (i.e., high load). The test tasks to be executed include: task P0 (highest priority), which is for urgent release compatibility testing; task P1 (high priority), which is for new feature scenario testing; and task P2 (normal priority), which is for regression testing. The allocation steps based on resource information and task priority using a greedy algorithm are as follows: (1) First, check the priority: prioritize task P0, assign it to the simulator A (10%) with the lowest occupancy, and execute it immediately; (2) After simulator A starts executing task P0, the remaining idle resources are viewed by simulator B (30%), and the next high-priority task P1 is assigned to simulator A. (3) The emulator C has an occupancy rate of 80%. No new tasks will be assigned for the time being. Task P2 will be assigned after the load on emulator C decreases. (4) If simulator A finishes task P0 first, the occupancy rate of simulator A will return to 10%, and it will immediately take over the next task P2 to be executed without waiting for simulator B to finish task P1.

[0037] In another specific embodiment, the polling scheduling algorithm can be a weighted polling strategy. Specifically, when the resource utilization rate of all target simulators is below 20%, this weighted polling scheduling logic is initiated. The waiting time of each test task to be executed is calculated, and the weight is calculated according to the rules: for every 10 minutes increase in the waiting time of a task, the corresponding weight value is increased by 1. Based on the weight ranking of each test task and combined with the weighted polling rules, the test tasks are sequentially allocated to different simulators. At the same time, during the allocation and execution of test tasks, the device status and task queuing status are continuously monitored, the task weights are dynamically updated, and the weighted polling allocation is executed cyclically to balance the long-term operating load of each simulator and ensure the orderly execution of test tasks.

[0038] In another specific embodiment, the preset algorithm may further include a dynamic prediction strategy. By continuously collecting CPU utilization data of each target simulation device over the past hour, the CPU load change trend of each target simulation device is fitted, and the estimated load value of each simulator for the next 5 minutes is predicted based on this trend. Then, the predicted load values ​​of all target simulation devices are compared and sorted, and the target simulation device with the lowest predicted load is selected. High-priority test tasks are preferentially assigned to this target simulation device, ensuring that high-priority test tasks are executed on devices with lower load pressure and more stable operation, thereby improving the execution quality and success rate of key test tasks and achieving precise and optimal allocation of test tasks.

[0039] Optionally, to avoid the unnecessary occupation of system resources caused by repeated execution of test actions in test tasks, to prevent data corruption caused by repeated testing, and to prevent pollution of the operating environment due to anomalies during testing, the method further includes: Set the corresponding execution identifier for the test corresponding to the test task; The test is idempotent and / or rolled back based on the execution identifier.

[0040] Idempotent handling refers to preventing duplicate execution by binding a unique execution identifier to each test task. Specifically, a globally unique execution identifier is bound to each test task, and the execution record of the identifier is verified before execution. If the test has already been executed, it is skipped; only if it has not been executed is the test started, thus preventing the repeated creation of simulators and the repeated running of test cases, achieving test idempotency. Anomaly rollback refers to performing reverse tracing by binding a unique execution identifier to each test task. Specifically, if an anomaly occurs during testing, the execution identifier is used to accurately locate all changed data, such as newly added simulators, database logs, and temporary configurations, allowing for batch undoing, environment restoration, and data rollback to the pre-test state. This avoids polluting the baseline environment and is suitable for risk control in low-traffic online tests.

[0041] For example, in this embodiment of the disclosure, for each test task to be executed, a globally unique execution identifier (e.g., a unique execution ID) is assigned to its corresponding single test action (i.e., test). This execution identifier is then associated and bound with the current test task, the target simulated device, the test cases of the test task to be executed, and the test account, establishing an association mapping relationship and storing it in the system database. Before starting the test, the database is queried to find the historical execution records corresponding to the execution identifier. Based on the query results, idempotent processing is selectively performed on this test. If abnormal situations such as program errors, test case execution failures, or device offline occur during the test run, rollback processing is performed based on the execution identifier.

[0042] Furthermore, after the idempotency processing and rollback processing are completed, the normal test process continues to run; in abnormal scenarios, after the data and environment are restored, the test is terminated and the abnormal log is output, thus completing the closed-loop management of a single test task.

[0043] In one specific embodiment, upon receiving a test instruction to start a specified test task, the unique execution identifier corresponding to this test is extracted, and it is determined whether there is a record of completion or execution for this execution identifier. If an execution record is found for the execution identifier, it is determined to be a duplicate test trigger, and the test startup process is skipped directly, without repeatedly creating the target simulation device or repeatedly loading and running test cases. If no execution record is found for the execution identifier, it is determined to be a first trigger, and the simulation device is created normally, the corresponding test cases are loaded, and the test on the target application is started in the simulated runtime environment. After the test officially starts, the execution identifier, test startup time, and associated device information are synchronously written into the execution record and marked as being in execution, thereby achieving idempotent control of the test process and avoiding resource consumption and data corruption problems caused by repeated operations.

[0044] In another specific embodiment, during test execution, the operating status of the target simulated device executing the test actions, the test case execution results, and the database write status are monitored in real time. When an abnormal signal is detected, a rollback mechanism is immediately triggered, and the unique execution identifier corresponding to the current test is locked. Based on this execution identifier, reverse tracing is performed to traverse and locate all changes generated throughout the entire test process, including temporarily created target simulated devices, test logs stored in the system database, temporarily effective device and application configurations, and temporary data generated during the test. Batch undo operations are performed on all changed data and environment items obtained through tracing, such as destroying temporarily created simulated devices, deleting newly added test logs, restoring temporary configurations to the original baseline version, and cleaning up temporary data generated by the test, completely reverting the entire test environment and business data to the initial state before the start of this test. After the rollback operation is completed, the abnormal record corresponding to the execution identifier is updated, the test task is terminated, effectively avoiding dirty test data from polluting the online baseline environment and meeting the risk control requirements of low-traffic testing in a real environment.

[0045] Step 104: Based on the data generated by each target simulation device during the test, generate test logs corresponding to each target simulation device.

[0046] In this embodiment of the application, test logs corresponding to each target simulation device can be generated based on the data generated by each target simulation device during the test. For example, test logs can be generated for each target simulation device's data during the test, so that the test logs can be analyzed later.

[0047] Alternatively, test logs can be generated only for the target simulation device that generates abnormal data during the test, for analysis of test anomalies.

[0048] Based on the above description, the following examples will further illustrate the testing methods for the applications disclosed herein, as detailed below.

[0049] The test task includes at least one test case, and each test case is used to indicate a test scheme and a corresponding verification scheme in an application scenario.

[0050] In this embodiment, a TV terminal is used as an example. Test cases can be test cases for TV-specific application scenarios. By extracting the core user operation chain of the TV terminal (such as "play-song change-sound quality / effect change"), the remote control key values ​​(direction keys, confirmation key, function keys, etc.) are structurally bound to the test steps to form a scenario-based test suite containing operation sequences and verification standards, ultimately achieving accurate reproduction of the continuous scenario on the TV terminal. The user operation chain refers to the high-frequency, continuous core business operation flow when a user uses the product on the TV terminal, and is the smallest reusable unit constituting a complete usage scenario. For example, for a music application scenario, the user operation chain can be: homepage recommendations → select playlist with direction keys → confirm key → play song → change song → adjust volume / sound quality / effects → exit playback; for a video application scenario, the user operation chain can be: homepage recommendations → select drama → play → fast forward / rewind → switch resolution → select episode → exit playback; for an account application scenario, the user operation chain can be: My → select login → scan code / verification code login → bind device → view membership benefits.

[0051] Specifically, the steps for extracting the user action chain are as follows: (1) Data collection: Based on product tracking logs / user behavior playback, the top 20 daily active user behavior paths are selected, and low-frequency and abnormal operations are filtered out.

[0052] (2) Link aggregation: Connect discrete action nodes (such as “select playlist” and “play”) in time order, merge duplicate paths, and form a standardized operation link template.

[0053] (3) Scene trimming: Combined with the test objectives (compatibility / stability), core business nodes are retained and unnecessary branches (such as personalized recommendation pop-ups) are removed to ensure that the link is reproducible and verifiable.

[0054] (4) Test case mapping: Map each link to an independent test scenario, and clarify the scenario entry, operation sequence and expected results.

[0055] In one embodiment, the method further includes: The test plan based on the test task is used to test the target application in the simulated operating environment of the target simulation device, and the test results are obtained. If any abnormal test results are found that do not conform to the verification scheme, test logs corresponding to each target simulation device are generated based on the data generated by the target simulation device during the test.

[0056] In this embodiment of the application, the test plan may include multiple test steps, each step of which corresponds to a verification standard (i.e., verification plan). If there are abnormal test results in the test results where a test step fails to pass the verification standard, then a test log corresponding to the target simulation device is generated based on the data corresponding to the test step that fails to pass the verification standard.

[0057] In one embodiment, after step "generating test logs corresponding to each of the target simulation devices based on the data generated by the target simulation devices during the testing process", the method further includes: Obtain at least one verification rule corresponding to the test case; Based on the data corresponding to the abnormal test results in the test log and the various verification rules, anomaly analysis information and anomaly handling solutions corresponding to the abnormal test results are generated.

[0058] In this embodiment of the application, test logs can be collected, key parameters can be extracted from the test logs, and the most similar verification rule can be found from the verification rules through the association model to perform root cause analysis, so as to generate anomaly repair suggestions and root cause reports.

[0059] Furthermore, the step "analyzing the data corresponding to the abnormal test results in the test log and each of the verification rules to generate abnormal analysis information and abnormal handling solutions corresponding to the abnormal test results" includes: The anomaly analysis information corresponding to the anomaly test results is converted into a first vector, and each of the verification rules is converted into a second vector; Similarity is calculated based on the first vector and each of the second vectors to obtain the similarity results corresponding to each of the verification rules; From the various similarity results, target similarity results that meet the first preset condition are selected, and based on the target verification rules corresponding to the target similarity results, anomaly analysis information and anomaly handling schemes corresponding to the abnormal test results are generated.

[0060] In this embodiment, the anomaly analysis information corresponding to the anomaly test result is converted into a first vector, and each of the verification rules is converted into a second vector. The cosine similarity between the first vector and the second vector is calculated to match the most similar verification rule. For example, the similarity result is a similarity value. Verification rules with similarity values ​​higher than 0.8 are selected as target verification rules to match the root cause. At the same time, the rule success rate and priority are combined for further screening to finally determine the optimal root cause.

[0061] Optionally, the test cases and corresponding verification rules are stored in a database. After step "analyzing the data corresponding to the abnormal test results in the test log and each of the verification rules to generate abnormal analysis information and abnormal handling solutions corresponding to the abnormal test results", the method further includes: The anomaly analysis information and the anomaly handling plan are sent to the database so that the database updates the association between test cases and verification rules stored in the database based on the anomaly analysis information and the anomaly handling plan.

[0062] In this embodiment, the database can be a knowledge base, which stores core information such as test cases and associated verification rules for each test task. Furthermore, exception cases and version difference data generated during the testing process can be automatically fed back to the knowledge base, driving the dynamic optimization of test cases and associated verification rules.

[0063] In one specific embodiment, taking a TV terminal as an example, this application provides a method for constructing scenario-based test cases specifically for TV terminals. Specifically, it extracts the core user operation chain of the TV terminal, structurally binds remote control key values ​​with test steps, and forms a scenario-based test suite containing operation sequences and verification standards, ultimately achieving accurate reproduction of continuous scenarios on the TV terminal. Simultaneously, this application also provides a method for batch scheduling and parallel testing of multiple versions of TV terminal emulators. It designs a dedicated scheduling algorithm based on a greedy strategy and presets configuration templates for multiple versions of TV terminal emulators. This application implements batch creation / destruction of emulators through a scheduling engine, and intelligently allocates test tasks according to task priority and resource utilization, supporting parallel testing of multiple system versions. It also includes idempotency and rollback mechanisms to ensure the stability of the testing process. This application addresses the core needs of multi-version adaptation testing for TV terminals by customizing a greedy strategy scheduling algorithm to achieve batch management and parallel testing of emulators, breaking through the efficiency bottleneck of traditional solutions. This method requires the integration of multiple dimensions such as task priority and resource utilization in its design.

[0064] In one specific embodiment, this application embodiment can extract key parameters such as system version, dependency library version, and exception type from abnormal test logs using regular expression matching + NLP technology; then, based on these parameters, a three-dimensional association model of "exception, system version, and dependency library" is constructed; finally, the parameters are converted into feature vectors, and the root cause is matched using a cosine similarity algorithm (threshold 0.8), and repair suggestions are output by combining historical rule success rates and priorities. The three-dimensional association model proposed in this application embodiment integrates multi-dimensional parameters and intelligent algorithms to achieve automatic analysis, significantly improving the efficiency and accuracy of root cause localization.

[0065] Furthermore, this application provides a closed-loop system and implementation method for testing, analysis, and optimization across the entire process. Specifically, it stores core information such as test cases and associated verification rules in a knowledge base. This application automatically feeds back abnormal cases and version difference data generated during testing to the knowledge base, driving the dynamic optimization of test cases and associated verification rules. Simultaneously, this application also includes a full-process audit chain and a sandbox environment to ensure the compliance and traceability of the testing process. This application, by constructing a closed-loop system across the entire process, achieves data linkage and dynamic optimization at each stage, while also taking into account compliance control.

[0066] In summary, the embodiments of this disclosure provide a method for testing an application. This method can acquire at least one device configuration information in response to a test event for the target application, create corresponding target simulation devices based on at least one preset simulation device and the device configuration information, and simulate the target application running in various types of terminal device environments. Based on the test cases of the acquired test tasks, the method tests the target application in the simulated running environments of each target simulation device. Based on the data generated by each target simulation device during the testing process, test logs are generated for each target simulation device. By creating multiple target simulation devices using preset device configuration information and preset simulation devices, the method simulates the target application running in various types of terminal device environments and performs testing based on the test cases of the test tasks. This effectively expands the testing coverage of the target application, significantly improves the comprehensiveness and effectiveness of the target application testing, effectively avoids compatibility issues on terminal devices after the target application is launched, and thus ensures the operational stability of the target application on various terminal devices after its launch.

[0067] Based on the above description, the following examples will further illustrate the testing method of the application disclosed herein. This disclosure adopts an overall architecture of multiple modules and corresponding closed-loop links to implement the application testing method. Specific embodiments are as follows: (1) Core Overall Architecture: The architecture integrates six core modules: a scenario-based test suite construction module, a multi-version TV simulator management module, an automated scheduling engine, an abnormal log intelligent analysis module, a knowledge base, and an audit and privacy protection module, forming a complete link of scenario construction, batch simulator coverage, intelligent analysis, and closed-loop optimization. The modules in the architecture provided in this disclosure are deeply adapted to the TV end testing requirements, avoiding the adaptation defects of generalized architectures; the knowledge base enables data linkage and closed-loop optimization of each module, breaking through the limitations of isolated and uncoordinated testing links in existing technologies.

[0068] (2) The core responsibilities of each module are as follows: 1) Scenario-based test suite construction module: Extract real-world scenarios, structure test steps, and maintain a reusable test case library; 2) Multi-version TV emulator management module: Preset configuration templates for multiple brands / models, batch create / destroy emulators, monitor running status, and achieve full version coverage through batch deployment of emulators, replacing the need for full purchase of physical devices; 3) Automated scheduling engine: Parses tasks, schedules across simulators, executes test cases, catches exceptions, and has idempotency and rollback mechanisms; 4) Intelligent analysis module for anomaly logs: collects logs, parses parameters, correlates and matches root causes, and generates repair suggestions; 5) Knowledge base: Stores test cases, templates, associated validation rules, and historical data, and supports dynamic updates; 6) Audit and Privacy Protection Module: Records audit chain, de-identifies sensitive information, and implements access control and approval workflow.

[0069] (3) To ensure the standardized implementation of the plan, four core data models are defined as follows: 1) Scenario-based test case model: Core fields include test case ID, name, test steps (binding remote control key values), verification criteria, etc. For example, test case ID = UC_TV_001 (basic playback scenario), and steps include key-value mappings such as "navigation - startup - playback - song switching - audio quality / effect switching". This application embodiment integrates remote control key values ​​as core fields into test cases, accurately adapting to the TV terminal operation logic and solving the problem of general test case models not being suitable for TV terminals.

[0070] 2) Emulator configuration template model: Includes template ID, system version, brand adaptation parameters, resolution, memory, and other configurations, supporting emulation adaptation for 50+ brands and 200+ models. Example: Template ID=EMU_TV_001 (Android 14, 1920×1080, adapted to a mainstream TV brand parameters); 3) Exception Log Parsing Model: Includes key parameters such as log ID, system version, exception type, and dependency library version. Example: Log ID = LOG_ERR_001 (Android 13 crash, audio SDK 2.0); 4) Associated validation rule model: Core fields include rule ID, exception type, root cause description, and remediation suggestions. For example, rule ID = RULE_001 (Audio SDK 2.0 is not compatible with Android 13 MediaPlayer API).

[0071] This application embodiment establishes a three-dimensional relationship of "anomaly-system version-dependency library" to provide core data support for intelligent root cause localization, breaking through the limitations of existing rule models that only focus on a single anomaly type and lack sufficient correlation dimensions.

[0072] (4) Implementation of core algorithms: The feasibility of the solution is supported by three core algorithms. The specific implementation logic is as follows: 1) Scenario-based test case scheduling algorithm (greedy strategy): The core logic is to allocate test tasks based on both task priority and simulator resource utilization, prioritizing the allocation of high-priority tasks to simulators with resource utilization <30% to avoid resource contention. The innovation of this algorithm lies in its customized design for multi-version TV testing scenarios, enabling optimal parallel scheduling of multiple versions and overcoming the limitation of general scheduling algorithms that do not consider the resource characteristics of TV simulators.

[0073] 2) Error log key parameter extraction algorithm (regular expression + NLP): Extract structured parameters such as system version and dependency libraries through regular expression matching, extract error keywords through TF-IDF, and slice and extract core error fragments; 3) Association Matching Algorithm (Cosine Similarity): The core logic is to convert abnormal parameters and rules into feature vectors respectively, and then match the root cause by calculating the cosine similarity (with a threshold set to 0.8). Simultaneously, it further filters based on rule success rate and priority, ultimately determining the optimal root cause. Low similarity scenarios trigger manual review. This algorithm integrates multi-dimensional feature vectors and historical data weights, effectively improving the accuracy of root cause localization and solving the problem of existing algorithms relying on only a single feature and having low localization accuracy.

[0074] (5) The embodiments of this application include two core workflows, which are executed automatically throughout the process, as follows: 1) Automated testing workflow: Configure tasks (upload APK, select scenario, specify version) → Batch deploy simulator → Schedule test case execution → Capture exceptions and logs → Generate version difference report → Audit archiving; 2) Intelligent analysis workflow for anomaly logs: collect logs → extract key parameters → match root causes with correlation models → generate repair suggestions → generate root cause report → provide feedback for knowledge base optimization; (6) The embodiments of this application realize the division of responsibilities between the client and the server, clarify the boundaries of responsibilities between the client and the server, and ensure efficient collaboration, as follows: 1) Server-side responsibilities: Maintaining the knowledge base, executing scheduling and association algorithms, managing simulators, handling audit privacy, and generating test reports; 2) Client / Test Agent Responsibilities: Provide a visual task configuration interface, execute test cases, collect logs, and simulate network scenarios.

[0075] (7) Module interaction and topology architecture, which includes two core parts: module interaction process and topology architecture, as detailed below: 1) Module interaction process: Testers submit tasks through the client → the server parses and queries the knowledge base → schedules simulator deployment and test case execution → captures exception logs and transmits them to the analysis module → generates a report and pushes it to the client (synchronously feeding back to the knowledge base) → the audit module records the entire process; 2) Topology: Deployed in layers according to “control and knowledge layer (knowledge base, rule engine, etc.), execution and service layer (simulator management, log collection, etc.), environment and security layer (sandbox, limiter, etc.)” to ensure high availability and security.

[0076] (8) Based on the above core concept, this application provides four specific implementation methods to adapt to different testing scenarios, as follows: 1) Offline playback testing: Testing based on recorded test cases within the sandbox, comparing results from multiple versions, suitable for basic compatibility verification; 2) Proxy-based scenario injection: Dynamically replaces parameters such as network status to simulate complex scenarios, suitable for in-depth compatibility testing; 3) Lightweight online verification: Authorize small-traffic accounts for testing, ensuring idempotency and rollback capability, suitable for verification in real-world environments; 4) Third-party dependency simulation: Reproduce third-party service responses by simulating the gateway to ensure test independence.

[0077] (9) Security and compliance safeguards: This application implements a variety of security and compliance safeguards to ensure that the testing process is legal and controllable, as detailed below: 1) Sensitive information de-identification: Replace / encrypt sensitive fields such as application package name and user identifier; 2) Minimum permissions and approval: Hierarchical permission control, online testing requires three levels of approval; 3) Idempotency and rollback: Unique execution IDs prevent duplicate operations, and automatic rollback is enabled in case of exceptions; 4) Complete audit chain: Records the entire process operation log, which is archived long-term and traceable; 5) Sandbox isolation: The test environment is isolated from the online environment, and a limiter controls the traffic; 6) Compliance verification: We do not collect real user data and conduct regular self-checks to ensure compliance with laws and regulations such as the Data Security Law.

[0078] The application testing method provided in this application embodiment can cover a variety of core compatibility testing scenarios for TV applications. The following are two typical applicable scenarios and the core application value of the solution, as detailed below: 1) Basic Playback Scenario: Suitable for core function compatibility testing of music and video TV applications. It can be based on multiple emulator versions (covering Android 9 / 11 / 13 / 14 and 50+ brand-compatible templates) to test core processes such as playback, song switching, and audio quality / effect switching. This solution replaces the traditional real-device testing mode with batch coverage via emulators, effectively compensating for the lack of full version and brand coverage due to insufficient real-device equipment, and improving the comprehensiveness of core function compatibility testing. 2) Offline Playback Scenario: Suitable for testing TV applications that require offline functionality. It can simulate complex environments such as network disconnection / recovery using multiple versions of emulators to verify the compatibility of features like offline playback and playlist synchronization. This solution leverages the parallel testing capabilities of batch emulators to quickly summarize multi-version and multi-brand adaptation test results and generate version difference reports. It avoids the drawbacks of traditional real-device testing, which is time-consuming and has limited coverage, thus improving the efficiency and coverage of compatibility testing in complex environments.

[0079] In summary, this application's embodiments, through a TV-specific scenario-based testing system and batch coverage using multiple emulator versions, accurately cover the continuous user behavior chain of "playback-song switching-sound quality / effect switching," while supporting multiple mainstream system versions. This effectively compensates for coverage gaps caused by insufficient real-device coverage, overcoming the dual limitations of incomplete generalized testing coverage and limited real-device-dependent coverage in existing solutions, achieving an innovative improvement in coverage. Furthermore, this application's embodiments, through a multi-version parallel automated scheduling engine, significantly improve the efficiency of single-version testing and multi-version parallel testing; combined with a three-dimensional intelligent association model, the root cause localization time is significantly reduced, breaking through the efficiency bottleneck of existing technologies and adapting to the needs of rapid iteration. Moreover, scenario-based testing and closed-loop optimization mechanisms based on remote control key mapping ensure testing and playback accuracy, solving the problem of large deviations between existing solution test results and actual TV usage scenarios, and improving reproduction accuracy. Furthermore, the embodiments of this application meet security requirements through operations such as sandbox environment, full-process auditing, and sensitive information de-identification; the provided standardized processes facilitate reuse, support CI / CD integration, build a low-cost private system based on open source tools, break through the limitations of cloud testing platform payment models and data security, and achieve continuous improvement of testing capabilities through a closed-loop optimization mechanism, thus possessing significant engineering application value.

[0080] This embodiment also provides a testing device for an application, which can be integrated into a terminal device. For example, such as... Figure 3 As shown, the testing apparatus for this application may include: The response unit 201 is configured to, in response to a test event for a target application, acquire at least one device configuration information, wherein the device configuration information is used to simulate the target application running in the operating environment of a type of terminal device; The creation unit 202 is used to create a corresponding target simulation device based on at least one preset simulation device and the configuration information of each device, wherein one of the target simulation devices is used to provide a type of terminal device operating environment; The acquisition unit 203 is used to acquire at least one test task and test the target application in the simulated operating environment of each target simulation device based on the test cases of the test task. The generation unit 204 is used to generate test logs corresponding to each of the target simulation devices based on the data generated by each target simulation device during the test.

[0081] In some embodiments, the device configuration information includes runtime environment parameters and the application installation file of the target application, wherein the runtime environment parameters are used to simulate the runtime environment of the terminal device.

[0082] In some embodiments, the testing apparatus for the application includes a processing subunit for: Obtain at least one test task; Based on a preset algorithm, the target test tasks that each target simulation device can currently process are determined from the test tasks; The target simulation devices are controlled to test the target application in the simulated operating environment of each target simulation device based on the test cases of the corresponding target test task.

[0083] In some embodiments, the testing apparatus for the application includes a processing subunit for: Obtain the current resource information of each of the target simulation devices; The preset algorithm is used to determine the target test tasks that the target simulation devices can currently process from the test tasks based on the task priority of each test task and the resource information of each target simulation device.

[0084] In some embodiments, the testing apparatus for the application includes a processing subunit for: Set the corresponding execution identifier for the test corresponding to the test task; The test is idempotent and / or rolled back based on the execution identifier.

[0085] In some embodiments, the test task includes at least one test case, wherein a test case is used to indicate a test scheme and a corresponding verification scheme in an application scenario.

[0086] In some embodiments, the testing apparatus for the application includes a processing subunit for: The test plan based on the test task is used to test the target application in the simulated operating environment of the target simulation device, and the test results are obtained. If any abnormal test results are found that do not conform to the verification scheme, test logs corresponding to each target simulation device are generated based on the data generated by the target simulation device during the test.

[0087] In some embodiments, the testing apparatus for the application includes a processing subunit for: Obtain at least one verification rule corresponding to the test case; Based on the data corresponding to the abnormal test results in the test log and the various verification rules, anomaly analysis information and anomaly handling solutions corresponding to the abnormal test results are generated.

[0088] In some embodiments, the testing apparatus for the application includes a processing subunit for: The anomaly analysis information corresponding to the anomaly test results is converted into a first vector, and each of the verification rules is converted into a second vector; Similarity is calculated based on the first vector and each of the second vectors to obtain the similarity results corresponding to each of the verification rules; From the various similarity results, target similarity results that meet the first preset condition are selected, and based on the target verification rules corresponding to the target similarity results, anomaly analysis information and anomaly handling schemes corresponding to the abnormal test results are generated.

[0089] In some embodiments, the testing apparatus for the application includes a processing subunit for: The anomaly analysis information and the anomaly handling plan are sent to the database so that the database updates the association between test cases and verification rules stored in the database based on the anomaly analysis information and the anomaly handling plan.

[0090] This disclosure provides an application testing apparatus. A response unit 201, in response to a test event for a target application, acquires at least one device configuration information, wherein one of the device configuration information is used to simulate the target application running in the operating environment of a type of terminal device. A creation unit 202 creates corresponding target simulation devices based on at least one preset simulation device and the device configuration information, wherein one of the target simulation devices is used to provide the operating environment of a type of terminal device. An acquisition unit 203 acquires at least one test task and tests the target application in the simulated operating environment of each target simulation device based on the test cases of the test task. A generation unit 204 generates test logs corresponding to each target simulation device based on the data generated by each target simulation device during the testing process. This disclosure effectively expands the testing coverage of the target application, significantly improves the comprehensiveness and effectiveness of the target application testing, effectively avoids compatibility issues on terminal devices after the target application is launched, and thus ensures the operational stability of the target application on various terminal devices after its launch.

[0091] Accordingly, this disclosure also provides an electronic device, which can be a terminal, such as a smartphone, tablet computer, laptop computer, touch screen, game console, personal computer (PC), personal digital assistant (PDA), or other terminal device. Alternatively, the electronic device can be a server.

[0092] like Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. The electronic device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored on the memory 302 and executable on the processor. The processor 301 and the memory 302 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0093] The processor 301 is the control center of the electronic device 300. It connects various parts of the electronic device 300 via various interfaces and lines. By running or loading software programs and / or units stored in the memory 302, and by calling data stored in the memory 302, it executes various functions and processes data of the electronic device 300, thereby providing overall monitoring of the electronic device 300. The processor 301 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this disclosure.

[0094] In this embodiment of the disclosure, the processor 301 in the electronic device 300 loads the instructions corresponding to the processes of one or more applications into the memory 302 according to the following steps, and the processor 301 runs the applications stored in the memory 302 to realize various functions, such as: In response to a test event for a target application, at least one device configuration information is acquired, wherein the device configuration information is used to simulate the target application running in the operating environment of a type of terminal device; A corresponding target simulation device is created based on at least one preset simulation device and the configuration information of each device, wherein one of the target simulation devices is used to provide a type of terminal device operating environment; Obtain at least one test task, and test the target application in a simulated operating environment of each of the target simulation devices based on the test cases of the test task; Based on the data generated by each target simulation device during the test, test logs corresponding to each target simulation device are generated.

[0095] The electronic device provided in this disclosure can, in response to a test event for a target application, acquire at least one device configuration information, create corresponding target simulation devices based on at least one preset simulation device and the device configuration information, and simulate the operation of the target application in the operating environment of various types of terminal devices; test the target application in the operating environment simulated by each target simulation device based on the test cases of the acquired test tasks; generate test logs corresponding to each target simulation device based on the data generated by each target simulation device during the test; and create multiple target simulation devices by using preset device configuration information and preset simulation devices to simulate the operation of the target application in the operating environment of various types of terminal devices and perform tests based on the test cases of the test tasks. This effectively expands the test coverage of the target application, significantly improves the comprehensiveness and effectiveness of the target application test, effectively avoids the problem of compatibility anomalies on terminal devices after the target application is launched, and thus ensures the operational stability of the target application on various types of terminal devices after its launch.

[0096] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0097] Optional, such as Figure 4 As shown, the electronic device 300 also includes: a touch display screen 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the touch display screen 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0098] The touch display screen 303 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 303 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 301. It can also receive and execute commands from the processor 301. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 301 to determine the type of touch event. Subsequently, the processor 301 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 303 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 303 can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 303 can also be used as part of the input unit 306 to achieve input functions.

[0099] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0100] Audio circuitry 305 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuitry 305 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and then processed by processor 301 before being transmitted via radio frequency circuitry 304 to, for example, another electronic device, or output to memory 302 for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and electronic devices.

[0101] The input unit 306 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0102] Power supply 307 is used to supply power to various components of electronic device 300. Optionally, power supply 307 can be logically connected to processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 307 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0103] although Figure 4 As not shown in the diagram, the electronic device 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0104] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0105] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0106] Therefore, embodiments of this disclosure provide a computer-readable storage medium storing a plurality of computer programs that can be loaded by a processor to execute a testing method for any of the application programs provided in embodiments of this disclosure. The computer program can execute the steps of the testing method for the following application programs: In response to a test event for a target application, at least one device configuration information is acquired, wherein the device configuration information is used to simulate the target application running in the operating environment of a type of terminal device; A corresponding target simulation device is created based on at least one preset simulation device and the configuration information of each device, wherein one of the target simulation devices is used to provide a type of terminal device operating environment; Obtain at least one test task, and test the target application in a simulated operating environment of each of the target simulation devices based on the test cases of the test task; Based on the data generated by each target simulation device during the test, test logs corresponding to each target simulation device are generated.

[0107] Because the computer program stored in this storage medium can, in response to test events for the target application, acquire at least one device configuration information, create corresponding target simulation devices based on at least one preset simulation device and the device configuration information, and simulate the target application running in various types of terminal device environments; test the target application in the simulated running environment of each target simulation device based on the test cases of the acquired test tasks; generate test logs corresponding to each target simulation device based on the data generated by each target simulation device during the test; and create multiple target simulation devices through preset device configuration information and preset simulation devices to simulate the target application running in various types of terminal device environments and perform tests based on test cases of test tasks, effectively expanding the test coverage of the target application, significantly improving the comprehensiveness and effectiveness of the target application test, effectively avoiding compatibility issues on terminal devices after the target application is launched, and thus ensuring the stability of the target application's operation on various terminal devices after launch.

[0108] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0109] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0110] Since the computer program stored in the computer-readable storage medium can execute the testing method of any application provided in the embodiments of this disclosure, the beneficial effects that the testing method of any application provided in the embodiments of this disclosure can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0111] According to one aspect of this disclosure, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above embodiments.

[0112] In the above embodiments of the application testing apparatus, computer-readable storage medium, electronic device, and computer program product, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process and beneficial effects of the above-described application testing apparatus, computer-readable storage medium, computer program product, electronic device, and their corresponding units can be referred to the description of the application testing method in the above embodiments, and will not be repeated here.

[0113] The foregoing has provided a detailed description of a testing method, apparatus, electronic device, computer-readable storage medium, and computer program product for an application provided by the embodiments of this disclosure. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the embodiments above are only for the purpose of helping to understand the methods and core ideas of this disclosure. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this disclosure. Therefore, the content of this specification should not be construed as a limitation of this disclosure.

Claims

1. A testing method for an application, characterized in that, include: In response to a test event for a target application, at least one device configuration information is acquired, wherein the device configuration information is used to simulate the target application running in the operating environment of a type of terminal device; A corresponding target simulation device is created based on at least one preset simulation device and the configuration information of each device, wherein one of the target simulation devices is used to provide a type of terminal device operating environment; Obtain at least one test task, and test the target application in a simulated operating environment of each of the target simulation devices based on the test cases of the test task; Based on the data generated by each target simulation device during the test, test logs corresponding to each target simulation device are generated.

2. The method according to claim 1, characterized in that, The device configuration information includes operating environment parameters and the application installation file of the target application. The operating environment parameters are used to simulate the operating environment of the terminal device.

3. The method according to claim 1, characterized in that, The step of obtaining at least one test task and testing the target application in a simulated operating environment on each of the target simulation devices based on the test cases of the test task includes: Obtain at least one test task; Based on a preset algorithm, the target test tasks that each target simulation device can currently process are determined from the test tasks; The target simulation devices are controlled to test the target application in the simulated operating environment of each target simulation device based on the test cases of the corresponding target test task.

4. The method according to claim 3, characterized in that, Each of the aforementioned test tasks is assigned a task priority; the step of determining the target test tasks that each target simulation device can currently process from the test tasks based on a preset algorithm includes: Obtain the current resource information of each of the target simulation devices; The preset algorithm is used to determine the target test tasks that the target simulation devices can currently process from the test tasks based on the task priority of each test task and the resource information of each target simulation device.

5. The method according to claim 1, characterized in that, The method further includes: Set the corresponding execution identifier for the test corresponding to the test task; The test is idempotent and / or rolled back based on the execution identifier.

6. The method according to claim 1, characterized in that, The test task includes at least one test case, and one test case is used to indicate a test scheme and a corresponding verification scheme in an application scenario.

7. The method according to claim 6, characterized in that, The method further includes: The test plan based on the test task is used to test the target application in the simulated operating environment of the target simulation device, and the test results are obtained. If any abnormal test results are found that do not conform to the verification scheme, test logs corresponding to each target simulation device are generated based on the data generated by the target simulation device during the test.

8. A testing apparatus for an application, characterized in that, include: A response unit is configured to, in response to a test event for a target application, acquire at least one device configuration information, wherein one of the device configuration information is used to simulate the target application running in the operating environment of a type of terminal device; A creation unit is used to create a corresponding target simulation device based on at least one preset simulation device and the configuration information of each device, wherein one of the target simulation devices is used to provide a type of terminal device operating environment; An acquisition unit is configured to acquire at least one test task and test the target application in a simulated operating environment of each of the target simulation devices based on the test cases of the test task. The generation unit is used to generate test logs corresponding to each of the target simulation devices based on the data generated by each target simulation device during the test.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to perform the steps of the test method for the application as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the test method for the application as described in any one of claims 1 to 7.

Images