Risk control policy testing method and device, electronic equipment and storage medium
By establishing a request-level isolation sandbox and using data simulation middleware to generate simulated data in risk control strategy testing, the problems of mutual interference in configuration and low data construction efficiency in risk control strategy testing are solved, thereby improving the stability and efficiency of automated testing and shortening the testing cycle.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING BAIJU YIXING TECH CO LTD
- Filing Date
- 2025-12-29
- Publication Date
- 2026-05-29
Smart Images
Figure CN122111835A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software testing technology, specifically to testing methods, devices, electronic equipment, and storage media for risk control strategies. Background Technology
[0002] In risk control systems for ride-hailing software operations (Software as a Service, SaaS), business operations heavily rely on dynamically configurable risk control rules and strategies. These strategies typically make real-time decisions based on multi-dimensional conditions such as user channels, order types, geographic locations, and customer tags. To ensure the accuracy and effectiveness of these strategies, test engineers need to conduct extensive and frequent testing.
[0003] In related technologies, risk control strategy testing typically relies on an independent testing environment with globally effective strategy configurations. When multiple test cases are executed in parallel, their modifications to the global configuration can overwrite each other, leading to severe test interference ("configuration pollution"). Furthermore, risk control decisions heavily depend on complex upstream business data (such as orders and user profiles). Testing requires manually constructing full-scale simulated data, a cumbersome process that struggles to simulate realism, resulting in low testing efficiency and insufficient coverage.
[0004] In other words, in related technologies, risk control testing suffers from problems such as mutual interference in configurations, low efficiency in constructing test data, and long testing cycles for risk control strategies. Summary of the Invention
[0005] This application provides a method, apparatus, electronic device, and storage medium for testing risk control strategies, in order to solve the problems of mutual interference in configuration, low efficiency in constructing test data, and long testing cycle of risk control strategies in risk control testing.
[0006] Firstly, this application provides a method for testing a risk control strategy, the method comprising: Based on the test scenario description file, a request-level isolation sandbox is established, and the corresponding private risk control strategy configuration is loaded for the isolation sandbox. The test scenario description file declares the data target, which is used to describe the target conditions that the upstream data required for the test should meet. In response to triggered risk control decision requests, the upstream data for simulation is determined through data simulation middleware based on the data objectives; Risk control decisions are made based on private risk control strategy configuration and simulated upstream data, and the decision results are compared with the expected results to generate a test report.
[0007] In one optional implementation, a request-level isolation sandbox is established, and a corresponding private risk control strategy configuration is loaded for the isolation sandbox, including: Generate a unique sandbox identifier; Save the private risk control strategy configuration as a configuration snapshot bound to the sandbox identifier.
[0008] In one alternative implementation, based on the data target, the simulated upstream data is determined through data simulation middleware, including: Send the data target to the data simulation middleware; The data simulation middleware determines the upstream data for simulation based on the target conditions.
[0009] In one alternative implementation, the test scenario description file includes: a sandbox identifier, a policy configuration snapshot identifier, a data target, trigger input data, and expected results.
[0010] In one alternative implementation, following the triggering of a risk control decision request, the method further includes: Obtain the sandbox identifier of the isolation sandbox from the risk control decision request; Based on the sandbox identifier, load the corresponding private risk control strategy configuration.
[0011] In one alternative implementation, comparing the decision result with the expected result to generate a test report includes: The actual results of the risk control decision output are compared with the expected results defined in the test scenario description file to obtain the comparison results; Based on the comparison results, a test report containing the execution status of the test cases is generated.
[0012] Secondly, this application provides a testing device for risk control strategies, the device comprising: The configuration loading module is used to establish a request-level isolation sandbox based on the test scenario description file, and load the corresponding private risk control strategy configuration for the isolation sandbox. The test scenario description file declares the data target, which describes the target conditions that the upstream data required for the test should meet. The data determination module is used to respond to triggered risk control decision requests and determine simulated upstream data through data simulation middleware based on the data target. The report generation module is used to make risk control decisions based on private risk control strategy configuration and simulated upstream data, and compare the decision results with the expected results to generate a test report.
[0013] Thirdly, this application provides an electronic device, including: a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes the computer instructions to perform a test method for the risk control strategy described in the first aspect or any of its corresponding embodiments.
[0014] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute a test method for a risk control strategy according to the first aspect or any corresponding embodiment described above.
[0015] Fifthly, this application provides a computer program product, including computer instructions, which are used to cause a computer to execute the risk control strategy described in the first aspect or any of its corresponding embodiments, and a testing method thereof.
[0016] The testing method for the risk control strategy proposed in this application achieves the following beneficial technical effects compared to existing technologies: Based on the test scenario description file, a request-level isolation sandbox is established, and corresponding private risk control strategy configurations are loaded for the sandbox. The test scenario description file declares the data objectives, which describe the target conditions that the upstream data required for the test should meet. This achieves request-level isolation of the risk control strategy configuration, completely eliminating configuration contamination when different test cases are executed in parallel, fundamentally improving the stability and success rate of automated testing. In response to triggered risk control decision requests, based on the data objectives, simulated upstream data is determined through data simulation middleware, thus transforming test data preparation from manually constructing specific data values to... By clearly defining the target data conditions, intelligent middleware automatically generates realistic simulated data, greatly improving the efficiency and authenticity of test data preparation. Based on private risk control strategy configurations and simulated upstream data, risk control decisions are made, and the decision results are compared with expected results to generate test reports. This achieves a fully automated closed loop from test case description, data preparation, strategy execution to result verification, significantly shortening the testing and verification cycle of risk control strategies. It also generates standardized test reports, improving the maintainability and reusability of the testing process, eliminating mutual interference in risk control test configurations, improving the efficiency of test data construction, and shortening the testing cycle of risk control strategies. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0018] Figure 1 This is a flowchart illustrating a testing method for a risk control strategy according to an embodiment of this application; Figure 2 This is a flowchart illustrating a testing method for another risk control strategy according to an embodiment of this application; Figure 3 This is a structural block diagram of a testing device for a risk control strategy according to an embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0020] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.
[0021] Traditional testing methods mainly rely on: 1. Set up an independent testing environment: Maintain a complete system isolated from the production environment and conduct tests within it. 2. Manually construct test data: Based on the test cases, manually create or call the interface to generate upstream data such as orders and users in the database. 3. Modify global configuration: Modify the risk control strategy configuration in the test environment to make it effective for all requests in the current environment, and then execute the test cases. Current risk control system testing faces two core contradictions: 1. Global Configuration Pollution: Traditional risk control strategy configurations use a static, globally effective mode, causing interference between different test cases (such as those from different channels or order types) when executed in parallel. For example, a customer's risk control rule test may unexpectedly trigger strategies from other business lines, resulting in a 20%-30% failure rate for automated tests. 2. Upstream data dependence: Risk control decisions rely on more than 10 types of external system data such as orders and driver status. Traditional Mock tools require manual construction of the entire data chain.
[0022] In view of the above, this application aims to overcome the aforementioned shortcomings and provide a highly isolated, data-driven, and declarative risk control strategy testing solution.
[0023] According to an embodiment of this application, a method embodiment for testing risk control strategies is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0024] This embodiment provides a method for testing risk control strategies, which can be used on server-side devices such as servers and workstations. Figure 1 This is a flowchart of a testing method for a risk control strategy according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps: Step S101: Based on the test scenario description file, establish a request-level isolation sandbox and load the corresponding private risk control strategy configuration for the isolation sandbox. The test scenario description file declares the data target, which is used to describe the target conditions that the upstream data required for the test should meet.
[0025] Specifically, a test scenario description file is a structured file that defines complete test cases, for example: {"sandbox_id": "SB001", "data_goals": [{"field": "order_amount", "operator":"gt", "value": 5000}]}. An isolation sandbox is a dynamically created, logically isolated virtual execution environment for a single test request. Its core is a unique sandbox identifier (ID) used to distinguish different tests. Private risk control policy configuration refers to a set of risk control rules that only take effect within this isolation sandbox, such as specific review rules for "large orders," which do not affect the configurations of other tests. A data target is a statement describing the data characteristics required for the test, not a specific value, for example, an order amount greater than 5000 yuan.
[0026] After reading the description file, the system creates a unique sandbox ID and loads the risk control strategy configuration specified in the file into this sandbox in a "private" manner. This achieves "request-level policy configuration isolation." This ensures that each test case runs under its own exclusive policy rules, eliminating inter-test interference (i.e., "configuration pollution") caused by globally shared configurations at the source, and laying the foundation for test stability and parallel execution.
[0027] Step S102: In response to the triggered risk control decision request, determine the simulated upstream data through the data simulation middleware according to the data target.
[0028] Specifically, a risk control decision request refers to a trigger instruction that requires the risk control system to perform a risk assessment on a specific business scenario (such as a transaction), for example: {"action": "evaluate_risk", "order_id": "simulated order 001"}. Data simulation middleware refers to an independent intelligent service. It receives abstract data targets (such as "high amount") and automatically returns realistic, specific data that matches the target. Simulated upstream data refers to business data dynamically generated by the middleware that meets testing requirements, such as the details of a simulated order with a status of "unpaid" and an amount of "8888 yuan".
[0029] When the test is executed, the system sends a request to the data simulation middleware based on the "data objectives" described in S101. This middleware understands these abstract objectives and intelligently generates or matches high-quality simulated data that meets the requirements for use by the risk control engine. This transforms test data preparation from "manually constructing specific values" to "declaring data characteristics." It greatly simplifies and accelerates the test data preparation process while ensuring the authenticity and complexity of the data's business logic, solving the problems of time-consuming, labor-intensive, and unrealistic data construction in traditional methods.
[0030] Step S103: Make risk control decisions based on private risk control strategy configuration and simulated upstream data, and compare the decision results with the expected results to generate a test report.
[0031] Specifically, the decision result refers to the actual risk assessment output by the risk control strategy platform after running based on private configurations and simulated data, for example: {"risk_level": "HIGH", "action": "REJECT"}. The expected result refers to the correct result that the test case should theoretically achieve, as predefined in the test scenario description file. The test report is a document automatically generated by the system, clearly listing the actual result, expected result, and pass / fail status of each test case.
[0032] Within an isolated sandbox, the risk control engine uses its proprietary configuration to calculate simulated data and derive actual decision results. The system then automatically compares these results with the pre-defined expected results in the description file. Its core effect is to achieve an "automated closed loop of testing and verification." This completely replaces the manual verification process, not only improving testing efficiency but also ensuring the accuracy and objectivity of verification, and directly generating structured test reports, making testing activities traceable and measurable.
[0033] The risk control strategy testing method provided in this embodiment establishes a request-level isolation sandbox based on a test scenario description file and loads the corresponding private risk control strategy configuration into the sandbox. The test scenario description file declares data objectives, which describe the target conditions that the upstream data required for the test should meet. This achieves request-level isolation of the risk control strategy configuration, completely eliminating configuration contamination when different test cases are executed in parallel, fundamentally improving the stability and success rate of automated testing. In response to triggered risk control decision requests, the simulated upstream data is determined through data simulation middleware based on the data objectives, thus preparing the test data from manually constructed... The system transforms volumetric data values into declarative data target conditions, and intelligent middleware automatically generates realistic simulated data, greatly improving the efficiency and authenticity of test data preparation. Based on private risk control strategy configurations and simulated upstream data, risk control decisions are made, and the decision results are compared with expected results to generate test reports. This achieves a fully automated closed loop from test case description, data preparation, strategy execution to result verification, significantly shortening the testing and verification cycle of risk control strategies. It also generates standardized test reports, improves the maintainability and reusability of the testing process, eliminates mutual interference in risk control test configurations, improves the efficiency of test data construction, and shortens the testing cycle of risk control strategies.
[0034] In one possible implementation, step S101 above, which involves establishing a request-level isolation sandbox and loading the corresponding private risk control strategy configuration for the isolation sandbox, includes: Step a1: Generate a unique sandbox identifier.
[0035] Step a2: Save the private risk control strategy configuration as a configuration snapshot bound to the sandbox identifier.
[0036] Specifically, a sandbox identifier refers to a unique identifier (ID) automatically generated by the system for a single test session. The sandbox identifier is the core of the isolated environment. For example, a system-generated string SB_OrderRisk_20231027_001 uniquely identifies the test throughout its entire lifecycle. A configuration snapshot refers to a fixed-version copy of the entire set of risk control strategy rules and parameters to be tested, saved at a specific point in time. For example, a JavaScript Object Notation (JSON) configuration file containing all rule thresholds, blacklists, whitelists, and decision-making processes, whose contents are frozen and stored.
[0037] When a test starts, the system first dynamically generates a unique sandbox identifier, which is equivalent to assigning a unique "room number" to that test. Then, the test-specific risk control strategy configuration is saved as a separate snapshot file, and this file is strongly bound to the sandbox identifier, essentially placing a specific "rule manual" in the corresponding room. This achieves precise isolation and persistent management of strategy configurations. Through the unique identifier, the system can accurately distinguish and route each test request; through snapshot binding, it ensures that each test case uses its own exclusive and unchanging strategy version from beginning to end. This technically eliminates interference between tests caused by shared configurations or temporary modifications, greatly ensuring the determinism and reproducibility of test results.
[0038] In one possible implementation, step S102 above, determining the simulated upstream data according to the data target through the data simulation middleware, includes: Step b1: Send the data target to the data simulation middleware.
[0039] Step b2: The data simulation middleware determines the upstream data for simulation based on the target conditions.
[0040] In this implementation, the core mechanism of data simulation lies in "declarative interaction." The test execution engine does not concern itself with specific data details; it only sends the "data target" expressing the test intent (e.g., "an unpaid order from a high-risk user") as a complete query request to the data simulation middleware. This middleware, acting as an intelligent data service, is responsible for receiving and parsing such abstract targets. Through its internal rule engine or historical data pattern matching algorithm, it automatically makes decisions and generates or retrieves a specific, realistic data record that meets all constraints (e.g., order details belonging to user Zhang San, amounting to 8888 yuan, and with a status of "pending payment"), thus completing the deterministic transformation from "target description" to "usable data."
[0041] This implementation method brings about a fundamental shift in testing paradigms and a significant improvement in efficiency. Its technical benefits are first reflected in liberating test data preparation from the tedious and inefficient "manual field-by-field construction" mode to a highly efficient "declaration of intent, automatic retrieval" mode, greatly shortening data preparation time. More importantly, it ensures the authenticity, compliance, and diversity of simulated data in business logic through intelligent middleware, effectively improving the depth and breadth of test coverage. Ultimately, this method achieves complete decoupling between test logic and underlying data construction, allowing test designers to focus on the business scenario itself, rather than data implementation details, thereby significantly improving the maintainability and iterative agility of test cases.
[0042] In one possible implementation, the test scenario description file includes: a sandbox identifier, a policy configuration snapshot identifier, a data target, trigger input data, and expected results.
[0043] Specifically, the test scenario description file is a structured list (such as a JSON / YAML file) that encapsulates all the elements required to execute a complete test. The sandbox identifier specifies the isolation environment ID dedicated to this test (e.g., SB_001); the policy configuration snapshot identifier points to the specific risk control rule version to be tested (e.g., Config_V2.1); the data target declares the required data characteristics (e.g., "order amount > 5000"); the trigger input data is the initial request to initiate the risk control assessment (e.g., user ID and order number); and the expected result defines the decision that the test case should theoretically output (e.g., {"action": "REJECT"}). These five elements together constitute a self-contained, independently executable set of test instructions.
[0044] The core technical advantage of this implementation lies in achieving standardization, coding, and efficient management of test assets. By encapsulating scattered test elements into a structured description file, test cases gain version control and collaborative editing capabilities. This not only eliminates errors and confusion caused by inconsistencies in test parameters, configurations, or data target descriptions, but also enables the entire testing process to be seamlessly parsed and executed by an automated platform, fundamentally improving the maintainability, reusability, and iteration efficiency of the test suite.
[0045] In one possible implementation, after responding to the triggered risk control decision request in step S102 above, the method further includes: Step c1: Obtain the sandbox identifier of the isolation sandbox from the risk control decision request.
[0046] Step c2: Load the corresponding private risk control strategy configuration based on the sandbox identifier.
[0047] This implementation clarifies the specific mechanism by which the risk control engine accurately associates with its private configuration during execution. When the system receives a risk control decision request, it first extracts the sandbox identifier bound to this test from specific fields or context of the request. Subsequently, the system uses the sandbox identifier to find and load the private risk control strategy configuration pre-bound to it, serving as the sole rule basis for this decision.
[0048] This implementation method achieves precise routing and configuration isolation at the request level. It ensures that the risk control engine can dynamically and accurately switch to the corresponding private rule set when processing each test request, thereby strictly guaranteeing the independence and purity of different test case execution environments at the technical level. This is a key technical guarantee for eliminating configuration pollution and enabling parallel execution of tests.
[0049] In one possible implementation, the step S103 above, comparing the decision result with the expected result to generate a test report, includes: Step d1: Compare the actual results of the risk control decision output with the expected results defined in the test scenario description file to obtain the comparison results; Step d2: Based on the comparison results, generate a test report containing the execution status of the test cases.
[0050] This implementation describes an automated closed-loop process for testing and verification. After the risk control engine outputs an actual result (e.g., {"Decision": "Reject"}) based on private configuration and simulated data, the system automatically and accurately compares it with the predefined expected result (e.g., {"Decision": "Reject"}) in the test scenario description file, generating a comparison result ("Consistent" or "Inconsistent"). Subsequently, based on this comparison result, the system automatically marks the corresponding test case as "Pass" or "Fail," and summarizes detailed information such as the execution status and actual output of all test cases, ultimately generating a structured test report.
[0051] This implementation method automates the entire process from test execution to result evaluation. It completely replaces manual observation and verification of results, greatly improving the efficiency and accuracy of the verification process, avoiding human error, and ensuring the consistency of evaluation criteria. Simultaneously, the automatically generated structured reports make test results clear at a glance, easy to trace and analyze, and provide direct support for the archiving of test assets and the measurement of test quality, which is key to the efficient closed-loop of the entire automated testing process.
[0052] Figure 2 This is a flowchart illustrating a testing method for another risk control strategy according to an embodiment of this application. As shown in the figure, the method is divided into four stages: test preparation and sandbox establishment -> Data Simulation Middleware (DSM) simulation of test data -> Platform execution and intelligent data simulation -> Test report.
[0053] The first phase involves test preparation and sandbox setup. This phase includes the following steps: Step 1: Test preparation and sandbox setup.
[0054] Procedure: The test engineer creates a new test session on the platform, and the system automatically generates a Sandbox-ID (e.g., SB_OrderRisk_A1). The test engineer then uploads the configuration JSON file for this new strategy and binds it to the Sandbox-ID, creating a Config-Snapshot. Step 2: Write the Test Scenario Descriptor (TSD).
[0055] Operation: The test engineer writes a TSD file that no longer cares about the specific order ID, but instead declares the data goals (data_goals).
[0056] Phase Two: Data-Driven Intelligent Simulation: DSM Simulation Test Data Operation: DSM finds the corresponding data_goals based on the Sandbox-ID in the request, and dynamically generates or matches simulated order and user data from the pool to a certain condition, and returns it to RSP.
[0057] Phase 3: Platform Execution and Intelligent Data Simulation. This phase includes the following steps: Step 1: The test platform executes the TSD, and the platform injects the Sandbox-ID: SB_OrderRisk_A1 into the risk control request. Step 2: The Risk Strategy Platform (RSP) receives the request, the configuration management module identifies the Sandbox-ID, and loads the private policy configuration bound to it. Step 3: In order to make a decision, RSP needs to query upstream data and DSM to match strategies. Phase 4: Decision-making and verification.
[0058] Operation: RSP executes risk control logic based on private configuration and simulated data, and arrives at a decision result ("High risk, secondary authentication required"). The platform automatically compares the actual result with the expected_result in TSD. If the platform confirms that the actual result is completely consistent with the expectation, the test case is marked as passed.
[0059] This risk control strategy testing method completely eliminates test interference: through sandbox isolation, different test cases can be executed in complete parallel without affecting each other, increasing the success rate of automated testing by over 80%. It significantly improves test data preparation efficiency: by changing from "manual field-by-field construction" to "declaring data targets," data preparation time is reduced from hours to minutes, while ensuring the authenticity and complexity of the data. It achieves standardized and reusable testing: TSD files codify test assets, facilitating version management, reuse, and sharing, improving the standardization and maintainability of testing. It accelerates risk control strategy iteration: the entire testing process is highly automated, shortening the testing and verification cycle of new strategies by 70%, enabling rapid response to business changes.
[0060] This embodiment also provides a risk control strategy testing device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0061] This embodiment provides a testing device for risk control strategies, such as... Figure 3 As shown, it includes: The configuration loading module 301 is used to establish a request-level isolation sandbox based on the test scenario description file, and load the corresponding private risk control strategy configuration for the isolation sandbox. The test scenario description file declares the data target, which describes the target conditions that the upstream data required for the test should meet. The data determination module 302 is used to determine the simulated upstream data through the data simulation middleware in response to the triggered risk control decision request, based on the data target; The report generation module 303 is used to make risk control decisions based on private risk control strategy configuration and simulated upstream data, and compare the decision results with the expected results to generate a test report.
[0062] In some alternative implementations, the configuration loading module 301 includes: A generation unit is used to generate a unique sandbox identifier; The configuration snapshot saving unit is used to save private risk control strategy configurations as configuration snapshots bound to the sandbox identifier.
[0063] In some alternative implementations, the data determination module 302 includes: The sending unit is used to send the data target to the data simulation middleware; The determination unit is used by the data simulation middleware to determine the upstream data for simulation based on the target conditions.
[0064] In some alternative implementations, the test scenario description file includes: sandbox identifier, policy configuration snapshot identifier, data target, trigger input data, and expected results.
[0065] In some alternative implementations, the data determination module 302, after responding to a triggered risk control decision request, further includes: The acquisition unit is used to obtain the sandbox identifier of the isolation sandbox from the risk control decision request; The loading unit is used to load the corresponding private risk control strategy configuration based on the sandbox identifier.
[0066] In some alternative implementations, the report generation module 303 includes: The comparison unit is used to compare the actual results of the risk control decision output with the expected results defined in the test scenario description file to obtain the comparison results; The report generation unit is used to generate a test report containing the execution status of test cases based on the comparison results.
[0067] The risk control strategy testing apparatus provided in this application embodiment can execute the risk control strategy testing method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.
[0068] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0069] The following is a detailed reference. Figure 4 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from memory 408 into random access memory (RAM) 403. The RAM 403 also stores various programs and data required for the operation of the electronic device. The processor 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.
[0070] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.
[0071] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from memory 408, or installed from ROM 402. When the computer program is executed by processor 401, it performs the functions defined in the risk control strategy testing method of embodiments of this application.
[0072] Figure 4 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0073] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the testing method for the risk control strategy shown in the above embodiments is implemented.
[0074] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.
[0075] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.
Claims
1. A testing method for a risk control strategy, characterized in that, The method includes: Based on the test scenario description file, a request-level isolation sandbox is established, and a corresponding private risk control strategy configuration is loaded for the isolation sandbox. The test scenario description file declares a data target, which is used to describe the target conditions that the upstream data required for the test should meet. In response to the triggered risk control decision request, simulated upstream data is determined through data simulation middleware based on the data target; Risk control decisions are made based on the private risk control strategy configuration and the simulated upstream data, and the decision results are compared with the expected results to generate a test report.
2. The method according to claim 1, characterized in that, The process of establishing a request-level isolation sandbox and loading the corresponding private risk control strategy configuration for the isolation sandbox includes: Generate a unique sandbox identifier; Save the private risk control strategy configuration as a configuration snapshot bound to the sandbox identifier.
3. The method according to claim 1, characterized in that, The step of determining the simulated upstream data through data simulation middleware based on the data target includes: The data target is sent to the data simulation middleware; The data simulation middleware determines the simulated upstream data based on the target conditions.
4. The method according to claim 1, characterized in that, The test scenario description file includes: sandbox identifier, policy configuration snapshot identifier, data target, trigger input data, and expected results.
5. The method according to claim 1, characterized in that, Following the response to the triggered risk control decision request, the following is also included: Obtain the sandbox identifier of the isolation sandbox from the risk control decision request; Based on the sandbox identifier, load the corresponding private risk control strategy configuration.
6. The method according to claim 1, characterized in that, The step of comparing the decision results with the expected results to generate a test report includes: The actual results of the risk control decision output are compared with the expected results defined in the test scenario description file to obtain the comparison results; Based on the comparison results, a test report containing the execution status of the test cases is generated.
7. A testing device for a risk control strategy, characterized in that, The device includes: The configuration loading module is used to establish a request-level isolation sandbox based on the test scenario description file, and load the corresponding private risk control strategy configuration for the isolation sandbox. The test scenario description file declares the data target, which is used to describe the target conditions that the upstream data required for the test should meet. The data determination module is used to determine simulated upstream data through data simulation middleware in response to a triggered risk control decision request, based on the data target. The report generation module is used to make risk control decisions based on the private risk control strategy configuration and the simulated upstream data, and compare the decision results with the expected results to generate a test report.
8. An electronic device, characterized in that, include: A memory and a processor are interconnected, the memory stores computer instructions, and the processor executes the computer instructions to perform the test method of the risk control strategy according to any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the test method of the risk control strategy according to any one of claims 1 to 6.
10. A computer program product, characterized in that, Includes computer instructions, said computer instructions being used to cause a computer to execute the test method of the risk control strategy according to any one of claims 1 to 6.