Software testing Using Test documents

It's not enough just to do your best.  You have to know what to do and then try your best. --Edward Deming

Without a record, you can't tell what time really happened. --Virginia Wood

In this part, we will link the knowledge of software testing and explain how all the work related to software testing is planned, how it is organized, and how it communicates with the project team.

　　Software test plans are the primary means by which software testers communicate intentions with product development teams. The IEEE Standards for Software test documentation express the purpose of the software test plan in the following ways:

　　Define the scope, methodology, resources, and progress of the test activity, identify the project under test, the features to be tested, the test tasks to be performed, the owner of each task, and the risks associated with the plan.

　　Here we review the definition of a software defect (bug):

1) software to achieve product specifications required function

2) The software has appeared the product manual should not appear the mistake

3) The software realizes the function not mentioned in the product specification

4) The goal that the software should achieve, though not expressly mentioned in the product specification

Test Case Planning Goals:

1) organization. the right plan organizes use cases for effective review and use by all testers and other project team members.

2) repeatability. we already know that it is necessary to perform the same tests several times during the project to find new software defects and to ensure that old software defects are repaired.

3) tracking.

4) test confirmed . In a handful of risky industries, the software testing team must demonstrate that it does perform the tests that are planned for execution. Publishing software that ignores certain test cases is actually illegal and dangerous. The correct test case planning and tracking provides a means of proving the content of the test.

Test cases should contain the main content: Identifiers , test items, input instructions, output descriptions, environmental requirements, special process requirements, and the dependency between the force.

　　

* Why all software defects are not necessarily fixed

A. The Test team does not have enough time , the testers are too few to meet the requirements of all the functions tested

B. not real software defects, in many cases, understanding errors, test errors, or changes to the specification will be treated as a function of the possible software defects.

C. the risk of repair is too large, in many cases the software itself is very fragile, difficult to clear up the clue, it is possible to repair the flaw and come out more problems. Under the pressure of urgent product release schedule, it will take a lot of risk to revise the software.

D. not worth repairing, in the actual software testing, some of the less common, infrequently appearing software defects can be spared.

E. invalid software bug Repair report, testers did not build strong enough test cases, thought that the software defects have been repaired, but there is no

* How to restore the identified software defects as far as possible

A. reporting software defects as soon as possible

　　B. effective description of software defects: Short, single

C. in reporting software defects is not to be evaluated

　　D. tracking software defect reports to the end

* What technologies can be used to isolate and reproduce software defects

Don't take any assumptions for granted. Make a note of everything you do-every step, every pause, every piece of work.

Find time-dependent and race-condition issues. Software defects only appear at certain moments? Maybe it depends on the speed of the input data.

Boundary conditions software defects, memory leaks, and data overflows white-box problems may slowly reveal themselves.

State defects are only exposed in specific software states.

Consider the interaction of resource dependencies and memory, network, and hardware sharing,

Do not neglect the hardware.

* Software defects of life from appearing to disappearing like what

Very much like the life cycle of an insect, the life cycle of a software defect is like this: found a flaw---open------

　　

Software testing Using Test documents