软件测试基础学习笔记

软件及测试

定义

软件：控制计算机工作的工具
软件测试：使用技术手段验证软件是否满足使用需求
测试目的：减少软件缺陷，保障软件的质量

测试分类

按照测试阶段划分：

• 单元测试：针对程序的源代码进行测试（一般由开发进行）
• 集成测试：又称接口测试，针对模块之间的访问地址进行测试
• 系统测试：对整个系统进行测试，包括功能、兼容、文档等测试
• 验收测试：主要分为内测、公测，使用不同人群来发掘项目缺陷

按照代码可见度划分：

• 黑盒测试：代码不可见，UI功能可见
• 灰盒测试：部分源代码可见，功能可见
• 白盒测试：全部代码可见

质量模型

说明:衡量一个优秀软件的维度

• 功能性：
  • eg:需求：10个功能；每个功能详情
    • 功能数量正确
    • 功能正确实现
    • 错误处理情况（eg密码错误等）
• 性能：
  • eg：需求：预估每日在线20w
    • 服务器每秒处理请求数
    • 服务器硬件配置是否满足
• 兼容性
  • 浏览器：谷歌、IE、苹果、火狐、欧朋
  • 操作系统：win7、win8、win10、其他
  • 手机：分辨率、品牌、系统、网络、其他
• 易用性
  • 简洁、友好、流畅、美观
• 可靠性
  • 无响应
  • 卡顿、响应时间慢
  • 死机、系统崩溃
• 安全
  • 传输加密
  • 存储加密
• 可移植性
  • 网站数据迁移
• 可维护性

测试流程

1. 需求评审：各部门需求理解保持一致；测试需落地需求中有多少功能，哪些是核心功能；
2. 计划编写：测什么、谁来测、怎么测
3. 用例设计：验证项目是否符合需求的操作文档
4. 用例执行：项目开发完成后开始执行用例文档实施测试
5. 缺陷管理：对缺陷进行管理的过程
6. 测试报告：实施测试结果文档

测试用例

• 用例：用户使用的案例
• 测试用例：为测试项目而设计的执行文档
• 测试用例的作用：
  • 防止漏测
  • 实施测试的标准
• 用例设计：
  • 8大要素：用例编号、用例标题、项目/模块、优先级、前置条件、测试步骤、测试数据、预期结果
  • 设计编写格式：
    • 用例编号：项目_模块_编号
    • 用例标题：预期结果（测试点）
    • 项目/模块：所属项目或模块
    • 优先级
    • 前置条件：执行该用例需要的前置操作
    • 测试步骤：描述操作步骤
    • 测试数据：有就写，没有就不写
    • 预期结果

练习：
需求：QQ登录

1. 账号为空
2. 账号为注册
3. 密码为空
4. 密码错误

用例编号	用例标题	模块	优先级	前置条件	测试步骤	测试数据	预期结果
QQ_login_001	账号为空，登录失败	登录	p1	1、打开登录页面； 2、网络正常	1、输入账号；2、输入密码；3、点击登录	账号：空；密码“123”	登录失败，提示账号不可为空
…

测试用例设计方法

等价类

场景：对穷举场景设计测试点
说明：在所有测试数据中，具有某种共同特征的数据集合进行划分
分类：

• 有效等价类：满足需求的数据集合
• 无效等价类：不满足需求的数据集合

步骤：

1. 明确需求
2. 确定有效和无效等价类
3. 提取数据编写测试用例

eg、验证qq号的合法性，要求6-10位自然数
需求：长度：6-10位； 类型：自然数
有效等价：6-10位自然数
无效等价：小于6位自然数；大于10位自然数；6-10位非自然数；空
提取数据：7位：1234567；5位：12345；13位：1234567890123

边界值

定义：选取正好等于、刚好大于、刚好小于边界的值作为测试数据

• 上点：边界上的点(刚好等于)
• 离点：距离上点最近的点(刚好大于、刚好小于)
• 内点：范围内的点

步骤：

1. 明确需求
2. 确定有效等价类和无效等价类
3. 确定边界范围值
4. 提取数据编写测试用例

优化：
结论：7个点优化为5个点
上点：必选（不考虑区间开闭）
内点：必选（建议选择中间的点）
离点：开内闭外（开区间选择内部离点，闭区间选择外部离点）

判定表法

定义：是一种以表格形式表达多条件逻辑判断的工具
组成：

• 条件桩：列出问题中的所有条件，列出条件的次序无关紧要
• 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
• 条件项：列出条件对应的取值，所有可能情况下的真假值
• 动作项：列出条件项的，各种可能取值情况下应该采取的动作结果

规则：

• 判定表中，贯穿条件项和动作项的一列就是一条规则
• 假设有n个条件，每个条件的取值有两个，那么有2的n次方种规则

步骤：

1. 明确需求
2. 画判定表
3. 提取数据编写用例

场景法

定义：场景法也叫流程图法，是用流程图来描述用户的使用场景，然后通过覆盖流程路径来设计测试用例
意义：

• 用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
• 测试人员角度：平时都是单个功能点进行测试，容易忽略多个功能的组合测试

说明：

1. 覆盖业务测试需要使用流程图法
2. 先测试业务，在测试单功能、单模块、单页面
3. 业务用例需要流程图来梳理，需要学会画流程图和看懂流程图

错误推荐法

应用场景：当项目用例都执行完毕，且bug修复完成，离上线还有一段时间，可以使用错误推荐法去复测主要业务 或 未覆盖的业务

缺陷

定义：软件在使用过程中存在的任何问题都是缺陷，简称bug
标准：

• 少功能：软件未实现需求规格说明书中明确要求的功能
• 功能错误：软件出现了需求规格说明书中不应该出现的错误
• 多功能：软件实现的功能超出需求规格说明书中指明的范围
• 隐性功能错误：软件未实现需求规格说明书中虽未明确指明，但是应该实现的要求
• 不易使用：软件难以理解，不易使用，运行缓慢，用户体验不好

缺陷产生的原因：

• 需求阶段：需求描述不易理解，有歧义、错误等
• 设计阶段：设计文档存在错误或者缺陷
• 编码阶段：代码出现错误
• 运行阶段：软硬件系统本身故障导致缺陷

缺陷的生命周期：需求规格说明(可能产生bug)->设计(可能产生bug)->编码(可能产生bug)->测试(发现bug)->故障分类->故障隔离->故障解决(可能产生bug)
缺陷核心内容：

• 标题：描述缺陷的核心问题
• 预置条件：缺陷产生的前提
• 缺陷的复现步骤
• 预期结果
• 实际结果
• 必要附件：日志、截图、视频等

缺陷的提交要素：编号、严重程度、优先级、bug类型、缺陷状态
缺陷类型：功能错误、界面UI错误、兼容性、数据、易用性、改进建议、架构