测试用例颗粒度

原文链接:http://www.51testing.com/html/25/n-3693125.html

前言

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

  1. 【海外制单-海外制单界面】;
  2. 【海外制单-自动打印海外发货唛头(标签)】;
  3. 【海外制单-批量打印海外发货唛头】;
  4. 【海外制单-打印海外箱单(按箱)】。

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

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

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

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

颗粒度与测试的关系

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

  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,就是通畅,其他显示就是不通畅。

转载于:https://my.oschina.net/dwq000/blog/1855255

<think>好的,我现在需要帮用户解答如何编写有效的测试用例以及测试用例设计的最佳实践。首先,用户提到了他们查找相关信息或示例,所以我的回答需要结构清晰,步骤明确,并且给出实际例子。根据用户提供的引用内容,我需要整合这些信息,同时确保符合系统级指令的要求,比如正确使用LaTeX格式和引用标识。 首先,我应该回顾用户提供的引用内容。引用[1]提到测试用例模板和测试管理工具的重要性,引用[2]强调测试目标明确、需求文档的使用以及评审流程,引用[3]讨论了用例评审和改进中的常见问题,引用[4]和[5]涉及自动化测试用例的设计原则和工具选择。这些都需要在回答中有所体现。 接下来,我需要组织回答的结构。用户的问题分为两部分:编写有效测试用例和设计最佳实践。可能需要分步骤说明,每个步骤结合引用中的要点,比如明确测试目标、设计步骤、评审优化等。同时,要举一个示例测试用例,这样用户更直观理解。 另外,用户希望生成相关问题,我需要根据回答内容提出相关的问题,比如性能测试用例设计、自动化测试用例的注意点等。这些需要参考引用中的内容,尤其是引用[4]和[5]关于自动化的部分。 需要注意的是,用户可能没有技术背景,所以语言要尽量通俗,但保持专业性。同时,确保所有数学表达式用$...$格式,如果有的话。不过测试用例设计可能不涉及太多数学,但如果有变量或公式的情况,比如边界值分析中的数值范围,可能需要用到LaTeX。例如,输入范围是$[0,100]$,可以用LaTeX表示。 然后,检查是否有需要单独成段的公式,但可能这部分内容较少,所以可能不需要使用$$...$$格式。但如果有,比如举例数学公式,要正确应用。 现在开始整理步骤: 1. 明确测试目标:引用[2]提到要明确测试目标和范围,这里需要强调根据需求文档确定测试重点。 2. 用例设计方法:等价类划分、边界值分析(例如,输入框允许$0 \leq x \leq 100$)、场景法等,结合引用[2]和[3]中的用例覆盖问题。 3. 编写结构:测试步骤、预期结果,引用[1]的模板和引用[4]的原子性测试用例。 4. 评审优化:引用[3]中的评审过程,避免重复用例和明确细节。 5. 自动化整合:引用[4]和[5]提到的自动化测试用例设计原则,比如颗粒小,减少UI交互。 6. 示例:用户登录功能的测试用例,展示步骤和预期结果,符合引用[3]中的示例要求。 在生成相关问题部分,需要考虑用户可能进一步的问题,如性能测试、自动化工具选择、评审常见问题等,结合引用内容中的知识点。 最后,确保引用标识正确添加到对应的建议后面,比如提到测试用例模板时引用[1],提到评审时引用[3],自动化部分引用[4][5]等。同时,检查LaTeX是否正确应用,比如边界值的$0 \leq x \leq 100$是否正确使用$...$格式,没有数学公式的情况下是否需要调整。 现在,整理这些思路,形成结构化的回答,确保每个步骤清晰,引用正确,示例明确,相关问题相关且具有引导性。</think>### 如何编写有效的测试用例及设计最佳实践 #### 一、核心原则 1. **明确测试目标** 根据需求文档确定测试范围和优先级,例如“用户登录功能需支持用户名+密码验证”[^2]。 2. **覆盖关键场景** 包含正向操作(如输入合法用户名)、逆向操作(如密码错误)、边界值(如输入框允许$0 \leq x \leq 100$的数值)[^3]。 #### 二、设计方法 | 方法 | 说明 | 示例 | |---------------|--------------------------------------|-------------------------------| | 等价类划分 | 将输入划分为有效/无效类 | 用户名长:有效(3-20字符)、无效(<3或>20)| | 边界值分析 | 测试临界值 | 输入值为$0$、$100$、$-1$、$101$| | 场景法 | 模拟用户实际使用流程 | 用户登录→修改资料→退出系统 | #### 三、编写规范 ```gherkin # 示例:用户登录功能测试用例 Scenario: 验证合法用户登录 Given 用户进入登录页面 When 输入用户名"test_user"和密码"Passw0rd!" And 点击登录按钮 Then 跳转到首页 And 显示欢迎消息"欢迎回来,test_user" ``` #### 四、评审与优化 1. 通过团队评审消除重复用例(如引用[3]中TC001与TC019重复问题) 2. 明确模糊需求(如文本输入框字符类型限制需与产品确认[^3]) 3. 使用测试管理工具(如Jira、TestRail)结构化存储用例[^1] #### 五、自动化适配 - **原子性原则**:单个用例不超过2个页面交互,断言不超过2个[^4] - **工具选择**:Selenium(UI)、Postman(API)、Appium(移动端)[^5] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值