Software Test Management Process
A general process of software testing:
Analysis of test requirements to determine
Test Plan
test execution
Test logging and defect tracking
Regression Testing
Test Summary and Report
test requirements
1 Requirements Specifications Check Points
<1 Correctness: Check requirements specification against original requirements
<2 Necessity: Requirement items that cannot be traced back to provenance may be redundant
<3 Priority: properly divided and identified
<4 Clarity: Do not use vague words
<6 Testability: Every requirement must be verifiable
<7 Completeness: Necessary and unnecessary information cannot be omitted
<8 Consistency: Consistent with original requirements, internally consistent
<9 Modifiable: Good organization makes requirements easy to modify
Steps for checking requirements documents
<1 Obtain the latest version of the software requirement specification, and try to obtain the original user requirement document as much as possible
<2 Read and try to understand all requirements described in the requirements specification
<3 Check against the requirements specification sheet
<4 Discuss the inspection results, revise the requirements specification and return to the first step until all the problems in the inspection list are passed
Test Plan
Software test plan is an overall design of the test process. By collecting project and product-related information, analyzing the test scope and test risk, estimating test cases, workload, resources and time, etc., the strategy adopted for testing , methods, environment, resources and progress to make reasonable arrangements.
1 Why do test plans
The inner role of the test plan:
<1 As a result of the test plan, for review by stakeholders and developers
<2 Storage plan schedule, test environment and more
<3 Stores details of plan execution and allows testers to do peer review
The external role of the test plan: to be viewed by the customer, and to explain the test work to the customer.
2 Test Plan Elements
Determining the test scope - formulating test strategy - test resource arrangement - schedule - risk and countermeasures
Determine the scope of the test
For example, for an integrated system, which integrates several existing systems to form a new system, it is necessary to consider whether the test scope includes all subsystems or only the interface part, and needs to be combined with the integration method. , the way between systems, etc. to decide.
Develop a testing strategy
Test strategy: sequence, test item priority, coverage method, regression test principle
Testing Tactics: Testing Methods Testing Skills Testing Tools
In order to design a good test strategy, it is necessary to understand the structure of the software, the distribution of functions, and the importance of each module to the customer. This determines the focus and priority of testing.
Regression testing should also be considered. According to the schedule of the project, the iteration frequency of the version, etc., the method of regression testing should be reasonably arranged. At the same time, the characteristics of the product, the importance of functional modules, the risk of errors, etc. should be combined to formulate effective strategies for regression testing. .
Schedule testing resources
By fully evaluating factors such as test difficulty, test time, workload, etc., to determine the rational use of test resources, it is necessary to evaluate the test workload according to the complexity and quality requirements of the test object, combined with test experience, so as to determine the test resource arrangement.
schedule
The progress of the test needs to be arranged in combination with the development plan of the project, the overall plan of the product, and the various activities of the test itself. The design of test cases, the construction of test environment, and the preparation of test reports are included in the schedule. It is best to reserve a buffer time between each test. On the one hand, the buffer time can be used for planned changes, and on the other hand, it can give testers time to improve and supplement test cases.
planning risk
Generally, the risks that may be encountered are the changes of the project plan, the inability of test resources to be in place in time, etc. When formulating the test plan, it should be evaluated according to the actual situation of the project, and a reasonable and effective corresponding strategy should be formulated.
For changes to the project plan, consider establishing a more general communication channel, so that testers can keep abreast of the changes and the impact of the changes, so that they can make corresponding changes, such as adjustment of the test plan.
Test design and test cases
The design of the test case is a detailed design of the specific execution of the test, and it is the concentrated reflection of the test thinking. Therefore, do not pursue the writing of test cases excessively, but consider more about the method and thinking of test case design.
Requirements-based testing approach
RBT (Requirements-Based Testing) is a requirements-based testing method that makes testing more effective because it focuses testing on the root cause of quality problems, namely requirements.
In a requirements-based testing approach, maintaining traceability to requirements is very important, maintaining traceability between requirements and test cases helps monitor progress, measure coverage, and of course control requirements changes
Requirements-based testing focuses on two things:
<Verify that the requirements are correct, complete, unambiguous, and logically consistent.
<From a "black box" perspective, design sufficient and necessary test sets to ensure that both design and code fully meet the requirements
Equivalent Partition Design
An equivalence class refers to a set of input domains in which each input condition is equivalent. Equivalence partitioning holds that if a condition in the equivalence class is used as the test data to test the program's defects, then the other conditions in the equivalence class cannot be used for testing.
Equivalence classes enable the typical black-box testing method not to consider the internal structure of the program, but only the input specification of the program.
The advantage of the equivalence division class is that it considers various situations of a single input domain, and avoids the incompleteness of blind or random selection of input data and the instability of coverage.
The disadvantage of equivalent division is that only the classification of the input domain is considered, and the combination of inputs is not considered. If only the equivalent division method is used, some cases may be missed.
boundary value division
Boundary value analysis assumes that most errors occur on the boundaries of various input conditions, and if values near the boundaries do not cause errors, other values are less likely to cause errors.
The value range of the boundary value is different, and the value basis is also different, and the positions of the upper point, the departure point, and the inner point are different.
Example:
Closed interval integer value range [1,10] The upper points are 1 and 10, the outliers are 0 and 11, the inner points are 2, 9, 4, 7, etc.
Open interval integer value range (1,10) points 1 and 10, off points 2 and 9, inner points 3, 4, 8, 7, etc.
Half-open and half-closed interval integer value range [1,10) on points 1 and 10, off points 2 and 9, inner points 2, 4, 8, etc.
basic path analysis
Basic path analysis is generally used in white-box testing to cover program branch paths, but it can also be used in some black-box testing.
The key point of the basic path analysis method is to cover the process to ensure that the program reflects all possible logic, but this method also has certain shortcomings, that is, the basic path analysis method only covers the process once, and does not consider some processes with loops.
cause and effect diagram
Cause-and-effect diagrams are simplified logic diagrams that intuitively show the relationship between program input conditions and output actions. The cause and effect diagram method is a method of designing test cases by means of graphics, which is especially suitable for various situations where the program under test has multiple input conditions and the output of the program depends on the input conditions.
The steps to design a test case using the cause-and-effect diagram method are as follows:
Analyze all possible inputs and outputs
Find the contrast between input and output
draw a cause-and-effect diagram
Convert a cause and effect diagram into a decision table
Corresponding decision table to each test case
For example, a business document processing rule is that for documents that are in the state of being submitted for review, if the data integrity rate reaches more than 80% or is confirmed by the salesperson, it will be accepted, otherwise it will be rejected.
Analyze input and output:
Input: In the state of submission, more than 80% of the data is complete and confirmed by the salesman
output: processing not processing
Input and output correspondence:
<1 is in submission and more than 80%, processing
<2 is being submitted and confirmed by the salesman, processing
<3 is being submitted, the data does not reach 80%, but the salesperson confirms it and processes it
<4 in submission but less than 80% and no confirmation, no processing
<5 not submitted, not processed
scene design
Scenario design is the test case design idea advocated by Rational's RUP development model
Most of the current software is event-controlled process, and the scene when the event is triggered is the so-called scene. In the process of test case design, by describing the event-triggered scene, it can effectively stimulate the design ideas of testers, and at the same time understand and understand the test case. Execution also helps a lot.
wrong guessing
The wrong guess method is based on experience and direct speculation about various errors that may occur in the program, and design test cases in a targeted manner.
Orthogonal table and equalization table use
Orthogonal table method is an effective design method to reduce the number of test cases.
Example:
Name: fill in, leave out
Gender: Male Female
Status: Active inactive
It is generally believed that each of the three conditions has two input parameters, and 8 use cases are required to cover them all.
Using the orthogonal table method then:
<1 The first step is to determine what factors exist, the factors are input conditions, name and gender status
<2 In the second step, each factor has several levels, and the level is the parameter of the input condition. For example, there are two input factors for gender, male and female.
<3 The third step is to select a suitable orthogonal table, here L4 (2^3) table is used, 2 identifies the number of levels (the number of parameters of the input conditions), 3 identifies the number of factors (that is, the number of input conditions), and 4 refers to 4 use cases
000
011
101
110
<4 Part 4 maps variable values to tables. E.g
The first column represents the name, 0 means fill in 1 means not fill in
The second column represents gender, 0 for male and 1 for female
The third column represents the status, 0 means active, 1 means inactive
<5 The fifth step is converted into test cases
Fill in name male activation
Fill in the name female is not activated
Do not fill in the name male will not activate
Do not fill in the name female activation
In the same orthogonal table, the number of occurrences of each level of each test factor is exactly the same, because in the experiment each level of each factor and each level of other factors have exactly the same probability of participating in the experiment , to ensure that the interference of other factors is excluded to the greatest extent in each level. The horizontal collocations (pairs of numbers formed horizontally) of any two sets of two columns (two factors) are identical.
The uniform test method is a design method similar to the orthogonal table test method. Orthogonal tables are characterized by neat comparability and balanced dispersion. The uniform method only considers uniform dispersion, which further reduces the number of tests.
Combining coverage with the use of PICT
Combination coverage can be divided into single factor coverage, paired coverage, and triple coverage according to the degree of combined coverage. The most commonly used is paired coverage. The pairwise coverage method requires that all horizontal combinations of two factors (input conditions) are covered at least once,
Combined coverage can be achieved using the PICT tool officially provided by Microsoft
PICT accepts a text model file as input, and then outputs a set of test cases. The model file format is as follows:
<Paramater>:<value1>,<value2>,<value3>,<valueN>
Separate input conditions and parameters with colons, one input condition per line, and separate parameters with commas,
E.g:
Size:128, 521,1024,2048
Files:FAT,FAT32,NTFS
Type:Logical,Single,Span,Mirror
Save the content to txt, there is a directory, and then enter on the command line
PICT “C:\PICT\MODEL.TXT”
If you need to generate test cases and store the test case generation results locally, use the following commands:
PICT “C:\PICT\MODEL.TXT” > “C:\PICT\OUT.TXT”