测试用例设计的误区

xulin168

1、 能发现到目前为止没有发现的缺陷的用例是好的用例：

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

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

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

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

　　不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度 也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实 现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到 一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

　　在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在 给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目 标，一切围绕测试的目标进行。

　　除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

3、 测试用例设计是一劳永逸的事情；

　　这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例 却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰 后，对测试人员不屑一顾。

　　这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

4、 测试用例不应该包含实际的数据；

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

5、 测试用例中不需要明显的验证手段；

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

B2CPC

我倒，是前面有的前辈贴过的，楼主来骗分数的呀，哈哈

dyzax926

管它呢，以前没看过，现在我看到了，这个贴子对我是有意义的！哈

Kapok

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

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

测试是根本无法保证“程序做了它应该做的事情”或“程序没有做它不该做的事情”的 除非做 exhaustive testing

通过测试只有可能保证程序做错了某些事情

证明程序的对错本来就是一个 undecidable problem

swallow0918

同意楼上的。测试只是为了发现软件中存在的bug，而不是保证什么。

ggstar

保证程序做了应该做的
这句话应该没什么问题阿

songfun

今天这位楼主发飙了，呵呵，一口气发了很多帖子。
不过有一些帖子精华区有了

wzb521

1、我觉得这句话不对。
    什么叫发现没有发现的BUG就是好的用例，难道没发现BUG的就不是好的了吗？BUG的出现部分程度上是跟程序员的书写习惯有关系的。程序出错就是程序做了它不应该做的，难道你能证明吗？
2、这句话，某些方面是对的，但也不一定完全对。写的详细了，测试员就会有以来性，也就不去拓展，不去发挥自己的思路了。有好也有坏。
3、测试用例书写是件好事，虽然我不写，但我能体会到他的好处。
4、没有包含具体数据，那不是和2矛盾了吗？楼主怎么不看好再说呢？也不知道这几条是谁写的。。。
5、需要明显的证明手段（如果没有，那你如何判断结果是否正确呢？你都不知道结果，还测试什么呢？这不是和2又冲突了吗？）证明手段不一定是提交成功，如果是单步的，我们只要看数据库里是否添加就可以。如果是集成测试，我们还要看添加进去是否能回显，等等。


以上仅代表个人意见。。。

kpxl

大家有点误解了。

发现没有发现的bug 的用例是好用例，这句话应该这样来理解，你设计了一份用例测试一个别人已经测试过的系统，这里你会发现一些他曾经发现的Bug，也会发现一些他没有发现的Bug，那对于整个系统来说，你设计的能发现他没有发现Bug的那些用例就是好用例，可以补充到用例库中。

说说测试的范围：
我认为测试是既要验证程序实现了应该有的功能，又要验证程序不应该完成的功能。这句话有点拗口，简单说就是和我们写用例一样，需要设计正面的测试用例，验证程序在正确的输入下得到了正确的结果，还要验证程序在错误的输入下，是否能够判断出来，或者说能够得到让用户接受的结果。

至于楼主说的第二条，我是不赞成的，说句实话目前国内的公司很少能做到这点，所以楼主觉得这样没有必要，劳民伤财，但是我愿来在的美国的一家软件公司就基本上做到了这一点，新人就是直接拿着老员工的用例跑，现在甚至是把测试分成两组，一组写用例，一组执行。不能因为我们目前的现状就降低我们对自己的要求，就好像说因为我们国家穷，没有钱，大家就不用穿衣服了一样，这个比喻不太恰当，呵呵。

大妮

订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段

恩，这句话很有用，不能简单的说订单成功就是通过了，还要看关联的数据是否更新成功