目录
一、测试流程
需求分析:
说明:根据产品需求文档,提取出规则要求
提取规则要求的目的:
- 明确软件有哪些功能和要求
- 为设计测试点做准备
设计测试点:
测试点:要进行验证的点,根据需求规则设计测试点。
设计测试点的目的:
- 防止测试时有遗漏
- 为编写测试用例做准备
测试用例:
说明:将测试点转化为测试执行的文档。
编写用例的目的:
- 指导测试点正确测试实施
- 为执行测试做准备
用例执行:
说明:执行用例就是执行测试。
缺陷管理:
说明:当执行用例结果和预期结果不符时为缺陷,就需要对缺陷进行管理。
缺陷管理目的:
- 测试的目的就是减少软件缺陷(提交缺陷——>等待修复——>验证缺陷)
- 为测试报告做准备
测试报告:
说明:对于本次执行测试缺陷进行分析统计,对于本次测试实施进行总结。
主要内容:
- 缺陷统计
- 缺陷分析
- 遗留缺陷
- 测试总结
二、测试用例
2.1概念
用例:用户使用的案例
测试用例:执行测试时用户案例
英文:Test Case
目的:保证测试点的正确执行
2.2用例编写格式
说明:用例编写格式一般由八大要素组成。
编写示例
微信登录测试点:
- 登录成功
- 密码错误,登录失败
三、设计测试点
3.1等价类
3.1.1概念
3.1.2案例
(验证QQ账号的合法性)
要求:6~10位自然数
步骤:
1.明确需求
- 内容:自然数(0、1、2······)
- 长度:6-10位
2.确定有效和无效等价类
- 有效等价:6-10位
- 无效等价:①小于6位 ②大于10位 ③非自然数
3.提取数据编写测试用例
- 有效等价:8位(12345678)
- 无效等价:①小于6位——5位(12345) ②大于10位——11位(12345678901) ③非自然数
3.1.3适用场景
针对:需要有大量数据测试输入,但是没法穷举测试的地方。
- 输入框
- 下拉列表
- 单选复选框
典型代表:页面输入框类测试
3.1.4执行用例
- 当执行结果和预期结果不一致,则为缺陷。
- 发现缺陷需要进行缺陷管理(提交——>开发修复——>测试验证——>关闭缺陷)
示例:(验证某城市电话号码正确性)
要求:
- 区号:空或者是三位数字
- 前缀码:非“0”且非“1”开头的三位数字
- 后缀码:四位数字
步骤:
1.明确需求
2.确定有效和无效等价类
3.提取数据编写测试用例
4.执行用例
3.2边界值
3.2.1概念
说明:选取正好等于、刚好大于、刚好小于边界的值作为测试数据。
边界值法设计用例步骤:
- 明确需求
- 确定有效和无效等价类
- 确定边界范围值
- 提取数据编写测试用例
3.2.2案例
需求:通过边界值法验证标题长度的合法性
要求:标题长度大于0,小于等于30个字符(0<标题长度<=30)
步骤:
1.明确需求
- (0,30]
2.确定有效和无效等价类
- 有效:4
- 无效:-1,31
3.确定边界值
- 上点:0,30
- 离点:-1,1,39,31
- 内点:10
4.提取数据编写用例
优化:
- 上点:必选
- 内点:必选
- 离点:开内闭外
5.执行用例
3.2.3使用场景
- 在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)
- 常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰语
- 典型代表:有边界范围的输入框类测试
示例:(验证QQ号的合法性)
要求:6~10位自然数
步骤:
1.明确需求
2.确定有效和无效等价类
3.确定边界值
4.提取数据编写用例
5.用例执行
3.3判定表
3.3.1判定表使用原因
案例:验证“若用户欠费或者关机,则不允许被叫”功能测试
说明:
- 等价类、边界值分析法主要关注单个输入条件的测试
- 并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试
3.3.2概念
1.定义:是一种以表格形式表达多条件逻辑判断的工具
2.组成:
- 条件桩:列出问题中的所有条件,列出条件的次序无关紧要。
- 动作桩:列出问题中可能采取的操作,操作的排列顺序没有约束。
- 条件项:列出条件对应的取值,所有可能情况下的真假值。
- 动作项:列出条件项的各种取值情况下应该采取的动作结果。
3.规则
- 判定表中贯穿条件项和动作项的一列就是一条规则
- 假设有n个条件,每个条件的取值有两个(0,1),全组含有2的n次方种规则
4.判定表设计用例步骤
1.明确需求 | |
2.画出判定表 | 列出条件桩和动作桩 填写条件项,对条件进行全组合 根据条件项的组合确定动作项 简化合并相似规则(有相同的动作) |
3.根据规则编写测试用例 |
3.3.3案例
1.需求分析
- 如果金额大于500元,又未过期,则发出批准单和提货单
- 如果金额大于500元,但过期了,则不发批准单与提货单
- 如果金额小于等于500元,则不论是否过期都发出批准单和提货单
- 在过期的情况下不论金额大小还需要发出通知单
2.画判定表
3.设计测试用例
4.执行用例
3.3.4使用场景
- 有多个输入条件,多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有依赖(制约)关系。
- 判定表一般适用于条件组合数量较少的情况(比如4个条件以下)
示例:(文件修改规则)
1.明确需求
- 输入的第一列字符必须是A或B
- 第二列字符必须是一个数字
- 如果第一列字符不正确,则给出信息L
- 如果第二列字符不正确,则给出信息M
- 如果两列字符输入正确,则修改文件成功
2.画判定表
3.设计测试用例
4.用例执行
3.4场景法
3.4.1概念
说明:场景法也可以叫做流程图法,是用流程图描述用户的使用场景,然后通过覆盖流程路径来设计测试用例。
意义:
- 用户使用角度:用户平时使用的不是单个功能,而是多个功能组合起来进行使用。
- 测试人员角度:平时测试的都是单个功能点进行测试,容易忽略多个功能的组合测试。
3.4.2案例
ATM机取款流程
ATM机取款流程——流程图
设计测试用例
用例执行
3.4.3使用场景
根据实际的应用场景来测试业务用例可以使用场景法。
四、缺陷管理
4.1概念
1.定义:软件在使用过程中存在的任何问题都叫软件的缺陷,简称bug。
2.缺陷评判标准:
3.缺陷产生原因:
需求阶段:需求描述不易理解,有歧义、错误等
设计阶段:设计文档存在错误或者缺陷
编码阶段:代码出现错误
运行系统:软硬件系统本身故障导致软件缺陷
4.软件缺陷的生命周期:
5.软件缺陷的类型:
4.2缺陷编写
1.缺陷的核心内容
2.缺陷描述
案例:
3.缺陷的跟踪流程
4.缺陷的提交流程
5.缺陷的提交要素
6.提交缺陷的注意事项
4.3缺陷管理工具
1.禅道
禅道项目管理软件 - 开源、免费的项目研发测试管理工具 (zentao.net)https://www.zentao.net/特点:
- 国产、免费、开源、简单、轻量级
- 三管融合(产品管理、项目管理、质量管理)
2.禅道的使用用户
3.禅道使用流程
五、抓包
5.1抓包目的
- 功能测试时跳过ui界面验证,验证后端程序处理能力。(如:请求支付100元,通过抓包修改请求价格0.1元,查看后端程序是否能正常处理)
- 分析前端bug还是后端bug。(如:ui显示数据错误,提交bug时需要指定提交人,那是提交给前端开发还是后端开发?)
- 弱网测试(如:app应用模拟4G、3G网络)
- 接口测试时,缺乏接口描述文档,需要抓包获取。(如:查看支付宝请求信息)
5.2抓包概念
说明:通过工具抓取前端与后端的通信内容
5.3抓包知识
- 抓包操作(http、https)
- 断点操作-拦截修改(请求、响应)
- 弱网测试
5.4抓包工具
- fidder(windows)断点、弱网、录制请求和响应
- Charles(mac、windows)断点、弱网、录制请求和响应
- 浏览器开发者工具(查看请求和响应首选)