本文主要是介绍你设计的测试用例颗粒度多大合适？（二），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
测试用例之度——系列之颗粒度
测试用例是测试工作的核心。测试工作是讲究投入产出比的工作，这也是测试用例设计的指导思想。
测试用例有度的概念，正如亚里士多德在《伦理学》中讨论道德为例：道德意味着过与不及之间的状态。面向测试用例，网上流传着这么一句话：“不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试”
下面就列举测试用例设计的方方面面，看不同的团队，不同的测试目的，如何把握测试用例设计之度。
颗粒度：
颗粒度的粗细，有无标准？什么是粗？什么是细？
1、以功能点划分？
仅仅覆盖所有的功能性需求为粗？
仅仅正向覆盖所有的功能需求（功能、性能）为粗？
正向/负向覆盖所有的功能需求（功能、性能）以及正向覆盖性能需求为粗？
正向/负向覆盖所有的需求为细？覆盖到产品包，涵盖兼容性、升级、安装、易用性为细？
2、以STEP划分？
每条用例有一个STEP为粗，三？五？十为细？以上为细？
以测试设计思路的体现？
只采用正向为粗？只采用正/负向为粗？考虑应用场景为细？考虑业务逻辑为细？
3、以数量级？
百条？千条？万条？
4、以数据覆盖？
等价类是粗？穷举是细？
每个人、每个机构判定测试用例粗细的标准都不一样，没有标准的答案。所以测试用例颗粒度的粗细，本身就是一个相对而言的标准。
尝试用图示来表示颗粒度粗细的常规概念：
测试用例颗粒度粗、细的特点是什么？
用例设计分析：
粗颗粒度面向宏观，面向正向的功能点、大的功能模块和整体性，体现测试用例的设计思路；细颗粒度面向微观，面对具体的一个个功能点的正向/负向逻辑，体现测试用例的细节和完备性。
面对测试执行人员：
粗颗粒度用例不容易被测试新手执行，因为很多约定成俗的操作、现象，甚至行业术语都不清楚。细颗粒度用例相对较易被测试新手执行。
覆盖度：
粗颗粒度覆盖度可能小于细颗粒度用例（粗颗粒度只覆盖全部正向和部分负向，细颗粒度覆盖全部正向、负向、其他等）；但还有一种可能性，就是粗细用例均覆盖全面，但是深度不同。类似下雨的降雨量不同，对农作物（产品）的意义不同。
可维护性：
毫无疑问，测试用例和需求的匹配，测试用例本身的维护是大多数团队的工作难点重点，粗颗粒度便于维护，方便和需求保持高度一致；细颗粒度用例，越细越不容易维护，维护成本过大，特别是需求频繁变更会导致不可维护。
类似的概念，比如自动化测试环节，GUI不停改变导致的脚本重写类似。
时间：
粗颗粒度构架和评审的时间较短，适合周期较紧的项目；细颗粒度构建和编写的时间较长，适合周期宽松或更倾向于质量的项目。
资源：
粗颗粒度占用资源较少（人力、评审、会议室等），适合小团队或同一团队多项目模式；细颗粒度占用资源较多，适合大团队或单一项目模式。
风险：
毫无疑问，粗颗粒度用例的风险是漏测，存在很大概率漏测的风险，依赖于测试人员的个人素质；细颗粒度也存在漏测，不过相对更可能是测试人员自己的想当然跳过用例不执行。
细颗粒度用例最大的风险就是可维护性，或者投入产出比。
（未完待续）
这篇关于你设计的测试用例颗粒度多大合适？（二）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
