Process management of software testing
1. The various processes of software testing (PDCA)
1. Analysis and determination of test requirements 2. Test plan 3. Test design 4. Test execution 5. Test recording and defect tracking 6. Regression testing 7. Test summary and report
2. Test requirements
1. Check Points for Requirements Specifications
Correctness: Check requirements specification against original requirements
Necessity: Requirement items that cannot be traced back to the source may be redundant
Prioritization: properly divided and identified
Clarity: not using vague words
Testability: Every requirement must be verifiable
Integrity: Necessary and necessary information cannot be omitted
Consistency: Consistent with original requirements, internally consistent
Modifiability: Good organization makes requirements easy to modify
3. Inspection steps of requirements document
(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 the requirements described in the requirements specification
(3) Check and record against the requirements specification checklist
(4) Discuss the inspection results, revise the requirements specification and return to the first step until all items in the inspection list pass
Example:
1. Whether it covers all the requirements put forward by users
2. Whether the words are clear and whether there is any ambiguity in the semantics
3. Is there a clear description of what the software system needs to do and what not to do?
4. Whether the target environment for software use, including software and hardware environments, is described
5. Whether the demand items are properly numbered
6. Whether the requirements are consistent and do not conflict with each other
7. Whether the format of each input and output of the system, and the corresponding relationship between input and output are clearly explained
8. Whether the performance requirements of the software system are clearly described
9. Whether the priority of requirements is reasonably allocated
10. Are the various constraints described?
4. Check requirements by writing test cases
Testers build and attempt to answer the designed black-box tests to test the completeness, accuracy, clarity, and conciseness of requirements.
Five, the test plan
1. Determine the scope of the test
2. Develop a test strategy: (1) Test strategy: the order of testing, the priority of testing, the coverage method of testing, the principles of regression testing, etc.
(2) Test tactics: adopted technologies, architectures, protocols, etc.
3. Arrange test resources: Determine the rational use of test resources by fully estimating the difficulty of the test, test time, workload and other factors.
4. Arrange the progress: The progress of the test needs to be combined with the development plan of the project. The overall planning of the product is arranged, as well as the various activities that consider the test itself.
5. Plan risks: Estimate the risks that may be encountered during the testing process and formulate corresponding countermeasures.
Six, test design and test cases
1. Requirements-based testing approach
RBT is a requirements-based testing method that makes testing more effective because it focuses testing on the root causes of quality problems.
Requirements-based testing is one of the most fundamental software testing, focusing on the following two key issues
(1) Verify that the requirements are correct, complete, unambiguous, and logically consistent
(2) From the perspective of 'black box', design a sufficient and necessary test set to ensure that the design and code can fully meet the requirements.
2. Equivalence class division method
An equivalence class is a set of input domains in which each input condition is equivalent.
The legal person for equivalence class division is that if one condition in the equivalence class is used as the test data to test the program defects, then the other conditions in the equivalence class cannot be used for testing.
Equivalence class is a typical black-box testing method, which does not need to consider the internal structure of the program, but only needs to consider the input specification of the program.
Classify two equivalence classes: 1. Effective equivalence class: those that meet the conditions, 2. Invalid equivalence classes: those that do not meet the conditions
Although the equivalence class classification method is simple and easy to use, it does not fully consider the combination of last year's college entrance examination, and needs to be supplemented with other test case design methods.
3. Boundary value analysis method
Assuming that most errors occur on the boundaries of various input conditions, if values near the boundaries do not cause errors, other values are less likely to cause errors.
The advantage of boundary value analysis is that it is simple and easy to use, only needs to consider the value near the boundary of a single input, and this method is very effective in uncovering errors in many cases. However, like the method of equivalence class division, they do not consider the direct combination of inputs, so they need to be further combined with other test case design methods.
4. Equivalent value + boundary value
Usually combined with equivalence class division and boundary value analysis, the relevant input fields of the software are analyzed. Common analysis fields include integers, real numbers, strings and characters, dates, times, currencies, etc.
5. 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.
Fundamental path analysis focuses on covering the flow, ensuring that the program embodies all possible logic. However, 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 cycles. Therefore, it needs to be considered in combination with other test case design methods. Such as wrong guessing method, scene analysis method.
6. Cause and effect diagrams
A cause-and-effect diagram is a simplified logic diagram that visually shows the interrelationships between the conditions of a program's inputs and the actions of its outputs. The cause and effect diagram method is a systematic method for designing test cases by means of graphs, and 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.
Cause and effect diagram method design test case steps
1. Analyze all possible inputs and possible outputs
2. Find the correspondence between input and output
3. Draw a cause-and-effect diagram.
4. Convert the cause and effect diagram into a decision table
5. Map the decision table to each test case
By drawing a cause and effect diagram, the logical relationship between input conditions and the relationship between input and output can be more clearly understood. The disadvantage is that it needs to draw a picture and convert it into a judgment table, and it will take a lot of time for more complex input and output.
7. Scene design method
Most of the current software is triggered by events to control the flow, and the scene when the event is triggered is the so-called scene. In the process of test case design, by describing the situation when the event is triggered, it can effectively stimulate the design thinking of testers, and at the same time, it is of great help to the understanding and execution of test cases.
The scenario design method requires testers to give full play to their imagination of the user's actual business scenarios.
8. Wrong guessing
The error guessing method is used to speculate various errors that may occur in the program based on experience and intuition, and design test cases in a targeted manner. Because testing is not inherently a very rigorous discipline, the experience and intuition of the tester can complement this lack of rigor.
9. Orthogonal table
Orthogonal table method is an effective design method to reduce the number of test cases.
Orthogonal table design test case steps
(1) Determine what the factors are. For example, name, gender, status, three factors
(2) What are the levels of each factor? Level refers to the parameters of the input conditions. For example, the above name has two levels: fill in and not fill in
(3) Choose a suitable quadrature table
Example: Suppose there are three factors: name, gender, and status, and each factor has two levels: filled, unfilled, male, female, active, and inactive
That is, you can use the orthogonal table L4 (2^3) 4 means that four use cases need to be executed, 3 means the number of factors, and 2 means the number of levels
This orthogonal table is as follows: 0 means one level and 1 means another level
0 0 0: The first use case: fill in male activation
0 1 1: Article 2: Fill in female not active
1 0 1 : Article 3: Not Filled Male Not Activated
1 1 0 : Article 4 : Leave blank for female activation
If the orthogonal table is not used, then 8 items need to be executed, so I will not write them one by one.
The difficulty in using orthogonal tables for testing is finding a suitable orthogonal table.
Address: http://support.sas.com/techsup/technote/ts723_Designs.txt
10. Use the uniform experiment method to design test cases
Using the uniform experiment method to design test cases is similar to using the orthogonal table method. It also needs to go through several steps such as analyzing the input conditions and parameters, selecting the appropriate uniform table, insinuating factors and levels, and converting them into test cases.
11. Combined Coverage and Use of PICT
Combinatorial coverage method is another test case design method that effectively reduces the number of test cases. According to the different coverage, it can be divided into single factor coverage, paired combination coverage, and three-three combination coverage. Pairwise combined overlays are most commonly used.
Pairwise combination coverage requires that all horizontal combinations of any two factors (input conditions) be covered at least once.
PICT is an algorithm that implements combined coverage.
Use of PICT:
PICT takes a plain text and outputs a collection of test cases
The format is as follows
NAME : VALUE1, VALUE2,VALUE3....
Test cases can be dumped through PICT > PICT "text.txt" > "output.txt'
12. Use of classification trees and TESTONA
The entire input domain of test objects is divided into independent classes by a classification tree.
Using the classification tree approach, the most important source of information for the tester is the functional specification of the test object
It transforms test case design into a process of combining several structured and systematic test object components - making it easy to grasp, understand, and document.
step:
1. Identify the test object and analyze the input space
2. Classify the input space of the test object
3. Draw a classification tree and combine it into test cases
The core idea of classification tree design test case is the construction of classification tree, and TESTONA is a tool for designing classification tree.
13. Granularity of test cases
(1) The writing of test cases is too complicated or detailed, which will bring two problems, one is the efficiency problem, and the other is the maintenance cost problem
(2) If the test case is written too simply, the meaning of the test case may be lost.
7. Execution of the test
The analysis and inspection of requirements, the planning of tests, and the preparation of test cases are all prepared for the execution of tests.
1. Reasonable selection of test cases
(1) For the first execution of the test, a basic test case selection strategy is: first execute the basic test case, and then execute the complex test case; execute the test case with high priority first, and then execute the test with low priority. Example.
(2) The selection of test cases for regression testing is a bit more complicated.
2. Test division and resource utilization
The division of labor in the test can avoid the limitations of the tester's thinking. Different people may find different problems when executing the same use case.
3. Setting up the test environment
(1) Xu Ao uses a large amount of data, such as capacity testing, stress testing
(2) External hardware devices
(3) Multiple operating systems
(4) Deploying multiple machines
(5) Network equipment and network environment configuration
4. BVT test and smoke test
BVT tests, also known as compilation check tests, mainly check whether the source code can be correctly compiled into a new, fully usable version. If the BVT test fails, the tester cannot get the new version for testing.
The smoke test is to run its most basic functions first after a compiled version comes out. If there are errors in the simple operation, then the tester does not need to carry out the next in-depth test. Test cases for smoke testing should evolve as development progresses.
The purpose of BVT testing and smoke testing is to check that the program is complete and that the most basic testability requirements are achieved. It can reduce unnecessary workload of testers. The first step before the formal test execution used in the BVT test and the smoke test.
8. Recording and Tracking of Tests
1. Bug quality measurement: As a tester, you must describe the bug clearly.
2. A qualified bug report must include the following:
1. The version that found the problem: Helps developers analyze and summarize the degree of concentration of the problem
2. The environment in which the problem occurs: operating system environment, software configuration environment, etc.
3. Problem reproduction steps: try to reduce the operation steps to a few steps that must be executed to reproduce the error
4. Description of expected behavior: there are expectations before errors
5. Description of Wrongdoing
3. Bug report issues
1. Do not have typos 2. Do not enter several bugs into the same problem area 3. Attach necessary screenshots and files
4. Track the life cycle of a bug
New: Newly discovered bugs that are not assigned to developers for revision without a review decision
Open: Confirm that it is a bug and think it needs to be modified, and assign it to the appropriate developer
Fixed: After the developer makes a modification, it is marked as a modified state, which is to be verified by the tester's regression test
Rejected: think it is not a bug and refuse to modify
Delay: Temporarily can not (do not need) to modify, delay modification
Closed, regression verification passed, bug closed
Reopen: It has been verified that the bug still exists, reopen it.
Regression Testing
Repeat the same test many times
Risk-Based Regression Testing
The essence is to assess the risks inherent in different parts of the system and focus on testing those that are most risky. This place may leave some parts of the habit under-tested, or even completely untested, but he guarantees that the risk of doing so is minimal.
9. Test summary and report
1 . The defect classification report can be divided into
Defect type distribution report: The distribution of defect types, generally using a pie chart histogram.
Defect area distribution report: the occurrence of different functional modules, pie chart, bar chart
Defect status distribution report: describe the proportion of various states in the defect, such as the percentage of open eixed closed
2. Defect Trend Report
Mainly describe the defect situation over a period of time
3. Classic defect and bug mode
Summarize defects
Classic defects meet the conditions: repeated, frequent occurrence, can represent a certain type of errors, and these errors can be found by relatively fixed testing methods or means.
Refine Bug Mode
(1) Analyze bug reports to find out the types of bugs that often occur
(2) Analyze the root cause of the bug and find the deep-seated cause of the bug
(3) Analyze the method of finding bugs, and summarize how to find this type of bug every time