在设计测试用例工作中，把握测试用例粒度的粗细是件很伤神的事：测试用例写得很细，会带来很多问题：首先是效率问题，测试人员的首要任务有效地测试产品尽可能多的发现产品缺陷，如果测试用例写的过细，在设计测试用例时势必花费大量时间，这些时间中很大一部分是应该用在有效地测试产品上的；再次，测试用例设计得过于详细，测试执行人员就成了执行用例的机器，只能按照用例去操作而缺少了的思考空间，使测试执行人员的思维局限于测试用例中；还有如果这些用例还要复用在其他版本中时，产品功能稍微改动，就需要修改大量的测试用例，从而使用例的维护代价大大提高。但是测试用例写得太粗就会包含太多验证点，当用例在执行到某一个验证点时被卡住，这个用例就被标为无法通过，下面的验证点可能就不再执行，直接标记用例无法通过，同时也为定位bug增加了难度；还有测试用例粒度过大还容易遗漏测试项。下面也就小探讨一下测试用例粒度问题。

首先说下划分测试用例粒度粗细的标准

划分粒度粗细的标准是什么？什么样的用例粒度算粗粒度？什么样的粒度算细粒度？

1.一条用例的步骤：小于5步为细粒度，大于10步为粗粒度(合理吗)

2.以项目的用例个数：几百个用例为粗粒度，几千个用例为细粒度(合理吗)

3.以数据覆盖度：等价类为粗，穷举为细(合理吗)

个人感觉以上几种参考划分都有点片面，设计出何时粒度的测试用例需要根据软件的有效功能进行设计。首先说一下什么是有效功能，有效功能就是整个业务流完成一个具有实际意义的功能，任何一部分从业务流中独立出来都无实际意义。

再说一个纠结的问题，几个功能之间存在相互依赖的关系，这时候用例该怎样设计？多个功能融合在一个用例中，一个用例需要很多步骤描述，有人认为描述的步骤很多，就说测试粒度细。其实不然，这样写虽然每个步骤很多，但是想全面的写出这几个功能组合起来形成的用例几乎是不可能的，很有可能漏掉一些重要的测试点。最好的办法就是将多个相互之间存在依赖关系的功能区分为单个的有效功能。例如，现在有A、B、C三个功能，其中B功能的开始必须依赖于A功能的完成，而且A功能如果出现不同的完成状态，B功能也会做出不同的反应；C功能对B功能的依赖也是如此。我们可以发现A、B、C都是独立的有效功能，它们之间存在的依赖性，可以理解为是一种状态或者说数据的依赖性。后一个功能关心的，是前一个功能最终提供给它的是什么样的“输入”，而不是前一个功能到底作了些什么。这样看来，我们完全可以将它们分别包含在几个独立的测试用例中，而在每个测试用例的开始，把不同的输入作为不同前置条件来描述。

最后哪些因素决定了测试用例的粒度

1、时间、资源因素：

时间短、项目紧、编写用例评审时间较短时，而且人手短缺，适合粗颗粒度用例。项目周期较长时，人员配备充足，适合细颗粒度用例。

2、执行测试用例的人员：

测试人员都是思路和基础技能扎实的有多年测试经验的高手，他们都有高度的责任心而且对产品十分熟悉可以采用粗颗粒度用例。测试人员新手多，没有经验，对产品几乎不了解，需要再指导下进行基础测试工作，或责任心一般时，需采用细颗粒度用例。

下面是ls命令查看一个目录下文件的属性写给不同类型执行者的用例

写给自己看的：使用ls命令查看该目录下文件的属性

写给稍微有点基础的人看：打开终端，使用“ls -l

目录路径”，查看该目录下文件文件属性

写给linux盲看的：点击桌面上的终端图标，打开终端，在终端中输入

“ls -l /../../目录名”

3、需求变更：

需求变更较多时，建议采用粗颗粒度的用例，可较灵活的覆盖需求。经过一轮轮的评审，等需求基线化之后，在实际的滚动测试中，在逐步细化用例。需求变更较少时，或需求变更波及较小，系统设计框架不会频繁改动，可对应较大的细化测试用例变更量。

例如：一个需求，粗颗粒度的用例为100条，细颗粒度的用例为10000条。此需求变更，如果要修改粗颗粒度的用例，只需要修改10条；修改细颗粒度的用例，牵扯到细化的交叉逻辑，需要审阅3000条用例并可能修改1000条。

总结；测试用例的粒度粗细多大算粗多小算细没有一定的标准，还需要在工作中不断地实践积累，熟能生巧，做得多了，见得多了，再设计用例自然是得心应手。