An options trading client based one-stop GUI automated testing method and device

Abstract

The application provides an option transaction client-based one-stop GUI automation test method and device, and relates to the technical field of software automation testing. The method constructs a one-stop GUI automation test system from data preparation, script component recording and compilation, requirement tree construction, scene design, scene component linkage and data driving, regression test set customization, test execution, maintenance and recovery, adapts to complex business scenarios and special controls of the option transaction client, realizes standardization and automation of the test process, significantly improves the regression test efficiency, reduces the script maintenance cost, and guarantees the stability and result accuracy of the test process.

Description

Technical Field

[0001] This application relates to the field of software automation testing technology, and in particular to a one-stop GUI automation testing method and apparatus based on an options trading client. Background Technology

[0002] Options, as a rapidly developing new type of financial derivative, have prompted major securities companies to design professional options trading clients. These clients serve as the entry point for professional options trading, with interfaces specifically designed for the characteristics of options trading. They offer features such as setting stop-loss and take-profit orders, pre-set conditional orders, risk control orders, order splitting, combined option exercise, and strategy combination trading. (See also...) Figure 1 The functional structure of the options trading system shown includes four core modules: vertical order placement, horizontal order placement, other order placement, and advanced trading functions. Each core module has corresponding functions.

[0003] With the rapid iteration of options trading systems, GUI (Graphical User Interface) automated testing has become a crucial part of quality assurance in regression testing for each version iteration, ensuring the quality of options trading client deployments. Here, GUI is a specific implementation of UI (User Interface), specifically referring to the interface through graphical elements such as windows, buttons, and icons. UI broadly refers to the interface between humans and machines; it's a general term that can be graphical, command-line based, voice-based, touch-based, etc.

[0004] With the continuous development of technology, a variety of mature test execution frameworks have emerged in the market, each with its own unique advantages and application scenarios. Currently, commonly used UI automation test script generation tools and frameworks include Selenium, Pywinauto, and TestComplete.

[0005] Among them, Selenium, as an open-source and highly compatible website automation testing tool and framework, is excellent. However, Selenium UI automation testing tool needs to run in a browser environment and can only be used for testing web applications and websites.

[0006] Pywinauto is a Python library for automating GUI testing, particularly suitable for testing applications on the Windows platform. It programmatically simulates user actions such as key presses, mouse movements, and window switching, achieving a high degree of automation in testing graphical user interfaces. However, compared to some visual testing tools, Pywinauto's test scripts may require more manual debugging, especially when dealing with non-standard controls or complex UI hierarchies. When performing large-scale or intensive testing tasks, Pywinauto's performance may not be as good as dedicated automation testing tools, as it is essentially a library rather than an optimized standalone application.

[0007] TestComplete excels in executing automated client-side GUI tests. Its built-in page object recording function accurately identifies and manipulates various GUI elements in client applications, ensuring test stability and accuracy even in complex and ever-changing UI environments. Its built-in test commands and functions simplify test script writing. Furthermore, TestComplete integrates a complete solution from test planning, execution, monitoring to reporting. However, while TestComplete's IDE (Integrated Development Environment) offers a range of advanced debugging and test management features, its rich functionality and accompanying documentation and training resources result in a high learning curve. When executing large-scale or complex tests, TestComplete's high-performance requirements may strain machine hardware specifications, thus limiting its deployment feasibility in resource-constrained environments. Despite its comprehensive functionality, TestComplete's customization and extensibility may not be as flexible as some open-source frameworks for certain specific needs.

[0008] Other mainstream test execution frameworks in the industry, such as Microsoft UI Automation (UIA), SikuliX, and AutoIt, also have obvious advantages and disadvantages. Microsoft UI Automation focuses on accessing and manipulating UI elements under the .NET framework, and its support for non-.NET applications is limited due to the limitations of the .NET framework. SikuliX is an image recognition-based automation testing framework that identifies controls and operations by comparing pixels on the screen, making it particularly suitable for interface elements lacking traditional identifiers. However, image recognition can be affected by resolution and color mode, leading to false positives, and test script maintenance is relatively difficult because even small changes to the interface can require a lot of script adjustments. AutoIt is a small scripting language specifically designed for Windows automation, often used to create installers or perform system administration tasks, but it is also suitable for GUI testing. However, its functionality is relatively limited, it does not support modern testing frameworks and methodologies, and it is somewhat inadequate for complex testing scenarios.

[0009] Each of the aforementioned automation frameworks has its own strengths and weaknesses, and none can perfectly meet all testing needs for systems like options trading clients, which have complex testing scenarios, special controls, and components. However, with the deepening of system functions and the acceleration of iteration speed, automated testing has become an indispensable part of ensuring software quality and promoting agile testing. How to tailor testing to the characteristics of options trading clients, through meticulous scripting, reasonable scenario design, efficient automation configuration, and rigorous test maintenance strategies, to adapt to the system's complexity, lower the testing threshold, ensure system quality and stability, while simultaneously reducing testing costs and time and improving overall testing efficiency, has become a pressing technical problem to be solved. Summary of the Invention

[0010] In view of the above problems, this application is proposed to provide a one-stop GUI automated testing method and apparatus based on an options trading client to overcome or at least partially solve the above problems. The technical solution is as follows: Firstly, a one-stop GUI automated testing method based on an options trading client is provided, applied to an automated testing system. The automated testing system includes an automated test recording tool and an automated test management platform. The method includes: Data preparation steps: Obtain test data and build function libraries, and build a data pool based on the test data; the test data includes account data, target cache data, price data, position data, fund database data, and pre-defined account permission data; the function libraries include file processing libraries, common operation libraries, table processing libraries, utility libraries, and database processing libraries; Script component recording and compilation steps: Record the interface elements of the options trading client using an automated test recording tool to generate test scripts; the test scripts are written in a scripting language and include the location information and operation instructions of the interface elements; Requirements tree construction steps: In the automated test management platform, construct the requirements tree according to the hierarchical structure of system, module, function, and sub-function; where the leaf nodes of the requirements tree correspond to testable requirement verification points; Scenario design steps: Design business scenarios for requirement verification points. Each business scenario contains at least one sub-scenario. Each sub-scenario contains a test operation sequence and a test verification point. The test verification point is used to verify whether the corresponding requirement verification point is met. Scene component linkage and data-driven steps: Bind test scripts in script components to business scenarios, and generate test cases through data pool; Regression test set customization steps: Create at least one regression test set, each regression test set corresponds to a functional module or a business scenario, and each regression test set contains at least one test case; Test execution steps: Execute the test cases in the regression test set, record the execution logs, running data, output parameters, verification results, screenshots and videos during the test execution process, and generate a test report; Maintenance and recovery steps: When the interface of the options trading client changes, update the positioning information of the interface elements; and when test cases fail to execute, perform error recovery operations, including: capturing and recording exception information, refreshing the interface of the options trading client, and re-executing the test cases that failed after all test cases have been executed.

[0011] In one possible implementation, during the script component recording and compilation steps, a set of attributes of the interface elements is stored in an object library. The set of attributes includes one or more of the following: position attribute, location attribute, window ID attribute, window class attribute, and style attribute. By setting weight values ​​for the attributes of each interface element through the object library, and performing fuzzy matching to locate the interface elements based on the weight values, the positioning information of the interface elements is obtained.

[0012] In one possible implementation, the script component recording and compilation steps also include: Using the already located interface elements as reference points, click or input operations can be performed on unrecorded interface elements by specifying an offset, without the need to re-record the interface elements of the options trading client.

[0013] In one possible implementation, the script component recording and compilation steps also include: Set explicit wait conditions in the test script. Explicit wait conditions are used to prevent subsequent operation instructions in the test script from being triggered until the interface element reaches a visible or interactive state.

[0014] In one possible implementation, the business scenario includes positive example verification logic and negative example verification logic in the scenario design step; the method further includes: Parameterization mechanisms are used to configure at least one set of input parameters for business scenarios, and different test cases are generated based on different input parameters.

[0015] In one possible implementation, during the scene component linkage and data-driven steps, test scripts from script components are bound to the business scene, and test cases are generated through a data pool, including: Test cases are generated by substituting test data from the data pool into the business scenario bound to the test script.

[0016] In one possible implementation, at least one regression test set includes a first regression test set and a second regression test set, the first regression test set corresponding to a first functional module, and the second regression test set corresponding to a second functional module; the test execution steps include: Parallel testing is achieved by simultaneously executing the first and second regression test sets on multiple executors.

[0017] In one possible implementation, during the maintenance and recovery steps, error recovery operations are performed, including: When an exception is detected during test case execution, capture and record the exception information, and refresh the interface of the options trading client. After all test cases have been executed, re-execution is performed on the test cases that failed.

[0018] In one possible implementation, the maintenance and recovery steps also include: Before each test case begins execution, an initial state is created; After each test case is completed, the test environment of the options trading client is rolled back to its initial state.

[0019] Secondly, a one-stop GUI automated testing device based on an options trading client is provided, applied to an automated testing system. The automated testing system includes an automated test recording tool and an automated test management platform. The device includes: The data preparation unit is used to acquire test data and build function libraries, and to build a data pool based on the test data. The test data includes account data, target cache data, price data, position data, fund database data, and pre-made account permission data. The function libraries include file processing libraries, common operation libraries, table processing libraries, utility libraries, and database processing libraries. The script component recording and compilation unit is used to record the interface elements of the options trading client using an automated test recording tool to generate test scripts. The test scripts are written in a scripting language and contain the location information and operation instructions of the interface elements. The requirement tree building unit is used to construct a requirement tree in the automated test management platform according to the hierarchical structure of system, module, function, and sub-function; wherein, the leaf nodes of the requirement tree correspond to testable requirement verification points; The scenario design unit is used to design business scenarios for requirement verification points. Each business scenario includes at least one sub-scenario, and each sub-scenario includes a test operation sequence and a test verification point. The test verification point is used to verify whether the corresponding requirement verification point is met. The scenario component linkage and data-driven unit is used to bind test scripts in script components to business scenarios and generate test cases through data pool driving. The regression test set customization unit is used to create at least one regression test set. Each regression test set corresponds to a functional module or a business scenario, and each regression test set contains at least one test case. The test execution unit is used to execute test cases in the regression test set, record execution logs, running data, output parameters, verification results, screenshots and videos during the test execution process, and generate test reports; The maintenance and recovery unit is used to update the location information of interface elements when the interface of the options trading client changes; and to perform error recovery operations when test cases fail to execute. The error recovery operations include: capturing and recording exception information, refreshing the interface of the options trading client, and re-executing the test cases that failed to execute after all test cases have been executed.

[0020] By utilizing the above technical solutions, this application provides a one-stop GUI automated testing method and apparatus based on an options trading client. This method constructs a one-stop GUI automated testing system covering the entire process from data preparation, script component recording and compilation, requirement tree construction, scenario design, scenario component linkage and data-driven operation, regression test set customization, test execution, maintenance and recovery. It adapts to the complex business scenarios and special controls of options trading clients, achieves standardization and automation of the testing process, significantly improves regression testing efficiency, reduces script maintenance costs, and ensures the stability of the testing process and the accuracy of the results. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0022] Figure 1 A functional structure diagram of an options trading system is shown; Figure 2 A flowchart of a one-stop GUI automated testing method based on an options trading client, as provided in an embodiment of this application, is shown. Figure 3 An automation flowchart of the TestOne automated test management platform mentioned in the embodiments of this application is shown; Figure 4 A flowchart illustrating the construction combination strategy mentioned in an embodiment of this application is shown; Figure 5 This application illustrates a requirement-to-use case structure diagram as described in an embodiment. Figure 6 This application illustrates a requirement-scenario-use case diagram related to embodiments of the application. Figure 7 The test set related to "vertical order placement" mentioned in the embodiments of this application is shown; Figure 8 This document shows a schematic diagram illustrating the test set content mentioned in an embodiment of this application; Figure 9 A schematic diagram illustrating the test results mentioned in the embodiments of this application is shown; Figure 10 This illustration shows a diagram illustrating the display of historical report content mentioned in an embodiment of this application; Figure 11 This document shows a schematic diagram illustrating the object management repository (hereinafter referred to as the object repository) mentioned in an embodiment of this application; Figure 12 A flowchart illustrating the error recovery mechanism mentioned in an embodiment of this application is shown; Figure 13 The diagram shows the structure of a one-stop GUI automated testing device based on an options trading client provided in an embodiment of this application. Detailed Implementation

[0023] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the term "comprising" and its variations should be interpreted as open-ended terms meaning "including but not limited to."

[0025] To address the aforementioned technical problems, this application provides a one-stop GUI automated testing method based on an options trading client. This method is applied to an automated testing system, which includes an automated test recording tool and an automated test management platform. Figure 2 As shown, this one-stop GUI automated testing method based on an options trading client may include the following steps S201 to S208: S201, Data Preparation Steps: Obtain test data and build function libraries, and build a data pool based on the test data; among which, the test data includes account data, target cache data, price data, position data, fund database data, and pre-made account permission data; the function libraries include file processing libraries, common operation libraries, table processing libraries, utility libraries, and database processing libraries; S202, Script component recording and compilation steps: Record the interface elements of the options trading client using an automated test recording tool to generate test scripts; the test scripts are written in a scripting language and include the location information and operation instructions of the interface elements; S203, Requirements Tree Construction Steps: In the automated test management platform, construct the requirements tree according to the hierarchical structure of system, module, function, and sub-function; where the leaf nodes of the requirements tree correspond to testable requirement verification points; S204, Scenario Design Steps: Design business scenarios for requirement verification points. Each business scenario includes at least one sub-scenario. Each sub-scenario includes a test operation sequence and a test verification point. The test verification point is used to verify whether the corresponding requirement verification point is met. S205, Scene Component Linkage and Data-Driven Steps: Bind test scripts in script components to business scenarios, and generate test cases through data pool driving; S206, Steps for customizing regression test sets: Create at least one regression test set, each regression test set corresponds to a functional module or a business scenario, and each regression test set contains at least one test case; S207, Test Execution Steps: Execute the test cases in the regression test set, record the execution logs, running data, output parameters, verification results, screenshots and videos during the test execution process, and generate a test report; S208, Maintenance and Recovery Steps: When the interface of the options trading client changes, update the positioning information of the interface elements; and when an exception occurs during test case execution, perform error recovery operations, including: capturing and recording exception information, refreshing the interface of the options trading client, and re-executing the test cases that failed after all test cases have been executed.

[0026] This embodiment constructs a one-stop GUI automated testing system covering the entire process from data preparation, script component recording and compilation, requirement tree construction, scenario design, scenario component linkage and data-driven operation, regression test set customization, test execution, maintenance and recovery. It adapts to the complex business scenarios and special controls of option trading clients, realizes the standardization and automation of the testing process, significantly improves regression testing efficiency, reduces script maintenance costs, and ensures the stability of the testing process and the accuracy of the results.

[0027] This application provides a possible implementation method. In the S202 script component recording and compilation step, the attribute set of interface elements is stored in an object library. The attribute set includes one or more of the following: position attribute, location attribute, window ID attribute, window class attribute, and style attribute. The object library is used to set a weight value for each attribute of the interface element. Based on the weight value, the interface element is fuzzy matched and located to obtain the positioning information of the interface element.

[0028] This embodiment achieves accurate and stable positioning of interface elements through multi-dimensional attribute positioning and weighted fuzzy matching mechanism of object library. It can maintain high recognition accuracy even when the interface layout is finely adjusted, avoid element positioning failure caused by small changes in the interface, improve the stability of test scripts, and reduce the workload of positioning maintenance.

[0029] This application provides a possible implementation method. The S202 script component recording and compilation steps further include: using the located interface element as a reference point, performing click or input operations on the unrecorded interface element by specifying an offset, without having to re-record the interface elements of the options trading client.

[0030] This embodiment uses an offset mechanism, taking a stably positioned object as the base point, and precisely operates on unrecorded element objects by specifying an offset. When a major change occurs on the page and the original object position becomes invalid, there is no need to re-record; the problem can be solved simply by adjusting the offset, which greatly reduces the script maintenance cost.

[0031] This application provides a possible implementation method. The S202 script component recording and compilation step further includes: setting an explicit wait condition in the test script, wherein the explicit wait condition is used to prevent subsequent operation instructions in the test script from being triggered before the interface element reaches a visible or interactive state.

[0032] This embodiment replaces fixed-time waiting with explicit waiting, ensuring that elements do not trigger subsequent actions before they become visible or interactive, thus avoiding script execution failures caused by network latency or interface loading and improving the stability of test execution.

[0033] This application provides a possible implementation method. In the S204 scenario design step, the business scenario includes positive example verification logic and negative example verification logic. The method also includes: configuring at least one set of input parameters for the business scenario through a parameterization mechanism, and generating different test cases based on different input parameters.

[0034] This embodiment uses positive and negative example verification logic and parameterization mechanism to quickly generate multiple test scenarios based on the same business scenario, covering normal processes and abnormal boundary scenarios, thereby improving the coverage and design efficiency of test cases.

[0035] This application provides a possible implementation method in the S205 scenario component linkage and data-driven step, which involves binding test scripts in the script component to the business scenario and generating test cases through data pool driving, including: substituting test data from the data pool into the business scenario bound to the test script to generate test cases.

[0036] This embodiment achieves data-driven automated testing by substituting test data from the data pool into the business scenario bound to the test script, ensuring the efficiency and accuracy of the testing process.

[0037] This application provides a possible implementation method in which at least one regression test set includes a first regression test set and a second regression test set, the first regression test set corresponding to a first functional module, and the second regression test set corresponding to a second functional module; the test execution steps include: synchronously executing the first regression test set and the second regression test set on multiple executors to achieve parallel testing.

[0038] This embodiment achieves scenario isolation and parallel execution through a customized regression test set strategy, fundamentally avoiding data pollution and result interference between different test scenarios, and significantly shortening the regression test cycle.

[0039] This application provides a possible implementation method in which, in the S208 maintenance and recovery step, an error recovery operation is performed, including: when an abnormal test case execution is detected, capturing and recording the abnormal information, and refreshing the interface of the options trading client; after all test cases have been executed, performing a re-execution operation on the test cases that failed to execute.

[0040] This embodiment uses an error recovery mechanism to immediately capture and record any anomalies detected during test case execution, while simultaneously refreshing the client page. After all test cases have been executed, it supports proactive re-execution of failed test cases, ensuring the continuity of testing activities and data integrity.

[0041] This application provides a possible implementation method, and the S208 maintenance and recovery step further includes: creating an initial state before each test case starts execution; and rolling back the test environment of the option trading client to the initial state after each test case finishes execution.

[0042] This embodiment uses a transactional testing mechanism to provide a consistent initial testing environment for each test case, avoiding data residue from previous test cases from interfering with subsequent test cases and ensuring the accuracy and reproducibility of test results.

[0043] The above introduces Figure 2 The embodiments shown have various implementation methods for each stage. The following will further explain the one-stop GUI automated testing method based on an options trading client according to the embodiments of this application through specific examples.

[0044] In a specific embodiment, the automated test recording tool can be AutoRunner, and the automated test management platform can be TestOne. For example... Figure 3 The diagram shown is the automation flowchart of the TestOne automated test management platform. The steps are: creating a project, creating test requirements, creating components, creating test case scenarios, intelligently generating test cases, executing tasks (immediate execution, scheduled execution, and scheduled execution), automatically identifying and classifying errors / problems, automatically performing regression testing, and automatically generating reports.

[0045] TestOne is a microservice architecture based on the B / S (Browser / Server) framework. It integrates functions such as test system project management, requirements analysis, scenario design, case design, script writing, regression task scheduling, execution analysis, and report generation, comprehensively standardizing the automated testing process. Its custom test report generation function helps testers deeply understand test results and adjust testing strategies in a timely manner.

[0046] The specific steps are as follows: Steps one through eight. Step 1: Test data preparation and function library construction.

[0047] 1. Basic Data Preparation Test data preparation mainly includes the following points: 1) Account and target caching processing; 2) Obtaining price, open interest, and funding databases: contract information query table, underlying security of the contract, option dates, etc.; 3) Pre-configuration of test data and account permissions.

[0048] Here, the pre-built test data and account permissions can include pre-built data types, namely: contract supplement type, which is suitable for solving problems such as insufficient contracts for securities in the case, adding covered shares, and prompting error messages such as failed put option exercise and insufficient frozen quantity; account permission type, which pre-built accounts with different permissions for option trading needs; query type, which involves querying customer funds, positions, and orders; and others, such as scenario-based data generation for constructing portfolio contracts and arbitrage portfolios.

[0049] 2. Basic construction of function libraries The various library files built in the function library are called by the test scripts during the script component recording and compilation process in step two. Specifically, the file processing library (FileUtil.bsh) implements common file processing functions such as file reading and writing, and directory operations during the test; the public operation library (function_xczq_qq.bsh) encapsulates common operations of the options trading client, such as placing orders, canceling orders, and querying; the table processing library (public_checkGridInfo.bsh) is used to validate and verify the table data in the client interface; the utility library (public_tomenu.bsh) provides auxiliary functions such as menu navigation and window switching; and the database processing library (checkResult_DB.bsh) is used to perform database queries and compare results to verify the consistency between the data displayed on the interface and the data in the backend. This function library reuse mechanism avoids repeatedly writing the same code in multiple test scripts, improving the development efficiency and maintainability of the test scripts.

[0050] Step 2: Recording and compiling script components.

[0051] Based on the specific needs of options trading, an automated test recording tool, AutoRunner, was built for script recording, and the test scripts were written in the BeanShell language. (1) Object positioning: Through the object library management system, it supports the precise positioning of interface elements by various attributes (such as position, location, windowID, winClass, style, etc.). Its element attribute weight control fuzzy matching mechanism introduces object weight setting options, and maintains high recognition accuracy even when the interface layout is fine-tuned.

[0052] (2) Offset Mechanism: The script supports using a stable and confirmed positioning object as a base point, and precisely clicking or manipulating unrecorded element objects by specifying an offset. When a major change occurs on the page that causes the original object position to become invalid, there is no need to re-record; the issue can be resolved simply by adjusting the offset.

[0053] (3) Element operation wait: Implement explicit wait to ensure that the element will not trigger subsequent actions before it is visible or interactive, and avoid using fixed time waits such as sleep.

[0054] (4) Comprehensive test command library: It has a rich and comprehensive test command library, including but not limited to assertions, parameter acquisition, log output, interactive simulation, system control and other comprehensive test engineering commands.

[0055] Step 3: Construct a multi-level requirement tree.

[0056] In the TestOne platform, a multi-level requirement tree is first built based on detailed test requirements to ensure that all test points are covered. The requirement tree is organized hierarchically according to "system → module → function → sub-function", with each leaf node corresponding to a testable requirement verification point.

[0057] Step 4: Business Scenario Design Ideas.

[0058] A series of efficient testing solutions have been tailored for the options system. Leveraging the flexible component association features of the testing platform and incorporating a data-driven mechanism, specific business scenarios are designed around each required verification point. The logically clear test scenarios and the use of parameterization mechanisms provide test engineers with a way to dynamically switch test contexts. For example, the portfolio strategy construction scenario includes three sub-scenarios: "Constructing a portfolio strategy—Single-sided closing—Removing the portfolio strategy," and also supports positive and negative example verification mechanisms.

[0059] like Figure 4 The diagram shows the process of constructing a portfolio strategy. Upon entering the "Construct Portfolio Strategy" page, the system inputs the contract portfolio strategy information and determines the business type. If the business type is Null, the system continues with order information verification. If the business type is an unlocking strategy, the system continues with strategy release and order information verification. If the business type is a one-sided closing position, a one-sided closing order is placed and order information verification is performed. The system then performs backend prompt verification and concludes the process.

[0060] Step 5: Scene component linkage and data-driven approach.

[0061] Based on the established requirements and the business scenarios under their respective veins, corresponding script components are bound (the component association function combines multiple script components into complex test instances), and a large number of test cases are automatically generated through the data pool to achieve comprehensive parameterized testing.

[0062] like Figure 5 The diagram shows the structure from requirements to use cases, including the project, requirement tree, scenario, and use cases. The project is "CITIC Securities Online Trading Options Version". The requirement tree includes horizontal order placement, vertical order placement, and other orders. The scenario is "Buy to Open Position", which includes insufficient funds, order price fluctuation verification, and transaction quantity verification. The use case is "Single scenario binding script component, introducing data pool to generate test cases".

[0063] This includes creating requirements, designing and configuring scenarios (component script binding, data-driven test case generation and management), ensuring an efficient and accurate testing process. Specific steps are as follows: Figure 6 The diagram shown is a requirement-scenario-use case diagram.

[0064] In this process, ensuring the comprehensiveness of requirements analysis, the rationality of scenario design, the accuracy of use case generation, and the efficiency of automated configuration are key.

[0065] Step Six: Automated regression strategy, test isolation.

[0066] To improve testing quality and efficiency, multiple customized regression test suites were created. Through fine-grained segmentation, each test suite focuses on a specific functional module or business scenario, fundamentally avoiding interference between different test scenarios and ensuring that each regression test activity achieves the highest level of professionalism and accuracy. After adopting the customized regression test suite strategy, two significant improvements were observed: Scene isolation (stability enhancement): Each test set strictly corresponds to a specific test point or functional block, eliminating data dependencies and result contamination during cross-scene testing, and improving the reliability and credibility of test results.

[0067] Parallel execution (improved efficiency): Different test sets can be executed synchronously on multiple executors, enabling automated parallel batch processing via the GUI, significantly shortening the overall regression testing cycle.

[0068] Figure 7 The test set for "vertical order placement" is shown, including the test set name and test status. Figure 8 The test suite contents are shown, including test cases, executors, and execution records.

[0069] Step 7: Visualize the execution results and archive historical data.

[0070] During execution, all test results will provide an intuitive view of the test execution status. Every step of the execution log will be recorded, including log entries, runtime data, output parameters, verification results, screenshots, and videos. This not only facilitates subsequent problem localization and auditing but also provides rich reference materials for future test improvements. Figure 9 The diagram illustrates a test result display, including running data, output parameters, data verification, images and videos, and running logs.

[0071] The test report enables historical data archiving and backtracking. The testing platform retains records of all test executions, supports historical data querying and comparison, and helps identify hidden problems and potential trends in the system's long-term operation, providing a basis for future test strategy optimization. Furthermore, the report can be exported in multiple formats to meet diverse needs. Figure 10 The diagram illustrates a display of historical report content, including the test results for tasks, test sets, tabs, tag sets, and tag lists.

[0072] Step 8: Automated test maintenance and error recovery.

[0073] 1. Test case maintenance strategy when the interface changes Use an object management repository: The TestOne automated testing platform has a powerful built-in object management repository that stores the location information of all UI element objects. When the interface changes, you only need to modify the element location information in the object repository online, reducing the workload of modifying the test cases themselves. Figure 11 A schematic diagram illustrating the object management repository (hereinafter referred to as the object repository) mentioned in the embodiments of this application is shown.

[0074] Object offset manipulation: This mechanism reshapes positioning rules. When the interface changes, the offset of known positioning script objects can be adjusted directly to apply to unrecorded or invalid objects without re-recording, simplifying script maintenance. This enhances the flexibility and efficiency of test scripts, ensuring smooth execution even with frequent changes in interface layout.

[0075] Encapsulation using the Page Object Model: Recording some page elements and actions as a component means that when the interface structure changes, only the implementation of the page component needs to be updated, rather than directly modifying the test script, which improves the maintainability and readability of the code.

[0076] 2. Resume test execution state in case of system crash or other errors. Transactional testing: Create a clean state before each test case begins, and clean up or roll back to the initial state after the test is completed, ensuring that each test is under the same starting conditions.

[0077] Error recovery mechanism: Implement error recovery logic. When an exception is detected during test case execution, it is immediately captured and recorded, and the client page is refreshed. After all test cases have been executed, the test platform supports the function of actively re-executing failed test cases.

[0078] like Figure 12 The flowchart illustrates the error recovery mechanism. Test set: Execute test cases, setting the number of consecutive executions: a=2; Initial execution, a=1; Sequential execution of test cases, determining success rate. If successful, test case execution and settlement; If an exception / failure occurs, record and refresh the client page, then continue test case execution and settlement. Next, determine if there are any failed test cases, a; If failed test cases exist and the number of executions is <2, trigger consecutive execution, a+1, and automatically execute the failed test cases, continuing to determine success rate; If no failed test cases exist, or the number of executions is 2, merge the test set, export the report, and end.

[0079] The number of consecutive re-executions can be configured according to actual testing needs (in this embodiment, it is set to 2 times by default) to avoid the accuracy of test conclusions being affected by occasional failures caused by network fluctuations or instantaneous system anomalies, while also preventing the waste of test resources caused by infinite retries.

[0080] This embodiment, through the above technical solution, achieved a dual improvement in system stability and efficiency during the GUI automation testing of options trading clients. The following is a detailed explanation of the improvements: 1) Significantly improved testing efficiency: By adopting a customized regression test suite for parallel execution, the time for a single complete regression test was reduced from approximately 16 hours (2 person-days) for manual execution to 1 hour for automated parallel execution, a reduction of approximately 93.75%. On average, each iteration saves 2 person-days of testing manpower, freeing testers from repetitive tasks and allowing them to focus on test design and strategy optimization. Script maintenance time was also reduced; when the interface changed, through object library management and offset mechanisms, the average maintenance time was reduced from 2 hours to 15 minutes, improving maintenance efficiency by 87.5%.

[0081] 2) Enhanced test coverage and accuracy: The coverage of automated test cases has now reached 98%. After implementing the scenario isolation regression test set strategy, the false positive rate caused by data contamination between scenarios has decreased by 85%, and the reliability of test results has been significantly improved. At the same time, transactional testing and error recovery mechanisms ensure the continuity of testing, and the success rate of automatic recovery execution after anomalies has reached 96%.

[0082] 3) A powerful tool for both script editing and recording: The script editing tool perfectly combines interface recording and script programming. Its built-in object library management system ensures accurate object location and easy maintenance, further enhancing the stability and efficiency of testing.

[0083] 4) Refined management of scene design: In terms of scenario module design and test case binding, the principle of "starting from requirements and ending with scenarios" was followed, achieving refined and scalable test case design. This multi-level requirement tree ensures full coverage of functional points, increasing the coverage of automated test cases from 60% to 98%.

[0084] 5) In-depth analysis and visualization of execution results: The importance of test result analysis for continuous improvement is highlighted by the test execution status view provided by the test platform, which clearly shows the test progress and execution results. The archiving and backtracking functions of historical data further deepen the understanding of the long-term operating status of the system and help predict potential risks and development trends in the future.

[0085] It should be noted that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In practical applications, all the above possible implementation methods can be arbitrarily combined in a combined manner to form possible embodiments of this application, which will not be described in detail here.

[0086] Based on the one-stop GUI automated testing method for options trading clients provided in the above embodiments, and based on the same inventive concept, this application also provides a one-stop GUI automated testing device for options trading clients.

[0087] Figure 13 This is a structural diagram of the one-stop GUI automated testing device based on an options trading client provided in this application embodiment. Figure 13 As shown, this one-stop GUI automated testing device based on an options trading client is applied to an automated testing system. The automated testing system includes an automated test recording tool and an automated test management platform. Specifically, the one-stop GUI automated testing device based on an options trading client may include a data preparation unit 1310, a script component recording and compilation unit 1320, a requirement tree construction unit 1330, a scenario design unit 1340, a scenario component linkage and data-driven unit 1350, a regression test set customization unit 1360, a test execution unit 1370, and a maintenance and recovery unit 1380.

[0088] The data preparation unit 1310 is used to acquire test data and build function libraries, and to build a data pool based on the test data; wherein, the test data includes account data, target cache data, price data, position data, fund database data, and pre-made account permission data; the function library includes file processing library, common operation library, table processing library, utility library, and database processing library; The script component recording and compilation unit 1320 is used to record the interface elements of the options trading client through an automated test recording tool and generate test scripts; wherein, the test scripts are written in a scripting language and contain the positioning information and operation instructions of the interface elements; The requirement tree construction unit 1330 is used to construct a requirement tree in the automated test management platform according to the hierarchical structure of system, module, function, and sub-function; wherein, the leaf nodes of the requirement tree correspond to testable requirement verification points; The scenario design unit 1340 is used to design business scenarios for requirement verification points. The business scenario includes at least one sub-scenario, and each sub-scenario includes a test operation sequence and a test verification point. The test verification point is used to verify whether the corresponding requirement verification point is met. The Scene Component Linkage and Data-Driven Unit 1350 is used to bind test scripts in script components to business scenarios and generate test cases through data pool driving. The regression test set customization unit 1360 is used to create at least one regression test set. Each regression test set corresponds to a functional module or a business scenario, and each regression test set contains at least one test case. Test execution unit 1370 is used to execute test cases in the regression test set, record execution logs, running data, output parameters, verification results, screenshots and videos during the test execution process, and generate test reports; The maintenance and recovery unit 1380 is used to update the positioning information of interface elements when the interface of the options trading client changes; and to perform error recovery operations when test case execution is abnormal. The error recovery operations include: capturing and recording the abnormal information, refreshing the interface of the options trading client, and re-executing the test cases that failed after all test cases have been executed.

[0089] This application embodiment provides a possible implementation method, wherein the script component recording and editing unit 1320 is further used for: The object library stores a collection of attributes for UI elements, which includes one or more of the following: position attribute, location attribute, window ID attribute, winClass attribute, and style attribute. By setting weight values ​​for the attributes of each interface element through the object library, and performing fuzzy matching to locate the interface elements based on the weight values, the positioning information of the interface elements is obtained.

[0090] This application embodiment provides a possible implementation method, wherein the script component recording and editing unit 1320 is further used for: Using the already located interface elements as reference points, click or input operations can be performed on unrecorded interface elements by specifying an offset, without the need to re-record the interface elements of the options trading client.

[0091] This application embodiment provides a possible implementation method, wherein the script component recording and editing unit 1320 is further used for: Set explicit wait conditions in the test script. Explicit wait conditions are used to prevent subsequent operation instructions in the test script from being triggered until the interface element reaches a visible or interactive state.

[0092] This application embodiment provides a possible implementation, where the business scenario includes positive example verification logic and negative example verification logic; the scenario design unit 1340 is further used for: Parameterization mechanisms are used to configure at least one set of input parameters for business scenarios, and different test cases are generated based on different input parameters.

[0093] This application embodiment provides a possible implementation method, wherein the scene component linkage and data driving unit 1350 is further used for: Test cases are generated by substituting test data from the data pool into the business scenario bound to the test script.

[0094] This application embodiment provides a possible implementation, wherein at least one regression test set includes a first regression test set and a second regression test set, the first regression test set corresponding to a first functional module, and the second regression test set corresponding to a second functional module; the test execution unit 1370 is further configured to: Parallel testing is achieved by simultaneously executing the first and second regression test sets on multiple executors.

[0095] This application embodiment provides a possible implementation, wherein the maintenance and recovery unit 1380 is further configured to: When an exception is detected during test case execution, capture and record the exception information, and refresh the interface of the options trading client. After all test cases have been executed, re-execution is performed on the test cases that failed.

[0096] This application embodiment provides a possible implementation, wherein the maintenance and recovery unit 1380 is further configured to: Before each test case begins execution, an initial state is created; After each test case is completed, the test environment of the options trading client is rolled back to its initial state.

[0097] Those skilled in the art will clearly understand that the specific working process of the systems, devices, and modules described above can be referred to the corresponding process in the foregoing method embodiments. For the sake of brevity, it will not be repeated here.

[0098] Those skilled in the art will understand that the technical solution of this application, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several program instructions to cause an electronic device (e.g., a personal computer, server, or network device) to execute all or part of the steps of the methods described in the embodiments of this application when running the program instructions. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0099] Alternatively, all or part of the steps of the foregoing method embodiments can be implemented by hardware (such as electronic devices like personal computers, servers, or network devices) associated with program instructions. The program instructions can be stored in a computer-readable storage medium. When the program instructions are executed by the processor of the electronic device, the electronic device executes all or part of the steps of the methods described in the embodiments of this application.

[0100] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that within the spirit and principles of this application, modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the corresponding technical solutions to leave the protection scope of this application.

Claims

1. A one-stop GUI automated testing method based on an options trading client, characterized in that, Applied to an automated testing system, the automated testing system including an automated test recording tool and an automated test management platform, the method includes: Data preparation steps: Obtain test data and build function libraries, and build a data pool based on the test data; the test data includes account data, target cache data, price data, position data, fund database data, and pre-defined account permission data; the function libraries include file processing libraries, common operation libraries, table processing libraries, utility libraries, and database processing libraries; Script component recording and compilation steps: Record the interface elements of the options trading client using an automated test recording tool to generate test scripts; the test scripts are written in a scripting language and include the location information and operation instructions of the interface elements; Requirements tree construction steps: In the automated test management platform, construct the requirements tree according to the hierarchical structure of system, module, function, and sub-function; where the leaf nodes of the requirements tree correspond to testable requirement verification points; Scenario design steps: Design business scenarios for requirement verification points. Each business scenario contains at least one sub-scenario. Each sub-scenario contains a test operation sequence and a test verification point. The test verification point is used to verify whether the corresponding requirement verification point is met. Scene component linkage and data-driven steps: Bind test scripts in script components to business scenarios, and generate test cases through data pool; Regression test set customization steps: Create at least one regression test set, each regression test set corresponds to a functional module or a business scenario, and each regression test set contains at least one test case; Test execution steps: Execute the test cases in the regression test set, record the execution logs, running data, output parameters, verification results, screenshots and videos during the test execution process, and generate a test report; Maintenance and recovery steps: When the interface of the options trading client changes, update the positioning information of the interface elements; and when test cases fail to execute, perform error recovery operations, including: capturing and recording exception information, refreshing the interface of the options trading client, and re-executing the test cases that failed after all test cases have been executed.

2. The method according to claim 1, characterized in that, In the script component recording and compilation steps, the attribute set of the interface element is stored in the object library. The attribute set includes one or more of the following: position attribute, location attribute, window ID attribute, window class attribute, and style attribute. By setting weight values ​​for the attributes of each interface element through the object library, and performing fuzzy matching to locate the interface elements based on the weight values, the positioning information of the interface elements is obtained.

3. The method according to claim 1, characterized in that, The script component recording and compilation steps also include: Using the already located interface elements as reference points, click or input operations can be performed on unrecorded interface elements by specifying an offset, without the need to re-record the interface elements of the options trading client.

4. The method according to claim 1, characterized in that, The script component recording and compilation steps also include: Set explicit wait conditions in the test script. Explicit wait conditions are used to prevent subsequent operation instructions in the test script from being triggered until the interface element reaches a visible or interactive state.

5. The method according to claim 1, characterized in that, In the scenario design step, the business scenario includes positive example verification logic and negative example verification logic; the method also includes: Parameterization mechanisms are used to configure at least one set of input parameters for business scenarios, and different test cases are generated based on different input parameters.

6. The method according to claim 1, characterized in that, In the scenario component linkage and data-driven steps, test scripts in the script component are bound to the business scenario, and test cases are generated through data pool driving, including: Test cases are generated by substituting test data from the data pool into the business scenario bound to the test script.

7. The method according to claim 1, characterized in that, At least one regression test set includes a first regression test set and a second regression test set, the first regression test set corresponds to the first functional module, and the second regression test set corresponds to the second functional module. The test execution steps include: Parallel testing is achieved by simultaneously executing the first and second regression test sets on multiple executors.

8. The method according to claim 1, characterized in that, During the maintenance and recovery process, error recovery operations are performed, including: When an exception is detected during test case execution, capture and record the exception information, and refresh the interface of the options trading client. After all test cases have been executed, re-execution is performed on the test cases that failed.

9. The method according to claim 1, characterized in that, The maintenance and recovery steps also include: Before each test case begins execution, an initial state is created; After each test case is completed, the test environment of the options trading client is rolled back to its initial state.

10. A one-stop GUI automated testing device based on an options trading client, characterized in that, Applied to an automated testing system, the automated testing system includes an automated test recording tool and an automated test management platform, the device comprising: The data preparation unit is used to acquire test data and build function libraries, and to build a data pool based on the test data. The test data includes account data, target cache data, price data, position data, fund database data, and pre-made account permission data. The function libraries include file processing libraries, common operation libraries, table processing libraries, utility libraries, and database processing libraries. The script component recording and compilation unit is used to record the interface elements of the options trading client using an automated test recording tool to generate test scripts. The test scripts are written in a scripting language and contain the location information and operation instructions of the interface elements. The requirement tree building unit is used to construct a requirement tree in the automated test management platform according to the hierarchical structure of system, module, function, and sub-function; wherein, the leaf nodes of the requirement tree correspond to testable requirement verification points; The scenario design unit is used to design business scenarios for requirement verification points. Each business scenario includes at least one sub-scenario, and each sub-scenario includes a test operation sequence and a test verification point. The test verification point is used to verify whether the corresponding requirement verification point is met. The scenario component linkage and data-driven unit is used to bind test scripts in script components to business scenarios and generate test cases through data pool driving. The regression test set customization unit is used to create at least one regression test set. Each regression test set corresponds to a functional module or a business scenario, and each regression test set contains at least one test case. The test execution unit is used to execute test cases in the regression test set, record execution logs, running data, output parameters, verification results, screenshots and videos during the test execution process, and generate test reports; The maintenance and recovery unit is used to update the location information of interface elements when the interface of the options trading client changes; and to perform error recovery operations when test cases fail to execute. The error recovery operations include: capturing and recording exception information, refreshing the interface of the options trading client, and re-executing the test cases that failed to execute after all test cases have been executed.

Images