引言：昨天文章谈及到测试用例设计的颗粒度有人问

# 颗粒度如何划分？

# 颗粒度粗细与什么有关？

网上释义大把个人觉得还不够通俗，我就在通俗描述一下从以下几点去梳理梳理...

颗粒度分类

- 粗颗粒度

- 细颗粒度

粗细有何标准？

# 以用例数量划分

从我现在了解的测试同学写测试用例条数来看，一般一个功能点大部分都是百条至几百条左右

百条以下可以为粗

千条之上可以为细

万条那肯定是毋庸置疑为细

# 以测试数据去划分

边界值、等价类测试为粗

穷举、钻牛角尖为细

总结：粗颗粒度面向宏观，面向正向的功能点、大的功能模块和整体性，体现测试用例的设计思路；细颗粒度面向微观，面对具体的一个个功能点的正向/负向逻辑，体现测试用例的细节和完备性。

“重要功能”、“特殊功能”颗粒密集度高,“通用功能”可以试用通用测试粒度,密集度应该可以大致界定。个人认为,假如你非要为了一个字体的样式而写了一大长串的测试用例 ,那么...

颗粒度粗细与什么有关？

1.版本此次新增或修改的代码量

2.有效的测试时间以及人力

3.业务逻辑的难易程度

4.以需求去判断

5.以服务用户群体

# 以代码量去判断

如果开发修改几百行代码，测试时间不管是否充足并且逻辑复杂此时肯定是使用细颗粒度测试

如果开发仅仅就是修改几行代码，测试时间充足，可以使用通用颗粒度测试

如果开发仅仅就是修改几行代码，测试时间不充足，可以使用粗颗粒度测试

# 以项目时间判断

时间短、项目紧、编写用例评审时间较短时，适合粗颗粒度用例。

项目周期较长时，适合细颗粒度用例。

# 以测试人员判断

测试人员中熟手多，思路和基础技能扎实，或测试人员构成责任心高时，可以采用粗颗粒度用例。

测试人员新手多，需要再指导下进行基础测试工作，或责任心一般时，需采用细颗粒度用例

# 以需求判断

需求变更较多时，建议采用粗颗粒度的用例，可较灵活的覆盖需求。经过一轮轮的评审，等需求基线化之后，在实际的滚动测试中，在逐步细化用例——根据项目实际情况。

需求变更较少时，或需求变更波及较小，不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估，可对应较大的细化测试用例变更量。

# 以用户群体判断

如果项目/产品最终面对的客户是特定人员、专业人员、技术人员、培训后的操作员，可以采用粗颗粒度的用例。

如果项目/产品最终面对的客户是广义的使用群体、人民大众消费者，要采用细颗粒度的用例。

# 以实际场景列举

例如此次公司安排个人测试的抽奖系统项目周期5天，测试时间2天 ，个人表示只列举了测试点，测试用例都没来及写 ，每天加班九十点左右，这种何来细可立足之谈

- 仅仅只覆盖主要需求点正向功能为粗

例如：针对一个用户群为自己内部员工或者小范围用户使用，需求方只需要满足功能点能够正常运行就OK我们此时就可以用粗颗粒度进行设计测试用例，达到最少人力时间成本完成最终刚需需求点，提前供他们使用.

- 将功能点正反异常场景功能、页面、UI、兼容、用户体验度、全部涉及到的测试用例为细

例如：一个大型电商APP或者社交软件；用户群是对外投入市场使用，此时用户对其功能界面体验性肯定是要求极高，我们此时就要从各个测试方向细化测试用例，"用户想到的我们要想到，用户想不到的我们也要想到"

专注软件测试行业前景分析、测试思想、管理领域分享；划水之余带领1W+测试开发攻读功能、接口自动化测试、Python好文 关注作者 回复"测试""Python""postman"领取系统学习资料

题图 : 心得分享