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

    在聊测试用例是否需要编写时，我们先聊聊大多互联网公司的研发流程，基本上简单说就是：产品经理编写需求=>产品、研发、测试等进行需求评审=>开发设计，编码，同时测试编写用例并评审=>开发提交测试=>测试执行测试=>产品发布。 这是个大体的流程，当然每个公司会根据自己的情况做一些调整，更加符合自己的团队，并随着项目的进行不断的进行总结，调整，好的团队还会尽可能的把测试提前。

    从大体流程晓得，测试编写用例是在需求评审结束，项目立项后，那这个测试用例编写是否真的是必须的呢？

    就个人观念看：测试用例的编写是必须的！ 很多测试人员会觉得测试用例的编写是很浪费时间，因为最后提交测试执行时很难按照预先编写的测试用例执行。

    测试很难按照预先编写的用例执行，个人觉得最主要的原因是：在需求评审阶段没做好或者根本就没有做需求评审，造成开发，产品和测试三者之间没有对需求达成一致的理解，也可能需求不完善，不明确，有疑问点等，在编码过程中还在不停的变更需求。

    但是我并不以为这是不可控的，至少可以控制在可接受范围内，这里可能又得花费很多时间去聊需求评审的必要性和重要性，明显不是我们现在想要聊的内容。

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

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

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

    然而在大多数互联网公司，基本都走敏捷，讲究小步快跑，快速试错，基本上产品迭代非常频繁，就像我目前所在团队基本两周一个迭代，这给我们测试留下的执行测试的时间就极短，更别说写用例的时间，这时我们就不得不在某种程度上做个妥协，简化测试用例，不再对每一条用例做详细描述，或者说我们更多的是写测试点。然而这里还是建议遇到比较复杂的流程时，还是能尽可能用例描述详细。测试点不表示不需要考虑各种用户场景，而是尽可能通过一句话能描述出这个场景的概要，这样测试人员在了解需求的前提下通过这么一句话概要就可以清楚知道需要执行哪些用例，这对测试员的要求会相对更高点。

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

    其实我个人很喜欢在编写用例之前和准备执行测试时，找开发聊聊开发是准备如何实现和现在是如何实现这个功能。通过个人的积累发现，跟开发聊实现很容易从开发的设计中你可以把握到测试的注意点，并记录体现在用例中。例如Ａ开发曾经用某种方式做了ａ功能，出现了某个bug,现在B开发用了同样方式实现，那么极有可能之前的bug这次还会出现。

    产品走迭代，测试用例同样也需要迭代。我目前的团队这个做的不好，而之前我自己带的团队一直很注重这块。这就关系到测试用例的管理，我当前所在的团队，每个迭代都会新启用一个文档去记录你的测试用例，这样这份测试用例上你只能看到这个迭代的修改和新增，而无法查看到该模块没变化的用例，或者说根本无法拿出一份完整的测试用例，有时开发问起某个开发已久的功能逻辑时，测试甚至都没办法找到这个功能模块的用例从而去推断当时的逻辑。而如果用例走迭代，每个新迭代都居于上个迭代的用例上做增删改。例如假设我通过excel来管理我的用例，那么我每次新迭代开始时，我就复制一份旧的用例，居于复制而来的用例上做修改形成最新版的测试用例，这样我既能保留以前迭代的测试用例（可便于功能回溯），又可以有一个完整的当前系统的测试用例。

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