上周拿到了一批新产品，并继承了现有的测试程序。得到的信息是：测产品的时候要多测几次，因为测试结果不太稳定。

测之前，我先给测试程序加了个功能，把测试结果写入数据库（也是我自己建的）。“不太稳定”这话概念太模糊，得有些实实在在的数据来澄清一下。后面的统计基本上都是来自数据库。

敢情这个“不太稳定”的意思就是对于一个好（good）产品来说，首次通过率（FPY）是不到10%，二次通过率（测第二次）约50%，而三次的通过率才达到90%！

我对这个测试的第二个改进就是在测试源码里加入一些找虫（debug）的输出。说到这个我觉着原先设计测试的人想法也很怪，为什么不多输出点儿东西呢？难道是为了担心屏幕上的信息太多反而让操作者无所适从？可操作者其实就是普通工人，对他们来说通过或者失败的结果才是最重要的，你在屏幕多输出几行他们根本不在乎，反正也懒得去看而且也看不懂。再说了，输出30行和输出300行大概还有些区别，可输出300行或500行对工人真没啥区别。

靠着增加的输出，我对测试失败的原因有了一些猜测，并付诸实验，终于确定了对最常见问题的解决方法。这样在首次失败后，进行一些手工的操作，二次通过率就能达到90%了！

现在开始第三个改进。其实前两个（数据库和debug输出）都对测试流程本身并无影响。毕竟是前人的东西，没搞清状况之前还是尽量不要给人家乱改，否则一是心里没谱，二来改坏了说不清啊。

第三个改进就是模拟那个手工操作的流程并加入程序。加完调试成功后果然首次通过率达到了90%，缺点是大多数新产品的测试时间几乎翻倍了。其实这个也是正常，因为本就能通过的那不到10%的产品测试时间其实没变，那些三次都过不了的时间也没变（当然还会失败），而测试时间几乎加倍的那些产品都是首次通过，而它们本应该需要两三次才能过的。

我觉着一个好的测试程序的基本条件之一就是得稳定，能得到操作者的信任。什么是信任，那就是测试失败的时候操作者的第一反应不是“测试程序有问题”，而是“被测试的产品不合格”。这个说来简单，但我在工作中听到“测一次不过？那再测几次吧”这样的话实在不少。这样的测试程序。。。算了，懒得说了。

手边的这个程序虽然还做不到令人信服的程度（对好产品的首次通过率应该就是100%），但毕竟有了些进步，任重道远啊～～～

注明一下：所有的测试失败其实都是由于产品自身的软件不稳定引起的，其实是软件的设计问题。我当然第一时间就给软件组提交了虫子报告（bug report），但不可能等到他们把软件升级，生产还是要继续的，所以只能在测试中尽可能的绕过或者解决这些虫子。