Front-end application testing method, device, terminal equipment and storage medium

Abstract

The present application is applicable to the field of R&D management technology, and provides a front-end application testing method, apparatus, terminal equipment and storage medium, wherein a front-end application testing method is provided, wherein the component information of each front-end component in the front-end application file is identified, wherein the component information includes the location information and script file of the front-end component, and the location information is the storage path of the front-end component stored under the front-end application file; according to the location information of each front-end component, a test node corresponding to each front-end component is generated, and the script file is configured on the test node; exception information is injected into the script file on each test node to obtain a test front-end application file; when the test front-end application file is run, the test result generated by the test front-end application file is obtained. It is convenient for users to obtain the test front-end application file by injecting exception information into the test node, and can quickly obtain the test result generated by the test front-end application file when the exception occurs.

Description

Technical Field

[0001] The present application relates to the field of R&D management technology, and in particular to a front-end application testing method, apparatus, terminal equipment, and storage medium. Background Art

[0002] Currently, back-end chaos engineering tools simulate a series of system, service call, or network anomalies, randomly injecting them into back-end distributed systems to observe the system's response. However, the front-end interface, which is the user's direct entry point—the front-end component—is not tested using any tools. This leads to users encountering a variety of issues while using front-end applications, such as blank screens or even application crashes. Therefore, while existing technologies only test the back-end systems of front-end applications, they lack a specific testing solution for the front-end applications themselves, making it impossible to proactively test for any anomalies that may arise during use. Summary of the Invention

[0003] In view of this, the embodiments of the present application provide a front-end application testing method, apparatus, terminal device and computer-readable storage medium to solve the problem that there is no testing solution for front-end applications in the prior art and it is impossible to test in advance the abnormal conditions that may occur during the use of the front-end application.

[0004] A first aspect of an embodiment of the present application provides a front-end application testing method, comprising:

[0005] Identify component information of each front-end component in the front-end application file; wherein the component information includes location information and script files of the front-end component, and the location information is the storage path where the front-end component is stored under the front-end application file;

[0006] Generate a test node corresponding to each front-end component according to the location information of each front-end component, and configure the script file on the test node;

[0007] Injecting exception information into the script file on each test node to obtain a test front-end application file;

[0008] When the test front-end application file is run, a test result generated by the test front-end application file is obtained.

[0009] In one embodiment, before generating the test node corresponding to each front-end component according to the location information of each front-end component, the method further includes:

[0010] Obtaining a chaos tool and storing the chaos tool in the installation directory of the front-end application file;

[0011] Run the chaos tool to identify each front-end component of the front-end application file in the installation directory, and generate each test node accordingly.

[0012] In one embodiment, after generating the test node corresponding to each front-end component according to the location information of each front-end component, the method further includes:

[0013] Obtaining and sequentially generating dependency relationships between each of the test nodes according to the location information of each front-end component;

[0014] According to the dependency relationship between each of the test nodes, a test node tree is generated for each of the test nodes.

[0015] In one embodiment, the chaos tool includes a plurality of abnormal information, each abnormal information having a corresponding initial weight value;

[0016] The injecting of exception information into the script file on each test node to obtain a test front-end application file includes:

[0017] In the test node tree, a target node is correspondingly identified, where the target node is a node generated by the chaos tool when it identifies multiple front-end components in the same installation directory;

[0018] Randomly obtaining the abnormal information among the plurality of abnormal information according to the initial weight value;

[0019] The exception information is injected into the script file corresponding to the target node to obtain the test front-end application file.

[0020] In one embodiment, after obtaining the test result generated by the test front-end application file when the test front-end application file is executed, the method further includes:

[0021] Receive modification instructions issued by the tester based on the test results;

[0022] Modify the initial weight value of the abnormal information according to the modification instruction;

[0023] Randomly injecting the abnormal information into the script file corresponding to the target node according to the modified initial weight value among the plurality of abnormal information;

[0024] Acquire test results generated by the front-end application when the exception occurs multiple times, and modify the script file corresponding to the target node according to the test results.

[0025] In one embodiment, the exception information includes exceptions, exception capture functions, and exception injection functions;

[0026] Before obtaining the test result generated by the test front-end application file when the test front-end application file is run, the method further includes:

[0027] Receive an injection instruction, wherein the injection instruction is used to inject the exception and the exception capture function into the script file corresponding to the target node according to the exception injection function in the exception information, and generate the test front-end application file;

[0028] Run the test front-end application file, and when the exception occurs, capture the script file corresponding to the exception according to the exception capture function.

[0029] In one embodiment, after obtaining the test result generated by the test front-end application file when the test front-end application file is executed, the method includes:

[0030] Stop running the test front-end application file;

[0031] Obtaining a preset processing solution, and resolving the test result according to the processing solution;

[0032] After resolving the test results, the test results are uploaded to the blockchain and the test front-end application file continues to run.

[0033] A second aspect of an embodiment of the present application provides a front-end application testing device, comprising:

[0034] An identification module, configured to identify component information of each front-end component in a front-end application file; wherein the component information includes location information and a script file of the front-end component, and the location information is a storage path where the front-end component is stored under the front-end application file;

[0035] A first generating module is configured to generate a test node corresponding to each front-end component according to the location information of each front-end component, and configure the script file on the test node;

[0036] A first injection module is used to inject abnormal information into the script file on each test node to obtain a test front-end application file;

[0037] The first acquisition module is used to acquire the test results generated by the test front-end application file when the test front-end application file is run.

[0038] The fourth aspect of an embodiment of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the terminal device. When the processor executes the computer program, the steps of the front-end application testing method provided by the first solution are implemented.

[0039] A fifth aspect of an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of the front-end application testing method provided by the first solution.

[0040] The front-end application testing method, apparatus, terminal device, and computer-readable storage medium provided by the embodiments of the present application have the following beneficial effects:

[0041] The present invention provides a front-end application testing method that identifies component information in a front-end application file, generates a test node for each front-end component, and configures a script file into the test node, allowing the test user to visually observe each front-end component. This method also facilitates the user to inject exception information into the test node to obtain the test front-end application file, improving the efficiency of the test user's injection of exception information and allowing the user to quickly obtain the test results generated by the test front-end application file when an exception occurs. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0043] Figure 1 This is a flowchart of an implementation of a front-end application testing method provided in an embodiment of the present application;

[0044] Figure 2 This is a flowchart of an implementation of a front-end application testing method provided by another embodiment of the present application;

[0045] Figure 3 This is a flowchart of a front-end application testing method provided in another embodiment of the present application;

[0046] Figure 4 This is a flowchart of an implementation of a front-end application testing method provided by another embodiment of the present application;

[0047] Figure 5 This is a structural block diagram of a front-end application testing device provided in an embodiment of the present application;

[0048] Figure 6 This is a structural block diagram of a terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solutions and advantages of this application more clearly understood, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0050] The front-end application testing method involved in the embodiment of the present application can be executed by a control device or terminal (hereinafter referred to as a "mobile terminal").

[0051] See also Figure 1 , Figure 1 A flow chart illustrating an implementation of a front-end application testing method provided in an embodiment of the present application is shown.

[0052] S101. Identify component information of each front-end component in a front-end application file; wherein the component information includes location information and a script file of the front-end component, and the location information is a storage path in which the front-end component is stored under the front-end application file.

[0053] In the application, the above-mentioned front-end application file is used to generate a front-end application, and the corresponding front-end application generated can be a web page application software or an application software on a mobile terminal. It has function buttons that can be operated by the test user, that is, the front-end application has a function entrance (front-end page) that directly faces the test user. Exemplarily, the desktop (computer desktop) on the mobile terminal has a front-end application software. By clicking on the front-end application software, the mobile terminal can load the web front-end application interface and load the required front-end application interface on the web front-end application interface, that is, the front-end page. At present, the front-end page of the web application software is basically implemented by Vue (a progressive framework for building user interfaces) or React framework (a framework for creating interactive user interfaces). However, the basis of the front-end page implemented by Vue or React framework is to use a series of nested components. It can be understood that the front-end page is composed of multiple executable front-end components in the front-end application file. When the front-end application interface is loaded, the executable operation function buttons and display pages are generated according to the executable front-end components. Among them, the language file can be generated by JavaScript language, which is an object-based and event-driven client-side scripting language with relative security. It is also a scripting language widely used in web applications. It is often used to add dynamic functions to HTML web applications and respond to various operations of test users.

[0054] In applications, front-end application files downloaded by mobile terminals are generally stored in the mobile terminal's database (the computer's storage hard drive). This database contains script files for each front-end component in the front-end application file. These script files can be considered files containing code information, while the files displayed on the mobile terminal's desktop can be understood as a convenient way to use the front-end application files on the mobile terminal.

[0055] S102: Generate a test node corresponding to each front-end component according to the location information of each front-end component, and configure the script file on the test node.

[0056] In the application, after generating the test node corresponding to each front-end component, the generation tool can obtain the storage path (location information) of each front-end component stored under the front-end application file, and the storage paths corresponding to each front-end component have corresponding connections and hierarchical relationships with each other. A recursive program can be pre-stored inside the generation tool, which can establish a node and add the node object (corresponding script file) to the node after reading the corresponding stored location information. If there are other front-end components under the storage path, the program can establish nodes one by one again. In actual situations, the test user himself does not know whether there is the next test node under a certain test node, and the recursive program will call itself cyclically during operation, recursively adding test nodes one by one.

[0057] Exemplarily, for a hypertext markup language document (front-end application component), it can be used as a document node (root test node), and each hypertext markup language tag contained in this document can be considered as a tag node (next-level test node), and the front-end component contained in the hypertext markup language tag is a text node (next-level test node), until each hypertext markup language attribute is an attribute node (bottom-level test node). Because each front-end component in the front-end application file is stored in the same or different levels of installation location, the corresponding generated test node can be considered as a collection of multiple test nodes with a hierarchical relationship. Among them, the generated test node can be used to configure the corresponding script file, and is visually displayed on the operation interface of the mobile terminal. The test user can find the corresponding configured script file by clicking on the test node.

[0058] S103: Inject exception information into the script file on each test node to obtain a test front-end application file.

[0059] In the application, the above-mentioned exception information is used to cause the corresponding script file to generate an exception during runtime. The exception information includes an exception, which can be a preset section of code that can be set according to actual needs. For the exception information, a new script file containing the exception can be pre-defined within it, which contains the code corresponding to the exception, the logical processing of the exception (capture processing, response processing), and the parameter value of the original script file that can point to the return test node. The new script file can obtain the parameter value during runtime and point to the original script file for execution based on the parameter value, realizing all the corresponding functions of the original script file and the corresponding functions that occur when the exception is executed. Then, the exception information is injected into the script file, and the script file is encapsulated to generate a test front-end application component. For example, a null pointer exception that may cause the front-end application file to crash during runtime can be represented by "NULLPOINTEREXCEPTION". After injecting this code into the script file in the test node, the corresponding script file can be modified to generate a test front-end application file containing the modified script file. In the application, there are multiple test nodes as mentioned above, and there are also multiple corresponding script files. The same or different exception information can be injected into all nodes at the same time to test the test front-end application file. The same or different exception information can also be injected into multiple specified script files, or multiple different exception information can be injected into a specified script file at the same time. There is no limitation on this.

[0060] S104: When the test front-end application file is run, a test result generated by the test front-end application file is obtained.

[0061] In the application, after running the test front-end application file, the script file containing the exception information will also execute the code information corresponding to the injected exception when it is called and executed, thereby causing the front-end application file to produce the corresponding exception result, which is the test result of the test front-end application file.

[0062] In the application, when an exception occurs, the test results generated by the test front-end application need to be observed. However, when faced with a front-end application file that has multiple exception information injected at the same time, there are many specific implementation scenarios for the front-end application file. If each implementation scenario is manually operated, the workload of the test user is increased. And if there are too many implementation scenarios, the test user may miss the test. Therefore, the tester can pre-set the instructions for the front-end application software to automatically simulate the implementation scenario, reducing the operating steps of the test user. For front-end application files that need to be injected with less exception information, the corresponding specific implementation scenarios of the front-end application files are few and simple, so the tester can directly perform manual operations on the front-end page to conduct the test, and there is no limitation on this.

[0063] As can be seen from the above, this embodiment provides a front-end application testing method that identifies component information in a front-end application file, generates a test node for each front-end component, and configures a script file into the test node, allowing the test user to intuitively visualize each front-end component. This method also facilitates the user to inject exception information into the test node to obtain the test front-end application file, improving the efficiency of the test user's injection of exception information and allowing the user to quickly obtain the test results generated by the test front-end application file when an exception occurs.

[0064] See also Figure 2 , Figure 2 This is a flow chart of a front-end application testing method provided by another embodiment of the present application. Figure 1 In a corresponding embodiment, the front-end application testing method provided in this embodiment further includes steps S201 to S202 before step S102, wherein step S101 and steps S201 to S202 are executed in no particular order. Detailed description is as follows:

[0065] S201. Obtain a chaos tool and store the chaos tool in the installation directory of the front-end application file.

[0066] In applications, chaos engineering involves randomly injecting faults to observe how the software system reacts, thereby understanding its vulnerabilities. Before these faults impact test users, a series of measures can be implemented to improve the system's resilience and protect against unknown risks. The tool used to perform chaos engineering experiments is the chaos tool. The installation directory is the storage path where the front-end application files are stored on the mobile terminal. Mobile terminals can download the chaos tool to the installation directory using the npm install method and run it using the npm run chaosXXX command. The "npm install" command includes: npm install moduleName# installs the module to the project directory (installation directory); npm install -g moduleName# -g installs the module globally; the specific disk location depends on the location of the npm configprefix; npm install --save moduleName# --save installs the module to the project directory and adds the dependencies to the dependencies node of the package file; npm install --save-dev moduleName# --save-dev installs the module to the project directory and adds the dependencies to the devDependencies node of the package file.

[0067] S202. Run the chaos tool to identify each front-end component of the front-end application file in the installation directory, and generate each test node accordingly.

[0068] In applications, the Chaos tool traverses front-end application files, retrieves each front-end component based on the traversal, and then generates test nodes. The Chaos tool includes code-generated instructions for npm run chaosXXX. Enter these instructions in the control interface of the application under test, and the operating system on the terminal device will automatically call the installed Chaos tool to execute the executable file configured in package.json, effectively running the Chaos tool in the installation directory. The code-generated instructions for npm run chaosXXX are pre-associated with the Chaos tool. During runtime, the Chaos tool traverses and identifies each front-end component in the front-end application file to generate test nodes.

[0069] In this embodiment, the chaos tool is downloaded to generate test nodes for each front-end component in the front-end application file and perform tests. Compared with the system test corresponding to the existing front-end application file, the test is only reflected in the server side of the front-end application system. This embodiment is more purposeful and has higher testing efficiency. It can obtain a stable system corresponding to the front-end application file for the test user more quickly.

[0070] In one embodiment, after S102, the method further includes:

[0071] According to the location information of each front-end component, the dependency relationship between each of the test nodes is obtained and generated in sequence.

[0072] According to the dependency relationship between each of the test nodes, a test node tree is generated for each of the test nodes.

[0073] In the application, the above dependency relationship can be a parallel dependency relationship when multiple front-end components are saved in the same folder, a parent-child dependency relationship when the folder corresponding to a front-end component contains other front-end components, etc., and there is no limitation on this.

[0074] For example, for the front-end components B, C, and D of the front-end application components under the A installation directory, if the B1 folder under the A installation directory contains the B front-end component, and the C1 folder contains the C front-end component, and the D front-end component is in the same installation node as the B1 folder and the C1 folder. The chaos tool will identify the installation nodes corresponding to these front-end components and generate a test node tree, that is, the root node of the test node tree is the A installation directory, and then the next layer of test nodes are the B1 test node formed by all the front-end components contained in the B1 folder, the C1 test node formed by all the front-end components contained in the C folder, and the D node formed by the D front-end component. The next layer of the B1 test node has the B test node corresponding to the B front-end component, and the next layer of the C1 test node is the C test node corresponding to the C front-end component. Among them, the script files corresponding to each test node can be used to inject script information.

[0075] In applications, the Chaos tool can also scan all folders containing front-end components under installation directory A and identify all front-end components and their interdependencies within each folder through keyword matching and semantic analysis. All front-end components are then assembled according to their dependencies, forming a complete test node tree. For example, in installation directory A, by matching certain keywords, such as "import" or "commponent," suspected front-end component lines containing these keywords are found. This front-end component line is then segmented according to its terms. For example, "I love apple" can be divided into three words. Keyword matching and semantic analysis are then used to infer the specific front-end component B. Finally, if a real front-end component B is found in the front-end component directory or other relevant paths, then a dependency exists between the A test node and the corresponding B test node of the B front-end component. This continues in this way, forming a test node tree with A as the root node.

[0076] In the application, after the chaos tool identifies the front-end application file and generates a test node tree, it can display the generated test node tree on the operation interface of the mobile terminal, so that the test user can clearly see the relationship between the various front-end components, thereby having a holistic and clear understanding of the front-end components, paving the way for later selection of which front-end component to perform chaos.

[0077] In this embodiment, the location information of each front-end component is identified by the chaos tool, and a test node tree is generated for the test nodes with dependencies, which helps the test user to intuitively distinguish the relationship between each front-end component and facilitates the test user to inject anomalies into each front-end component.

[0078] See also Figure 3 , Figure 3 This is a flow chart of a front-end application testing method provided by another embodiment of the present application. Figure 1 In a corresponding embodiment, the front-end application testing method provided in this embodiment further includes steps S301 to S303 in step S103. The details are as follows: the chaos tool includes multiple abnormal information, each abnormal information has a corresponding initial weight value; S103 includes:

[0079] S301. In the test node tree, a corresponding target node is identified. The target node is a node generated when the chaos tool identifies multiple front-end components in the same installation directory.

[0080] In the application, when generating the above-mentioned test node tree, the test nodes generated for identifying multiple front-end components under the same folder can all be considered as target nodes. Specifically, referring to the above example for the front-end component B, the front-end component C, and the front-end component D of the front-end application component under the A installation directory, if the B1 folder under the A installation directory contains the B front-end component, and the C1 folder contains the C front-end component, and the D front-end component and the B1 folder and the C1 folder are in the same installation node. Among them, the A test node is the root node, and the B1 test node, C1 test node, and D test node connected to it can all be considered as brother nodes in the second level, that is, target nodes. However, for the B test node and the C test node in the third level, they are not brother nodes because they are not the same as the previous test node.

[0081] S302: Randomly obtain the abnormal information from the multiple abnormal information according to the initial weight value.

[0082] In the application, the chaos tool also includes an exception library, which is used to store the above-mentioned exception information. The exception information in the exception library can be set by the chaos tool itself, or it can be exception information written by the test user according to the actual situation, and the written exception information is stored in the exception library so that it can be called and injected into the test node at any time. Since the impact of each exception information on the front-end application corresponding to the front-end application component is different, the test user can set the initial weight value by himself, or use the initial weight value preset by the exception information. For the exception information corresponding to the initial weight value, if the initial weight value is larger, when the chaos tool randomly selects the exception information for injection, the probability of the selected exception information is also higher than that of the exception information with a smaller initial weight value. In the application, using the initial weight value to randomly inject exception information can reduce the subjectivity of manually injecting exception information, which is more conducive to testing the front-end application component and obtaining a stable front-end application system for user use.

[0083] In other applications, the test user may also actively select abnormal information and actively or randomly select the front-end component corresponding to the test node or target node to be injected, and there is no limitation on this.

[0084] S303: Inject the exception information into the script file corresponding to the target node to obtain the test front-end application file.

[0085] In an application, the target node is a sibling node of all test nodes. When using a chaos tool to identify all front-end components and generate a test node tree, the target node can be specially displayed. For example, the target node can be highlighted, and the highlighted target nodes can be displayed in the same color on the web interface for target nodes in the same folder, while the corresponding highlight colors for target nodes in different folders can be different, making it easier for test users to observe the dependencies between various front-end components. For an application to be tested, if an application has four front-end component nodes, namely test node A, test node B, test node C, and test node D, test nodes B and C are subordinate nodes of test node A, test nodes B and C are target nodes, and test node D is a subordinate node of test node B. When injecting exception information, compared to injecting exception information into all four test nodes to obtain the corresponding four fault results, the user needs to check all four test nodes to determine which test node's corresponding front-end component caused the exception. However, if we start from the target node, we only need to inject exception information into test node B and test node C. When we obtain the fault result, we can determine which target node's corresponding front-end component caused the exception information based on the different forms of the exception information, thereby improving the testing efficiency of the front-end components in the front-end application file.

[0086] In this embodiment, by identifying the corresponding target node and randomly injecting the abnormal information into the target node according to the initial weight value corresponding to each abnormal information, the subjectivity of manually injecting abnormal information is reduced, and it is more conducive to testing the front-end application components. By injecting abnormal information into the target node, the number of test nodes injected with abnormal information is reduced, and the testing efficiency of the front-end application files is improved.

[0087] See also Figure 4 , Figure 4 This is a flow chart of a front-end application testing method provided by another embodiment of the present application. Figure 1 Correspondingly, the front-end application testing method provided in this embodiment further includes S401 to S404 after S104. The details are as follows:

[0088] S401: Receive modification instructions issued by a tester based on the test results.

[0089] S402: Modify the initial weight value of the abnormal information according to the modification instruction.

[0090] In the application, the above-mentioned modification instructions are used to modify the initial weight values ​​corresponding to the exception information. Specifically, each exception information in the exception library has a corresponding initial weight value, that is, each exception in the exception information has a corresponding initial weight value. Exemplarily, the initial weight value corresponding to each exception can be a random number between 1-10, which can be customized by the test user. For example, the initial weight value corresponding to each exception is set to 1. When the chaos tool randomly selects the exception information in the exception library and injects it into the test node, the probability of each exception information being randomly selected is the same. Afterwards, after multiple experiments to obtain the test results, it is found that the exception in a certain exception information has a greater impact on the function of the front-end application. Then, the test user can issue a modification instruction in the subsequent experiment to increase the probability of the exception information being randomly selected and injected into the test node.

[0091] S403 . Randomly inject the abnormal information among the plurality of abnormal information into the script file corresponding to the target node multiple times according to the modified initial weight value.

[0092] In an application, if the initial weight value corresponding to a certain exception information is increased, multiple tests are required to better understand the functional impact of the exception information on the front-end application. Among them, the initial weight value corresponding to a certain exception information can be increased by changing the initial weight value 1 to 10, so that the exception information will be included in each of the multiple randomly selected exception information. In addition, when the selected exception information is injected into the target node, the test node for each exception information injection can be randomly selected or a test node specified by the test user, and there is no limitation on this.

[0093] In an application, when different exception messages are injected into different or the same test nodes, the resulting failures may have different impacts on the user being tested. For example, if a front-end application fails to fully display an image, and the front-end application is a food ordering application, the front-end application will be run according to the ordering scenario when the exception message is injected into the front-end component contained in the test node that displays the food product interface. Under normal circumstances, the front-end application's operation interface will not be able to fully display the pushed food product images. Although this will affect the test user's use, the test user can still order food based on the food name in the corresponding food image. However, if the exception message indicates that payment is unavailable, after simulating ordering through the front-end application, when entering the payment interface to make payment, the corresponding payment function will not be responded to, that is, the payment function is unavailable, and the front-end application is unavailable. Compared to the exception message of incomplete image display, the payment unavailable exception message has a deeper impact on the user.

[0094] S404: Acquire test results generated by the front-end application when the exception occurs multiple times, and modify the script file corresponding to the target node according to the test results.

[0095] In the application, during the experimental process of testing the front-end application, for each fault result corresponding to the exception information, the test user can continuously adjust the response method of the exception in the exception information, that is, to add a new execution code to the script file corresponding to the original test node to solve the exception, or use a new front-end component to replace the original script file, without limitation. Furthermore, when the front-end application occurs, the impact on the test user is smaller. Among them, multiple experiments can be conducted to compare the multiple test results when the front-end application occurs after each adjustment of the response method to the exception, and the best fault solution can be selected. It is more purposeful and more efficient, and a stable front-end application for the user to be tested can be obtained more quickly.

[0096] In this embodiment, the initial weight value of the exception information is adjusted through multiple experiments, so that the exception information with the greatest impact on the front-end application can be selected multiple times and randomly injected into the test node to observe its different impacts on the front-end application. Then, based on the results of multiple tests, the script file corresponding to the test node is modified to obtain a stable front-end application.

[0097] In one embodiment, the exception information includes exceptions, exception capture functions, and exception injection functions. The front-end application testing method provided in this embodiment further includes, before S104:

[0098] An injection instruction is received, where the injection instruction is used to inject the exception and the exception capture function into a script file corresponding to the target node according to the exception injection function in the exception information, thereby generating the test front-end application file.

[0099] In the application, the above injection instruction is used to inject exception information into the target node. Specifically, the method of injecting exceptions into the script file in the test node can be: in the front-end page of the visual test node, select a test node to be tested (it can also be randomly selected by the chaos tool). The chaos tool randomly selects an exception information (including exceptions, exception injection functions and corresponding exception capture responses) from the exception library, and injects the exception and exception capture function into the script file according to the exception injection function. The original script file, the code corresponding to the exception and the code corresponding to the exception capture function can be encapsulated into a new front-end component, and the front-end application file containing the new front-end component is the test front-end application file. For the C test node containing the C front-end component, the C front-end component can be encapsulated and wrapped, and after a series of processing (for example, the rest of the code is added to the execution code of the original C front-end component), the high-order component C is finally obtained. Among them, the high-order component C includes the working capabilities of the original C front-end component, and also includes the newly added execution code capability, and the newly added execution code capability includes the exception capture function.

[0100] Run the test front-end application file, and when the exception occurs, capture the script file corresponding to the exception according to the exception capture function.

[0101] In the application, the above-mentioned exception capture function can be used to capture JavaScript exceptions using the try...catch... code block in JavaScript. Through the design of the above code, when the injected exception is a JavaScript execution error, the test user can quickly locate the erroneous code and execution context. Among them, the exception information can also include the exception response method. For example, for the running test front-end application file, when the injected exception occurs, the exception capture function will respond and capture the current injected exception, and then remind the test user through the injected exception response method that X exception has occurred in the XXX component. For example, each high-order component will have its own capture function (the above-mentioned try...catch... code block), which can locate which high-order component (the test node where the exception is injected) has an exception.

[0102] In this embodiment, the exception injection function in the exception information is used to inject the exception and the exception capture function into the corresponding test node. When multiple exceptions are injected into different test nodes, the test user can quickly determine the current fault result based on the exception capture function, and which test node injected the exception information generated it, and then process the script file of the test node.

[0103] In one embodiment, the front-end application testing method provided in this embodiment further includes, after S104:

[0104] Stop running the test front-end application file.

[0105] In an application, when testing a test front-end application file, the injection of exception information may cause the test front-end application file to generate a failure result. To prevent the test front-end application file from crashing due to the current failure result and thus being unable to proceed to subsequent test steps, you can stop running the test front-end application file when the failure result of the test front-end application file is obtained.

[0106] Obtain a preset processing solution, and resolve the test result according to the processing solution.

[0107] In the application, the above-mentioned exception library may also include an exception response function, which can resolve the exception according to the exception response function pre-set in the exception library when the exception occurs. Among them, exceptions can also be divided into predictable exceptions and unpredictable unknown exceptions. For example, for the exception of "incomplete image display", after injecting the exception information containing the exception into the test node, the test front-end application file should display that the image loading is unclear or abnormal when it is running. If the text display is unclear at the same time, it means that an unknown exception has occurred. If an unknown exception occurs, "Unknown exception occurred" can be displayed on the front-end page for the test user to observe.

[0108] In the application, in addition to pre-setting the exception response function for the test front-end application file in the exception library when an exception occurs, the test user can also handle unknown exceptions in advance through architectural adjustments for predictable or unpredictable exceptions; or, a series of degradation schemes can be preset to enable the test front-end application file to quickly degrade when encountering an exception, reduce the crash rate of the test front-end application file, and improve the emergency response capability of the test front-end application file. Among them, the application software corresponding to the test front-end application file has many mature frameworks when it is developed, and the implementation of a business requirement can adopt multiple frameworks. Problems found in the chaos experiment (front-end application testing) can be avoided by changing the application software framework. For example, for a product display application, if the front-end application has the function of displaying products in the form of short videos, but encounters an exception (poor network signal, or the plug-in for playing videos on the terminal device is damaged, or the plug-in for playing videos is not updated) that causes the front-end application to be unable to play short videos, the application can adopt a preset degradation scheme, such as displaying pre-set product pictures, to improve the emergency response capability of the front-end application, thereby improving the front-end experience and user satisfaction of users after the test. Alternatively, images in front-end applications often experience loading exceptions that prevent them from being displayed. This is likely due to image pixelation being too high. The exception handling function you can set up can compress the images in the background and then re-upload them.

[0109] After resolving the test results, the test results are uploaded to the blockchain and the test front-end application file continues to run.

[0110] In the application, after resolving the exception to avoid the front-end application file from crashing during operation, the front-end application file can continue to run and continue to obtain the fault results when other exceptions occur. In addition, in all embodiments of the present application, the corresponding front-end application test plan is obtained based on the chaos tool. Specifically, the front-end application test plan is processed by the chaos tool. Uploading the front-end application test plan to the blockchain can ensure its security and fairness and transparency to users. The user device can download the front-end application test plan from the blockchain to verify whether the front-end application test plan has been tampered with. The blockchain referred to in this example is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain is essentially a decentralized database, a string of data blocks generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. The blockchain can include the blockchain underlying platform, the platform product service layer, and the application service layer.

[0111] See also Figure 5 , Figure 5 This is a structural block diagram of a front-end application testing device provided in an embodiment of the present application. In this embodiment, the mobile terminal includes various units for executing Figures 1 to 4 Each step in the corresponding embodiment. Please refer to Figures 1 to 4 as well as Figures 1 to 4 For the convenience of explanation, only the parts related to this embodiment are shown. Figure 5 The front-end application testing device 100 includes: an identification module 10, a first generation module 20, a first injection module 30 and a first acquisition module 40, wherein:

[0112] The identification module 10 is used to identify the component information of each front-end component in the front-end application file; wherein, the component information includes the location information and script file of the front-end component, and the location information is the storage path of the front-end component stored in the front-end application file.

[0113] The first generating module 20 is configured to generate a test node corresponding to each front-end component according to the location information of each front-end component, and configure the script file on the test node.

[0114] The first injection module 30 is used to inject abnormal information into the script file on each test node to obtain a test front-end application file.

[0115] The first acquisition module 40 is configured to acquire, when the test front-end application file is run, a test result generated by the test front-end application file when an exception in the exception information occurs.

[0116] As an embodiment of the present application, the front-end application testing device 100 further includes:

[0117] The second acquisition module is used to acquire the chaos tool and store the chaos tool in the installation directory of the front-end application file.

[0118] The first running module is used to run the chaos tool, identify each front-end component of the front-end application file in the installation directory, and generate each test node accordingly.

[0119] As an embodiment of the present application, the front-end application testing device 100 further includes:

[0120] The third acquisition module is used to acquire and generate dependency relationships between each of the test nodes in sequence according to the location information of each front-end component.

[0121] The second generating module is configured to generate a test node tree for each of the test nodes according to the dependency relationship between the test nodes.

[0122] As an embodiment of the present application, the chaos tool includes a plurality of abnormal information, each abnormal information having a corresponding initial weight value; the first injection module 30 is further used to:

[0123] In the test node tree, a target node is correspondingly identified, where the target node is a node generated by the chaos tool when it identifies multiple front-end components in the same installation directory;

[0124] Randomly obtaining the abnormal information among the plurality of abnormal information according to the initial weight value;

[0125] The exception information is injected into the script file corresponding to the target node to obtain the test front-end application file.

[0126] As an embodiment of the present application, the front-end application testing device 100 further includes:

[0127] The first receiving module is used to receive the modification instruction issued by the tester according to the test result.

[0128] The modification module is used to modify the initial weight value of the abnormal information according to the modification instruction.

[0129] The second injection module is used to randomly inject the abnormal information into the script file corresponding to the target node according to the modified initial weight value among the multiple abnormal information.

[0130] The fourth acquisition module is used to obtain the test results generated by the front-end application when the exception occurs multiple times, and modify the script file corresponding to the target node according to the test results.

[0131] As an embodiment of the present application, the exception information includes exceptions, exception capture functions, and exception injection functions; the front-end application testing device 100 further includes:

[0132] The second receiving module is used to receive an injection instruction, where the injection instruction is used to inject the exception and the exception capture function into the script file corresponding to the target node according to the exception injection function in the exception information to generate the test front-end application file.

[0133] The second running module is used to run the test front-end application file, and when the exception occurs, capture the script file corresponding to the exception according to the exception capture function.

[0134] As an embodiment of the present application, the front-end application testing device 100 further includes:

[0135] The stop module is used to stop running the test front-end application file.

[0136] The processing module is used to obtain a preset processing solution and solve the test result according to the processing solution.

[0137] The third running module is used to upload the test results to the blockchain after solving the test results and continue to run the test front-end application file.

[0138] It should be understood that Figure 5 In the structural diagram of the front-end application test device shown, each unit / module is used to perform Figures 1 to 4 The steps in the corresponding embodiments, and Figures 1 to 4 Each step in the corresponding embodiment has been explained in detail in the above embodiment. Figures 1 to 4 as well as Figures 1 to 4 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0139] Figure 6 This is a structural block diagram of a terminal device provided by another embodiment of the present application. Figure 6 As shown, the terminal device 60 of this embodiment includes: a processor 61, a memory 62, and a computer program 63 stored in the memory 62 and executable on the processor 61, such as a program of the method. When the processor 61 executes the computer program 63, the steps in each embodiment of the method described above are implemented, such as Figure 1S101 to S104 shown, or Figure 2 、 Figure 3 and Figure 4 Alternatively, the processor 61 executes the computer program 63 to implement the above Figure 5 The functions of each module / unit in the corresponding embodiment are, for example, Figure 5 For details on the functions of modules 10 to 40, please refer to Figure 5 The relevant descriptions in the corresponding embodiments are not repeated here.

[0140] Exemplarily, the computer program 63 may be divided into one or more units, which are stored in the memory 62 and executed by the processor 61 to implement the present application. The one or more units may be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution process of the computer program 63 in the terminal device 60. For example, the computer program 63 may be divided into a first acquisition unit, a first determination unit, a first adjustment unit, a second adjustment unit, and an execution unit, and the specific functions of each unit are as described above.

[0141] The turntable device may include, but is not limited to, a processor 61 and a memory 62. Those skilled in the art will understand that Figure 6 It is only an example of the terminal device 60 and does not constitute a limitation of the terminal device 60. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the turntable device may also include input and output devices, network access devices, buses, etc.

[0142] The processor 61 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0143] The memory 62 may be an internal storage unit of the terminal device 60, such as a hard disk or memory of the terminal device 60. The memory 62 may also be an external storage device of the terminal device 60, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. equipped on the terminal device 60. Furthermore, the memory 62 may include both an internal storage unit of the terminal device 60 and an external storage device. The memory 62 is used to store computer programs and other programs and data required by the turntable device. The memory 62 may also be used to temporarily store data that has been output or is about to be output.

[0144] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A front-end application testing method, characterized in that: The method comprises: Identify component information of each front-end component in the front-end application file; wherein the component information includes location information and script files of the front-end component, and the location information is the storage path where the front-end component is stored under the front-end application file; Generate a test node corresponding to each front-end component according to the location information of each front-end component, and configure the script file on the test node; Injecting exception information into the script file on each test node to obtain a test front-end application file; When running the test front-end application file, obtaining the test results generated by the test front-end application file; Before generating the test node corresponding to each front-end component according to the location information of each front-end component, the method further includes: Obtaining a chaos tool and storing the chaos tool in the installation directory of the front-end application file; Run the chaos tool to identify each front-end component of the front-end application file in the installation directory, and generate each test node accordingly; The chaos tool includes a plurality of abnormal information, each abnormal information having a corresponding initial weight value; The injecting of exception information into the script file on each test node to obtain a test front-end application file includes: In the test node tree, a target node is correspondingly identified, where the target node is a node generated by the chaos tool when it identifies multiple front-end components in the same installation directory; Randomly obtaining the abnormal information among the plurality of abnormal information according to the initial weight value; The exception information is injected into the script file corresponding to the target node to obtain the test front-end application file.

2. The front-end application testing method according to claim 1, characterized in that: After generating the test node corresponding to each front-end component according to the location information of each front-end component, the method further includes: Obtaining and sequentially generating dependency relationships between each of the test nodes according to the location information of each front-end component; According to the dependency relationship between each of the test nodes, a test node tree is generated for each of the test nodes.

3. The front-end application testing method according to claim 1, characterized in that: After obtaining the test result generated by the test front-end application file when the test front-end application file is run, the method further includes: Receive modification instructions issued by the tester based on the test results; Modify the initial weight value of the abnormal information according to the modification instruction; Randomly injecting the abnormal information into the script file corresponding to the target node according to the modified initial weight value among the plurality of abnormal information; Acquire test results generated by the front-end application when the exception occurs multiple times, and modify the script file corresponding to the target node according to the test results.

4. The front-end application testing method according to claim 1, characterized in that: The exception information includes exceptions, exception capture functions and exception injection functions; Before obtaining the test result generated by the test front-end application file when the test front-end application file is run, the method further includes: Receive an injection instruction, wherein the injection instruction is used to inject the exception and the exception capture function into the script file corresponding to the target node according to the exception injection function in the exception information, and generate the test front-end application file; Run the test front-end application file, and when the exception occurs, capture the script file corresponding to the exception according to the exception capture function.

5. The front-end application testing method according to claim 4, characterized in that: After obtaining the test result generated by the test front-end application file when the test front-end application file is run, the method includes: Stop running the test front-end application file; Obtaining a preset processing solution, and resolving the test result according to the processing solution; After resolving the test results, the test results are uploaded to the blockchain and the test front-end application file continues to run.

6. A front-end application testing device, characterized in that: include: An identification module, configured to identify component information of each front-end component in a front-end application file; wherein the component information includes location information and a script file of the front-end component, and the location information is a storage path where the front-end component is stored under the front-end application file; A first generating module is configured to generate a test node corresponding to each front-end component according to the location information of each front-end component, and configure the script file on the test node; A first injection module is used to inject abnormal information into the script file on each test node to obtain a test front-end application file; A first acquisition module is used to acquire a test result generated by the test front-end application file when the test front-end application file is run; The front-end application testing device further includes: A second acquisition module is configured to acquire a chaos tool and store the chaos tool in the installation directory of the front-end application file; the chaos tool includes a plurality of exception information, each exception information having a corresponding initial weight value; A first running module is configured to run the chaos tool, identify each front-end component of the front-end application file in the installation directory, and generate each test node accordingly; The first injection module is further configured to: In the test node tree, a corresponding target node is identified, and the target node is a node generated by the chaos tool to identify multiple front-end components under the same installation directory; among the multiple exception information, the exception information is randomly obtained according to the initial weight value; the exception information is injected into the script file corresponding to the target node to obtain the test front-end application file.

7. A terminal device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 5 are implemented.

8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images