软件测y试：测试用例应注意的四点!.docVIP

软件测试：测试用例应注意的四点!.txt如果真诚是一种伤害，请选择谎言；如果谎言是一种伤害，请选择沉默；如果沉默是一种伤害，请选择离开。由安博测试空间技术中心/提供 1. 单个用例覆盖最小化原则。 　　这条原则是所有这四条原则中的”老大“，也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。下面举个例子来介绍，假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，可以有下面两种方法来设计测试用例： 　　?方法1 ：用一个测试用例覆盖三个子功能 -Test_A1_A2_A3， 　　?方法2 ：用三个单独的用例分别来覆盖三个子功能 - Test_A1，Test_A2，Test_A3 　　方法1适用于规模较小的工程，但凡是稍微有点儿规模和质量要求的项目，方法2则是更好的选择，因为它具有如下的优点： 　　?测试用例的覆盖边界定义更清晰 　　?测试结果对产品问题的指向性更强 　　?测试用例间的耦合度最低，彼此之间的干扰也就越低 　　上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容，不要“搂草打兔子”捎带着把啥啥啥啥都带进来，这样只会增加测试执行阶段的负担和风险。David Astels在他的著作《Test Driven Development：A Practical Guide》曾这样描述，最好一个测试用例只有一个Assert语句。此外，覆盖功能点简单明确的测试用例，也便于组合生成新的测试，在Visual Studio中就引入了Ordered Test的概念。 　　2. 单次投入成本和多次投入成本原则。 　　与其说这是一条评判测试用例的原则，不如说它是一条思考问题的思维角度和原则。成本永远是任何项目进行决策时所要考虑的首要因素，项目中的测试也是如此，对成本的考虑也应该客观和全面的体现在测试的设计、执行和维护的整个阶段中。当你在测试中遇到一些左右为难的问题需要决策时，尝试着从成本角度去分析一下，也许会对你的决策有所帮助。 　　测试中的成本按其时间跨度可以分为：单次投入成本和多次投入成本。例如：编写测试用例可以看作是单次投入成本，因为编写测试用例一般是在测试的计划阶段进行(Scrum每个Sprint的开始阶段)的，虽然后期会有小的改动，但绝大多数是在一开始的设计阶段就基本上成型了;自动化测试用例也是如此，它也属于是一次性投入;测试用例(包括：手工和自动化测试用例)的执行则是多次投入成本，因为每出一个新版本Build时都要执行所有的测试用例(或者进行BVT测试仅执行高优先级的测试用例)、分析测试结果、调试失败测试用例、确定测试用例的失败原因(产品缺陷、测试用例缺陷、测试框架缺陷还是随机问题导致了测试用例的失败)，以验证该版本整体质量是否达到了指定的标准。 　　之所有要引入单次和多次成本的思考，是希望能够通过区分测试中不同活动对测试成本的影响，从而进行帮助我们合理布局在不同阶段的投入和做出正确的决策，以保证在有限可负担测试成本的前提下，最大限度地有效开展测试工作。例如，当我们意识到了，测试用例的设计和自动化属于是一次性投入，而测试用例的执行则是反复多次的投入时，就应该积极思考如何能够提高需要反复投入的测试执行的效率，在一次投入和需要多次活动需要平衡时，优先考虑多次投入活动的效率，其实这里是有很多工作可以做。 　　例如：第一条原则-单个用例覆盖最小化原则 - 就是一个很好的例子，测试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_A