测试用例该爱该恨？

前言
无论是在传统软件公司还是互联网公司，测试用例的设计和编写一直是测试人员不可或缺的基本工作。但在是否需要编写测试用例和编写测试用例粒度问题一直有着争论和探讨。

项目基本流程

在聊测试用例是否需要编写时，我们先聊聊大多互联网公司的研发流程，简单说就是：

产品经理编写需求=>产品、研发、测试等进行需求评审=>开发设计，编码，同时测试编写用例并评审=>开发提交测试=>测试执行测试=>产品发布
　　
这是个大体的流程，当然每个公司会根据自己的情况做一些调整，更加符合自己的团队，并随着项目的进行不断的进行总结，调整。

用例编写与执行阶段

从大体流程晓得，测试编写用例是在需求评审结束，项目立项后，那这个测试用例编写是否真的是必须的呢？
　　
就个人观念看：测试用例的编写是必须的！很多测试人员会觉得测试用例的编写是很浪费时间，因为最后提交测试执行时很难按照预先编写的测试用例执行。
　　
测试很难按照预先编写的用例执行，个人觉得最主要的原因是：在需求评审阶段没做好或者根本就没有做需求评审，造成开发，产品和测试三者之间没有对需求达成一致的理解，也可能需求不完善，不明确，有疑问点等，在编码过程中还在不停的变更需求。

即使有详细的需求评审流程，但是往往测试人员在去编写测试用例时，为了使用例能尽可能的覆盖到更多的测试点，会不停的从各种角度的去理解需求，常会发现需求的一些遗漏点，疑问点，然后通过及时的沟通，可以及早的发现问题，减低研发过程的风险，减少用例编写完到最后执行用例期间变动，这样编写用例的过程反而有助于测试理解需求。

编写用例的好处

编写用例很大的好处就是避免盲目的执行测试。用例就好像是一本剧本，测试员可以根据剧本的设定能对被测系统做到较为全面的测试。

用例粒度

用例粒度好比一个剧本，写细了容易束缚了表演者的自我发挥，写粗了又担心表演者遗漏某些重要环节。
　　
如果你是一家传统软件公司，一个项目可能几个月甚至半年、一年才一次交付，那么你拥有充足的时间去设计你的测试用例，那么我建议你的用例能尽可能描述详细，不停的修复、补充、完善。

然而在大多数互联网公司，基本都走敏捷，讲究小步快跑，快速试错，基本上产品迭代非常频繁，譬如一个公司的产品两周一个迭代。
　　
这给我们测试留下的执行测试的时间就极短，更别说写用例的时间，这时我们就不得不在某种程度上做个妥协，简化测试用例，不再对每一条用例做详细描述，而更多的是写测试点。

遇到比较复杂的流程时，还是希望能尽可能将用例描述详细。测试点不表示不需要考虑各种用户场景，而是尽可能通过一句话能描述出这个场景的概要，这样测试人员在了解需求的前提下通过这么一句话概要就可以清楚知道需要执行那些用例，这对测试员的要求会相对更高点。

用例模块化

用例写多了，总会发现很多功能模块是类似的，例如查询功能，翻页功能，文本框校验，时间控件校验等等，这时可以学学编程思路，某段代码多处用到，那么就提取成一个公共方法，供各个地方调用。同样编写测试用例时，你也可以提取类似的测试用例，形成一个用例库，供相同的功能模块引用。

用例迭代

用例走迭代，每个新迭代都居于上个迭代的用例上做增删改。例如假设我通过excel来管理我的用例，那么我每次新迭代开始时，我就复制一份旧的用例，居于复制而来的用例上做修改形成最新版的测试用例，这样我既能保留以前迭代的测试用例（可便于功能回溯），又可以有一个完整的当前系统的测试用例。

总结

用例评审也是非常必须的，特别是一些经验老道或者业务熟悉的老司机，可以在用例评审上快速的帮忙指出用例的遗漏点，有助于测试人员打开思路，尽可能多的覆盖用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来，结束后及时找相关人员确认，避免猜测。

软件测试交流群：785128166

微信公众号：程序员二黑；关注后可免费领取一套视频资源；详细讲解了：python自动化测试、web自动化、接口自动化、移动端自动化、面试经验等相关内容，学习资源的价值取决于你的行动，莫做“收藏家”

下篇更新：测试用例的思路分析

功能测试精选干货文章合集点这：

干货分享 | 功能测试精选文章合集（你还怕找不到自己需要的文章吗？）