如何提高测试覆盖率
请教一下大家，我写的测试用例很多，但真正发现的bug却很简单，如何才能提高测试覆盖率呢？给点意见问题同上呀
我现在写测试用例是根据SRS的，先把要测的几大块定好，然后向里面填充。但是写好的测试用例，对我的执行没有什么用，我觉得哦。
因为开始测试的时候，我基本上不用测试用例了，全凭感觉来测试的。
我发现通过自己设计的测试用例根本测不出来问题的。 同感 使用各种方法进行测试，路径覆盖，条件覆盖，分支覆盖……实际我在测试的时候，用自己写的测试用例也是发现不了很多的bug。还有就是使用随机测试，比如：如果做手工测试的化，你除了要按照SRS的需求上面描述的步骤设计测试用例，你还要想如果不是这么做的话，会怎么样？
甚至有的时候你可能要有一些很极端的想法，或者把自己定位在客户的角度去使用软件，也许你会发现更多的bug。
而且有的时候，不只是软件功能不能实现才算是bug，有的时候不方便顾客使用，或者界面不易于学习，你也可以提出来。 先把需求看明白
然后 在根据需求去编写写测试用例
最后
不明白的话问写需求的 编写测试用例用到的方法主要是等价分类和边界值了，基本的功能方面覆盖率就很高了，其它的20%没有覆盖的就是我们所说的反向测试用例了，那得需要对业务很熟悉才可以写出有效的用例。
呵呵，这是我的一点见解，大家有没高见啊？
Free Test
我相信大家也都不原意对照着测试用例进行机械的执行，但测试用例的作用还是巨大的很多人都说无法按照测试用例发现很多bug，我想这应该比较正常吧，我们编写的测试用例应该都是基本功能模块的覆盖，如果发现了Bug,那就应该是比较严重的甚至致命的了
当然这些也和软件开发的程度有关，如果开发到后期，还经常能通过执行TestCase发现很多Bug,那我感觉这款软件的稳定性、可靠性都太值得怀疑了
所以说，发现Bug更多的来自于Free Test，其实我们在进行Free Test时候更多进行的应该是崩溃性测试吧，所以对软件的要求很高，这时候发现Bug也应该是正常的了 我觉得测试用例在后期使用比较好
因为可以指导测试人员更加细致的测试 同一楼上的说法，现在业内情况大抵如此。。。 的确....总觉得对照着用例很难发现问题.
7楼的说的很好,学到了.
给点意见
这是我的一点想法.http://www.51testing.com/?80778/action_viewspace_itemid_66481.html
大家给点意见! 看来这个问题是普遍现象哦 测试用例 指明方向 不然 几百个功能点 凭感觉是不行的 . 先找出你要测试的大的项，然后再把这些项细化，然后再不断地补充完善测试用例，如复杂的组合光是正交还不行，还要进行补充，场景中不能总是用正确的操作步骤去操作，跨越几个步骤看看效果也许会更好。 还是压力测试最能发现问题 要熟悉一些常用的测试用例设计方法。
针对不同的情况用不同的方法设计用例。 测试用例文档只是一个测试的思路，帮助测试人员减少测试遗漏的地方。但真正在测试的时候，还需要测试人员对缺陷的敏感度，大多数测试人员可能都有一定的计算机操作基础，但实际的用户可能并不是这样，所以测试人员应尽量从用户的使用角度出发来评价功能的实现情况。
那就写个好的用例
那就写个好的用例 怎么保证软件测试覆盖率?如何提高软件测试覆盖率?:hug: 我觉得应当是主要做好测试需求的分析,怎么来做呢?详解如下:
1、获取测试需求：从PM或者产品经理那里获得-用户需求说明书、详细设计说明书、数据库设计文档、接口文档说明书、USE CASE用例说明书；
2、需求分析，产生需求文档：这是一个了解项目业务和产品设计与架构的过程。（多了解点设计方面的东东，否则不只是显得很瓜，而且会让人看不起，工作无法展开或者很困难^_^)goon
具体做法：将不同来源的需求整理出来，划分成一个个测试需求点，针对每一个需求点进行测试分析。界定测试范围，然后用各种测试方法产生测试点。比如我们项目的补单的东东：30分钟-60分钟没有处理成功的订单，需要去做补单处理。这里面包含了n多内容！这里需要考虑两个方面：（1）怎么分析测试点？（这里需要把每一个点都要罗列出来)（2）测试的时候怎么去实现？抓住这两点在review的时候就好展开您的评审工作了，否则会显的很瓜，反之您的能力就体现出来了。
其次，在测试过程中需要不断完善测试用例。在测试结束后，将总结出来的测试结果添加到用例中去。
okay开发也是经常看代码才知晓程序和业务逻辑的，well tester的武器就是test case。当开发人员发生争执时候就有据可依了，他们也会看自己代码的版本。
还有就是需要加强测试流程的规范，所谓“无以规矩不成方圆”。 经验，业务熟悉程度
页:
[1]
