大家来聊聊对这句话的理解

chenlei8899

今天看软件工程的书,说到"那些只能使程序正确执行的测试用例是没有什么意义的,执行这些测试用例只是白白浪费时间和金钱而已,而能够发现错误的测试用例才是成功的例子".
我觉得这句话说得不对,我做测试工作2年了,工作中大部分测试用例都能正确执行,因为没有执行这些正确的例子,又怎么知道程序会不会在这里出错呢?

moly

Originally posted by Fantasy at 2005-8-11 09:01:
我觉得判定测试用例的好坏，最好的衡量标准就是覆盖率。

一般达到怎样的指标算是认为测试基本OK？
比如，函数覆盖率达到80%算不算？还是必须达到100%

Josh_zhu

那句话本身没有什么错误，是你没有理解作者要表达的意思，他时说：有些人为了完成（应付）测试，故意找了一些根本没有意义的用例。而没有从实际需要去做，当然没有什么意义了

jackei

Originally posted by C# at 2005-10-8 17:00:
理論上講，測試的用例越多越好，但現實中必然要追求用較少的測試成本達到理想的軟件質量，究竟執行哪些用例，必然要由測試人員的經驗和能力來作出必要與非必要的判斷和取捨。如果程序的難度超出了相關測試人員的 ...

这种说法太理论化了。
所谓的“很多無意義用例，而又無法發現問題”的测试用例是在测试用例设计阶段产生的，如果有这种测试用例——没有通过等价类划分、因果图/决策表等方法整合掉，但是最后通过的评审的测试用例就必须要被执行。
换句话说，通过了评审的测试用例都要被执行，如果认为不应该执行，那么应该在评审时提出。
那种理论上的“用較少的測試成本達到理想的軟件質量”，需要的是长期从事同一个行业测试工作形成的积累，只能是一个目标——没有最好，只有更好。我敢放言，国内没有任何一家公司敢说自己在这方面做得很好。

C#

理論上講，測試的用例越多越好，但現實中必然要追求用較少的測試成本達到理想的軟件質量，究竟執行哪些用例，必然要由測試人員的經驗和能力來作出必要與非必要的判斷和取捨。如果程序的難度超出了相關測試人員的能力所能及的把握理解的範圍，那麽就會出現執行很多無意義用例，而又無法發現問題的情況了。

jackei

唉，希望大家要明白，软件缺陷是包括几个方面的。大家在讨论的几乎都是由于设计和实现而引入的缺陷。但是测试工作的第一步就是先验证是否实现了需求中定义的所有功能，如果某个功能没有实现，那么也是一个缺陷，这种缺陷并不是靠所谓的“异常的”测试用例来发现的。
不知道大家明白了没有，在缺陷被发现之前，是不知道它是否存在的，所以根本不存在哪些测试用例有用，哪些测试用例没有用的问题。所有的测试用例都是必需的，不过并不是所有的测试用例都被执行罢了。

kpxl

看看大家讨论的这么激烈，偶也谈谈看法，仅代表个人观点：

测试用例的作用：测试用例的作用很重要这是毋庸置疑的，但是到底重要到什么地步？还有测试用例的用处是什么，到底是用来发现Bug还是什么。我想在不同的阶段甚至不同的系统的要求和看法都是不尽相同的。软件工程上讲，软件测试是为了证明软件有错误，那是否可以说测试用例就是为了发现Bug而设计的，或者说没有发现Bug的测试用例就不是好的用例？测试用例是为了发现Bug还可以接受，如果说没有发现Bug的用例不是好用例就有点让人不能接受了。因为在拿到Spec之后，测试人员会先开始理解需求，然后设计测试用例，这时你根本就不可能知道哪里会出错。这是其一，其二，RUP要求每个场景要设计一个正面的用例和至少2个以上的负面用例，由我近三年的测试经验，Bug大部分都是发生在负面用例的处理上，因为正面的用例开发自己如果稍作测试都可以发现，但是你不能因为这样，就不设计正常的用例吧，如果出错呢？而且这不是简单的功劳苦劳的问题，就如同工兵排雷一样，雷区就在前面，你不能因为工兵排了半天没有发现地雷，而说工兵没有工作或者说工作没有成效吧，至少他给你找到了一条安全的路线。
还有一点就是上面有人提到测试覆盖率的问题，个人认为这完全是空话，试问如何评定测试覆盖率？怎么量化？难道用通过执行测试用例发现的Bug数占总Bug数的比率来当作测试用例覆盖率？这个值大家可以想想，能代表什么？其实什么都不是！

说了一通，欢迎大家拍砖头！

takiro

现在对于用例的定义还是那么死板 虽然大的方向是不变的 但针对每个公司所达到的目的 每个测试组的不同情况用例的设计是可以变更的 用例的作用并不单单是为了发现错误 也可以做用例库完善/用例覆盖率准则/个人用例设计评定等 对于elmerwu的观点 我是非常赞同的 并不能因为用例没有直接发现错误 而抹杀了它的间接指导意义！

bseagull

我想这是否就是讲的正向测试 和 逆向测试？

elmerwu

成功的测试用例并不是没用的，就像以前一个故事说的，一个人吃了6个饼才觉得饱了，他就认为前5个饼都是没用的。这种看法众所周知是错的，第6个饼是因为有前5个饼的基础。同样的，正确的测试用例只是为那个错误的用例打下基础的，ggstar说的对，好的测试用例不是指一个，而是指一组。一组用例只要能发现BUG就是好用例

assult_xp

从不同的角度看自然得出不同的结论，看你重视哪方面了。

xulin168

使程序正确执行的用例也有意义，因为，这是要算成本的，是算钱的。不然，测试的钱怎么算!

flytigerboy

学习学习，偶还是刚进入测试这一行的！

TestOrNotTest

Originally posted by yaindilly at 2005-8-13 12:43 AM:
这是个测试效率的问题。测试效率的单位是问题每千测试用例数。正常用例不产生效率，所以句子中说他们没有什么价值。何况正常的用例测一遍就废掉了，没用了。

一次就废掉？
你这句话在回归测试里就是错误的。。。

Tender

怎么听上去楼上的像在“拍马P”啊！：）

swallow0918

Originally posted by 天网 at 2005-8-15 22:32:
这是很早以前关于测试的很片面的看法之一：测试的目的是为了发现错误，一个好的测试用例是能够发现以前没有发现的错误，一次成功的测试是发现了从前未发现的错误的测试。现在关于测试的目的已不仅仅限制在发现错 ...

同意老师的回答！这种观点也是正确的。

天网

这是很早以前关于测试的很片面的看法之一：测试的目的是为了发现错误，一个好的测试用例是能够发现以前没有发现的错误，一次成功的测试是发现了从前未发现的错误的测试。现在关于测试的目的已不仅仅限制在发现错误上。即使限制在发现错误这点上，不能达到各种层次的覆盖也是没有多少意义的。

yaindilly

这是个测试效率的问题。测试效率的单位是问题每千测试用例数。正常用例不产生效率，所以句子中说他们没有什么价值。何况正常的用例测一遍就废掉了，没用了。

ggstar

我觉得好的用例不是指一个用例，而是指一组用例

Fantasy

我觉得判定测试用例的好坏，最好的衡量标准就是覆盖率。