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

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

　　软件测试用例是为了有效发现软件缺陷而编写的。因此正确认识和设计软件测试用例可以提高软件测试的有效性，便于测试质量的度量。

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

　　误区之一：让测试新人设计测试用例

　　在与测试同行交流的过程中，不少刚参加测试工作的测试新人经常询问的一个问题是：“怎么才能设计好测试用例?”。因为他(她)们以前从来没有设计过测试用例，面对大型的被测试软件感到“老虎吃天，无从下口”。

　　让测试新人设计测试用例是一种高风险的测试组织方式，它带来的不利后果是设计出的测试用例对软件功能和特性的测试覆盖性不高，编写效率低，审查和修改时间长，可重用性差。

　　软件测试用例设计是软件测试的中高级技能，不是每个人(尤其是测试新人)都可以编写的，测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

　　因此，实际测试过程中，通常安排经验丰富的测试人员进行测试用例设计，测试新人可以从执行测试用例开始，随着项目进度的不断进展，测试人员的测试技术和对被测软件的不断熟悉，可以积累测试用例的设计经验，编写测试用例。

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

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

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

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

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

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

　　现在软件公司都意识到了测试用例设计的重要性了，但是一些人认为设计测试用例是一次性投入，测试用例设计一次就“万事大吉”了，片面追求测试设计的“一步到位”。

　　这种认识造成的危害性使设计出的测试用例缺乏实用性，或者误导测试用例执行人员，误报很多不是软件缺陷的“Bug”，这样的测试用例在测试执行过程中“形同虚设”，难免沦为“垃圾文档”的地步。

　　“唯一不变的是变化”。任何软件项目的开发过程都处于不断变化过程中，用户可能对软件的功能提出新需求，设计规格说明相应地更新，软件代码不断细化。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整，数量的增减，增加一些针对软件新增功能的测试用例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。

　　软件测试用例设计只是测试用例管理的一个过程，除此之外，还要对其进行评审、更新、维护，以便提高测试用例的“新鲜度”，保证“可用性”。因此，软件测试用例也要坚持“与时俱进”的原则。

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