做了多年测试，写了很多的测试用例，却对如何写测试用例越来越迷糊了。感觉自己写测试用例就是把需求文档翻译一下，需求文档越详细，我的测试用例就越详细；需求文档如果比较粗糙，那测试用例就会比较笼统，遇到细节就只能让产品把需求文档细化一下。希望有测试大牛能给对下面的问题指点迷津：
如何写好测试用例？
写测试用例的目的是什么？
测试用例是什么？
1.第一个问题：如何写好测试用例？首先我觉得要理解透需求文档内容，知道被测产品大概是什么样子，看看是否有同类竞品参考；其次可以多和产品人员沟通，在需求理解过程有疑问的地方重点标识，明确被测点。写用例，依据需求文档，但不能纯粹的翻译需求文档，对被测点要能够举一反三，也就是正常、异常多种用例点，这样才能尽可能的覆盖需求；
2.第二个问题：测试用例的目的是什么？在我看来主要有 3 个目的：一是自己梳理测试需求与被测点，执行过程能够循序渐进的开展工作，做到无遗漏；二是执行便捷，即使自己没时间执行，其他同事哪怕新来的同事，按照你的用例也能够按步骤、预期完成该项测试；三是留存测试依据，说句难听点的后期项目出现线上 bug 时追溯问题根源，对比用例设计情况是自己漏测，还是其他原因导致的一目了然；
3.第三个问题：测试用例是什么？在我看来测试用例是测试过程的一个产出物，是指导测试执行的主要依据。测试用例设计质量高，能够尽可能的发现潜在问题，避免流向用户。
以上纯属个人看法，欢迎补充。
个人觉得，测试用例的编写需要常常提醒自己 “不是写给自己看的” 这个观点
好观点
1.第一个问题：如何写好测试用例？首先我觉得要理解透需求文档内容，知道被测产品大概是什么样子，看看是否有同类竞品参考；其次可以多和产品人员沟通，在需求理解过程有疑问的地方重点标识，明确被测点。写用例，依据需求文档，但不能纯粹的翻译需求文档，对被测点要能够举一反三，也就是正常、异常多种用例点，这样才能尽可能的覆盖需求；
2.第二个问题：测试用例的目的是什么？在我看来主要有 3 个目的：一是自己梳理测试需求与被测点，执行过程能够循序渐进的开展工作，做到无遗漏；二是执行便捷，即使自己没时间执行，其他同事哪怕新来的同事，按照你的用例也能够按步骤、预期完成该项测试；三是留存测试依据，说句难听点的后期项目出现线上 bug 时追溯问题根源，对比用例设计情况是自己漏测，还是其他原因导致的一目了然；
3.第三个问题：测试用例是什么？在我看来测试用例是测试过程的一个产出物，是指导测试执行的主要依据。测试用例设计质量高，能够尽可能的发现潜在问题，避免流向用户。
以上纯属个人看法，欢迎补充。
所以需要方法，等价类、边界值是最常用的，其它流程图、因果判定法等等有时候也需要用到。再就是结合实际场景去考虑一些 “坑” 点
用例是什么？测试过程中测试执行的依据，你的领域知识 + 测试思维的结合，是包含了需求，且不仅限于需求内容的。
目的是什么？让测试执行能证明哪些 OK，有哪些不 OK，最终帮助决策。
如何写好？想的比产品多和远，了解过开发的水平，熟悉用户的习惯，测试基础扎实，整个研发流程正规，不偷懒时间充足。用例想写不好都难。当然，再好的用例也要根据实际情况来，不适宜的好用例也谈不上多好。
测试用例肯定不是需求文档复制粘贴一遍啦，不然为啥会有 正向 反向 异常 临界 错误猜想 五类 case 的说法？测试方向也分很多种啦，业务类测试（金融对这方面要求更高），数据类测试（数据挖掘，数仓对这方面要求更高），技术类测试（高科技互联网，集成电路等对这方面要求更高），用户体验类测试（游戏方向对这方面要求更高），每种类型做到极致都是不容易的。。楼主想成为哪方面的测试？如果找准自己的定位，这 3 个问题就有答案了
建议用思维导图的方式列大纲，再逐层细化。会看到很多忽视的点，产品基本不会从代码层面考虑问题，这就是测试需要补上的。
推荐一本书《探索吧》https://item.jd.com/11407168.html
根本原因是我觉得写测试用例没有意义，最多是让自己熟悉需求，提醒自己不要有遗漏点，但是现在都敏捷开发了，周一分配了任务，周二就有任务需要测试了，写用例的时间也压缩了。
也非常感谢推荐的书籍，另外一位同学也推荐了一本书，都是非常知名的书。但是全部都是脱离了业务单纯的讲测试，我并不喜欢这类书（可能是我理解的不够吧），我觉得都是在讲理论，太脱离实际了。没有看到一本书是教测试人员如何更好的去了解业务的，去熟悉开发用到的技术。假如我拿到一个测试购物商城的需求，与其看那些方法论，我还不如找一个竞品，去淘宝，京东上面看看人家是怎么做的，我觉得这样更有助于发现问题，提升质量。不是说方法论不好，是觉得大家都在说方法论，有点脱离现实了。
大概分享一下我的经验吧，从需求分析到测试完成的整个流程，怎么样做到快速，全面的完成测试工作。
第一点：快速理解需求背景，基于对被测系统的了解情况下判断该需求会调用那些业务模块，相关的接口以及实现方法。
第二点：编写思维导图，基于对业务的理解下，对整个业务逻辑进行分析，是否存在漏洞以及符合预期，有一个比较好的方法就是提前罗列出所有的因素，对每一个因素进行分析，防止因为某些特殊因素导致漏测。
第三点：编写测试用例，设计测试数据，提前设计好测试数据能大幅提高测试效率，设计测试用例时有一个比较重要的点就是对整个思维导图及需求文档进行分析，对细节点进行补充。
第四点：提测，快速把握所有关键点的诀窍在于，对每一个操作都抓包先观察一遍，花上几分钟。软件即数据，把数据流转的过程理清楚了就不怕代码上线了有什么幺蛾子。同时也方便定位 bug
四海
回复
感谢回答。思路非常清晰，也具有可操作性。
只是我觉得第一点说着比较简单，但是实际上工作量会比较大。要和产品对需求，要和开发了解业务模块和接口，这块要求产品和开发提前有高质量的输出物（需求文档、开发文档）才可以。
hai
回复
第一个点的话，其实是基于你对被测系统的熟悉程度的，我是专门做电商活动的，公司内产品提出需求我就能直接告诉他这个功能以前做过没，在哪做过，相关的数据有没有，去哪拉取，是新功能的话需要调用那些模块来做会比较简单方便，怎么做。这一块的话，你对每个模块都熟悉，测试也可以做到任务的需求 owner，虽然技术可能不懂，但是你比开发懂业务，比产品懂技术，多尝试负责更多的东西，长久之后就会发现，你会有更多收获的，我平时工作基本就可以做到听了需求再听听开发怎么做就可以提前预估出哪些地方会有 bug，那些地方设计和实际是不符合的。
其实你啥都懂，只是觉得自己写出的 case 不好，然后自我怀疑？
测试用例必要性个人觉得有几点可以作为参考：1、方便整理测试思路，并不是所有的需求要点都会体现到需求文档上面，所以有很多要点是需要做需求分析的时候去进行功能补充，还有就是有些设计可能是似是而非的，还得设想程序端逻辑实现，进行相关测试验证和环境相关的准备 2、方便后期版本维护和回归 ，特别是需求改动多的模块，没有老版本对比很伤 3、方便他人接手，节省二次需求分析时间。测试用例反馈出来的不就是测试流程覆盖的过程么，小体量的功能模块 ，可以通过经验临时去覆盖测试，但是对于大体量的功能，没有用例做参考，或许回过头来 你都不知道自己测试执行到哪一步了