这些天招了新人，新项目紧张的测试告一段落，我也开始为功能写用例。
一段时间不写了，写起来有点生疏，但是思路还很清楚。写到一半收到新人写完发过来的用例。
我一看就懵了，哥您这用例根本就是直接拷策划案啊，跟策划案都一样还要你这用例干嘛。
我一下就觉得这哥们是不是糊弄事儿，后来我把他叫过来聊了聊，发现不是，是他就觉得用例就该是这样。
在之后不断教他和反复修改用例的过程中，我也同时开始不断审视用例到底该写到什么程度。
首先，先说用例的目的是什么？
用例的主要目的是让可以将每一条需要测试的点都想清楚明白，其次让你测试的覆盖面尽量广，并且通过书面的形式记录可以减少遗漏。
目的清楚了那要写到什么程度去达到这个目的就轻松多了。
再回答这个问题，测试用例要详细到什么程度？
有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。
另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。
实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。
举个例子："用户登陆系统"的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况，如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。
另一个影响测试用例的就是组织的开发能力和测试对象特点。
如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。
因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。
最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。
以下可做参考：
1.将每一个功能点分解成可以进行测试（需要写明可操作的步骤）的测试点
2.用例每一条都是一个测试点，不要将多个测试点写到一个用例里
3.无法测试的点需要提出与程度沟通定出解决方案（做GM命令，改数据库等）
只有清晰明确了，用例才能帮助你进行全面的测试。
同时用例也是考察技术基本能力重点之一，因为用例实际就是你怎么测的思路的表现，我不可能站在你身边看你怎么测，我只能通过用例去看，如果用例写的不好，那这个测试员我只能说我可能也不会太看好。
总结：
感谢每一个认真阅读我文章的人！！！
作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。