战胜软件测试十大挑战：面向人的策略

by William E. Perry and Randall W. Rice

Dorset House Publishing, New York, NY, 1997, 216 pp.

 

软件工程在范围和规模上都有了很大的增长，因此，实现单独的某个项目可以使用的方法很多。各种可能路径的组合很容易就达到成千上万甚至更多，这就导致了对它们的完全测试变得毫无可能。还有软件模块之间的动态交互，以及经过修改后的模块需要进行回归测试的问题。再有就是，软件开发人员经常不愿执行测试，而且，所有的研究都得出了可靠的结论，就是：开发人员不应该测试自己的成果。由此，需要发展独立的测试小组

创建，激励，管理这些小组是个艰巨的任务。测试小组是介于开发者和客户之间的，在寻找错误的时候他们必须是残忍的，但又是不彻底的，因为产品不可能完美无缺。经理们应该感到满意，因为测试所花费的工作量是并不是白搭的的并且值得产品为之推迟。

十大挑战描述如下：

10）训练有素的测试

随便将某个人置于测试的位子，让他测试，这是种极大的浪费。测试是一种要求策略，能力和自豪感的职业。这些品质需要慢慢灌输，而且需要培训才能具备。

9）建立和开发人员的关系

测试人员和开发人员的关系素来就是紧张的，虽然大家的目标是一样的，但是却很容易陷入相互厌恶之中。

8）不用工具测试

如果可能，应该尽量避免不用工具测试，因为手工测试易于出错。大多数测试工具的花费可以从甚至仅仅一个严重BUG的发现中得到抵消。

7）向经理解释测试

测试不仅仅是软件周期的最后一步，还常被认为是为仆人保留的。从为测试所做的预算就常常可见一斑。由于在开发者手中被发现的错误只会花费在用户手中发现的错误的一小部分，所以这种看法很短见。

6）与顾客和用户交流

测试不仅仅是找出代码中的bug，测试的一个重要的部分就是：确定已经创作出来的是不是应该创作的。这就意味着必须具备双向的交流通道。

5）为测试留下时间

这也许是所有挑战中最为困难的，在多数情况下，开始测试时开发过程已经进行了一年或者更多。毫无疑问，软件产品已经刊登过广告了，如果它具有吸引力的话，就会有用户盼着它完成，等着购买，在这种情况下，要为测试留下足够的时间变得更加困难。

4）测试“越墙”的产品

当开发人员完成开发以后，他们经常将产品“越墙”扔到测试者手中，测试人员对其进行测试，如果失败了，测试人员再将其“越墙”扔回到开发者手中（似乎开发人员和测试人员之间有一道不可逾越的墙）。如果他们改用面对面，职业的谈话来进行简单交接的话，情况会变得更好。

3）目标游移不定

这似乎是第二大困难的挑战，修改一个模块将影响到其他模块，试图将持续测试和修改bug交织进行的话，就是要将两个复杂的任务合并在一起。

2）在损失对损失的情况下抉择

穷举测试是不可能实现的，而且还有如此多的外力试图让软件测试者停止测试，放手的时间必将到来，所以确定测试到什么质量水平（可以结束测试）是一门真正的艺术。

1）必须说不

有的时候，测试人员不得不说，软件还没有达到发布的水平，这就需要有勇气，信念，奉献和意愿来坚持你的立场。

 

英文原文：

SURVIVING THE TOP TEN CHALLENGES OF SOFTWARE TESTING: A PEOPLE-ORIENTED APPROACH

by William E. Perry and Randall W. Rice

Dorset House Publishing, New York, NY, 1997, 216 pp.

As software projects have grown in size and scope, the number of ways a single program can be used is huge. The combinatorial explosion of possible paths easily reaches the billions or higher, making it impossible to completely test all of them. Throw in the dynamic interactions between software modules, and there is the problem of what needs to be re-tested after modification. Furthermore, developers are often loath to perform testing, and every study leads to the solid conclusion that no one should test their own creation anyway. Hence, the development of independent testing teams.

Creating, motivating, and managing those teams is a formidable task. The testing team is in the middle between the rock of the developers and the hard place of demanding customers. They must be ruthless in their search for errors, yet not so exhaustive that the product is never completed. Managers must be satisfied that the testing effort is cost-effective and worth the delay.

The top ten list of challenges is described as follows: 10) Getting Trained in Testing

Placing someone down at a terminal and telling them to test a package is an enormous waste. Testing is a profession with strategies, competencies and a sense of pride. These qualities must be instilled, and that requires quality training.

9) Building Relationships With Developers

The relationship between testers and developers is by nature a strained one. It is easy to slip into the state of mutual dislike even though their goals are the same.

8) Testing Without Tools

While this can be done, it is to be avoided if possible. Manual testing is prone to error. The cost of most tools can be recovered by the discovery of even one serious bug.

7) Explaining Testing to Managers

Testing is not only the last step of the software cycle, it is often thought of as reserved for menials. This is commonly reflected in the amount of money budgeted for testing. Since a bug caught in-house costs a fraction of what one can cost in the hands of a user, this is very short-sighted.

6) Communicating With Customers - And Users

Testing is more than just finding bugs in the code. A significant part of testing is determining if what has been produced is what should have been produced. That means that there must be communication channels open for twoway traffic.

5) Making Tine For Testing

This probably is the most difficult challenge of all. In most cases, by the time the product goes to testing, it has been in the development process for a year or more. It has no doubt been advertised and, if it has any appeal, there are customers who are looking forward to the ship date and are eager to buy. Given these circumstances, wedging in adequate time for testing is very difficult.

4) Testing What's Thrown Over The Wall

When the developers are done, they often throw the package "over the wall" to the testers, who test it and if it fails, throw it back. It is much better if they perform simple hand-overs with face-to-face, professional conversations.

3) Hitting a Moving Target

This is most likely the second most difficult challenge. Modifying one module can affect the behavior of others. Trying to interweave the continued testing and fixing of errors is the amalgamation of two complex tasks.

2) Fighting A Lose-Lose Situation

Since exhaustive testing is not possible and there are so many forces trying to pry the software out of the hands of the tester, there must come a time to let it go. Determining how much quality is enough is a real art.

1) Have To Say No

There are times when the testers just have to say that the software is not yet ready for shipping. This requires courage, conviction, dedication and a willingness to stand your ground.

The authors of this book deal with all of these challenges in great detail, both from the perspective of the tester and of the manager. This is a book that should be read by all computer science students. There are many jobs in the software industry, but most companies start many of their new employees as testers and are disappointed with their background and training in this area. One employer even approached the local community college about the possibility of starting a program to train testers. Reading this book will not make you a quality software tester, but it is the first step toward becoming one.

Reviewed by Charles Ashbacher Charles Ashbacher Technologies

Copyright Mathematics and Computer Education Winter 2000
Provided by ProQuest Information and Learning Company. All rights Reserved