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