Software testing method and software testing apparatus

Abstract

A software testing method and a software testing apparatus are provided. The method includes following steps: according to multiple items on an operating interface of a Software-under-Test (SUT), generating multiple test actions that can be executed on the items; creating a software testing interface, defining multiple play actions of a tester in the software testing interface and matching the play actions to the test actions of the SUT; determining a significance of each of the test actions according to one or more execution sections in a program code of the SUT, or software function / performance / use-experience / security requirements corresponding to the test action; predicting an award that can be obtained by executing each of the play actions according to the significance of the test action matched by each of the play actions, and displaying the award on the software testing interface; and returning the reward in response to receiving an execution result of the play action.

Description

Technical Field

[0001] This invention relates to a testing method and apparatus, and more particularly to a software testing method and a software testing apparatus. Prior Technology

[0002] Software testing is a crucial and complex process because it involves ensuring that software products can operate stably and reliably under various conditions. Testers face numerous challenges in this process. Different software versions, hardware configurations, and operating system versions can all affect test results. To ensure consistency and reproducibility, the test environment must be consistent with the development and user environments. Furthermore, as the scale and functionality of software systems continue to grow, testing becomes even more complex. Ensuring that every component and function is thoroughly tested and that potential defects are identified is a major challenge in the field of software testing.

[0003] To obtain effective test results, a large amount of test data is often required. This data needs to be realistic and consistent with user scenarios. However, due to the difficulty in collecting, generating, and managing test data, many software developers face resource challenges such as insufficient testing time, limited testers, and insufficient testing equipment. Furthermore, if testing is outsourced, testers can directly view various designs of the application / webpage / interface before its release, which may result in the risk of intellectual property (IP) leakage.

[0004] Therefore, improving the breadth and concealment of testing, enabling external testers to participate in testing and perform testing efficiently without leaking software content, and generating clear and accurate reports so that management and the development team can quickly understand the quality status of the software, is a significant challenge. Summary of the Invention

[0005] This invention provides a software testing method and a software testing apparatus, which can expand software testing resources and improve software testing efficiency.

[0006] This invention provides a software testing method applicable to electronic devices with processors. The method includes the following steps: generating multiple test actions executable on multiple items in the user interface of the software-under-test (SUT); creating a software testing interface, defining multiple play actions for the tester within the interface, and matching these play actions to the multiple test actions of the SUT; determining the importance of each test action based on one or more execution sections in the SUT's code corresponding to that action, or based on software functionality / performance / user experience / security requirements; predicting the reward obtainable from executing each play action based on its importance and displaying it on the software testing interface; and providing a reward in response to the received execution result of the play action.

[0007] This invention provides a software test report generation apparatus, comprising a display device, an input device, a storage device, and a processor. The input device receives user operations. The storage device stores computer programs. The processor is coupled to the display device, input device, and storage device, and is configured to load and execute the computer program to: generate multiple test actions that can be performed on multiple items on the user interface of the software under test; create a software test interface, define multiple user actions within the software test interface, and match the user actions to multiple test actions of the software under test; determine the importance of the test actions based on one or more execution sections in the code of the software under test corresponding to each test action, or based on software functionality / performance / user experience / security requirements; predict the reward that can be obtained by performing each user action based on the importance of the test actions matched to each user action, and display the reward on the software test interface; and provide a reward in response to the received execution result of the user action.

[0008] The software testing method and apparatus of the present invention convert the operation actions performed by the tester in the software testing interface into the test actions of the software under test, predict the rewards that can be obtained by performing each operation action according to the importance of the test action, and give back to the tester in the form of scores, sound and light effects or rewards. This allows external testers to participate in the testing, thereby expanding software testing resources and improving software testing efficiency.

[0009] To make the above features and advantages of the present invention more apparent and understandable, specific embodiments are described below in conjunction with the accompanying drawings for detailed explanation. Simple Explanation of the Diagram

[0010] Figure 1 is an example of a software testing interface according to an embodiment of the present invention. Figure 2 is a block diagram of a software testing apparatus according to an embodiment of the present invention. Figure 3 is a flowchart illustrating a software testing method according to an embodiment of the present invention. Figure 4 is a flowchart illustrating a method for rewarding predicted operational actions according to an embodiment of the present invention. Figure 5 is a schematic diagram illustrating a conversion mechanism according to an embodiment of the present invention. Implementation

[0011] The software testing method and apparatus of this invention provide a conversion mechanism between the user interface of the software under test (web page or application) and a software testing interface (e.g., a game user interface). This allows the rewards obtained by testers performing actions within the software testing interface to reflect the importance of the test actions. This importance may reflect test coverage, software design flaws, software functionality / performance / user experience / security requirements, and the identification of program errors. Furthermore, this invention can design relevant Application Programming Interfaces (APIs) to allow various software programs to easily connect to the testing platform, providing diverse game interface experiences and quick conversion options.

[0012] For example, Figure 1 illustrates an example of a software testing interface according to an embodiment of the present invention. Referring to Figure 1, this embodiment uses, for example, a game interface 10 as the software testing interface. The player can control a character 12, while the opponent 14 represents the program 16 to be tested. The program 16 to be tested is, for example, a webpage to be tested, which includes operation items 18 such as buttons, icons, and data entry. This embodiment of the present invention provides a simple and easy-to-learn interface 10, which converts the actions of the character 12 in the game into button or text operations on the program 16 to be tested, and guides the player to perform high-value test actions by predicting in advance the score and feedback that the player may obtain by performing each action. In addition, by evaluating the actual contribution of the player after performing the test actions, sound and light effects are used to provide sensory feedback, thereby increasing the player's motivation and interest in performing the test.

[0013] Figure 2 is a block diagram of a software testing apparatus according to an embodiment of the present invention. Referring to Figure 2, the software testing apparatus 20 of this embodiment is, for example, a computer device with computing capabilities such as a file server, database server, application server, workstation, or personal computer, or a mobile device such as a mobile phone or tablet computer; this embodiment does not limit the type. The software testing apparatus 20 includes components such as a display device 22, an input device 24, a storage device 26, a connection device 27, and a processor 28. The functions of these components are described below:

[0014] The display device 22 may be a display or television, for example, using a liquid crystal display (LCD), a light-emitting diode (LED), a field emission display (FED), or other types of panels as the display panel, and using a cold cathode fluorescent lamp (CCFL) or a light-emitting diode as the backlight module; there are no limitations on this.

[0015] Input device 24 may be, for example, an input tool such as a keyboard, mouse, remote control, joystick, touchpad, or touch screen that can detect user input operations; a camera that can analyze player images and postures to obtain player expressions / movements; or an augmented reality / virtual reality (AR / VR) device, and is not limited thereto. In some embodiments, input device 24 may be, for example, a touch panel, and may be integrated with display device 22 to form a touch screen to provide both display and operation functions.

[0016] Storage device 26 may be any type of fixed or removable random access memory (RAM), read-only memory (ROM), flash memory, hard disk, or similar element or combination thereof, for storing computer programs that can be executed by processor 28 and the data used therein.

[0017] The connection device 27 is, for example, a wired connection device such as a universal serial bus (USB), RS232, universal asynchronous receiver / transmitter (UART), integrated circuit (I2C), serial peripheral interface (SPI), display port, thunderbolt, or local area network (LAN) interface, or a wireless connection device that supports communication protocols such as wireless fidelity (Wi-Fi), RFID, Bluetooth, infrared, near-field communication (NFC), or device-to-device (D2D). It is used to connect to the Internet and to connect to an electronic device (e.g., a web server) on which the software under test is installed or configured via the Internet to access and test the software under test. This embodiment does not limit the type and connection method of the connection device 27.

[0018] Processor 28 may be, for example, a Central Processing Unit (CPU), or other programmable general-purpose or special-purpose microprocessors, microcontrollers, digital signal processors (DSPs), programmable controllers, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), graphics processing units (GPUs), or other similar devices or combinations thereof, but this embodiment is not limited thereto. In this embodiment, processor 28 may load computer programs from storage device 26 to execute the software testing method of this embodiment of the invention.

[0019] Figure 3 is a flowchart illustrating a software testing method according to an embodiment of the present invention. Please refer to Figures 2 and 3 simultaneously. The method of this embodiment is applicable to the software testing apparatus 20 described above. The detailed steps of the software testing method of this embodiment are described below with reference to the various components of the software testing apparatus 20.

[0020] In step S302, the software testing device 20 generates multiple test actions that can be performed on the multiple items on the operation interface of the software under test, based on the processor 28. These items include, for example, buttons, icons, input fields, text descriptions, screen swiping operations, or physical buttons on the operation interface. Correspondingly, the test actions include, for example, pressing a button, pressing a physical button on the device, swiping the screen, selecting an icon, or inputting text. This embodiment does not limit the types of items and test actions.

[0021] In step S304, the processor 28 creates a software test interface, defines multiple operation actions of the tester in the software test interface, and matches the operation actions to multiple test actions of the software under test.

[0022] In some embodiments, the software testing interface is, for example, a game operation interface. The tester's operation actions are, for example, the fighting actions, moves, etc., performed by the player controlling the character in the game operation interface. The test actions that match the operation actions are, for example, the opponent's actions or responses (visual or auditory effects) after being hit by the character, which can correspond to the operation of buttons, icons, etc. in the operation interface.

[0023] In step S306, the processor 28 determines the importance of the test action based on one or more execution segments in the program code of the software under test corresponding to each test action.

[0024] In step S308, the processor 28 predicts the reward that can be obtained by performing each operation action based on the importance of the test action matched with each operation action, and displays the reward on the software test interface.

[0025] In some embodiments, the processor 28 may further determine the importance of the test actions based on software functionality / performance / user experience / security requirements, and predict the rewards that can be obtained by performing each operation action accordingly. This embodiment does not limit the method. Detailed reward prediction / calculation methods will be described in later embodiments.

[0026] In step S310, the processor 28 provides a reward in response to the execution result of the received operation action.

[0027] In step S312, the processor 28 determines whether a termination operation has been received. If no termination operation is received, the process returns to step S302, regenerating test actions that can be performed on the items on the updated user interface, and predicting the reward for performing the actions. Specifically, during the test, the software under test transitions between different screen states. Therefore, after each action is performed, the processor 28 recalculates the layout of multiple items on the user interface based on the subsequent screen state and predicts the reward the tester can obtain for performing the actions.

[0028] In step S312, if it is determined that an end operation has been received, the processor 28 will collect the operation actions received during the test, the test actions matched by the operation actions, and the rewards obtained as test trajectory data, and use them to generate a test report of the software under test.

[0029] For example, embodiments of the present invention can provide billing advance notice / notification / accounting services for outsourced testing. After the tester finishes all games, the processor 28 can transmit all test trajectory data to the outsourced testing team in a certain issue report format, and obtain the outsourced testing service fee according to the cooperation agreement between the two parties, or obtain confirmation from the outsourced testing team of the service fee amount to be paid. Once the amount is confirmed, the processor 28 can notify the player through the game interface or other second channels (such as email, SMS, communication software, etc.). Through real-time notification, players can obtain satisfaction not only from the game but also from the income, thereby gradually making them like the outsourced testing service cooperation model, and thus consolidating the user community ecosystem of the outsourced testing service platform based on game conversion technology in this embodiment.

[0030] Figure 4 is a flowchart illustrating a method for rewarding predicted operational actions according to an embodiment of the present invention. Referring simultaneously to Figures 2 and 4, the method of this embodiment is applicable to the aforementioned software testing apparatus 20.

[0031] In step S402, the software testing device 20 uses the processor 28 to insert multiple test instructions into multiple execution segments of the program code of the software under test to verify the execution process of each execution segment. This process includes whether it has been executed, the number of times it has been executed, and variable data during execution, etc., which are not limited here.

[0032] In step S404, the processor 28 estimates the code coverage of the software under test based on the execution history of the execution segment.

[0033] In some embodiments, the code coverage mentioned above includes source code coverage, which can be action-oriented languages ​​such as C++, C, Java, Basic, Python, Objective-C, Swift, PHP, and JavaScript. The processor 28, for example, divides the code into single-entry-single-exit (SESE) execution segments. This code coverage can be defined as the percentage of SESE execution segments that are executed at least once.

[0034] The preparation of the dough can be considered from the following two aspects:

[0035] I. Client-side code coverage: This part can be determined by inserting test commands (instruments) into the code of the software under test to answer questions about which code segments have been executed, how many times they have been executed, and the variable data during execution. This information can be recorded in a file, displayed directly on the screen, or reported back to the conversion module via the application programming interface (API).

[0036] II. Server-side code coverage: This part can be queried from the server via an HTTP request.

[0037] In some embodiments, the code coverage described above includes binary code coverage. Typically, when source code coverage is unavailable, specific tools can be used to estimate binary code coverage. Similar to source code coverage, SESE execution sections of binary code can also be defined. This portion can also be estimated directly using certain tools or from pre-inserted code.

[0038] The preparation of noodles can also be considered from the following two aspects:

[0039] I. Client-side two-process code coverage: This part can also be answered by inserting test commands in the test version of the program to determine which program segments have been executed, how many times they have been executed, and the variable data during execution, etc. This information can be recorded in a file, written directly to the screen, or reported to the conversion module through the application programming interface (API).

[0040] II. Server-side two-process code coverage: This part can be queried from the server via network request.

[0041] Returning to the flow in Figure 4, in step S406, the processor 28 predicts the reward for each operation based on the code coverage that can be achieved by executing each operation within a predetermined time.

[0042] In detail, the tester predicts the reward they will receive for each action. This reward can be converted into the possible score for each selectable action the tester sees on the screen, guiding the tester to take actions that will lead to the most valuable test report.

[0043] For example, based on the estimation of source code coverage or binary code coverage, processor 28 can use the following summation formula to estimate the reward for performing a certain operation action a:

[0044] reward = SUM elen(e) / (2k),

[0045] Here, e represents all that are not covered and can be reached from a in k steps.

[0046] The above formula can predict the action 'a' that will achieve the highest coverage in a short period of time.

[0047] For example, based on the program's execution flowchart, the processor 28 can predict whether the screen resulting from each operation might contain features / performance requirements specified in the user requirement document, or execution of publicly disclosed security-sensitive permissions / data, or key features based on user experience. If such a situation is likely, the processor 28 can assign a higher prediction score to that operation.

[0048] In terms of presenting the predicted score, the processor 28 can provide cues through visual / auditory technologies such as color temperature and patterns (e.g., trophies, wreaths, ice cream, lollipops).

[0049] Figure 5 is a schematic diagram of the conversion mechanism according to an embodiment of the present invention. Referring to Figure 5, this embodiment divides the tester reward feedback mechanism 50 into two parts: a client-side conversion mechanism 52 and a server-side conversion mechanism 54. The tester performs an action through the operating role 12. This action is converted into a test action by the client-side conversion mechanism 52 and provided to the server-side conversion mechanism 54. The server-side conversion mechanism 54 generates a test response, including coverage, errors, and vulnerabilities, and provides it to the client-side conversion mechanism 52. Finally, the client-side conversion mechanism 52 provides feedback to the action of the opponent 14 representing the program under test, and displays scores, audio-visual effects 56, etc., on the operation interface 10 as rewards for the tester's action. The purpose of the feedback mechanism 50 is to ensure that the value of the test report is reflected in the score obtained by the tester and the intensity of the sensory stimulation of the audio-visual effects.

[0050] It should be noted that if the software under test is a standalone application, the above-mentioned client-side conversion mechanism 52 and server-side conversion mechanism 54 can be combined into one.

[0051] In the embodiment of Figure 4, in addition to predicting the reward for the operation based on the code coverage rate, the processor 28 can also set additional rewards for the tester to perform the operation based on updated elements, major failures, violation of requirements, design flaws, specific test tasks, etc.

[0052] In step S408, the software testing device 20 uses the processor 28 to analyze multiple differences between the current version and the previous version of the software under test, and sets additional rewards for performing operations that match the test actions based on the test actions corresponding to the execution sections where these differences are located. The aforementioned differences include newly added screen elements, newly added code, modified execution sections, etc., and this embodiment does not limit their types.

[0053] In detail, during the debugging process or during the version update process, the embodiments of the present invention can track newly added screen elements, modified SESE, and newly added code, and give them extra high scores, so as to guide testers to trigger operation actions and achieve testing of program functions affected by version updates.

[0054] In step S410, the software testing device 20 uses the processor 28 to detect whether the execution of an operation causes a major failure of the software under test. If a major failure is determined to have occurred, the processor 28 sets an additional reward for executing the operation based on the number of major failures. The aforementioned failures include system crashes, system freezes, corruption of important data, or leakage of sensitive data, but this embodiment is not limited to these.

[0055] In detail, a major failure of the software under test (SUT) typically means that the software under test has lost its functionality, such as crashing, freezing (becoming unresponsive), corruption of important data, or leakage of sensitive data. If this major failure has never been reported before, the embodiments of this invention can award a higher feedback score; however, if a major failure is repeatedly reported, the feedback score can be reduced accordingly.

[0056] In step S412, the software testing device 20 uses the processor 28 to assess whether performing an operation results in an event that violates the user requirements document. If an event violates the user requirements document, the processor 28 sets additional rewards for performing the operation based on the importance of the event described in the user requirements document. These events include file upload failure, video playback failure, animation failure, incorrect button colors, absence of a specially designated button, or substandard performance, but this embodiment is not limited to these.

[0057] In detail, embodiments of the present invention can assess violations of user requirements documents, such as file upload failure, video playback failure, animation failure, button colors not matching the requirements document description, special designated buttons failing to appear on the screen, and substandard performance. If such a situation is determined to have occurred, a score can be awarded based on the importance of the event described in the user requirements document.

[0058] In step S414, the software testing device 20 is configured by the processor 28 based on the published security vulnerabilities or design flaws of the software under test, and based on the test actions corresponding to the execution segment where the security vulnerabilities or design flaws are located, to set additional rewards for performing operation actions that match the test actions.

[0059] The aforementioned security vulnerabilities include, for example, OWASPtop 10 security vulnerabilities or security vulnerabilities disclosed in CVEs. The aforementioned design flaws include, for example, design defects already disclosed in certain software components. This invention does not limit the source or type of security vulnerabilities or design flaws.

[0060] In step S416, the software testing device 20, through the processor 28, sets additional rewards for performing operations matching the test actions based on the test actions corresponding to the execution segment where the specific test task is located, for specific test tasks of the software under test. The aforementioned specific test tasks include performance testing, specific business process testing, stress testing, or load testing, but this embodiment is not limited to these.

[0061] In detail, in the outsourcing of testing of the software under test, if a specific purpose testing task is selected, such as performance testing, specific business process testing, stress testing, load testing, etc., the embodiments of the present invention can give the tester a greater reward after the operation of completing part of the testing purpose is achieved.

[0062] In some embodiments, the software testing device 20 uses a processor 28 to determine whether the software under test exhibits a design flaw based on general user experience. For example, when file downloads take an excessively long time, the lack of progress indicators (such as a spinning hourglass, digital clock, or analog clock) can cause users to wonder if the system has stopped responding. Similarly, failure to display account login status can leave users unsure if they have completed the login process. Furthermore, the arrangement of screen elements may lack aesthetic appeal. Additionally, some screen elements may be incomprehensible to users, causing confusion. Embodiments of this invention can provide greater rewards to testers when determining whether the software under test exhibits a design flaw.

[0063] In some embodiments, the grouping relationship between the test operations of the software under test and the player's actions can be further defined. Since there may be many test operations that can be performed in a given execution state of the software under test—for example, a shopping page may have dozens of category menu items (such as men's clothing, women's clothing, children's clothing, etc.) and hundreds of product photos; or there may be very few—for example, a two-stage verification screen may only have a one-time password (OTP) field and an OK button.

[0064] Testers may have many possible actions within a software testing interface (e.g., a game screen). For example, in a card game, there may be dozens of cards to play; in a Go game, there may be hundreds of possible placement points; in a Tetris game, there are multiple positions and rotation directions to choose from during the fall. Alternatively, the number of actions may be limited. For example, in a fighting game, there may only be a few moves to perform; in a Pac-Man game, the only options are to stop or move left, up, down, or right.

[0065] Based on the above, embodiments of the present invention can group several test operations into the same operation action; or conversely, group several operation actions into the same test action. The specific grouping mechanism will be detailed in the following embodiments.

[0066] In some embodiments, when there are more test operations than operation actions: the processor 28 of the software testing device 20 matches multiple test actions performed on multiple items of the same or similar nature to the same operation action, and in response to receiving the operation action, selects one of the multiple test actions matched by the operation action to be executed in a way that maximizes reward, fuzzing, randomization, or cybersecurity data distortion (e.g., XSS, SQL injection).

[0067] In detail, when there are more test operations than operation actions, embodiments of the present invention can map test operations with similar functions to the same operation action. For example, all product option elements can be mapped to one or more operation actions, and these operation actions will accept test operations of product option elements. On the other hand, test operations related to checkout, such as shopping cart, checkout, order inquiry, etc., can be mapped to another operation action.

[0068] In some embodiments, the processor 28 may determine the criteria for matching multiple test actions to the same operation action based on the predicted reward that can be obtained by performing each test action. For example, some operation actions may only correspond to test actions with higher predicted rewards, while some operation actions may only correspond to test actions with lower predicted rewards.

[0069] In some embodiments, when a tester selects a certain action, the processor 28 may select the test operation with the highest predicted feedback score from the test operations that match this action, or select the test operation by means of fuzzing, randomization, or cybersecurity data transformation. This embodiment does not limit the selection method.

[0070] In some embodiments, when there are more test operations than operation actions: the processor 28 of the software testing device 20 matches multiple operation actions with the same or similar characteristics to the same test action, and predicts the reward that can be obtained by performing multiple operation actions according to the importance of the test action, so as to provide the reward in response to receiving one of the multiple operation actions.

[0071] In detail, when there are fewer test operations than actual actions, embodiments of the present invention can map actions with similar image / location / sound characteristics to the same test operation, and add special audio-visual effects to the corresponding action based on the predicted reward (e.g., feedback score) of the test operation. Thus, after repeated use of the software testing interface (e.g., a game interface), testers can become familiar with which type of action might trigger which type of test operation.

[0072] In some embodiments, the processor 28 may set multiple sessions for performing actions using a software testing interface, and decide whether to proceed to the next session or end the operation (game over) based on the accumulated rewards from performing actions in one of the multiple sessions.

[0073] In detail, embodiments of the present invention allow testers to choose when to end the test, or to know the expected end time of the test. For example, the following mechanisms or procedures may be employed:

[0074] A. You can set up segments in the game, each with different backgrounds, music, characters, weapons, treasures, points, etc.

[0075] B. A time or target score budget can be set for each game segment, corresponding to the test budget for the test session. If a player fails to achieve the target score within the time limit, the player is considered to have failed and the game ends. At this point, the player can decide whether to replay another game segment. However, if the player achieves the score target within the time or budget, appropriate rewards or audio-visual incentives can be given, and the player can proceed to the next game stage.

[0076] In some embodiments, the processor 28 may decide whether to switch the software testing interface to another software testing interface based on the accumulated rewards from performing operations in the software testing interface.

[0077] In detail, embodiments of the present invention allow testers to select different software testing interfaces during the testing process, such as switching from the interface of the Pac-Man game to the interfaces of SimCity, social games, fighting games, Tetris, etc., and then accumulate scores in each of these different games, and even participate in the world leaderboard of such outsourced testing games.

[0078] In summary, the software testing method and apparatus of this invention, through the conversion mechanism between the user interface of the software under test (web page or application) and the software testing interface (e.g., game user interface), can protect the intellectual property rights of the application and its developers, allowing a wide range of gamers to participate in the software testing outsourcing industry and expanding the landscape of software testing human resources. Furthermore, this invention allows testers to combine their work with gaming, thereby maximizing testing efficiency, and through cooperation with major game development companies worldwide, cross-industry and cross-sectoral benefits can be generated.

[0079] Although the present invention has been disclosed above by way of embodiments, it is not intended to limit the present invention. Anyone skilled in the art can make some modifications and refinements without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

[0080] 10: User Interface 12: Role 14: Opponent 16: Program under test 18: Operational Items 20: Software testing device 22: Display device 24: Input device 26: Storage device 27: Connecting device 28: Processor 50: Feedback Mechanism 52: Client-side conversion mechanism 54: Server-side conversion mechanism 56: Score, sound and light effects S302~S314, S402~S416: Steps

Claims

1. A software testing method applicable to an electronic device having a processor, the method comprising the following steps: generating multiple test actions executable on multiple items on an operation interface of a software under test (SUT); creating a software testing interface, defining multiple operation actions (operation actions) of a tester in the software testing interface, and matching the operation actions to the multiple test actions of the software under test; determining the importance of each test action based on one or more execution sections in the program code of the software under test corresponding to each test action; predicting a reward obtainable by executing each operation action based on the importance of the test action matched to each tested operation action, and displaying the reward on the software testing interface; and providing feedback on the reward in response to receiving the execution result of the operation action.

2. The method of claim 1, wherein the steps of determining the importance of the test action based on one or more execution sections of the program code of the software under test corresponding to each of the test actions, and predicting the reward obtainable by performing each of the test actions based on the importance of the test actions matched to each tested operation, include: Multiple test instructions are inserted into multiple execution segments of the code in the software under test to verify the execution history of each execution segment, including whether it has been executed, the number of times it has been executed, and variable data during execution; based on the execution history of the execution segments, the code coverage of the software under test is estimated; and based on the code coverage that can be achieved by performing each operation within a predetermined time, the reward of the operation is predicted.

3. The method as described in claim 2, wherein the code coverage includes source code (source code) code coverage and binary code coverage, and includes distinction between user-side and server-side.

4. The method as described in claim 1, further comprising: The system analyzes multiple differences between the current version and the previous version of the software under test, and sets additional rewards for performing operations that match the test actions based on the test actions corresponding to the execution segments where the differences are located. The differences include newly added screen elements, newly added code, and modified execution segments.

5. The method as described in claim 1, further comprising: Detect whether performing the operation causes a major failure of the software under test; And if the software under test suffers a major failure, a reward is set based on the number of times the major failure occurs, which includes crashes, system freezes, damage to important data, or leakage of sensitive data.

6. The method as described in claim 1, further comprising: Determine whether performing the operation will result in a violation of the user requirements document. And if the event that violates the requirements is set, the reward given for performing the operation will be set according to the importance of the event described in the user requirements document. The events include file upload failure, video playback failure, animation failure, mismatched button colors, failure to appear of a specially designated button, or failure to meet the performance standard.

7. The method as described in claim 1, further comprising: Based on the disclosed security vulnerabilities or design flaws of the software under test, and based on the test action corresponding to the execution segment where the security vulnerability or design flaw is located, additional rewards are set for performing the operation action that matches the test action.

8. The method as described in claim 1, further comprising: For a specific test task of the software under test, based on the test action corresponding to the execution segment where the specific test task is located, additional rewards are set for performing the operation action that matches the test action. The specific test task includes performance testing, specific business process testing, stress testing, or load testing.

9. The method as described in claim 1, further comprising: Multiple test actions performed on multiple projects with the same or similar nature will be matched to the same operation action; In response to receiving the execution result of the operation, one of the plurality of test actions matched with the operation is selected and executed by maximizing the reward, fuzzing, randomizing or deforming the information.

10. The method of claim 9, wherein the step of matching multiple test actions performed on multiple items of the same or similar nature to the same operation action includes: Based on the predicted rewards that can be obtained by performing each of the plurality of test actions, a criterion is determined to match the plurality of test actions to the same operation action.

11. The method as described in claim 1, further comprising: Multiple actions with the same or similar characteristics are matched to the same test action, and the reward that can be obtained by performing the multiple actions is predicted according to the importance of the test action, so as to provide the reward in response to receiving the execution result of one of the multiple actions.

12. The method as described in claim 1, further comprising: Define multiple segments for performing the operation using the software testing interface; And based on the accumulated reward from performing the operation in one of the plurality of paragraphs, decide whether to proceed to the next paragraph or end the operation.

13. The method as described in claim 1, further comprising: Based on the accumulated rewards from performing the operation in the software testing interface, a decision is made as to whether to switch the software testing interface to another software testing interface.

14. The method as described in claim 1, further comprising: In response to receiving the end operation, the system collects the operation actions received during the test, the test actions matched by the operation actions, the response of the system under test, and the rewards obtained as test trajectory data, and generates a test report for the software under test.

15. A software testing apparatus, comprising: Display device; Input device, receiving user input; Storage device for storing computer programs; The processor, coupled to the display device, the input device, and the storage device, is configured to load and execute the computer program to: generate multiple test actions that can be performed on multiple items on the user interface of the software under test; create a software test interface, define multiple user actions in the software test interface, and match the user actions to the multiple test actions of the software under test; determine the importance of the test actions based on one or more execution sections in the program code of the software under test corresponding to each test action; predict the reward that can be obtained by performing each test action based on the importance of the test actions matched to each tested action, and display the reward on the software test interface. And in response to receiving the execution result of the operation, the reward is given back.

16. The software testing apparatus of claim 15, wherein the processor includes inserting a plurality of test instructions into a plurality of execution segments of the code of the software under test to examine the execution history of each execution segment, the history including whether it has been executed, the number of times it has been executed, and variable data at the time of execution; estimating the code coverage of the software under test based on the execution history of the execution segments; and predicting the reward of the operation based on the code coverage that can be achieved by executing each operation within a predetermined time, wherein the code coverage includes source code coverage and binary code coverage, and includes distinctions between user end and server end.

17. The software testing apparatus of claim 15, wherein the processor further parses multiple differences between the current version and the previous version of the software under test, and sets an additional reward for performing an operation matching the test action based on the test action corresponding to the execution segment where the difference is located, the difference including new screen elements, new code, and modified execution segments.

18. The software testing apparatus of claim 15, wherein the processor further detects whether performing the operation causes a major failure of the software under test, and if it causes a major failure of the software under test, sets a reward for performing the operation based on the number of occurrences of the major failure, the major failure including crash, freeze, damage to important data or leakage of sensitive data.

19. The software testing apparatus of claim 15, wherein the processor further assesses whether performing the operation causes an event that violates the requirements based on a user requirements document, and if such event violates the requirements, sets a reward for performing the operation based on the importance of the event described in the user requirements document, the event including file upload failure, video playback failure, animation failure, mismatched button colors, absence of a specially designated button, or failure to meet performance standards.

20. The software testing apparatus of claim 15, wherein the processor further responds to receiving an end operation by collecting the operation received during the test, the test action matched by the operation, the response of the program under test, and the reward obtained as test trajectory data, and generating a test report of the software under test.

Images