CN113934646B - System and method for software testing - Google Patents
System and method for software testing Download PDFInfo
- Publication number
- CN113934646B CN113934646B CN202111545933.5A CN202111545933A CN113934646B CN 113934646 B CN113934646 B CN 113934646B CN 202111545933 A CN202111545933 A CN 202111545933A CN 113934646 B CN113934646 B CN 113934646B
- Authority
- CN
- China
- Prior art keywords
- test
- round
- case
- cases
- defect
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The embodiment of the application discloses a system and a method for software testing, which comprises the steps of creating a test plan, wherein the test plan at least comprises two test rounds, and the test rounds have a sequence; loading a first test case; sequentially testing each test round, and determining whether the next test round can be started or the test round needs to be added based on the test condition of the current test round and a preset condition; when all test rounds are finished, generating a first test result; generating a test report based on the first test result; the whole test plan process is controlled, and the case execution condition and the defect condition are analyzed and counted to provide data support for project replication.
Description
Technical Field
The present application relates to the field of software systems, and more particularly, to a system and method for testing software.
Background
As an indispensable software testing loop in the whole software life cycle, few platforms or systems specially serving for software testing are available in the market, and basically some project management software has test cases and defect management functions, but the actual use requirements are not met for the whole software testing process. And the turn circulation in the whole software testing process is that the online system is lack of corresponding access control, which is completely determined by manpower, and the risk of project quality is high. And after the project test is finished, a test report cannot be automatically generated, quantitative data of the project quality related pair and data analysis of each dimension cannot be provided, and data support is provided for project replication. Therefore, a test platform which can be specially used for the whole test process of a user is needed in the software test industry, the test process is standardized, the test efficiency is improved, and quality boards of all dimensions are provided.
Disclosure of Invention
One of the embodiments of the present specification provides a method for software testing, including creating a test plan, where the test plan includes at least two test rounds, where the test rounds have a sequential order; loading a first test case; sequentially testing each test round, and determining whether the next test round can be started or the test round needs to be added based on the test condition of the current test round and a preset condition; when all test rounds are finished, generating a first test result; and generating a test report based on the first test result.
Further, labeling the loaded first test case; and when all the test rounds are tested, pushing one or more test cases in the final test cases to the regression case pool.
Further, the method also comprises the steps of converting the test cases in the regression case pool into automatic test cases and marking the automatic test cases.
Further, the step of sequentially testing each test round, and determining whether the next test round can be started or the test round needs to be added based on the test condition of the current test round and the preset condition comprises importing a second test case; distributing a tester to execute the test; generating a second test result; and determining whether the current test round is qualified or not based on the second test result.
Further, the importing the second test case includes importing the second test case from the regression case pool.
Further, the test report may at least include the test round, the number of test case executions, the defect repair rate, the secondary round convergence rate, the test case execution rate, the number of smoking test case pieces, the smoking test case passing rate, the effective defect, the defect repair rate, the defect density, the daily defect clearance rate, the defect reopening rate, the quality convergence rate, and the defect cause distribution.
One of the embodiments of the present specification further provides a system for software testing, including a test plan creating module, configured to create a test plan, where the test plan includes at least two test rounds, where the test rounds have a sequence; the first test case loading module is used for loading a first test case; the test module is used for sequentially testing each test round, and determining whether the next test round can be started or the test round needs to be added based on the test condition of the current test round and a preset condition; the first test result generation module is used for generating a first test result when all test rounds are tested; and the test report generating module is used for generating a test report based on the first test result.
Further, the test system comprises a regression case pool and a label correlation module, wherein the label correlation module is used for marking a label on the loaded first test case; and the test case pushing module is used for pushing one or more test cases in the final test cases to the regression case pool when all test rounds are tested.
The test case conversion module is used for further converting the test cases in the regression case pool, and the test module comprises a second test case leading-in unit which is used for leading in the second test case; the tester distributing unit is used for distributing testers to execute tests; the second test result generating unit is used for generating a second test result; and the judging unit is used for determining whether the current test round is qualified or not based on the second test result.
Drawings
The present description will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. These embodiments are not intended to be limiting, and in these embodiments like numerals are used to indicate like structures, wherein:
FIG. 1 is an exemplary flow diagram of a method for software testing, according to some embodiments described herein;
FIG. 2 is an exemplary flow diagram of a method of testing each test run in accordance with some embodiments of the present description;
FIG. 3 is an exemplary block diagram of a system for software testing, shown in accordance with some embodiments of the present description;
FIG. 4 is an exemplary block diagram of a test module shown in accordance with some embodiments of the present description.
Detailed Description
In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only examples or embodiments of the present description, and that for a person skilled in the art, the present description can also be applied to other similar scenarios on the basis of these drawings without inventive effort. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.
The present application will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. These embodiments are not intended to be limiting, and like reference numerals refer to like structures throughout these embodiments.
The scenarios referred to by embodiments of the present specification may include at least a user, a server, a network, and a storage device.
In some embodiments, the software testing system may be used in various scenarios requiring software testing, such as software on-line testing, software iterative testing, and the like.
The users may include one or more of testers, managers, developers, and the like. The user may test the software by using the user terminal, where the user terminal may be various devices (e.g., a smart phone and/or a computer, etc.), and for example, a manager may issue a test item through the user terminal. As another example, a tester may complete a test plan through a user terminal.
Servers may be used to manage resources and process data and/or information. In some implementations, the server has a processor disposed thereon, and the processor can be configured to process the obtained data, information, and the like and execute program instructions according to the data, information, and the like to implement the functions described in some embodiments of the present specification. In some embodiments, the server may be communicatively coupled to the user terminal to receive instructions from the user to implement the software testing functions described in some embodiments of the present disclosure.
The network may provide a conduit for the exchange of information. In some embodiments, information may be exchanged between the user terminal, the server, and the storage device over a network. For example, a manager can issue a test item through a network, the server receives the issued test item, generates a test plan, and sends the test plan to a tester for testing, and the tester performs testing according to the received test plan to obtain a test result.
The storage device may be used to store data and/or instructions. For example, the test results are stored in a memory device. For another example, the test requirements issued by the user terminal are stored in the storage device.
The foregoing is merely for convenience in understanding and the present system may be used to practice the method in some embodiments of the present disclosure in other possible implementations.
FIG. 1 is an exemplary flow diagram of a method for software testing, according to some embodiments described herein. As shown in fig. 1, the process 100 may include the following steps. In some embodiments, the process 100 may be performed by the software testing system 300.
A test plan may refer to a plan relating to software testing. In some embodiments, a test plan may be created according to project requirements. For example, a test plan is created based on the size of the project.
In some embodiments, the functional test case can be created by online creation or Excel import on a web interface. For example, when a current iteration is tested, a tester may import a functional test case of the current iteration.
In some embodiments, a test plan may be associated with a project.
In some embodiments, the test plan may include a test procedure for a project iteration. For example, test runs. In some embodiments, the test procedure for each project iteration may correspond to a test plan.
A test round may refer to the number of times a software test is performed. In some embodiments, the test runs may include a lead run and a pre-issue run. In other embodiments, the test runs may also include one or more of smoking wheels, secondary runs, and the like.
In some embodiments, the different rounds have different precedence. For example, the smoking wheel precedes the primary wheel, the primary wheel precedes the secondary wheel, and the secondary wheel precedes the pre-dispensing wheel.
In some embodiments, the test round may be determined by project. For example, according to the size of the item. As another example, according to the complexity of the project.
The first test case may refer to a test case for iterative testing of software. E.g., all test cases of the current iteration.
In some embodiments, the test case of the current iteration may be loaded into the test system in advance; the test system may also be loaded while the test is being performed. For example, a pre-created test case for this iteration is loaded. As another example, test cases for other iterations of the project are loaded.
In some embodiments, test cases may be loaded according to their type. For example, the functional test cases required for this iteration are loaded.
In some embodiments, step 130 may further be included to label the loaded first test case. In some embodiments, step 130 may be performed by tag association module 340.
The tags may be used to identify the level of the test case. Such as smoke, function, regression, etc.
In some embodiments, a test case may correspond to a label. For example, test case 1 may be labeled with a smoke label. In other embodiments, a test case may correspond to multiple types of tags. For example, test case 2 may be labeled with a smoke label and a function label. The relationship of test cases and labels may be other relationships as well.
In some embodiments, the test system may automatically identify the level of the test case and label it with a corresponding label. In other embodiments, test cases may also be marked manually.
In some embodiments, step 140 may also be included, when all test rounds are tested, pushing one or more of the final test cases to the regression case pool. In some embodiments, step 140 may be performed by the test case push module 350.
The regression case pool may refer to a unit storing multiplexed test case information. In some embodiments, the regression case pool may provide information for the test system to reuse test cases. For example, a memory cell storing multiplexed test cases. For another example, a file in which the address of the multiplexed test case is recorded. The multiplexing test case may refer to an important test case. For example, test cases that are used more than once. Also for example, a test case implementing the main program function. In some embodiments, the test system may push test cases to the regression case pool based on whether the test cases satisfy the condition of reusing the test cases. For example, the test cases which are used more than once in the last software iteration or software development are pushed to the regression case pool. For another example, the test case that implements the main program function is pushed to the regression case pool.
In other embodiments, the test cases may be pushed to the regression case pool in other feasible ways, including but not limited to manual checking.
The final test case may refer to a final version of the test case for software testing. For example, for testing test cases used by the pre-release wheel. For another example, the test case is finally determined after modification or deletion.
In some embodiments, the final test case may be determined based on the type of test round. For example, the test case used by the pre-release wheel to implement the main program may be determined as the final test case. In some embodiments, the modified test case may be used as the final test case. For example, one or more of the modified first test cases may be determined as final test cases.
In some embodiments, the method further comprises converting the test cases in the regression case pool into automatic test cases and marking the automatic test cases.
The automatic test case refers to a test case capable of performing automatic test.
In some embodiments, the test cases in the regression pool may be converted into automated test cases in various possible ways, including but not limited to one or more of manual conversion, association of test cases in the regression pool with automated tests, and the like.
The identification can be used to show whether the test case is an automated test case.
In some embodiments, automated test cases may be identified in a variety of possible ways.
And 150, sequentially testing each test round, and determining whether the next test round can be started or the test round needs to be added based on the test condition of the current test round and a preset condition. In some embodiments, step 130 may be performed by test module 360.
The current test round refers to the test round currently under test.
The preset condition may refer to a preset condition that the current test round is qualified. In some embodiments, the preset conditions may be different for different test runs. For example, the preset conditions for the smoking wheel test are different from the preset conditions for the first round of testing.
The next test round may refer to a test round in which a test is performed next after the current test round in order of precedence. For example, the test plan includes a smoking wheel, a first wheel, a second wheel, and a pre-release wheel, and when the current test round is the first round, the next test round is the second round.
In some embodiments, when the test is executed, the execution condition of the current test round can be counted in real time and displayed. For example, the execution progress, the passing rate, the defect repair rate and the like of the current test round are displayed in real time. So that the tester can conveniently judge the test quality of the current project.
For more details of step 150, refer to fig. 2 and its related description, which are not repeated herein.
The first test result may refer to the test result of all rounds in the test plan.
In some embodiments, the first test result may include one or more of a use case execution condition, a defect condition, etc. of the test plan.
In some embodiments, the test system may generate the first test result in various possible ways, including but not limited to pulling all of the second test results, generating the first test result based on the second test results. For example, the sum of the test case execution schedules of the test results of the plurality of test rounds is determined as the test case execution schedule of the first test result. For another example, the test case passing rates of the second test results are compared to obtain the test case passing rate of the first test result. Further contents of the second test result are shown in fig. 2 and the description thereof, which are not repeated herein.
The test report may refer to statistics of the test plan. The test report may be used to reflect the execution of the test plan.
In some embodiments, the test report may include a table of test results.
In other embodiments, the test report may include a histogram of the defect cause distribution.
In some embodiments, the test report may include metrics for multiple dimensions. Such as metrics related to the execution of test cases. As another example, an index related to data related to a defect.
In some embodiments, the test case execution conditions may include one or more of the number of test case executions, data related to defects, and the like. The data related to the defect may include one or more of a daily cleaning rate of the defect, a reopening rate of the defect, a distribution of causes of the defect, a total number of the defect, and the like.
In some embodiments, the test report may include one or more of the test round, number of test case executions, defect repair rate, secondary round convergence rate, test case execution rate, number of smoking test case pieces, smoking test case pass rate, effective defects, defect repair rate, defect density, defect daily clean rate, defect reopening rate, quality convergence rate, defect cause distribution, and the like.
The number of test case executions may refer to the number of test cases executed in the test plan. For example, the number of test case executions may be the total number of test cases that were executed (i.e., no test cases that were repeatedly executed are included). As another example, the number of test case executions may be the number of times the test case is executed (i.e., including repeatedly executed test cases).
Some embodiments of the present description may feed back data regarding the size of the test items, the workload of the test plan, and the defects.
The defect repair rate may represent the condition of repairing the defect for the current test run. In some embodiments, the defect repair rate may be the number of defects repaired in the current test run/the total number of defects in the current test run. For example, the first round of 4 defects is proposed, and 2 defects are developed and repaired, so that the defect repair rate is 50%.
In some embodiments, the defect repair rate needs to be 95% or more.
The defect convergence rate may indicate the convergence of the defect. In some embodiments, the defect convergence rate may be a defect convergence rate for each pass. For example, the secondary round convergence rate, the regression round convergence rate, etc.
In some embodiments, the secondary wheel convergence rate needs to be equal to or greater than 90% and the regression wheel convergence rate needs to be equal to or greater than 95%.
The test case execution rate may represent the execution of the test case. In some embodiments, the test case execution rate may be expressed in percentage. For example, test case/total test case has been executed.
In some embodiments, the test case execution rate needs to be greater than or equal to 95%.
The number of smoking test cases may refer to the number of test cases used for smoking testing.
The pass rate of the smoking test case can represent the pass condition of the smoking test case.
In some embodiments, the smoking case throughput rate may be expressed as a ratio. For example, in the first round of testing, the number of passes/total number of smoking test cases is executed for the first time by the smoking test case.
In some embodiments, the smoking case throughput rate needs to be greater than or equal to 90%.
Valid defects may refer to defects that are valid for software testing. For example, a defect that hinders the main program implementation.
In some embodiments, a valid defect may be the total number of defects after filtering invalid states in the project iteration associated with the plan.
The defect repair rate may indicate the repair of the defect.
In some embodiments, the repair of defects may be represented by a ratio. For example, the number of valid defects closed/total number of valid defects in the project iteration.
In some embodiments, the defect repair rate needs to be 95% or more.
The defect density may be indicative of the quality of the test case. In some embodiments, the defect density may be characterized by a ratio. For example, the number of defects associated with test cases/total number of test cases.
In some embodiments, the defect density may be the number of defects associated with a tester's test case/the total number of defects for the tester.
Some embodiments of the present description can obtain an index of case defect density related to a tester, and realize statistics of case design quality of the tester.
The daily defect clearance may be used to indicate the current condition for cleaning the defect.
In some embodiments, the daily defect clearance may be expressed as a ratio. For example, the date on which the date defect is required corresponds to the sum of the date count rate/the number of days on which the date defect is present during the execution of the test plan.
In some embodiments, defects with a high or urgent priority before 5 o ' clock of the day should be cleared the day, and defects with a high or urgent priority after 5 o ' clock of the day should be cleared the next 24 o ' clock of the day.
The defect reopening rate can feed back the condition of repairing the defect. For example, whether the defect is repaired is developed.
In some embodiments, the defect reopening rate may be expressed as a ratio. E.g. the number of defect reopening/total number of defects.
Some embodiments of the present description may feed back the developer's ability and attitude to repair the defect.
The quality convergence rate may represent the quality of the test run.
In some embodiments, the quality convergence rate may be expressed as a ratio. In some embodiments, the quality convergence rates for different test runs may be represented by different ratios. For example, the mass convergence rate of the secondary round may be: 1-the bugDI value of the second round/(the bugDI value of the second round + the first round). For another example, the mass convergence rate of the regression wheel may be: 1-the budDI value of the regression round/(second round + first round + budDI value of the regression round). Where the bugDI value may have different weights based on the severity of the defect, for example, severity: 0, mild: 0.1, general: 1, severe: 3 and fatal: 10 are suggested.
The defect cause distribution can be used for representing the distribution condition of the defects.
In some embodiments, the defect cause distribution may include one or more of program logic errors, requirement understanding errors, requirement design ignorance, discrepancies with UI interactions, requirement changes, front-end compatibility issues, version dependency issues, system configuration issues, UI design deficiencies, interface design errors, historical carryover issues, code overriding, merging code issues, and the like.
In some embodiments, statistics may be made of the distribution causes of defects. In some embodiments, the distribution causes of different defects in the statistics have different effects. For example, if the defect cause is that the defect count/total defect count ratio for which the demand design is unknown is too high, it can be determined that the demand of the production staff is not detailed and needs to be improved. For example, if the defect count of the program problem is too high, it can be determined that the development quality of the developer is not good, and the self-test needs to be strengthened.
The test report may also include test case execution progress. The test case execution progress may refer to a situation in which a test case is executed in each test round.
In some embodiments, test case execution progress may be represented by a ratio. For example, the number of use cases executed/total number of use cases. Illustratively, in the first round, 8 test cases are executed, and the test case execution progress is 80%.
The test report may also include a test case pass rate. The test case passing rate can represent the passing condition of the test cases in the test round.
In some embodiments, the test case pass rate may be represented by a ratio. For example, the number of test case execution status flags passed/total number of test cases for the round. Illustratively, 8 test cases are executed in the first round, 6 test cases are passed in the execution, and the case passing rate is 60%.
In some embodiments, the test report may also include other various information, including, but not limited to, one or more of report name, on-line purpose, on-line function, issue & risk, related project personnel, and the like.
In some embodiments, a test report may be generated based on the first test result after the project is brought online.
Fig. 2 is an exemplary flow diagram of a method of testing each test run in accordance with some embodiments of the present description. As shown in fig. 2, the process 200 includes the following steps. In some embodiments, the process 200 may be performed by the test module 360.
The second test case may refer to a test case used for testing the test round. Such as test cases required for a smoking wheel. As another example, the first round of required test cases.
In some embodiments, the corresponding test case may be imported according to the type of the round. For example, a smoking wheel is tested and smoking test cases required to test the smoking wheel are imported.
In some embodiments, the imported test cases may be all test cases (e.g., the first test case) required for the current iteration. For example, a first test case may be imported into a first round for testing.
In some embodiments, the test cases imported in different rounds may be different. In some embodiments, the test cases of different test rounds may be the same. In other embodiments, test cases of different rounds may partially overlap.
In some embodiments, the test cases of the corresponding round can be automatically imported according to the type of the test round. For example, when the test system recognizes that the type of the test round is a smoking wheel, a test case with smoking level is imported.
In some embodiments, importing the second test case from the regression case pool may be included. For example, the test system automatically pulls test cases in the regression case pool.
In other embodiments, the second test case may also be imported in various feasible ways, including but not limited to manual selection.
In some embodiments, when the second test case is imported, whether the imported case generates a defect or not may also be shown. For example, test cases with defects in other rounds are labeled.
In some embodiments, the test system may distribute the test cases to corresponding testers for testing in various feasible ways. For example, test executives are assigned by type of test case.
The second test result may refer to a test result of the current test round. For example, when performing a first round of testing, the second test result may be the test result of the first round of testing.
In some embodiments, the second test result includes indicators of multiple dimensions, which may include one or more of test case execution progress, defect repair rate, case passing rate, and the like. In some embodiments, the second test result may be partially identical to the first test result.
In some embodiments, data statistics may be performed on the test conditions of the current test round to obtain a second test result. For example. And carrying out statistics on the execution condition of the test case to generate a second test result of the test case.
In some embodiments, a use case state may be marked based on the execution of a test case, where a use case state may refer to the execution state of a test case. In some embodiments, use case status may include one or more of pass, block, fail, and the like.
In some embodiments, the execution of the same test case in different test rounds may be different. For example, the execution status of the execution case of test case 1 in the smoking wheel may be a failure, and the execution status of the execution case in the first round may be a pass.
In some embodiments, when the execution status of the test case is failure, recording the test case marked as failure may also be included.
In some embodiments, the manner in which test cases are marked may include associating bugs for failed test cases. For example, for each failed test case, a defect page is created for the failed test case, wherein the defect page may include one or more of preconditions, test steps, expected results, and other information related to the test case.
Some embodiments of the present description enable saving tester time in creating defects.
And 240, determining whether the current test round is qualified or not based on the second test result. In some embodiments, step 240 may be performed by decision unit 440.
In some embodiments, the test case status may be used to determine whether the test round is qualified. For example, whether the test round is qualified or not is determined according to the passing rate of the test cases.
In some embodiments, whether the current test round is qualified or not may be determined by whether one or more indexes in the test result reach a preset condition. For example, whether the use case execution progress reaches 90%, whether the defect repair rate is greater than 90%, and whether the use case passing rate reaches 90%.
In some embodiments, it may also be determined whether the current round is eligible based on the requirements of the partial test results illustrated in the first test result of FIG. 1. Wherein, the partial test result refers to the test result which is defined and acted the same as the second test result in the first test result.
And responding to the preset condition of meeting the current test turn, and enabling the current test turn to be qualified. And in response to the preset condition of the current test turn not being met, re-executing the test.
In some embodiments, it may also be determined whether the current test round requires circulation based on the second prediction result. For example, the first round, the test round, and the flow to the regression test round.
In some embodiments, when the use case execution progress is 100%, the use case passing rate is greater than 95%, and the defect repair rate is greater than 95%, the current test round may be circulated or online.
In some embodiments, when the test cases are executed in the current test round, the test cases may be selected for execution in the current test round. For example, the first round is circulated to the second round, and the test cases of the first round can be selected to be executed to the second round, wherein the circulated cases can be the state to be executed at the beginning.
In some embodiments, the second prediction result may further include a defect convergence rate, and the test system may further determine whether the test round needs to be increased based on the defect convergence rate. For example, the defect convergence rate of the test round of the second round is equal to the sum of the bugDI values of 1-second round/(the sum of the bugDI values of the first round + the second round), and when the defect convergence rate is less than 90%, it is determined that the test round needs to be increased.
FIG. 3 is an exemplary block diagram of a system for software testing, shown in accordance with some embodiments of the present description. As shown in FIG. 3, the system for software testing may include at least a test plan creation module 310, a first test case loading module 320, a testing module 360, a first test result generation module 370, and a test report generation module 380.
The test plan creating module 310 is configured to create a test plan, where the test plan includes at least two test rounds, and the test rounds have a sequence. In some embodiments, refer to fig. 1 and its related description for more details regarding the creation of the test plan, which are not repeated herein.
The first test case loading module 320 is configured to load a first test case. In some embodiments, refer to fig. 1 and the related description thereof for more contents regarding loading the first test case, which are not described herein again.
The test module 360 is configured to sequentially test each test round, and determine whether to move to the next test round or to increase the test round based on the test condition of the current test round and a preset condition. In some embodiments, reference is made to fig. 1 and the related description for further contents of testing each test turn in turn, and details thereof are not repeated here.
The first test result generating module 370 is configured to generate a first test result when all test rounds are completed. In some embodiments, reference is made to fig. 1 and the related description for more details regarding generating the first test result, which are not repeated herein.
And a test report generating module 380 for generating a test report based on the first test result. In some embodiments, refer to fig. 1 and the related description for further contents of generating a test report, which are not described herein again.
In some embodiments, the system for software testing may also include a regression use case pool 330. In some embodiments, reference is made to fig. 1 and the description thereof for more contents of the regression case pool, which is not described herein again.
In some embodiments, the system for testing software may further include a tag association module 340 configured to tag the loaded first test case. In some embodiments, reference is made to fig. 1 and the description thereof for more contents of tagging the loaded first test case, and details are not repeated here.
In some embodiments, the system for software testing may further include a test case pushing module 350, configured to push one or more test cases in the final test cases to the regression case pool after all testing rounds are completed. In some embodiments, reference is made to fig. 1 and the description thereof for more contents of pushing one or more test cases in the first test case to the regression case pool, and details are not repeated here. Feeding device
FIG. 4 is an exemplary block diagram of a test module shown in accordance with some embodiments of the present description. As shown in fig. 4, the test module 360 may include at least a second test case importing unit 410, a tester distributing unit 420, a second test result generating unit 430, and a determining unit 440.
And the second test case importing unit is used for importing a second test case. In some embodiments, for more about importing the second test case, refer to fig. 2 and the related description thereof, which are not described herein again.
And the tester distributing unit is used for distributing the testers to execute the tests. In some embodiments, reference is made to fig. 2 and the related description thereof for more about distributing the tester to perform the test, which is not described herein again.
And the second test result generating unit is used for generating a second test result. In some embodiments, reference is made to fig. 2 and the related description for more details regarding generating the second test result, which are not repeated herein.
And the judging unit is used for determining whether the current test round is qualified or not based on the second test result. In some embodiments, reference is made to fig. 2 and the related description for more details regarding determining whether the current test round is qualified, and details are not repeated here.
The second test result can display one or more data of project group, iteration, plan name, test stage, executed number of test cases, failed test cases, effective defects, execution progress, passing rate, defect repair rate, case name, function module, test case grade, creator, test case state, assigned executor, executor number, case name, case execution state, case type and the like.
The test system can select the test cases according to the types of the test rounds. In some embodiments, the test case includes a label. In some embodiments, the test case may further include whether a defect occurred.
In some embodiments, the test system may also multiplex the test cases by means of checking.
The test report may include a table. In some embodiments, the tabular form of the test report may be one or more of a test run, a number of executed cases, a case execution rate, a smoking case, a smoking pass rate, an effective defect, a defect repair rate, a defect density, a defect daily clean rate, a defect reopening rate, a secondary run quality convergence rate, a regression run quality convergence rate, and the like of the present iteration test.
The test report may include a distribution histogram. In some embodiments, the distribution histogram of the test report may exhibit one or more of program logic errors, discrepancies with UI interactions, demand understanding errors, others, and the like.
Some embodiments of the present description divide the testing process into multiple testing rounds through a testing plan. And each turn can pull the corresponding test case to execute, thereby meeting the requirements of the current software test flow. The test flow is standardized, and the test efficiency is improved.
Some embodiments of the description have corresponding system access control in each test round flow and online, so that unstable factors of manual judgment are avoided, and the project quality is improved.
In some embodiments of the present description, each turn has real-time test condition statistics, which helps project-related personnel to intuitively grasp the progress and risk of the current project test.
Some embodiments of the present description can automatically generate and send a test report after multi-dimensional data statistical analysis, and can visually feed back the test condition and quality condition of the whole project to related personnel, thereby providing data support for project replication.
Some embodiments of the present description may implement determining different criteria for different test runs by different criteria and names for the test process stage division.
It should be understood that the embodiments described herein are merely illustrative of the principles of embodiments of this disclosure. Other variations are also possible within the scope of the present description. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the specification can be considered consistent with the teachings of the specification. Accordingly, the embodiments of the present description are not limited to only those embodiments explicitly described and depicted herein.
Claims (8)
1. A method for software testing, comprising
Creating a test plan, wherein the test plan at least comprises two test rounds, and the test rounds have a sequence;
loading a first test case;
sequentially testing each test round, and determining whether the next test round can be started or the test round needs to be added based on the test condition of the current test round and a preset condition; the preset condition is a preset condition that the current test round is qualified, when the current test round meets the preset condition, the flow is determined to be transferred to the next test round, and when the current test round does not meet the preset condition, the current test round is executed again;
when all test rounds are finished, generating a first test result;
generating a test report based on the first test result;
the step of testing each test round in sequence and determining whether the next test round can be flowed or the test round needs to be added based on the test condition of the current test round and the preset condition comprises the steps of
Importing a second test case;
distributing a tester to execute the test;
generating a second test result;
and determining whether the current test round is qualified or not based on the second test result.
2. The method for software testing as recited in claim 1, further comprising
Labeling the loaded first test case;
and when all the test rounds are tested, pushing one or more test cases in the final test cases to the regression case pool.
3. The method for software testing according to claim 2, further comprising converting and identifying test cases in the regression case pool to automated test cases.
4. The method for software testing of claim 3, wherein said importing a second test case comprises importing the second test case from the pool of regression cases.
5. The method for software testing according to claim 1, wherein the test report at least comprises the test round, the number of test case executions, the defect repair rate, the secondary round convergence rate, the test case execution rate, the number of smoke test case pieces, the pass rate of smoke test case, the effective defect, the defect density, the defect daily clearing rate, the defect reopening rate, the quality convergence rate, and the defect cause distribution.
6. A system for software testing, comprising
The test plan creating module is used for creating a test plan, wherein the test plan at least comprises two test rounds, and the test rounds have a sequence;
the first test case loading module is used for loading a first test case;
the test module is used for sequentially testing each test round, and determining whether the next test round can be started or the test round needs to be added based on the test condition of the current test round and a preset condition; the preset condition is a preset condition that the current test round is qualified, when the current test round meets the preset condition, the flow is determined to be transferred to the next test round, and when the current test round does not meet the preset condition, the current test round is executed again;
the first test result generation module is used for generating a first test result when all test rounds are tested;
the test report generating module is used for generating a test report based on the first test result;
the test module includes:
the second test case importing unit is used for importing a second test case;
the tester distributing unit is used for distributing testers to execute tests;
the second test result generating unit is used for generating a second test result;
and the judging unit is used for determining whether the current test round is qualified or not based on the second test result.
7. The system for software testing according to claim 6, comprising a regression use case pool, further comprising
The label correlation module is used for marking a label on the loaded first test case;
and the test case pushing module is used for pushing one or more test cases in the final test cases to the regression case pool when all test rounds are tested.
8. The system for software testing according to claim 7, further comprising a test case transformation module for transforming the test cases in the regression case pool into automated test cases and marking the automated test cases.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111545933.5A CN113934646B (en) | 2021-12-17 | 2021-12-17 | System and method for software testing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111545933.5A CN113934646B (en) | 2021-12-17 | 2021-12-17 | System and method for software testing |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113934646A CN113934646A (en) | 2022-01-14 |
| CN113934646B true CN113934646B (en) | 2022-03-22 |
Family
ID=79289217
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111545933.5A Active CN113934646B (en) | 2021-12-17 | 2021-12-17 | System and method for software testing |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113934646B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110245088A (en) * | 2019-06-21 | 2019-09-17 | 四川长虹电器股份有限公司 | A kind of defect automated verification system and verification method based on Jenkins |
| CN111459809A (en) * | 2020-03-23 | 2020-07-28 | 汇通达网络股份有限公司 | Software testing method based on rapid demand version iteration |
| CN112988577A (en) * | 2021-03-08 | 2021-06-18 | 中国地震局第二监测中心 | Rapid software evaluation execution method |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1955945A (en) * | 2005-10-25 | 2007-05-02 | 国际商业机器公司 | Method and device for automatic generating test executive routine sequence of software test process |
| FR2895074B1 (en) * | 2005-12-21 | 2008-02-15 | Thales Sa | FUNCTIONAL MONITOR FOR FLIGHT MANAGEMENT SYSTEM |
| CN106708725A (en) * | 2015-11-17 | 2017-05-24 | 上海机电工程研究所 | Test sequence dynamic management method combining test with diagnosis |
| CN106227667B (en) * | 2016-07-28 | 2019-03-19 | 南京大学 | A kind of method for generating test case of the mobile application of the IFML based on extension |
| US10783065B2 (en) * | 2018-03-23 | 2020-09-22 | Sungard Availability Services, Lp | Unified test automation system |
| CN109144863A (en) * | 2018-08-10 | 2019-01-04 | 广东电网有限责任公司信息中心 | A kind of automated testing method based on network system |
| CN110059012B (en) * | 2019-04-24 | 2022-08-23 | 江苏满运软件科技有限公司 | Program test control method, device, storage medium and platform |
| CN110888801A (en) * | 2019-10-23 | 2020-03-17 | 贝壳技术有限公司 | Software program testing method and device, storage medium and electronic equipment |
-
2021
- 2021-12-17 CN CN202111545933.5A patent/CN113934646B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110245088A (en) * | 2019-06-21 | 2019-09-17 | 四川长虹电器股份有限公司 | A kind of defect automated verification system and verification method based on Jenkins |
| CN111459809A (en) * | 2020-03-23 | 2020-07-28 | 汇通达网络股份有限公司 | Software testing method based on rapid demand version iteration |
| CN112988577A (en) * | 2021-03-08 | 2021-06-18 | 中国地震局第二监测中心 | Rapid software evaluation execution method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113934646A (en) | 2022-01-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10185649B2 (en) | System and method for efficient creation and reconciliation of macro and micro level test plans | |
| CN107516192B (en) | Agile item management method, device, system, electronic device and storage medium | |
| Kellner et al. | ISPW-6 software process example | |
| Kellner et al. | Software process modeling example problem | |
| EP1577760A2 (en) | Method and system for testing software development activity | |
| CN108491254A (en) | A kind of dispatching method and device of data warehouse | |
| Asghar et al. | Impact and challenges of requirements elicitation & prioritization in quality to agile process: Scrum as a case scenario | |
| CN110333895B (en) | Automatic operation and maintenance platform for electric power regulation cloud | |
| CN107193730A (en) | A kind of interface test method of automation | |
| Dias-Neto et al. | Supporting the combined selection of model-based testing techniques | |
| EP2913757A1 (en) | Method, system, and computer software product for test automation | |
| CN113934646B (en) | System and method for software testing | |
| CN113221321A (en) | Simulation and index evaluation method and system based on task equipment fault | |
| CN112215510A (en) | Method, device, equipment and storage medium for generating work priority of nuclear power plant | |
| Van Moll et al. | The importance of life cycle modeling to defect detection and prevention | |
| Linger et al. | Cleanroom Software Engineering Reference Model: Version 1.0 | |
| Sedigh-Ali et al. | Metrics and models for cost and quality of component-based software | |
| CN115629956A (en) | Software defect management method and system based on interface automatic test | |
| Xin et al. | A framework of software reusing engineering management | |
| Farooq et al. | Quality practices in open source software development affecting quality dimensions | |
| Shaye | Transitioning a team to agile test methods | |
| Satyarthi et al. | Framework for Requirement Management using Requirement Traceability. | |
| CN115185825A (en) | Interface test scheduling method and device | |
| Nord et al. | A structured approach for reviewing architecture documentation | |
| Xie et al. | Design and implementation of bank financial business automation testing framework based on QTP |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20220114 Assignee: Yunzhu Information Technology (Chengdu) Co.,Ltd. Assignor: China Construction e-commerce Co.,Ltd. Contract record no.: X2023980032450 Denomination of invention: A system and method for software testing Granted publication date: 20220322 License type: Common License Record date: 20230220 |
|
| EE01 | Entry into force of recordation of patent licensing contract |