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