Various stages of software testing

PDCA cycle (Deming cycle) plan do check action1, test requirements analysis and determination 2, test Plan 3, test Design 4, test execution 5, test records and defect tracking 6, regression test 7, Test summary and report 1, test requirements analysis and determination p114 1.2, Requirements of the specification of the inspection points p116 (on how to do a good job in software requirements analysis, as well as the measurement of software requirements, please refer to the "Exploration needs-quality before design" book, "Exploring Requirements:quality before" Example 1. Whether all required items (completeness) are covered by the userUser's original requirement material (user requirement document, user-supplied relevant material, research record, communication record with user) 2, whether the word is clear, whether there is ambiguity in semantics (explicit)Identify such keywords as may, may, probably, approximate, and so on, as to further clarify the need, will not lead to late development and understanding of the conflict 3, whether to clearly describe what the software system needs to do and what not to do (necessity)Coverage is not much, less is the demand coverage is not sufficient, more may be unnecessary, imposed on the customer's function, both waste manpower, but also increase the risk of software implementation 4. Whether the target environment for software use is described, including the hardware and soft environment (integrity)Should be based on the actual user adaptation of the hardware and software environment and network environment to test, 5, whether the requirements of the item is a reasonable number (modifiable)For the maintenance and management of requirements 6, whether the requirements are consistent, do not conflict with each other (consistency)For example, the description of the software used in the environment does not mention the need to use the Linux platform, and in the description of the development of the installation package requires support for Linux, will create confusion. 7, whether the system is clearly described in each input, output format, and the input and output of the corresponding relationship (testability)Check that each type of input has a fixed output, if not, it lacks the basis for judging and verifying the correctness of the system. 8. Do you clearly describe the performance requirements (completeness) of the software system?Sometimes the need for security is included, and if it does, you need to consider 9, the priority of the demand is reasonable allocation (priority)Key effects, important effects, user care features, the user is eager to function first 10, whether to describe a variety of constraints (testability)Complete and reasonable constraints, consistent with the user's business scenario document: Enter  2 greater than 0, test plan p119         -- A annihilation for all software bugs to determine test scope development Test strategy test resource scheduling-------test, time, effort, personnel-------due to the limitations of each individual's thinking, each test is finally scheduled for no less than 2 individual tests, For cross-test scheduling-------It is best to reserve a buffer time to respond to planned changes, and to give testers time to refine and supplement test case risks and countermeasures-------consider establishing a fallback mechanism  3, test design, and test cases P122´ Methods: Equivalence class partitioning method boundary value analysis method equivalence class + Boundary value Basic Path Analysis method causality diagram method Scene design method error guessing orthogonal table and TCG use    equivalence class partitioning method: Generally can be divided into effective equivalence class and invalid equivalence class   such as: In a system, Fill in a how many years old adult mathematics test how many points (assuming that the adult age is x,0<x<=18, the mathematics result is y:0<=y<=100 so the age according to the equivalence class division can divide into x<0,0<x<=18,x>18, The valid equivalence class is 0<x<=18, the invalid equivalence class is the x<0,x>18  mathematics result according to the equivalence class division can divide into y<0,0<=y<=100,y>100, the effective equivalence class is 0<=y<= 100, the invalid equivalence class is the y<0,y>100  boundary value analysis method: (generally used in conjunction with equivalence class partitioning) the general boundary value analysis is because the process of developing a loop body may be mistaken for <,<=.　　  such as the following code for (int i = 0;i <100; i + +) {int j = i+1; System.out.println ("Loop +j+")//loop to do something} The program here is 100 cycles, so it will do 100 times, if the programmer accidentally writes I <100 i <= 100, it will overflow, Boundary value checking is a good test method at this time.   For example: In a system, fill in a how many years old adult mathematics test how many points (assuming that the adult age is x,0<x<=18, the mathematics result is y:0<=y<=100 according to the above equivalence class division method we know, the age effective equivalence class is 0 <x<=18, so the boundary value is0,1,18,19 is a mathematical achievement, the effective equivalence class is 0<=y<=100, so the boundary value is the -1,0,100,101  basic Path analysis method: (generally according to the flowchart) such as approval contract: Edit contract-submit-Audit pass-build a set of books Contract-submit-Audit not pass-Modify-submit-Audit pass-set    cause and Effect diagram method (generally used with the decision table) to be continued ...  ´ Combination Overlay (PICT use)

Http://www.pairwise.org/http://msdn.Microsoft.com/en-us/testing/bb980925.aspx

Model file Format:<paramname>: <value1>,<value2>, .....

How to use: p132

Classification number and the use of Testona http://www.berner-matter.com/en/products/testona/index.html

Testona:http://www.testona.net/cms/upload/3_raw/testonalightsetup_4.1.1.exe

Various stages of software testing