测试用例颗粒度

测试积点老人

前言

　　在测试过程中，我们会经常遇到，实现一个功能有多个操作路径/步骤，比如：在一个库存管理系统中，需要修改一种类型箱子标签的打印格式，而打印这个箱子标签（唛头），涉及很多操作路径，比如有：

• 【海外制单-海外制单界面】；
• 【海外制单-自动打印海外发货唛头（标签）】；
• 【海外制单-批量打印海外发货唛头】；
• 【海外制单-打印海外箱单（按箱）】。
  

　　这4个路径都可以打印同一个模板，也就是预期结果一样，但是四个路径操作方式不一样，那么这个时候是设计1条用例，还是4条用例呢？

　　还有一种情况是一个操作产生多个不同的结果，比如：点击登陆按钮后，显示成功登陆系统的弹窗提示，同时写入1条登陆日志到数据库表AAA中，同时向系统发送1条接口日志，表示登陆成功。这个是时候，你是设计3个用例，还是1个用例呢？如果设计3个用例那么就是操作步骤跟预期结果一一对应的关系，如果设计1个用例就是1个操作步骤，多个结果（检查点）的关系。有时候我们就有些迷茫了，到底是设计少一些用例，还是设计多一些用例呢？

　　在我测试的时候，就经常遇到这种情况，我通常的处理是，如果这个需求场景特别多，需要设计很多用例，时间又少，那么我尽量精简测试用例，如果某个需求场景少，那么有多个路径的情况，我会设计成多个用例，这样不至于让人看起来用例数量太少，担心需求用例覆盖不全的感觉。其实在测试理论实践上这就是测试用例颗粒度的把握问题。

　　下面给大家讲解一下测试用例颗粒度的知识。

颗粒度与测试的关系

　　如果把测试用例设计得很细，照顾到每一个数据输入、每一个条件、每一个环境、每一个路径，那么测试用例的数量将是巨大的，虽然风险很小很小，但是测试效率会很低，并且测试执行没有思考的空间，可能使测试执行人员变得呆板（除非全部测试自动化），不需要创造力、思考。测试用例设计很粗，测试效率可能比较高，测试人员有一个发挥的空间，使测试更有趣，但这依赖于个人的责任感和能力，风险大得多。
　　颗粒度的大小取决与以下几点：

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

• 颗粒度的大小还取决与客户对“产品”的要求。测试有一个难题是测试的精度，或者说颗粒度的定义，不要说一个程序，就算是一个简单的登录都可以写出几乎无穷尽的测试用例，所以你需要指明功能、性能需求，使用环境等，并说明对缺陷容忍的限度。才好依据最终的需求来定义测试的颗粒度，也才好写测试用例，总之，客户的要求越详细所得到的测试用例越准确。如果客户跟你说这个地方你必须仔仔细细的测试。那么我们在写测试用例的时候。这个颗粒度一定要小了。

• 一般功能颗粒密集度可能会根 据项目或是时间来确定。如果时间充裕颗粒度可以适当小。

• 粒度取决于测试的种类，一般用验收测试,是项目测试中颗粒度比较大。系统测试颗粒度相对较小。

  
  

有效度量测试用例条件

• 颗粒度可以跟代码行数对应：一般来说代码量越大，内部逻辑就越复杂，出现bug的的可能性也越高。对应的测试粒度也越小。

• 测试团队内部对粒度达成一致，适当把握颗粒度：明确测试用例编写的颗粒度，大家都有这种感觉，你写测试用例，你测试这个产品的时候，你十条测试用例就测试完了，有人写三十条，你就觉得奇怪，我觉得十条已经是局限了，怎么你能写到三十条，你去看他的用例，发现这也能算一条，这是组织内部测试用例颗粒度没有达成一致。

• 颗粒度要适合业务的需要：各公司测试用例设计的粒度不同，适合自己的需要，适合业务的需要即可，测试用例的数量统计方法，我觉得说明不了测试作得是否专业。

• 测试用例设计的覆盖率和有效性，才是说明测试是否专业的依据之一：对于进行工作量的统计还可以，不过用例还是不能简单的以数量来看，设计一个很简单的功能点的用例可能很容易，可能一天能设计十个这样的用例，但是对于一个相对复杂的功能，可能一天才能准备两个用例，光靠数量是说明不了问题的。

  
  

测试用例之度——系列之颗粒度

　　测试用例是测试工作的核心。测试工作是讲究投入产出比的工作，这也是测试用例设计的指导思想。
　　测试用例有度的概念，正如亚里士多德在《伦理学》中讨论道德为例：道德意味着过与不及之间的状态。面向测试用例，网上流传着这么一句话：“不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试”。
　　下面就列举测试用例设计的方方面面，看不同的团队，不同的测试目的，如何把握测试用例设计之度。

颗粒度：

　　颗粒度的粗细，有无标准？什么是粗？什么是细？

1. 以功能点划分？
　　仅仅覆盖所有的功能性需求为粗？
　　仅仅正向覆盖所有的功能需求（功能、性能）为粗？
　　正向/负向覆盖所有的功能需求（功能、性能）以及正向覆盖性能需求为粗？
　　正向/负向覆盖所有的需求为细？覆盖到产品包，涵盖兼容性、升级、安装、易用性为细？

2. 以STEP划分？
　　每条用例有一个STEP为粗，三？五？十为细？以上为细？
　　以测试设计思路的体现？
　　只采用正向为粗？只采用正/负向为粗？考虑应用场景为细？考虑业务逻辑为细？

3. 以数量级？
　　百条？千条？万条？

4. 以数据覆盖？
　　等价类是粗？穷举是细？
　　每个人、每个机构判定测试用例粗细的标准都不一样，没有标准的答案。所以测试用例颗粒度的粗细，本身就是一个相对而言的标准。
　　尝试用图示来表示颗粒度粗细的常规概念：

测试用例颗粒度粗、细的特点是什么？

用例设计分析：

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

面对测试执行人员：

　　粗颗粒度用例不容易被测试新手执行，因为很多约定成俗的操作、现象，甚至行业术语都不清楚。细颗粒度用例相对较易被测试新手执行。

覆盖度：

　　粗颗粒度覆盖度可能小于细颗粒度用例（粗颗粒度只覆盖全部正向和部分负向，细颗粒度覆盖全部正向、负向、其他等）；但还有一种可能性，就是粗细用例均覆盖全面，但是深度不同。类似下雨的降雨量不同，对农作物（产品）的意义不同。

可维护性：

　　毫无疑问，测试用例和需求的匹配，测试用例本身的维护是大多数团队的工作难点重点，粗颗粒度便于维护，方便和需求保持高度一致；细颗粒度用例，越细越不容易维护，维护成本过大，特别是需求频繁变更会导致不可维护。
　　类似的概念，比如自动化测试环节，GUI不停改变导致的脚本重写类似。

时间：

　　粗颗粒度构架和评审的时间较短，适合周期较紧的项目；细颗粒度构建和编写的时间较长，适合周期宽松或更倾向于质量的项目。

资源：

　　粗颗粒度占用资源较少（人力、评审、会议室等），适合小团队或同一团队多项目模式；细颗粒度占用资源较多，适合大团队或单一项目模式。

风险：

　　毫无疑问，粗颗粒度用例的风险是漏测，存在很大概率漏测的风险，依赖于测试人员的个人素质；细颗粒度也存在漏测，不过相对更可能是测试人员自己的想当然跳过用例不执行。

　　细颗粒度用例最大的风险就是可维护性，或者投入产出比。

Miss_love

感谢分享