背景
最近面试了几个人，问了一些关于测试用例的问题，但是基本上没有能回答的让我满意。作为一个测试人员，测试用例的编写绝对是非常重要的技能。别小看测试用例，小小的用例里面包含了大大的只会。
测试用例
毫无疑问，测试用例的编写是一个测试人员的基本功，无论做什么方式的测试，都离不开测试用例，一份好的测试用例能够在测试执行过程中给予非常好的指导意义。
测试用例的产出一般来说，是根据产品（业务）的需求分析后得出测试需求，再根据测试需求进行细分，得到测试用例。这中间的学问就非常大了。
测试设计
软件测试的目的就是保证软件的质量，漏测是最大的忌讳，因此在测试设计过程中，如何防止设计遗漏是非常关键的。产品（业务）的需求对功能上描述是比较清晰的，按照功能来设计，只要设计的方法正确，那么功能上基本不会有问题。但是这仅仅是从业务的角度来分析问题，还需要分析开发的设计文档，根据开发的设计，适当的补充一些需求文档上没有覆盖的点。最后，还需要用自己的经验做一些探索性的测试用例。
所以一个好的测试设计应该包括以下几个部分：
- 业务功能的覆盖
- 开发设计中针对业务功能的补充
- 某些专题模块的单独测试
- 工作经验的探索设计
测试用例的颗粒度
这个问题在早期工作中有专门尝试过，不同的设计方式对后续的维护以及执行影响非常大，因此在项目的初期就要想好用例设计的颗粒度。在网上看了一些文章，对于这点的理解都不深，我简单列一下，不同颗粒度的优缺点如下：
粗颗粒度
优点
- 设计的周期短
- 可维护性强
- 能够快速的应对频繁变更的需求
- 执行时灵活度高，能够有效的调动执行人员的积极性
- 占用测试资源少，少量的人员花费少量的时间即可完成
缺点
- 漏测的可能性高
- 项目质量过于依赖测试人员的职业素养
- 用例数量少
适用场景
粗颗粒度的测试用例相对适合小团队适用，人少，时间短，而且能够快速的相应变化的需求。当然，缺点也是非常明显的，没有了详细的测试用例的束缚，每个点的质量就非常依赖测试人员的素质，需要测试人员有很高的职业道德，并且对于业务的理解程度，系统的架构的熟悉程度都有很高的要求。
在大项目中也并不是不能使用，我曾经在项目中这么干过，说实话，效果还不错，在大项目中，开发人员数量多，对于业务的理解也是参差不齐，很有可能他们没有按照约定的方式进行实现，而这种情况在大项目中会导致大量的测试用例需要维护，而粗颗粒度的设计，能够低成本的快速响应这些变化。
我在缺点中的列的用例数量少，不是开玩笑随便列的。一般来说要拿资源都是以数据说话，测试用例数量少就意味着，你的谈判筹码就少，能申请到的资源也就少，但是在项目不减少的情况下，工作量是固定的，因此每个人的工作量就会相应的增加，这也是进行粗颗粒度拆分时需要注意的地方
细颗粒度
优点
- 漏测的可能性小
- 风险左移，对于管理者来说容易把控
- 用例数量多，利于申请资源
- 不依赖测试人员的综合素质
- 能够针对测试用例提前准备大量的测试数据
缺点
- 测试设计的周期长
- 可维护性极弱
- 执行束缚大
适用场景
细颗粒度的好处也显而易见，能够把所有风险集中到设计阶段，对于管理者来说省了非常大的精力来做其他事，但是由于精细的设计，导致小团队没有很多的资源往测试设计中投入，因此细颗粒度的设计比较适合大团队，对于测试人员的要求非常低，即使是刚入职的新人也能够快速的上手进行测试。在测试颗粒度细的情况下，能够非常清晰的了解将来执行阶段需要使用的数据，环境等资源，因此能够将数据提前准备，这将极大的减少测试执行阶段的时间。
当然，缺点也是显而易见的，需求做一点变更或者开发不老实一点，马上就会血崩，案例维护的成本非常之高，尤其是大项目的用例，维护起来非常的折磨人。而且在执行过程中实际结果和用例产生一点偏差，都会让执行人员非常的尴尬。
总结
总结了那么多内容，都是一些理论，在实际的工作中是可以穿插起来进行的。测试用例的颗粒度在一个项目中是可以共存的，并不是所有的用例都要粗或者都要细，可以根据自身的情况做一些调整，比如按照业务进行拆分的时候，可以把自己熟悉的业务做粗颗粒度的编写，变化非常小的部分做细颗粒度的编写，提前做好分工的情况下，根据不同执行人员的素质也可以做颗粒度的拆分。理论知识永远是死的，人才是活的，根据自己的实际情况合理的利用理论知识才是自我提升的途径。
