测试案例颗粒度,目前测量颗粒度最常用的方法有

　　导读：昨天文章谈到了测试用例设计的粒度，有人问。

　　#粒度是怎么划分的？

　　#粒度粗细和什么有关？

　　网上解读对很多个人来说还不够普及，我就用普及度来描述，从以下几点来梳理。

颗粒度分类

　　-粗粒度

　　-精细粒度

粗细有何标准？

　　#

以用例数量划分

　　从我现在所知道的测试同学写的测试用例数量来看，一个功能点大部分都在一百到几百左右。

　　100以下可以厚。

　　一千巴以上也可以。

　　一万条，肯定是毋庸置疑的。

# 以测试数据去划分

　　边界值和等价类测试很粗糙。

　　筋疲力尽，往一个细洞里钻死胡同。

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

　　“重要功能”和“特殊功能”的粒子密度较高，“一般功能”的粒子密度可以用一般的测试粒度来大致定义。就个人而言，如果你必须为一种字体样式写一长串测试用例，那么.

颗粒度粗细与什么有关？

　　1.这次添加或修改的代码量。

　　2.有效的测试时间和人力

　　3.业务逻辑的难度

　　4.根据需求判断

　　5.为了服务于用户群

# 以代码量去判断

　　如果你开发修改了几百行代码，不管测试时间是否充足，逻辑是否复杂，那么你都必须使用细粒度测试。

　　如果开发只是修改几行代码，测试时间足够，可以使用通用粒度测试。

　　如果开发只是修改几行代码，测试时间不够，可以用粗粒度测试。

# 以项目时间判断

　　当时间短，项目紧，编写用例的评审时间短时，适合粗粒度的用例。

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

# 以测试人员判断

　　当测试人员精通，有坚实的想法和基本技能，或者有高度的责任感时，可以采用粗粒度的用例。

　　当有很多新手测试人员，需要在别人的指导下进行基本的测试，或者有普遍的责任感时，应该采用细粒度的用例。

# 以需求判断

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

　　当需求变化较小，或者需求变化影响较小时，并不是系统设计框架的频繁变更。——具体标准需要对不同行业的产品进行评估，可以对应详细测试用例的较大变化。

# 以用户群体判断

　　如果项目/产品的最终客户是特定的人员、专业人员、技术人员和训练有素的操作人员，可以采用粗粒度的用例。

　　如果项目/产品的最终客户是广泛的用户和消费者，那么应该采用细粒度的用例。

# 以实际场景列举

　　比如这次公司安排个人测试的抽奖系统项目周期为5天，测试时间为2天。个人说只列了测试点，测试用例没来没写，每天加班到90点左右。这怎么能有根据呢？

　　-仅覆盖主要需求点。正向函数粗糙。

　　比如一个用户群是自己内部员工或者小范围用户使用，需求方只要满足功能点，正常工作，就OK了。我们此时可以设计粗粒度的测试用例，实现最小的人力和时间成本完成最终的刚需需求点，供他们提前使用。

　　-将功能点的功能、页面、UI、兼容性、用户体验以及所有相关的正反异常场景的测试用例进行细分。

　　比如：某大型电商APP或社交软件；用户群投放市场供外部使用。这时候用户对其功能界面的体验肯定有极高的要求。此时我们将从所有测试方向细化测试用例，

"用户想到的我们要想到，用户想不到的我们也要想到"

　　专注于软件测试行业的前景分析，测试思想和管理领域的分享；划水之后带领1W测试开发学习函数，接口自动化测试，Python好文章。作者回复测试， Python ，邮差来