Application test method and device, electronic equipment and computer readable storage medium

Abstract

The embodiment of the invention discloses an application testing method and device, electronic equipment and a computer readable storage medium. According to the embodiment of the invention, after at least one recording instruction triggered by a recording object is received, a running view of a target application is recorded according to the recording instruction, and recorded content is obtained; taking the recorded content as a test case, and updating a test case data set of the target application; when a playback instruction triggered by the test object for the target application is received, reading a target test case specified by the test object from the test case data set; then, obtaining a target recording view of the target test case, and determining a target view model corresponding to the target recording view; obtaining target time sequence information of a target recording view in the target test case, and calling a target view model to play back the target recording view based on the target time sequence information; according to the scheme, a zero-code and burying-point-free recording process can be realized, and a special application event is recorded and played back.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and more specifically to an application testing method, apparatus, electronic device, and computer-readable storage medium. Background Art

[0002] Automated testing is a process that transforms human-driven testing actions into machine-executed actions. It generally refers to the automation of software testing, i.e., running a system or application under preset conditions and evaluating the results. Compared to traditional testing methods (which typically involve testers designing test cases, having them reviewed, and then executing tests step-by-step according to the procedures described in the test cases to compare actual and expected results), automated testing can save manpower, time, and hardware resources, thus improving testing efficiency.

[0003] Most current automated testing solutions require manual writing of test cases, followed by testing with the help of third-party applications or tools, making it impossible to automate the entire testing process. Furthermore, it is difficult to simulate and test certain special events (such as camera events). Summary of the Invention

[0004] This application provides an application testing method, apparatus, electronic device, and computer-readable storage medium that eliminates the need for testers to manually write test cases and allows for recording and playback testing of specific events.

[0005] This application provides an application testing method, including:

[0006] Upon receiving at least one recording instruction triggered by the recording object, the running view of the target application is recorded according to the recording instruction to obtain the recording content;

[0007] The recorded content is used as test cases, and the test case dataset of the target application is updated. Each test case includes at least one recorded view, and each recorded view corresponds to a view model in the target application.

[0008] When a replay instruction is received from the test object for the target application, the target test case specified by the test object is read from the test case dataset;

[0009] Obtain the target recording view of the target test case, and determine the target view model corresponding to the target recording view;

[0010] Obtain the target timing information of the target recorded view in the target test case, and based on the target timing information, call the target view model to replay the target recorded view.

[0011] Accordingly, embodiments of this application provide an application testing apparatus, including:

[0012] The recording unit is used to receive at least one recording instruction triggered by the recording object during the operation of the target application, record the running view of the target application according to the recording instruction, and obtain the recording content.

[0013] An update unit is used to use the recorded content as a test case and update the test case dataset of the target application. The test case includes at least one recorded view, and each recorded view corresponds to a view model in the target application.

[0014] The reading unit is used to read the target test case specified by the test object from the test case dataset when a playback instruction triggered by the test object for the target application is received.

[0015] The parsing unit is used to obtain the target recording view of the target test case and determine the target view model corresponding to the target recording view;

[0016] The playback unit is used to obtain the target timing information of the target recorded view in the target test case, and based on the target timing information, call the target view model to play back the target recorded view.

[0017] In some embodiments, the recording unit may be specifically used to take the running view corresponding to the start recording command as the starting view and start recording with the starting view as the recording start point; take the running view corresponding to the end recording command as the ending view and stop recording with the ending view as the recording end point, thereby obtaining the recorded content.

[0018] In some embodiments, the recording unit may be specifically used to obtain the start recording time carried by the start recording instruction, take the running view of the target application displayed at the start recording time as the starting view; obtain the start status identifier corresponding to the start recording time in the starting view, and the start status data corresponding to the start status identifier; and start recording by taking the start status identifier and the start status data as the recording starting point.

[0019] In some embodiments, the recording unit may be specifically used to obtain the end recording time carried by the end recording instruction, use the running view of the target application displayed at the end recording time as the endpoint view; obtain the endpoint status identifier corresponding to the end recording time and the endpoint status data corresponding to the endpoint status identifier in the endpoint view; stop recording using the endpoint status identifier and the endpoint status data as the recording endpoint, and obtain the recording content.

[0020] In some embodiments, the updating unit may be specifically used to obtain a transition view located between the starting view and the ending view in the recorded content, and to use the starting view, the transition view, and the ending view as the recorded view; to obtain a view model identifier corresponding to each recorded view, and to combine the view model identifier and the recorded view to form a view data pair, wherein the recorded content includes at least one of the view data pairs; to sort the view data pairs according to the timing information of the recording process to obtain the test cases, and to add the test cases to the test case dataset.

[0021] In some embodiments, the update unit may be specifically used to obtain a view state identifier contained in each recorded view and state data corresponding to each view state identifier, wherein the view state identifier is used to drive the target application to update the interface according to the state data; and to combine the view model identifier, the view state identifier and the state data into the view data pair.

[0022] In some embodiments, the parsing unit may be specifically used to extract target view data pairs from the target test cases, wherein the target view data pairs include target view model identifiers and target recording views, and each target view model identifier corresponds to a target recording view; and based on the target view model identifier, determine the target view model corresponding to the target recording view.

[0023] In some embodiments, the playback unit may be specifically used to broadcast a target view model identifier corresponding to the target recorded view to all view models of the target application based on the first timing information, so that each view model determines whether to start playback after receiving the target view model identifier; after receiving feedback information confirming the start of playback, the view model that returned the feedback information is taken as the target view model, and the target recorded view is played back using the target view model.

[0024] In some embodiments, the playback unit may be specifically used to obtain the current playback view that is in playback state at the current moment, determine the next target recording view that is in the next playback order of the current playback view based on the first timing information; determine the next target view model identifier corresponding to the next target recording view based on the correspondence between the target view model identifier and the target recording view; and broadcast the next target view model identifier to all view models of the target application when the current playback view has finished playing.

[0025] In some embodiments, the playback unit may be specifically used to use the view model that returns the feedback information as the target view model corresponding to the next target recording view; and to start the target view model to play back the next target recording view.

[0026] In some embodiments, the playback unit may be specifically used to take the target view model that is currently in playback state as the current view model, and take the target recording view corresponding to the current view model as the current playback view; based on the second timing information, send a state update instruction to the current view model so that the current view model updates the target state data according to the target state identifier in the current playback view.

[0027] In some embodiments, the playback unit may be specifically used to take the target state identifier currently in playback state as the current state identifier and the target state data corresponding to the current state identifier as the current state data; determine the next target state identifier in the next playback order of the current state identifier based on the second timing information; determine the next target state data corresponding to the next target state identifier based on the correspondence between the target state identifier and the target state data; and send the state update instruction to the current view model when the current state data playback is completed, so that the current view model can play back according to the next target state data.

[0028] Furthermore, this application also provides an electronic device, including a processor and a memory, wherein the memory stores an application program, and the processor is used to run the application program in the memory to execute the application testing method provided in this application.

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

[0030] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute steps in any of the application testing methods provided in embodiments of this application.

[0031] In this embodiment, after receiving at least one recording instruction triggered by a recording object, the running view of the target application is recorded according to the recording instruction to obtain the recorded content. Then, the recorded content is used as test cases, and the test case dataset of the target application is updated. The test cases include at least one recorded view, and each recorded view corresponds to a view model in the target application. When a playback instruction triggered by a test object for the target application is received, the target test case specified by the test object is read from the test case dataset. Then, the target recorded view of the target test case is obtained, and the target view model corresponding to the target recorded view is determined. Then, the target timing information of the target recorded view in the target test case is obtained, and based on the target timing information, the target view model is called to play back the target recorded view. Because this solution utilizes the unique unidirectional data flow concept of the MVI architecture, test cases can be obtained directly from recording instructions during the target application's operation, eliminating the need for testers to manually write test cases. This enables a zero-code, no-code recording process. Furthermore, this solution can record at any point in the target application's operation, thus covering more application functions and scenarios in the test (such as special events that are difficult to test with traditional automated testing solutions, such as camera events). The testing method is highly flexible and has a wide range of applications. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a schematic diagram of the MVI software architecture pattern;

[0034] Figure 2 This is a schematic diagram illustrating an application scenario of the application testing method provided in the embodiments of this application;

[0035] Figure 3 This is a flowchart illustrating the application testing method provided in the embodiments of this application;

[0036] Figure 4 This is a schematic diagram of the system architecture of the application testing method provided in the embodiments of this application;

[0037] Figure 5 This is a schematic diagram of the recording process in the application testing method provided in the embodiments of this application;

[0038] Figure 6 This is a schematic diagram of the playback process in the application testing method provided in the embodiments of this application;

[0039] Figure 7 This is another flowchart illustrating the application testing method provided in the embodiments of this application;

[0040] Figure 8 This is a schematic diagram of the application testing device provided in the embodiments of this application;

[0041] Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0043] For ease of description, the terms that will appear in the following descriptions will be explained as follows.

[0044] MVVM, short for Model-View-ViewModel, is a software architecture pattern for building user interfaces. Its name represents its three components: Model, View, and ViewModel. The Model handles data and business logic; it can be data retrieved from the network, a database, or other data sources. The Model layer is typically independent of the user interface and can be shared across multiple interfaces. The View displays data and interacts with the user; it can be an Activity (a lifecycle representation in Android application development), a Fragment (another lifecycle representation in Android application development), or a View. The View layer is primarily responsible for displaying the user interface and responding to user input. The ViewModel acts as a bridge between the View and the Model, retrieving data from the Model and converting it into a form that the View layer can directly use. The ViewModel also detects data changes in the Model and notifies the View to update accordingly. Typically, each View has a corresponding ViewModel. The main goal of MVVM is to separate the application's user interface from its underlying data model, achieving automatic synchronization between data and the user interface through data binding, thereby reducing code coupling and improving the application's maintainability and testability.

[0045] MVI: Short for Model-View-Intent. MVI is a software architecture pattern based on an improvement of the MVVM architecture. Figure 1 A schematic diagram of the MVI architecture is shown, such as... Figure 1 As shown, MVI divides an application into four core components: Model, View, Intent, and State. The Model handles the state and logic of the data; the View displays the data and user interface; the Intent represents the user's actions, such as button clicks or input; and the State reflects the current state of the application, which can include persistent UI states (such as changes to the View in the interface) and transient UI states (such as pop-ups and prompts). For clarity, persistent UI states will be represented as State, and transient UI states as Effects. The basic MVI flow includes: the user initiates an Intent through the View; the Intent is passed to the Model; the Model updates the State based on the Intent; the change in State is passed to the View, and the View updates the interface accordingly. MVI improves upon MVVM by addressing the chaotic management of state and behavior in the MVVM architecture, transforming data flow into a unidirectional flow, and centrally managing state to form a single, trusted data source.

[0046] Record-and-Playback (RNP): RNP is an automated testing method that allows developers to pre-record test operations and then replay the test process by executing the recording script.

[0047] This application provides an application testing method, apparatus, and computer-readable storage medium. The application testing apparatus can be integrated into an electronic device, such as a smartphone, tablet, desktop computer, smart speaker, or smartwatch, but is not limited to these. The application terminal has various application software installed, providing corresponding application services to users. Software testers can perform automated testing of the application software through the application terminal. For example, software testers can record the application software's interface and store the recorded test cases in a database; software testers can also access the test cases stored in the database and replay them on the application terminal. The database can be used to store test cases. The database can be the application terminal's local database or a cloud database shared by multiple application terminals. The application terminal and the database can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0048] Figure 2 A schematic diagram illustrating an application scenario of the application testing method provided in this application embodiment is shown. For example... Figure 2 As shown, taking the application testing device integrated into an electronic device as an example, where the electronic device is the application terminal, the application terminal has various application software installed. These application software programs can be developed using the MVI architecture pattern. After receiving at least one recording instruction triggered by the recording object, the application terminal records the running view of the target application according to the recording instruction, obtaining the recorded content. Then, the recorded content is used as test cases, and the test case dataset of the target application is updated. Each test case includes at least one recorded view, and each recorded view corresponds to a view model in the target application. When a playback instruction triggered by the test object for the target application is received, the target test case specified by the test object is read from the test case dataset. Then, the target recorded view of the target test case is obtained, and the target view model corresponding to the target recorded view is determined. Next, the target timing information of the target recorded view in the target test case is obtained, and based on the target timing information, the target view model is called to play back the target recorded view.

[0049] It is understood that, in the specific implementation of this application, the recording of the running view of the target application is involved. When the following embodiments of this application are applied to specific products or technologies, permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0050] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the preferred order of the embodiments.

[0051] This embodiment will be described from the perspective of an application testing device, which is equipped with various application software. Specifically, the application testing device can be integrated into an electronic device, such as a smartphone, tablet computer, desktop computer, smart speaker, smartwatch, or other application terminal.

[0052] An application testing method includes: receiving at least one recording instruction triggered by a recording object; recording a running view of a target application according to the recording instruction to obtain recorded content; using the recorded content as test cases and updating the test case dataset of the target application, wherein the test cases include at least one recorded view, and each recorded view corresponds to a view model in the target application; when receiving a playback instruction triggered by a test object for the target application, reading the target test case specified by the test object from the test case dataset; obtaining the target recorded view of the target test case and determining the target view model corresponding to the target recorded view; obtaining the target timing information of the target recorded view in the target test case, and based on the target timing information, calling the target view model to play back the target recorded view.

[0053] Figure 3 A flowchart illustrating the application testing method provided in an embodiment of this application is shown. Figure 3 As shown, the specific process of this application testing method is as follows:

[0054] 101. Upon receiving at least one recording instruction triggered by the recording object, record the running view of the target application according to the recording instruction to obtain the recording content.

[0055] The target application can be understood as any application software installed on the application testing device. Generally, the target application is the application software that needs to be tested. Software testers can select any application software for automated testing, and the application currently selected for automated testing is the target application. It should be noted that the target application in this embodiment is developed using the MVI architecture pattern in the Android application development architecture. Therefore, the application testing method provided in this embodiment can perform automated testing on target applications using the MVI architecture pattern.

[0056] During the application design and development phase, different numbers and visual effects of Views can be designed for different applications. Therefore, a target application may include multiple views, and during the application's runtime, the corresponding views will be displayed according to the progress of the application. For ease of description, the views contained in the target application are called application views, and the views displayed during the target application's runtime are called runtime views. The application views of the target application include runtime views.

[0057] In the application testing method provided in this application embodiment, the instructions involved in the application testing method can be embedded into the view model of the MVI architecture mode to obtain the recording and playback view model (abbreviated as RNPViewMode). Figure 4 A schematic diagram of the system architecture of the application testing method provided in an embodiment of this application is shown. Figure 4As shown, the recording / playback view model is a key class for implementing application testing methods. It inherits from the MVI architecture pattern's view model, enabling it to perform recording and playback functions while fulfilling normal MVI architecture functionalities. In the target application, Activity / Fragment can be used to represent the view's lifecycle. Each Activity / Fragment contains an instance of the recording / playback view model, used to send user intents, detect updates to state values, and update the interface.

[0058] For ease of distinction, in this embodiment, the software tester in the recording phase is referred to as the recording object, and the software tester in the playback phase is referred to as the test object. It should be understood that any software tester can perform tasks in both the recording and playback phases; therefore, any software tester can be both a recording object and a test object.

[0059] When the recording target issues a recording command through the application terminal, the application software to which the recording command is directed is the target application, and the recording command issued by the recording target can be understood as the user's intent. In this embodiment, during the operation of the target application, the recording target can issue a recording command through the touch screen of the application terminal, through an external button of the application terminal, or through other hardware of the application terminal. After receiving the recording command, the application terminal can record the running view of the target application according to the recording command to obtain the recorded content.

[0060] In this embodiment of the application, the recording instruction may include a start recording instruction and an end recording instruction. The start recording instruction can be understood as the user intent upon which the application terminal initiates recording, and the end recording instruction can be understood as the user intent upon which the application terminal stops recording.

[0061] Specifically, recording the running view of the target application according to the recording instruction to obtain the recording content may include: taking the running view corresponding to the start recording instruction as the starting view and starting the recording with the starting view as the recording start point; taking the running view corresponding to the end recording instruction as the ending view and stopping the recording with the ending view as the recording end point, thus obtaining the recording content.

[0062] The recording subject initiates recording by inputting a start recording command through the target application's running view. The application terminal then transmits this start recording intention to the recording playback view model. Upon receiving the start recording intention, the recording playback view model uses the running view targeted by the start recording command as the starting view and begins recording from that view. Subsequently, if the recording subject then inputs a stop recording command through the target application's running view, the application terminal transmits this stop recording intention to the recording playback view model. Upon receiving this stop recording intention, the recording playback view model uses the running view targeted by the stop recording command as the ending view and stops recording from that view. The recorded content is then obtained. The recorded content includes all running views recorded within the time interval between the start and stop recording commands.

[0063] For example, if the target application includes 10 application views, namely UI-1, UI-2, UI-3, UI-4, UI-5, UI-6, UI-7, UI-8, UI-9, and UI-10 (the display order of these application views is determined based on the actual operation of the target application), during the operation of the target application, when UI-2 is displayed, the recording object triggers the start recording command. At this time, the application terminal starts recording with UI-2 as the starting view. Subsequently, during the operation of the target application, UI-5, UI-6, UI-2, and UI-7 are displayed in sequence. When UI-7 is displayed, the recording object triggers the end recording command. At this time, the application terminal ends recording with UI-7 as the ending view. In this recording process, the recorded content, in the order of display time, includes the following view content: UI-2, UI-5, UI-6, UI-2, and UI-7.

[0064] It should be understood that the number of application views in the target application can be other values. The number of application views mentioned above is merely an example for the purpose of explanation and does not limit the number of application views in the target application.

[0065] In this embodiment, the target application includes multiple application views. Each application view includes at least one view state identifier and state data corresponding to the view state identifier. The state data indicates the interface display status under the view state identifier. For each application view in the target application, it may include multiple view states, and each view state corresponds to one set of state data. For example, during the display of an application view, there may be multiple view interfaces. These view interfaces are different, showing the interface display status of the same application view in different states. Different view interfaces have different state data, which is the content of the view interface at the data level. To distinguish the view interfaces in different states of the application view, different view state identifiers can be used to name the view interfaces.

[0066] Taking application view UI-1 as an example, if UI-1 includes three view states, each view state corresponds to a view interface, and the view interface can be stored as state data at the data level. By calling the state data, the corresponding view interface can be presented at any time. In order to distinguish the above three view states, each view state can be marked, and the resulting view state identifiers are UI-1A, UI-1B, and UI-1C, respectively.

[0067] It should be understood that the number of view states contained in each application view can be other values. The number of view states mentioned above is merely an example for the sake of illustration and does not limit the number of view states contained in an application view.

[0068] Since each application view can include at least one view status identifier and the status data corresponding to the view status identifier, taking the running view corresponding to the start recording command as the starting view and starting recording from the starting view can include: obtaining the start recording time carried by the start recording command, taking the running view of the target application displayed at the start recording time as the starting view; obtaining the start status identifier corresponding to the start recording time and the start status data corresponding to the start status identifier in the starting view; and starting recording from the start status identifier and the start status data as the recording starting point.

[0069] In this embodiment, the view state identifier of the application view and the corresponding state data are recorded during the recording phase. Specifically, during the recording phase, the recording object inputs a start recording command through the running view of the target application, initiating the intention to start recording; the application terminal transmits the intention to start recording to the recording playback view model; after receiving the intention to start recording, the recording playback view model can intercept and record the view state identifier and the corresponding state data, using the start recording time carried by the start recording command as the recording starting point; subsequently, if the recording object inputs a stop recording command through the running view of the target application, initiating the intention to stop recording; the application terminal transmits the intention to stop recording to the recording playback view model; after receiving the intention to stop recording, the recording playback view model can stop recording using the end recording time carried by the end recording command as the recording ending point.

[0070] For example, in the aforementioned example, the application terminal starts recording with UI-2 as the starting view and ends recording with UI-7 as the ending view. If UI-2 includes two view state identifiers, UI-2A and UI-2B, and UI-7 includes four view state identifiers, UI-7A, UI-7B, UI-7C, and UI-7D, then if the starting state identifier corresponding to the start recording time is UI-2B, the application terminal will start recording using UI-2B and its corresponding state data as the starting point.

[0071] Similarly, using the running view corresponding to the end recording command as the endpoint view, and stopping recording with the endpoint view as the recording endpoint, the recorded content can be obtained by: obtaining the end recording time carried by the end recording command; using the running view displayed by the target application at the end recording time as the endpoint view; obtaining the endpoint status identifier corresponding to the end recording time in the endpoint view, and the endpoint status data corresponding to the endpoint status identifier; and stopping recording with the endpoint status identifier and endpoint status data as the recording endpoint, thus obtaining the recorded content. Based on the aforementioned example, if the endpoint status identifier corresponding to the end recording time is UI-7C, the application terminal will stop recording with UI-7C and the status data corresponding to UI-7C as the recording endpoint. Therefore, the recorded content obtained in this recording process includes: all view status identifiers displayed within the time interval of the start recording time and the end recording time (UI-2B and UI-7C are the recording start and recording endpoint, respectively, both within this range), and the status data corresponding to the aforementioned view status identifiers.

[0072] It should be understood that, for a view within the time interval between the start and end recording times, taking UI-7 as an example, the endpoint state identifier corresponding to the end recording time is UI-7C. The recorded content may fall into the following categories: If UI-7A and UI-7B's respective view interfaces are also displayed within the aforementioned time interval, then the recorded content includes UI-7A, UI-7B, and UI-7C, along with their respective state data. If UI-7A and UI-7D's respective view interfaces are also displayed within the aforementioned time interval, then the recorded content includes UI-7A, UI-7D, and UI-7C, along with their respective state data. Of course, other situations may exist, which will not be listed here.

[0073] In this embodiment, the recording / playback view model serves as the core ViewModel abstract class, inheriting from ViewModel. It can contain State (persistent UI state) values, Effect (temporary UI state) values, and Intent (user intent) values. State is of type StateFlow (a data flow processing tool), Effect is of type SharedFlow (a data flow processing tool), and Intent is of type Channel (a data flow processing tool). It provides functions such as SendIntent, UpdateState, and SendEffect to update the UI. The UpdateState and SendEffect functions intercept and record the application state, storing it as test cases upon completion of recording. Specifically, SendIntent is provided externally and called externally to send user intents, such as when a button is clicked. The UpdateState function is called internally within the recording / playback view model to update the application state. The SendEffect function is called internally within the ViewModel to send a one-time application event. The recording and playback view model also includes the `HandleIntent` function. The `HandleIntent` function can call the `updateState` and `sendEffect` functions to update application events based on different user intent Intents. During the process of calling the `updateState` and `sendEffect` functions to update application events, the recording function (`recoerd`) provided in the recording controller can be called through these functions. The `recoerd` function is used to temporarily store application events in a collection. When recording ends, the application events in the collection can be stored as a test case file in a specific format (such as JSON).

[0074] Figure 5This diagram illustrates the recording process in the application testing method provided in this embodiment. Figure 5 As shown, during the execution of the target application, all application events (such as user operation events, camera events, etc.) in the target application will call SendIntent to drive state updates, record and replay the view model to detect changes in Intent (user intent), and call UpdateState and SendEffect in HandleIntent according to different Intent (user intent) to update the UI interface. In UpdateState and SendEffect, application events are intercepted and recorded to obtain the recorded content (i.e. test cases).

[0075] 102. Use the recorded content as test cases and update the test case dataset of the target application. Each test case includes at least one recorded view, and each recorded view corresponds to a view model in the target application.

[0076] The recorded content can be stored as test cases for later playback. Test cases can be recorded for different stages of the target application's operation, resulting in multiple test cases. These test cases can then form a test case dataset for the target application.

[0077] During a recording cycle, there may be other views of the target application between the starting view and the ending view. Therefore, the recording views in a test case may include not only the starting view and the ending view, but also other views. It should be understood that the starting view and the ending view may be the same or different.

[0078] In the MVI software architecture pattern, each View has a corresponding ViewModel. Since the recorded View is the View being recorded, each recorded View corresponds to a ViewModel in the target application.

[0079] In this embodiment of the application, using recorded content as test cases and updating the test case dataset of the target application may include: obtaining the transition view between the starting view and the ending view in the recorded content, and using the starting view, transition view, and ending view as recorded views; obtaining the view model identifier corresponding to each recorded view, and combining the view model identifier and the recorded view to form a view data pair, wherein the recorded content includes at least one view data pair; sorting the view data pairs according to the timing information of the recording process to obtain test cases, and adding the test cases to the test case dataset.

[0080] For ease of description, the running view located between the starting view and the ending view in a recording cycle is referred to as the transition view. For example, in the previous example, the application terminal starts recording with UI-2 as the starting view; then, the target application sequentially displays UI-5, UI-6, UI-2, and UI-7 during the recording process. When UI-7 is displayed, the recording object triggers the end-of-recording command, and the application terminal ends recording with UI-7 as the ending view. At this time, for this recording process, the transition views include UI-5, UI-6, and UI-2.

[0081] During recording, the recorded view and its corresponding view model identifier can be recorded as data pairs. That is, a data pair is formed by combining the recorded view with its corresponding view model identifier. If the recording content includes N recorded views, then there will be N data pairs. For ease of description, the view model identifiers corresponding to each recorded view in the above example are represented as: View-2 (representing the view model identifier corresponding to UI-2), View-5 (representing the view model identifier corresponding to UI-5), View-6 (representing the view model identifier corresponding to UI-6), and View-7 (representing the view model identifier corresponding to UI-7).

[0082] Since the recording process is based on a timeline, the data in the recording content is sorted according to the chronological order of its appearance during the recording process, thus obtaining test cases that contain the timing information of the recording process.

[0083] It should be understood that a test case can include multiple identical views. For example, in the aforementioned example, the application terminal starts recording with UI-2 as the starting view; subsequently, the target application sequentially displays UI-5, UI-6, UI-2, and UI-7 during its operation, and the application terminal ends recording with UI-7 as the ending view. The test case obtained from this recording includes the following views in chronological order: UI-2, UI-5, UI-6, UI-2, and UI-7. UI-2 appears twice, indicating that UI-2 was displayed twice during the target application's operation in this recording.

[0084] Since each application view can include at least one view state identifier and corresponding state data, each recorded view (the application view being recorded) can also include at least one view state identifier and corresponding state data. Based on this, combining the view model identifier and the recorded view to form a view data pair can include: obtaining the view state identifier contained in each recorded view and the state data corresponding to each view state identifier; the view state identifier is used to drive the target application to update the interface according to the state data; and combining the view model identifier, view state identifier, and state data into a view data pair.

[0085] Table 1. Examples of view data pairs

[0086] View Model Identifier View status indicator Status data View-2 UI-2B UI-2B Status Data View-5 UI-5A UI-5A Status Data View-5 UI-5B UI-5B Status Data View-6 UI-6B UI-6B Status Data View-6 UI-6C UI-6C Status Data View-6 UI-6A UI-6A Status Data View-2 UI-2A UI-2A Status Data View-7 UI-7B UI-7B status data View-7 UI-7C UI-7C Status Data

[0087] Table 1 shows an example of view data pairs in the test cases provided in this application embodiment. As shown in Table 1, each row represents a view data pair, and each view data pair includes a view model identifier, a view state identifier, and state data. The data in the recorded content is stored in the form of data pairs. During subsequent playback of the test cases, the corresponding view model can be directly called based on the recorded view model identifier, and the interface can be updated based on the view state identifier and state data. Furthermore, the data pairs in the recorded content also need to be stored according to the timing information during the recording process. This ensures that during subsequent playback of the test cases, time delays are simulated according to the stored timing information, and the state data in each data pair is serialized and displayed, thereby accurately presenting the recorded content.

[0088] 103. When a replay instruction is received from the test object for the target application, the target test case specified by the test object is read from the test case dataset.

[0089] The test case dataset can be located in a specified location within the database. For example, it can be stored in folders such as Android Studio (an integrated development environment for Android systems) or Androidtest / assets (an application resource manager for Android systems). The test object can trigger a replay command using the Android system's UI testing tools, allowing the application terminal to retrieve the corresponding test cases from the test case dataset as target test cases for replay. In this embodiment, besides implementing replay testing locally via Android Studio, it can also be combined with DevOps (a combination of Development and Operations, a collective term for a set of processes, methods, and systems) to achieve fully automated replay testing. For instance, it can be integrated with a GitHub CI (an automated script service provided by GitHub that triggers based on Git-related events) pipeline to automatically run Android system UI tests after code submission, thus achieving automated replay testing.

[0090] Taking the test case dataset stored in the Androidtest / assets directory as an example, testers can write test classes (such as PlaybackTest) in the androidTest / java directory. The test classes can use annotations with predefined rules (such as the @RunWith(Parameterized::class) annotation), so that they can read all test case files in the androidTest / assets directory. After reading the corresponding test cases, they can perform replay tests based on the read target test cases.

[0091] 104. Obtain the target recording view of the target test case and determine the target view model corresponding to the target recording view.

[0092] After obtaining the target test cases, they can be parsed to obtain the target recorded views contained within them. Since each recorded view corresponds to a view model in the target application during recording, once the target recorded view is determined, the target view model corresponding to it can be determined based on the correspondence between recorded views and view models during recording. Determining the target view model can include: extracting target view data pairs from the target test cases, where each pair includes a target view model identifier and a target recorded view, with each identifier corresponding to a target recorded view; and determining the target view model corresponding to the recorded view based on the identifier.

[0093] The target test case includes at least one target view data pair. Each target view data pair includes a target recorded view and a target view model identifier. Therefore, after determining the target recorded view in the target test case, the target view model identifier corresponding to that target recorded view can be determined, thereby determining the target view model corresponding to that target recorded view. After determining the target view model corresponding to the target recorded view, the target recorded view in the target test case can be replayed according to the workflow of the MVI software architecture pattern.

[0094] 105. Obtain the target timing information of the target recorded view in the target test case, and based on the target timing information, call the target view model to replay the target recorded view.

[0095] In this embodiment, since the test case recording stage is performed using a timeline as the coordinate, the recorded test cases contain the timing information of the recording process. Correspondingly, the target test cases include the target timing information of the target recorded view. By calling the corresponding target view model according to the target timing information to replay the target recorded view in the target test case, time delay can be simulated, thereby ensuring that the playback process of the target test case is consistent with the recording process in terms of timing and view content.

[0096] Figure 6 A schematic diagram of the playback process in the application testing method provided in this application embodiment is shown. Figure 6 As shown, the playback process can be implemented through the Android system's playback controller (a device testing tool). It can read the target test cases in the test case dataset and send the target test cases to the recording playback view model via broadcast, so that the recording playback view model can respond.

[0097] In this embodiment, the target timing information includes first timing information reflecting the playback order among the target recorded views. Taking Table 1 as an example of the content after parsing the target test cases, the target recorded views obtained after parsing the target test cases include UI-2, UI-5, UI-6, UI-2, and UI-7 in sequence. During playback, the target recorded views need to be played back in the above order. The first timing information can be understood as indicating the order in which the above target recorded views start playing back according to specific time nodes.

[0098] Based on this, and using the target timing information, the target view model is invoked to replay the target recorded view. This can include: broadcasting the target view model identifier corresponding to the target recorded view to all view models in the target application based on the first timing information, so that each view model can determine whether to start playback after receiving the target view model identifier; after receiving feedback confirming the start of playback, the view model that returned the feedback information is taken as the target view model, and the target recorded view is replayed using the target view model. The target test case stores the target view model identifier. The application terminal can use the broadcast transmitter configured in the playback controller to broadcast the target view model identifier and the target recorded view to all view models (i.e., recording and playback view models) in the target application according to the first timing information. Each view model in the target application includes a broadcast receiver. All view models in the running target application will receive the broadcast. After receiving the broadcast, they can compare the target view model identifier with their own view model identifier to determine whether they should start playback. If the target view model identifier is the same as its own view model identifier, then the view model can be used as the target view model to play back the target recorded view corresponding to this broadcast. At the same time, the target view model can also send the confirmation of playback start to the broadcast transmitter in the playback controller.

[0099] Specifically, based on the first timing information, broadcasting the target view model identifier corresponding to the target recorded view to all view models of the target application may include: obtaining the current playback view that is currently in playback state; determining the next target recorded view in the next playback order of the current playback view based on the first timing information; determining the next target view model identifier corresponding to the next target recorded view based on the correspondence between the target view model identifier and the target recorded view; and broadcasting the next target view model identifier to all view models of the target application when the current playback view has finished playing.

[0100] Based on the aforementioned examples, if the current playback view is UI-5, then based on the first timing information, the next target recorded view in the playback order after UI-5 can be determined to be UI-6. Since the view model identifier corresponding to UI-6 is View-6, the next target view model identifier is View-6. When the application terminal detects that UI-5 has finished playing back, it can broadcast View-6 and UI-6 to all view models in the running target application. After receiving the broadcast, the view model identified as View-6 can play back UI-6. Similarly, after View-6 has finished playing back, it can broadcast View-2 and UI-2 to all view models in the running target application. After receiving the broadcast, the view model identified as View-2 can play back UI-2, and so on, until all target recorded views of the target test case have finished playing back.

[0101] The process of using the view model that returns feedback information as the target view model and then using that target view model to replay the target recorded view can include: using the view model that returns feedback information as the target view model for the next target recorded view; and starting the target view model to replay the next target recorded view. For example, in the above example, when the application terminal detects that UI-5 has finished playing back, it broadcasts View-6 and UI-6 to all view models in the running target application. After receiving the broadcast, the view model identified as View-6 returns feedback information to the application terminal. At this time, the application terminal uses the view model identified as View-6 as the target view model and directly starts the view model identified as View-6 to replay UI-6.

[0102] During the test case recording phase, each recorded view can include at least one view status identifier and corresponding status data. Correspondingly, during the test playback phase, for each target test case, each target recorded view can include at least one target status identifier and corresponding target status data. Furthermore, the target timing information can also include second timing information reflecting the playback order of the target status identifiers in the target recorded view. Taking Table 1 as an example of the parsed content of the target test cases, after parsing the target test cases, the resulting target recorded views sequentially include UI-2, UI-5, UI-6, UI-2, and UI-7. During playback, the target recorded views need to be played back in the above order. During the sequential playback, for each target recorded view, the target status identifiers and corresponding target status data must also be played back according to the timeline information of the recording phase. Therefore, the second timing information can be understood as indicating the order in which the target status data in each target recorded view begins playback according to specific time nodes.

[0103] Based on this, after broadcasting the target view model identifier corresponding to the target recording view to all view models of the target application based on the first time sequence information, it may further include: taking the target view model that is currently in the playback state as the current view model, and taking the target recording view corresponding to the current view model as the current playback view; sending a state update instruction to the current view model based on the second time sequence information, so that the current view model updates the target state data according to the target state identifier in the current playback view.

[0104] Based on the aforementioned examples, if the target view model currently in playback mode is View-6 (the current view model), then the corresponding target recording view for the current view model View-6 is UI-6 (the current playback view). Since the current playback view UI-6 includes three view states during the recording phase, which are UI-6B, UI-6C, and UI-6A in chronological order (second timing information), the application terminal can send status update instructions to the current view model View-6 sequentially according to the second timing information of the target status identifier during the playback of the current playback view UI-6. This allows the current view model to update the target status data according to the target status identifier in the current playback view.

[0105] Specifically, sending a state update instruction to the current view model based on the second time sequence information may include: taking the target state identifier currently in playback state as the current state identifier, and taking the target state data corresponding to the current state identifier as the current state data; determining the next target state identifier in the next playback order of the current state identifier based on the second time sequence information; determining the next target state data corresponding to the next target state identifier based on the correspondence between the target state identifier and the target state data; and sending a state update instruction to the current view model when the current state data playback is completed, so that the current view model can play back according to the next target state data.

[0106] Based on the aforementioned examples, for the current playback view UI-6, during the playback of the current playback view UI-6 using the current view model View-6, if the target state identifier currently in playback state is UI-6B (current state identifier), based on the second timing information, it can be determined that the next target state identifier in the playback order of the current state identifier UI-6B is UI-6C. After detecting that the state data of the current state identifier UI-6B has been played back, a state update command can be sent to the current view model View-6. After receiving the command, the current view model View-6 can update its state according to UI-6C so that the application terminal can play back the state data of UI-6C. After the playback of UI-6C is completed, the current view model View-6 can update its state according to UI-6A so that the application terminal can play back the state data of UI-6A.

[0107] The application testing method of this application is compared with traditional automated testing solutions, examples of which are as follows:

[0108] Espresso (an automated testing solution): Espresso is a UI testing framework officially released by Google, primarily used for UI testing of Android applications. Espresso provides an API to simulate user interactions, such as clicks and swipes, and can verify the state of UI elements. Espresso can run directly in Android Studio, and its synchronous mechanism can automatically handle asynchronous operations, such as network requests or database queries, making tests more stable. However, Espresso can only be used to test a single application and cannot perform cross-application testing. Furthermore, Espresso requires manually writing test cases, and writing Espresso test cases requires a certain understanding of the application's internal structure.

[0109] UI Automator (a UI testing framework): UI Automator is another testing framework provided by Google that can be used for cross-application UI testing. UI Automator provides various classes to simulate user actions and verify UI elements. However, UI Automator also requires manual writing of test cases, and its interface is not as intuitive as Espresso, so writing test cases may require more time and effort.

[0110] Appium (an automated testing framework): Appium is an open-source, cross-platform testing framework that supports automated testing on Android, macOS, and Microsoft systems. Appium uses the WebDriver protocol (an interface protocol), allowing test cases to be written in various programming languages. Appium has a relatively long startup time, which may affect testing efficiency. Furthermore, Appium only supports recording simple test case scripts.

[0111] As can be seen from the above, in this embodiment of the application, after receiving at least one recording instruction triggered by the recording object, the running view of the target application is recorded according to the recording instruction to obtain the recording content; then, the recording content is used as test cases, and the test case dataset of the target application is updated, wherein the test cases include at least one recording view, and each recording view corresponds to a view model in the target application; when a playback instruction triggered by the test object for the target application is received, the target test case specified by the test object is read from the test case dataset; then, the target recording view of the target test case is obtained, and the target view model corresponding to the target recording view is determined; then, the target timing information of the target recording view in the target test case is obtained, and based on the target timing information, the target view model is called to play back the target recording view. Because this solution utilizes the unique unidirectional data flow concept of the MVI architecture, test cases can be obtained directly from recording instructions during the target application's operation, eliminating the need for testers to manually write test cases. This enables a zero-code, no-code recording process. Furthermore, this solution can record at any point in the target application's operation, thus covering more application functions and scenarios in the test (such as special events that are difficult to test with traditional automated testing solutions, such as camera events). The testing method is highly flexible and has a wide range of applications.

[0112] Based on the method described in the above embodiments, the following examples will provide further detailed explanations.

[0113] In this embodiment, the application testing device will be specifically integrated into an electronic device, which may be an application terminal such as a smartphone, tablet computer, desktop computer, smart speaker, or smartwatch, and the application terminal has the target application installed as an example for illustration.

[0114] Figure 7 Another flowchart illustrating the application testing method provided in this application embodiment is shown. Figure 7 As shown, an application testing method has the following specific process:

[0115] 201. When the application terminal receives the start recording command triggered by the recording object, it takes the running view corresponding to the start recording command as the starting view and starts recording from the starting view.

[0116] For example, the application terminal can obtain the start recording time carried by the start recording command, take the running view of the target application displayed at the start recording time as the starting view; obtain the start status identifier corresponding to the start recording time in the start view, and the start status data corresponding to the start status identifier; and start recording by taking the start status identifier and start status data as the recording starting point.

[0117] 202. When the application terminal receives the end recording command triggered by the recording object, it takes the running view corresponding to the end recording command as the endpoint view and stops recording with the endpoint view as the recording endpoint, thus obtaining the recorded content.

[0118] For example, the application terminal can obtain the end recording time carried by the end recording command, take the running view of the target application displayed at the end recording time as the endpoint view; obtain the endpoint status identifier corresponding to the end recording time in the endpoint view, and the endpoint status data corresponding to the endpoint status identifier; stop recording by taking the endpoint status identifier and the endpoint status data as the recording endpoint, and obtain the recorded content.

[0119] 203. The application terminal uses the recorded content as test cases and updates the test case dataset of the target application.

[0120] For example, a test case includes at least one recorded view, each corresponding to a view model in the target application. The application terminal can obtain the transition view between the start view and the end view in the recorded content, and use the start view, transition view, and end view as recorded views; obtain the view model identifier corresponding to each recorded view, and combine the view model identifier and the recorded view to form a view data pair, with the recorded content including at least one view data pair; sort the view data pairs according to the timing information of the recording process to obtain test cases, and add the test cases to the test case dataset.

[0121] 204. When a replay instruction triggered by the test object for the target application is received, the application terminal reads the target test case specified by the test object from the test case dataset.

[0122] For example, the test case dataset can be located in a specified location within a database, such as in folders like Android Studio (an integrated development environment for Android systems) or Androidtest / assets (an application resource manager for Android systems). The test object can trigger a replay command using Android's UI testing tools, and the application terminal can then read the corresponding test cases from the test case dataset as target test cases for replay.

[0123] 205. The application terminal obtains the target recording view of the target test case and determines the target view model corresponding to the target recording view.

[0124] For example, the application terminal can extract target view data pairs from the target test cases. The target view data pairs include target view model identifiers and target recording views, with each target view model identifier corresponding to a target recording view. Based on the target view model identifiers, the target view model corresponding to the target recording view is determined.

[0125] 206. The application terminal obtains the target timing information of the target recorded view in the target test case, and calls the target view model to replay the target recorded view based on the target timing information.

[0126] For example, the target timing information includes first timing information reflecting the playback order among the target recorded views. Based on the first timing information, the application terminal can broadcast the target view model identifier corresponding to the target recorded view to all view models of the target application, so that each view model can determine whether to start playback after receiving the target view model identifier; after receiving feedback information confirming the start of playback, the view model that returned the feedback information is taken as the target view model, and the target view model is used to play back the target recorded view.

[0127] For example, the application terminal can obtain the current playback view that is in playback state at the current moment, determine the next target recording view in the next playback order of the current playback view based on the first timing information; determine the next target view model identifier corresponding to the next target recording view based on the correspondence between the target view model identifier and the target recording view; and broadcast the next target view model identifier to all view models of the target application when the current playback view has finished playing.

[0128] For example, each target recording view may include at least one target status identifier and target status data corresponding to the target status identifier. The target timing information may also include second timing information reflecting the playback order among the various target status identifiers in the target recording view. The application terminal can use the target view model currently in playback state as the current view model and the target recording view corresponding to the current view model as the current playback view. Based on the second timing information, a status update command is sent to the current view model so that the current view model updates the target status data according to the target status identifier in the current playback view.

[0129] For example, the application terminal can use the target status identifier that is currently in playback as the current status identifier, and the target status data corresponding to the current status identifier as the current status data; based on the second timing information, determine the next target status identifier that is in the next playback order of the current status identifier; based on the correspondence between the target status identifier and the target status data, determine the next target status data corresponding to the next target status identifier; and when the current status data playback is completed, send a status update instruction to the current view model so that the current view model can play back according to the next target status data.

[0130] As described above, when the application terminal receives a start recording command triggered by the recording object, it takes the running view corresponding to the start recording command as the starting view and starts recording from the starting view. When it receives a stop recording command triggered by the recording object, it takes the running view corresponding to the stop recording command as the ending view and stops recording from the ending view, thus obtaining the recorded content. Then, the application terminal uses the recorded content as test cases and updates the test case dataset of the target application. Each test case includes at least one recording view, and each recording view corresponds to a view model in the target application. When the application terminal receives a playback command triggered by the test object for the target application, it reads the target test case specified by the test object from the test case dataset. After that, the application terminal obtains the target recording view of the target test case and determines the target view model corresponding to the target recording view. The application terminal then obtains the target timing information of the target recording view in the target test case and, based on the target timing information, calls the target view model to play back the target recording view. Because this solution utilizes the unique unidirectional data flow concept of the MVI architecture, test cases can be obtained directly from recording instructions during the target application's operation, eliminating the need for testers to manually write test cases. This enables a zero-code, no-code recording process. Furthermore, this solution can record at any point in the target application's operation, thus covering more application functions and scenarios in the test (such as special events that are difficult to test with traditional automated testing solutions, such as camera events). The testing method is highly flexible and has a wide range of applications.

[0131] To better implement the above methods, this application embodiment also provides an application testing device, which can be integrated into network devices, such as application terminals, etc. The terminal may include smartphones, tablets, desktop computers, smart speakers, smartwatches, etc.

[0132] Figure 8 A schematic diagram of the application testing device provided in an embodiment of this application is shown. Figure 8 As shown, the application testing device may include a recording unit 301, an updating unit 302, a reading unit 303, a parsing unit 304, and a playback unit 305, as follows:

[0133] (1) Recording unit 301;

[0134] The recording unit 301 is used to receive at least one recording instruction triggered by the recording object during the operation of the target application, record the running view of the target application according to the recording instruction, and obtain the recording content.

[0135] For example, the recording unit 301 can be used to obtain the start recording time carried by the start recording command, and use the running view displayed at the start recording time as the starting view for the target application; obtain the start status identifier corresponding to the start recording time and the start status data corresponding to the start status identifier in the start view; and start recording by using the start status identifier and the start status data as the recording starting point.

[0136] The recording unit 301 can be specifically used to obtain the end recording time carried by the end recording command, use the running view displayed at the end recording time as the endpoint view; obtain the endpoint status identifier corresponding to the end recording time and the endpoint status data corresponding to the endpoint status identifier in the endpoint view; stop recording by using the endpoint status identifier and the endpoint status data as the recording endpoint, and obtain the recording content.

[0137] (2) Update unit 302;

[0138] The update unit 302 is used to use the recorded content as test cases and update the test case dataset of the target application. The test cases include at least one recorded view, and each recorded view corresponds to a view model in the target application.

[0139] For example, update unit 302 can be used to obtain the transition view between the start view and the end view in the recording content, and use the start view, transition view and end view as the recording view; obtain the view model identifier corresponding to each recording view, and combine the view model identifier and the recording view to form a view data pair, and the recording content includes at least one view data pair; sort the view data pairs according to the timing information of the recording process to obtain test cases, and add the test cases to the test case dataset.

[0140] The update unit 302 can be used to obtain the view state identifier contained in each recorded view and the state data corresponding to each view state identifier. The view state identifier is used to drive the target application to update the interface according to the state data. The view model identifier, view state identifier and state data are combined into view data pairs.

[0141] (3) Reading unit 303;

[0142] The reading unit 303 is used to read the target test case specified by the test object from the test case dataset when it receives a replay instruction triggered by the test object for the target application.

[0143] (4) Analysis Unit 304;

[0144] The parsing unit 304 is used to obtain the target recording view of the target test case and determine the target view model corresponding to the target recording view.

[0145] For example, the parsing unit 304 can be used to extract target view data pairs from target test cases. The target view data pairs include target view model identifiers and target recording views, with each target view model identifier corresponding to a target recording view. Based on the target view model identifier, the target view model corresponding to the target recording view is determined.

[0146] (5) Playback unit 305;

[0147] The playback unit 305 is used to obtain the target timing information of the target recorded view in the target test case, and to call the target view model to play back the target recorded view based on the target timing information.

[0148] For example, the playback unit 305 can be used to broadcast the target view model identifier corresponding to the target recorded view to all view models of the target application based on the first timing information, so that each view model can determine whether to start playback after receiving the target view model identifier; after receiving the feedback information confirming the start of playback, the view model that returned the feedback information is used as the target view model, and the target recorded view is played back using the target view model.

[0149] The playback unit 305 can be used to obtain the current playback view that is in playback state at the current moment, determine the next target recording view in the next playback order of the current playback view based on the first timing information, determine the next target view model identifier corresponding to the next target recording view based on the correspondence between the target view model identifier and the target recording view, and broadcast the next target view model identifier to all view models of the target application when the current playback view has finished playing.

[0150] The playback unit 305 can be used to use the view model that returns feedback information as the target view model corresponding to the next target recording view; and to start the target view model to play back the next target recording view.

[0151] The playback unit 305 can be used to take the target view model that is currently in playback state as the current view model, and take the target recording view corresponding to the current view model as the current playback view; based on the second time sequence information, send a state update instruction to the current view model so that the current view model updates the target state data according to the target state identifier in the current playback view.

[0152] The playback unit 305 is specifically used to take the target state identifier that is currently in playback state as the current state identifier and the target state data corresponding to the current state identifier as the current state data; determine the next target state identifier in the next playback order of the current state identifier based on the second time sequence information; determine the next target state data corresponding to the next target state identifier based on the correspondence between the target state identifier and the target state data; and send a state update instruction to the current view model when the current state data playback is completed, so that the current view model can play back according to the next target state data.

[0153] In practice, each of the above units can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units, please refer to the previous method embodiments, which will not be repeated here.

[0154] As can be seen from the above, in this embodiment of the application, after the recording unit 301 receives at least one recording instruction triggered by the recording object, it records the running view of the target application according to the recording instruction to obtain the recording content; then, the updating unit 302 uses the recording content as test cases and updates the test case dataset of the target application, wherein the test cases include at least one recording view, and each recording view corresponds to a view model in the target application; when a playback instruction triggered by the test object for the target application is received, the reading unit 303 reads the target test case specified by the test object from the test case dataset; then, the parsing unit 304 obtains the target recording view of the target test case and determines the target view model corresponding to the target recording view; the playback unit 305 then obtains the target timing information of the target recording view in the target test case, and calls the target view model to play back the target recording view based on the target timing information. Because this solution utilizes the unique unidirectional data flow concept of the MVI architecture, test cases can be obtained directly from recording instructions during the target application's operation, eliminating the need for testers to manually write test cases. This enables a zero-code, no-code recording process. Furthermore, this solution can record at any point in the target application's operation, thus covering more application functions and scenarios in the test (such as special events that are difficult to test with traditional automated testing solutions, such as camera events). The testing method is highly flexible and has a wide range of applications.

[0155] This application also provides an electronic device, such as... Figure 9 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically:

[0156] The electronic device may include components such as a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, a power supply 403, and an input unit 404. Those skilled in the art will understand that... Figure 9 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. Wherein:

[0157] The processor 401 is the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes software programs and / or modules stored in the memory 402, and calls data stored in the memory 402, to perform various functions and process data. Optionally, the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 401.

[0158] The memory 402 can be used to store software programs and modules. The processor 401 executes various functional applications and data processing by running the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 402 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 402 may also include a memory controller to provide the processor 401 with access to the memory 402.

[0159] The electronic device also includes a power supply 403 that supplies power to the various components. Preferably, the power supply 403 can be logically connected to the processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 403 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.

[0160] The electronic device may also include an input unit 404, 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.

[0161] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 401 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 402 according to the following instructions, and the processor 401 runs the applications stored in the memory 402 to realize various functions, as follows:

[0162] Upon receiving at least one recording instruction triggered by the recording object, the system records the running view of the target application according to the recording instruction to obtain the recorded content. Then, the recorded content is used as test cases, and the test case dataset of the target application is updated. Each test case includes at least one recorded view, and each recorded view corresponds to a view model in the target application. When a playback instruction triggered by the test object for the target application is received, the target test case specified by the test object is read from the test case dataset. Then, the target recorded view of the target test case is obtained, and the target view model corresponding to the target recorded view is determined. Next, the target timing information of the target recorded view in the target test case is obtained, and based on the target timing information, the target view model is called to play back the target recorded view.

[0163] For example, an electronic device can receive a start recording command triggered by a recording object, use the running view corresponding to the start recording command as the starting view, and start recording with the starting view as the recording start point; upon receiving a stop recording command triggered by the recording object, use the running view corresponding to the stop recording command as the ending view, and stop recording with the ending view as the recording end point, thus obtaining the recorded content; then, the electronic device uses the recorded content as test cases and updates the test case dataset of the target application, wherein each test case includes at least one recording view, and each recording view corresponds to a view model in the target application; when a playback command is received from the test object for the target application, the electronic device reads the target test case specified by the test object from the test case dataset; then, the electronic device obtains the target recording view of the target test case and determines the target view model corresponding to the target recording view; the electronic device then obtains the target timing information of the target recording view in the target test case, and based on the target timing information, calls the target view model to play back the target recording view, and so on.

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

[0165] As can be seen from the above, in this embodiment of the application, after receiving at least one recording instruction triggered by the recording object, the running view of the target application is recorded according to the recording instruction to obtain the recording content; then, the recording content is used as test cases, and the test case dataset of the target application is updated, wherein the test cases include at least one recording view, and each recording view corresponds to a view model in the target application; when a playback instruction triggered by the test object for the target application is received, the target test case specified by the test object is read from the test case dataset; then, the target recording view of the target test case is obtained, and the target view model corresponding to the target recording view is determined; then, the target timing information of the target recording view in the target test case is obtained, and based on the target timing information, the target view model is called to play back the target recording view. Because this solution utilizes the unique unidirectional data flow concept of the MVI architecture, test cases can be obtained directly from recording instructions during the target application's operation, eliminating the need for testers to manually write test cases. This enables a zero-code, no-code recording process. Furthermore, this solution can record at any point in the target application's operation, thus covering more application functions and scenarios in the test (such as special events that are difficult to test with traditional automated testing solutions, such as camera events). The testing method is highly flexible and has a wide range of applications.

[0166] 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.

[0167] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the application testing methods provided in embodiments of this application. For example, the instructions can execute the following steps:

[0168] Upon receiving at least one recording instruction triggered by the recording object, the system records the running view of the target application according to the recording instruction to obtain the recorded content. Then, the recorded content is used as test cases, and the test case dataset of the target application is updated. Each test case includes at least one recorded view, and each recorded view corresponds to a view model in the target application. When a playback instruction triggered by the test object for the target application is received, the target test case specified by the test object is read from the test case dataset. Then, the target recorded view of the target test case is obtained, and the target view model corresponding to the target recorded view is determined. Next, the target timing information of the target recorded view in the target test case is obtained, and based on the target timing information, the target view model is called to play back the target recorded view.

[0169] For example, upon receiving a start recording command triggered by a recording object, the running view corresponding to the start recording command is used as the starting view, and recording begins with the starting view as the recording start point. Upon receiving a stop recording command triggered by a recording object, the running view corresponding to the stop recording command is used as the ending view, and recording stops with the ending view as the recording end point, thus obtaining the recorded content. Then, the recorded content is used as test cases, and the test case dataset of the target application is updated. Each test case includes at least one recording view, and each recording view corresponds to a view model in the target application. When a playback command is received from a test object for the target application, the target test case specified by the test object is read from the test case dataset. Then, the target recording view of the target test case is obtained, and the target view model corresponding to the target recording view is determined. Next, the target timing information of the target recording view in the target test case is obtained, and based on the target timing information, the target view model is called to play back the target recording view, and so on.

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

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

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

[0173] According to one aspect of this application, a computer program product or computer program is 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 alternative implementations of the data access aspect described above.

[0174] The above provides a detailed description of an application testing method, apparatus, and computer-readable storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. An application testing method, characterized in that, include: Upon receiving at least one recording instruction triggered by the recording object, the running view of the target application is recorded according to the recording instruction to obtain the recording content; The recorded content is used as test cases, and the test case dataset of the target application is updated. Each test case includes at least one recorded view, and each recorded view corresponds to a view model in the target application. When a replay instruction is received from the test object for the target application, the target test case specified by the test object is read from the test case dataset; Obtain the target recording view of the target test case, and determine the target view model corresponding to the target recording view; Obtain the target timing information of the target recorded view in the target test case, and based on the target timing information, call the target view model to replay the target recorded view.

2. The application testing method as described in claim 1, characterized in that, The recording instructions include a start recording instruction and a stop recording instruction. The recording of the running view of the target application according to the recording instructions, to obtain the recorded content, includes: Use the running view corresponding to the start recording command as the starting view, and start recording with the starting view as the recording starting point; The running view corresponding to the end recording command is used as the endpoint view, and recording is stopped with the endpoint view as the recording endpoint, thus obtaining the recorded content.

3. The application testing method as described in claim 2, characterized in that, The target application includes multiple application views, each of which includes at least one view status identifier and status data corresponding to the view status identifier. The status data indicates the interface display status under the view status identifier. The step of using the running view corresponding to the start recording command as the starting view and starting recording with the starting view as the recording starting point includes: Obtain the start recording time carried by the start recording command, and use the running view displayed at the start recording time as the starting view for the target application; Obtain the start status identifier corresponding to the start recording time in the start view, and the start status data corresponding to the start status identifier; The recording is started by using the starting state identifier and the starting state data as the starting point.

4. The application testing method as described in claim 3, characterized in that, The step of using the running view corresponding to the end recording command as the endpoint view, and stopping recording with the endpoint view as the recording endpoint, to obtain the recorded content includes: Obtain the end recording time carried by the end recording instruction, and use the running view displayed at the end recording time as the endpoint view; Obtain the endpoint status identifier corresponding to the end recording time in the endpoint view, and the endpoint status data corresponding to the endpoint status identifier; The recording is stopped by using the endpoint status identifier and the endpoint status data as the recording endpoint, and the recording content is obtained.

5. The application testing method as described in any one of claims 1-4, characterized in that, The step of using the recorded content as test cases and updating the test case dataset of the target application includes: Obtain the transition view located between the starting view and the ending view in the recorded content, and use the starting view, the transition view, and the ending view as the recorded view; Obtain the view model identifier corresponding to each recorded view, and combine the view model identifier and the recorded view to form a view data pair, wherein the recorded content includes at least one of the view data pairs; The test cases are obtained by sorting the view data pairs according to the timing information of the recording process, and then the test cases are added to the test case dataset.

6. The application testing method as described in claim 5, characterized in that, The step of combining the view model identifier and the recorded view to form a view data pair includes: Obtain the view state identifier contained in each of the recorded views, and the state data corresponding to each of the view state identifiers. The view state identifier is used to drive the target application to update the interface according to the state data. The view model identifier, the view state identifier, and the state data are combined into the view data pair.

7. The application testing method as described in claim 1, characterized in that, Determining the target view model corresponding to the target recording view includes: Extract target view data pairs from the target test cases. Each target view data pair includes a target view model identifier and a target recording view, with each target view model identifier corresponding to one target recording view. Based on the target view model identifier, the target view model corresponding to the target recording view is determined.

8. The application testing method as described in claim 7, characterized in that, The target timing information includes first timing information reflecting the playback order between the target recorded views. The step of replaying the recorded view of the target by calling the target view model based on the target time series information includes: Based on the first timing information, the target view model identifier corresponding to the target recording view is broadcast to all view models of the target application, so that each view model can determine whether to start playback after receiving the target view model identifier; Upon receiving feedback confirming the start of playback, the view model that returned the feedback information is used as the target view model, and the target recorded view is played back using the target view model.

9. The application testing method as described in claim 8, characterized in that, The step of broadcasting the target view model identifier corresponding to the target recorded view to all view models of the target application based on the first timing information includes: Obtain the current playback view that is in playback state at the current moment, and determine the next target recording view that is in the next playback order of the current playback view based on the first timing information; Based on the correspondence between the target view model identifier and the target recording view, determine the next target view model identifier corresponding to the next target recording view; Once the current playback view is detected to have finished playing, the identifier of the next target view model is broadcast to all view models of the target application.

10. The application testing method as described in claim 9, characterized in that, Each target recording view includes at least one target status identifier and target status data corresponding to the target status identifier. The target timing information also includes second timing information reflecting the playback order among the various target status identifiers in the target recording view. After broadcasting the target view model identifier corresponding to the target recorded view to all view models of the target application based on the first timing information, the method further includes: The target view model currently in playback mode is taken as the current view model, and the target recording view corresponding to the current view model is taken as the current playback view; Based on the second timing information, a state update instruction is sent to the current view model so that the current view model updates the target state data according to the target state identifier in the current playback view.

11. The application testing method as described in claim 10, characterized in that, The step of sending a state update instruction to the current view model based on the second timing information includes: The target status identifier that is currently in playback state is used as the current status identifier, and the target status data corresponding to the current status identifier is used as the current status data; Based on the second timing information, determine the next target state identifier that is in the next playback order of the current state identifier; Based on the correspondence between the target state identifier and the target state data, the next target state data corresponding to the next target state identifier is determined; Once the playback of the current state data is complete, a state update instruction is sent to the current view model so that the current view model can play back the data according to the next target state data.

12. An application testing device, characterized in that, include: The recording unit is used to receive at least one recording instruction triggered by the recording object during the operation of the target application, record the running view of the target application according to the recording instruction, and obtain the recording content. An update unit is used to use the recorded content as a test case and update the test case dataset of the target application. The test case includes at least one recorded view, and each recorded view corresponds to a view model in the target application. The reading unit is used to read the target test case specified by the test object from the test case dataset when a playback instruction triggered by the test object for the target application is received. The parsing unit is used to obtain the target recording view of the target test case and determine the target view model corresponding to the target recording view; The playback unit is used to obtain the target timing information of the target recorded view in the target test case, and based on the target timing information, call the target view model to play back the target recorded view.

13. An electronic device, characterized in that, It includes a processor and a memory, the memory storing an application program, and the processor running the application program within the memory to perform the steps of the application testing method according to any one of claims 1 to 11.

14. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the application testing method according to any one of claims 1 to 11.

15. 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 application testing method according to any one of claims 1 to 11.

Images