- 📢专注于分享软件测试干货内容，欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
- 📢交流讨论：欢迎加入我们一起学习！
- 📢资源分享：耗时200+小时精选的「软件测试」资料包
- 📢 最困难的时候，也就是我们离成功不远的时候！
目录
- ———来自研发大佬的近期自述：
- 首先，先说用例的目的是什么？
- 再回答这个问题，测试用例要详细到什么程度？
- 最后
———来自研发大佬的近期自述：
这些天招了新人，新项目紧张的测试告一段落，我也开始为功能写用例。
一段时间不写了，写起来有点生疏，但是思路还很清楚。写到一半收到新人写完发过来的用例。
我一看就懵了，哥您这用例根本就是直接拷策划案啊，跟策划案都一样还要你这用例干嘛。
我一下就觉得这哥们是不是糊弄事儿，后来我把他叫过来聊了聊，发现不是，是他就觉得用例就该是这样。
在之后不断教他和反复修改用例的过程中，我也同时开始不断审视用例到底该写到什么程度。
首先，先说用例的目的是什么？
用例的主要目的是让可以将每一条需要测试的点都想清楚明白，其次让你测试的覆盖面尽量广，并且通过书面的形式记录可以减少遗漏。
目的清楚了那要写到什么程度去达到这个目的就轻松多了。
再回答这个问题，测试用例要详细到什么程度？
有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。
另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。
实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。
举个例子：“用户登陆系统”的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况，如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。
另一个影响测试用例的就是组织的开发能力和测试对象特点。
如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。
因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。
最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。
以下可做参考：
1.将每一个功能点分解成可以进行测试（需要写明可操作的步骤）的测试点
2.用例每一条都是一个测试点，不要将多个测试点写到一个用例里
3.无法测试的点需要提出与程度沟通定出解决方案（做GM命令，改数据库等）
只有清晰明确了，用例才能帮助你进行全面的测试。
同时用例也是考察技术基本能力重点之一，因为用例实际就是你怎么测的思路的表现，我不可能站在你身边看你怎么测，我只能通过用例去看，如果用例写的不好，那这个测试员我只能说我可能也不会太看好。
最后
如果你想学习自动化测试，那么下面这套视频应该会帮到你很多
如何逼自己1个月学完自动化测试，学完即就业，小白也能信手拈来，拿走不谢，允许白嫖....
最后我这里给你们分享一下我所积累和整理的一些文档和学习资料，有需要直接领取就可以了！
以上内容，对于软件测试的朋友来说应该是最全面最完整的备战仓库了，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。
