测试用例

转自：https://testerhome.com/topics/7943

测试用例
测试用例的产出一般来说，是根据产品（业务）的需求分析后得出测试需求，再根据测试需求进行细分，得到测试用例。

测试设计
软件测试的目的就是保证软件的质量，漏测是最大的忌讳，因此在测试设计过程中，如何防止设计遗漏是非常关键的。

产品（业务）的需求对功能上描述是比较清晰的，按照功能来设计，只要设计的方法正确，那么功能上基本不会有问题。但是这仅仅是从业务的角度来分析问题，还需要分析开发的设计文档，根据开发的设计，适当的补充一些需求文档上没有覆盖的点。最后，还需要用自己的经验做一些探索性的测试用例。

所以一个好的测试设计应该包括以下几个部分：
业务功能的覆盖
开发设计中针对业务功能的补充
某些专题模块的单独测试
工作经验的探索设计

测试用例的颗粒度
不同的设计方式对后续的维护以及执行影响非常大，因此在项目的初期就要想好用例设计的颗粒度，不同颗粒度的优缺点如下：

粗颗粒度
优点：
设计的周期短
可维护性强
能够快速的应对频繁变更的需求
执行时灵活度高，能够有效的调动执行人员的积极性
占用测试资源少，少量的人员花费少量的时间即可完成

缺点：
漏测的可能性高
项目质量过于依赖测试人员的职业素养
用例数量少

适用场景
粗颗粒度的测试用例相对适合小团队适用，人少，时间短，而且能够快速的相应变化的需求。当然，缺点也是非常明显的，没有了详细的测试用例的束缚，每个点的质量就非常依赖测试人员的素质，需要测试人员有很高的职业道德，并且对于业务的理解程度，系统的架构的熟悉程度都有很高的要求。

在大项目中也并不是不能使用，我曾经在项目中这么干过，说实话，效果还不错，在大项目中，开发人员数量多，对于业务的理解也是参差不齐，很有可能他们没有按照约定的方式进行实现，而这种情况在大项目中会导致大量的测试用例需要维护，而粗颗粒度的设计，能够低成本的快速响应这些变化。

我在缺点中的列的用例数量少，不是开玩笑随便列的。一般来说要拿资源都是以数据说话，测试用例数量少就意味着，你的谈判筹码就少，能申请到的资源也就少，但是在项目不减少的情况下，工作量是固定的，因此每个人的工作量就会相应的增加，这也是进行粗颗粒度拆分时需要注意的地方

细颗粒度

优点：
漏测的可能性小
风险左移，对于管理者来说容易把控
用例数量多，利于申请资源
不依赖测试人员的综合素质
能够针对测试用例提前准备大量的测试数据

缺点：
测试设计的周期长
可维护性极弱
执行束缚大

适用场景
细颗粒度的好处也显而易见，能够把所有风险集中到设计阶段，对于管理者来说省了非常大的精力来做其他事，但是由于精细的设计，导致小团队没有很多的资源往测试设计中投入，因此细颗粒度的设计比较适合大团队，对于测试人员的要求非常低，即使是刚入职的新人也能够快速的上手进行测试。在测试颗粒度细的情况下，能够非常清晰的了解将来执行阶段需要使用的数据，环境等资源，因此能够将数据提前准备，这将极大的减少测试执行阶段的时间。

当然，缺点也是显而易见的，需求做一点变更或者开发不老实一点，马上就会血崩，案例维护的成本非常之高，尤其是大项目的用例，维护起来非常的折磨人。而且在执行过程中实际结果和用例产生一点偏差，都会让执行人员非常的尴尬。