测试用例编写指导

一、背景及目标

测试用例是将产品需求转换为具体可验证的指标,为了防止测试过程中出现遗漏,按照测试用例执行可以提高工作效率,它还可以跟踪整体测试进度,起到指导作用,并可以作为历史参考,因此测试用例的准确性和完整性对产品质量的影响至关重要。在测试用例编写方面需要建立在学习了理论方法、通用测试用例模板、对产品业务的深入理解和一定的经验这四个因素基础上,才能编写高质量的测试用例。
对于非专业的测试人员,如果想了解测试用例,并希望能够快速地编写一些基础场景的用例,来完成大部分功能覆盖,可以通过阅读本文接下来章节的内容,在深入理解了产品需求文档前提条件下,使用文中介绍的方法和技巧应用到项目中用例编写,基本可以完成70%~80%覆盖率的用例编写,剩下的就是项目反复实践,积累测试经验,最终达到用例编写覆盖率稳定达到95%以上。
本文适用范围:所有人

二、测试用例编写的步骤

1、精读需求文档:对需求理解不到位会导致测试用例无法全面覆盖,因此在编写用例前需要充分阅读和理解需求,它是写好测试用例的大前提。
2、梳理测试功能点:使用xmind进行测试功能点的梳理能够从全局的角度把控,防止测试设计出现遗漏,具体方法见第六章节。
3、Gitee上创建测试用例目录:测试用例的有效管理也是非常必要的,对于后续的执行、维护有事半功倍的作用,具体方法见第四章节。(每个公司使用的测试用例管理平台不一样,可视视情况来定)
4、根据第二步中的测试功能点,编写具体的测试用例:测试用例的定义以及包含的要素见第三章节,具体的编写用例方法和测试点分类汇总见第七、八、九章节。
Tips:可以借助AI助手协助编写用例,具体会在第七章节中介绍。

三、测试用例定义及要素

1.测试用例定义
测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说,测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。

2.测试用例组成

  • 功能模块:比如某检验管理后台模块
  • 用例标题:【一级菜单】【二级菜单】具体用例目的
  • 版本:当前需求版本号
  • 优先级:P0,P1,P2,P3
  • 用例类型:功能测试、UI测试、兼容性测试、性能测试、安全测试等
  • 前置条件:用来对环境、输入数据、测试账号等做说明
  • 测试步骤:尽可能的用易懂的过程语言描述操作步骤
  • 期望结果:说明每一步的操作应该产生的结果
  • 设计人员:编写该条用例的人员
    3.用例优先级定义
  • P0(核心):
      【定义】:该类用例设计系统基本功能,也就是最重要的功能,保证系统流程可以走通、该级用例的数量一般在20% (二八原则,前20%的用例可以发现软件80%的重要bug)
      【划分依据】:该用例执行的失败会导致系统无法正常运行。阻塞测试继续进行测试,可以认为是操作概率较高、需求级别高、出现问题的概率高、出现问题的严重级别高的用例
    【执行阶段】:线下冒烟、线上回归、集成测试、回归测试
  • P1(重要):
      【定义】:所有产品功能列表、产品形态上提供的可操作性功能
      【划分依据】:主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能测试用例,这种用例能发现重要的bug或者能保证软件的功能是稳定的
      【执行阶段】:集成测试、回归测试
  • P2(一般):
      【定义】:不影响功能的页面检查、兼容性检查、边界值检查、非法检查等
      【划分依据】:使用频率较低于P1用例。主要是一些边界和配置测试,例如:UI相关的特殊字符、字符串超长、完整性测试;功能相关的的异常场景包含依赖业务方异常、网络异常、非标场景或其他可靠性、兼容性测试等
    【执行阶段】:集成测试、专项测试(性能、安全、稳定性测试等)
  • P3(生僻):
    【定义】:如果没有可以不使用该级别,该级别用例一般非常少。
      【划分依据】:该用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误,但是那些用例的触发条件非常特殊,仍然应该被植入4级用例中。如界面规范化的测试也可归入4级用例。在实际使用中使用频率非常低、对用户可有可无的功能。
      【执行阶段】:在版本测试中有某些正常原因(包括:环境、人力、时间等)经过测试经理同意可以不进行测试。

四、测试用例组织方式

在编写测试用例前,需要先搭建用例的整体框架,然后在具体的分类下进行编写用例。
位置在Gitee上的项目》测试》测试用例下,具体用例划分原则:在【项目】这个大类下,从【功能模块】出发按照【前端】和【后端】来划分,接下来介绍具体的组织方式。

  • 前端用例组织
    一级目录对应一个独立的功能模块
    二级目录对应某个功能模块下一级菜单
    三级目录对应二级菜单
    …以此类推

  • 后端用例组织
    功能测试:
    一级目录对应一个独立的功能模块
    二级目录对应某个功能模块下一级菜单
    三级目录对应二级菜单
    …以此类推

五、测试用例编写原则

  • 从用户角度出发设计用例:注意用户使用场景,用例的编写不能脱离使用场景,特别是核心功能的测试,用例设计应该达到100%覆盖率
  • 全面性:对于需求说明书和相关技术规范中要求的功能点进行全覆盖测试,要求所有功能均能正常实现。
  • 可测性
  • 简洁、清晰、易理解:测试用例的编写要求清晰、完整的表达测试含义
  • 勿穷举测试用例
  • 勿过于复杂、过于简单

六、测试功能点梳理

编写测试用例前,最好是不要直接去写用例,很容易遗漏掉一些功能点,建议根据需求说明书梳理出测试功能点。
推荐功能点梳理的方法:使用xmind工具
首先,从前端、后端两个方向进行梳理。然后,每个方向下按照模块下的一级、二级等菜单进行划分。
下面以某检验一期项目某检验管理后台功能模块为例,梳理出一级菜单【菜单管理】下的二级菜单【横幅设置】的功能点。
使用Xmind梳理出测试功能点:
【前端】:主要关注页面UI展示排版、按钮、列表、日期、弹框、单行输入框,上传图片等是否可用和合理。(具体可见第八、九章)

  • 页面展示排版正确性的检查
  • 列表检查
  • 添加表单中必填项的检查
  • 输入框的合法、非法值、边界值校验
  • 按钮检查
  • 上传照片大小、格式检查
  • 日期控件检查
    【后端】:主要关注功能的实现,数据的准确性,业务场景的完整性
  • 添加横幅
  • 修改横幅
  • 删除横幅
  • 启用/禁用横幅
  • 顺序调整检查
    编写测试用例时,将以上功能点进行组合设计用例,比如添加–修改-删除,添加-添加-删除 ,修改-修改-修改-删除,这样去组合,以及排序可以遍历:列表的第一个/中间/最后一个进行排序.
    完成测试点梳理之后,结合第七章测试用例编写方法和第八、九章前后端测试点汇总就可以进行具体的测试用例编写了。

七、测试用例编写方法

1.常见的用例设计方法

1.1等价类划分

定义:将输入的数据等价划分成几个类,从每个类里面选出一个测试用例,如果这个测试用例通过,说明这一个类的测试用例都通过。
  • 适用范围:有范围限制的输入框
  • 方法:划分有效等价类和无效等价类
    有效等价类:满足输入数据要求的类
    无效等价类:不满足输入数据要求的类
  • 举例:以I检验的添加横幅为例,对于横幅名称输入长度的测试点设计,假定输入框限制的范围为:2-32长度:
    横幅名称长度校验
    1.小于2位 设计一个测试用例:长度为1
    2.2-32位 设计一个测试用例:长度为10
    3.大于32位 设计一个测试用例:长度为40

1.2边界值分析法

定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
  • 适用范围:
    输入框有范围限制的情况

  • 方法:选择以下三个点
    上点:边界上的点
    离点:离边界最近的点
    内点:范围内的点

  • 举例:仍以上面的为例。
    边界点:2、32
    离点:1、40
    内点:10
    基于1.1等价类划分,边界值分析法补充测试点:
    横幅名称输入

    1. 小于2位 设计一个测试用例:长度为1
    2. 2-32位 设计一个测试用例:长度为10
    3. 大于上32位 设计一个测试用例:长度为40
    4. 等于2、32位 设计两条用例:长度为2,32
      综上一般设计这种有长度限制输入框的用例,是将等价类划分和边界值分析法结合起来使用.

1.3因果图法

定义:因果图是从需求中找出因(输入条件)和果(输出或程序状态的改变),通过分析输入条件之间的关系(组合关系、约束关系等)及输入和输出之间的关系绘制出因果图,再转化成判定表,从而设计出测试用例的方法。
  • 适用场景:各种输入条件之间存在某种相互制约关系或输出结果依赖于各种输入条件的组合时的情况
  • 方法:
    1)分析需求,确定程序的输入与输出。
    2) 分析得出输入与输入之间、输入与输出之间的对应关系,将这些输入与输出之间的关系转换成用例。
  • 举例:
    以添加横幅,其中展示时间输入:时间段展示和永久展示。两种输入对应不同的结果:
    输入 输出
    时间段展示 前端效果:展示开始时间和结束时间
    功能实现效果:横幅区生效时间为时间段
    永久展示 前端效果:不展示开始时间和结束时间
    功能实现效果:横幅区生效时间为永久

1.4场景法

定义:基于用户实际使用场景来设计用例,考虑用户实际使用操作和使用情况。

1.5错误推测法(了解)

定义:基于经验和直接推测程序中可能会发生的错误来设计用例。故这种方法对测试要求比较高。

1)程序中所有可能的错误
2) 容易发生错误的特殊情况
3) 以前产品测试中曾经发现的错误

1.6借助AI自动化生成用例

测试用例的编写对于组合比较多以及页面元素比较多的情况下,可以借助AI自动设计出基础场景的用例,再人工进行复杂场景的组合设计补充。

推荐以下平台:
免费(国内):
1、百度:文心智能体平台https://vzdlrr.smartapps.baidu.com/ (推荐)
2、360AI搜索:https://so.360.com/search/
3、https://kimi.moonshot.cn/
收费(国外):
Chatgpt
借助AI前提是需要将需求的逻辑描述清晰,才能得到比较接近满足需求的用例,在此基础上进行修改和补充。

八、测试点分类汇总

1.基础用例

1.1前端用例检查点分类汇总

前端用例设计主要关注的测试点归纳为以下类:

1.1.1界面

主要关注:标题名称、描述、颜色、布局、样式、滚动条,详细检查如下:

  1. 风格、样式、颜色是否协调
  2. 界面布局是否整齐、协调(保证全部显示出来的,尽量不要使用滚动条
  3. 界面操作、标题描述是否恰当(描述有歧义、注意是否有错别字)
  4. 操作是否符合人们的常规习惯(有没有把相似的功能的控件放在一起,方便操作)
  5. 提示界面是否符合规范(不应该显示英文的cancel、ok,应该显示中文的确定等)
  6. 界面中各个控件是否对齐
  7. 对于信息比较长的文本,文本框有没有提供自动竖直滚动条
  8. 用滚动条移动页面时,页面的控件是否显示正常
  9. 操作顺序是否合理
  10. 背景灰度冻结
  11. 页面分辨率检查,在各种分辨率浏览系统检查系统界面友好性。
  12. 对于正常的功能,用户可以不必阅读用户手册就能使用

1.1.2Button按钮

主要关注:增加/添加、修改/编辑、删除、保存、取消、确定、选择、搜索、上一步、下一步等按钮是否可点击,状态展示是否正确。
1、检查按钮按钮的状态在相应的场景下是置灰还是可点击。
2、检查一些有必要提示的按钮,点击后是否有提示。
3、检查按钮操作后,查看信息回到的页面是否合理。

1.1.3日期控件

1.日期控件是否可编辑
2.日期控件的长度是否合理,以修改时可以把时间全部显示出来为准
3.日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XXXX:XX:XX

1.1.4列表

1.查询结果列表列宽是否合理、标签描述是否合理
2.查询结果列表太宽没有横向滚动提示
3.分页展示,上一页,下一页等是否可用。

1.1.5输入框

主要关注:文本输入框、数值输入框、日期输入框(具体见第九章表格中对于输入框要检查的项)
  • 字符型输入框:字符型输入框、长度检查、空格检查、多行文本框输入、安全性检查
  • 数值型输入框:检查边界值、位数、异常值、特殊字符、安全性检查(不能直接输入就copy)
  • 日期型输入框:关注合法性检查、异常值、特殊字符

1.1.6弹框

  • 检查弹框的最大化、最小化功能是否正常
  • 检查弹框展示的位置是否合理
  • 检查失焦后,弹窗是否会被关闭。

1.1.7图片

  • 检查图片上传的支持的格式。
  • 检查图片上传的大小。
  • 检查图片上传后是否失真。

1.1.8单选/复选框

  • 检查单选后是否可以选中多个,单选后是否可以取消
  • 检查复选框的全选、全不选、部分选中的情况

1.2后端用例测试点分类汇总

后端用例主要关注数据的准确性,业务逻辑是否满足需求。一般在设计用例时,考虑正向的场景时,反向的也要考虑,对于一些边界值也要考虑。用例要设计组合测试、业务场景测试。

1.2.1正反测试

  1. 使用所有默认值进行测试
  2. 根据所有产品文档、帮助文档中描述的内容要进行遍历测试
  3. 所有界面出现是和否的逻辑,要测试
  4. 异常的数据系统是否能够正确响应

1.2.2边界值测试

对于有范围限制的输入框,输入边界值验证系统响应。需要设计边界值测试用例。

1.2.3组合测试

提交表单前,对于每个字段的取值需要进行组合测试用例设计

1.2.4业务场景测试

业务流程,一般会涉及到多个模块的数据,所以在对业务流程测试时,首先要保证单个模块功能的正确性,其次就要对各个模块间传递的数据进行测试,这往往是容易出现问题的地方,测试时一定要设计不同的数据进行测试。

某一功能模块具有最基本的增删改查功能,则需要进行以下测试:

  1. 单项功能测试(增加、修改、查询、删除)
  2. 增加——>增加——>增加 (连续增加测试)
  3. 增加——>删除
  4. 增加——>删除——>增加 (新增加的内容与删除内容一致)
  5. 增加——>修改——>删除
  6. 修改——>修改——>修改 (连续修改测试)
  7. 修改——>增加(新增加的内容与修改前内容一致)
  8. 修改——>删除
  9. 修改——>删除——>增加 (新增加的内容与删除内容一致)
  10. 删除——>删除——>删除 (连续删除测试)

2.进阶测试用例编写(了解)

性能、稳定性、可靠性、安全测试

  • 23
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

如梦@_@

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值