深圳哪家网站公司好,金华公司网站建设,黄石本地做网站的,检测网站死链当我们在编写测试用例时#xff0c;总是会遇到一个问题#xff1a;如何确定测试用例的颗粒度#xff1f;测试用例过于粗糙#xff0c;可能无法全面覆盖系统的细节#xff1b;而颗粒度过细#xff0c;又会导致测试重复、冗余。掌握合适的颗粒度#xff0c;不仅可以提高测…当我们在编写测试用例时总是会遇到一个问题如何确定测试用例的颗粒度测试用例过于粗糙可能无法全面覆盖系统的细节而颗粒度过细又会导致测试重复、冗余。掌握合适的颗粒度不仅可以提高测试效率还能确保测试的质量。那么究竟如何确定测试用例的颗粒度呢今天我们一起来探讨这个问题。 测试用例颗粒度是一个看似简单却非常重要的问题。如何根据项目需求、功能复杂度和测试目标来设置合适的颗粒度这直接影响到测试覆盖率、测试效率以及后续的维护工作。 随着软件开发周期的加速以及持续集成和自动化测试的普及测试用例的设计不仅仅是为了发现缺陷还需要考虑到如何在较短的时间内有效地覆盖更多的功能点。合理的颗粒度设置可以帮助团队在资源有限的情况下实现全面的测试覆盖并保持高效的测试进度。 合理的测试用例颗粒度是平衡测试覆盖率与测试效率的关键
通常我们需要根据以下几个因素来确定测试用例的颗粒度 功能复杂度功能越复杂测试用例的颗粒度应越细。比如复杂的登录模块除了常规的用户名和密码验证还需要覆盖验证码、异常输入、SQL注入等场景。 风险评估高风险区域的测试用例颗粒度应该相对较细以确保全面覆盖潜在的失败点。比如在处理支付、身份认证等关键功能时我们应该设计多个小颗粒度的测试用例来验证每个细节。 模块分解对于大模块的测试可以将功能拆分成多个子模块并分别进行测试。每个子模块的测试用例颗粒度应确保充分测试其独立功能。 测试目标如果目标是验证系统的整体功能是否可用可以选择较大的颗粒度重点覆盖主要功能流如果目标是进行深入的功能验证测试用例则应更细致。 1. 颗粒度与测试的关系
如果把测试用例设计得很细照顾到每一个数据输入、每一个条件、每一个环境、每一个路径那么测试用例的数量将是巨大的虽然风险很小很小但是测试效率会很低并且测试执行没有思考的空间可能使测试执行人员变得呆板除非全部测试自动化不需要创造力、思考。测试用例设计很粗测试效率可能比较高测试人员有一个发挥的空间使测试更有趣但这依赖于个人的责任感和能力风险大得多。 2. 颗粒度的大小取决与以下三点
1、“重要功能”、“特殊功能”颗粒密集度高“通用功能”可以试用通用测试粒度密集度应该可以大致界定。个人认为假如你非要为了一个字体的样式而写了一大长串的测试用例 那么这个颗粒度就毫无意义了。
2、颗粒度的大小还取决与客户对“产品”的要求。测试有一个难题是测试的精度或者说颗粒度的定义不要说一个程序就算是一个简单的登录都可以写出几乎无穷尽的测试用例所以你需要指明功能、性能需求使用环境等并说明对缺陷容忍的限度。才好依据最终的需求来定义测试的颗粒度也才好写测试用例总之客户的要求越详细所得到的测试用例越准确。如果客户跟你说这个地方你必须仔仔细细的测试。那么我们在写测试用例的时候。这个颗粒度一定要小了。
3、一般功能颗粒密集度可能会根据项目或是时间来确定。如果时间充裕颗粒度可以适当小。
4、粒度取决于测试的种类一般用验收测试,是项目测试中颗粒度比较大。系统测试颗粒度相对较小。 3. 有效度量测试用例条件
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下安装……。 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 bytes32 time3ms TTL64就是通畅其他显示就是不通畅。 测试用例的颗粒度是测试质量的核心之一合理设置颗粒度可以使测试既高效又全面。在设计测试用例时测试人员应根据功能复杂度、风险评估和项目需求来合理确定测试用例的颗粒度。通过灵活运用细粒度的测试策略我们能够更好地保障软件产品的质量。 “测试颗粒度的精准把握是确保软件质量的制胜法宝。”
