如何评定测试用例的好坏
现在我做的是功能测试，每次设计测试用例的时候，我总是尽可能地考虑更多的情况，使设计的测试用例能够完善。但是总是找不到一个比较规范或更有效的办法来检测自己设计的测试用例是否真的好（能找到更多的bug），大家有什么好的建议呢？ 楼上的挺全面了我记得一句话： 用尽量少的用例 发现尽量多的缺陷
不知道这句话还有没有补充。。
另外 如果是数据驱动式的 数据表也应该方便维护 补充楼上说的～
个人觉得评价用例的好坏并不能只凭它发现有多少缺陷，而是发现缺陷的质量
比如说同样是测手机，两个人都写了100个用例，A发现了50个缺陷但那些功能基本上是不会用到的功能上的缺陷，而B发现了1个缺陷，他发现这个手机在通话中有缺陷，你说谁的用例好的？ 我觉得这要根据实际情况来分析，比如一个项目的系统测试，要求是尽早验证主要功能模块，或者某些功能需要尽早测试，不同情况下用例的设计和规程都是不同。
设计的大方向还是上面几位朋友说的。 测试用例发现BUG 的百分比？
这个怎么衡量，你永远不知道你的系统还有多少bug没有发现。
曾经有这样一个故事，一个软件经过测试，发现100个bug,另外一个软件经过测试，发现5个bug,那么哪个软件的质量好一些，测试更充分一些？
这肯定是无法进行衡量的，发现100个缺陷的软件可能还有1000个bug没有发现，相反，可能另外一个软件只有5个bug。
但是测试用例的设计，显然要考虑测试覆盖。需要按照的一定的测试用例设计方法进行，不能拍脑袋决定。 原帖由 lengz 于 2007-3-31 15:47 发表 http://bbs.51testing.com/images/common/back.gif
补充楼上说的～
个人觉得评价用例的好坏并不能只凭它发现有多少缺陷，而是发现缺陷的质量
比如说同样是测手机，两个人都写了100个用例，A发现了50个缺陷但那些功能基本上是不会用到的功能上的缺陷，而B发 ...
哈哈 是的 原帖由 rickyzhu 于 2007-4-1 21:27 发表 http://bbs.51testing.com/images/common/back.gif
测试用例发现BUG 的百分比？
可以用缺陷密度衡量吗 n/kloc？
还有是不是可以通过缺陷分析找出残留缺陷密度 判断测试是否可以退出——我觉得很厉害阿 现在企业有这么做吗 1、个人认为测试用例应该尽可能多的扩展Case
2、测试用例的编写者并不是该用例的使用者，这一点需要在编写的时候讲究语言的合理性
3、个人认为测试用例编写如果能够达到“即使一个初级入门者，使用你编写的测试用例照样可以发现同样质量的Bug“就非常好了！
[ 本帖最后由 maych 于 2007-4-2 12:50 编辑 ] 个人认为：用尽量少的用例，覆盖面要全，发现ＢＵＧ的百分比，最重要的是发现BUG的质量 我觉得要看用例的覆盖面以及可执行性，发现bug的数量则很难说，因为bug的数量本身跟软件质量是有关的，打个比方说，同一个系统，有两组不同的人去开发，然后使用同一套测试用例去测试，两者发现的bug数肯定是不一样的，因为软件质量本身就存在差异，但不能说这两套测试用例有优劣之分，本来就一份用例啊~ 我的总结如下：
1。用例的覆盖率很重要，特别是对主要功能点的覆盖
2。用例设计的内容及步骤的详细度高，可执行性强，好的用例，是任何一个测试员都可执行测试，而无须再细看需求文档
3。用例的测试结果，所测试发现的BUG数量和质量，特别是质量很重要，因为BUG的数多，可能是开发人员的问题，而能测试出很难发现的BUG就是测试用例设计的水平了
4。用例能及早发现BUG，而不是很晚发现BUG
5。能全面提供很连贯测试数据，就按其测试用例的顺序，及每个用例的数据可用于下一用例
6。测试用例很准确描述测试期望结果；
7。测试用例的归类，将测试用例分成业务类，UI类，数据逻辑类等，不同行业分类不一致，这样测试人员对其测试目的很清晰 我觉得第一要保证功能覆盖率，第二才是缺陷与用例的比例。 11楼说的真好:P 大家都说的很好！ 11#说的不错，学习了--- 说得非常棒，学习了。 测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能.再加上软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计 11楼的总结很好，支持一下~
页:
[1]
