软件测试用例的认识误区

　　软件测试用例的认识误区   软件测试　

   　软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合。正确认识和设计软件测试用例可以提高软件测试的有效性，便于测试质量的度量，增强测试过程的可管理性。

　　在实际软件项目测试过程中，由于对软件测试用例的作用和设计方法的理解不同，测试人员(特别是刚从事软件测试的新人)对软件测试用例存在不少错误的认识，给实际软件测试带来了负面影响，本文对这些认识误区进行列举和剖析。

　　误区之一：测试输入数据设计方法等同于测试用例设计方法

　　现在一些测试书籍和文章中讲到软件测试用例的设计方法，经常有这样的表述：测试用例的设计方法包括：等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是很片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。

　　这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。如果测试用例设计人员把这种认识拿来要求自己，则害了自己;拿来教人，则害了别人;拿来指导测试，则害了测试团队。听起来似乎是“小题大做”，但是绝不是“危言耸听”。

　　无疑，对于软件功能测试和性能测试，确定测试的输入数据很重要，它决定了测试的有效性和测试的效率。但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个子集，除了确定测试输入数据之外，测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。

　　在设计测试用例时，需要综合考虑被测软件的功能、特性、组成元素、开发阶段(里程碑)、测试用例组织方法(是否采用测试用例的数据库管理)等内容。具体到设计每个测试用例而言，可以根据被测模块的最小目标，确定测试用例的测试目标;根据用户使用环境确定测试环境;根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤;根据软件需求文档和设计规格说明确定期望的测试用例执行结果。

　　误区之二：强调测试用例设计得越详细越好

　　在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面：尽可能设计足够多的设计用例，测试用例的数量阅读越好;测试用例尽可能包括测试执行的详细步骤，达到“任何一个人都可以根据测试用例执行测试”，追求测试用例越详细越好。

　　这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源，可能等到测试用例设计、评审完成后，留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段，分配给测试的时间和人力资源是有限的，而软件项目的成功要坚持“质量、时间、成本”的最佳平衡，没有足够多的测试执行时间，就无法发现更多的软件缺陷，测试质量更无从谈起了。

　　编写测试用例的根本目的是有效地找出软件可能存在的缺陷，为了达到这个目的，需要分析被测试软件的特征，运用有效的测试用例设计方法，尽量使用较少的测试用例，同时满足合理的测试需求覆盖，从而达到“少花时间多办事”的效果。

　　测试用例中的测试步骤需要详细到什么程度，主要取决于测试用例的“最终用户”(即执行这些测试用例的人员)，以及测试用例执行人员的技能和产品熟悉程度。如果编写测试用例的人员也是测试用例执行人员，或者测试用例的执行人员深刻了解被测软件，测试用例就没有必要太详细。而如果是测试新人执行测试用例，或者软件测试外包给独立的第三方公司，那么测试用例的执行步骤最好足够详细。

　　误区之三：追求测试用例设计“一步到位”

原文转自：http://www.ltesting.net