浅谈软件测试用例设计的六大误区

《浅谈软件测试用例设计的六大误区》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、由安博测试空间技术中心http://www.btestingsky.com/提供 在IT行业，软件质量问题日益成为软件企业生存与发展的核心,软件测试作为保障软件质量的有效手段日益得到认可。软件测试作用例设计是软件测试的重要一环，然而很多测试人员（尤其是刚从事测试工作的新人）对测试用例设计的作用和方法还存在认识误区，本文旨在对这些认识误区进行简单剖析。    误区一、好的用例是能发现未知BUG的用例：    首先必须说明，这句话其实是很有道理的，然而很多测试人员都曲解了这句话的原意。他们把测试用例看作孤立的个例，盲目追求设计“难于发现的缺陷”的用例，忘记了测试的

2、目标是尽可能发现程序中存在的缺陷。    软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合,对它的评价也只能对测试用例的集合来进行，测试本身是一种验证加确认（validation&verification）的活动，测试需要保证程序做了它应该做的事情,且没有做它不该做的事情。    测试用例的好坏应以是否完整有效覆盖需求为依据，我们不应针对单个的测试用例去评判其好坏，而应对某次测试的用例集合总体作评价。    误区二、测试用例应该详尽,使得未接触系统的人也能进行测试：    测试用例描述的详细程度困扰着许多测试人员。描述简

3、单的用例不利于用例的传递，而描述复杂的用例的设计和维护需要耗费大量的时间。然而很多测试主管或者测试工程师本身，强调测试用例“越详细越好”，全然不顾实际的测试资源不足的事实，一定要写出“没有接触过系统的人员也能进行测试”的用例。    这种做法无疑会耗费了很多的时间和资源，从而极大的压缩测试实施的时间和人力，没有足够的测试执行时间，就无法发现更多的软件缺陷，测试质量也就无从谈起。    测试活动应需要结合自身的资源（测试人员对系统熟悉程度、测试工程师数量、测试时间等）和项目的需求来进行综合考量，以实现质量、时间和成本的最佳平衡。我们建议给测试设计安排30%-40

4、%左右的测试时间，测试工程师可以根据项目的具体情况确定测试用例的颗粒度，在测试用例的评审阶段由相关人员对其把关即可。    误区三、测试用例设计是一劳永逸的事情；    很多测试人员（尤其是对测试技术不太了解的主管）认为设计测试用例是一次性投入，片面追求测试用例设计一步到位，导致设计的测试用例与需求和设计不同步的情况在实际开发过程屡屡出现。    这种认识造成的危害性在于使得设计的测试用例缺乏实用性，误报很多不是软件缺陷的BUG，误导测试用例执行人员，同时也浪费了开发人员的解决BUG的精力和时间。    几乎所有软件项目的开发过程都处于不断变化（随着需求的变更

5、）过程中。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整和数量的增减，增加一些针对软件新增功能的测试用例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。    误区四、测试用例不包含实际的数据和明显的验证手段；        测试用例是通常是一组输入、执行条件、预期输出结果的组合，毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具备可执行性。例如我们常用的边界值法就对数据提出了明显的要求。    很多测试工程师（尤其是测试新手）编写的测试用例中，“预期输出”仅

6、描述为程序的可见行为，实际上，“预期结果”的含义并不只是程序的可见行为。例如，对一个代表信息管理系统，输入代表信息，点击“保存”按钮后，系统提示“保存成功”，这样是不是一个完整的用例呢？是不是系统输出的“保存成功”就应该作为我们唯一的验证手段呢？显然不是，保存是否成功需要查看相应的数据记录是否在数据库中更新：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。    因此，在测试用例中，还应该包含实际的测试数据和对测试结果的显式验证手段。    误区五、测试输入数据设计方法等同于测试用例设计方法     现在流行的一些测试书籍认为，测试用例的设计方法包

7、括：等价类、错误推测法、场景设计法、边界值法、因果图法等。这种表述是极其片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。     确定测试的输入数据对于软件功能测试和性能测试的重要性不言而喻，它决定了测试的有效性和效率。但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个很小的方面，除了确定测试输入数据之外，测试用例的设计还包括如何根据需求和行业软件的具体设计规范确定测试用例的设计策略、设计用例的表示方法以及测试用例组织管理形式等问题。    我们绝对不能从心理上忽视测试用例设计内容的丰富性和技术的复

8、杂性，而应综合考虑被测软件的功能、特性