软件测试基础理论
一:测试常用分类
-
按阶段划分
- 单元测试:针对程序源代码进行测试(开发)
- 集成测试:又称接口测试,主要针对模块或系统与系统之间的接口进行验证(交汇)
- 系统测试:针对软件全面进行验证(功能,兼容,文档)
- 验收测试:使用内测、公测来实现
- 内测:公司内部进行测试。
- 公测:让玩家来测试
-
代码可见度划分
- 黑盒测试:又称功能测试(完全看不见程序源代码。只能针对功能进行验证)
- 灰盒测试:又称接口测试(看不见部分代码)
- 白盒测试:又称单元测试(针对程序源代码进行测试)
-
总结
1.系统测试和黑盒测试重点核心是**功能测试** 2.集成测试和灰盒测试又称**接口测试** 3.单元测试和白盒测试是对**代码**进行测试 4.自动化测试归属**功能测试** 5.性能测试、安全测试归属**专项测试**
二:冒烟测试
- 大规模执行测试之前,针对程序主要功能进行验证,保证程序具备可测性。
- 面试题:提测标准是什么?–冒烟测试通过!测试之前要怎么做?–冒烟测试
三:模型
一:质量模型
- 功能性:功能满足需求
- 性能效率:性能满足实际需求
- 兼容性:软件能与主流硬件和软件兼容
- 易用性:便于使用
- 可靠性:性能和功能应用可靠
- 信息安全:信息在传输或者存储过程的安全程度
- 可维护性:便于维护
- 可移植性:具备迁移和便捷性
重点:功能、性能、兼容、易用、安全
二:测试模型
- W模型–蓝色开发–绿色测试
1.提取需求,根据需求去设计测试点
2.根据测试点编写用例覆盖测试点,执行测试点
开发流程:需求分析、概要设计、详细设计、编码、集成、实施、交付
测试流程:(系统测试设计、集成测试设计、单元测试设计)、单元测试、集成测试、系统测试、验收测试
四:测试流程
一:需求分析
- 前置:阅读需求分析文档,记录不明确之处
1.确定各部分对需求理解一致
2.站在不同角度对需求进行(查漏补缺)
二:计划编写
- 测什么:测试目标及范围
- 谁来测:人员进度安排
- 怎么测:测试策略、测试工具
三:测试用例设计
- 验证项目是否符合需求的操作文档(设计执行测试的文档)
说明:设计测试的文档
四:测试用例执行
- 项目模块开发完成开始执行用例文档实施测试
说明:执行测试的文档
五:缺陷管理
- 对缺陷进行管理的过程
说明:提交 -> 验证 -> 关闭
六:测试报告
- 实施测试结果文档
说明:测试目标、测试过程、缺陷统计、缺陷分析、测试总结
五:测试用例
1.含义
用例:用户使用的案例
测试用例:执行测试的文档(用户使用的案例)
考虑点:质量模型(功能、性能、兼容、易用、安全)
2.测试用例设计编写格式
- 用例编号:项目+模块+编号
- 用例标题:预期结果+操作步骤
- 模块/项目:所属项目或模块
- 前置条件:要执行此条用例,有哪些前置操作
- 优先级:表示用例的重要程度或者影响力P0~P4(P0最高)
- 测试步骤:描述操作步骤
- 测试数据:操作的数据,没有的话可以为空
- 预期结果:期望达到的结果
- 实际结果:验证用例的结果
用例编号 | 用例标题 | 模块/项目 | 前置条件 | 优先级 | 测试步骤 | 测试数据 | 预期结果 | 实际结果 |
---|
六:等价类(解决穷举问题)
1.等价划分
- 说明
- 在所有测试数据中,具有某种共同特征的数据集合进行划分
- 分类
- 有效等价类:满足需求的数据集合进行划分
- 无效等价类:不满足需求的数据集合
- 步骤
- 1.明确需求
- 2.确定有效和无效等价类
- 3.提取数据编写测试用例
2.案例
- 需求:6~10位自然数
- 明确需求
- 6~10位并且是自然数
- 确定有效和无效等价类
- 有效等价类:6~10位并且是自然数(选其其中一位)
- 无效等价类:5位自然数:12345, 8位非然数:a1~7(所有无效数据集合,取一个即可)
- 提取数据编写测试用例
- 有效等价类:12345678
- 无效等价类
- 12345
- 1234567a
用例编号 | 用例标题 | 模块/项目 | 前置条件 | 优先级 | 测试步骤 | 测试数据 | 预期结果 | 实际结果 |
---|---|---|---|---|---|---|---|---|
qq_001 | 5位自然数 | 打开qq程序 | P0 | 1.输入qq号 2.点击验证 | 12345 | 不合法 | ||
qq_002 | 8位非然数 | 打开qq程序 | P0 | 1.输入qq号 2.点击验证 | 1234567a | 不合法 | ||
qq_003 | 8位自然数 | 打开qq程序 | P0 | 1.输入qq号 2.点击验证 | 12345678 | 合法 |
七:边界值分析法
1.边界范围节点
- 选取正好等于、刚好大于、搞好小于边界的值作为测试数据
- 上点:边界上的点(正好等于)
- 离点:距离上点最近的点(刚好大于、刚好小于)
- 内点:范围内的点(区间范围内的数据)
2.边界值设计用例步骤
1.明确需求
2.确定有效和无效等价类
3.确定边界范围值
4.提取数据编写测试用例
八:判定表(多个条件判断)
1.判定表定义及组成部分
-
是一种以表格形式表达多条件逻辑判断的工具
-
组成:
- 条件桩:列出问题中的所有条件,列出条件的次序无关紧要。
- 动作桩:列出问题中可能采取的操作,操作的排列顺序没有约束。
- 条件项:列出条件对应的取值,所有可能情况下的真假值。
- 动作项:列出条件项的、各种取值情况下应该采取的动作结果。
-
规则
- 判定表中贯穿条件项和动作项的一列就是一条规则
- 假设有n个条件,每个条件的取值有两个(0,1),全组合有2的n次方种规则
条件 | 是否欠费 是否关机 | 是 是 | 是 否 | 否 是 | 否 否 |
---|---|---|---|---|---|
操作 | 是否允许主被叫 | 否 | 否 | 否 | 是 |
2.判定表法设计用例步骤
- 明确需求
- 画出判定表
- 列出条件桩和动作桩
- 填写条件项,对条件进行全组合
- 根据条件项的组合确定动作项
- 简化、合并相似规则(有相同的动作)
- 根据规则编写测试用例
-
应用场景
- 有多个输入条件,多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有依赖(制约)关系
- 判定表一般适用于条件组合数量较少的情况(比如4个条件以下)
- 提示:如果碰到项目中多条件组合大于4个相互依赖,可以使用(正交表和因果图来实现)
九:缺陷管理–禅道
- https://biz.demo16.zentao.net/my.html
1.缺陷的定义
- 软件在使用过程中存在的任何问题都叫软件的缺陷,简称bug。
2.缺陷的判定标准
- 软件为实现需求说明书中明确要求的功能–少功能
- 软件出现了需求说明书中指明不应该出现的错误–功能错误
- 软件实现的功能超出需求说明书指明的范围–多功能
- 软件未实现需求说明书中虽未明确指明但应该实现的要求–隐形功能错误
- 软件难以理解,不易使用,运行缓慢,用户体验不好–不易使用
3.缺陷产生的原因
- 需求
- 需求阶段:需求描述不易理解,有歧义,错误等。
- 设计
- 设计阶段:设计文档存在错误或者缺陷。
- 编码
- 编码阶段:代码出现错误。
- 运行
- 运行阶段:软硬件系统本身故障导致软件缺陷。
4.缺陷提交要素
- 缺陷报告编号:缺陷的唯一标志
- 严重程度
- 严重(S1):主功能
- 一般(S2):次要功能
- 微小(S3):易用性、界面
- 建议(S4):建议性问题
- 缺陷优先级
- Priarity 0 :24小时之内解决
- Priarity 1 : 发布前必须解决
- Priarity 2 :可以在下一个版本中修复
- Bug类型:代码错误、兼容性问题、设计缺陷、性能问题(质量模型)
- 缺陷状态:
- New:新建
- Open:打开
- Closed:关闭
- Postpone:延期
5.禅道使用流程
- [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oWApwVrn-1677672630802)(https://tomatoz.oss-cn-guangzhou.aliyuncs.com/Typora/image-20221201131235478.png)]
十:缺陷编写
1.缺陷报告示例
- 标题:操作数据描述+预期+实际
2.缺陷的跟踪流程
发现BUG后,首先确认BUG可复现
- New:新建
- Open:打开
- Closed:关闭
- Postpone:延期
5.禅道使用流程
十:缺陷编写
1.缺陷报告示例
- 标题:操作数据描述+预期+实际
2.缺陷的跟踪流程
发现BUG后,首先确认BUG可复现