软件及测试
定义
软件：控制计算机工作的工具
软件测试：使用技术手段验证软件是否满足使用需求
测试目的：减少软件缺陷，保障软件的质量
测试分类
按照测试阶段划分：
- 单元测试：针对程序的源代码进行测试（一般由开发进行）
- 集成测试：又称接口测试，针对模块之间的访问地址进行测试
- 系统测试：对整个系统进行测试，包括功能、兼容、文档等测试
- 验收测试：主要分为内测、公测，使用不同人群来发掘项目缺陷
按照代码可见度划分：
- 黑盒测试：代码不可见，UI功能可见
- 灰盒测试：部分源代码可见，功能可见
- 白盒测试：全部代码可见
质量模型
说明:衡量一个优秀软件的维度
- 功能性：
- eg:需求：10个功能；每个功能详情
- 功能数量正确
- 功能正确实现
- 错误处理情况（eg密码错误等）
- 性能：
- 兼容性
- 浏览器：谷歌、IE、苹果、火狐、欧朋
- 操作系统：win7、win8、win10、其他
- 手机：分辨率、品牌、系统、网络、其他
- 易用性
- 可靠性
- 安全
- 可移植性
- 可维护性
测试流程
- 需求评审：各部门需求理解保持一致；测试需落地需求中有多少功能，哪些是核心功能；
- 计划编写：测什么、谁来测、怎么测
- 用例设计：验证项目是否符合需求的操作文档
- 用例执行：项目开发完成后开始执行用例文档实施测试
- 缺陷管理：对缺陷进行管理的过程
- 测试报告：实施测试结果文档
测试用例
- 用例：用户使用的案例
- 测试用例：为测试项目而设计的执行文档
- 测试用例的作用：
- 用例设计：
- 8大要素：用例编号、用例标题、项目/模块、优先级、前置条件、测试步骤、测试数据、预期结果
- 设计编写格式：
- 用例编号：项目_模块_编号
- 用例标题：预期结果（测试点）
- 项目/模块：所属项目或模块
- 优先级
- 前置条件：执行该用例需要的前置操作
- 测试步骤：描述操作步骤
- 测试数据：有就写，没有就不写
- 预期结果
练习：
需求：QQ登录
- 账号为空
- 账号为注册
- 密码为空
- 密码错误
| 用例编号 | 用例标题 | 模块 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
|---|
| QQ_login_001 | 账号为空，登录失败 | 登录 | p1 | 1、打开登录页面； 2、网络正常 | 1、输入账号；2、输入密码；3、点击登录 | 账号：空；密码“123” | 登录失败，提示账号不可为空 |
| … | | | | | | | |
测试用例设计方法
等价类
场景：对穷举场景设计测试点
说明：在所有测试数据中，具有某种共同特征的数据集合进行划分
分类：
- 有效等价类：满足需求的数据集合
- 无效等价类：不满足需求的数据集合
步骤：
- 明确需求
- 确定有效和无效等价类
- 提取数据编写测试用例
eg、验证qq号的合法性，要求6-10位自然数
需求：长度：6-10位； 类型：自然数
有效等价：6-10位自然数
无效等价：小于6位自然数；大于10位自然数；6-10位非自然数；空
提取数据：7位：1234567；5位：12345；13位：1234567890123
边界值
定义：选取正好等于、刚好大于、刚好小于边界的值作为测试数据
- 上点：边界上的点(刚好等于)
- 离点：距离上点最近的点(刚好大于、刚好小于)
- 内点：范围内的点
步骤：
- 明确需求
- 确定有效等价类和无效等价类
- 确定边界范围值
- 提取数据编写测试用例
优化：
结论：7个点优化为5个点
上点：必选（不考虑区间开闭）
内点：必选（建议选择中间的点）
离点：开内闭外（开区间选择内部离点，闭区间选择外部离点）
判定表法
定义：是一种以表格形式表达多条件逻辑判断的工具
组成：
- 条件桩：列出问题中的所有条件，列出条件的次序无关紧要
- 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
- 条件项：列出条件对应的取值，所有可能情况下的真假值
- 动作项：列出条件项的，各种可能取值情况下应该采取的动作结果
规则：
- 判定表中，贯穿条件项和动作项的一列就是一条规则
- 假设有n个条件，每个条件的取值有两个，那么有2的n次方种规则
步骤：
- 明确需求
- 画判定表
- 提取数据编写用例
场景法
定义：场景法也叫流程图法，是用流程图来描述用户的使用场景，然后通过覆盖流程路径来设计测试用例
意义：
- 用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
- 测试人员角度：平时都是单个功能点进行测试，容易忽略多个功能的组合测试
说明：
- 覆盖业务测试需要使用流程图法
- 先测试业务，在测试单功能、单模块、单页面
- 业务用例需要流程图来梳理，需要学会画流程图和看懂流程图
错误推荐法
应用场景：当项目用例都执行完毕，且bug修复完成，离上线还有一段时间，可以使用错误推荐法去复测主要业务 或 未覆盖的业务
缺陷
定义：软件在使用过程中存在的任何问题都是缺陷，简称bug
标准：
- 少功能：软件未实现需求规格说明书中明确要求的功能
- 功能错误：软件出现了需求规格说明书中不应该出现的错误
- 多功能：软件实现的功能超出需求规格说明书中指明的范围
- 隐性功能错误：软件未实现需求规格说明书中虽未明确指明，但是应该实现的要求
- 不易使用：软件难以理解，不易使用，运行缓慢，用户体验不好
缺陷产生的原因：
- 需求阶段：需求描述不易理解，有歧义、错误等
- 设计阶段：设计文档存在错误或者缺陷
- 编码阶段：代码出现错误
- 运行阶段：软硬件系统本身故障导致缺陷
缺陷的生命周期：需求规格说明(可能产生bug)->设计(可能产生bug)->编码(可能产生bug)->测试(发现bug)->故障分类->故障隔离->故障解决(可能产生bug)
缺陷核心内容：
- 标题：描述缺陷的核心问题
- 预置条件：缺陷产生的前提
- 缺陷的复现步骤
- 预期结果
- 实际结果
- 必要附件：日志、截图、视频等
缺陷的提交要素：编号、严重程度、优先级、bug类型、缺陷状态
缺陷类型：功能错误、界面UI错误、兼容性、数据、易用性、改进建议、架构