求教：什么样的用例才是好的用例呢
请教一个问题：什么样的用例才是好的用例呢 能够覆盖测试需求的用例，估计就很不错了。 能够发现软件现在还没有发现的问题覆盖软件需求，应该差不太多了 同意楼上的
回复 #1 anruie 的帖子
我认为软件测试用例只要能找到尽可能多的Bug就是好的测试用例具体衡量标准：对于系统测试 考虑测试用例对于需求的覆盖程度
对于集成测试 考虑测试用例对于函数间接口 模块间接口 子系统间接口的覆盖程序
对于单元测试考虑逻辑覆盖率 个人认为不管有没有发现BUG，只要有条理清晰的思路写出来的用例就是好用例 那如何才能做到需求100%覆盖呢？ 好的用例应该是:1)用例的关注点要明确,清晰;2)用例的输入和预期输出要写得详细一点(时间不是很紧的话),也许是自己来执行的,但写得明白一点,以防过了一段时间之后,自己看自己写的用例,都看不懂. 覆盖需求,简洁易懂,格式规范 偶同意8楼的，好的用例不一定要发现BUG，但是关注点应该明确，针对性要强 个人觉得，如果能用最少的用例发现比较多的bug，那应该就是好的用例。
比较全面的覆盖到需求的用例。能够比较直观的重现错误的用例。
关于用例
最近快要考试了忽然想起这个阶段其实就是学的怎么写用例我觉得如果只是做好自己的本职工作的话就是用各种分类法设计用例，越全面越好，重点把握好覆盖率
如果想要有所造诣，那就要多思考了，其实在测试的过程中，功能方面所能造成的软件修改还不是最令人头疼的，在性能测试方面那基本上是要汤和药一起换的 ，所以如果能够从函数，类这方面就着手去分析以后可能导致的性能问题的话，应该就可以是个行家了 人家说的是好用例，又不是设计， 个人觉得，不要刻意追求用例的好坏。用例是为了什么？目的是发现软件缺陷，而如何才能更好的做到这点，并不是说发现了缺陷了就是好用例，没有发现的就不好，而是要靠用例对需求的覆盖。
如果非要说用例的好坏，那就是在用例设计中，一些意想不到的组合了，而那些往往是在你有了很多经验后，一些错误猜测的用例里面。 将需求覆盖全面且能发现BUG的用例 用例的好坏关键就在于它是否能够达到有效的覆盖率。
在实际工作的CASE的数量往往是于工作量成正比的，然而紧张的项目周期不允许我们一味的最求CASE的数量。所以说CASE不在多而在于精。
我们只要按照CASE的设计方法（等价类划分、边界值等方法）结合需求文档来设计CASE，并对需求达到一定的覆盖率。大家应该都学过：1条CASE中要尽可能多的去覆盖有效等价类。这就是控制CASE数量的一种手段，同时又保证了CASE的质量。相反如果不用方法去随意的编写CASE，当然也能覆盖需求，但CASE的数量会多出很多，测试内容也会有很多不必要的重复。
所以要写出好的CASE除了要使用方法外，也存在着很多的技巧，还需要在实际工作去操作并积累经验。
[ 本帖最后由 liangliang1108 于 2007-3-13 22:48 编辑 ] A good test case is one that has a high probability to find an error. 其实在工作中，最主要的和最难的应该就是如何写好测试用例吧，个人认为通过各种方法设计出测试数据，通过分析，删减得到的部分用来作为用例的输入，尽量用少的用例来发现更多的错误吧！我觉得好用例就是为了覆盖需求而设计的，用来发现其中不满足的情况。 我们做测试的不就是为了找到BUG吗??好的测试用例当让是为了找出BUG.... 设计测试用例，在实际测试用例设计过程中，不仅要根据需要、场合单独使用这些方法，
常常综合运用多个方法，使测试用例的设计更为有效。
1。写的清晰，能让测试执行人员执行起来方便，
并且一个测试用例中的测试数据尽量做到包含尽可能多的测试点！
2。好的测试用例是发现迄今为止未发现的错误的测试用例
3。能够全面覆盖测试需求的用例。
总之，要从多个方面来考虑．
以上是个人的观点．不知是否正确．sdlkfj5
页:
[1]
2
