如何确保测试的深度与广度，怎样去提升？？一个好的用例是否能很好的体现？？

测试用例的重要性，其实多年未变！

他是要用测试用例来保障基本质量的，至于发散思维 场景法等，其实多数都是考虑的异常，就是在基本质量的基础上进行优化，保证更好的体验！

很重要啊，之前有个帖子，测试用例重要到公司还要根据测试用例数考核

先回答：重要。抛开业务覆盖率谈测试用例都是耍大刀，好的测试用例可以让你用更有限的资源去实现产品质量最大化的提升，测试本身就是一项有风险的软件活动，所以要和你的测试的业务需求挂钩，核心业务还要细细咀嚼，发现其隐形的测试需要，如：人员，环境等。现在有的公司敏捷大行其道，只写测试导图不写测试用例，其默认参与到敏捷的测试人员本身素质是很高的，是业务上的专家，而且可以充当万金油的角色：项目管理，研发内部调节，需要明确与改进，自动化/性能开发等。这也是我等测试人员的价值体现。我有见过把整个 UI 扒下来遍历控件写用例的公司，那用例数很酸爽。

谢谢点名。

什么是好的测试用例？对于质量的角度来说，覆盖率越全的越好，但是对于回归用例来说，我推荐能发现 bug 的用例就是好用例。

你质疑用例的有效性问题，我理解的是用例设计不到位，才会导致很多 bug 不是通过用例发现的，那么除了发现 bug 外，我们更应该提升我们的用例设计能力，毕竟谁也不会做一辈子执行，不执行就发现不了 bug（保证不了质量），这说不过去吧？

更详细的观点请参考：
到底要不要写测试用例看这篇
通过 bug 来完善自己测试用例设计思路看这篇
怎么体现测试用例的深度看这篇

我的观点：
测试其实是门艺术。
测试用例只是方式方法，测试真正要做好，技术，产品理解，场景，人缺一不可。

楼主可以分享分享几次线上事故带来的反思，讨论也会比较热烈

测试用例的作用，我觉得重要的地方有三个：
1、可以说明一轮测试的结束，如果一直发散，那么你永远没办法说测试完成，永远没有上线的时间
2、更早的发现需求设计漏洞，我相信在写用例的时候一定会发现需求设计漏洞
3、测试发散思维的基点，先脑图，在写用例，相信写用例的时候会有很多补充，所以在用例的基础上发散，会扩散的更远。

测试一切的基础，重中之重。

更多是是领导量化统计你的工作而已 不然没人知道你干了多少活 或者现在测试进度是多少了 。

其实很多小公司都是上手直接点点点。包括我在最近的一个公司也是如此。但是测试用例个人觉得依然重要。它可以体现测试人员的工作输出。可以监督测试人员的测试执行，避免漏场景，不至于后面出现问题跟开发扯皮落入下风。
至于用例如何写得好，这个实在是个大学问。以至于每次面试我都害怕面试官问我用例设计。每次觉得用例不久那样，点着点那，看实际结果跟预期结果对不对。但是面试的时候，你总会被问得怀疑人生，为什么我之前没考虑得这么多。。。

https://testerhome.com/articles/16793 参考下这个。

工具类和功能测试本来就相辅相配合的，工具类完成了多少标记给功能测试，让功能测试时间投入更重要事情上去。
自动化和接口的用例依据也是根据功能测试用例去写，两者如果分开和水中捞月一样。

重要 测试过程有个依据 以后跟踪起来也方便。 还有一个更重要的功能，甩锅，出现了问题 用例里没有就是测试的锅，就算是咖啡厅里跟老板要炒米粉然后咖啡厅爆炸了的操作，也是测试没测到。

测试用例很重要，但是在形式上不能太重了。目前情况下，大部分公司的迭代都是比较快的，维护测试用例的成本显得就比较高了。个人认为，除了核心功能和较大迭代需要维护测试用例，其他小的功能和优化迭代只要准备测试点或一两条功能用例进行维护就可以了。

嗯嗯，这个我认同，目前好多都是形式化，反而真正操作确是探索性的

编写测试用例的同时，也是熟悉需求的过程，这个过程可以发现需求中遗留、不合理的地方

测试用例是基础，每个测试都需要先打好基础。。。当打好基础以后，再结合 case 和 bug 的发生规律，会有一些感想，未来的路上，找 bug 的速度会变的相当快~（也就是说，可以做到，几乎知道 bug 在哪里）

人是比较健忘的，用测试用例来执行主要是不会重复劳作