测试用例必要性个人觉得有几点可以作为参考：1、方便整理测试思路，并不是所有的需求要点都会体现到需求文档上面，所以有很多要点是需要做需求分析的时候去进行功能补充，还有就是有些设计可能是似是而非的，还得设想程序端逻辑实现，进行相关测试验证和环境相关的准备 2、方便后期版本维护和回归 ，特别是需求改动多的模块，没有老版本对比很伤 3、方便他人接手，节省二次需求分析时间。测试用例反馈出来的不就是测试流程覆盖的过程么，小体量的功能模块 ，可以通过经验临时去覆盖测试，但是对于大体量的功能，没有用例做参考，或许回过头来 你都不知道自己测试执行到哪一步了

其实你啥都懂，只是觉得自己写出的 case 不好，然后自我怀疑？

第一个点的话，其实是基于你对被测系统的熟悉程度的，我是专门做电商活动的，公司内产品提出需求我就能直接告诉他这个功能以前做过没，在哪做过，相关的数据有没有，去哪拉取，是新功能的话需要调用那些模块来做会比较简单方便，怎么做。这一块的话，你对每个模块都熟悉，测试也可以做到任务的需求 owner，虽然技术可能不懂，但是你比开发懂业务，比产品懂技术，多尝试负责更多的东西，长久之后就会发现，你会有更多收获的，我平时工作基本就可以做到听了需求再听听开发怎么做就可以提前预估出哪些地方会有 bug，那些地方设计和实际是不符合的。

感谢回答。思路非常清晰，也具有可操作性。
只是我觉得第一点说着比较简单，但是实际上工作量会比较大。要和产品对需求，要和开发了解业务模块和接口，这块要求产品和开发提前有高质量的输出物（需求文档、开发文档）才可以。

大概分享一下我的经验吧，从需求分析到测试完成的整个流程，怎么样做到快速，全面的完成测试工作。
第一点：快速理解需求背景，基于对被测系统的了解情况下判断该需求会调用那些业务模块，相关的接口以及实现方法。
第二点：编写思维导图，基于对业务的理解下，对整个业务逻辑进行分析，是否存在漏洞以及符合预期，有一个比较好的方法就是提前罗列出所有的因素，对每一个因素进行分析，防止因为某些特殊因素导致漏测。
第三点：编写测试用例，设计测试数据，提前设计好测试数据能大幅提高测试效率，设计测试用例时有一个比较重要的点就是对整个思维导图及需求文档进行分析，对细节点进行补充。
第四点：提测，快速把握所有关键点的诀窍在于，对每一个操作都抓包先观察一遍，花上几分钟。软件即数据，把数据流转的过程理清楚了就不怕代码上线了有什么幺蛾子。同时也方便定位 bug

也非常感谢推荐的书籍，另外一位同学也推荐了一本书，都是非常知名的书。但是全部都是脱离了业务单纯的讲测试，我并不喜欢这类书（可能是我理解的不够吧），我觉得都是在讲理论，太脱离实际了。没有看到一本书是教测试人员如何更好的去了解业务的，去熟悉开发用到的技术。假如我拿到一个测试购物商城的需求，与其看那些方法论，我还不如找一个竞品，去淘宝，京东上面看看人家是怎么做的，我觉得这样更有助于发现问题，提升质量。不是说方法论不好，是觉得大家都在说方法论，有点脱离现实了。

根本原因是我觉得写测试用例没有意义，最多是让自己熟悉需求，提醒自己不要有遗漏点，但是现在都敏捷开发了，周一分配了任务，周二就有任务需要测试了，写用例的时间也压缩了。

做事就怕迷茫，既然已经写了很多的用例，说明经验比较丰富了，这个时候能不能将之前写的用例总结出一套方法论来呢，有相应的设计方法（功能，效率，易用，健壮等），及评估用例的标准（需求覆盖，流程覆盖，语句覆盖等），推荐微信上一本书，测试架构师，希望能帮你走出迷茫

推荐一本书《探索吧》https://item.jd.com/11407168.html

建议用思维导图的方式列大纲，再逐层细化。会看到很多忽视的点，产品基本不会从代码层面考虑问题，这就是测试需要补上的。

测试用例肯定不是需求文档复制粘贴一遍啦，不然为啥会有 正向 反向 异常 临界 错误猜想 五类 case 的说法？测试方向也分很多种啦，业务类测试（金融对这方面要求更高），数据类测试（数据挖掘，数仓对这方面要求更高），技术类测试（高科技互联网，集成电路等对这方面要求更高），用户体验类测试（游戏方向对这方面要求更高），每种类型做到极致都是不容易的。。楼主想成为哪方面的测试？如果找准自己的定位，这 3 个问题就有答案了

用例是什么？测试过程中测试执行的依据，你的领域知识 + 测试思维的结合，是包含了需求，且不仅限于需求内容的。
目的是什么？让测试执行能证明哪些 OK，有哪些不 OK，最终帮助决策。
如何写好？想的比产品多和远，了解过开发的水平，熟悉用户的习惯，测试基础扎实，整个研发流程正规，不偷懒时间充足。用例想写不好都难。当然，再好的用例也要根据实际情况来，不适宜的好用例也谈不上多好。

感谢回复，非常有收获。

所以需要方法，等价类、边界值是最常用的，其它流程图、因果判定法等等有时候也需要用到。再就是结合实际场景去考虑一些 “坑” 点

好观点

个人觉得，测试用例的编写需要常常提醒自己 “不是写给自己看的” 这个观点