今天听到一朋友说测试用例写了一大堆，执行用例后没找到几个 bug，太费时费力，还不如拿到产品后自由发挥测试找的 bug 多，请教我如何提高测试用例的有效性？我思路比较狭隘，特向各位集思广益.........，另外你们的用例有效性一般能达到百分之多少？
说明 case 写得太表面，而没有注意到测试细节。
比如：
操作：点击 XXXX， 结果：XXXX
这种 case 出问题的概率比较小。
如果写成
操作前执行 xxx，再点 YY，结果：ZZZZ
点击 XX 后执行 yyy，结果：ZZZZ
效果是不是会不一样的？
个人理解，大家讨论。
这涉及到了测试用例粒度的问题。
如果测试用例只覆盖了主流程，这些是需求文档表述的最浅显的，如果这都达不到，一般来讲也不会达到测试的入口准则，也就不能提测了。
所以问题更多的应该是细化测试用例，更多的关注需求细节以及需求没有覆盖到的细节。
一些常见的测试用例编写方法提到的边界值、等价类等，其实还是有很大价值的，设计测试用例的时候，也可以使用，而不仅仅只是测试文本域使用。
另外为什么自由发挥找到的 bug 比较多，这个其实也能总结出经验，填补进测试用例中。
我这边主要做服务端的， 我们会拿测试脚本加 jacoco 进行 CASE 分析，可以有效的检查用例的有效性及覆盖度。
但 ui 这块以前我是先根据需求，只做主体流程用例，剩下的就探索测试了，但这个也要看公司吧，有的公司就以用列数量为产出物。。。。
除了主流程案例可以结合业务实际场景多设计异常场景，尤其是一些场景的组合，或者设置特殊的前置条件，这类比较容易测出缺陷，这种要对业务比较了解，主流程案例一般测个几轮大多都会解决了，很多功能测试也能拿不错的工资价值也就在这里了
如果只是点点点肯定基本与产品一样；需要细化测试类型，比如 接口 后端 前端 api 性能 安全 ；当然还要根据不同产品 不同团队的现状做调整。
个人认为，测试用例的首要目的不是找到各种刁钻的 bug，而是保证产品的功能或者流程能按照预期的要求实现。
用例执行后找到的 bug 数量，并不能作为用例有效性高低的判断，而是开发质量的直接提现。比方说开发质量非常高，你用例写的再细在全面，找不到几个 bug 也很正常。
“测试用例写了一大堆，执行用例后没找到几个 bug，太费时费力，还不如拿到产品后自由发挥测试找的 bug 多”，这话只能说明，用例的覆盖度不够，简而言之，测试用例写的不全面，有遗漏。你应该思考的是如何提高测试用例的覆盖度。
自由测试我们也叫随机测试，是在基本功能、流程、用户体验等测试都没什么大问题之后才进行的测试。随机测试也偶尔能发现一些常规用例无法发现的特定环境下的问题，但数量一般不多，bug 的价值也相对较低，不建议在此阶段花费太多时间和精力。
设计测试用例的目的是发现 BUG?那测试人员不能发现 BUG 就没价值？有意思。
有用例的测试是有设计的测试，发现问题绝对比你自由发挥点点点的概率要大
设计和编写测试用例是很耗时的，但是你写完的测试用例并不是用完就作废了，它是可以在后续的版本里面复用的，所以长期来看，它的投入产出比是很高的
测试是一个完整的活动过程，测试设计和测试执行不应该割裂来。并且执行的时候决不能就照着用例来，不动脑子。如果不动脑子的话，写好测试用例发现 bug 的比率不如 free test 的五分之一（原来做过一个上千用例级别的试验）。
测试用例的主要作用应该是：辅助人脑做备忘，启发测试人员，而不应该是操作手册。 强推一本书，看看这个作者是怎么说的，能够很好的回答你的问题。 http://www.thetesteye.com/papers/TheLittleBlackBookOnTestDesign.pdf
没错，明知没用还继续做，掩耳盗铃是测试界一大通病。
老式的测试用例设计已经过时，不过大多数人还在拒绝这一点。写出详细的测试用例本身注定了就是一个低效的活动。
看过许多人写的用例，发现很多人的用例都是静态的，比如说测列表，就写多少条数据躺在那，然后打开查看比对数据。
现在应该更多的是写交互，而且应该从开始写到结尾，比如你做了一个操作，列表怎么变，会给前端带来哪些影响。交互里面的 bug 是最多的
最喜欢有效这种话题了，有效的本质是有比较性，测试也是分和之前比，和测试后比。
从事前用例的角度来说，如果每次执行的用例都是不变的，那么这个同学本身发现 bug 的概率就是低的。所以当业务耦合，系统耦合发生时用例一定是变的。所以之前的误区就是用例本身是不变的，至少每个版本测试用例是肯定需要变化的。
而如何更有效那就得从业务及代码的角度来看了，之前提到的提高用例覆盖率，接口测试是不错的点。
比如做单接口覆盖 (容错，模糊)，当单接口覆盖完了基本可以区别之前的业务测试用例哪些是有效，哪些是不重要的了。
从事后的角度来说，漏测分析非常有必要。将漏测的或者监控到的线上 bug 统一起来分析自己的用例并补全。
另外用例有效性一定不是 okr 的指标。测试只有一个指标 － 线上质量
之前有次经历还有印象：
有时候在 Web 上正常操作会碰到 CRSF 错误和 Cookie 过期两个问题，没找到稳定重现方法。
想了想 CRSF 的原因，觉得可能和多浏览器，多标签，多终端有关，按这个思路测试，仍然没重现，却发现三个其他功能点在这种场景下的缺陷。
那先查 Cookie 过期吧，想到 App 没有碰到同样的问题，仔细对比在 Web 和 App 上登录状态有关的请求，对着文档一个字段一个字段看，发现登录请求中有个字段没有必要再使用了，在新的系统设计里虽然没有直接害处，但本着 “冗余会在未来坑你” 的想法也提了个缺陷。
对着两边的抓包记录，注意到 Web 比 App 多了 longpulling，每个浏览器标签有一个，而且响应时间不稳定，有时会超过 5 秒。联想到异步，两个标签，在这 5 秒内一个退出登录会怎么样？
之后重现了一个问题，开发同事修复的时候发现另一个也是同样的原因，取决于两个异步请求处理的先后。
还没完，退出登录很少被用到，所以过期时间的功能可能有问题……
周小丽
回复
具体到这个问题，表述的过于简单了，开始只有 “冗余会在未来坑你” 这个想法，找相关同事讨论了下，设想了几个可能被坑的场景之后才提的。提了之后开发那意见也不一致，不过这个问题最后是改了，其他问题也有碰到最后不改的。
有 “代码洁癖” 的人也有，这时候也不用费劲去设想那个会有严重后果的场景了。