About Testing——Chapter 2. 怎样进行测试

*本章所有内容均收集自网络，并非本人撰写，所以很多东西理解的比我更深刻  

1.        测试的规律

1） 木桶原理。

在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

2） Bug的80-20原则。

一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

 

2.      Regression Bug和Late Discovery Bug

Regression Bug，由于开发新特性或Fix Bug导致以前正常工作的特性罢工了。这种情况，通常出现在产品的开发中。

为了便于分析，Regression Bug又分为Release Regression和Build Regression。

Release Regression指的是和上一个产品版本相比，出现的Bug。

Build Regression的解释就更复杂些。通常开发软件的一个版本的过程中，会有很多Build，通常测试会根据需要每天或每隔几天取一个Build进行测试。相对于前某个Build的Regression Bug就是Build Regression。

产生Regression Bug的主要原因是：

单元测试没有做充分。

隔山打牛的Bug，单元测试很难做到。

测试环境问题

另外，通常Regression Bug也有较高的误报率，或者争议比例较大。

控制Regression Bug的方法通常从强调单元测试开始，然后是控制Bug的Reopen率，增加Code Review的频率，引入自动测试。但是，Regression Bug在全部Bug中的比例，在通过上述方法控制到20%到30%后，开始出现难以下降的趋势。

Late Discovery Bug则是QA之痛。用质量的术语来说，就是漏检。每个Release都会发现无数上个版本测试没有发现的Bug。通常这也会达到20%到30%。

产生Late Discovery Bug的主要原因是：

测试覆盖率。通过黑盒测试，要想做到100%分支的Cover率，是不可能的。这样，总会有漏掉的Bug。

个人的测试盲区。每个人都有脑筋死角或盲区，先入为主的认识会让人们不能发现很明显的问题。

解决的方法有：

增加Ad Hoc测试，就是不按照事先设计好的Case执行的测试。

交叉测试，减少测试误区。

 

3.      软件测试的几条建议

1.         应当把“尽早和不断地测试”作为开发者的座右铭。

2.        程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

3.        设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

4.        一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

5.        对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

6.        制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

7.        回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

8.        妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。