qileilove

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

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

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

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

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

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

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

　　从某个角度讲，经常Failed测试用例并不值得你太担心，而那些从来都是Passed的用例，应该是值得你抽时间检查的对象。

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

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

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

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

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

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

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

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

　　总之，我们在编写和实现测试用例的时候，除了实现基本功能之外，还要多留意的用例（特别是自动化用例）Passed和Failed有效性，经常容易被忽略地是Failed有效性，所以要尽可的寻找途径来验证其有效性。