Application stability testing methods and readable storage media

Abstract

This invention proposes an application stability testing method and a readable storage medium. The method includes: detecting that a trigger condition for an application stability test task is met, and reading the test task's runtime configuration; starting the application on each test device; detecting that the application on each test device has started, starting the UI process of each test device; detecting that the UI process of each test device has started, starting the stability test process of the application on each test device; detecting that the stability test process of the application on each test device has started, starting the heartbeat acquisition page sub-thread of each test device, and driving each heartbeat acquisition page sub-thread to acquire the application's page context information at the arrival of each heartbeat cycle, and parsing the information of the application's currently running page from the page context information. This invention enables the acquisition of the application's real page information during application stability testing.

Description

Technical Field

[0001] The embodiments of the present invention relate to application stability testing methods, readable storage media, and computer program products. Background Technology

[0002] APP (application) stability testing refers to testing whether the system version is stable and can continuously provide services to users during the long-term continuous operation of the APP.

[0003] Currently, Monkey is the preferred tool for app stability testing. Monkey sends random user event streams (such as key input, touch screen input, and gesture input) to the system to perform stability testing on the app.

[0004] During app stability testing, it's necessary to read the app's pages to calculate version page coverage and other metrics during app runtime. Version page coverage is calculated as: (Number of pages in the current version of the app traversed during the test) / (Total number of pages in the app). However, for apps using dynamic plugin architectures (such as Replugin plugins), the displayed pages are dynamically changing strings according to certain rules, and page coverage is even dynamically calculated each time the app starts. This makes it impossible to obtain the actual page content, leading to inaccurate calculated version page coverage. Figure 1 The example image shows a page from an app captured using existing technology. It can be seen that the page names are all garbled characters. Furthermore, in existing testing methods, when obtaining the total number of pages in the app, if a page is split into multiple pages, it is counted as multiple pages. This results in the calculated version page coverage being lower than the actual version page coverage. Summary of the Invention

[0005] This invention proposes an APP stability testing method, a readable storage medium, and a computer program product to obtain the actual page information of an application during application stability testing.

[0006] The technical solution of this invention is implemented as follows:

[0007] An application stability testing method, the method comprising:

[0008] If the triggering conditions for a stability test task of an application are detected, the main function is entered through the main process of the test task, and the runtime configuration of the test task is read.

[0009] Based on the test device identifiers defined in the runtime configuration, launch the application on each test device;

[0010] The application on each test device has been detected to be running, and the user interface (UI) process of each test device is started.

[0011] The UI process of each test device has been detected to be running. The stability test process of the application on each test device is then started.

[0012] The stability test process of the application on each test device has been detected to have started. The heartbeat acquisition page sub-thread of each test device is started, and each heartbeat acquisition page sub-thread is driven to collect the page context information of the application when each heartbeat cycle arrives, and to parse the information of the currently running page of the application from the page context information.

[0013] The runtime configuration further includes: the name and version number of the application;

[0014] The step of launching the application on each test device according to the test device identifier defined in the running configuration includes:

[0015] Based on the test device identifiers, application names, and version numbers defined in the runtime configuration, launch the corresponding version of the application on each test device;

[0016] The information of the application's currently running page includes: the name of the application's currently running page;

[0017] After the sub-threads driving each heartbeat collection page parse the information of the currently running page of the application from the page context information, the process further includes:

[0018] Each heartbeat acquisition page sub-thread saves the parsed information of the currently running page of the application to the database;

[0019] Furthermore, upon detecting the completion of the current stability test task, the system retrieves the names of all running pages of the application collected by the heartbeat acquisition page sub-thread of each test device during this stability test task from the database. Duplicate running page names are removed, and the total number of remaining running page names is taken as the number of pages of the current version of the application traversed in this test task. The system also retrieves the number of pages of the current version of the application traversed in all previous test tasks. This number is then added to the total number of pages of the current version of the application traversed in all previous test tasks to obtain the total number of pages of the current version of the application traversed in all completed test tasks. The ratio of this ratio to the total number of pages of the current version of the application is taken as the page coverage rate of the current version of the application.

[0020] The total number of pages in the application is pre-configured by the user.

[0021] After the main process of the test task enters the main function and reads the runtime configuration of the test task, the process further includes:

[0022] Store one or more page loading strategies from the runtime configuration into the database;

[0023] Simultaneously with activating the heartbeat acquisition page sub-thread of each test device, the process further includes:

[0024] Start the page loading sub-thread of each test device, drive the page loading sub-thread to read the page loading strategy from the database in sequence, and load the application's pages according to the read page loading strategy.

[0025] The process of driving the page loading sub-thread to sequentially read page loading strategies from the database includes:

[0026] The page loading sub-thread is driven to read a page loading strategy from the page loading strategies stored in the database in descending order of priority, based on the principle that the fewer times it has been executed, the higher its priority.

[0027] Furthermore, after executing any page loading strategy, the execution count of that strategy is incremented by 1.

[0028] The page loading strategy includes: entry routes for one or more pages.

[0029] The step of collecting the application's page context information at the arrival of each heartbeat cycle includes:

[0030] At the arrival of each heartbeat cycle, the page context information in the memory stack is read and stored in memory as a list;

[0031] The step of parsing the information of the currently running page of the application from the page context information includes:

[0032] Parse the last data entry from the list of page context information in memory, and then parse the information of the currently running page of the application from that last data entry.

[0033] An application stability testing device, comprising: a processor and a memory, wherein:

[0034] The memory stores a program configured to cause the processor to perform the steps of the application stability testing method as described in any of the preceding claims when executed by the processor.

[0035] A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the steps of the application stability testing method as described in any of the preceding claims.

[0036] A computer program product includes a computer program or instructions that, when executed by a processor, implement the steps of the application stability testing method as described in any of the preceding claims.

[0037] In this embodiment of the invention, by driving the heartbeat acquisition page sub-thread to collect the application's page context information when each heartbeat cycle arrives and parsing the information of the application's currently running page from the page context information, the true page information of the application can be obtained when conducting application stability testing. Attached Figure Description

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

[0039] Figure 1 These are sample images of an app's pages captured using existing technology.

[0040] Figure 2 This is a flowchart of an application stability testing method provided in an embodiment of the present invention;

[0041] Figure 3 This is an exemplary structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0042] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0043] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0044] The technical solution of the present invention will be described in detail below with reference to specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0045] This invention proposes a method for testing the stability of an application. The method involves detecting when a trigger condition for a stability test task is met, entering the main function through the main process of the test task, and reading the runtime configuration of the test task. Based on the identifiers of each test device defined in the runtime configuration, the application on each test device is started. Upon detecting that the application on each test device has started, the UI process of each test device is started. Upon detecting that the UI process of each test device has started, the stability test process of the application on each test device is started. Upon detecting that the stability test process of the application on each test device has started, the heartbeat acquisition page sub-thread of each test device is started, and each heartbeat acquisition page sub-thread is driven to collect the page context information of the application at the arrival of each heartbeat cycle, and parse the information of the currently running page of the application from the page context information. This invention enables the acquisition of the actual page information of the application during application stability testing.

[0046] Figure 2 The flowchart of an application stability testing method according to an embodiment of the present invention is as follows:

[0047] Step 201: The triggering conditions for a stability test task of an application are detected. The main process of the test task enters the main function and reads the runtime configuration of the test task.

[0048] Here, the triggering conditions for a stability test task of an application can be: detecting the arrival of the test cycle of the stability test task of the application, or detecting the arrival of the preset test time point of the stability test task of the application, or receiving a stability test command for the application input by the user.

[0049] The configuration for running this test task includes: the application's name, version number, etc., and may also include: page loading strategy, etc.

[0050] The application in this embodiment of the invention can be an Android application that uses dynamic plugins (such as replugin plugins).

[0051] Step 202: Launch the application on each test device according to the test device identifiers defined in the runtime configuration.

[0052] Step 203: The application has been detected to be running on each test device. Start the UI (User Interface) process on each test device.

[0053] Step 204: The UI process of each test device has been detected to be running. Start the stability test process of the application on each test device.

[0054] Step 205: The stability test process of the application on each test device has been detected. The heartbeat acquisition page sub-thread of each test device is started, and each heartbeat acquisition page sub-thread is driven to collect the page (activity) context information of the application when each heartbeat cycle arrives, and parse the information of the currently running page of the application from the page context information.

[0055] The stability testing process in this embodiment of the invention may use the Monkey process.

[0056] The interval of the heartbeat cycle can be preset, such as 100ms, 200ms, etc.

[0057] In the above embodiments, by driving the heartbeat acquisition page sub-thread to collect the application's page context information when each heartbeat cycle arrives and parsing the information of the application's currently running page from the page context information, the real page information of the application can be obtained when conducting application stability testing.

[0058] The runtime configuration in step 201 further includes: the name and version number of the application;

[0059] In step 202, based on the identifiers of each test device defined in the runtime configuration, the application on each test device is launched, including:

[0060] Based on the identifiers of each test device, the name of the application, and the version number defined in the runtime configuration, launch the corresponding version of the application on each test device;

[0061] In step 205, the information of the application's currently running page includes: the name of the application's currently running page;

[0062] In step 205, after driving each heartbeat acquisition page sub-thread to parse the information of the current running page of the application from the page context information, it further includes: driving each heartbeat acquisition page sub-thread to save the parsed information of the current running page of the application to the database;

[0063] Furthermore, upon detecting the completion of the current stability test task, the system retrieves the names of all running pages of the application collected by the heartbeat acquisition page sub-thread of each test device during this stability test task from the database. Duplicate running page names are removed, and the total number of remaining running page names is taken as the current version page count of the application traversed in this test task. The system also retrieves the current version page count of the application traversed in all previous test tasks. This current version page count is added to the total number of current version page counts of the application traversed in all previous test tasks to obtain the total number of current version page counts of the application traversed in all completed test tasks. The ratio of the total number of current version page counts of the application traversed in all completed test tasks to the total number of pages of the application is taken as the current version page coverage rate of the application.

[0064] Specifically, the process of driving each heartbeat acquisition page sub-thread to save the parsed information of the application's currently running page to the database involves: associating the parsed information of the application's currently running page with the application's name and then saving it to the database.

[0065] The total number of pages in the application is pre-configured by the user to ensure the accuracy of the total number of pages in the application, and further ensure the accuracy of the calculation of the page coverage of the current version of the application.

[0066] In the above embodiments, since the names of the actual pages of the application are collected, the accuracy of the calculation of the page coverage of the current version of the application is improved.

[0067] After calculating the page coverage of the current version of the application in this test task, the page coverage of the current version of the application in this test task can be saved and notified to the user.

[0068] In practical applications, at the end of this test task, the coverage rate of the application can also be calculated as: the number of pages of the current version of the application that were traversed in this test task / the total number of pages of the application.

[0069] In one optional embodiment, after the main process of the test task enters the main function and reads the running configuration of the test task in step 201, it further includes: storing one or more page loading strategies in the running configuration into the database;

[0070] Furthermore, in step 205, while starting the heartbeat acquisition page sub-thread of each test device, it further includes: starting the page loading sub-thread of each test device, driving each page loading sub-thread to read the page loading strategy from the database in sequence and load the application's page according to the read page loading strategy.

[0071] In one optional embodiment, driving each page loading sub-thread to read page loading strategies from the database sequentially includes: driving each page loading sub-thread to read a page loading strategy from the page loading strategies stored in the database in descending order of priority, according to the principle that the fewer times it has been executed, the higher its priority; and after executing any page loading strategy, incrementing the execution count of that strategy by 1.

[0072] In one optional embodiment, the page loading strategy includes: entry routes for one or more pages.

[0073] Because certain pages have a low probability of being loaded during normal application operation, page loading strategies are defined to improve the comprehensiveness and accuracy of testing. These strategies define the entry routes for these pages, ensuring they are loaded during testing. When executing these strategies, to further improve comprehensiveness and accuracy, the strategy with the fewest executions is executed first, ensuring that as many pages as possible are loaded.

[0074] In one optional embodiment, step 205, collecting the page context information of the application at the arrival of each heartbeat cycle, includes: reading the page context information in the memory stack at the arrival of each heartbeat cycle, and storing the read page context information in memory in the form of a list;

[0075] Furthermore, in step 205, the information of the currently running page of the application is parsed from the page context information, including: parsing the last piece of data from the page context information list in memory, and parsing the information of the currently running page of the application from the last piece of data.

[0076] Additionally, at the end of this test task, parameters such as the number of crashes, coverage rate, current version page coverage (referred to as version coverage), runtime, total number of pages traversed, and number of strategies (schemas) traversed / executed can be displayed to the user.

[0077] This invention also provides an application stability testing apparatus, which includes a processor and a memory, wherein the memory stores a computer program or instructions configured to cause the processor to perform the steps of the application stability testing method as described in any of the above embodiments when executed by the processor.

[0078] This invention also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps of the application stability testing method as described in any of the above embodiments.

[0079] This invention also provides a computer-readable storage medium that stores instructions, which, when executed by a processor, can perform the steps in the application stability testing method described above. In practical applications, the computer-readable medium may be included in the devices / apparatus / systems described above, or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium stores instructions, which, when executed by a processor, can perform the steps in the application stability testing method described above.

[0080] According to embodiments disclosed in this invention, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof, but not intended to limit the scope of protection of this invention. In the embodiments disclosed in this invention, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0081] like Figure 3 As shown, embodiments of the present invention also provide an electronic device. For example... Figure 3 As shown, it illustrates a structural schematic diagram of the electronic device involved in an embodiment of the present invention, specifically:

[0082] The electronic device may include a processor 31 with one or more processing cores, a memory 32 with one or more computer-readable storage media, and a computer program stored in the memory and executable on the processor. When the program in the memory 32 is executed, the aforementioned application stability testing method can be implemented.

[0083] Specifically, in practical applications, this electronic device may also include components such as a power supply 33 and an input / output unit 34. Those skilled in the art will understand that... Figure 3 The structure of the electronic device 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. Wherein:

[0084] The processor 31 is the control center of the electronic device. It connects various parts of the electronic device through various interfaces and lines. By running or executing software programs and / or modules stored in the memory 32, and calling data stored in the memory 32, it performs various functions of the server and processes data, thereby monitoring the electronic device as a whole.

[0085] The memory 32 can be used to store software programs and modules, i.e., the aforementioned computer-readable storage medium. The processor 31 executes various functional applications and data processing by running the software programs and modules stored in the memory 32. The memory 32 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc.; the data storage area may store data created based on server usage, etc. Furthermore, the memory 32 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 32 may also include a memory controller to provide the processor 31 with access to the memory 32.

[0086] The electronic device also includes a power supply 33 that supplies power to the various components. This power supply can be logically connected to the processor 31 via a power management system, enabling functions such as charging, discharging, and power consumption management. The power supply 33 may also include one or more DC or AC power sources, a recharging system, a power fault detection circuit, a power converter or inverter, a power status indicator, or any other components.

[0087] The electronic device may also include an input / output unit 34, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control. The input / output unit 34 can also be used to display information input by the user or information provided to the user, as well as various graphical user interfaces, which can be composed of graphics, text, icons, video, and any combination thereof.

[0088] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments disclosed in this invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in the order specified in the drawings. For example, two blocks shown connected together may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0089] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this invention. In particular, the features described in the various embodiments and / or claims of this invention can be combined and / or combined in various ways without departing from the spirit and teachings of this invention, and all such combinations and / or combinations fall within the scope of this disclosure.

[0090] This article uses specific embodiments to illustrate the principles and implementation methods of the present invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of the present invention, and are not intended to limit the present invention. For those skilled in the art, changes can be made to the specific implementation methods and application scope based on the ideas, spirit and principles of the present invention. Any modifications, equivalent substitutions, improvements, etc., made should be included within the scope of protection of the present invention.

Claims

1. A method for testing application stability, characterized in that, The method includes: If the triggering conditions for a stability test task of an application are detected, the main function is entered through the main process of the test task, and the runtime configuration of the test task is read. Based on the test device identifiers defined in the runtime configuration, launch the application on each test device; The application on each test device has been detected to be running, and the user interface (UI) process of each test device is started. The UI process of each test device has been detected to be running. The stability test process of the application on each test device is then started. The stability test process of the application on each test device has been started. The heartbeat acquisition page sub-thread of each test device is started, and each heartbeat acquisition page sub-thread is driven to collect the page context information of the application when each heartbeat cycle arrives and parse the information of the currently running page of the application from the page context information. The step of collecting the application's page context information at the arrival of each heartbeat cycle includes: reading the page context information in the memory stack at the arrival of each heartbeat cycle, and storing the read page context information in memory in the form of a list; The step of parsing the information of the currently running page of the application from the page context information includes: parsing the last piece of data from the page context information list in memory, and parsing the information of the currently running page of the application from the last piece of data.

2. The method according to claim 1, characterized in that, The runtime configuration further includes: the name and version number of the application; The step of launching the application on each test device according to the test device identifier defined in the running configuration includes: Based on the test device identifiers, application names, and version numbers defined in the runtime configuration, launch the corresponding version of the application on each test device; The information of the application's currently running page includes: the name of the application's currently running page; After the sub-threads driving each heartbeat collection page parse the information of the currently running page of the application from the page context information, the process further includes: Each heartbeat acquisition page sub-thread saves the parsed information of the currently running page of the application to the database; Furthermore, upon detecting the completion of the current stability test task, the system retrieves the names of all running pages of the application collected by the heartbeat acquisition page sub-thread of each test device during this stability test task from the database. Duplicate running page names are removed, and the total number of remaining running page names is taken as the number of pages of the current version of the application traversed in this test task. The system also retrieves the number of pages of the current version of the application traversed in all previous test tasks. This number is then added to the total number of pages of the current version of the application traversed in all previous test tasks to obtain the total number of pages of the current version of the application traversed in all completed test tasks. The ratio of this ratio to the total number of pages of the current version of the application is taken as the page coverage rate of the current version of the application.

3. The method according to claim 2, characterized in that, The total number of pages in the application is pre-configured by the user.

4. The method according to claim 1, characterized in that, After the main process of the test task enters the main function and reads the runtime configuration of the test task, the process further includes: Store one or more page loading strategies from the runtime configuration into the database; Simultaneously with activating the heartbeat acquisition page sub-thread of each test device, the process further includes: Start the page loading sub-thread of each test device, drive the page loading sub-thread to read the page loading strategy from the database in sequence, and load the application's pages according to the read page loading strategy.

5. The method according to claim 4, characterized in that, The process of driving the page loading sub-thread to sequentially read page loading strategies from the database includes: The page loading sub-thread is driven to read a page loading strategy from the page loading strategies stored in the database in descending order of priority, based on the principle that the fewer times it has been executed, the higher its priority. Furthermore, after executing any page loading strategy, the execution count of that strategy is incremented by 1.

6. The method according to claim 4, characterized in that, The page loading strategy includes: entry routes for one or more pages.

7. An application stability testing device, characterized in that, The device includes: a processor and a memory, wherein: The memory stores a program configured to cause the processor to perform the steps of the application stability testing method as described in any one of claims 1 to 6 when executed by the processor.

8. A non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores instructions, characterized in that, When executed by a processor, the instructions cause the processor to perform the steps of the application stability testing method as described in any one of claims 1 to 6.

9. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the steps of the application stability testing method as described in any one of claims 1 to 6.

Images