A test report generation method, device and equipment

Abstract

The embodiment of the specification discloses a test report generation method, device and equipment. The scheme comprises the following steps: determining an automatic test tool with multiple test operation original instructions; determining a test case containing test operation override instructions corresponding to the test operation original instructions, wherein the test operation override instructions are obtained by overriding the test operation original instructions through a patching operation; executing the test operation override instructions in the test case by executing the test case, and recording the execution of the test operation override instructions; and based on the patching code introduced by the patching operation, the execution of the test operation override instructions is recorded; and automatically generating a test report according to the execution result of the test operation override instructions and the data of the auxiliary record.

Description

Technical Field

[0001] This specification relates to the field of testing technology, and in particular to a method, apparatus, and device for generating test reports. Background Technology

[0002] For products such as software applications, their quality is closely related to pre-delivery testing, as well as subsequent post-delivery updates and iterative testing. To demonstrate the testing results, corresponding test reports need to be generated for R&D use or customer review. Examples include unit test reports and integration test reports. Additionally, product acceptance reports are also a type of test report provided to customers, demonstrating that the product to be delivered to the user has passed testing and meets requirements.

[0003] Currently, there are two main methods for generating test reports. The first method is manual compilation, where testers manually record executed test cases and results, summarizing them to create the report. The drawbacks of this method are low efficiency and inconsistent quality, prone to distortion or omissions. The second method uses reporting plugins like Mochawesome to automatically summarize test case results and generate reports. The disadvantages of this method are coarse granularity (only test case titles and execution results are provided), poor flexibility and extensibility, and difficulty in implementing customized requirements.

[0004] Therefore, a better solution for generating test reports is needed to meet the requirements of efficiency, quality, scalability, and other aspects. Summary of the Invention

[0005] This specification provides one or more embodiments of a test report generation method, apparatus, device, and storage medium to address the following technical problem: the need for a better solution for generating test reports to meet requirements in terms of efficiency, quality, and scalability.

[0006] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows:

[0007] This specification provides a test report generation method according to one or more embodiments, including:

[0008] Identify automated testing tools with multiple raw instructions for test operations;

[0009] Determine test cases that contain test operation overwrite instructions corresponding to the original test operation instructions, wherein the test operation overwrite instructions are obtained by overwriting the original test operation instructions through instrumentation.

[0010] By executing the test cases, the target operation to be tested in the test operation override instructions contained therein is executed, as well as the instrumentation code introduced based on the instrumentation operation, in order to assist in recording the execution-related information of the target operation to be tested;

[0011] A test report is automatically generated based on the execution result of the target operation to be tested and the data recorded in the auxiliary records.

[0012] This specification provides a test report generation apparatus according to one or more embodiments, comprising:

[0013] The test tool determination module identifies automated test tools with various raw instructions for test operations.

[0014] The override instruction test case module determines test cases containing test operation override instructions corresponding to the original test operation instructions, wherein the test operation override instructions are obtained by overwriting the original test operation instructions through instrumentation.

[0015] The test auxiliary recording module executes the test cases to execute the target operation to be tested in the test operation override instructions contained therein, as well as the instrumentation code introduced based on the instrumentation operation, in order to assist in recording the execution-related information of the target operation to be tested.

[0016] The test report generation module automatically generates a test report based on the execution result of the operation of the target to be tested and the data recorded in the auxiliary records.

[0017] This specification provides a test report generation device according to one or more embodiments, comprising:

[0018] At least one processor; and,

[0019] A memory communicatively connected to the at least one processor; wherein,

[0020] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform:

[0021] Identify automated testing tools with multiple raw instructions for test operations;

[0022] Determine test cases that contain test operation overwrite instructions corresponding to the original test operation instructions, wherein the test operation overwrite instructions are obtained by overwriting the original test operation instructions through instrumentation.

[0023] By executing the test cases, the target operation to be tested in the test operation override instructions contained therein is executed, as well as the instrumentation code introduced based on the instrumentation operation, in order to assist in recording the execution-related information of the target operation to be tested;

[0024] A test report is automatically generated based on the execution result of the target operation to be tested and the data recorded in the auxiliary records.

[0025] This specification provides one or more embodiments of a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0026] Identify automated testing tools with multiple raw instructions for test operations;

[0027] Determine test cases that contain test operation overwrite instructions corresponding to the original test operation instructions, wherein the test operation overwrite instructions are obtained by overwriting the original test operation instructions through instrumentation.

[0028] By executing the test cases, the target operation to be tested in the test operation override instructions contained therein is executed, as well as the instrumentation code introduced based on the instrumentation operation, in order to assist in recording the execution-related information of the target operation to be tested;

[0029] A test report is automatically generated based on the execution result of the target operation to be tested and the data recorded in the auxiliary records.

[0030] The above-described at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: By overwriting the original test operation instructions of the automated testing tool, the introduced instrumentation code will be executed along with the test target operation during the execution of the test cases, and targeted auxiliary recording will be performed while testing. Based on this, higher quality test reports can be automatically and efficiently generated, and the implementation cost is low and there are fewer errors and omissions. The instrumentation can be overwritten according to actual needs, and the focus and granularity of auxiliary recording can be adjusted, which is more flexible and scalable. It can help record more detailed and more practical test-related data to be presented in the generated test report. Attached Figure Description

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

[0032] Figure 1 A flowchart illustrating a test report generation method provided in one or more embodiments of this specification;

[0033] Figure 2 A flowchart illustrating a scheme for overwriting the original test operation instructions of an automated testing tool, provided in one or more embodiments of this specification.

[0034] Figure 3 A flowchart illustrating a rapid response scheme for abnormal problems based on malfunction simulation logic, provided for one or more embodiments of this specification;

[0035] Figure 4 A schematic diagram of a test operation overwrite instruction provided for one or more embodiments of this specification;

[0036] Figure 5 A method based on one or more embodiments provided in this specification Figure 1 A schematic diagram of a portion of an acceptance report generated using this method;

[0037] Figure 6 A schematic diagram of a test report generation device provided for one or more embodiments of this specification;

[0038] Figure 7 This is a schematic diagram of a test report generation device provided for one or more embodiments of this specification. Detailed Implementation

[0039] This specification provides a test report generation method, apparatus, device, and storage medium through its embodiments.

[0040] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0041] To address the issues in the background technology, the applicant considered using instrumentation to collect additional test-related information for automatically generating higher-quality test reports. Instrumentation, in software development, refers to the technique of adding extra instructions to code to collect information. It can be used for performance monitoring, debugging, test coverage analysis, and other applications. For example, instrumentation can collect information about which code blocks are running, their execution frequency, and execution time. In front-end testing or performance monitoring, instrumentation can be used to understand how the application interacts with the server and how the user interface responds to user actions.

[0042] However, in practice, this approach remains a significant burden for developers, requiring them to modify the code of each test case individually, and the instrumentation placement is prone to errors and omissions. To address this issue, this application considers overriding some of the original instructions used to execute test operations within a specified automated testing tool. This effectively instrumentes all instances of these original instructions across all test cases, requiring minimal modification to the test cases themselves. Furthermore, new input parameters can be introduced to these original instructions to meet flexible expansion needs. Consequently, during the test case execution, relevant test data is automatically and promptly recorded in a timely manner, providing a more comprehensive, complete, and detailed timeline of the test operations, thereby enabling the efficient generation of superior test reports.

[0043] Based on this overall approach, the solution proposed in this application will be further explained below.

[0044] Figure 1 This is a flowchart illustrating a test report generation method provided in one or more embodiments of this specification. The execution entity of this process may include a test device; if the test data is processed on another device connected to the test device, the execution entity may also include that other device.

[0045] Figure 1 The process includes the following steps:

[0046] S102: Identify automated testing tools with multiple raw instructions for test operations.

[0047] Automated testing tools come with a set of commands, referred to as raw commands, which are used to invoke pre-packaged logic. Test cases are written based on the framework corresponding to the automated testing tool, making them more concise and standardized. These raw commands are frequently used in test cases to indicate the order in which test operations should be executed within that test case.

[0048] For ease of understanding, the following examples primarily use Cypress, an existing automated testing tool, as an example. Cypress is a front-end automated testing tool that can be used to write various automated end-to-end tests. Designed specifically for modern web applications, Cypress runs test code directly in the browser and can be used to test any JavaScript-based web application. Cypress provides an easy-to-use API, supports synchronous and asynchronous testing, and offers a rich interactive test execution interface.

[0049] Here are some examples of Cypress's raw test commands: `cy.visit()` for accessing a link; `cy.type()` for entering content; `cy.click()` for clicking content; `cy.check()` for selecting a single / checkbox; and `cy.select()` for selecting from a dropdown list.

[0050] S104: Determine test cases that contain test operation overwrite instructions corresponding to the original test operation instructions, wherein the test operation overwrite instructions are obtained by overwriting the original test operation instructions through instrumentation.

[0051] In one or more embodiments of this specification, some original test operation instructions are overridden, and instrumentation code is introduced therein to obtain corresponding test operation overriding instructions. The test operation overriding instructions and the original test operation instructions can be identical in name form (e.g., function name). In this way, it is not necessary to modify the original code that calls these original test operation instructions, such as the code block in the test case. Furthermore, it is even possible to directly reuse the test cases previously written based on the original test operation instructions. After overriding, the original test operation instructions in these test cases have essentially become test operation overriding instructions.

[0052] Furthermore, depending on actual needs, new input parameters can be added to the original instructions of the test operation during overriding, so as to support certain instrumentation code introduced during overriding that needs to run based on the new input parameters.

[0053] S106: By executing the test case, the target operation to be tested in the test operation override instruction contained therein, and the instrumentation code introduced based on the instrumentation operation, are executed to assist in recording the execution-related information of the target operation to be tested.

[0054] In the test operation override instruction, in addition to instructing the execution of the original test operation, it also instructs how to perform auxiliary recording through instrumentation code, such as how to describe the current operation or step, what fields need to be recorded, when to record, whether to take screenshots and the specific screenshot objects, the output layout of the recorded content, and so on.

[0055] In one or more embodiments of this specification, the auxiliary record includes at least: recording the actual execution of the target operation to be tested itself (which may be a record of the operation process, and may also include additional descriptions adapted to the report requirements for understanding); for the test operation override instruction corresponding to the target operation to be tested, if the instrumentation code in the test operation override instruction also indicates a screenshot operation, then the screenshot of the page targeted by the target operation to be tested can also be recorded, which is more intuitive and more substantial as report material.

[0056] S108: Automatically generate a test report based on the execution result of the operation of the target to be tested and the data recorded in the auxiliary records.

[0057] If the auxiliary record data itself contains the execution result of the target operation under test, a test report can be automatically generated directly from the auxiliary record data. If the auxiliary record data does not contain the execution result, it can be obtained through other means, such as reading the output data of the function in the original instruction of the corresponding test operation, or using the capabilities that automated testing tools may have built into them. It may even be possible to initially organize the execution result (e.g., adding time stamps, structuring it into a specified data format, etc.). The auxiliary record data can be output in chronological order and filled into a pre-defined test report template to automatically generate a test report. Of course, the data can also be laid out more finely according to usability and aesthetic requirements.

[0058] In one or more embodiments of this specification, the data of the corresponding auxiliary records are concatenated and laid out according to the actual execution time sequence of each target operation to be tested (it can be arranged in chronological order before the same test case, and in other dimensions besides time between different test cases), to obtain a report content set consisting of multiple ordered content blocks; if the data of the auxiliary records itself does not contain the execution result of the corresponding target operation to be tested, the execution result is laid out in its own ordered content block or the next ordered content block; based on the laid-out report content set, the automatically generated test report is obtained.

[0059] The size of an ordered content block can be predefined based on actual needs. For example, multiple steps can be pre-defined in the test cases, and then the data recorded for each step can be divided into an ordered content block. Alternatively, multiple test cases can be divided into multiple test case sets according to their testing focus, so that each test case set corresponds to an ordered content block. Furthermore, depending on the target audience of the test report to be generated, if the target audience is internal personnel, the ordered content blocks can be meticulously divided according to normal functional performance dimensions to facilitate problem localization and improvement debugging. If the target audience is the customers of the product to be delivered (i.e., the object under test), the focus can be on selecting the data recorded for outstanding advantages and integrating them into ordered content blocks, while relatively unimportant or mediocre data can be processed more simply.

[0060] In one or more embodiments of this specification, the automatically generated test report can be an editable document to facilitate intuitive and efficient reverse iterative overwriting. Specifically, this includes: after automatically generating the test report, receiving user editing operations on the test report; determining the test operation overwriting instruction corresponding to the content or layout targeted by the editing operation; automatically converting the result of the editing operation into overwriting correction logic, and using the overwriting correction logic to rewrite the test operation overwriting instruction. The logic obtained from the rewriting can serve as a new processing branch in the test operation overwriting instruction, or it can be used to generate another test operation overwriting instruction independently.

[0061] For the automatic conversion mentioned in the previous paragraph, a mapping relationship can be established in advance between the region and content and the code block, function, and parameter of the instrumentation code in the test operation overwrite instruction. Based on this, it is possible to reverse locate the details in the instrumentation code from the document region and content involved in the operation result. And based on the coordinate positioning, semantic understanding, ORC and other processing methods of the document region and content, the details can be automatically modified, thereby realizing automatic conversion.

[0062] In one or more embodiments of this specification, the above-described solution can be used for test reports within the product development phase; it can also be used for test reports provided to customers when the product is ready for delivery, generally referred to as acceptance reports. More specifically, an acceptance report, taking a software product as an example, is a document written during the software testing process, particularly at the end of the acceptance testing phase. The purpose of acceptance testing is to confirm that the software meets business and user requirements. An acceptance report may include a series of acceptance criteria and test results to indicate whether the software has been accepted by the customer (usually the business party or end user); the acceptance report may also include discovered defects, unresolved issues, and some suggestions and feedback. This report helps the project team and the customer jointly understand whether the software is ready for deployment in a production environment.

[0063] The applicant's focus is on developing this solution specifically for acceptance reports, therefore, they place great emphasis on improvements in usability. In the applicant's actual business scenario, during website construction, after product deployment, testing and acceptance personnel conduct functional tests to ensure the delivered product is problem-free. After acceptance, an acceptance report needs to be issued for all website owners to review. The acceptance report includes product acceptance test case information, operation descriptions, and screenshots of relevant steps. Previously, report generation was primarily done manually, which was not only time-consuming and labor-intensive but also resulted in inconsistent quality and difficulty in achieving unified management. Therefore, the applicant proposed this solution, specifically including an automatic acceptance report generation scheme based on Cypress raw command instrumentation, thereby achieving the goals of saving manpower, improving efficiency, and unifying management.

[0064] pass Figure 1 This method, by overriding the original test operation instructions of the automated testing tool, allows the introduced instrumented code to accompany the execution of the test target operation during the test case execution. It provides targeted auxiliary recording while testing, thereby automatically and efficiently generating higher-quality test reports. Furthermore, it is low-cost to implement and less prone to errors. The instrumentation can be overridden according to actual needs, and the focus and granularity of auxiliary recording can be adjusted, offering greater flexibility and scalability. It can also assist in recording more detailed and practically valuable test-related data to be presented in the generated test report.

[0065] based on Figure 1 In addition to the method described herein, this specification also provides some specific implementation schemes and extension schemes of this method, which will be further explained below.

[0066] This specification provides a flowchart illustrating a scheme for overwriting the original test operation instructions of an automated testing tool, using one or more embodiments. (See attached diagram.) Figure 2 .

[0067] Figure 2 The process includes the following steps:

[0068] S202: Before determining the test case containing the test operation overwrite instruction corresponding to the original test operation instruction, obtain the pre-set report to automatically generate the switch logic.

[0069] S204: Using the switch state corresponding to the automatically generated switch logic (hereinafter referred to as switch) in the report as the selection condition, generate selection logic including a first processing branch and a second processing branch, wherein the second processing branch includes the normal execution logic for the original instruction of the test operation.

[0070] The switch has at least two selectable states: one for selecting the first processing branch and the other for selecting the second processing branch. To align with intuition, the switch can be configured such that: when the automatic report generation switch logic is in the "on" state, it indicates that automatic test report generation is required, and the first processing branch can be selected to continue execution. In the first processing branch, not only will the corresponding test operations be performed, but the aforementioned auxiliary recording will also be done. Conversely, when the automatic report generation switch logic is in the "off" state, it indicates that automatic test report generation is not required, and the second processing branch can be selected to continue execution, where only the corresponding test operations are performed normally, without requiring additional logic to generate a test report. In this way, the switch can be placed in the desired state through methods such as pre-configuration or immediate indication, resulting in flexible and efficient operation with good decoupling. Even when automatic test report generation is not required, the normal execution of test cases will not be affected, and especially, execution efficiency will not be impacted.

[0071] S206: In the first processing branch, the original test operation instruction is converted into a main object that is easy to chain-process. Based on the characteristics of the operation in the original test operation instruction, auxiliary recording logic is generated to adapt to it, and the auxiliary recording logic is integrated into the main object.

[0072] In one or more embodiments of this specification, the operational logic in the original test operation instruction can be broken down in the first processing branch, and then instrumented in more detail. This approach is particularly useful when adjustments to the original test operation are required. This allows for deeper intervention not only in auxiliary recording but also in the test operation itself, enabling more complex test operations and increasing testing flexibility. If no intervention in the test operation itself is needed, to prevent the test operation from being affected by auxiliary recording, the solution in step S206 can be adopted, converting the original test operation instruction into a main object that facilitates chained processing. This also helps improve subsequent recording efficiency and, in this case, facilitates the reuse of auxiliary recording logic for other original test operation instructions.

[0073] Furthermore, as mentioned earlier, the switch has at least two states and can be set to more optional states. For example, a third processing branch can be set up specifically for intervening in the test operation itself. In the third processing branch, the operation logic in the original test operation instruction is modified to a certain extent. For example, a simulated misoperation can be added. Assuming that the operation logic itself is to long press button A, the modified operation logic is to long press button A, or to simultaneously click button A and the button B next to button A.

[0074] Following the approach of the third processing branch described above, one or more embodiments of this specification also provide a flowchart illustrating a rapid response scheme for abnormal problems based on erroneous operation simulation logic. (See attached diagram.) Figure 3.exist Figure 3 In this scenario, the aforementioned third processing branch has multiple branches, each corresponding to a different erroneous operation simulation logic.

[0075] Figure 3 The process includes the following steps:

[0076] S302: Obtain a set of test cases, and determine the third processing branch corresponding to different test cases in the set of test cases.

[0077] The test case set can contain a large number of test cases; the larger the number of test cases, the more the advantages of this solution will be demonstrated. It should be noted that not all test cases are required to include a third processing branch, nor are all test operation override instructions required to include a third processing branch. New test operation override instructions can be generated based on existing ones.

[0078] S304: Calculate the degree of matching of operating habits between the erroneous operation simulation logic contained in each of the third processing branches.

[0079] The error simulation logic, based on operational characteristics, can reflect different error-prone thought processes. Some error-prone thought processes share commonalities to varying degrees. For the same user, their operating habits (and similarly, other factors such as device conditions and preferences) are consistent, and the corresponding consistency of their error-prone thought processes is also higher, making it more likely that they will make different error-prone operations with similar thought processes. Here, by matching operating habits, the error simulation logic corresponding to error-prone operations that are likely to be made by the same user is grouped together to more specifically simulate the errors that user may make.

[0080] S306: Based on the matching degree of the operating habits, extract multiple test case sets from the test case set.

[0081] If the user's operating habits match sufficiently, the corresponding test cases can be extracted to form a set of test cases, representing the actions of a virtual user. This process can be repeated to create multiple sets of test cases, with some test cases overlapping between different sets.

[0082] S308: When a user reports an abnormal problem, based on the historical data of the user collected in advance, a test example set is determined by matching among the multiple test example sets, which serves as the target subset.

[0083] The majority of the erroneous operation simulation logic involved in the determined test case set is quite similar to the user's own operating habits. Therefore, the operations performed in the test case set can be approximately regarded as operations that the user is very likely to perform in actual applications.

[0084] In one or more embodiments of this specification, if a match fails, new erroneous operation simulation logic can be generated based on the user operation corresponding to the abnormal problem and / or other historical data of the user to better reflect the possible erroneous operation made by the user. Based on the new erroneous operation simulation logic, at least some test operation overwrite instructions are supplemented and overwritten to add a new third processing branch, thereby making up for the blind spots that may exist in the current test cases. This approach is highly targeted and efficient, and helps to prevent abnormal problems that have not yet occurred from causing adverse user experience to the user.

[0085] S310: Execute the test cases in the target subset to quickly respond to the abnormal issue.

[0086] In this case, since the scope of iterative testing is converged more accurately to the target subset, the execution efficiency is high on the one hand, and it helps to discover test cases with higher practical value on the other hand.

[0087] In one or more embodiments of this specification, erroneous operation simulation logic can be generated (e.g., adaptively generated based on a large model) according to different users' operating habits (e.g., personality, hand size, preferences, etc.) or theoretically possible combinations of operations. Multiple processing branches containing erroneous operation simulation logic can be set accordingly, thereby efficiently and more realistically simulating a large number of testers performing differentiated tests on the same test case.

[0088] Analyze the characteristics of the operations in the original test commands to determine which dimensions these operations will focus on, and then focus on recording these dimensions. For example, assuming the operation is to access a link address, since this operation will cause a new page to open or a page to redirect, the focus will be on the dimension of dynamic page changes, and the auxiliary recording content can include screenshots of page changes. As another example, if the operation is to add a large number of business threads, the focus will be on the dimension of system pressure, and the auxiliary recording content can include data on changes in CPU and content usage.

[0089] S208: Based on the selection logic, generate a test operation overwrite instruction corresponding to the original test operation instruction.

[0090] The test operation override instruction must at least include this selection logic, and may optionally include some descriptive and layout content to better represent the data recorded in the subsequently generated test report.

[0091] pass Figure 2 The proposed solution allows the obtained test operation overwrite instructions to be easily switched back to the original test operation instructions by controlling the switch state, or flexibly switched to execute one or more auxiliary recording schemes, or even directly intervened in the test operation itself. It also has good decoupling and basically does not affect other original test operation instructions.

[0092] In one or more embodiments of this specification, additional step-differentiation custom instructions can be pre-written to better connect with auxiliary recorded data. In this case, the test cases can be modified to include step-differentiation custom instructions. Based on this, for example, ordered content blocks can be divided according to the position of the step-differentiation custom instructions in the test cases to represent different test steps; the step information generated by executing the step-differentiation custom instructions can be obtained; and the step information can be used to provide an overall description of the ordered content blocks as supplementary content in the automatically generated test report. This helps to make the content in the test report more organized and easier to read and understand, which is especially helpful for customers who lack sufficient understanding of the product's technical details.

[0093] It should be noted that custom instructions for distinguishing steps can also be called directly in the test operation override instructions. In this case, it may not be necessary to modify the test cases. Only some framework content of the automated testing tool needs to be intervened. For example, the implementation of the underlying test operation original instructions can be modified to cover the content. Or, a plugin customized based on this solution can be installed on the automated testing tool to intercept the call request to the test operation original instructions and replace it with the test operation override instructions, and so on.

[0094] Based on the foregoing description, and for ease of understanding and greater visual clarity, one or more embodiments of this specification also provide a code diagram illustrating a test operation overwrite instruction. (See attached diagram.) Figure 4 .

[0095] exist Figure 4 In the example, the original Cypress instruction `cy.visit()` for testing access to a link address is overridden. The parameters and function names involved are exemplary and can be understood from the comments in the code.

[0096] exist Figure 4 In this example, an environment variable parameter "flag" is used as the switch mentioned above. By controlling the value of "flag" as needed, it can be made to appear as if the original test operation command is being executed, but in reality, the main part of the added instrumentation code is being overridden.

[0097] When "flag" is in the "true" state, the main components of the overridden instrumented code will be executed. This involves performing the original test operation and automatically generating a step description, along with corresponding auxiliary records. These auxiliary records typically include defined fields such as "stepName," "stepDescription," "operateType," and "operateInfo" (the meaning of which can be understood from the literal meaning of the fields). To further complete the description of the test operation, the defined function "cy.screenshot" is used to automatically capture a screenshot of the relevant content. When "flag" is not in the "true" state, "originalFn" will be returned, indicating that the original test operation instructions will be executed normally.

[0098] Of course, based on the previous explanation, more selection branches can be added to directly intervene in the test operation itself, so as to achieve more flexible and complex new test operations. In this case, "flag" can be a variable with more possible values, such as an enumerated variable or other numerical variables, instead of a Boolean variable.

[0099] As mentioned earlier, this application focuses on the acceptance report scenario. Therefore, based on the preceding description, and more comprehensively, one or more embodiments of this specification also provide a Cypress-based automatic acceptance report generation solution. Figure 1 An exemplary specific implementation of the method described herein.

[0100] Some Cypress directives (serving as the original quality of the test operations mentioned above) have been overridden beforehand. For example, the overridden directives include: `cy.visit()` for recording visited link addresses; `cy.type()` for recording input content; `cy.click()` for recording clicked content; `cy.check()` for recording single / checkbox selections; `cy.select()` for recording dropdown selections; and so on. These directives are integrated non-intrusively, requiring no code modification on the user side and are automatically recorded. For certain steps, if necessary, an additional "stepDescription" parameter can be passed to specify the meaning of the step; the parameter passing method is shown in the example code below.

[0101] Two new custom commands have also been added (which can be used to distinguish custom commands from the steps mentioned above) to supplement and improve the report content, including:

[0102] cy.addCaseDescription('caseDescription'): Used to add descriptive information for test cases, such as calling it once for each test case;

[0103] cy.addStep('stepName','stepDescription'): Used to add step information.

[0104] Based on the above overwrite instructions and custom instructions, the following is a code example of a test case:

[0105] describe('test_name',function(){

[0106] it('what_it_does',function(){

[0107] / / Add a test case description for this test case, detailing the scenario, process, and other information of the test case.

[0108] cy.addCaseDescription("Acceptance Report Test")

[0109] cy.viewport(1920,1080);

[0110] cy.visit('https: / / www.m...test.com);

[0111] cy.wait(3000);

[0112] / / Add a step manually

[0113] cy.addStep("Account Login","Enter the correct username and password to log in to the system")

[0114] cy.xpath(' / / span[text()="Login"]',

[0115] {timeout:60000}).should('contain','login');

[0116] cy.get('#username').click();

[0117] cy.get('#username').type(ˋhuan…testˋ,{stepDescription:"Enter login information in the first input box"});

[0118] cy.get('#userpass').type(ˋ12…QYˋ,{stepDescription:"Enter login information in the second input box"});

[0119] cy.wait(3000);

[0120] / / Since the clicked content contains "login", the appropriate "click the login button" step will be automatically generated.

[0121] cy.xpath(' / / span[text()="Login"]').click({force:true});

[0122] cy.wait(3000)

[0123] cy.wait(3000);

[0124] / / Since the clicked content below contains the corresponding information, appropriate steps will be automatically generated, eliminating the need to add stepDescription information.

[0125] cy.xpath(' / / span[text()="Operations and Maintenance Change Management"]').click({force:true});

[0126] cy.xpath(' / / span[text()="Operations and Maintenance Change Management"]',{timeout:60000}).should('contain','Operations and Maintenance Change Management');

[0127] cy.wait(3000);

[0128] cy.xpath(' / / span[text()="My Changes"]').click({force:true});

[0129] });

[0130] });

[0131] As you can see, the test cases above use custom directives such as `cy.addCaseDescription("Acceptance Report Test")` and `cy.addStep("Account Login", "Enter the correct username and password to log in to the system")`, as well as overridden directives like `cy.visit('https: / / www.m…test.com'). Of course, directives like `cy.get` and `cy.xpath` can also be overridden. It should be noted that some URLs and account information have been partially masked to protect privacy, but this does not affect the understanding of this solution.

[0132] One or more embodiments of this specification also provide a basis Figure 1 A partial diagram of an acceptance report generated using this method is shown below. Figure 5 .

[0133] exist Figure 5 The system systematically and clearly distinguishes and describes each step, automatically recording information such as accessed links, entered information, and relevant screenshots. Similarly, execution-related information for different test cases can be automatically recorded and displayed according to the required layout, ultimately forming a complete acceptance report that is comprehensive and easy for the client to understand.

[0134] Compared to the two existing technologies mentioned in the background section, the above solution addresses the problems inherent in manual report generation. These include: resolving the inefficiency and inconsistent quality issues in manual report generation by automatically recording operation information and generating acceptance reports through overriding the original instrumentation commands. The entire process is fully automated, requiring no manual intervention. Furthermore, being based on the common web testing framework Cypress, it is suitable for most products, ensuring consistent report format and standardized data. It also addresses the issues of coarse granularity and poor scalability of reporting plugins like Mochawesome by automatically collecting test case step information through overriding common Cypress commands such as `visit`, `type`, and `press`. The reports contain detailed process records, and additional methods like `addStep` allow users to extend additional process information, offering greater flexibility.

[0135] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 6 , Figure 7 As shown. The apparatus and equipment are capable of performing the above methods and related alternatives accordingly.

[0136] Figure 6 This specification provides a schematic diagram of the structure of a test report generation device according to one or more embodiments, the device comprising:

[0137] Test tool determination module 602 determines automated test tools with various raw instructions for test operations;

[0138] The override instruction test case module 604 determines test cases containing test operation override instructions corresponding to the original test operation instructions, wherein the test operation override instructions are overwritten by instrumenting the original test operation instructions.

[0139] The test auxiliary recording module 606 executes the test case to execute the target operation to be tested in the test operation override instruction contained therein, as well as the instrumentation code introduced based on the instrumentation operation, so as to assist in recording the execution-related situation of the target operation to be tested.

[0140] The test report generation module 608 automatically generates a test report based on the execution result of the operation of the target to be tested and the data recorded in the auxiliary records.

[0141] Optionally, it also includes:

[0142] The original instruction overwrite module 610 obtains a pre-set report and automatically generates switch logic before determining the test case containing the test operation overwrite instruction corresponding to the original test operation instruction.

[0143] Using the switch state corresponding to the automatically generated switch logic in the report as the selection condition, a selection logic containing a first processing branch and a second processing branch is generated, wherein the second processing branch contains the normal execution logic for the original instruction of the test operation;

[0144] In the first processing branch, the original test operation instruction is converted into a main object that is easy to chain-process. Based on the characteristics of the operation in the original test operation instruction, auxiliary recording logic is generated to adapt to it, and the auxiliary recording logic is integrated into the main object.

[0145] Based on the selection logic, a test operation overwrite instruction corresponding to the original test operation instruction is generated.

[0146] Optionally, the selection logic further includes: a third processing branch generated using the switch state corresponding to the report automatically generated switch logic as the selection condition;

[0147] The original instruction overwrite module 610 generates user error simulation logic based on the operating habits of different users;

[0148] Generate erroneous operation simulation logic;

[0149] Based on the erroneous operation simulation logic, the operation logic itself in the original test operation instruction is modified to generate the third processing branch containing the erroneous operation simulation logic.

[0150] Optionally, the third processing branch has multiple branches, each corresponding to a different malfunction simulation logic;

[0151] The test auxiliary recording module 606 acquires a set of test cases and determines the third processing branch corresponding to different test cases in the set of test cases.

[0152] Calculate the degree of matching of operating habits among the erroneous operation simulation logic contained in each of the third processing branches;

[0153] Based on the matching degree of the operating habits, extract multiple test case sets from the test case set;

[0154] When a user reports an abnormal issue, the system matches the user's historical data collected in advance with the multiple test case sets to determine a test case set as the target subset.

[0155] Execute test cases in the target subset to quickly respond to the abnormal issue.

[0156] Optionally, the test auxiliary recording module 606, after matching the user's historical data collected in advance in the multiple test example sets, if the matching fails, generates new erroneous operation simulation logic based on the user's operation corresponding to the abnormal problem and / or other historical data of the user.

[0157] Based on the new erroneous operation simulation logic, at least some of the test operation overwrite instructions are supplemented and overwritten to add a new third processing branch.

[0158] Optionally, the test auxiliary recording module 606 records the actual operation performed on the target under test.

[0159] For the test operation override instruction corresponding to the target operation to be tested, if the instrumentation code in the test operation override instruction also indicates a screenshot operation, then the screenshot of the page targeted by the target operation to be tested is also recorded.

[0160] Optionally, the test report generation module 608 concatenates and lays out the data of the corresponding auxiliary records according to the operation time sequence of each of the actual executed target operations to obtain a report content set composed of multiple ordered content blocks;

[0161] If the data in the auxiliary record does not contain the execution result of the corresponding target operation to be tested, then the execution result will be laid out in the ordered content block to which it belongs or in the next ordered content block.

[0162] Based on the set of report content after layout, the automatically generated test report is obtained.

[0163] Optionally, the test cases also include additional steps to distinguish custom instructions;

[0164] The test report generation module 608 distinguishes the position of the custom instructions in the test case according to the steps, and divides the ordered content blocks to represent different test steps;

[0165] Obtain the corresponding step information generated by distinguishing custom instructions through the execution of the steps;

[0166] Using the information from the steps, a comprehensive description of the ordered content block is provided, which serves as supplementary content in the automatically generated test report.

[0167] Optionally, the test report is an editable document;

[0168] The test auxiliary recording module 606 receives user editing operations on the test report after the test report is automatically generated;

[0169] Determine the test operation overwrite instruction corresponding to the content or layout targeted by the editing operation;

[0170] The result of the editing operation is automatically converted into overwrite correction logic, and the overwrite correction logic is used to rewrite the test operation overwrite instruction.

[0171] Optionally, the test operation raw instructions are used to perform at least one of the following operations:

[0172] Access the link address; enter the content information; click; select a radio button or checkbox; or select from the drop-down list.

[0173] Figure 7 A schematic diagram of a test report generation device provided for one or more embodiments of this specification, the device comprising:

[0174] At least one processor; and,

[0175] A memory communicatively connected to the at least one processor; wherein,

[0176] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform:

[0177] Identify automated testing tools with multiple raw instructions for test operations;

[0178] Determine test cases that contain test operation overwrite instructions corresponding to the original test operation instructions, wherein the test operation overwrite instructions are obtained by overwriting the original test operation instructions through instrumentation.

[0179] By executing the test cases, the target operation to be tested in the test operation override instructions contained therein is executed, as well as the instrumentation code introduced based on the instrumentation operation, in order to assist in recording the execution-related information of the target operation to be tested;

[0180] A test report is automatically generated based on the execution result of the target operation to be tested and the data recorded in the auxiliary records.

[0181] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0182] Identify automated testing tools with multiple raw instructions for test operations;

[0183] Determine test cases that contain test operation overwrite instructions corresponding to the original test operation instructions, wherein the test operation overwrite instructions are obtained by overwriting the original test operation instructions through instrumentation.

[0184] By executing the test cases, the target operation to be tested in the test operation override instructions contained therein is executed, as well as the instrumentation code introduced based on the instrumentation operation, in order to assist in recording the execution-related information of the target operation to be tested;

[0185] A test report is automatically generated based on the execution result of the target operation to be tested and the data recorded in the auxiliary records.

[0186] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0187] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0188] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0189] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0190] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0191] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0192] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0193] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0194] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0195] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0196] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0197] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0198] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0199] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0200] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0201] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for generating a test report, comprising: Identify automated testing tools with multiple raw instructions for test operations; Determine test cases that contain test operation overwrite instructions corresponding to the original test operation instructions, wherein the test operation overwrite instructions are obtained by overwriting the original test operation instructions through instrumentation. By executing the test cases, the target operation to be tested in the test operation override instructions contained therein is executed, as well as the instrumentation code introduced based on the instrumentation operation, in order to assist in recording the execution-related information of the target operation to be tested; Based on the execution result of the target operation to be tested and the data recorded in the auxiliary system, a test report is automatically generated; Before determining the test case containing the test operation overwrite instruction corresponding to the original test operation instruction, the method further includes: obtaining a pre-set report automatic generation switch logic; using the switch state corresponding to the report automatic generation switch logic as a selection condition, generating selection logic containing a first processing branch and a second processing branch, wherein the second processing branch contains normal execution logic for the original test operation instruction; in the first processing branch, converting the original test operation instruction into a main object that is easy to chain-process, generating auxiliary recording logic adapted to the characteristics of the operation in the original test operation instruction, and integrating the auxiliary recording logic into the main object; generating the test operation overwrite instruction corresponding to the original test operation instruction according to the selection logic.

2. The method as described in claim 1, wherein the selection logic further comprises: a third processing branch generated using the switch state corresponding to the report automatically generated switch logic as a selection condition; The method further includes: Generate erroneous operation simulation logic; Based on the erroneous operation simulation logic, the operation logic itself in the original test operation instruction is modified to generate the third processing branch containing the erroneous operation simulation logic.

3. The method as described in claim 2, wherein the third processing branch has multiple branches, each corresponding to a different malfunction simulation logic; The execution of the instrumentation code based on the instrumentation operation by executing the test cases specifically includes: Obtain a set of test cases, and determine the third processing branch corresponding to different test cases in the set of test cases; Calculate the degree of matching of operating habits among the erroneous operation simulation logic contained in each of the third processing branches; Based on the matching degree of the operating habits, extract multiple test case sets from the test case set; When a user reports an abnormal issue, the system matches the user's historical data collected in advance with the multiple test case sets to determine a test case set as the target subset. Execute test cases in the target subset to quickly respond to the abnormal issue.

4. The method of claim 3, wherein after matching the user's historical data based on pre-collected data in the plurality of test case sets, the method further comprises: If the matching fails, a new erroneous operation simulation logic is generated based on the user operation corresponding to the abnormal problem and / or other historical data of the user. Based on the new erroneous operation simulation logic, at least some of the test operation overwrite instructions are supplemented and overwritten to add a new third processing branch.

5. The method as described in claim 1, wherein the auxiliary recording of the execution-related information of the operation on the target under test specifically includes: Record the actual operation performed on the target under test; For the test operation override instruction corresponding to the target operation to be tested, if the instrumentation code in the test operation override instruction also indicates a screenshot operation, then the screenshot of the page targeted by the target operation to be tested is also recorded.

6. The method as described in claim 1, wherein automatically generating a test report based on the execution result of the operation of the target to be tested and the data recorded in the auxiliary system specifically includes: According to the actual execution time sequence of each of the target operations to be tested, the corresponding auxiliary record data are concatenated and laid out to obtain a report content set consisting of multiple ordered content blocks; If the data in the auxiliary record does not contain the execution result of the corresponding target operation to be tested, then the execution result will be laid out in the ordered content block to which it belongs or in the next ordered content block. Based on the set of report content after layout, the automatically generated test report is obtained.

7. The method of claim 6, wherein the test case further includes additional steps to distinguish custom instructions; The automatic generation of a test report based on the execution result of the operation on the target to be tested and the data recorded in the auxiliary system specifically includes: Based on the steps described above, the positions of the custom instructions in the test cases are distinguished, and the ordered content blocks are divided to represent different test steps. Obtain the corresponding step information generated by distinguishing custom instructions through the execution of the steps; Using the information from the steps, a comprehensive description of the ordered content block is provided, which serves as supplementary content in the automatically generated test report.

8. The method as described in claim 1 or 6, wherein the test report is an editable document; After automatically generating the test report, the method further includes: Receive user editing operations on the test report; Determine the test operation overwrite instruction corresponding to the content or layout targeted by the editing operation; The result of the editing operation is automatically converted into overwrite correction logic, and the overwrite correction logic is used to rewrite the test operation overwrite instruction.

9. The method according to any one of claims 1 to 7, wherein the test operation original instruction is used to perform at least one of the following operations: Access the link address; enter the content information; click; select a radio button or checkbox; or select from the drop-down list.

10. A test report generation apparatus, comprising: The test tool determination module identifies automated test tools with various raw instructions for test operations. The override instruction test case module determines test cases that contain test operation override instructions corresponding to the original test operation instructions, wherein the test operation override instructions are obtained by overwriting the original test operation instructions through instrumentation. The test auxiliary recording module executes the test cases to execute the target operation to be tested in the test operation override instructions contained therein, as well as the instrumentation code introduced based on the instrumentation operation, in order to assist in recording the execution-related information of the target operation to be tested. The test report generation module automatically generates a test report based on the execution result of the operation of the target to be tested and the data recorded in the auxiliary records. Also includes: The original instruction overriding module, before determining the test case containing the test operation overriding instruction corresponding to the original test operation instruction, obtains a pre-set report automatic generation switch logic; using the switch state corresponding to the report automatic generation switch logic as a selection condition, it generates selection logic including a first processing branch and a second processing branch, wherein the second processing branch contains normal execution logic for the original test operation instruction; in the first processing branch, the original test operation instruction is converted into a main object that is easy to chain-process; based on the characteristics of the operation in the original test operation instruction, it generates an auxiliary recording logic that is adapted to it, and integrates the auxiliary recording logic into the main object; based on the selection logic, it generates the test operation overriding instruction corresponding to the original test operation instruction.

11. The apparatus of claim 10, wherein the selection logic further comprises: a third processing branch generated using the switch state corresponding to the report auto-generation switch logic as a selection condition; The original instruction overwrite module generates erroneous operation simulation logic; Based on the erroneous operation simulation logic, the operation logic itself in the original test operation instruction is modified to generate the third processing branch containing the erroneous operation simulation logic.

12. The apparatus of claim 11, wherein the third processing branch has multiple branches, each corresponding to a different malfunction simulation logic; The test auxiliary recording module acquires a set of test cases and determines the third processing branch corresponding to different test cases in the set of test cases. Calculate the degree of matching of operating habits among the erroneous operation simulation logic contained in each of the third processing branches; Based on the matching degree of the operating habits, extract multiple test case sets from the test case set; When a user reports an abnormal issue, the system matches the user's historical data collected in advance with the multiple test case sets to determine a test case set as the target subset. Execute test cases in the target subset to quickly respond to the abnormal issue.

13. The apparatus of claim 12, wherein the test auxiliary recording module, after matching the user's historical data collected in advance in the plurality of test example sets, if the matching fails, generates new erroneous operation simulation logic based on the user's operation corresponding to the abnormal problem and / or other historical data of the user; Based on the new erroneous operation simulation logic, at least some of the test operation overwrite instructions are supplemented and overwritten to add a new third processing branch.

14. The apparatus of claim 10, wherein the test auxiliary recording module records the actual operation performed on the target under test; For the test operation override instruction corresponding to the target operation to be tested, if the instrumentation code in the test operation override instruction also indicates a screenshot operation, then the screenshot of the page targeted by the target operation to be tested is also recorded.

15. The apparatus of claim 10, wherein the test report generation module, according to the operation time sequence of each of the actual executed target operations, concatenates and lays out the corresponding auxiliary record data to obtain a report content set composed of multiple ordered content blocks; If the data in the auxiliary record does not contain the execution result of the corresponding target operation to be tested, then the execution result will be laid out in the ordered content block to which it belongs or in the next ordered content block. Based on the set of report content after layout, the automatically generated test report is obtained.

16. The apparatus of claim 15, wherein the test case further includes additional steps to distinguish custom instructions; The test report generation module distinguishes the position of the custom instructions in the test case according to the steps, and divides the ordered content blocks to represent different test steps; Obtain the corresponding step information generated by distinguishing custom instructions through the execution of the steps; Using the information from the steps, a comprehensive description of the ordered content block is provided, which serves as supplementary content in the automatically generated test report.

17. The apparatus of claim 10 or 15, wherein the test report is an editable document; The test auxiliary recording module receives user editing operations on the test report after the test report is automatically generated; Determine the test operation overwrite instruction corresponding to the content or layout targeted by the editing operation; The result of the editing operation is automatically converted into overwrite correction logic, and the overwrite correction logic is used to rewrite the test operation overwrite instruction.

18. The apparatus of any one of claims 10 to 16, wherein the test operation original instruction is used to perform at least one of the following operations: Access the link address; enter the content information; click; select a radio button or checkbox; or select from the drop-down list.

19. A test report generation device, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: Identify automated testing tools with multiple raw instructions for test operations; Determine test cases that contain test operation overwrite instructions corresponding to the original test operation instructions, wherein the test operation overwrite instructions are obtained by overwriting the original test operation instructions through instrumentation. By executing the test cases, the target operation to be tested in the test operation override instructions contained therein is executed, as well as the instrumentation code introduced based on the instrumentation operation, in order to assist in recording the execution-related information of the target operation to be tested; Based on the execution result of the target operation to be tested and the data recorded in the auxiliary system, a test report is automatically generated; Before determining the test case containing the test operation overwrite instruction corresponding to the original test operation instruction, the method further includes: obtaining a pre-set report automatic generation switch logic; using the switch state corresponding to the report automatic generation switch logic as a selection condition, generating selection logic containing a first processing branch and a second processing branch, wherein the second processing branch contains normal execution logic for the original test operation instruction; in the first processing branch, converting the original test operation instruction into a main object that is easy to chain-process, generating auxiliary recording logic adapted to the characteristics of the operation in the original test operation instruction, and integrating the auxiliary recording logic into the main object; generating the test operation overwrite instruction corresponding to the original test operation instruction according to the selection logic.

Images