Scene recognition method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a scene recognition method and device, electronic equipment and storage medium, the method comprising: obtaining real traffic data on a user line, wherein the real traffic data comprises a plurality of first fields; identifying a combination of an interface address and a request method as a basic unit from the real traffic data; traversing the real traffic data based on the basic unit to determine the number of unique values corresponding to each first field and the total number of requests; determining whether the corresponding first field is a characteristic field according to the number of unique values and the total number of requests of the first field; and identifying a real use scene from the real traffic data according to the combination information of different characteristic fields. Thus, the characteristic field with business meaning can be stripped from the real traffic data, and the real user use scene is restored through field combination clustering, so as to realize automatic and intelligent mapping from original traffic to high-value business scene, and provide real and objective business basis for test design.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and specifically to a scene recognition method, apparatus, electronic device, and storage medium. Background Technology

[0002] Interface testing is a type of software testing used to verify the functionality of interactions between modules within a software system, or the communication between the system and external systems. Parameter combination scenarios are a core component of interface testing and a key factor in determining the depth of interface testing. With rapid iterations of requirements, interface complexity and parameter combination scenarios are increasing dramatically, with parameter combination scenarios growing exponentially.

[0003] In related technologies, regression testing typically relies on methods such as interface test cases or traffic replay.

[0004] This approach, lacking precise data analysis of specific scenarios, fails to construct a clear profile of the business scenario. Summary of the Invention

[0005] This disclosure aims to at least partially address one of the technical problems in the related art.

[0006] Therefore, the purpose of this disclosure is to propose a scenario recognition method, device, electronic device, and storage medium, which can extract business-meaning feature fields from real traffic data, and then restore the real user scenario through field combination clustering, so as to realize the automated and intelligent mapping from raw traffic to high-value business scenarios, and provide real and objective business basis for test design.

[0007] To achieve the above objectives, the scene recognition method proposed in the first aspect of this disclosure includes:

[0008] Obtain real online traffic data of users, wherein the real traffic data includes multiple first fields; The combination of interface address and request method is identified and determined as the basic unit from the real traffic data; Based on the basic unit, the real traffic data is traversed to determine the number of unique values ​​and the total number of requests corresponding to each of the first fields; Based on the number of unique values ​​in the first field and the total number of requests, determine whether the corresponding first field is a feature field; Based on the combination of different feature fields, the real usage scenarios are identified and determined from the real traffic data.

[0009] To achieve the above objectives, the scene recognition device proposed in the second aspect of this disclosure includes: The acquisition module is used to acquire real online traffic data of users, wherein the real traffic data includes multiple first fields; The first determining module is used to identify and determine the combination of interface address and request method from the real traffic data as a basic unit; The second determining module is used to traverse the real traffic data based on the basic unit to determine the number of unique values ​​and the total number of requests corresponding to each of the first fields. The third determining module is used to determine whether the first field is a feature field based on the number of unique values ​​of the first field and the total number of requests; The fourth determining module is used to identify and determine the real usage scenario from the real traffic data based on the combination information of different feature fields.

[0010] The electronic device proposed in the third aspect of this disclosure includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the scene recognition method proposed in the first aspect of this disclosure.

[0011] The fourth aspect of this disclosure provides a non-transitory computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the scene recognition method as proposed in the first aspect of this disclosure.

[0012] A fifth aspect of this disclosure provides a computer program product that, when instructions in the computer program product are executed by a processor, performs a scene recognition method as proposed in a first aspect of this disclosure.

[0013] The scenario identification method, apparatus, electronic device, and storage medium disclosed herein acquire real online user traffic data, which includes multiple first fields. The method identifies and determines combinations of interface addresses and request methods from the real traffic data as basic units. Based on these basic units, it iterates through the real traffic data to determine the number of unique values ​​and the total number of requests corresponding to each first field. Based on the number of unique values ​​and the total number of requests for each first field, it determines whether the corresponding first field is a feature field. Based on the combination information of different feature fields, it identifies and determines the real usage scenario from the real traffic data. Therefore, it is possible to extract feature fields with business meaning from real traffic data, and then reconstruct the real user usage scenario through field combination clustering. This achieves automated and intelligent mapping from raw traffic to high-value business scenarios, providing a real and objective business basis for test design.

[0014] Additional aspects and advantages of this disclosure will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0015] The above and / or additional aspects and advantages of this disclosure will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, in which: Figure 1 This is a schematic flowchart of a scene recognition method proposed in an embodiment of this disclosure; Figure 2 This is a schematic flowchart of a scene recognition method proposed in another embodiment of this disclosure; Figure 3 This is a flowchart illustrating the process of identifying real-world scenario information using factor analysis as proposed in this disclosure; Figure 4 This is a schematic diagram of the structure of a scene recognition device according to an embodiment of the present disclosure; Figure 5 This is a block diagram of an electronic device according to an embodiment of the present application. Detailed Implementation

[0016] Embodiments of this disclosure are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are used only to explain this disclosure, and should not be construed as limiting this disclosure. Rather, embodiments of this disclosure include all variations, modifications, and equivalents falling within the spirit and scope of the appended claims.

[0017] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0018] Figure 1 This is a schematic flowchart of a scene recognition method proposed in an embodiment of this disclosure.

[0019] It should be noted that the execution subject of the scene recognition method in this embodiment is a scene recognition device, which can be implemented by software and / or hardware. The device can be configured in an electronic device, which may include, but is not limited to, a terminal, a server, etc., such as a mobile phone, a PDA, etc.

[0020] like Figure 1 As shown, the scene recognition method includes: S101: Obtain the actual online traffic data of users, where the actual traffic data includes multiple first fields.

[0021] This refers to request data generated by users during actual software use (in a production environment) and recorded by the system. Examples include website access logs, tracking data reported by the app, and API request records received by the server. This real traffic data is distinct from "simulated" data created by testers.

[0022] The first field can refer to a field in the actual traffic data. A field, on the other hand, refers to an attribute or key-value pair in the data. In an API request, a field might refer to: query parameters in the URL (such as name in ?name=Tom), request headers (such as User-Agent), or JSON attributes in the request body (such as age in {"age": 25}).

[0023] For example, in this embodiment of the disclosure, permission to collect production traffic from the system and a token for analysis can be requested. After authorization is obtained, recording can be performed on the traffic platform, and real traffic can be collected based on the dimensions of application, interface, or method. After collecting traffic data, a traffic recording ID will be generated.

[0024] In this embodiment of the disclosure, by obtaining real online traffic data of users, reliable data support can be provided for subsequent identification and determination of real usage scenarios.

[0025] S102: Identify and determine the combination of interface address and request method from real traffic data as the basic unit.

[0026] The interface address usually refers to the URL (Uniform Resource Locator), which is the path of the API call.

[0027] The request method can refer to the action defined by the HTTP protocol, such as GET (get), POST (create), PUT (modify), and DELETE (delete).

[0028] In this embodiment of the disclosure, the two are combined as the basic unit because in the design of RESTful API, different methods for the same address represent different resource operations (for example, GET / user and POST / user are two completely different interfaces) and must be treated separately.

[0029] S103: Traverse the real traffic data based on the basic unit to determine the number of unique values ​​and the total number of requests corresponding to each first field.

[0030] The number of unique values ​​can be the number of different values ​​that a specific field takes in all requests.

[0031] The total number of requests can refer to the total number of times this interface (i.e., that "basic unit") is called within the statistical time window.

[0032] For example, for the "city" field, if in 100 requests, some people fill in city A, some fill in city B, and some fill in city C, resulting in a total of 3 different city names, then the number of unique values ​​is 3, and the total number of requests is 100.

[0033] S104: Determine whether the corresponding first field is a feature field based on the number of unique values ​​in the first field and the total number of requests.

[0034] Among them, feature fields can refer to those fields that best represent the business characteristics of this interface.

[0035] For example, in a weather query interface, "city ID" might be a feature field.

[0036] In this embodiment of the disclosure, when determining whether the corresponding first field is a feature field based on the number of unique values ​​of the first field and the total number of requests, it can be based on a pre-trained machine learning model, or it can be based on a combination of numerical and graphical methods, and there are no restrictions on this.

[0037] Optionally, in some embodiments, when determining whether the first field is a feature field based on the number of unique values ​​and the total number of requests, the ratio of the number of unique values ​​to the total number of requests can be used; when the ratio is less than a preset threshold, the corresponding first field is determined to be a feature field. This establishes a simple and efficient filtering mechanism that can quickly filter out low-value fields with highly repetitive values ​​and accurately identify core feature fields with rich value variations that best reflect business differences, thereby significantly improving the accuracy and computational efficiency of scene recognition.

[0038] In other words, the HLL probabilistic cardinality estimation algorithm can be used in this embodiment to traverse traffic data in units of "interface + method" and count the number of unique values ​​(M) and the total number of requests (N) for each field. Then, the ratio of M / N is calculated, and when this value is lower than a preset threshold, the field can be determined as a feature field (i.e., a factor).

[0039] The preset threshold can refer to a pre-defined numerical limit. For example, setting the threshold to 0.3 means that only fields with a ratio less than 0.3 are considered feature fields. This value can be adjusted according to different business scenarios.

[0040] It is understandable that traffic data may contain highly repetitive low-value fields (such as status codes and fixed identifiers). These low-value fields may generate additional computational costs. Therefore, filtering can be performed by determining the ratio of the number of unique values ​​to the total number of requests to improve computational efficiency and reduce costs.

[0041] Optionally, in some embodiments, after identifying the feature fields, all identified feature fields can be deduplicated. This eliminates duplicate feature items caused by data sources or business logic, ensuring the purity and uniqueness of the feature set, and avoiding weight bias or redundant calculations due to duplicate fields during subsequent scene clustering, thereby optimizing the accuracy of scene identification.

[0042] For example, in embodiments of this disclosure, a Bloom filter can be used to efficiently deduplicate all identified factors.

[0043] Understandably, when traversing traffic data, the same "factor" (i.e., feature field) may be identified repeatedly. For example, the "product ID" field might be identified as a factor in tens of thousands of requests. Without deduplication, recording it every time it's identified would generate a large amount of redundant data. Deduplication ensures that each factor retains only one unique record in the system, making the analysis results more concise and reducing maintenance costs. When combining factors to form "scenes" later, data needs to be retrieved from a unique, non-repeating "factor library." Deduplication guarantees that each factor in this "factor library" (such as "city ID" or "product type") is unique. If the factors themselves are duplicated, the scene statistics and matching built based on them will become chaotic and erroneous.

[0044] S105: Identify and determine real-world usage scenarios from real traffic data based on combinations of different feature fields.

[0045] In real-world usage scenarios, this can be used to instruct online users on what actions they are actually performing.

[0046] Understandably, multiple feature fields are combined according to specific rules to form a specific combination scenario. By recording these feature field combinations, the system can accurately identify what kind of operation the user is performing (e.g., checking the weather in Beijing versus checking the weather in Shanghai; buying product A versus buying product B).

[0047] In this embodiment, real online user traffic data is acquired, including multiple first fields. Combinations of interface addresses and request methods are identified from the real traffic data as basic units. Based on these basic units, the real traffic data is traversed to determine the number of unique values ​​and the total number of requests corresponding to each first field. Based on the number of unique values ​​and the total number of requests for each first field, it is determined whether the corresponding first field is a feature field. Based on the combination information of different feature fields, real usage scenarios are identified from the real traffic data. Therefore, feature fields with business meaning can be extracted from the real traffic data, and then the real user usage scenarios can be reconstructed through field combination clustering. This achieves automated and intelligent mapping from raw traffic to high-value business scenarios, providing a real and objective business basis for test design.

[0048] Figure 2 This is a flowchart illustrating a scene recognition method proposed in another embodiment of this disclosure.

[0049] like Figure 2 As shown, the scene recognition method includes: S201: Obtain the actual online traffic data of users, wherein the actual traffic data includes multiple first fields.

[0050] S202: Identify and determine the combination of interface address and request method as the basic unit from real traffic data.

[0051] S203: Traverse the real traffic data based on the basic unit to determine the number of unique values ​​and the total number of requests corresponding to each first field.

[0052] S204: Determine whether the corresponding first field is a feature field based on the number of unique values ​​in the first field and the total number of requests.

[0053] S205: Identify and determine real-world usage scenarios from real traffic data based on combinations of different feature fields.

[0054] The descriptions of S201-S205 can be found in the above embodiments, and will not be repeated here.

[0055] S206: Generate test cases based on real-world usage scenarios.

[0056] In software testing, a test case can refer to a set of data, including inputs, execution conditions, and expected results, designed to verify a specific function or scenario. For example, it can refer to API request data constructed based on identified "real-world usage scenarios."

[0057] Optionally, in some embodiments, when generating test cases based on real-world usage scenarios, the frequency of occurrence of each real-world usage scenario can be determined; based on the frequency of occurrence, the test priority of the corresponding real-world usage scenario can be determined; and based on the test priority, test cases corresponding to the real-world usage scenarios can be generated. This enables intelligent and differentiated allocation of test resources, ensuring that frequently occurring core business scenarios receive the highest test priority, while low-frequency peripheral scenarios have their priority reduced accordingly. This ensures that limited testing manpower and time can first cover the business paths that have the greatest impact on users, maximizing the return on investment in testing.

[0058] Frequency of occurrence refers to the number of times or how often a real-world usage scenario appears in the raw traffic data. If one scenario occurs 1 million times a day, while another scenario only occurs once a day, the former has a very high frequency of occurrence.

[0059] Test priority refers to the priority of a specific use case during the testing process. Higher priority means higher resource usage and earlier execution order. In this disclosure, scenarios with higher frequency of use have higher test priority.

[0060] In other words, in this embodiment of the present disclosure, after determining the actual use scenario, corresponding test cases can be configured for that scenario to ensure the relevance of the testing process and achieve the rational use of limited testing resources.

[0061] S207: Execute test cases to obtain test traffic data, wherein the test traffic data includes multiple second fields.

[0062] Test traffic data can refer to the response data returned by the system under test after executing test cases, or the request data simulated by the test tool.

[0063] The second field refers to the field in the test traffic data.

[0064] In other words, in this embodiment of the present disclosure, traffic data can be collected during the execution of test cases, thereby providing reliable data support for subsequent identification and determination of test use scenarios.

[0065] S208: Identify and determine the feature field from multiple second fields.

[0066] The method used in this embodiment to identify and determine the feature field from multiple second fields can be found in the above description of determining whether the first field is a feature field, and will not be repeated here.

[0067] S209: Identify and determine the test usage scenario from the test traffic data based on the combination of information from different feature fields.

[0068] The "test use case" can refer to a scenario identified from test traffic data. For example, if the original intention was to test the real-world scenario of "paid user search," the scenario identified from the test traffic after execution is the "test use case." This test use case can be compared with the real-world use case to observe whether they are consistent.

[0069] In other words, in this embodiment of the disclosure, after identifying and determining the real-world usage scenario, test cases can be generated based on the real-world usage scenario; the test cases are executed to obtain test traffic data, wherein the test traffic data includes multiple second fields; feature fields are identified and determined from the multiple second fields; and test usage scenarios are identified and determined from the test traffic data based on the combination information of different feature fields. Therefore, not only can high-fidelity test cases be generated based on real traffic, but also by executing the test and re-identifying the scenario, the effectiveness of the test data can be intuitively verified as successfully simulating real user behavior, achieving self-verification and quantitative evaluation of test effectiveness.

[0070] S210: Determine the matching results between the test use case and the real use case in the database.

[0071] The matching results can be used to indicate whether the test use case matches a real use case in the database.

[0072] Optionally, in some embodiments, the database is constructed as follows: key information is extracted from real traffic data, wherein the key information includes at least: application source, and / or interface address, and / or request method, and / or feature fields, and / or real use case; the key information is persisted to the database. Thus, an enterprise-level interface scenario knowledge base that is accumulative, traceable, and reusable can be constructed. The resulting database can not only support coverage calculation for the current project, but also serve as a historical baseline for regression testing scope assessment, and provide a reference model for scenario identification of new interfaces, achieving effective accumulation of test assets.

[0073] The application source can be used to indicate the specific application that generated the aforementioned actual traffic data.

[0074] In this embodiment of the disclosure, when the matching result between the test usage scenario and the real usage scenario in the database is determined, reliable data support can be provided for subsequent calculation of test coverage.

[0075] S211: Calculate the test coverage based on the matching results.

[0076] Test coverage can refer to scenario coverage, which is the proportion of the obtained test scenarios among all real-world use cases. For example, if 40 test scenarios are obtained, and there are 100 real-world use cases in the database, and the matching results indicate that 30 of the 40 test scenarios successfully match the real-world use cases in the database, then the corresponding test coverage is 30 / 100 = 30%.

[0077] In other words, after identifying and determining the test use scenario in this embodiment, the matching result between the test use scenario and the real use scenario in the database can be determined; based on the matching result, the test coverage rate is calculated. Therefore, accurate assessment of test quality can be achieved from the dimension of business scenario coverage, providing more business-value-added data support for test integrity.

[0078] In this embodiment, test cases are generated based on real-world usage scenarios; these test cases are executed to obtain test traffic data, which includes multiple second fields; feature fields are identified from these second fields; and test usage scenarios are identified from the test traffic data based on combinations of different feature fields. This not only enables the generation of high-fidelity test cases based on real traffic but also allows for intuitive verification of whether the test data successfully simulates real user behavior by executing tests and re-identifying scenarios, achieving self-verification and quantitative evaluation of test effectiveness. The matching results between the test usage scenarios and real-world usage scenarios in the database are determined; test coverage is calculated based on the matching results. This allows for accurate evaluation of test quality from the perspective of business scenario coverage, providing more business-value-added data support for test completeness.

[0079] Understandably, during user operations, the frontend calls server-side interfaces via parameter combinations, the backend processes the logic based on the parameters and returns the results, and the frontend ultimately renders and displays the results. Each user operation may trigger one or more server-side interface calls. This solution collects real online user traffic, analyzes user request data, filters valid information, extracts feature fields (i.e., "factors"), and identifies combinations of multiple factors. The system records the scenario information, frequency of occurrence, interface details, method information, and application source for each combination, thereby accurately identifying various combinations of application interfaces and locating high-frequency scenarios. Based on this data, it can accurately cover real online usage scenarios, ensure the stability of each user operation scenario, effectively guarantee delivery quality, reduce deployment risks, and continuously improve user experience. Figure 3 As shown, Figure 3 This is a flowchart illustrating the process of identifying real-world scenario information using factor analysis, as proposed in this disclosure.

[0080] Figure 4This is a schematic diagram of the structure of a scene recognition device proposed in an embodiment of this disclosure.

[0081] like Figure 4 As shown, the scene recognition device 40 includes: The acquisition module 401 is used to acquire the actual online traffic data of users, wherein the actual traffic data includes multiple first fields; The first determining module 402 is used to identify and determine the combination of interface address and request method as a basic unit from real traffic data; The second determining module 403 is used to traverse the real traffic data based on the basic unit to determine the number of unique values ​​and the total number of requests corresponding to each first field. The third determining module 404 is used to determine whether the corresponding first field is a feature field based on the number of unique values ​​in the first field and the total number of requests; The fourth determination module 405 is used to identify and determine the real usage scenario from real traffic data based on the combination information of different feature fields.

[0082] It should be noted that the foregoing explanation of the scene recognition method also applies to the scene recognition device of this embodiment, and will not be repeated here.

[0083] In this embodiment, real online user traffic data is acquired, including multiple first fields. Combinations of interface addresses and request methods are identified from the real traffic data as basic units. Based on these basic units, the real traffic data is traversed to determine the number of unique values ​​and the total number of requests corresponding to each first field. Based on the number of unique values ​​and the total number of requests for each first field, it is determined whether the corresponding first field is a feature field. Based on the combination information of different feature fields, real usage scenarios are identified from the real traffic data. Therefore, feature fields with business meaning can be extracted from the real traffic data, and then the real user usage scenarios can be reconstructed through field combination clustering. This achieves automated and intelligent mapping from raw traffic to high-value business scenarios, providing a real and objective business basis for test design.

[0084] According to embodiments of this application, this application also provides an electronic device and a readable storage medium.

[0085] Figure 5 This is a block diagram of an electronic device according to an embodiment of the present application.

[0086] like Figure 5 As shown, the electronic device includes: The memory 501, the processor 502, and the computer instructions stored in the memory 501 and executable on the processor 502.

[0087] When processor 502 executes instructions, it implements the scene recognition method provided in the above embodiments.

[0088] Furthermore, electronic devices also include: Communication interface 503 is used for communication between memory 501 and processor 502.

[0089] Memory 501 is used to store computer instructions that can be executed on processor 502.

[0090] Memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0091] The processor 502 is used to implement the scene recognition method of the above embodiments when executing the program.

[0092] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0093] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0094] Processor 502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0095] This application also proposes a computer program product that implements the scene recognition method of the embodiments of this application when the instruction processor in the computer program product is executed.

[0096] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0097] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0098] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0099] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0100] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0101] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0102] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0103] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A scene recognition method, characterized in that, include: Obtain real online traffic data of users, wherein the real traffic data includes multiple first fields; The combination of interface address and request method is identified and determined as the basic unit from the real traffic data; Based on the basic unit, the real traffic data is traversed to determine the number of unique values ​​and the total number of requests corresponding to each of the first fields; Based on the number of unique values ​​in the first field and the total number of requests, determine whether the corresponding first field is a feature field; Based on the combination of different feature fields, the real usage scenarios are identified and determined from the real traffic data.

2. The method as described in claim 1, characterized in that, The step of determining whether the first field is a feature field based on the number of unique values ​​in the first field and the total number of requests includes: Determine the ratio of the number of unique values ​​to the total number of requests; When the ratio is less than a preset threshold, the first field is determined to be the feature field.

3. The method as described in claim 1, characterized in that, After determining whether the first field is a feature field based on the number of unique values ​​of the first field and the total number of requests, the method further includes: All identified feature fields are deduplicated.

4. The method as described in claim 1, characterized in that, The method further includes: Based on the described real-world usage scenarios, generate test cases; The test cases are executed to obtain test traffic data, wherein the test traffic data includes multiple second fields; The feature field is identified from a plurality of the second fields; Based on the combination of different feature fields, the test usage scenario is identified and determined from the test traffic data.

5. The method as described in claim 4, characterized in that, The step of generating test cases based on the real-world usage scenario includes: Determine the frequency of occurrence of each of the aforementioned real-world use scenarios; Based on the frequency of occurrence, determine the test priority corresponding to the real-world usage scenario; Based on the test priority, test cases corresponding to the real-world usage scenario are generated.

6. The method as described in claim 4, characterized in that, The method further includes: Determine the matching results between the test use scenario and the real use scenario in the database; Based on the matching results, the test coverage is calculated.

7. The method as described in claim 6, characterized in that, The database is constructed based on the following method: Key information is extracted from the real traffic data, wherein the key information includes at least: application source, and / or the interface address, and / or the request method, and / or the feature fields, and / or the real usage scenario; The key information is persisted to the database.

8. A scene recognition device, characterized in that, include: The acquisition module is used to acquire real online traffic data of users, wherein the real traffic data includes multiple first fields; The first determining module is used to identify and determine the combination of interface address and request method from the real traffic data as a basic unit; The second determining module is used to traverse the real traffic data based on the basic unit to determine the number of unique values ​​and the total number of requests corresponding to each of the first fields. The third determining module is used to determine whether the first field is a feature field based on the number of unique values ​​of the first field and the total number of requests; The fourth determining module is used to identify and determine the real usage scenario from the real traffic data based on the combination information of different feature fields.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, in, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-7.

Images