测试用例设计的误区（原创）

dennis_d

参见我的个人主页：
http://sitwithwhom.51.net/index. ... d=a_20041221_104000

1、能发现到目前为止没有发现的缺陷的用例是好的用例：
首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：

    * 程序做了它应该做的事情
    * 程序没有做它不该做的事情

因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；
      不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。
      在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。
      除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。
      在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

3、测试用例设计是一劳永逸的事情；
      这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。
      这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

4、测试用例不应该包含实际的数据；
      测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

5、测试用例中不需要明显的验证手段；
      我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

jiping_xu

写的很好不错
本人受益非浅，我以前对测试用例的粗细程度总是迷茫
现在醍醐灌鼎

atce

2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；

这个问题的关键在于区分测试分析和测试执行. 多数公司是不区分的,当然不用太详细拉.

sunflowers

楼主说的很不错，测试用例的好坏对测试过程有很多的影响，，怎么设计有效的测试用例也是测试过程中的一个难点，测试用例的编写不仅包括测试用例的输入，步骤，预期的输出结果，而且在设计测试用例的过程中还应设计相应的测试数据。预期的输出结果中还可能包含隐藏的输出结果。
所以，如果软件的需求了解的还不输入或者需求写的不是很明确的话，，设计一个有效的测试用例恐怕是很难的。

关河

包括测试计划、测试实施、测试人员如何处理与开发人员的关系、测试团队的组织等等

关河

改了名字：）

决定不叫dennis_d，用 关河 的名字

jackei

已经加入精华贴，希望关河朋友可以为大家提供更多更好的文章^_^

twinkestar

写得不错，揭出了实际工作中的一些误区，很有参考价值

xjtuzxq

同意！

就我这段时间的工作经历来说

测试用例写的比较简单，很多连设计测试用例的思想在用例上面都没有得到体现

alfra

全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

这也是没有办法的事情啊。

xuerzj

写的很好，有同感呀。我们的测试用例书写的一个要求就是不要写得太细，不要把一个个步骤都写下来，那样维护量会大的惊人，而且对操作很熟悉的人去读繁琐的操作步骤是一种煎熬。我们要求使用用例的人员是经过业务培训对软件功能熟悉的人。我们也要求对于复杂的业务功能测试用例中要写明验证某表某字段的数据，书写保存成功这样累似的校验点是没有意义的，因为是否真的正确没有验证到。

awpfinal

谢谢楼主
刚刚接触测试，感觉对测试用例的设计详细程度无法把握好，看了这片文章收获不小，以后要多向各位高手学习。

飘雪

写的挺好，我在实际工作中也遇到了此类问题。

老牛

测试用例若不用写那么详细的话，是否将测试用例定位为测试作业指导书，这样是否更合适一些。这样不要太多的精力去维护测试用例，因测试用例就算很详细，也不能包括测试的所用内容，所以还是将测试用列写成具有指导性的，这样测试用例就会有较大的灵活性

云层

写到了一些点子上，对于新手可能一下明白不过来

test_zh

学习中体会

zension

受益非浅，第五点我是和作者不谋而合了，哈哈

luckhj

写的很好，支持

浪漫小站

楼主说得很对，其实好的测试用例并不是真的那么容易写的。我在短短的工作也遇到过同样的问题

gg

测试用例应该是随着开发不断尔变的把