英文版软件测试程序,《软件测试英文1》.doc

《软件测试英文1》.doc

Testing During Rapid ChangeBy Randall W. Rice, CSTE, CSQAAs the old adage goes, "the one thing that remains constant is change." In software development, one of the weaknesses of the classic waterfall approach is that it assumes little or no change. The real world changes every day. Because of this, other development models such as Rapid Application Development RAD have been promoted to embrace change and use it to refine the software through planned iterations.

While RAD helps software developers get early versions up and running very quickly, it causes testers many headaches. With each and every change is the opportunity to create new defects. The only way to find new defects is to perform a regression test which completely repeats a previous test and compares the results to find differences.

Two questions come to mind: 1 "Is it possible to completely test during rapid change?", and 2 "Which strategies can be used to test rapidly changing software?"

Is It Possible to Completely Test During Rapid Change?

Actually, no. However, that's a trick question because in most cases it is not possible to completely test software even in stable environments1. The essence of this question might be to ask, "Is it possible to test effectively during rapid change?" Can we expect to make the best use of people and other resources to test software? Can we expect to find the expected number of defects?

By observing projects using RAD, I have observed that a process for testing is essential to finding defects with any degree of effectiveness. Since the norm is to have no repeatable processes for most of what we do in building software, many people test in a RAD environment the same way they do in other environments - try a few cases here and there and look for problems.

Which Strategies Can Be Used?

It takes time to learn what works in each unique environment, but here are some general strategies that can be used for testing during rapid change:

First of all, accept the fac