写好的用例发现不了多少bug

manbuyunduanlg

我有一个疑问，就是费劲写好的测试用例库，真正去测试时，却没有多大的作用，发现的问题基本上大部分都是随机测试发现的，不知道别人有没有人和我有同感，怎么提高测试用例的质量？我现在很困惑，把这个问题拿出来大家讨论一下

honsongj

做以前没想好吧

feiyunkai

有三方面原因：
一、用例覆盖率不够：功能覆盖和逻辑覆盖。
二、用例的执行力不够。
三、用例没及时更新（现实中需求变更是很正常的事，另外自由测试发现的BUG应该补充到新的用例里）
     想要通过走用例，找出大多数甚至所有的BUG，是不现实的，因为假如仅仅通过走用例就可以找出系统中大多数甚至所有的BUG，那么每个公司还用得着那么多测试员吗，只要2个就够了，一个编写用例，一个执行测试，录制好测试脚本，每次有版本下来，回归一下就好了

mujjk

的确有这样的情况，随机测试发现的bug要比走测试用例发现的bug数目多。测试用例很多写的就是需求里面的内容，如果考虑需求覆盖率的话，已经达到，但测试粒度可能比较粗。我们写用例要有侧重点，对于重要模块，要尽量粒度细一点。同时将发现的bug补充到用例里面。

wslss007

额，取决于你用例的覆盖程度了，不过BUG也经常在异常操作时才出现的，你的用例可能没有涉及到太多异常操作，而是正常功能的测试为主。

老肥羊

先寫用例再寫測試用例
會比較好
學好一種分析能力
一種審視系統的能力
準確的接受信息與準確的輸出信息
明確的判斷力
當時我手下的測試工程師也有這種問題
其原因很簡單
最少我覺得是
測試用例都是貧空寫出來的，雖然有根據需求分析文檔或產品文檔或各種各樣的文檔
但這個過程缺乏了一種自己對整體系統需求的認識與分析
所以，我推薦你可以先對系統寫用例
寫完用例後再依據用例寫測試用例

3396408

原帖由 老肥羊 于 2009-2-3 10:38 发表
先寫用例再寫測試用例
會比較好
學好一種分析能力
一種審視系統的能力
準確的接受信息與準確的輸出信息
明確的判斷力
當時我手下的測試工程師也有這種問題
其原因很簡單
最少我覺得是
測試用例都是貧空寫出 ...

肥羊，整个样例大伙学习学习
系统用例和测试用例不是一回事？？不太明白，请直接

老肥羊

原帖由 3396408 于 2009-2-3 11:15 发表


肥羊，整个样例大伙学习学习
系统用例和测试用例不是一回事？？不太明白，请直接

我有發基本概念..

http://bbs.51testing.com/thread-138941-1-3.html

http://bbs.51testing.com/thread-138955-1-3.html

http://bbs.51testing.com/thread-138940-1-3.html

jfan288

正常就应该是这样的，测试用例只能测试已有的功能，是一种positive testing.
如果你的先前定义的测试用例能发现大量的bug，developer的水平或者开发流程就存在严重问题了。

jfan288

当然了，前提是你的覆盖率符合要求。
我们这边的要求是，功能测试对代码的覆盖率要达到80%

quxingying

我也有同感，测试用例测试出的问题比较少，一般都是随机测试测出的BUG

manbuyunduanlg

谢谢大家参与，希望更多的人参加进来

stacy-2008

看了大家的发言我受益匪浅，我来说说我的观点。要解决楼主这个问题，首先我们要了解一个概念，那就是测试用例包括哪些内容。会有人说，不就是什么前提条件、步骤、预期结果么。我说的包括内容不是说用例本身。其实测试用例应该有用例描述和测试数据两部分组成。一般用例描述部分大家根据需求文档进行编写的都会比较全。而出问题的地方，或者说很难找出bug的地方，是测试数据。其实我们的一个用例需要对应很多组的测试数据。只有测试数据完整了，那么我们才能找出很多bug。而测试数据的完整性，其实就是靠等价类、边界值这些用例的设计技巧来完成。我们在设计用例或者设计测试数据的时候没能比较娴熟的运用和结合这些方法和技巧。以上是我们测试用例找不到很多bug的一个重要原因。
除了以上的这个原因，其实还有一个比较重要的原因，那就是对需求的理解。大家都应该能感觉到一开始大家对需求的理解度没有后来深。这其实和大家一开始不重视需求理解，或者方法不对有很大关系。其实需求不管是对开发和测试都是重中之重。我们一开始必须深刻的理解它，才能写出相对完整有效的用例出来。以上两点是我们用例找不出bug 的主要原因。当然不是100%的bug都能从用例里面找出。但是应该尽量多的从用例里面找到bug。此外还有一点对用例质量的提升很有好处，那就是要不断维护。很多的公司一开始把用例写完后，在执行过程中，不去维护它。这样其实不是一个很好的习惯。我们应该发现了一些确实的用例内容，我们就要及时的补充进去，尤其是对产品类测试非常有用。从表面上看似乎浪费了时间，其实不然 ，这样做可以提高后面很多轮测试的效率，不需要自己再动脑子去想了，同时也提高了质量的保证程度。以上是我的一些见解，欢迎大家互相交流。
看了大家的发言我受益匪浅，我来说说我的观点。要解决楼主这个问题，首先我们要了解一个概念，那就是测试用例包括哪些内容。会有人说，不就是什么前提条件、步骤、预期结果么。我说的包括内容不是说用例本身。其实测试用例应该有用例描述和测试数据两部分组成。一般用例描述部分大家根据需求文档进行编写的都会比较全。而出问题的地方，或者说很难找出bug的地方，是测试数据。其实我们的一个用例需要对应很多组的测试数据。只有测试数据完整了，那么我们才能找出很多bug。而测试数据的完整性，其实就是靠等价类、边界值这些用例的设计技巧来完成。我们在设计用例或者设计测试数据的时候没能比较娴熟的运用和结合这些方法和技巧。以上是我们测试用例找不到很多bug的一个重要原因。
除了以上的这个原因，其实还有一个比较重要的原因，那就是对需求的理解。大家都应该能感觉到一开始大家对需求的理解度没有后来深。这其实和大家一开始不重视需求理解，或者方法不对有很大关系。其实需求不管是对开发和测试都是重中之重。我们一开始必须深刻的理解它，才能写出相对完整有效的用例出来。以上两点是我们用例找不出bug 的主要原因。当然不是100%的bug都能从用例里面找出。但是应该尽量多的从用例里面找到bug。此外还有一点对用例质量的提升很有好处，那就是要不断维护。很多的公司一开始把用例写完后，在执行过程中，不去维护它。这样其实不是一个很好的习惯。我们应该发现了一些确实的用例内容，我们就要及时的补充进去，尤其是对产品类测试非常有用。从表面上看似乎浪费了时间，其实不然 ，这样做可以提高后面很多轮测试的效率，不需要自己再动脑子去想了，同时也提高了质量的保证程度。以上是我的一些见解，欢迎大家互相交流。
看了大家的发言我受益匪浅，我来说说我的观点。要解决楼主这个问题，首先我们要了解一个概念，那就是测试用例包括哪些内容。会有人说，不就是什么前提条件、步骤、预期结果么。我说的包括内容不是说用例本身。其实测试用例应该有用例描述和测试数据两部分组成。一般用例描述部分大家根据需求文档进行编写的都会比较全。而出问题的地方，或者说很难找出bug的地方，是测试数据。其实我们的一个用例需要对应很多组的测试数据。只有测试数据完整了，那么我们才能找出很多bug。而测试数据的完整性，其实就是靠等价类、边界值这些用例的设计技巧来完成。我们在设计用例或者设计测试数据的时候没能比较娴熟的运用和结合这些方法和技巧。以上是我们测试用例找不到很多bug的一个重要原因。
除了以上的这个原因，其实还有一个比较重要的原因，那就是对需求的理解。大家都应该能感觉到一开始大家对需求的理解度没有后来深。这其实和大家一开始不重视需求理解，或者方法不对有很大关系。其实需求不管是对开发和测试都是重中之重。我们一开始必须深刻的理解它，才能写出相对完整有效的用例出来。以上两点是我们用例找不出bug 的主要原因。当然不是100%的bug都能从用例里面找出。但是应该尽量多的从用例里面找到bug。此外还有一点对用例质量的提升很有好处，那就是要不断维护。很多的公司一开始把用例写完后，在执行过程中，不去维护它。这样其实不是一个很好的习惯。我们应该发现了一些确实的用例内容，我们就要及时的补充进去，尤其是对产品类测试非常有用。从表面上看似乎浪费了时间，其实不然 ，这样做可以提高后面很多轮测试的效率，不需要自己再动脑子去想了，同时也提高了质量的保证程度.

manbuyunduanlg

还有一个现实问题就是，需求写的很模糊，怕以后做出来的产品达不到需求要求，所以就尽量写的不是很详细，这样设计出来的测试用例，虽然覆盖需求100%，但是较之系统应有的功能差很多。但是研发的习惯以及这种模式改变不了。
比如：数据导出功能：支持对选择的图像数据进行外部导出刻录到指定刻录设备(（CD/DVD）)。用户选择要导出的数据，点击导出按钮，弹出导出刻录对话框，用户可选择刻录设备配置，同时显示要导出数据，数据类型，刻录设备信息等。数据导出尽量支持IHE-PDI格式要求。同时提供外部刻录图像浏览需求支持的浏览软件。

这样一条需求怎么设计出详尽的用例呢