设计测试用例的四条原则(2)

　　之所有要引入单次和多次成本的思考，是希望能够通过区分测试中不同活动对测试成本的影响，从而进行帮助我们合理布局在不同阶段的投入和做出正确的决策，以保证在有限可负担测试成本的前提下，最大限度地有效开展测试工作。例如，当我们意识到了，测试用例的设计和自动化属于是一次性投入，而测试用例的执行则是反复多次的投入时，就应该积极思考如何能够提高需要反复投入的测试执行的效率，在一次投入和需要多次活动需要平衡时，优先考虑多次投入活动的效率，其实这里是有很多工作可以做。

　　例如：第一条原则-单个用例覆盖最小化原则 - 就是一个很好的例子，测试A功能的3个功能点A1，A2和A3，从表面上看用Test_A1_A2_A3这一个用例在设计和自动化实现时最简单的，但它在反复执行阶段会带来很多的问题：

　　首先，这样的用例的失败分析相对复杂，你需要确认到底是哪一个功能点造成了测试失败;

　　其次，自动化用例的调试更为复杂，如果是A3功能点的问题，你仍需要不断地走过A1和A2，然后才能到达A3，这增加了调试时间和复杂度;

　　第三，步骤多的手工测试用例增加了手工执行的不确定性，步骤多的自动化用例增加了其自动执行的失败可能性，特别是那些基于UI自动化技术的用例;

　　第四，(Last but not least)将不相关功能点耦合到一起，降低了尽早发现产品回归缺陷的可能性，这是测试工作的大忌。例如：如果Test_A1_A2_A3是一个自动测试用例，并按照A1->A2->A3的顺序来执行的，当A1存在Bug时，整个测试用例就失败了，而A2和A3并未被测试执行到。如果此时A1的Bug由于某些原因需要很长时间才能修复，则Test_A1_A2_A3始终被认为是因为A1的Bug而失败的，而A2和A3则始终是没有被覆盖到，这里存在潜在的危险和漏洞。当你在产品就要发布前终于修复了A1的Bug，并理所当然地认为Test_A1_A2_A3应该通过时，A2和A3的问题就会在这时爆发出来，你不得不继续加班修复A2和A3的问题。不是危言耸听，当A2/A3的代码与A1的Bug修复相关时，当你有很多如此设计的测试用例时，问题可能会更糟… …，真的!:(

　　综上所述，Test_A1_A2_A3这样的设计，减少地仅是一次性设计和自动化的投入，增加地却是需要多次投入的测试执行的负担和风险，所以需要决策时(事实上这种决策是经常发生的，尤其是在设计测试用例时)选择Test_A1_A2_A3还是Test_A1、Test_A2和Test_A3，请务必要考虑投入的代价。

　　4. 使测试结果分析和调试最简单化原则。

　　这条原则是实际上是上一条- 单次投入成本和多次投入成本原则 - 针对自动化测试用例的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调试更为简单，包括：用例日志、调试辅助信息输出等。因为测试用例的执行属于多次投入，测试人员要经常地去分析测试结果、调试测试用例，在这部分活动上的投入是相当可观的。有时候，测试框架提功能的一些辅助API等就可以帮助很好实现这个原则。例如：Coded UI Test就提供了类似的API，详见 - VS 2010 测试功能学习(18) – Coded UI Test三个必知的函数，来辅助基于Coded UI框架实现的自动化测试用例有更好的调试体验。

　　测试理论为测试工作指明了大的前进方向，在实际工程中还需要我们不断地“活化”这些理论，使理论和实践更好的契合在一起。在我看来，软件工程项目不论成败和好坏，对我们每个参与者都是无比宝贵的。作为有心人，从中我们体会到很多书本上不曾提到过的东西，只要不断地去观察、体会和总结，你会有更多自己的认识、理解和发现。有很多人写书称赞，代码之美、测试之美，其实工程项目也是很美，只是看你能不能更客观地去看待它。

原文转自：http://www.uml.org.cn/Test/201107202.asp