A method, apparatus and device for generating a test scenario

Abstract

Embodiments of the present specification provide a method, device and equipment for generating a test scenario. The method can include: obtaining a test document; the test document is used to record a test task of a software to be tested; collecting software feature information of the software to be tested to obtain a feature set; calculating a weight value of each software feature information in the feature set based on an association index used to represent an importance degree of the software feature information in a test scenario; combining a plurality of target software feature information in the feature set whose weight value is greater than or equal to a preset weight value to obtain a plurality of test scenario information; determining a sufficiency value of each test scenario information; the sufficiency value is used to represent a coverage degree of a core requirement of the test task by the test scenario information; and determining at least one target test scenario information from the plurality of test scenario information based on the sufficiency value.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and more particularly to a method for generating test scenarios. This specification also relates to an apparatus for generating test scenarios, a computing device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the continuous development of computer technology, users are using increasingly diverse software with more and more functions. However, both during software development and updates, it is necessary to generate test scenarios to test the software's usability in different scenarios. Traditional test scenario generation methods often rely heavily on human experience, which can easily lead to poor-quality test scenarios or test scenarios containing excessive redundant information due to insufficient human expertise.

[0003] Therefore, how to provide a way to generate high-quality, streamlined test scenarios for the software under test is an urgent problem to be solved. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide a method, apparatus, device, and computer-readable medium for generating test scenarios, which improves the quality of the generated test scenarios and reduces redundant information contained in the test scenarios.

[0005] According to a first aspect of one or more embodiments of this specification, a method for generating test scenarios is provided, comprising: Obtain the test documentation; the test documentation is used to record the test tasks of the software to be tested; The software feature information of the software to be tested is collected to obtain a feature set; Based on the correlation index used to represent the importance of the software feature information in the test scenario, the weight value of each software feature information in the feature set is calculated; Multiple target software feature information with weight values ​​greater than or equal to preset weight values ​​in the feature set are combined to obtain multiple test scenario information; Determine a sufficient value for each of the test scenario information; the sufficient value is used to characterize the degree to which the test scenario information covers the core requirements of the test task; Based on the sufficient value, at least one target test scenario information is determined from the plurality of test scenario information.

[0006] According to a second aspect of one or more embodiments of this specification, an apparatus for generating test scenarios is provided, comprising: The document acquisition module is used to acquire test documents; the test documents are used to record the test tasks of the software to be tested. The feature acquisition module is used to acquire software feature information of the software under test and obtain a feature set; The weight calculation module is used to calculate the weight value of each software feature in the feature set based on the correlation index used to represent the importance of the software feature information in the test scenario. The feature combination module is used to combine multiple target software feature information in the feature set whose weight values ​​are greater than or equal to preset weight values ​​to obtain multiple test scenario information. A sufficiency value determination module is used to determine the sufficiency value of each of the test scenario information; the sufficiency value is used to characterize the degree to which the test scenario information covers the core requirements of the test task; The test scenario determination module is used to determine at least one target test scenario information from multiple test scenario information based on the sufficient value.

[0007] According to a third aspect of one or more embodiments of this specification, a computing device is provided, including a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor, when executing the computer instructions, implements the steps of the method for generating a test scenario.

[0008] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions, which, when executed by a processor, implement the steps of the method for generating a test scenario.

[0009] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the method for generating test scenarios described above.

[0010] At least one embodiment of this specification can achieve the following beneficial effects: The software to be tested is determined by acquiring a test document that records the test tasks of the software to be tested; software feature information of the software to be tested is collected to obtain a feature set; based on a correlation index representing the importance of software feature information in the test scenario, the weight value of each software feature information in the feature set is calculated; multiple target software feature information with weight values ​​greater than or equal to preset weight values ​​are combined to obtain multiple test scenario information; a sufficiency value is calculated for each test scenario information; and based on the sufficiency value, target test scenario information that can be used to test the software to be tested is determined from the multiple test scenario information. On the one hand, by calculating the weight values ​​of software feature information and selecting target software feature information with higher weights for combination, the test scenario information can cover important information and reduce the coverage of redundant information. On the other hand, by calculating the sufficiency value of the test scenario, target test scenario information that meets the test requirements of the test task is filtered, ensuring that the target test scenario information better meets the test requirements for the software to be tested while also guaranteeing the quality of the generated target test scenario information. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram illustrating an application scenario of a method for generating test scenarios provided in one embodiment of this specification; Figure 2 This is a flowchart illustrating a method for generating a test scenario according to an embodiment of this specification; Figure 3 This is a schematic diagram of an architecture for generating test scenarios provided in one embodiment of this specification; Figure 4 This is a schematic diagram of the overall process for generating a test scenario provided in one embodiment of this specification; Figure 5 This specification provides an embodiment corresponding to... Figure 2 A schematic diagram of the structure of a device for generating test scenarios; Figure 6 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0013] 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 specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0014] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0015] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0016] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, 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, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0017] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0018] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0019] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, when device A receives data sent by device B, it can be understood as device A directly receiving data sent by device B, or it can be understood as device A indirectly receiving data sent by device B through device C or other entities. Similarly, when device B sends data to device A, it can be understood as device B directly sending data to device A, or it can be understood as device B indirectly sending data to device A through device C or other entities. Here, device C can be one entity, or it can be two or more entities.

[0020] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "structure A is connected to structure B," unless it is explicitly stated that structure A and structure B are directly connected, it should be understood that structure A can be directly connected to structure B, or indirectly connected to structure B. Similarly, when describing "structure A is on top of structure B," unless it is explicitly stated that structure A is directly above structure B (structures A and B are adjacent and structure A is above structure B), it should be understood that structure A can be directly above structure B, or indirectly above structure B (structures A and B are separated by other elements, and structure A is above structure B). And so on.

[0021] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0022] The following explains the terms and concepts used in one or more embodiments of this specification.

[0023] Test adequacy: A metric applicable to measuring the completeness and effectiveness of testing.

[0024] Test scenarios: These represent end-to-end business processes or user stories, used to verify whether the system can function correctly under specified conditions. A user story can represent a complete operation triggered from the perspective of a real user or business function.

[0025] Traffic replay is a technique that captures real network traffic in a production environment and re-executes those requests in a test environment or a new version of the system for system verification, performance testing, or security assessment.

[0026] In related technologies, test scenarios are generated by deriving from textual materials such as product requirement documents, system analysis descriptions, or test analysis documents. However, the quality of the generated test scenarios is highly correlated with the quality of the documents. If there are vague descriptions or missing information in the documents, low-quality test scenarios or even test scenarios with serious defects will be generated.

[0027] In related technologies, the program code of the software under test can also be used as the analysis object to generate test scenarios. However, the test scenarios are overly coupled with the code implementation details. When there are minor changes in the implementation logic or internal structure of the software under test, it is very easy to cause a large number of related scenarios to fail.

[0028] Related technologies can also collect and record real user requests in the generation environment and transform them into test scenarios. However, the daily request volume of real users is huge and accumulates day by day. If real user requests are transformed into test scenarios, the number of test scenarios will be huge, and there will be a large number of duplicate, similar or invalid scenarios, which will be costly to use for testing the software under test.

[0029] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0030] Figure 1 This is a schematic diagram illustrating an application scenario of a method for generating test scenarios provided in an embodiment of this specification.

[0031] like Figure 1 As shown, the solution may include test document 1, server 2, and target test scenario information 3. Server 2 can receive test document 1, determine the software to be tested based on test document 1, and collect software feature information of the software to be tested using a feature acquisition device to obtain a feature set. Server 2 can also calculate the weight value of each software feature information in the feature set based on one or more correlation indicators, and filter target software feature information with a weight value greater than or equal to a preset weight value from the feature set, thereby enabling the combination of target software feature information to generate multiple test scenario information. Server 2 can calculate the sufficiency value of each test scenario information to filter target test scenario information 3 that meets the requirements of the test task, thereby enabling the testing of the software to be tested using target test scenario information 3. Server 2 can connect to one or more client devices through a local area network connection, wide area network connection, Internet connection, or other types of data network. Client devices may include, but are not limited to, smartphones, tablets, laptops, PDAs, personal computers, smart home devices, and in-vehicle devices. Test document 1 and target test scenario information 3 can be displayed on the client devices. Server 2 can be a server cluster.

[0032] This application provides a method for generating test scenarios. It also relates to an apparatus for generating test scenarios, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0033] Figure 2 This is a flowchart illustrating a method for generating test scenarios provided in an embodiment of this specification.

[0034] From a programming perspective, the executor of the process can be a program hosted on an application server or application terminal. From a hardware perspective, the executor of the process can be a testing platform or server used to test the software. It can be understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0035] like Figure 2 As shown, the process may include the following steps: Step 202: Obtain the test document; the test document is used to record the test tasks of the software to be tested.

[0036] In the embodiments of this specification, the test document can be a structured or unstructured electronic document. The test document can be obtained from a database storing test documents; alternatively, the test document can be written by the test user or the development user. The information type in the test document can be code, text, or a combination of text and images, etc.

[0037] In the embodiments of this specification, the software to be tested can be a target software system or module that needs to be quality verified. The software to be tested can be at least one of an application, application service, or application interface. A test task can represent the task content of testing the software to be tested. Alternatively, a test task can also represent the testing intent for the software to be tested. A test task can be at least one of regression testing, change testing, version verification testing, or incremental testing.

[0038] Step 204: Collect the software feature information of the software to be tested to obtain the feature set.

[0039] In the embodiments of this specification, software feature information can be feature information extracted from the software under test to identify, distinguish, describe, or determine the software's attributes, state, behavior, or environment. Software feature information can also be information extracted from information related to the software under test. One piece of software feature information can correspond to one or more feature values. For example, if testing an interface, the feature information can be the transport protocols supported by the interface, and the feature values ​​can be HTTP, HTTPS, or WebSocket. The feature set can contain all software feature information specific to the software under test.

[0040] In the embodiments described in this specification, the server can invoke a feature acquisition device to collect software feature information of the software under test from one or more data sources. Alternatively, the server can directly collect the software feature information of the software under test from one or more data sources. The data sources can have a corresponding relationship with the software under test, so that the corresponding data source can be determined based on the software identifier of the software under test in order to collect the software feature information of the software under test.

[0041] Step 206: Calculate the weight value of each software feature in the feature set based on the correlation index used to represent the importance of the software feature information in the test scenario.

[0042] In the embodiments of this specification, a test scenario can represent the context in which a test task is performed on the software under test. A test scenario can include at least one of the following: test target information, software version information, user role information, or business process path information. The correlation indicator can be an indicator used to quantify or calculate the correlation between software feature information and the test scenario. The weight value can represent the relative importance of each software feature information in the test scenario and can be a normalized numerical value.

[0043] Step 208: Combine multiple target software feature information whose weight values ​​are greater than or equal to preset weight values ​​in the feature set to obtain multiple test scenario information.

[0044] In the embodiments of this specification, the preset weight values ​​can be determined based on expert experience; or the preset weight values ​​can be set based on test requirements. The test scenario information can be obtained by combining the feature values ​​of the target software feature information. For example, if the feature information is the operating system, the corresponding feature values ​​are System 1 and System 2; if the feature information is the browser, the corresponding feature values ​​are Browser 1, Browser 2, and Browser 3; if the feature information is the login status, the feature values ​​are logged in and not logged in; then they can be combined into a test scenario information: System 1 + Browser 1 + Logged In.

[0045] Step 210: Determine the sufficiency value for each of the test scenario information; the sufficiency value is used to characterize the degree to which the test scenario information covers the core requirements of the test task.

[0046] In the embodiments of this specification, the sufficiency value can represent the sufficiency of the test scenario. The core requirement can represent the key test conditions in the test task; for example, in security testing, "enabling Secure Sockets Layer (SSL)" is a core requirement. Specifically, the server can determine the core scenario information for testing the software under test based on the test task and the software under test. Based on the test scenario information and the core scenario information, the server can determine the coverage degree of the test scenario information over the core scenario information, and define the coverage degree as the sufficiency value. The core scenario information can consist of software feature information used to test whether the software under test meets the core requirements of the test task.

[0047] Step 212: Based on the sufficient value, determine at least one target test scenario information from the plurality of test scenario information.

[0048] In the embodiments of this specification, the target test scenario information may be one or more. The target test scenario information may be scenario information whose sufficient value is greater than or equal to a preset sufficient value. The preset sufficient value may be determined based on expert experience or based on test requirements. The target test scenario information may be scenario information selected for testing the software under test.

[0049] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only possible execution order. The order of some steps may be adjusted according to actual needs, or some steps may be omitted. When the claims involve method steps, changes in the order of such steps, or parallel execution between steps, are also within the scope of protection of the claims.

[0050] Figure 2 The method described above identifies the software to be tested by acquiring test documents that record the test tasks of the software under test, collects software feature information of the software under test, and obtains a feature set. Based on the correlation index used to represent the importance of software feature information in the test scenario, the weight value of each software feature information in the feature set is calculated. Multiple target software feature information with weight values ​​greater than or equal to preset weight values ​​are combined to obtain multiple test scenario information. The sufficiency value of each test scenario information is calculated, and based on the sufficiency value, target test scenario information that can be used to test the software under test is determined from the multiple test scenario information. On the one hand, by calculating the weight values ​​of software feature information, target software feature information with higher weights is selected for combination, so that the test scenario information can cover important information and reduce the coverage of redundant information. On the other hand, by calculating the sufficiency value of test scenarios, target test scenario information that meets the test requirements of the test task is filtered, so that the target test scenario information can better meet the test requirements of the software under test, while also ensuring the quality of the generated target test scenario information.

[0051] based on Figure 2 In addition to the method described herein, this specification also provides some improved implementation methods, which will be described below.

[0052] In one or more embodiments of this specification, the server can collect software feature information of the software under test from one or more data sources to obtain a relatively complete set of features of the software under test, so as to generate high-quality test scenario information subsequently. Optionally, the step of collecting the software feature information of the software under test to obtain a feature set may specifically include: Collect software feature information from historical traffic data; the historical traffic data refers to the historical traffic data generated during the interaction between the user and the software under test. Alternatively, software feature information can be collected from the source code; the source code is the code that constitutes the software under test. Alternatively, software feature information can be collected from the specification document of the software under test; the specification document is a document used to describe the functions and software specifications of the software under test. Alternatively, software feature information can be collected from the database of the software under test; the database is used to store behavioral data related to the software under test.

[0053] In one embodiment of this specification, historical traffic data can represent traffic data such as network requests, response logs, API call records, or front-end event tracking generated during real or simulated interactions between the user and the software under test. Traffic data can represent an interaction event stream. Historical traffic data can be collected using traffic playback. A specification document is a formal document used to describe the functions, interfaces, behavioral constraints, and non-functional requirements of the software under test. The specification document can include one or more documents such as a requirements specification, test instructions, API documentation, software design document, software specification document, or product requirements document. A database can represent a data storage system that the software under test depends on or has built into itself. The database can be used to record information such as business status and user operation behavior. Software specifications can represent the constraints used to constrain the software under test and the key business rules used to implement business services.

[0054] In one embodiment of this specification, the server can access a traffic log system to filter traffic data related to the software under test; parse the traffic data to extract feature information; aggregate and statistically analyze the feature information to output structured software feature information. In practical applications, traffic data contains multiple flow protocols. Traffic collection can be based on a cumulative window statistical method to parse multiple flow protocols, obtaining the input and output parameters of the traffic data; flattening the input and output parameters into key-value pairs; filtering fields with convergent values ​​or significant differences across traffic based on the key-value pairs; and then statistically analyzing the filtered fields to obtain software feature information related to business services, such as features that can be used to identify business anomalies, business risks, or business services. Flattening into key-value pairs can be a processing of input and output parameters with nested structures, resulting in a single "key=value" structure after flattening. Convergent values ​​mean that the field values ​​will not change arbitrarily, but are finite, fixed, or enumerable. Significant differences across traffic means that the field differs greatly under different business services or different user behaviors.

[0055] In one embodiment of this specification, the server can obtain access to the source code database, acquire the source code related to the software under test, use static analysis tools to parse the code structure, dependencies, and call chains of the source code, and extract code information from the source code. Based on change impact analysis, information related to business operations is identified from the code information as software feature information, and this software feature information is organized into structured data, such as key-value pairs. The feature information extracted from the source code may include at least one type of information, such as framework type, dependency library list, security-sensitive functions, or annotations.

[0056] In one embodiment of this specification, the server can determine the acquisition path of the specification document; acquire the specification document based on the acquisition path; parse the document format of the specification document; extract document information based on the document format using natural language processing technology or a rule engine; construct a mapping relationship between document information and interfaces to obtain software feature information. The acquisition path may include a local path address or a web address.

[0057] In one embodiment of this specification, the server can connect to a database associated with the software under test; analyze the data, table structure, operation logs, and data flow rules in the database to obtain software characteristic information. The table structure may include registration information, field names, indexes, and segment types. The data content may include the distribution of field values ​​and the amount of data; for example, the value of `refund_status` can be 0 indicating pending review, 1 indicating a refund, and 2 indicating rejection. The operation logs may include at least one type of log information such as SQL execution logs and write / update frequency. The data flow rules may include at least one type of rule such as database sharding and table partitioning strategies, caching strategies, and data lifecycle rules.

[0058] In one embodiment of this specification, the server can collect software feature information of the software under test from one or more of the above dimensions, thereby providing a more comprehensive and reliable basis for subsequent test scenario generation and task matching, effectively enhancing the pertinence of testing and defect detection capabilities.

[0059] In one or more embodiments of this specification, calculating the weight value of each software feature in the feature set based on a correlation index representing the importance of the software feature information in the test scenario may specifically include: Based on at least one of the first correlation index, the second correlation index, the third correlation index, and the fourth correlation index, the weight value of the software feature information is calculated; the first correlation index is used to represent the frequency of the software feature information being called; the second correlation index is used to represent the degree of impact on business services when the software feature information malfunctions; the third correlation index is used to represent the degree of impact of the software feature information on key decisions in the test scenario; and the fourth correlation index is used to represent the degree of impact of the software feature information on the system data storage layer.

[0060] In one embodiment of this specification, the frequency of software feature information calls can represent the frequency with which the software feature information is called or triggered in historical business services related to the software under test. Call frequency can represent the number of times it is called per unit of time, such as the number of times it is called in a day, or the number of times it is called in six hours, or the number of times it is called in four hours. In practical applications, call frequency can also represent the proportion of the target historical business service that calls or triggers the software feature information among all historical business services. For example, if there are 100 historical business services related to the software under test, and 95 target historical business services call or trigger the software feature information during the execution of these historical business services, then the call frequency can be 95%. Historical business services can be business services for the software under test obtained within a preset time period.

[0061] In one embodiment of this specification, the impact of a software feature information failure on business services can reflect the degree of damage caused to key business indicators such as user business continuity, service quality, or transaction success rate after the software feature information fails or becomes abnormal. The business services can be those provided by the software under test.

[0062] In one embodiment of this specification, the degree to which software feature information influences key decisions in a test scenario can be determined by whether the software feature information participates in the core judgment logic within the test scenario. The core judgment logic may include logic such as permission verification, routing selection, and state transitions, and the software feature information can directly affect the direction of the test results. The execution result of the core judgment logic can represent the key decision.

[0063] In one embodiment of this specification, the degree of influence of software feature information on the system data storage layer can be used to measure whether the software feature information involves data behaviors such as database read / write and caching operations; or the degree of influence of software feature information on the system data storage layer can also represent the impact of software feature information on data consistency, integrity, and data performance. The system data storage layer can be an independent layer specifically responsible for persistently storing, managing, reading, and writing all business data and system state. The system data storage layer can include at least one of the following: relational database, non-relational database, caching system, distributed file storage, message queue persistent storage, configuration storage, log storage, index storage, or data warehouse.

[0064] In one embodiment of this specification, the server can determine the value of any one of the first, second, third, and fourth correlation indicators as the weight value of the software feature information. Alternatively, the server can sum the values ​​of any two, three, or four of the first, second, third, and fourth correlation indicators, and use the sum as the weight value of the software feature information. The summation process can be either cumulative or weighted summation. Specifically, if the weight value of the software feature information is calculated based on the four correlation indicators, it can be calculated using the formula W_f = α*SF + β*GOC + γ*BD + δ*DD. Here, W_f represents the weight value; SF represents the value of the first correlation indicator; α represents the first weight for the first correlation indicator; GOC represents the value of the second correlation indicator; β represents the second weight for the second correlation indicator; BD represents the value of the third correlation indicator; γ represents the third weight for the third correlation indicator; DD represents the value of the fourth correlation indicator; and δ represents the fourth weight for the fourth correlation indicator. The first, second, third, and fourth weights can be set based on expert experience or based on testing requirements. These weights do not need to be fixed values ​​and can be adjusted as testing requirements change. The values ​​of each related indicator are processed numerical values, falling within the [0,1] range, thus avoiding inaccurate weight calculations due to large value differences. Furthermore, by introducing multiple dimensions of related indicators to comprehensively calculate the weights of software feature information, it is possible to more accurately identify truly high-risk, high-value software features in the testing scenario.

[0065] In one or more embodiments of this specification, optionally, the method of obtaining the first correlation index may specifically include: Obtain target historical traffic data containing the software feature information within a preset time period; Based on the target historical traffic data, determine the traffic level that represents the frequency of calls to the software feature information; Based on the traffic level, the first associated indicator is determined.

[0066] In one embodiment of this specification, the preset time period can be a time window used to limit the scope of historical traffic data collection, such as within a week, a month, or half a month. The target historical traffic data can represent traffic data that invoked software feature information within the preset time period. The traffic level can be preset based on expert experience or based on testing requirements.

[0067] In one embodiment of this specification, a traffic level representing the frequency of calls to software feature information is determined based on target historical traffic data. Specifically, the server can determine the daily average value of historical traffic data calling or using software feature information from the target historical traffic data; and determine the corresponding traffic level based on the daily average value. Alternatively, the server can determine the number of historical traffic data calls or uses of software feature information from the target historical traffic data; and determine the corresponding traffic level based on the ratio between the number of data and the total number of target historical traffic data. Based on the traffic level, a first correlation indicator is determined; specifically, a preset value corresponding to the traffic level is determined; the preset value is set as the indicator value of the first correlation indicator to facilitate the subsequent calculation of weight values. Taking the daily average frequency of software feature information calls as an example, the server can be divided into seven traffic levels based on the number of daily calls, with the call frequency decreasing sequentially from level one to level seven. The preset values ​​corresponding to levels one through seven are 1, 0.9, 0.8, 0.7, 0.5, 0.4, and 0.2, respectively. If the daily average number of calls to the software feature information is 3000, the call frequency can be determined to belong to the first traffic level, and the corresponding value can be 1, which can be set as the indicator value of the first correlation indicator. If the daily average number of calls to the software feature information is 100, the call frequency can be determined to belong to the seventh traffic level, and the corresponding value can be 0.2, which can be set as the indicator value of the first correlation indicator. Thus, the call frequency of the software feature information can be transformed into a first correlation indicator value that can be used to subsequently calculate the weight value, thereby providing reliable data support for the weight calculation.

[0068] In one or more embodiments of this specification, optionally, the method of obtaining the second correlation index may specifically include: Based on the risk level of the business service call chain associated with the software feature information, determine the fault impact level of the software feature information; Based on the level of fault impact, the second correlation index is determined.

[0069] In the embodiments of this specification, a business service can refer to a service that the software under test can provide, such as user login, order payment, etc. A business service call chain can be the service call path required to complete a business request. The risk level indicates the risk that exists in the business service call chain when a failure occurs, such as whether refund anomalies, asset loss, or user data leakage will occur. The higher the risk level, the greater the risk caused by a business service failure.

[0070] In one embodiment of this specification, the fault impact level of the software feature information is determined based on the risk level of the business service call link associated with the software feature information. Specifically, multiple business links corresponding to the software under test are obtained; a target business link matching the software feature information is determined from the multiple business links; the risk level of the target business link is determined, and the fault impact level corresponding to the risk level is determined. Based on the fault impact level, a second correlation index is determined. Specifically, a preset fault value corresponding to the fault impact level is determined as the index value of the second correlation index; if the target business link contains multiple links, the preset fault value of the fault impact level with the highest fault impact can be determined as the index value of the second correlation index.

[0071] In practical applications, before obtaining multiple business links corresponding to the software under test, the business process of the software under test can be determined; multiple business links can be determined based on the business process; the risk level of each link can be determined based on the business services of the business links, and a fault impact level corresponding to the risk level can be set; a corresponding preset fault value can be assigned to each fault impact level so that a weight value can be calculated based on the preset fault value. A fault impact level corresponds to a risk level. From the multiple business links, a target business link matching the software feature information can be determined. Specifically, for any business link, it can be determined whether the software feature information is a necessary path for that business link. For example, if the software feature information is a payment interface, it can be considered a necessary path for the payment business link, and the payment business link can be determined as the target business link. For any business link, it can be determined whether a failure of the software feature information can block the entire business process corresponding to that business link; or, for any business link, it can be determined whether the software feature information is a preset type for that business link; the preset type can include at least one of single-point type, no-degradation type, or no-circuit-breaker type. The target business link can then be determined based on the above determination results. The impact level of a fault can be divided into P1, P2, P3, P4, and P5, where the risk levels corresponding to P1 to P5 decrease sequentially. P1 represents a higher risk level caused by a business service failure, while P5 represents a lower risk level. The preset fault values ​​corresponding to P1 to P5 also decrease sequentially and belong to the range [0,1]. For example, if the software feature information is user login authentication, which belongs to the core user login link, a fault in this link would prevent all users from logging in and render the core function unavailable, resulting in a risk level of Level 1. Therefore, the impact level of the fault can be determined as P1, and the preset fault value is determined to be 1, with the second correlation index value also set to 1. This allows for the association of software feature information with the risk level of the corresponding business service call link, and the determination of the fault impact level based on the link risk. The second correlation index objectively reflects the potential fault consequences of software feature information in real business scenarios, while avoiding the subjectivity and inconsistency of relying on manual experience assessments, thus improving the accuracy of weight value calculation.

[0072] Optionally, in one or more embodiments of this specification, the method for obtaining the third correlation indicator may specifically include: Identify the decision branch codes that are covered by the software under test and whose importance is greater than a preset importance threshold; Calculate the first weight of the degree of influence of the software feature information on the decision branch code; Based on the first weight, the third correlation index is determined.

[0073] In one embodiment of this specification, decision branch code can represent a code segment in software code that performs logical judgments based on parameters, conditions, and states to generate different execution paths. Importance can represent the degree of importance of the decision branch code to business correctness, system security, and core processes, typically ranging from 0 to 1 or 0 to 100. The preset importance threshold can be determined based on expert experience or testing requirements. The first weight can represent the strength of the influence of software feature information on the direction of the decision branch code, ranging from 0 to 1 or 0 to 100. The larger the value, the stronger the influence of the software feature information on the direction of the decision branch code. For example, if software feature information A is a user type parameter, it can determine whether to follow the administrator exemption branch, having a decisive influence on the decision direction, so the first weight can be 1; if software feature information B is a payment channel parameter, it has no influence on the decision branch code, so the first weight can be 0.

[0074] In one embodiment of this specification, decision branch code covered by the test scenario and with an importance greater than a preset importance threshold is determined. Specifically, the server can perform static analysis or traversal of the code of the software to be tested, identify all if / else / switch branches, and calculate the importance of the branch code from several dimensions, such as whether the branch code is a core business process; whether the branch code involves security checks; whether the branch code affects fund transactions; whether the branch code is a single point of no loss logic, etc. If the judgment result is yes, the value can be incremented by one; if the judgment result is no, the value can be incremented by zero, and the value is normalized to obtain the importance. Branch code with an importance greater than the preset importance threshold is determined as important branch code. Based on the execution chain of the test scenario, decision branch code covered by the current test scenario is selected from the important branch code.

[0075] In one embodiment of this specification, a first weight is calculated to determine the degree of influence of the software feature information on the decision branch code. Specifically, the first weight can be determined based on the correlation between the software feature information and the decision branch code. For example, if there is a direct correlation between the software feature information and the decision branch code, the first weight can be determined to be 1; if there is an indirect correlation, the first weight can be determined to be a value between 0.4 and 0.7; if there is no correlation, the first weight can be determined to be 0. The server can determine the first weight as the index value of the third correlation indicator. The higher the first weight, the larger the index value of the third correlation indicator, and the higher the importance of the software feature information. This allows for the screening of the decision branch code of the software under test through an importance threshold, the determination of the third correlation indicator of the software feature information based on the decision branch code, reduction of non-critical logic interference, improvement of the effectiveness of feature-branch correlation analysis, and quantitative evaluation of the degree of influence of the software feature information on the decision branch code through the index value of the third correlation indicator.

[0076] Optionally, in one or more embodiments of this specification, the method for obtaining the fourth correlation index may specifically include: The source code of the software under test is analyzed to construct a data dependency path from the software feature information to database operations; Based on the data dependency path, it is determined whether the software feature information triggers a database operation; the database operation includes at least one of the following: storage write, read, update, and delete operations; If the software feature information triggers the database operation, then based on the operation type of the software feature information in the database operation, a second weight is determined to determine the degree of influence of the software feature information on the system data storage layer. Based on the second weight, the fourth correlation index is determined.

[0077] In one embodiment of this specification, a data dependency path can represent a complete execution chain from software feature information to database operations, such as software feature information → business logic judgment → SQL statement → database write / read operation. This chain can be a data dependency path. Database operations can represent core operations on the system's data storage layer, and can include at least one of the following: storage write, read, update, and delete operations; they can also include batch write, transaction commit, index modification, etc. The second weight can represent the degree of influence of software feature information on the system's data storage layer operations, with a value ranging from 0 to 1 or 0 to 100: the larger the value, the stronger the influence of the software feature information on the storage operation.

[0078] In one embodiment of this specification, the source code of the software to be tested is analyzed to construct a data dependency path from software feature information to database operations. Specifically, the server can traverse the source code of the software to be tested using a code link analysis tool to locate all database operation statements; based on the database operation statements, the software feature information such as input parameters, variables, and states that the database operation statements depend on is traced back to determine the complete data dependency path from feature information to business logic to database operations.

[0079] In one embodiment of this specification, determining whether the software feature information triggers a database operation can specifically involve determining whether the software feature information is a direct input to a data dependency path. For example, the user ID parameter in a query order affects the database read operation, so it is determined that the user ID parameter, as a software feature information, triggers a database operation. On the other hand, the payment amount parameter in a commodity transaction has no effect on the database read operation, so it can be determined that the payment amount parameter, as a software feature information, does not trigger a database operation.

[0080] In one embodiment of this specification, the server can assign different second weights to different operation types. For example, if the operation type is write or update, which has a significant impact on the database, the second weight can be set to 1; if it is delete, which has a smaller impact on the database, the second weight can be set to 0.9; and if it is read, which also has a smaller impact on the database, the second weight can be set to 0.8. The server can use the second weight as the value of the fourth correlation indicator. Therefore, by constructing data dependency paths and assigning second weights, the impact of software feature information on database operations can be quantified. This allows the importance of software feature information to be determined from the perspective of database operations, thereby improving the accuracy of screening target software feature information.

[0081] Optionally, in one or more embodiments of this specification, combining multiple target software feature information whose weight values ​​are greater than or equal to preset weight values ​​in the feature set to obtain multiple test scenario information may specifically include: Multiple target software feature information is combined based on the orthogonal array algorithm to obtain multiple test scenario information.

[0082] In one embodiment of this specification, an orthogonal array can represent a test scenario designed using mathematical orthogonal arrays, ensuring that all combinations of every two software feature information are covered, while significantly reducing the number of test scenarios. For example, with k software feature information, each with v feature values, an orthogonal array can cover all two-dimensional combinations using v*logk test scenarios. The orthogonal array algorithm can be part of a grouping algorithm, so that when generating a complete test scenario using a grouping algorithm, the software feature information can be processed based on the orthogonal array, reducing the explosive growth of test scenarios. A grouping algorithm can be an algorithm that combines multiple target test software to generate test scenario information; the orthogonal array algorithm can be used during the combination of target test software to reduce the number of grouped test scenario information.

[0083] Optionally, in one or more embodiments of this specification, combining multiple target software feature information based on the orthogonal array algorithm to obtain multiple test scenario information may specifically include: Obtain invalid feature combinations; the invalid feature combinations include at least one of the following: multiple software feature information with a similarity greater than or equal to a preset similarity, multiple software feature information with mutually exclusive functions, or invalid software feature information determined through trial operation; Multiple target software feature information is combined based on the orthogonal array algorithm to obtain multiple candidate test scenario information; The candidate test scenario information containing software feature information from the invalid feature combinations is removed to obtain multiple test scenario information.

[0084] In one embodiment of this specification, an invalid feature combination can represent a set of software feature information that cannot coexist in actual operation, is logically conflicting, redundant, or has been verified to cause system anomalies. The preset similarity can be determined based on expert experience; or it can be set based on user requirements. Multiple software feature information with a similarity greater than or equal to the preset similarity can represent multiple features with highly overlapping semantics or functions; for example, enabling logging and enabling debug logging. The similarity can be calculated based on at least one of the following methods: text embedding, cosine similarity, Euclidean distance, etc. Multiple software feature information with mutually exclusive functions can represent features that cannot be used simultaneously logically, such as male and pregnant. Invalid software feature information determined through trial operation can represent multiple software feature information whose test results are abnormal after small-scale, non-full-scale trial execution and trial combination verification; or it can also represent multiple software feature information whose historical software feature information combinations exhibit abnormalities during testing. Candidate test scenario information can represent a set of test scenarios initially generated by the orthogonal array algorithm and not yet proposed by invalid combinations.

[0085] In one embodiment of this specification, feature combinations with a similarity greater than or equal to a preset similarity are filtered. Specifically, the server can calculate the similarity value between any two or more software feature information using a similarity calculation formula; feature combinations with a similarity greater than or equal to the preset similarity are determined as invalid feature combinations. Feature combinations with mutually exclusive functions are also filtered. Specifically, the server can establish a mutual exclusion rule base based on software business rules, configuration constraints, and logical restrictions; the mutual exclusion rule base contains multiple mutually exclusive feature combinations with mutually exclusive functions; based on software feature information, software feature information combinations that match the mutually exclusive feature combinations in the mutual exclusion rule base are determined and identified as invalid feature combinations. The server can use the formula C={{f0,f1},{f1,f2,f3}} to represent invalid feature combinations, where C can represent a set of invalid feature combinations; f0 and f1 can represent a set of invalid feature combinations; f1,f2,f3 can represent a set of invalid feature combinations. This formula is only an example; in actual applications, the set of invalid feature combinations can contain multiple sets of invalid feature combinations.

[0086] In one embodiment of this specification, the server can utilize an orthogonal array algorithm to map the target software feature information and its corresponding feature values ​​to the columns and rows of an orthogonal array, such that each column corresponds to a software feature information and each row corresponds to a set of feature value combinations. According to the arrangement rules of the orthogonal array, a set of all feature values ​​that meet the two-dimensional combination coverage requirements is automatically generated. The feature value sets are then deduplicated to obtain multiple candidate test scenarios. It is determined whether any candidate test scenario information contains invalid feature combinations. If any candidate test scenario information contains invalid feature combinations, then that candidate test scenario is removed. After traversing the candidate test scenarios, the remaining candidate test scenarios can be used as test scenario information for testing the software under test. For example, candidate test scenario information 1 contains features A, B, C, and D; candidate test scenario information 2 contains features A, B, D, and E; where features A and C are invalid feature combinations, then candidate test scenario information 1 is removed, and candidate test scenario information 2 is retained. This allows for the reference of invalid feature combinations during the generation of test scenario information, reducing the generation of invalid or redundant test scenario information. This reduces the number of test scenarios while also improving the effectiveness of the test scenarios.

[0087] Optionally, in one or more embodiments of this specification, the method for determining the invalid software feature information may specifically include: Obtain feature blacklist information; the feature blacklist information contains feature combinations that caused abnormal test results during historical testing of other software; The software feature information belonging to the feature blacklist information in the feature set is determined as the invalid software feature information.

[0088] In one embodiment of this specification, historical tests may refer to automated or manual tests on other software under test that were completed prior to the current test task. Test result anomalies may indicate unexpected behavior that occurs during the testing process. Test result anomalies may include situations such as unreproducible results, missing logs, test framework crashes, tests entering infinite loops, and test results that do not meet expectations.

[0089] In one embodiment of this specification, the server can parse the blacklist information to obtain a set of abnormal feature combinations. The server can match the software feature information in the feature set with the feature combinations contained in the blacklist information, and determine multiple software feature information in the feature set that belong to the feature combinations in the blacklist information as invalid software feature information. These multiple invalid software feature information can constitute an invalid feature combination. Thus, the server can filter the software feature information in the feature set using the blacklist information to obtain multiple invalid software feature information that can constitute an invalid feature combination. Test scenarios can be generated using the invalid feature combinations formed by these multiple invalid feature information, improving the stability and reliability of the test scenarios.

[0090] In practical applications, the server can input blacklist information, specification documents, and feature sets into a large language model. This allows the large language model to process the feature sets based on the blacklist and specification document information, outputting invalid feature combinations. This enables the large language model to efficiently and quickly output accurate invalid feature combinations, allowing for the elimination of candidate test scenario information. This improves the effectiveness of test scenario information while significantly enhancing the sufficiency, generation efficiency, and adaptability to changing requirements. It also effectively reduces the high maintenance costs and potential human error risks associated with manually writing invalid feature combinations.

[0091] Optionally, in one or more embodiments of this specification, determining sufficient values ​​for each of the test scenario information may specifically include: The sufficient value of the test scenario information is determined based on at least one of the line coverage, branch coverage, core function coverage, and baseline coverage; the line coverage is calculated based on the number of lines of code executed when the test scenario information is tested and the total number of lines of source code executed when the software under test is run; the branch coverage is calculated based on the number of conditional branch results executed when the test scenario information is tested and the total number of conditional branches executed when the software under test is run; the core function coverage is calculated based on the number of core functions covered by the test scenario information and the total number of core functions covered by the software under test; the baseline coverage is calculated based on the number of baseline scenarios covered by the test scenario information and the total number of baseline scenarios corresponding to the software under test; the baseline scenario is a test scenario constructed based on historical traffic data for regression verification.

[0092] In one embodiment of this specification, code line coverage may include at least one of line coverage and change line coverage. Specifically, line coverage may be determined based on the ratio between the number of lines of source code actually executed during test scenario execution and the total number of lines of source code executable during the complete operation of the software under test; change line coverage may be determined based on the ratio between the number of lines of modified code actually executed during test scenario execution and the total number of lines of modified code executable during the complete operation of the software under test. Modified code may represent code that modifies the code of the software under test, such as modification or deletion operations.

[0093] In one embodiment of this specification, branch coverage may include at least one of full branch coverage and modified branch coverage. Full branch coverage may be determined based on the ratio between the number of branch results actually triggered during test scenario execution and the total number of conditional branches in the software under test; modified branch coverage may be determined based on the ratio between the number of modified branch results actually triggered during test scenario execution and the total number of modified conditional branches in the software under test. A modified branch may represent a branch that modifies a branch in the software under test, such as through modification or deletion operations.

[0094] In one embodiment of this specification, core functions can represent functions that play a critical role in the software functionality, security, or performance of the software under test. These functions can be obtained based on manual annotation or by analyzing various functions of the software under test using a large model. Core function coverage can be determined based on the ratio between the number of core functions covered by the test scenario and the total number of predefined core functions in the software under test.

[0095] In one embodiment of this specification, a baseline scenario can represent a typical usage model constructed based on clustering or sampling of historical real user traffic data, which can be used for regression testing to ensure that the new version does not break mainstream functionality. Baseline coverage can be determined based on the ratio of the number of baseline scenarios covered by the test scenario to the total number of preset baseline scenarios for the software under test.

[0096] In one embodiment of this specification, the server can normalize the coverage metrics, unify the measurement standards for each coverage metric, assign weights to each coverage metric based on business requirements and testing tasks, and process the coverage metrics of any test scenario information using a weighted summation method to obtain a sufficiency value for any test scenario information. Test scenario information with a sufficiency value greater than or equal to a preset threshold can be identified as target test scenario information. This allows for the integration of multi-dimensional coverage metrics such as lines of code, branches, core functions, and baseline scenarios, and the determination of sufficiency values ​​for test scenarios based on their weighted or logical combinations. This provides a more comprehensive and accurate reflection of the test scenario's coverage of key software functions and real user behavior, effectively avoiding testing blind spots caused by a single coverage metric.

[0097] In practical applications, the server can also introduce a sufficient value for calculating change scenario coverage test scenario information. Change scenario coverage can be determined based on the ratio of the number of change scenarios involved in the test scenario to all change scenarios in the software under test. Change scenarios can be scenarios generated based on software feature information related to the impact scope of code changes.

[0098] In practical applications, the server can call the agent to perform sufficiency measurement on the test scenario based on the above coverage dimensions. The agent can determine the target test scenario that meets the test task requirements based on the calculated sufficiency value and output the target test scenario.

[0099] In one or more embodiments of this specification, the method may optionally further include: Generate one or more of a first verification rule, a second verification rule, or a third verification rule; the first verification rule is used to verify whether the test results of the target test scenario information conform to the unified programming interface specification document; the second verification rule is used to verify whether the test results of the target test scenario information conform to the preset business rules of the software under test; the third verification rule is used to verify whether the data generated after the target test scenario information is executed is consistent with the expected data.

[0100] In one embodiment of this specification, the verification rules can be targeted verification rules automatically generated by the server using a large model to verify the target test scenario. Different target test scenarios may correspond to different verification rules to ensure the verifiability of each target test scenario's information. The test results can be the output generated by the system after the target test scenario information is executed, including observable data such as HTTP response bodies, database snapshots, memory states, and log streams.

[0101] In one embodiment of this specification, the One Application Programming Interface (One API) specification document can be a contract file that describes the interfaces exposed by the software under test in a standardized format. The One API specification document can define data structures, data types, and data value ranges; it can also cover checks such as field existence, type matching, length, and enumeration values, thereby determining whether the test results conform to the checks defined in the One API specification document. If the test results do not conform to the checks defined in the One API specification document, the software under test can be modified until the test scenario corresponding to the software under test conforms to the checks defined in the One API specification document.

[0102] In one embodiment of this specification, preset business rules can represent constraints predefined by the business party or product team that reflect the actual business logic. Predictive business rules can be stored in a preset database in the form of business requirement documents. If the test results do not conform to the preset business rules, it indicates that the software under test needs to be modified. For example, in discount calculation, if the preset business rule is a 60% discount for product A, but the test result is a 70% discount, it means the test result does not conform to the preset business rules.

[0103] In one embodiment of this specification, the expected data may represent the correct output results preset for a specific test scenario during the test design phase, based on requirements or historical behavior, including return values, database status, log content, message queue messages, etc. The third verification rule can be used to ensure data consistency between different system modules and database tables, such as ensuring that inventory decreases accordingly after an order is created or that the order status is correctly updated after payment is completed.

[0104] In one embodiment of this specification, the server can generate verification rules based on target test scenario information and related documentation. Specifically, it parses the unified programming interface specification document, extracts constraints such as the response structure, status code range, field types, and required fields of the corresponding interface, and constructs a first verification rule to verify whether the actual response conforms to the specification. It then loads preset business rules related to the target test scenario information from the rule engine or configuration center, reads expected data defined in the target test scenario information such as JSON fragments and database snapshot templates, and verifies the actual prediction results based on the expected data. For example, the software to be tested could be an "e-commerce system's order creation API"; the target test scenario information could be "User A (VIP) places an order for product X (priced at 100 yuan), uses a coupon (discounted by 20 yuan), and selects free shipping"; the first verification rule could be "the order creation interface response must include a string-type order identifier, a numeric total order amount greater than or equal to zero, and an order status selected from an enumeration value"; the second verification rule could be "VIP user orders automatically enjoy free shipping; coupons can only be used to offset the product amount, not the shipping fee"; the third verification rule could be "Order identifier: ORD123; Total order amount: 80; Shipping fee: 0; Order status: Confirmed". If the test result is "Order identifier: ORD456; Total order amount: 80; Shipping fee: 0; Order status: Confirmed", then the test result structure is compliant, the first verification rule passes; the shipping fee in the test result is 0, the second verification rule passes; and the test result value matches the expected value and the order identifier format matches, the third verification rule passes. This enables the generation of multi-dimensional verification rules targeting interface specifications, business rules, and expected data, achieving layered and precise verification of test results and effectively avoiding missed detections or misjudgments caused by a single verification method. At the same time, the on-demand rule generation mechanism improves the flexibility and maintainability of the testing system, allowing interface changes and business logic adjustments to be quickly mapped to the verification logic, significantly enhancing the adaptability and reliability of automated testing.

[0105] In one or more embodiments of this specification, the method may optionally further include: Based on change taint analysis technology, multiple candidate software feature information associated with changes to the software under test are determined from the feature set; Multiple target software feature information pieces with weight values ​​greater than or equal to preset weight values ​​in the feature set are combined to obtain multiple test scenario information, specifically including: Multiple target software feature information whose weight values ​​are greater than or equal to preset weight values ​​are combined to obtain multiple test scenario information.

[0106] In one embodiment of this specification, change taint analysis technology can use changed code as a taint source to trace the scope of the changed code's impact, such as called functions, modified data structures, and exposed interfaces, thereby identifying software feature information affected by the change. Candidate software feature information can represent features that are likely related to the change and selected from a feature set. Target software feature information can represent high-value features among the candidate software feature information whose weight values ​​are not less than a preset weight value.

[0107] In one embodiment of this specification, the server can identify newly added, modified, and deleted code segments by comparing the modified code with the original code of the software under test, determine the propagation path of the impact of the changed code, and identify directly and indirectly affected code regions, interfaces, and functional modules. It then maps the affected code regions to system interfaces and functional points to determine the affected software feature information. Based on a weight calculation formula, it assigns priorities to the affected features and groups high-priority features; the higher the weight, the higher the priority. This allows for the accurate identification of candidate software feature information associated with changes to the software under test by introducing change taint analysis technology. Combined with weight thresholds, it filters and combines high-value target software feature information, effectively narrowing the search space for test scenario generation and avoiding invalid combinations of irrelevant features. Simultaneously, the generated test scenarios are highly focused on the areas affected by the changes, significantly improving the targeting of the tests and the efficiency of defect detection, while reducing the waste of test resources.

[0108] In one or more embodiments of this specification, optionally, the server can determine the corresponding scenario generation method based on the type of test task. Specifically, if the server determines that the test task type of the software under test is change testing based on the test document, it can generate target test scenario information for change testing based on the change iteration mode. Further, the change iteration mode can be a mode that identifies the location of code changes and the propagation path of the changed code in the software under test through change taint analysis technology, determines the affected software characteristic information, and generates target test scenario information for change testing based on the affected software characteristic information. Change testing is mainly used to test whether the changed functions of the software under test can be used normally after changes occur. The changed functions can be newly added functions or modified functions.

[0109] In one embodiment of this specification, if the server determines that the test task type of the software under test is regression testing based on the test document, it can generate target test scenario information for regression testing based on the regression iteration mode. Further, the regression iteration mode can be a mode that constructs a baseline regression model and a defect model based on the target software feature information and historical traffic data; and generates target test scenario information for regression testing based on the target software feature information using the baseline regression model and the defect model. Regression testing can represent testing whether the original functions are normal after changes are made to the software under test. The baseline regression model can be used to generate test scenario information; the defect model can refer to invalid feature combinations to constrain the baseline regression model, avoiding the baseline regression model from generating invalid scenario information. In practical applications, the test task can be a test task input by the test user; or a test task retrieved from the database; or a test task for the software under test generated by a large model based on context information and software under test information provided by the user. The context information can be the changed code of the software under test; or the changed functional modules; or the source code before and after the change, etc.

[0110] In one or more embodiments of this specification, the server can verify the test scenario of the software under test through offline baseline verification. Specifically, the server can use offline traffic cleaning to determine the baseline scenario; determine the standard response data output after correctly processing the business when executing business in the baseline scenario; use the standard response data as verification data; test the baseline scenario corresponding to the software under test, and determine the output test response data. The baseline scenario can be used as the test scenario of the software under test. If the test response data is consistent with the standard response data, it indicates that the baseline scenario test for the software under test has passed; if the test response data is inconsistent with the standard response data, it indicates that the baseline scenario test for the software under test has failed; determine whether the correlation between the test response data satisfies the correlation between the standard response data; if the correlation between the test response data does not satisfy the correlation between the standard response data, it indicates that the baseline scenario test for the software under test has failed; if the correlation between the test response data satisfies the correlation between the standard response data, it indicates that the baseline scenario test for the software under test has passed. If the result of any of the above determinations is negative, the test fails. The relationships between response data can represent the business logic relationships used to determine the response data. For example, if the baseline scenario is a 20% discount on a purchase, the server can determine whether the test response data is calculated based on the 20% discount formula. This is used to determine whether the relationships between the test response data meet the relationships between the standard response data, without focusing on the specific amount. Besides making judgments based on response data, the server can also make judgments based on input parameters. For example, during the testing of the software under test based on the baseline scenario, standard input parameters corresponding to the standard response data can be input to determine whether the response data is consistent when the input parameters are the same.

[0111] In one or more embodiments of this specification, the server can also verify the test scenario of the software under test through real-time dual-run comparison. Specifically, the server can generate target test scenario information in the above manner. For the modified version of the software under test, preset input parameters are input into the target test scenario information to obtain a first output parameter (first response data); for the unchanged version of the software under test, preset input parameters are input into the target test scenario information to obtain a second output parameter (second response data); the difference between the first output parameter and the second output parameter is calculated; if the difference value is greater than a preset difference threshold, the test fails; if the difference value is not greater than the preset difference threshold, the test passes.

[0112] To clearly illustrate the method for generating test scenarios provided in the embodiments of this specification, Figure 3This is a schematic diagram of an architecture for generating test scenarios, provided as an embodiment of this specification. Figure 3 As shown, it can include an intent understanding unit, a scenario generation unit, a sufficiency measurement unit, and a scenario feature extraction unit. The intent understanding unit can parse test documents provided by developers or testers to obtain the corresponding test intent, such as at least one of iterative change testing, baseline regression testing, application testing, or interface testing. The scenario feature extraction unit can collect software feature information related to the software under test from dimensions such as traffic collection, code analysis, document analysis, and large number analysis, and store it in a feature library. Specifically, the traffic collection dimension can be a dimension that collects software feature information based on historical traffic data; the code analysis dimension can be a dimension that collects software feature information based on source code; the document analysis dimension can be a dimension that collects software feature information based on specification documents; and the large number analysis dimension can be a dimension that collects software feature information based on a database.

[0113] Figure 3 The scene generation unit can include an interface selection subunit, a feature selection subunit, and a scene assembly subunit. The interface selection subunit can perform associated interface analysis or an application interface sliding window selection operation based on the test intent and the software under test, in order to determine the target interface related to the software under test from the interface library. Associated interface analysis, when the test intent is determined to be interface testing, can analyze the interfaces associated with the interface under test from the interface library to obtain the target interface, including the interface under test. The application interface sliding window selection operation, when the test intent is determined to be application testing, can determine multiple interfaces involved in the application under test from the interface library, and select the target interface for testing the application from these multiple interfaces using a sliding window selection method.

[0114] The feature selection subunit's feature grading can utilize feature taint correlation analysis technology to filter candidate software feature information related to changes in the target interface involved in the software under test from the feature library. A preset weight calculation method is used to score the feature labels of each software feature information. Specifically, the weight value of the software feature information can be determined as the feature label score result. Based on the feature label score result, target software feature information is selected from the candidate software feature information. The feature selection subunit's feature grouping can use a grouping algorithm to combine target software feature information to obtain candidate test scenario information; invalid feature information involved in the feature blacklist is used to filter invalidity and remove duplicates from the test scenario information to obtain the test scenario information. The grouping algorithm may include orthogonal array algorithms. The scenario assembly subunit can perform verification point analysis and scenario validity analysis on the test scenario information to generate corresponding verification rules; then, the test scenario information carrying the verification rules is stored in the scenario library as the result of scenario assembly.

[0115] Before generating verification rules, the test scenario information can be fully measured based on multiple dimensions such as baseline coverage, change scenario coverage, core function coverage, line coverage, and branch coverage in the full measurement unit to obtain the full value of the test scenario information. Target test scenario information with a full value greater than or equal to a preset full threshold is determined from the test scenario information. Corresponding verification rules are generated for the target test scenario information, and the target test scenario information carrying the verification rules is stored in the scenario library.

[0116] Figure 4 This specification provides a schematic diagram of the overall process for generating a test scenario, as illustrated in the embodiments. Figure 4 As shown, the server can perform scene intent understanding based on test documents. During this process, external environment parameters can be referenced, such as the code information of the software under test, thereby improving the accuracy of scene intent recognition. The test intents identified by scene intent understanding can include change testing and regression testing. For regression testing, high-frequency interfaces can be acquired to determine their software feature information. For change testing, interface impact mapping can be performed to identify the interfaces affected by the change and obtain their corresponding software feature information. Furthermore, change taint analysis can be performed on the software under test, and feature impact mapping can be performed based on the analysis results to determine the software feature information affected by the change.

[0117] The server can calculate weights for each identified software feature, obtaining the weights of each feature. Simultaneously, it can utilize a large model to perform invalid feature filtering, similar feature analysis, and mutually exclusive feature analysis on the feature blacklist and the identified software features, resulting in invalid feature combinations. Based on the weights of each software feature and the invalid feature combinations, software feature information is combined to obtain test scenario information. Code path analysis is performed on the test scenario information to determine the execution logic of the software under test within the test scenario information. Based on the execution logic, the test scenario is validated and generated, resulting in target test scenario information carrying validation rules. Scenario evaluation is performed on the target test scenario information, and the software feature combinations contained in the target test scenario information that fail the evaluation are added to the feature blacklist. Specifically, scenario evaluation can involve testing the software under test using the target test scenario information; if the test results are abnormal, the scenario evaluation is considered to have failed. Figure 4 This is for illustrative purposes only and is not intended to limit the scope of this application.

[0118] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0119] Through the above methods, firstly, the embodiments of this specification mine real user behavior paths and parameter combinations from historical traffic data, and combine them with natural language processing technology to parse the boundary conditions in the requirements document to form a two-way verification mechanism, which can improve the authenticity of scenario coverage and business relevance, and improve the accuracy of generating test scenarios.

[0120] Secondly, the embodiments of this specification analyze test scenarios through indicators such as baseline scenario coverage, line of code coverage, core function coverage, and branch coverage. At the same time, key features are selected based on feature weight calculation, avoiding overemphasis on a certain feature indicator, such as high-frequency call scenarios, while ignoring scenarios with significant impact from business failures. This ensures high coverage of business logic while generating test scenarios that meet expectations.

[0121] Thirdly, in the embodiments of this specification, software feature information can be collected from multiple data sources. While using feature weights to filter target software feature information, the generation of test scenarios can also be constrained by orthogonal arrays and invalid feature combinations. This ensures the authenticity and comprehensiveness of the generated test scenarios while preventing an excessive number of test scenarios.

[0122] Fourthly, in the embodiments of this specification, test scenarios can be generated from the perspective of end-to-end interfaces, avoiding excessive coupling with the code, improving the effectiveness of generating test scenarios, and reducing maintenance costs.

[0123] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods.

[0124] Figure 5 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a device for generating test scenarios.

[0125] like Figure 5 As shown, the device may include: The document acquisition module 502 is used to acquire test documents; the test documents are used to record the test tasks of the software to be tested. The feature acquisition module 504 is used to acquire the software feature information of the software under test and obtain a feature set; The weight calculation module 506 is used to calculate the weight value of each software feature in the feature set based on the correlation index used to represent the importance of the software feature information in the test scenario. The feature combination module 508 is used to combine multiple target software feature information in the feature set whose weight values ​​are greater than or equal to preset weight values ​​to obtain multiple test scenario information. The sufficiency value determination module 510 is used to determine the sufficiency value of each of the test scenario information; the sufficiency value is used to characterize the degree to which the test scenario information covers the core requirements of the test task; The test scenario determination module 512 is used to determine at least one target test scenario information from multiple test scenario information based on the sufficient value.

[0126] based on Figure 5 The embodiments of this specification also provide some specific implementation schemes of the method, which are described below.

[0127] Optionally, the feature acquisition module may be specifically used for: Collect software feature information from historical traffic data; the historical traffic data refers to the historical traffic data generated during the interaction between the user and the software under test. Alternatively, software feature information can be collected from the source code; the source code is the code that constitutes the software under test. Alternatively, software feature information can be collected from the specification document of the software under test; the specification document is a document used to describe the functions and software specifications of the software under test. Alternatively, software feature information can be collected from the database of the software under test; the database is used to store behavioral data related to the software under test.

[0128] Optionally, the weight calculation module may be specifically used for: Based on at least one of the first correlation index, the second correlation index, the third correlation index, and the fourth correlation index, the weight value of the software feature information is calculated; the first correlation index is used to represent the frequency of the software feature information being called; the second correlation index is used to represent the degree of impact on business services when the software feature information malfunctions; the third correlation index is used to represent the degree of impact of the software feature information on key decisions in the test scenario; and the fourth correlation index is used to represent the degree of impact of the software feature information on the system data storage layer.

[0129] Optionally, the weight calculation module may be specifically used for: Obtain target historical traffic data containing the software feature information within a preset time period; Based on the target historical traffic data, determine the traffic level that represents the frequency of calls to the software feature information; Based on the traffic level, the first associated indicator is determined.

[0130] Optionally, the weight calculation module may be specifically used for: Based on the risk level of the business service call chain associated with the software feature information, determine the fault impact level of the software feature information; Based on the level of fault impact, the second correlation index is determined.

[0131] Optionally, the weight calculation module may be specifically used for: Identify the decision branch codes that are covered by the software under test and whose importance is greater than a preset importance threshold; Calculate the first weight of the degree of influence of the software feature information on the decision branch code; Based on the first weight, the third correlation index is determined.

[0132] Optionally, the weight calculation module may be specifically used for: The source code of the software under test is analyzed to construct a data dependency path from the software feature information to database operations; Based on the data dependency path, it is determined whether the software feature information triggers a database operation; the database operation includes at least one of the following: storage write, read, update, and delete operations; If the software feature information triggers the database operation, then based on the operation type of the software feature information in the database operation, a second weight is determined to determine the degree of influence of the software feature information on the system data storage layer. Based on the second weight, the fourth correlation index is determined.

[0133] Optionally, the feature combination module may be specifically used for: Multiple target software feature information is combined based on the orthogonal array algorithm to obtain multiple test scenario information.

[0134] Optionally, the feature combination module may be specifically used for: Obtain invalid feature combinations; the invalid feature combinations include at least one of the following: multiple software feature information with a similarity greater than or equal to a preset similarity, multiple software feature information with mutually exclusive functions, or invalid software feature information determined through trial operation; Multiple target software feature information is combined based on the orthogonal array algorithm to obtain multiple candidate test scenario information; The candidate test scenario information containing software feature information from the invalid feature combinations is removed to obtain multiple test scenario information.

[0135] Optionally, the feature combination module may be specifically used for: Obtain feature blacklist information; the feature blacklist information contains feature combinations that caused abnormal test results during historical testing of other software; The software feature information belonging to the feature blacklist information in the feature set is determined as the invalid software feature information.

[0136] Optionally, the sufficient value determination module may specifically be used for: The sufficient value of the test scenario information is determined based on at least one of the line coverage, branch coverage, core function coverage, and baseline coverage; the line coverage is calculated based on the number of lines of code executed when the test scenario information is tested and the total number of lines of source code executed when the software under test is run; the branch coverage is calculated based on the number of conditional branch results executed when the test scenario information is tested and the total number of conditional branches executed when the software under test is run; the core function coverage is calculated based on the number of core functions covered by the test scenario information and the total number of core functions covered by the software under test; the baseline coverage is calculated based on the number of baseline scenarios covered by the test scenario information and the total number of baseline scenarios corresponding to the software under test; the baseline scenario is a test scenario constructed based on historical traffic data for regression verification.

[0137] Optionally, the device can also be used for: Generate one or more of a first verification rule, a second verification rule, or a third verification rule; the first verification rule is used to verify whether the test results of the target test scenario information conform to the unified programming interface specification document; the second verification rule is used to verify whether the test results of the target test scenario information conform to the preset business rules of the software under test; the third verification rule is used to verify whether the data generated after the target test scenario information is executed is consistent with the expected data.

[0138] Optionally, the device can also be used for: Based on change taint analysis technology, multiple candidate software feature information associated with changes to the software under test are determined from the feature set; Multiple target software feature information pieces with weight values ​​greater than or equal to preset weight values ​​in the feature set are combined to obtain multiple test scenario information, specifically including: Multiple target software feature information whose weight values ​​are greater than or equal to preset weight values ​​are combined to obtain multiple test scenario information.

[0139] It is understood that the modules mentioned above refer to computer programs or program segments used to perform one or more specific functions. Furthermore, the distinction between these modules does not imply that the actual program code must also be separate.

[0140] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0141] The above is an illustrative scheme of an apparatus for generating test scenarios according to this embodiment. It should be noted that the technical solution of this apparatus for generating test scenarios and the technical solution of the method for generating test scenarios described above belong to the same concept. For details not described in detail in the technical solution of the apparatus for generating test scenarios, please refer to the description of the technical solution of the method for generating test scenarios described above.

[0142] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0143] Figure 6 A structural block diagram of a computing device provided according to an embodiment of this specification is shown.

[0144] The computing device 600 includes: Memory 610 and processor 620; The memory 610 is used to store computer programs / instructions, and the processor 620 is used to execute the computer programs / instructions, which, when executed by the processor 620, implement the steps of the method for generating test scenarios.

[0145] Specifically, the components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and the database 650 is used to store data.

[0146] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0147] In one embodiment of this specification, the above-described components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0148] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 600 can also be a mobile or stationary server.

[0149] The processor 620 executes the computer instructions to implement the steps of the method for generating test scenarios.

[0150] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the method for generating test scenarios described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the method for generating test scenarios described above.

[0151] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the method for generating a test scenario as described above.

[0152] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the method for generating test scenarios described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the method for generating test scenarios described above.

[0153] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method for generating test scenarios described above.

[0154] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the method for generating test scenarios described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the method for generating test scenarios described above.

[0155] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the embodiments of apparatus, devices, media, and program products, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The apparatus, devices, media, and program products provided in the embodiments of this specification correspond to the methods, and therefore the apparatus, devices, media, and program products also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding apparatus, devices, media, and program products will not be repeated here.

[0156] 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 a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0157] 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 methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. 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 a digital system themselves to "integrate" it onto a PLD, 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 also 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 also 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.

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

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

[0160] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0161] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the invention can take the form of a computer program product embodied 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.

[0162] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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, generate instructions 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.

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

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

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

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

[0167] 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 character versatile optical disc (DVD) or other optical storage, magnetic tape, 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.

[0168] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application 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.

[0169] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for generating test scenarios, comprising: Obtain the test documentation; the test documentation is used to record the test tasks of the software to be tested; The software feature information of the software to be tested is collected to obtain a feature set; Based on the correlation index used to represent the importance of the software feature information in the test scenario, the weight value of each software feature information in the feature set is calculated; Multiple target software feature information with weight values ​​greater than or equal to preset weight values ​​in the feature set are combined to obtain multiple test scenario information; Determine a sufficient value for each of the test scenario information; the sufficient value is used to characterize the degree to which the test scenario information covers the core requirements of the test task; Based on the sufficient value, at least one target test scenario information is determined from the plurality of test scenario information.

2. The method according to claim 1, wherein collecting the software feature information of the software under test to obtain a feature set specifically includes: Collect software feature information from historical traffic data; the historical traffic data refers to the historical traffic data generated during the interaction between the user and the software under test. Alternatively, software feature information can be collected from the source code; the source code is the code that constitutes the software under test. Alternatively, software feature information can be collected from the specification document of the software under test; the specification document is a document used to describe the functions and software specifications of the software under test. Alternatively, software feature information can be collected from the database of the software under test; the database is used to store behavioral data related to the software under test.

3. The method according to claim 1, wherein calculating the weight value of each software feature in the feature set based on a correlation index representing the importance of the software feature information in the test scenario specifically includes: The weight value of the software feature information is calculated based on at least one of the first correlation index, the second correlation index, the third correlation index, and the fourth correlation index. The first correlation index is used to represent the frequency of the software feature information being called; the second correlation index is used to represent the degree of impact on business services when the software feature information fails; the third correlation index is used to represent the degree of impact of the software feature information on key decisions in the test scenario; and the fourth correlation index is used to represent the degree of impact of the software feature information on the system data storage layer.

4. The method according to claim 3, wherein the method for obtaining the first correlation indicator specifically includes: Obtain target historical traffic data containing the software feature information within a preset time period; Based on the target historical traffic data, determine the traffic level that represents the frequency of calls to the software feature information; Based on the traffic level, the first associated indicator is determined.

5. The method according to claim 3, wherein the method for obtaining the second correlation indicator specifically includes: Based on the risk level of the business service call chain associated with the software feature information, determine the fault impact level of the software feature information; Based on the level of fault impact, the second correlation index is determined.

6. The method according to claim 3, wherein the method for obtaining the third correlation indicator specifically includes: Identify the decision branch codes that are covered by the software under test and whose importance is greater than a preset importance threshold; Calculate the first weight of the degree of influence of the software feature information on the decision branch code; Based on the first weight, the third correlation index is determined.

7. The method according to claim 3, wherein the method for obtaining the fourth correlation indicator specifically includes: The source code of the software under test is analyzed to construct a data dependency path from the software feature information to database operations; Based on the data dependency path, it is determined whether the software feature information triggers a database operation; the database operation includes at least one of the following: storage write, read, update, and delete operations; If the software feature information triggers the database operation, then based on the operation type of the software feature information in the database operation, a second weight is determined to determine the degree of influence of the software feature information on the system data storage layer. Based on the second weight, the fourth correlation index is determined.

8. The method according to claim 1, wherein combining multiple target software feature information with weight values ​​greater than or equal to preset weight values ​​in the feature set to obtain multiple test scenario information specifically includes: Multiple target software feature information is combined based on the orthogonal array algorithm to obtain multiple test scenario information.

9. The method according to claim 8, wherein combining multiple target software feature information based on the orthogonal array algorithm to obtain multiple test scenario information specifically includes: Obtain invalid feature combinations; the invalid feature combinations include at least one of the following: multiple software feature information with a similarity greater than or equal to a preset similarity, multiple software feature information with mutually exclusive functions, or invalid software feature information determined through trial operation; Multiple target software feature information is combined based on the orthogonal array algorithm to obtain multiple candidate test scenario information; The candidate test scenario information containing software feature information from the invalid feature combinations is removed to obtain multiple test scenario information.

10. The method according to claim 9, wherein the method for determining the invalid software feature information specifically includes: Obtain feature-based blacklist information; The feature blacklist information includes feature combinations that caused abnormal test results during historical testing of other software. The software feature information belonging to the feature blacklist information in the feature set is determined as the invalid software feature information.

11. The method according to claim 1, wherein determining sufficient values ​​for each of the test scenario information specifically includes: The sufficient value of the test scenario information is determined based on at least one of line coverage, branch coverage, core function coverage, and baseline coverage; The line coverage is calculated based on the number of lines of code executed when the test scenario information is tested, and the total number of lines of source code executed when the software under test is run; the branch coverage is calculated based on the number of conditional branch results executed when the test scenario information is tested, and the total number of conditional branches executed when the software under test is run. The core function coverage is calculated based on the number of core functions covered by the test scenario information and the total number of core functions covered by the software under test; the baseline coverage is calculated based on the number of baseline scenarios covered by the test scenario information and the total number of baseline scenarios corresponding to the software under test. The baseline scenario is a test scenario built based on historical traffic data for regression validation.

12. The method according to claim 1, further comprising: Generate one or more of the first verification rule, the second verification rule, or the third verification rule; The first verification rule is used to verify whether the test results of the target test scenario information conform to the unified programming interface specification document; the second verification rule is used to verify whether the test results of the target test scenario information conform to the preset business rules of the software under test; the third verification rule is used to verify whether the data generated after the target test scenario information is executed is consistent with the expected data.

13. The method according to claim 1, further comprising: Based on change taint analysis technology, multiple candidate software feature information associated with changes to the software under test are determined from the feature set; Multiple target software feature information pieces with weight values ​​greater than or equal to preset weight values ​​in the feature set are combined to obtain multiple test scenario information, specifically including: Multiple target software feature information whose weight values ​​are greater than or equal to preset weight values ​​are combined to obtain multiple test scenario information.

14. An apparatus for generating test scenarios, comprising: The document acquisition module is used to acquire test documents; the test documents are used to record the test tasks of the software to be tested. The feature acquisition module is used to acquire software feature information of the software under test and obtain a feature set; The weight calculation module is used to calculate the weight value of each software feature in the feature set based on the correlation index used to represent the importance of the software feature information in the test scenario. The feature combination module is used to combine multiple target software feature information in the feature set whose weight values ​​are greater than or equal to preset weight values ​​to obtain multiple test scenario information. A sufficiency value determination module is used to determine the sufficiency value of each of the test scenario information; the sufficiency value is used to characterize the degree to which the test scenario information covers the core requirements of the test task; The test scenario determination module is used to determine at least one target test scenario information from multiple test scenario information based on the sufficient value.

15. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 13.

Images