下面给大家讲解一下测试用例颗粒度的知识：
　　颗粒度与测试的关系
如果把测试用例设计得很细，照顾到每一个数据输入、每一个条件、每一个环境、每一个路径，那么测试用例的数量将是巨大的，虽然风险很小很小，但是测试效率会很低，并且测试执行没有思考的空间，可能使测试执行人员变得呆板（除非全部测试自动化），不需要创造力、思考。测试用例设计很粗，测试效率可能比较高，测试人员有一个发挥的空间，使测试更有趣，但这依赖于个人的责任感和能力，风险大得多。
颗粒度的大小取决与以下三点
1、“重要功能”、“特殊功能”颗粒密集度高，“通用功能”可以试用通用测试粒度，密集度应该可以大致界定。个人认为，假如你非要为了一个字体的样式而写了一大长串的测试用例 ，那么这个颗粒度就毫无意义了。
　　2、颗粒度的大小还取决与客户对“产品”的要求。测试有一个难题是测试的精度，或者说颗粒度的定义，不要说一个程序，就算是一个简单的登录都可以写出几乎无穷尽的测试用例，所以你需要指明功能、性能需求，使用环境等，并说明对缺陷容忍的限度。才好依据最终的需求来定义测试的颗粒度，也才好写测试用例，总之，客户的要求越详细所得到的测试用例越准确。如果客户跟你说这个地方你必须仔仔细细的测试。那么我们在写测试用例的时候。这个颗粒度一定要小了。
　　3、一般功能颗粒密集度可能会根据项目或是时间来确定。如果时间充裕颗粒度可以适当小。
　4、粒度取决于测试的种类，一般用验收测试,是项目测试中颗粒度比较大。系统测试颗粒度相对较小。
　　有效度量测试用例条件：
1、颗粒度可以跟代码行数对应：一般来说代码量越大，内部逻辑就越复杂，出现bug的的可能性也越高。对应的测试粒度也越小。
2、测试团队内部对粒度达成一致，适当把握颗粒度：明确测试用例编写的颗粒度，大家都有这种感觉，你写测试用例，你测试这个产品的时候，你十条测试用例就测试完了，有人写三十条，你就觉得奇怪，我觉得十条已经是局限了，怎么你能写到三十条，你去看他的用例，发现这也能算一条，这是组织内部测试用例颗粒度没有达成一致。
　3、颗粒度要适合业务的需要：各公司测试用例设计的粒度不同，适合自己的需要，适合业务的需要即可，测试用例的数量统计方法，我觉得说明不了测试作得是否专业。
　　4、测试用例设计的覆盖率和有效性，才是说明测试是否专业的依据之一：对于进行工作量的统计还可以，不过用例还是不能简单的以数量来看，设计一个很简单的功能点的用例可能很容易，可能一天能设计十个这样的用例，但是对于一个相对复杂的功能，可能一天才能准备两个用例，光靠数量是说明不了问题的。
　　测试用例之度——系列之颗粒度
测试用例是测试工作的核心。测试工作是讲究投入产出比的工作，这也是测试用例设计的指导思想。
测试用例有度的概念，正如亚里士多德在《伦理学》中讨论道德为例：道德意味着过与不及之间的状态。面向测试用例，网上流传着这么一句话：“不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试”
　下面就列举测试用例设计的方方面面，看不同的团队，不同的测试目的，如何把握测试用例设计之度。
　　颗粒度：
颗粒度的粗细，有无标准？什么是粗？什么是细？
1、以功能点划分？
仅仅覆盖所有的功能性需求为粗？
仅仅正向覆盖所有的功能需求（功能、性能）为粗？
正向/负向覆盖所有的功能需求（功能、性能）以及正向覆盖性能需求为粗？
正向/负向覆盖所有的需求为细？覆盖到产品包，涵盖兼容性、升级、安装、易用性为细？
2、以STEP划分？
每条用例有一个STEP为粗，三？五？十为细？以上为细？
以测试设计思路的体现？
只采用正向为粗？只采用正/负向为粗？考虑应用场景为细？考虑业务逻辑为细？
3、以数量级？
百条？千条？万条？
4、以数据覆盖？
等价类是粗？穷举是细？
每个人、每个机构判定测试用例粗细的标准都不一样，没有标准的答案。所以测试用例颗粒度的粗细，本身就是一个相对而言的标准。
尝试用图示来表示颗粒度粗细的常规概念：
测试用例颗粒度粗、细的特点是什么？
　用例设计分析：
　　粗颗粒度面向宏观，面向正向的功能点、大的功能模块和整体性，体现测试用例的设计思路；细颗粒度面向微观，面对具体的一个个功能点的正向/负向逻辑，体现测试用例的细节和完备性。
面对测试执行人员：
粗颗粒度用例不容易被测试新手执行，因为很多约定成俗的操作、现象，甚至行业术语都不清楚。细颗粒度用例相对较易被测试新手执行。
覆盖度：
粗颗粒度覆盖度可能小于细颗粒度用例（粗颗粒度只覆盖全部正向和部分负向，细颗粒度覆盖全部正向、负向、其他等）；但还有一种可能性，就是粗细用例均覆盖全面，但是深度不同。类似下雨的降雨量不同，对农作物（产品）的意义不同。
　可维护性：
毫无疑问，测试用例和需求的匹配，测试用例本身的维护是大多数团队的工作难点重点，粗颗粒度便于维护，方便和需求保持高度一致；细颗粒度用例，越细越不容易维护，维护成本过大，特别是需求频繁变更会导致不可维护。
类似的概念，比如自动化测试环节，GUI不停改变导致的脚本重写类似。
　时间：
粗颗粒度构架和评审的时间较短，适合周期较紧的项目；细颗粒度构建和编写的时间较长，适合周期宽松或更倾向于质量的项目。
　资源：
粗颗粒度占用资源较少（人力、评审、会议室等），适合小团队或同一团队多项目模式；细颗粒度占用资源较多，适合大团队或单一项目模式。
　风险：
毫无疑问，粗颗粒度用例的风险是漏测，存在很大概率漏测的风险，依赖于测试人员的个人素质；细颗粒度也存在漏测，不过相对更可能是测试人员自己的想当然跳过用例不执行。
细颗粒度用例最大的风险就是可维护性，或者投入产出比。
　测试用例颗粒度常规应用场景的枚举：
上面分析了很多测试用例颗粒度粗、细的特点，那么，常规的测试来讲，如何大致定位测试用例颗粒度的粗细呢？
下面以单一的应用环境来体现。
还是要强调那句话：相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试。
单一条件：
1、时间因素：
时间短、项目紧、编写用例评审时间较短时，适合粗颗粒度用例。
项目周期较长时，适合细颗粒度用例。
比如规划六个月的项目，计划阶段和设计阶段有一个半月，测试前期进入，有足够的时间来进行人员培训、测试用例编写，需要细颗粒度。如果项目是一个月，测试准备时间只有五个工作日，那么可能在第三天就要完成第一轮的测试用例评审，建议以粗颗粒度为主，覆盖功能和体现思路。
　2、项目人员：
测试人员中熟手多，思路和基础技能扎实，或测试人员构成责任心高时，可以采用粗颗粒度用例。
测试人员新手多，需要再指导下进行基础测试工作，或责任心一般时，需采用细颗粒度用例。
测试人员熟手和新手的区别，大家一目了然。在这里，特意把责任心作为测试用例编写粗细的一个判别标准。实际上，测试人员的职业素质中，就有责任心一项，这种品质方面的要求因人而异——而且每个人都肯定对自己的责任心还自我感觉良好。
举个例子，比如安装测试：
粗的写法：在微软的各种操作系统下进行遍历安装，确认setup安装成功。——那么责任心好的人，可能会去翻阅规格书，确认setup支持的操作系统，再依次安装测试。责任心一般的人，可能就想当然的认为visia这种过渡版本很少人用/server 2000 不是个人用户的菜，就直接跳过这两种系统。
所以面对责任心一般的人，就必须写成细的用例：安装测试：A、在window XP 的 SP2 环境下安装；B、在xp的SP3 环境下安装；C、在win server 2000 下安装；……。
　3、项目质量性质
项目质量要求一般，或项目为过渡项目，生命周期短；项目为临时项目时，可采用粗颗粒度用例。
项目质量要求高，客户或公司对质量的定位为第一位，品牌工程项目，采用细颗粒度用例。
难道不是所有的项目都是高质量高要求的么？当然不是。
不同国家和民族的人对质量的要求是不一样的：美国是够用就好，德国是精益求精，中国是当场不挂就行。
不同产业链位置的公司对质量要求是不一样的：顶级公司做完美的产品，中级公司做性价比高的产品，底层公司做廉价的产品。
不同定位的公司对质量的要求是不一样的：在火车站门口的饭店吃的是客流量，在市区偏远地方的饭店吃的是回头客。
不同目的的单子对质量的要求是不一样的：做账拉回扣的虚项目，中标后无人使用，三年后设备升级，质量就没有要求。做重点项目，质量要求苛刻等。
所以，肯定会有不同的项目质量性质。也自然有不同的测试策略和测试目的，顺序导出的就是不同颗粒度的测试用例。
4、资源配置：
资源配置较少，无法实现测试用例的细化时，可以采用粗颗粒度的测试用例。
资源配置较多，可满足用例编写、评审、修订的交叉进行时，可采用细颗粒度。
　　举例：如果测试人员配置较少，一共就三五个人，每人负责一个项目，彼此没有时间去做评审，甚至项目都存在临时增多的现象，就无从谈起测试用例的细化，甚至粗颗粒度都较难实现，只能拉一个测试大纲出来。
或者测试团队有十多个人，但是项目是流水式过来的。需求、开发、测试是流水线模式处理大批量的项目，无法做到一个项目的全流程参与时，也很难展开测试用例评审、修订以致细化事宜。
　5、需求变更：
需求变更较多时，建议采用粗颗粒度的用例，可较灵活的覆盖需求。经过一轮轮的评审，等需求基线化之后，在实际的滚动测试中，在逐步细化用例——根据项目实际情况。
需求变更较少时，或需求变更波及较小，不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估，可对应较大的细化测试用例变更量。
举例：一个需求，粗颗粒度的用例为100条，细颗粒度的用例为10000条。此需求变更，如果要修改粗颗粒度的用例，只需要修改10条；修改细颗粒度的用例，牵扯到细化的交叉逻辑，需要审阅2000条用例并可能修改1200条。
如果测试用例修改人非测试用例编写人，则修改时间还可能延长1.3倍。
　6、项目对象：
如果项目/产品最终面对的客户是特定人员、专业人员、技术人员、培训后的操作员，可以采用粗颗粒度的用例。
如果项目/产品最终面对的客户是广义的使用群体、人民大众消费者，要采用细颗粒度的用例。
面向专业人员的项目/产品，测试倾向于正向测试，一些问题或使用方式在规定、需求之外，可以在培训或规范中指定操作模式，或凭借技术人员的功底来避免问题。
面向非专业人员的项目/产品，无法做到培训和操作约定，各种稀奇古怪的使用方法，操作习惯，所以更倾向于细颗粒度，覆盖负向和随机操作的测试用例。
7、测试团队素质：
团队个体素质较高，可适应粗犷、敏捷的风格时，可以采用粗颗粒度的用例。
团队处于成立初期或磨合期，需要细化的规则约定来指导时，采用细颗粒度的用例。
8、公司决策投入：
公司对测试工作的投入，对产品质量的要求，对行业节奏的把握。具体分析，可参考项目质量性质部分的论述。
测试用例粗细的另外一个概念：用例的文字描述粗细。
（旧文贴成）
文档分为好多种，在后面写测试用例的时候你们会遇到类似的颗粒度的问题。
第一类是写给自己，以及懂这个技术的，差不多水平的同事看的。这样只需要大致的描述核心关键点就可以。
第二类是给技术一般的员工，但是有一定底子的人看的，这样基本的概念就不用描述，整体步骤描述清楚就可以。
第三类是给不懂技术，只会看图一步步操作的外行看的，这样就要详细细致的描述基本概念，步步都截图，傻瓜式的对比参照的搞过去。
　　举个例子，使用ping 命令
第一类写法：如果网络不通，使用ping命令测试一下网络是否通畅。
第二类写法：如果网络不通，在cmd模式下，使用ping X.X.X.X 的命令格式，测试一下网络是否通畅。
第三类写法：如果网络不通，点击开始，选择运行，然后在运行框里输入cmd，然后在弹出框里面，使用ping X.X.X.X 的命令格式，如果显示Reply from X.x.x.x bytes=32 time=3ms TTL=64，就是通畅，其他显示就是不通畅

软件测试之测试用例颗粒度问题相关推荐

  1. 测试用例颗粒度实例列举

    引言:昨天文章谈及到测试用例设计的颗粒度有人问 # 颗粒度如何划分? # 颗粒度粗细与什么有关? 网上释义大把个人觉得还不够通俗,我就在通俗描述一下从以下几点去梳理梳理... 颗粒度分类 - 粗颗粒度 ...

  2. 软件测试之-测试用例写作规范

    通用测试用例写作规范 软件测试用例得出软件测试用例的内容,其次,按照软件测试写作方法,落实到文档中,两者是形式和内容的关系,好的测试用例不仅方便自己和别人查看,而且能帮助设计的时候考虑的更周. 一个好 ...

  3. 软件测试之测试用例的设计

    目录 测试用例 什么是测试用例 测试用例的基本要素 评价测试用例的标准: 测试用例的设计方法 测试用例的总体设计方法还是基于需求设计 具体的设计方法(6种) 等价类划分 边界值 因果图(逻辑图) 正交 ...

  4. 软件测试之测试用例设计(二)

    本文是学习软件测试的,内容均转载自https://blog.csdn.net/qq_41782425 目录 一丶边界值例题 二丶判定表 三丶黑盒测试用例设计(正交实验) 一丶边界值例题 1.结合等价类 ...

  5. 软件测试之测试用例设计（三）

    说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家! 接着上一篇博客继续往下写 :https://blog.csdn.net/qq_41782425/article/details/9 ...

  6. 软件测试之测试用例评审

    一.评审目的 一般来说,参加测试用例评审的人员包括对应项目的产品人员.设计人员.开发人员和测试人员. 图1-1 测试用例评审相关人员 测试用例评审会议的发起者一般是测试人员,既然我们是发起者,那我们发 ...

  7. 软件测试之测试用例设计题

    1.假设京东有一个Web API:http://p.jd.com?p1=90&p0=100,输入打折价p1和原价p0,返回折扣信息0.9,请设计测试用例进行测试. 答案: (1)输入打折价错误 ...

  8. 软件测试之测试用例编写

    整体编写思路: 理解需求–>了解功能–>了解业务–>拆分功能点–>利用五大方法(等价类.因果图.边界值.错误猜测.场景法)–>从不同方向出发编写测试用例 用例需要掌握的方 ...

  9. 软件测试之测试用例编写及编写规范

    转载自:https://www.cnblogs.com/zengch/p/13485620.html 一.什么是测试用例 为实施测试,向被测试系统所提供的输入数据,操作或各种环境设置以及期望结果的一个 ...

最新文章

  1. 嘉兴新型智慧城市建设带来的三个问号
  2. 微服务调用组件Feign：简介以及搭建环境
  3. 一张图理清 Python3 所有知识点
  4. linux多线程学习(二)——线程的创建和退出
  5. xcode工程间的引用，iOS静态库
  6. device 查看tensor_【ML实践笔记】05-DeepLizard教程8-9：在PyTorch中创建tensor
  7. 数字翻译成英语JavaScript
  8. 详解函数的三种传递方式
  9. 【C++程序设计技巧】NVI（Non-Virtual Interface ）
  10. disallow php,在robots.txt中Disallow: /abc和Disallow: /abc/的区别
  11. 设计模式|职责链模式--流程状态审批（枚举实现）
  12. w7计算机休眠网络就断了,设置Win7电脑休眠时不断开WiFi教程
  13. Java习题练习：幸运数
  14. 【分享】推荐一些不错的计算机书籍
  15. netty案例，netty4.1源码分析篇五《一行简单的writeAndFlush都做了哪些事》
  16. java培训 | 零基础学习java开发的学习方法有哪些
  17. 手机号归属地数据导入及查询工具源代码（C++）
  18. TYPE1码本 一【5G笔记】
  19. 计算机配置主板技术参数,怎么看电脑的配置?教你4个方法查看新电脑pc配置硬件参数...
  20. 闪蝶-COBOL代码分析工具

热门文章

  1. GitHub--logparser(日志解析器)
  2. nginx安装、配置文件详解、测试
  3. 【高效程序员系列】3、别碰鼠标------让键盘飞起来
  4. ubuntu 下 ssd磁盘检测
  5. Python基础之告警定义与告警抑制
  6. apple 兑换代码使用_什么是Apple True Tone，我该如何使用？
  7. Algorithms学习笔记-第一章 基础
  8. 阿里云服务器常用配置收费1核2G/2核4G/4核8G/8核16G多配置
  9. 一篇文章读懂《麦肯锡极简工作法》
  10. 有关“SRS Audio Sandbox”的一些问题？