软件测试
软件：控制计算机硬件工作的工具
定义
-
使用技术手段验证软件是否满足使用需求
目的：
- 减少软件缺陷（也就是bug）--> 保证软件质量
测试主流技能
- 功能测试：验证程序功能是否满足需求（根据文档）
- 自动化测试：代码去测试 --> 使用代码或工具代替手工，对项目测试
- 接口测试：使用代码或工具对服务端提供的接口进行测试（验证程序中的接口是否访问正常）
- 性能测试：模拟多人使用软件，查找服务器缺陷 （工具/代码）
7种测试分类的区别
按测试阶段划分
- 单元测试：针对程序源代码进行测试（开发自行测试）
- 集成测试：又称接口测试，针对模块之间访问地址进行测试。
- 系统测试：对整个系统进行测试（功能、兼容、文档等测试）（针对程序的功能和非功能）
- 验收测试：分为内测、公测，使用不同人群来发掘项目缺陷
按代码可见度划分
- 黑盒测试：不关注源代码，针对程序UI功能进行测试
- 源代码不可见
- UI功能可见
- 灰盒测试：针对程序部分代码进行测试（接口）
- 部分源代码可见 -- （集成测试 -- 接口
- 功能不可见
- 白盒测试：针对程序源代码进行测试
- 全部代码可见 （测源代码 --> 单元测试
- UI功能不可见
质量模型的重点五项
- 概念：衡量一个优秀软件的维度（方向）
- 功能性
- 数量为【】个
- 功能是否正确实现
- 错误处理的情况
- 性能
- 服务器每秒处理请求数
- 服务器硬件配置是否满足
- 兼容性
- 浏览器（谷歌、IE、火狐、欧朋、苹果）
- 操作系统：Win系统（Win7、Win8、Win10）
- 手机：分辨率、品牌、系统、网络、其他
- 易用性
- 简洁
- 友好
- 流畅
- 美观
- 可靠性
- 无响应
- 卡顿：响应时间慢
- 死机：系统崩溃
- 安全
- 数据的传输 - > 传输加密
- 数据的存储 - > 存储加密
- 可移植性
- 网站数据迁移（比如换一个好一点的服务器时)
- 可维护性
总结：
质量模型：功能、性能、兼容、易用、安全、可靠性、移植性、维护性
测试流程的6个步骤
- 需求评审
- 确保各部门需求理解一致
- 计划编写（明确哪些功能是核心的）
- 测什么，谁来测，怎么测
- 用例设计
- 验证项目是否符合需求的操作文档
- 用例执行
- 项目模块开发完成，开始执行用例文档实施测试
- 缺陷管理
- 发现不一致后 --> 对缺陷进行管理的过程
- 测试报告
- 实施测试后得到的结果文档
测试用例
用例：用户使用的案例
- 测试用例：为测试项目而设计的执行文档
- 作用
- 防止漏测
- 实施测试的标准
- 作用
- 用例设计编写模式
- 用例编号：项目 _ 模块 _ 编号
- 用例标题：预期结果（测试点）
- 模块/项目：所属项目或模块
- 优先级：表示用例的重要程度或者影响力 P0 ~ P4 （P0最高） ---> 用户用的频率最高的一定是核心
- 测试步骤：描述操作步骤
- 测试数据：操作的数据，没有的话可以为空
- 预期结果：期望达到的结果
练习
根据以下测试点编写用例
- 需求：QQ登录（4条）
- 账号为空
- 账号未注册
- 密码为空
- 密码错误
等价类划分法
- 说明：在测试所有数据中，具有某种共同特征的数据集合进行划分
- 分类：
- 有效等价类：满足需求的数据集合
- 无效等价类：不满足需求的数据集合
- 步骤：
- 明确需求
- 确定有效和无效等价类
- 提取数据编写测试用例（根据有效和无效）
重点：有效等价和无效等价各取一个即可
练习
-
需求1：验证QQ账号的合法性
要求：6-10位自然数
还要考虑到非自然数和为空的情况
分析需求时：拆
-
需求2：验证某城市电话号码的正确性
要求：
- 区号：空或者是三位数字
- 前缀码：非 "0" 且非 "1" 开头的三位数字
- 后缀码：四位数字
- 一共2个有效用例，8个无效用例
-
适用场景
- 针对：需要有大量数据测试输入，但是没法穷举测试的地方
- 输入框
- 下拉列表
- 单选复选框
- 典型代表：页面的输入框类测试
- 针对：需要有大量数据测试输入，但是没法穷举测试的地方
边界值
需求：判断输入的数据是否小于-99或大于99，如果小于-99或大于99给出错误提示
--> 关注边界值 -99 和 99
说明：使用边界值解决边界位数限制问题
-
边界范围节点
-
选取正好等于、刚好大于，刚好小于边界的值作为测试数据
- 上点：边界上的点（正好等于）
- 离点：距离上点最近的点（刚好大于、刚好小于）
- 内点：范围内的点（区间范围内的数据）
- 有关范围限制，最多：7条用例（暂时未优化）
-
边界值能解决位数限制问题，但是不能解决类型问题（要结合等价类）
-
边界值法设计用例步骤
- 明确需求
- 确定有效和无效等价类（此处只用考虑类型）
- 确定边界范围值
- 提取数据编写测试用例
-
练习
需求：通过边界值法验证标题长度的合法性
要求：标题长度大于0，小于等于30个字符
-
优化：
-
结论：7个优化为5个点
重点：开内闭外（开区间选包含的点，闭区间选不包含的点）
-
上点：必选（不考虑区间开闭）
-
内点：必选（建议选择中间范围）
-
离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）
10<a<=20 --> 使用开闭区间表达：(10,20]
开区间：不包含 闭区间：包含
- 开区间指的是区间边界的两个值不包括在内 （a,b)
- 闭区间指的是区间边界的两个值包括在内 [a,b]
- 半开半闭区间：开区间一边的边界值不包括在内，而闭区间一边的边界值包括在内 [a,b),(a,b]
-
-
总结：
强调：单个输入框，常用的方式:边界+等价类
判定表法
-
案例：验证“若用户欠费或关机，则不允许主被叫”功能的测试
-
说明：
- 等价类边界值分析法主要关注单个输入类的条件的测试
- 并未考虑输入条件间的各种组合、输入条件与输出结果之间有相互制约关系的测试
-
定义：是一种以表格形式表达多条件逻辑判断的工具
-
组成：
- 条件桩：列出问题中的所有条件，列出条件的次序无关紧要
- 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
- 条件项：列出条件对应的取值，所有可能情况下的真假值
- 动作项：列出条件项的、各种取值情况下应该采取的动作结果
- 规则：
- 判定表中贯穿条件项和动作项的一列就是一条规划
- 假设有n个条件，每个条件的取值有两个（0，1），全组合有2的n次方种规则
判定表法设计用例步骤
-
明确需求
-
画出判定表
1）列出条件桩和动作桩
2）填写条件项，对条件进行全组合
3）根据条件项的组合确定动作项
4）简化、合并相似规则（有相同的动作）
-
根据规则编写测试用例
案例：
-
需求：
- 输入的第一列字符必须是A或B
- 第二列字符必须是一个数字
- 如果第一列字符不正确，则给出信息L
- 如果第二列字符不正确，则给出信息M
- 如果两列字符输入正确，则修改文件成功
-
判定表
-
分析：只有第一列和第二列两个条件 --- 4条用例
-
-
用例
使用场景
-
有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约关系）
-
判定表一般适用于条件组合数量较少的情况（比如四个条件以下）
-
若条件超过四个，就不适合覆盖所有条件，应采用（正交法）来解决
业务测试覆盖
流程图
-
业务用例是根据流程图来梳理的
-
-
先测试业务，再测试单功能、单模块、单页面
-
作用：梳理业务用例
-
工具：
- processon
- visio
场景法
-
说明
- 场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
-
意义：
-
用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试
-
-
适用场景
- 根据实际的应用场景，来测试业务用例，可以使用场景法
-
案例：ATM机取款流程
-
流程图：
-
另一种流程图表达方式：
-
用例：
错误推荐法
- 介绍
- 定义：通过经验推测系统可能出现的问题
- 思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷
- 场景：
- 时间紧任务量大时，根据之前项目类似的经验，找出易出错的模块重点测试
- 实践宽裕 通过该方法列出之前出现问题较多的模块，再次测试
- 应用场景：当项目用例都测试完毕，且bug都修复完成，离上线还有一段时间，在这段时间中可是使用错误推荐法复测主要业务或测试未覆盖的功能。
用例执行
- 说明：执行结果与用例的期望结果不一致（含义），为缺陷
- 用例执行不通过为缺陷，需要进行缺陷管理。
缺陷
-
定义
- 软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。
缺陷的判定标准
- 软件未实现需求（规格）说明书中明确要求的功能 - 少功能
- 软件出现了需求（规格）说明书中指明不应该出现的错误 - 功能错误
- 软件实现的功能超出需求（规格）说明书指明的范围 - 多功能
- 软件未实现需求（规格）说明书中虽未明确指定 - **隐性功能错误**（缺少隐性功能）
- 软件难以理解，不易使用，运行缓慢，用户体验不好 - 不易使用
1. 少功能
2. 功能错误
3. 多功能
4. 缺少隐性功能
5. 易用性
缺陷产生的原因
- 需求阶段
- 需求描述不易理解，有歧义，错误等
- 设计阶段
- 设计文档存在错误或者缺陷
- 编码阶段
- 代码出现错误
- 运行阶段
- 软硬件系统本身故障导致软件缺陷
1. 需求文档
2. 架构设计
3. 编码实现
4. 环境（硬件、软件）
软件缺陷的生命周期
- 软件缺陷的核心内容
- 缺陷的标题：描述缺陷的核心问题
- 缺陷的预置条件：缺陷产生的前提
- 缺陷的复现步骤：复现缺陷的过程
- 缺陷的预期结果：希望得到的结果
- 缺陷的实际结果：实际得到的结果
- 缺陷的必要附件：图片、日志等信息（证据）
缺陷提交要素
- 缺陷报告编号
- 缺陷的唯一性标志
- 严重程度
- 严重（S1）：主功能
- 一般（S2）：次要功能
- 微小（S3）：易用性，界面
- 建议（S4）：建议性问题
- 缺陷优先级
- Priority 0 ：24小时之内解决
- Priority 1 ：发布前必须修复
- Priority 2：可以在下一个版本中修复
- Bug类型
- 代码错误，兼容性问题，设计缺陷，性能问题
- 缺陷状态
- New：新建
- Open：打开
- Closed：关闭
- Postponed：延期
软件缺陷类型
1. 功能错误
2. 错误界面（UI）
3. 兼容性
4. 数据
5. 易用性
6. 改进建议
7. 架构
工作流程
- 设计用例 --> 执行用例（执行测试）--> 缺陷（提交、验证、关闭）
- 缺陷定义：任何问题（bug）
- 缺陷标准：多功能、少功能、错误、缺少隐性功能、易用性
- 描述缺陷：缺陷标题、前置条件、复现步骤、预期结果、实际结果、附件备注
- 提交缺陷信息：指派人、缺陷等级、修复优先级、类型、状态（统计缺陷）
案例
- 单模块用例设计
缺陷编写
缺陷报告示例（Excel）
缺陷的跟踪流程
提示：知道测试和开发流程中涉及的工作即可
提交缺陷的注意事项
可重现
-
缺陷可以复现
-
复现相关：
Bug复现步骤是什么意思？ 例如，您是一名软件测试人员，在测试过程中意外或故意发现错误，然后向上述人员或开发人员提供反馈。为了避免开发人员无意识的搜索浪费时间，您需要在测试中写出bug的步骤（尽可能详细），然后让开发人员按照您的步骤找到您找到的bug行，以确认它是否是bug，这有助于开发人员在最短的时间内修改bug 软件测试人员在测试过程中无意或有意发现一个bug，他们会反馈给上面或开发者。为了避免开发人员无意识的搜索浪费时间，您需要在测试中写出bug的步骤（尽可能详细），然后让开发人员按照您的步骤找到您发现的bug，并确认是否是bug有助于开发人员在最短时间内修改bug。
唯一性
- 一个缺陷上报一个问题
规范性
- 符合公司或者项目要求
面试题：
- 发现缺陷后，首先会怎么办？
- 确定Bug可复现，确定是Bug
- 提交时，要检查缺陷是否已存在
缺陷编写规范
准确
- 描述的信息是正确的
具体
- 有细节且是真实待定的
简洁易懂
- 描述简单容易理解
次序清晰
- 描述缺陷过程有条件，有先后顺序
缺陷管理工具
1.项目管理工具 - 管理缺陷（禅道、JIRA、TFS）
2.Excel管理缺陷
禅道（项目管理工具）
-
特点
- 三权分立
- 产品部门 —— 构想者
- 研发部门 —— 执行者
- 测试部门 —— 保证者
- 四角协同（角色）
- 产品经理
- 项目经理
- 研发团队
- 测试团队
- 三权分立
-
使用流程图
前面两个是管理用例，后面两个是管理缺陷
- 禅道使用流程
-
使用禅道管理缺陷
- 登录
-
创建缺陷
-
提交缺陷
-
关闭缺陷