好的测试用例的发现bug的比率应该是多少？
我是刚进入测试行业的新人。最近在写一些测试用例。在写一个功能的测试用例，但使我迷茫的是，测试用例发现的bug的比率为多大的时候就可以说这些功能测试的用例就可以算是高效的测试用例？请高手们指点一下，小妹在这里谢过了！ 我个人感觉，测试用例需要的覆盖，而不是有效。换句话说，测试用例涉及到的地方，保证不要有遗漏，问题尽可能的发掘。
测试用例以外的地方，听天由命吧。
另外一种大众的说法：
一个好的测试用例,就是能发现程序中至今未发现的错误。
一个成功的测试就是发现了程序中至今未发现的错误。 正常我的经验告诉我是百分之六十 谢谢指点，不过版本升级后就，在前一个版本发现问题的地方在修改后，我再次测试的时候一把那不会再有什么大的问题，但是老师说在修改过的地方会有更多的问题隐藏。不过我再次测试的前版本有错的地方的时候，不仅用以前的用例，还增加了一些新用例。这样做是不是会浪费一定的时间，在时间紧任务重的情况下，我们该怎样做到平衡时间和用例的关系呢？ 几乎每一个测试人员都抱怨没有足够的时间用于测试，但实际情况是测试任何东西到完整的程度都是不可能有充足时间的。当你充分考虑软件的特性如可用性、安全性、兼容性、互操作性等时这一点尤其正确。不要再抱怨缺少时间，学会根据风险来进行优先级排序，把注意力都放在对管理层很重要的应用目标上。有时候我们测试的内容超出了我们需要测试的，因为我们的目标偏离了产品的价值。
如果你测试的东西后来有缺陷被发现，不要变得气馁。你可能已经做了非常全面的工作，获得了高水平的缺陷移除，但100%都是不可能的目标。 挺好得 帖子 这个要看程序写得好坏而不是测试用例写的如何吧?
我们要做的是尽量把错误找出来
如果程序没问题,那不代表测试的人失败啊 支持一下！！ 其实，测试人员应该和开发人员是互助互利，但是在现实中开发的人员和测试人员之间却有了鸿沟。使本来就缺乏沟通的开发人员和测试人员之间产生了“暗斗”。 根据业内的一般指数
工作量（人天） 30.5乘以千行代码
需求文档规格（页）4.18乘以千行代码
缺陷总数（个） 22.5乘以千行代码
遗留缺陷（个） 0.45乘以千行代码 这样的指数，晕。
做了实训，好累。
什么都的我写，测试计划，测试用例，运行测试用例，提交Bug，测试总结。。。。。
明天要答辩了，我今天做了一天的答辩ppt。
呵呵突然发现，我对word和ppt的应用能力还是比较好的。
工作，工作，放下工作，立志学习，辞了工作，找工作........
期待工作.......... 你还在做测试吗 我也是新手 好多不都得东西啊迷迷糊糊的 感觉这个指标不好衡量 这个看开发 的能力吧
页:
[1]
