《完美软件》读书笔记9：良好测试的要素

“没有什么事物是好的或者坏的，而是思维让事物有了好坏之分”--莎士比亚

如何才能知道，测试是否进行得很好？你对测试结果又能够有多少信任？

1、永远无法确切地知道

永远无法确切地知道，而且永远无法通过孤立地看某个测试来知道一个测试是否是良好的--但是确实有很多方法可以得知某个测试是否是糟糕的。

2、只能根据事实来评估良好性

如果知道一个系统中有多少BUG，就至少可以开始评估一组测试的良好性，或者说非糟糕性。

3、可能希望故意插入一些BUG

通过植入BUG（或者说‘插错’）来获得对软件中可能余留了多少问题的定量估算。

4、对良好性的估算总是统计性的

大多数时候，一个不能工作的烟雾报警器与一个可以工作的烟雾报警器是没有区别的。遗憾的是，最常见的提醒人们替换电池的是火灾。

类似地，不能认为测试员找到的BUG少就认为TA工作表现差；劣质软件、单元测试未排除简单BUG（噪音），都会让测试员看上去表现优秀。

这种度量体系下，糟糕的开发人员可能是测试员最好的朋友:(

5、可以对‘不差’进行估算

经理还是可以通过以下类型的问题对‘不差性’进行很多的评估：

* 测试是否名义上能够提供需要的住处？

* 是否进行了文档记录？

* 是否能理解它？如果不行，你怎么可能知道它到底是好还是坏？

* 它是否至少覆盖了那些最重要的部分？

* 是否确实完成了（测试执行）？

* 是否可以看出测试和演示之间的差别？

* 对趋势和状态的报告是否过于简单化和定期化了？

* 不同类型的测试活动之间是否有不一致的地方？比如性能测试发现了功能性缺陷

* 经理们是明察秋毫的吗？

小结：永远无法确切地知道测试是否完成得很好；但是如果测试完成得不好，有很多方法可以知道或估算出来。

 

常见错误：

1、未考虑到底在寻找哪些信息

2、根据发现的BUG数量来衡量测试人员的好坏

3、认为可以确定一个测试有多好

4、在不了解产品内部结构的情况下进行

5、测试时过于了解产品的内部结构

6、给出对BUG的统计估算时将它们当作固定的、确定的数字

7、未对测试的‘不良性’进行度量

8、不能保证开发过程良好地完成：对低劣的代码测试得再好又有什么用呢？

9、未考虑由于发现大量BUG导致的测试效率的损失

======== by 鬼谷子@魔教=========================