Software testing method based on defect pre-embedding and defect switch

Abstract

The present invention discloses a software testing method based on defect pre-embedding and defect switch, relates to the field of software testing and defect management, and comprises the following steps: Step 1: record defect data and extract problem features, construct a decision tree to independently classify defect data into front-end defects and back-end defects, create a defect collection form to design corresponding unique defect codes and defect types, and define a defect management list; the present invention records defect data and constructs a decision tree to classify them into front-end defects and back-end defects, creates a defect collection form, uses a system architect to divide defect data implantation tasks, and the front and back ends dynamically execute according to the switch status, creates a configuration interface to define the defect status, and realizes single and batch status switching, allows defect data to be entered in a preset form, dynamically switches normal and defect code segments, formulates defect strategy combinations according to teaching objectives, and creates a knowledge base to record each strategy and its implementation process and verification results.

Description

Technical Field

[0001] The present invention relates to the field of software testing and defect management, and in particular to a software testing method based on defect pre-embedding and defect switching. Background Art

[0002] The modern software industry's requirements for testers are constantly increasing. The software product architecture is becoming more complex, and the functional and performance requirements are diversified, making the testing process extremely challenging. This requires software testing training courses to be more in line with actual operations. With the increasing complexity of software products and the rising market demand for high-quality software, how to effectively train testers has become an important issue.

[0003] The existing technology has the following deficiencies: when designing embedded defects, the existing technology often relies on the needs of theoretical teaching, which means that the designed defects are to some extent different from the actual production environment and cannot truly reflect the common defects in the actual development process. Trainees have not received sufficient training on the complexity and uncertainty encountered in actual work.

[0004] Although the current simultaneous deployment of multiple versions provides an opportunity for comparative testing, it requires more hardware resources and operating costs. Students need to spend time switching between versions, which interferes with the learning process and leads to low teaching efficiency. The frequent version switching and multiple deployments of multiple versions in a single deployment increase the complexity of operations. Each deployment requires management and coordination, which increases the maintenance workload and burdens students' learning experience.

[0005] The above information disclosed in this Background section is only for enhancement of understanding of the background of the present disclosure and therefore it may contain information that does not constitute the prior art that is already known to one of ordinary skill in the art. Summary of the invention

[0006] The purpose of the present invention is to provide a software testing method based on defect pre-embedding and defect switching to solve the problems in the above-mentioned background technology.

[0007] In order to achieve the above object, the present invention provides the following technical solution: a software testing method based on defect pre-embedding and defect switch, specifically comprising the following steps:

[0008] Step 1: Record defect data and extract problem features, build a decision tree to independently classify defect data into front-end defects and back-end defects, create a defect collection form design corresponding to the unique defect code and defect type, and define the defect management list;

[0009] Step 2: Use system architects to divide the implantation tasks of defect data and develop defect code segments and normal code segments. The front and back ends dynamically execute the code according to the switch status and switch identification respectively;

[0010] Step 3: Create a configuration interface to define the basic status of defect data as open, closed, and pending verification, and display all defect data and current status. Set the status switching button to realize single defect status switching and batch defect status switching;

[0011] Step 4: Allow defect data to be entered into the system under test in a preset form, divide the presets to realize front-end and back-end defects, dynamically switch between normal and defective code segments, and realize real-time conversion of defect data status;

[0012] Step 5: Develop defect strategy combinations for different solutions based on the goals and scenarios of the teaching trial, set the test time frame and update the basic status of the defect data, and create a knowledge base to record each strategy and its implementation process and verification results.

[0013] Preferably, the defect data used as teaching trials when the test experts try out the system under test and the defect data designed by the test experts for the system under test in combination with scenarios and methods are recorded, the problem features of the defect data are extracted, the problem features are randomly selected to build a decision tree, and the internal branch nodes represent the problem features of the defect data, and the internal leaf nodes represent the type results. The problem features of the branch nodes are randomly selected to best split the defect data and independently classify them into front-end defects and back-end defects, create a defect collection form, design the corresponding defect unique code and defect type for each defect data, define a defect management list to enter the switch status, switch identification, defect unique code, defect type, defect source and test strategy of the defect data, display all entered defect data in pages through the defect management list, and regularly review the defect management list and mark and archive it.

[0014] Preferably, the system architect is utilized to divide the task of implanting defect data, and develops defective code segments and normal code segments in the codes that they are responsible for respectively, and utilizes the defect management list to enter and mark the unique defect code. The front end directly uses the key value corresponding to the switch identifier of the defect data as the label. When the system under test is executed, the query interface of the defect data is called through the unique defect code to query the switch status and switch identifier of the current defect in the defect management list. The back end determines the basic status of the defect data in the execution code according to the switch status of the defect data, and the front end matches the execution code according to the key value corresponding to the returned switch identifier.

[0015] Preferably, a configuration interface is created to define the basic status of defect data as on, off, and pending verification. All defect data and the current status are displayed through the configuration interface. Status switch buttons are set to implement single defect status switching and batch defect status switching. Single defect status switching only updates the current defect status, while batch defect status switching updates all selected defect statuses at once. Each defect status change is recorded in an operation log and an API interface is provided to allow defect status management to be called.

[0016] Preferably, defect data is allowed to be entered into the system under test in a preset form. The preset implementation of front-end defects specifically includes: when the user enters the system under test, a request is sent to the server to obtain the page location and the defect unique code, and the page location is matched, the defect status corresponding to the code module name is obtained according to the corresponding defect unique code and the key value of the corresponding status is returned, and the normal or defective version of the code is loaded according to the code module name. The preset implementation of back-end defects specifically includes: loading the back-end defects in the defect management list through the unified management class of the configuration interface, and obtaining the defect unique code, according to each back-end defect, the defect unique code of the normal code segment and the defective code segment is identified in the corresponding method body, when the user executes the method body, the normal code segment and the defective code segment are dynamically switched according to the switch status of the current defect data, and all preset defect data in the version are dynamically converted in the basic state of the defect data.

[0017] Preferably, formulate defect strategy combinations of different schemes according to the objectives and scenarios of the teaching trial. If the goal is to comprehensively test the capabilities of the system under test, then open multiple defect strategies, implement and specify 18 defects for extensive testing and develop test cases, record the results and close the defects. If the goal is to verify specific repairs, then only open the corresponding defect strategy, implement and specify 8 defects for focused testing and develop test cases, set the test time frame for the defect strategy, execute the test cases to record the actual results during the test, update the basic status of the defect data, close the fixed defects and record the verification results, create a knowledge base and enter each strategy and its implementation process and verification results.

[0018] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0019] 1. By eliminating version redundancy and simplifying the operation process, both students and teachers can focus more on improving teaching content and skills, and promote the improvement of overall education quality. The dynamic defect management concept can flexibly add and adjust defects according to actual teaching needs and specific scenarios, which is more in line with the actual operating environment and improves teaching efficiency. Students can quickly enter the actual operation state and conduct testing and learning in a real environment, which significantly reduces the cost and complexity of the tested system during multi-version deployment or switching.

[0020] 2. By combining course theory with actual work scenarios, students' engineering practice ability in real situations is improved. Teachers can design preset defects based on course content and dynamically add defects according to the actual work environment. This can not only best restore the real work environment, but also enable students to experience the connection between theory and practice in the process of problem solving, enhance the pertinence and practicality of learning, and enable students to gain practical experience in the environment by facing and dealing with real defects in real time in the experimental environment, cultivate keen insight and the ability to solve complex problems, and improve their mastery of system operation, abnormal analysis and solution strategies when dealing with defects, so as to achieve the goal of transforming theoretical knowledge into practical ability. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0022] Figure 1 The present invention is a method flow chart of the software testing method based on defect pre-embedding and defect switch. DETAILED DESCRIPTION

[0023] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that the description of the present disclosure will be more comprehensive and complete, and the concept of the example embodiments will be fully conveyed to those skilled in the art.

[0024] The present invention provides Figure 1 The software test method based on defect pre-embedding and defect switch shown in the figure specifically includes the following steps:

[0025] Step 1: Record defect data and extract problem features, build a decision tree to independently classify defect data into front-end defects and back-end defects, create a defect collection form design corresponding to the unique defect code and defect type, and define the defect management list;

[0026] Record the defect data used as teaching trials when test experts try out the system under test, as well as the defect data designed by test experts for the system under test in combination with scenarios and methods as teaching trials, extract the problem features of the defect data, randomly select the problem features to build a decision tree, and use the internal branch nodes to represent the problem features of the defect data, and the internal leaf nodes to represent the type results. Randomly select the best splitting pair of problem features of the branch nodes to independently classify the defect data into front-end defects and back-end defects, create a defect collection form, design the corresponding defect unique code and defect type for each defect data, define the defect management list to enter the switch status, switch identification, defect unique code, defect type, defect source and test strategy of the defect data, display all entered defect data in pages through the defect management list, and regularly review the defect management list and mark and archive it.

[0027] By building a decision tree and independently classifying defect data into front-end defects and back-end defects, defect management becomes more systematic and clear. Designing unique codes and types for each defect data helps to quickly identify and track defects. The defect management list provides the necessary switch states and identifications. The regular review function ensures timely updating and archiving of defect data, which helps to maintain an efficient testing process. Through the collection and management of actual defect data, the training courses can be more in line with real scenarios and help trainees develop practical problem-solving skills.

[0028] Step 2: Use system architects to divide the implantation tasks of defect data and develop defect code segments and normal code segments. The front and back ends dynamically execute the code according to the switch status and switch identification respectively;

[0029] System architects divide the task of implanting defect data, and develop defective code segments and normal code segments in the codes they are responsible for. The defect management list is used to enter and mark the unique defect code. The front end directly uses the key value corresponding to the switch identifier of the defect data as a label. When the system under test is executed, the query interface of the defect data is called through the defect unique code to query the switch status and switch identifier of the current defect in the defect management list. The back end determines the basic status of the defect data in the execution code according to the switch status of the defect data, and the front end matches the execution code according to the key value corresponding to the returned switch identifier.

[0030] System architects participate in the division of defect data implantation tasks, so that each developer is clear about the part they are responsible for. By entering and marking the unique defect code in the defect management list, the data of each defect becomes systematized, making the management of defect data more transparent and consistent. When executing the system under test, the switch status of the defect management list is queried through the unique code, realizing real-time monitoring and control of defects and being able to dynamically adjust the test environment. The front end directly uses the key value corresponding to the switch identifier of the defect data as a label, which simplifies data interaction, allows a more intuitive understanding of the defect status, and quickly responds to changes in requirements. The back end determines the basic status of the execution code based on the switch status of the defect data, ensuring that the code executed in different scenarios is reliable and reducing erroneous execution caused by defects.

[0031] Step 3: Create a configuration interface to define the basic status of defect data as open, closed, and pending verification, and display all defect data and current status. Set the status switching button to realize single defect status switching and batch defect status switching;

[0032] Create a configuration interface to define the basic status of defect data as open, closed, and pending verification, where open is defined as the defect is in an activated state, and the system under test shows the corresponding problem based on the defect data; closed is defined as the defect is in a repaired state, and the system under test is operating normally; pending verification is defined as the defect is in a repaired state but it remains to be verified whether the repair is successful. All defect data and the current status are displayed through the configuration interface, and status switching buttons are set to implement single defect status switching and batch defect status switching. Single defect status switching only updates the current defect status, and batch defect status switching updates all selected defect statuses at once. Each defect status change records an operation log and provides an API interface to allow defect status management to be called.

[0033] The basic status of defect data is clearly divided into "on", "off" and "pending verification". All defect data and their current status are displayed through the configuration interface to facilitate defect tracking and management. Single and batch status switching buttons are set to allow users to quickly update defect status as needed, which improves the flexibility and efficiency of operations. In particular, it significantly reduces the time cost when dealing with a large number of defects. Each defect status change is recorded in the operation log to ensure the transparency and traceability of the management process. An API interface is provided to allow the call of defect status management, which enhances the scalability and integration capabilities of the system under test. By introducing the "pending verification" status, it is ensured that the repaired defects can go through the verification process to prevent unrepaired defects from being mistakenly considered to have been resolved.

[0034] Step 4: Allow defect data to be entered into the system under test in a preset form, divide the presets to realize front-end and back-end defects, dynamically switch between normal and defective code segments, and realize real-time conversion of defect data status;

[0035] Defect data is allowed to be entered into the system under test in a preset form. The preset implementation of front-end defects specifically includes: when the user enters the system under test, a request is sent to the server to obtain the page location and the defect unique code, and the page location is matched. The defect status corresponding to the code module name is obtained according to the corresponding defect unique code and the key value of the corresponding status is returned. The normal or defective version of the code is loaded according to the code module name. The preset implementation of back-end defects specifically includes: loading the back-end defects in the defect management list through the unified management class of the configuration interface, and obtaining the defect unique code, identifying the defect unique code of the normal code segment and the defect code segment in the corresponding method body according to each back-end defect, when the user executes the method body, the normal code segment and the defect code segment are dynamically switched according to the switch status of the current defect data, and all preset defect data in the version are dynamically converted in the basic state of the defect data.

[0036] The page location and defect unique code are obtained through user requests, and the corresponding defect status is automatically matched and loaded, which greatly reduces the time of manual search and configuration and improves management efficiency. The backend can dynamically switch between normal code segments and defect code segments according to the switch status of the defect, ensuring that the system under test can respond quickly in different situations. The normal code segment and defect code segment are identified in the method body through the defect unique code, so that the defects and normal status of each module are clear at a glance. The unified management class of the configuration interface allows centralized management of backend defects, improves the ability to supervise defects, and reduces the potential risks brought by decentralized management. When the user executes the method body, the mechanism of dynamically switching defect code and normal code supports real-time verification, which helps to quickly discover and fix potential problems, and realizes the dynamic conversion of all preset defect data in the basic state, making defect management more systematic and facilitating the effective classification and processing of different defects.

[0037] Step 5: Develop defect strategy combinations for different solutions based on the goals and scenarios of the teaching trial, set the test time frame and update the basic status of defect data, and create a knowledge base to record each strategy and its implementation process and verification results;

[0038] Develop defect strategy combinations for different solutions based on the goals and scenarios of the teaching trial. If the goal is to comprehensively test the capabilities of the system under test, then open multiple defect strategies, implement and specify 18 defects for extensive testing and develop test cases, record the results and close the defects. If the goal is to verify specific repairs, then only open the corresponding defect strategy, implement and specify 8 defects for focused testing and develop test cases, set the test time frame for the defect strategy, execute the test cases to record the actual results during the test, update the basic status of the defect data, close the fixed defects and record the verification results, create a knowledge base and enter each strategy and its implementation process and verification results.

[0039] Flexible selection and implementation of corresponding defect strategies according to different test objectives make testing activities more focused. Under the comprehensive test goal, multiple defect strategies are opened and extensive testing of 18 defects is implemented to ensure that the capabilities of all aspects of the system can be fully verified, which helps to discover potential problems in the system under test. For the verification goals of specific repairs, only the corresponding defect strategies are opened, and focused testing of 8 defects is implemented to ensure the effectiveness and reliability of the repairs, reduce unnecessary test interference, and improve verification efficiency. A knowledge base is created and the implementation process and verification results of each strategy are entered to promote knowledge accumulation and sharing. Example

[0040] Test whether the login function of the system under test is normal. Under normal circumstances, enter the user name and password in the login interface of the system under test and click Login. The password prompt requires a combination of 8-16 digits and letters, and feedback of login success information or error information.

[0041] The teacher logs in to the system under test and enters the defect management list, retrieves the preset defect data for the system under test login, and selects the basic state of the defect data as on; when the student tests the login function of the system under test, he uses the boundary value test method to input the user name and characters that do not meet the password specification requirements, clicks to log in, and when the system under test executes the login method body, it queries the switch state of the current defect data according to the defect unique code. If the query state is on, the defect code is executed, that is, the password specification verification is skipped and the user authentication is directly entered. If the query state is off, the normal code is executed, that is, the password specification verification is entered and an error message is returned if it does not meet the requirements. When the student finds that the password entered does not meet the specifications and there is no error prompt, the error message is found and the login defect is submitted.

[0042] When the system under test is completed, the teacher turns off the switch of the login defect through the defect management list and updates the defect status. The student tests the system under test again, opens the login interface, enters the user name and the password that does not meet the specifications and clicks to log in. The system under test then executes the login method body and queries the defect data according to the preset defect unique code. If the switch status is off, the normal code is executed and the password is verified to be non-compliant. If it is not compliant, an error message is returned. The student re-tests the login and finds that the error message does not exist, which verifies that the login defect has been fixed. Example

[0043] Assume that the current system under test is an e-commerce system, and it is necessary to test whether the shopping process of the system under test has defects.

[0044] The teacher logs in to the system under test and enters the defect management list, retrieves the preset defect data of the shopping process of the system under test, and selects the basic state of the defect data as open; similarly, according to the steps of Example 1, when students test the system under test according to the test case, if they find a defect, they submit the defect. The teacher checks the students' discovery of the defect data, turns off the switch of the shopping process defect through the defect management list, and asks the students to retest. The teacher turns off the defects in batches according to the students' discovery of defects and the formulated test strategy until all defects are found. The students retest the shopping process and find that the error information does not exist, then it is verified that the shopping process defect has been fixed.

[0045] The above description is only by way of illustration of certain exemplary embodiments of the present invention. It is undoubted that those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the above drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. A software testing method based on defect pre-embedding and defect switch, characterized in that: The specific steps include: Step 1: Record defect data and extract problem features, build a decision tree to independently classify defect data into front-end defects and back-end defects, create a defect collection form design corresponding to the unique defect code and defect type, and define the defect management list; Step 2: Use system architects to divide the implantation tasks of defect data and develop defect code segments and normal code segments. The front and back ends dynamically execute the code according to the switch status and switch identification respectively; Step 3: Create a configuration interface to define the basic status of defect data as open, closed, and pending verification, and display all defect data and current status. Set the status switching button to realize single defect status switching and batch defect status switching; Step 4: Allow defect data to be entered into the system under test in a preset form, divide the presets to realize front-end and back-end defects, dynamically switch between normal and defective code segments, and realize real-time conversion of defect data status; Step 5: Develop defect strategy combinations for different solutions based on the goals and scenarios of the teaching trial, set the test time frame and update the basic status of the defect data, and create a knowledge base to record each strategy and its implementation process and verification results.

2. The software testing method based on defect pre-embedding and defect switch according to claim 1 is characterized in that: In the step one, the defect data used as teaching trials when the test experts try out the system under test and the defect data designed by the test experts for the system under test in combination with scenarios and methods as teaching trials are recorded, a decision tree is constructed to independently classify the defect data into front-end defects and back-end defects, a defect collection form is created, a corresponding defect unique code and defect type are designed for each defect data, a defect management list is defined, all entered defect data are displayed in pages through the defect management list, and the defect management list is regularly reviewed, marked and archived.

3. The software testing method based on defect pre-embedding and defect switch according to claim 2 is characterized in that: The method of constructing a decision tree to independently classify defect data into front-end defects and back-end defects specifically includes: extracting problem features of the defect data, randomly selecting problem features to construct a decision tree, and using internal branch nodes to represent the problem features of the defect data, using internal leaf nodes to represent type results, and randomly selecting the best splitting method for the problem features of the branch nodes to independently classify the defect data into front-end defects and back-end defects.

4. The software testing method based on defect pre-embedding and defect switch according to claim 1 is characterized in that: In the step 2, the system architect is used to divide the implantation task of the defect data, and develops defective code segments and normal code segments in the codes they are responsible for. The defect unique code is entered and marked using the defect management list. The front end directly uses the key value corresponding to the switch identifier of the defect data as a label. When the system under test is executed, the query interface of the defect data is called through the defect unique code to query the switch status and switch identifier of the current defect in the defect management list. The back end determines the basic status of the defect data in the execution code according to the switch status of the defect data, and the front end matches the execution code according to the key value corresponding to the returned switch identifier.

5. The software testing method based on defect pre-embedding and defect switch according to claim 1 is characterized in that: In the step three, a configuration interface is created to define the basic status of defect data as open, closed, and pending verification. All defect data and the current status are displayed through the configuration interface. Status switching buttons are set to implement single defect status switching and batch defect status switching. Single defect status switching only updates the current defect status, while batch defect status switching updates all selected defect statuses at one time. Each defect status change is recorded in an operation log and an API interface is provided to allow defect status management to be called.

6. The software testing method based on defect pre-embedding and defect switch according to claim 1 is characterized in that: In the step 4, defect data is allowed to be entered into the system under test in a preset form, and the front-end and back-end defects are preset. When the user executes the method body, the normal code segment and the defective code segment are dynamically switched according to the switch state of the current defect data, and all preset defect data in the version are dynamically converted in the basic state of the defect data.

7. The software testing method based on defect pre-embedding and defect switch according to claim 6 is characterized in that: The preset implementation of front-end and back-end defects specifically includes: when the user enters the system under test, a request is sent to the server to obtain the page location and the defect unique code, and the page location is matched, the defect status corresponding to the code module name is obtained according to the corresponding defect unique code and the key value of the corresponding status is returned, the normal or defective version of the code is loaded according to the code module name, the back-end defects in the defect management list are loaded through the unified management class of the configuration interface, and the defect unique code is obtained, and the defect unique codes of the normal code segment and the defective code segment are identified in the corresponding method body according to each back-end defect.

8. The software testing method based on defect pre-embedding and defect switch according to claim 1 is characterized in that: In the step five, formulate defect strategy combinations of different schemes according to the objectives and scenarios of the teaching trial; if the goal is to comprehensively test the capabilities of the system under test, then open multiple defect strategies, implement and specify 18 defects for extensive testing and formulate test cases, record the results and close the defects; if the goal is to verify specific repairs, then only open the corresponding defect strategy, implement and specify 8 defects for focused testing and formulate test cases, set the test time frame of the defect strategy, execute the test cases to record the actual results during the test, update the basic status of the defect data, close the fixed defects and record the verification results, create a knowledge base and enter each strategy and its implementation process and verification results.

Images