我对这项测试也非常感兴趣，并和其进行了一些交流，想深入了解一些更详细的情况，比如测试数据规模、执行的时间长短、测试数据分布等，随着交流的深入同事突然意识到似乎测试代码似乎有些不大合乎常理的表现，进一步调试发现代码中一段生成数据地方其实并没有正确执行，虽然测试仍在执行但输入的数据没有，测试只是在空转，并没有执行被测程序的逻辑，所以整个曲线显示是一条水平线。
这其实是个小问题，但其背后隐藏着这样一个问题，你的测试用例是有效的吗？但通过分析这样一个实际工作中的问题对我们的测试工作带来一些有意的思考：
- 自动化测试需要有详细的日志输出，以便于诊断测试的确切执行情况。自动化测试用例的执行过程对我们来说是一个黑盒过程，我们一般只是看到它的结果是Passed或者Failed。如果这个黑盒过程本身就是错误的，如本文一开始所给出的例子，结果是Passed就没有任何意义了。而且这样的Passed只会是给问题雪上加霜，减少了发现问题的可能性。
- 测试人员特别是自动化测试工程师，应该对那些看似完美的东东多些疑问，多些探究精神，在经过客观途径验证之前时刻保持谨慎的乐观。
- 测试用例要么Passed要么 Failed，看似简单的结果，但其中还是有些值得深究的内容的。任何一个测试用例实际上是肩负着双重责任的： 其一，保证在被测功能正确的情况下，测试用例应该是Passed；其二，则是在被测功能异常的情况下，测试返回Failed。一般的情况下，我们对用例只是验证了第一种情况后就算完成，并提交的用例管理库或者代码库中。而很少真正有人去验证一下被测试功能异常的情况下，测试用例确实Failed，其结果路径是这样的：· Passed –> Passed –> Passed –> …–> Passed? or Failed?之所以会有这样的情况，首先是因为从意识上大多数人都认为测试中功能行为的判断以足够强壮；其次，是因为很多用例的实现和执行多是在被测功能实现之后才开始，这时的被测功能刚实现出来，并经过开发人员反复调试是正确的，此时很难再有简单的途径模拟出错误的功能来验证测试用例Failed。解决的办法就是，尽可能寻找途径去模拟被测功能的异常，再就是合理选择实现测试用例的时间。很多情况我们的用例是为了覆盖已有的Bug而添加的，以避免回归缺陷。这样的测试用例最好是在Bug修复之前就实现好，那么它一定必须是Failed，这个机会就可以验证出Failed情况。从这角度上看，其实测试驱动开发（Test Driven Development， TDD）的模型更为合理和自然，TDD先有测试用例，再实现功能代码，该测试用例必然是经过一系列的Failed之后最终达到Passed，其结果路径如下。TDD的原理保证了测试用例一定是由Failed开始，不用费心去模拟功能异常以得到Failed结果 : · Failed –> Failed –> Failed –> …–> Passed
- 产品的质量有测试来监控，那么谁来监控测试本身的质量呢？人、过程和工具。人－测试人员需要更有责任心，保持对任何问题的谨慎和探究精神；过程－测试计划和用例的交叉评审，测试代码的Review；工具–利用代码覆盖来探究测试用例有效性。
最新评论