上一篇关于测试用例设计的博文《设计测试用例的四条原则》中，介绍了设计测试用例的四条原则。本篇结合最近工作遇到的一个小插曲，介绍一下测试用例本身Passed和Failed的有效性问题。

我所在的团队上个 Sprint有一项很重要的工作，就是进行Stress测试，需要编写自动化用例测试模拟程序长时间的执行，并观察其内存消耗是否呈现合理的增长趋势，以及有没有内存的泄漏等问题。同事很快编写好了测试用例，并执行了个把个小时，得出了初步的数据。数据显示程序的表现相当完美，不仅内存没有陡峭的突变，甚至连大斜率的线性增长也木有，基本呈现为一条略有波动的水平直线。非常让人振奋，这样的表现打消团队之前的担心，完成这项工作所需的时间也将大大小于之前的预估。

我对这项测试也非常感兴趣，并和同事进行了一些交流，想深入了解一些更详细的情况，比如测试数据规模、执行的时间长短、测试数据分布等，随着交流的深入同事突然意识到似乎测试代码似乎有些不大合乎常理的表现，进一步调试发现代码中一段生成数据的代码并没有正确生成数据，虽然测试仍在执行但输入的数据没有，测试只是在空转，并没有真正执行被测程序的逻辑，所以整个曲线才呈现为一条水平线。

这件事本身是个小问题，但其背后隐藏着一个值得我们深究的问题：当你的测试用例Passed的时候，被测产品果真是正确的吗？仔细想想这个问题，可以得到一些对我们的测试工作有意的思考：

1. 自动化测试需要有详细的日志输出，以便于诊断测试的确切执行情况。

自动化测试用例的执行过程对我们来说是一个黑盒过程，我们一般只是看到它的结果是Passed或者Failed。如果这个黑盒过程本身就是错误的，如本文一开始所给出的例子，结果是Passed就没有任何意义了。而且这样的Passed只会是给问题雪上加霜，减少了发现问题的可能性。

2.测试人员特别是自动化测试工程师，应该对那些看似完美的东东多些疑问，多些探究精神，在经过客观途径验证之前时刻保持谨慎的乐观。

从某个角度讲，经常Failed测试用例并不值得你太担心，而那些从来都是Passed的用例，应该是值得你抽时间检查的对象。有点类似于强迫症，没当我编写的测试用例一次就Passed，我总是对此表示怀疑 -“我真有这么厉害吗？“，总是要看到它Failed过才肯安心。

3. 测试用例要么Passed要么 Failed，看似简单的结果，但其中还是有些值得深究的内容的。

任何一个测试用例实际上是肩负着双重责任：其一，保证在被测功能正确的情况下，测试用例应该是Passed；其二，则是在被测功能异常的情况下，测试返回Failed。一般的情况下，我们只是验证了第一种情况后就算完成，并将用例提交到用例管理库或者代码库中。很少真正有人去验证一下在被测试功能异常的情况下，测试用例确实Failed。这样的用例验证可以总结为如下的模式：

Passed –> Passed –> Passed –> …-> Passed? or Failed?

之所以会有这样的情况，首先，是因为从意识上讲，大多数人都认为测试中对被测功能行为的判断以足够强壮，但其实这种没有客观佐证的判断并不可靠；其次，很多用例的实现和执行多是在被测功能实现之后才开始，这时的被测功能刚实现出来，并经过开发人员反复调试修改，绝大多数情况下都是正确的，由于产品代码已经提交，此时很难再有简单的途径模拟出错误的功能行为，以验证测试用例Failed的情况。

解决的办法有两种：一、尽可能寻找途径去模拟被测功能的异常；二、再就是合理选择实现测试用例的时间。很多情况我们的用例是为了覆盖已有的Bug而添加的，以避免回归缺陷。这样的测试用例最好是在Bug修复之前就实现，那么它一定是Failed，这个机会就可以验证出Failed情况。

扩展一下这个话题，从用例Failed/Passed路径这角度上看，测试驱动开发（Test Driven Development，TDD）的模型更为合理和自然。因为，TDD强调先有测试用例，再实现产品功能代码，先实现的测试用例必然是经过一系列的Failed之后，最终达到Passed，其模型可以总结如下：

Failed –> Failed –> Failed –> …–> Passed

TDD的原理保证了测试用例一定是由Failed开始，到Passed结束，所以不用费心去模拟功能异常以得到Failed结果，同时保证了用例对Failed和Passed都一定进行了验证。

4.产品的质量有测试来监控，那么谁来监控测试本身的质量呢？人、过程和工具。

人－测试人员需要更有责任心，保持对任何问题的谨慎乐观和探究精神；过程－测试计划和用例的交叉评审，测试代码也要进行review，同时选择合理的时机实现测试；工具–利用代码覆盖来探究测试用例有效性。