零基础学软件测试：超详细软件测试基础理论知识讲解

文章目录

• 1、软件测试相关概念
• • 1.1、什么是软件
  • 1.2、什么是软件测试
  • 1.3、软件测试分类
• 2、软件生命周期
• 3、软件开发模型
• 4、软件测试工作流程
• 5、软件质量
  • 5.1、什么是质量
  • 5.2、软件质量
  • 5.3、软件质量的九大特征
• 6、软件达到上线标准
  • 6.1、测试覆盖率
  • 6.2、bug遗留率
• 7、需求分析
  • 7.1、需求
  • 7.2、什么是需求分析
  • 7.3、需求分析范围
  • 7.4、为什么要做测试需求分析
  • 7.5、如何进行需求分析
• 8、测试计划
  • 8.1、什么是测试计划
  • 8.2、测试计划包含哪些内容
  • 8.3、测试计划文档编写
• 9、测试方案
  • 9.1、什么是测试方案
  • 9.2、测试方法一般包含哪些内容
  • 9.3、不同测试类型的测试方案
• 10、测试计划
  • 10.1、什么是测试用例
  • 10.2、测试用例包含哪些内容
  • 10.3、测试用例方法
    • 10.3,1、等价类
    • 10.3,2、边界值分析法
    • 10.3,3、场景法
    • 10.3,4、错误推断法
    • 10.3,5、因果图判定表
    • 10.3,6、正交实验法
• 11、用例评审
  • 11.1、什么是用例评审
  • 11.2、用例评审目的
  • 11.3、用例评审两种方式
• 12、测试执行
  • 12.1、测试执行的前提条件
  • 12.2、怎样测试执行
  • 12.3、bug类型
  • 12.4、bug等级
  • 12.5、bug的生命周期及流程
  • 12.6、bug的常用管理工具
  • 12.7、bug单包含哪些内容
• 13、测试报告
  • 13.1、什么是测试报告
  • 13.2、测试报告包含什么内容

1、软件测试相关概念

1.1、什么是软件

软件=程序+数据+文档

• 程序：程序即软件 比如淘宝、京东、支付宝、微信
• 数据：登录qq，展示qq好友账号，聊天记录等等信息
• 文档：程序相关的文档 比如：用户帮助文档，合同及协议

软件分类

• 应用软件：为了解决某些具体问题而购买、开发或研制的各种程序或软件包 比如：京东 淘宝
• 系统软件：系统软件是生成、准备和执行其他程序所需要的一组文件和程序 比如windows系统 android ios系统

1.2、什么是软件测试

定义：使用人工和自动手段来运行或测试某个系统的过程

目的：

• 检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
  • 规定的需求是什么？产品从用户中收集整理到的用户需求（规格说明书）
• 软件测试目的：发现bug，降低成本、提高质量

1.3、软件测试分类

• 按照阶段划分

  • 单元测试
    • 测试对象：程序代码 比如：模块、函数、类
    • 测试者：开发人员
  • 集成测试
    • 测试对象：把多个单元整合到一起进行测试（本质还是测试代码）
    • 测试者：开发人员
  • 系统测试
    • 软件系统搭建起来，查看软件与用户需求是否相符
    • 测试者：软件测试人员
  • 验收测试
    • 用户对软件进行测试
    • 测试者：用户、测试人员
    • 验收测试两种形式
      • Alpha测试：用户或者第三方来到开发方对系统进行的测试
      • Beta测试：系统的环境不受开发方控制，测试人可以用户，测试时间不集中 即公测
      • 两者的区别
        • 主要区别：测试场所不一样
          • Alpha测试在开发方提供的环境下进行的
          • Beta测试是在真实的用户环境下进行测试，测试人比较多，时间不集中
        • Alpha测试先于beta测试

• 是否查看代码划分

  • 白盒测试：不关注外部功能是否实现，只关注内部逻辑具体实现（查看代码进行测试，）
  • 黑盒测试：关注外部功能是否实现，不需要关注内部逻辑具体实现（不需要查看代码进行测试）
  • 灰盒测试：既要关注外部功能是否实现，也要关注内部逻辑是否实现

• 按照被测对象是否运行划分

  • 动态测试：运行被测系统进行的测试，查看实际结果是否与预期结果一致
  • 静态测试
    • 不运行被测系统进行的测试
    • 包含文档检查、代码走查，桌面检查

• 按不同的测试手段划分

  • 手工测试：点点的测试
  • 自动化测试：通过代码或者工具对系统进行自动化的测试

• 按测试包含的内容划分

  • 功能测试：验证软件的每一个功能是否按照需求文档中的规定运行，通过输入适当的输入来测试功能
  • 界面测试：对系统界面的进行的测试 比如 颜色 布局 设计
  • 安全测试：比如：sql注入
  • 兼容性测试：在不同的浏览器下进行运行系统，查看系统的功能
  • 易用性测试：站在用户的角度，查看软件是否操作方便、是否容易被理解
  • 性能测试：在大量用户使用的场景下，查看系统是否正常

• 其他划分

  • 冒烟测试
    • 进行系统测试之前进行的测试，对核心功能进行的测试
    • 什么时间进行：进行系统测试之前进行的测试
  • 回归测试
    • 对已修复的bug进行的测试
    • 如何进行回归测试
      • 对已修复的bug进行的测试
      • 对与bug相关联的功能进行覆盖测试
  • 随机测试、探索性测试
    • 根据自己的经验而进行的测试
    • 一般作为测试的一种补充

2、软件生命周期

软件开始研制到最终被废弃不用所经历的各个阶段

1. 需求分析
   • 输出文档：需求规格说明书（SRS）
2. 设计
   • 输出1：概要设计说明书
     • 主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。（针对项目整体的架构及模块与模块业务关联及数据的传递）
   • 输出2：详细设计说明书
     • 对概要设计中表述的各模块进行深入分析等，其中需要包含数据库设计说明。（针对某个模块的具体详细设计）
3. 编码
4. 测试
   • 单元测试
   • 集成测试
   • 系统测试
   • 验收测试
5. 运行维护

3、软件开发模型

软件是基于什么样的模型开发出来（开发人员决定）
常见的软件开发模型

• 瀑布模型
  • 核心特点：线性顺序开发，严格划分为需求分析、设计、编码、测试、维护等阶段，前一阶段完成后才能进入下一阶段‌
  • 优势：阶段清晰、文档规范，适合需求稳定的传统项目（如军工系统）‌
  • 局限性：需求变更成本高，测试滞后导致缺陷修复代价大‌
• V模型
  • 核心特点：开发与测试严格对应（如单元测试→编码，验收测试→需求分析），形成对称V形结构‌
  • 优势：测试分级明确，适用于合同约束型项目‌
  • 局限性：测试后置，无法适应迭代需求‌
• W模型
  • 核心特点：双V结构，测试与开发并行，强调早期验证（如需求评审阶段即开始测试设计）‌
  • 优势：降低缺陷修复成本，提升测试效率‌
  • 局限性：仍基于串行流程，不适合敏捷开发‌
• 原型模型
  • 核心特点：快速构建可运行原型，通过用户反馈迭代完善需求‌
  • 分类：测试分级明确，适用于合同约束型项目‌
    • 抛弃型原型‌：仅用于需求验证，完成后丢弃‌
    • ‌演化型原型‌：逐步完善为最终产品‌
  • 适用场景‌：需求不明确或需快速验证的初期项目‌
• H模型
  • 核心特点：测试完全独立于开发流程，分为准备（设计用例）与执行（运行测试）两部分，支持灵活触发‌
  • 优势：实现“持续测试”，适合复杂迭代项目‌
  • 局限性：对团队协作要求高‌
• X模型
  • 核心特点：支持探索性测试与多曲线并行开发，允许需求变更贯穿全周期‌
  • 优势：挖掘计划外缺陷，适应快速变化‌
  • 局限性：依赖测试人员经验，资源消耗大‌

总结对比

模型	核心流程	适用场景	关键改进点
瀑布模型	线性顺寻开发	需求稳定的传统项目	阶段划分清晰
V模型	开发-测试对称对应	合同约束型项目	明确测试分级
W模型	开发测试双V并行	需早期验证项目	降低修复成本
H模型	测试独立全周期触发	复杂迭代环境	实现持续集成
X模型	多曲线探索性测试	敏捷开发场景	支持需求灵活变更

现在常见开发模型

• 敏捷开发模型
  • 核心特点
    • 以人为核心，强调快速响应变化，通过短周期（通常2-4周）迭代交付可运行软件‌
    • 四大核心价值观：个体与交互高于流程工具、可工作软件高于详尽文档、客户合作高于合同谈判、响应变化高于遵循计划‌
  • ‌优势‌
    • 适应需求频繁变更，早期交付降低风险‌
    • 客户全程参与，减少理解偏差‌
  • ‌局限性
    • 依赖团队自律性，文档管理较弱‌
    • 不适合强合规性项目（如军工系统）‌
• 迭代开发模型
  • 核心特点
    • 分轮次完善系统，每轮迭代完成部分功能并优化整体架构‌
    • 早期版本仅为框架（如绘画轮廓），后续逐步细化‌
  • ‌优势‌
    • 早期验证架构合理性，降低重构风险‌
  • ‌局限性
    • 初期交付物价值低，客户体验较差‌
• 增量式开发模型
  • 核心特点
    • 将系统拆分为多个功能模块（增量），按优先级分批交付‌
    • 每个增量均完成需求分析→设计→实现→测试全流程‌
  • ‌优势‌
    • 早期交付核心功能，降低市场风险‌
    • 模块化开发便于团队分工‌
  • ‌局限性
    • 需提前规划模块依赖关系‌
    • 增量间集成成本较高‌

4、软件测试工作流程

1. 需求分析
   • 重点：参考需求规格说明书（SRS）,研读并理解需需求，参与需求评审会议
   • 需求评审会议
     • 参与人员：产品经理、项目经理、开发、测试
     • 主要目的：项目业务学习，并发现需求的问题
2. 测试计划
   • 输出文档：测试计划文档
3. 编写测试用例（测试设计）-用例评审
   • 输出：测试用例文档
4. 部署测试环境-执行测试-提交bug并跟踪bug -2到3轮的测试-达到测试要求-测试通过
   • 输出：bug清单
5. 编写测试报告
   • 输出：测试报告文档
6. 发布上线

5、软件质量

5.1、什么是质量

质量：反映实体满足明确或隐含需要能力的特性总和。

5.2、软件质量

软件与明确的和隐含的定义的需求相一致的程度

5.3、软件质量的九大特征

• 功能性
  • 当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力。
    • 适合性：软件产品符合需求，能解决用户业务问题
    • 准确性：软件产品数据和处理处理能力要准确
    • 互操作性：软件产品与其他系统的交互和对接能力。
    • 安全保密性：软件产品权限安全，不同角色进入拥有不同的操作权限
• 性能
  • 时间特征
    • 响应时间、处理时间、吞吐率
  • 资源利用性
    • 是否耗资源（CPU\内存占用率）
• 安全性
  • 软件在受到恶意攻击的情形下依然能够继续正确运行的能力
• 兼容性
  • 软件适应不同的规定环境下的能力
    • 常见的兼容性（浏览器、操作系统）
• 可靠性
  • 在指定条件下使用时，软件产品维持规定的性能级别的能力。
    • 成熟性
      • 软件产品为避免由软件内部的故障而导致失效的能力。
    • 容错性
      • 软件出现故障或者违反其指定接口的情况下，依然维持规定的性能级别的能力。
    • 易恢复性
      • 失效发生后，重建规定的性能级别并恢复受直接影响的数据的能力。
• 易用性
  • 在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
    • 易理解
    • 易学性
    • 易操作性
    • 吸引性
    • 用户体验性
• 安装/卸载
  • 执行安装/卸载时，能按照一定的规格和流程将软件安装上的能力。
• 可移植性
  • 适应性
    • 软件不需采用其他手段就可适应不同的指定环境的能力。
  • 易安装性
    • 软件在指定环境中被快速安装的能力。
  • 共存性
    • 软件在同一环境下同与其他软件共存的能力。
  • 易替换性
    • 软件在同一环境下，替代另一个相同用途的软件的能力。
• 可维护性
  • 易分析性
  • 易改变性
  • 稳定性
  • 易测试性

6、软件达到上线标准

6.1、测试覆盖率

由测试来控制，测试覆盖率越高越好，趋向100%

• 测试点覆盖率100%（需求分析）
• 测试用例的覆盖率100%（用例编辑）
• 测试执行的覆盖率100%（用例执行）

6.2、bug遗留率

开发控制的 ，bug遗留率趋向0

7、需求分析

7.1、需求

• 明确需求
  • 需求文档中的明确提及的需求
• 隐性需求
  • 文档没有提及到，但是需要解决的需求

7.2、什么是需求分析

主要解决“测什么”的问题，一般来自需求规格说明书中原始需求

1. 测试目标（对象）：解决测试什么问题
2. 具体到被测对象中有什么需要测试–每个测试目标要测试内容

7.3、需求分析范围

• 功能性需求
  • 全部覆盖已定义的业务流程及项目的所有功能
• 非功能性需求
  • 非功能指的性能、安全性、兼容性等等

7.4、为什么要做测试需求分析

• 软件测试需求是设计测试用例的依据
• 有助于保证测试的质量与进度
• 测试需求是衡量测试覆盖率的重要指标

7.4、如何进行需求分析

1. 需求收集

   • 需求的来源
     • 需求规格说明书(SRS）
     • 开发需求
     • 继承需求
     • 同行竞争产品
     • 经验库
   • 问题：项目没有任何需求文档如何进行需求分析？
     • 参考同行的竞争产品及站用户的角度及自身的经验进行

2. 测试需求分析

   • 对需求文档进行细化及分解，提取需求的要点（测试点）
     1.已需求文档为参考依据
     2、细化分解需求（提取测试点）
     • 细化和分解具体包括
       • 对需求中描述中的输入、输出、处理、限制、约束等，给出对应的验证内容；
       • 对功能的交互，给出对应的验证内容
         • 比如：注册成功操作验证，通过登录功能去进行验证
     • 提取测试点的常用工具
       • xmind
       • excel
     • 测试点的特征
       • 制定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求
       • 测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时的出错条件
       • 测试需求不涉及具体的测试数据，测试数据设计是测试设计环节应解决的内容
     • 提取需求分析的一般步骤
       • 1、界面检查，参考需求原型
       • 2、从上到下，从左到右对各控件的输入输出提取测试点(注意输入考虑限制及约束)
       • 3、按钮 按照逻辑的先后顺利进行分析，特别需要注意分析交互功能（关联功能）
         • 关联功能是什么
           • 验证当前功能结果的功能
         • 一般不能通过提示去验证功能结果，需要通过关联功能去进行验证
     • 常见控件测试要点
       • 文本框
         • 是否可编辑、是否密文显示
         • 是否必填
         • 是否重复
         • 长度、输入限制类型
       • 下拉框
         • 验证下拉框内容数据的完整及准确性
         • 测试选中数据后是否能正常带出到下拉文本框
         • 注意关联下拉框的校验
       • 单选按钮
         • 验证选项内容数据的完整及准确性
         • 验证所有的单选项在同一组数据中，最多只能同时选中一个选项
       • 复选按钮
         • 验证选项内容数据的完整及准确性
         • 验证可同时选中多个选项，操作其中一个选项不会引起其他选项的变化
       • 文件上传
       • 按钮
         • 可点击
         • 操作成功，验证关联功能
         • 操作失败，验证关联功能
       • 搜索
         • 搜索条件的显示
         • 单条件/多条件搜索，验证搜索数据精确/模糊匹配，搜索的数据是否正确
         • 搜索结果展示，如果空，是否有提示 如果数据多，是否支持翻页
       • 排序
         • .排序方式的验证
         • 点击排序后验证数据展示
       • 翻页功能
         • 数据少于一页，不显示翻页，数据多余一页显示翻页
         • 当前也为首页点击首页，或者当前页为末页点击最后一页，均不跳转，非首页及非尾页，点击其他页，验证页面跳转正确
       • 导出
         • 1.列表结果为空，是否支持导出
         • 2.导出模板的校验，是否与导出设置保持一致
         • 3.校验导出的数据的正确性
         • 4.测试大数据量导出是否超时
       • 导入
         • 1. 测试导入模板的正确性
         • 2. 用错误的模板导入数据，查看提示信息是否正确，查看数据是否导入成功（如果能正常导出是个大问题）
         • 3. 校验导入数据每一列数据的正确性，输入格式的校验，必填的校验，重复数据行验证的过滤
         • 4. 数据部分错误时，是否能导入成功，预期结果参考需求规格说明书
         • 5. 导入失败，导入超时，数据是否正常回滚（使用大数据量进行测试）
         • 6. 导入正确，在系统中查询相应数据，验证数据正确性
       • 超链接
         • 1. 展示，是否可点击
         • 2. 点击是否能正常跳转到相应的页面
       • 新增数据
         • 1. 各个字段输入格式的校验
         • 2. 必填的校验
         • 3. 唯一性的校验，去重复的校验
         • 4. 新增成功/失败，到系统相应的可视化查询页面查询数据成功/失败，且各字段值显示正确
       • 删除数据
         • 一、单个删除：删除成功/失败：到系统相应的可视化查询页面查询数据失败/成功
         • 二、批量删除
           • 1. 不勾选数据，点击删除，给出提示，验证关联功能
           • 2. 勾选单个数据，点击删除，验证关联功能
           • 3. 跨行勾选多个数据，点击删除，验证关联功能
           • 4. 不跨行勾选多个数据，点击删除，验证关联功能
       • 编辑数据
         • 1. 关键信息（作为主键，用来做唯一校验的字段）是可不可编辑，如果可编辑则是问题
         • 2. 其他可编辑字段，测试方法参考新增数据的测试方法
       • 查询数据
         • 1. 只读展示，如果可编辑则是问题
         • 2. 校验数据展示正确性

3. 测试需求分析评审

通过需求评审会议进行需求分析评审

• 参与人：产品、测试、开发
• 需求分析评审的目的
  1. 需求的完整性
     • 是否有遗留的需求、隐形需求
  2. 需求的准确性
     • 测试点是否与需求一致

8、测试计划

8.1、什么是测试计划

就对测试工作的统筹和安排的一份测试文档
测试计划由谁来写

• 一般由测试组长或项目经理

需要看测试计划的有哪些人

• 组长
• 项目经理
• 开发
• 产品
• 销售推广人员

8.2、测试计划包含哪些内容

• 5W+1H
  • 5W
    • 目的（why）
    • 测试范围（what）
    • 测试进度安排（when）
      • 测试计划：1天
      • 测试需求分析
      • 用例设计
      • 测试执行：分多轮进行测试；分三轮；6:3:1
      • 测试报告：1天或者半天
      • 测试执行：需求分析+测试用例编写接近1:1
    • 测试人员（who）
    • 测试环境（where）
  • 1H
    • 测试方法+测试工具（how）
  • 风险评估
    • 预测整个项目测试过程中可能存在的风险，并制定出对应的应对方案
• 两周一个版本（双休）
  • 测试计划1天
  • 需求分析2天
  • 用例编写3天
  • 执行前0.5天
    • 环境搭建
    • 冒烟测试
  • 测试执行
    • 第一轮测试2.5天
    • 第二轮测试1.5天
    • 第三轮
  • 测试报告0.5天
• 人天
  • 一个人多少个工作日完成，用来评估工作量
  • 一般工作量=人数*天数 比如10人10天 总的工作量人天=100人天

8.1、测试计划文档编写

‌测试计划文档核心结构‌

1. 引言
   • 说明文档目的、读者对象及项目背景，明确测试目标（如功能验证/性能优化）
   • 定义术语与缩略语，避免歧义
2. 测试范围
   • 列出被测功能模块（如登录、支付）、非功能需求（性能/安全指标）及排除项
3. 测试策略
   • 明确测试类型（功能/性能/安全测试）及方法（黑盒/白盒）
   • 自动化测试比例及工具选型（如Selenium/JMeter）
4. 资源规划
   • ‌人力资源‌：测试团队分工（如测试经理/工程师）
   • ‌环境需求‌：硬件配置（服务器规格）、软件版本（OS/数据库）
5. 进度与里程碑
   • 制定测试阶段时间表（如需求评审→用例设计→执行→报告）
   • 定义准出标准（如缺陷修复率≥95%）
6. ‌风险管理
   -识别潜在风险（如需求变更、环境延迟）及应对措施

9、测试方案

9.1、什么是测试方案

描述测试的具体方法
有些企业会把测试方案并入测试计划中，作为测试策略，有些企业，测试方案是独立一份文档

9.2、测试方法一般包含哪些内容

• 测试范围
• 测试的目标
• 方法
• 完成的标准
• 需考虑的特殊事项

9.1、不同测试类型的测试方案

• 功能测试
  • 方法
    • 针对各个功能点使用有效数据时得到预期的结果。
    • 针对各个功能点在使用无效数据时显示相应的错误或警告消息。
    • 各业务规则得到了正确的执行。
• 兼容性测试
  • 方法
    • 通过不同的浏览（Firefox/IE浏览器/谷歌chrome浏览器）器覆盖所有的功能，查看功能及界面展示是否正常
  • 浏览器的兼容性测试
    • 常见的浏览器有哪些
      • Firefox火狐
      • IE浏览器
      • 谷歌chrome浏览器
• 本地国际化测试
  • 方法
    • 系统是否支持不同区域的数据设置格式
    • 系统本地化的内容是否准确
• 数据库测试
  • 方法
    • 输入成功注册的用户信息, 查看与数据库是否一致
    • 查看发布信息是否可以正常输入数据库.

10、测试计划

10.1、什么是测试用例

对每个测试点进行数据设计及步骤设计的文档，包含测试输入，执行条件以及预期结果
目的：验证程序是否跟用户的需求一致
用例编辑工具：excel、xmind

10.2、测试用例包含哪些内容

• 用例编号
  • 特点：编号必须唯一
  • 格式
    • 项目_编号 比如：电商项目_001
    • 项目_测试阶段(it st uat)_测试项_编号 比如：电商项目_ST_注册_001
• 模块
  • 为了处理某一事务对应的所有的功能集合
  • 一个项目存在多个模块，一个模块下存在多个功能
• 用例标题
  • 概括描述测试的目的，必须言简意赅，标题不能太长
  • 一般编写技巧：输入+结果
• 用例级别
  • 用例的级别可以用高中低或者123
    • 高
      • 主要核心业务功能，冒烟用例
    • 中
      • 错误异常的测试点
    • 低
      • 兼容性、界面错误
• 预置条件
  • 执行当前用例，需要做什么特殊准备（什么环境或者测试数据准备），一般情况，不需要填写预置条件
• 测试步骤
  • 具体的测试数据+操作步骤
  • 编写格式
    • 1、路径 【商城首页>注册】点击【注册】
    • 2、输入包含具体的测试数据 用户名：admin ,密码：admin
    • 3、动作 勾选阅读并同意协议，点击【注册】
• 预期结果
  • 按照操作步骤，应该有什么的结果（结果跟用户需求相一致）
    • 多对一
      • 多个步骤对应一个结果
    • 一对一
      • 一个步骤对应一个结果，如果多个步骤则对应多个结果
• 实际结果
  • 执行测试结果
    • pass
      • 用例测试通过
    • failed
      • 用例测试不通过，预期结果跟实际结果不一致
    • 阻塞
      • 用例没法执行

10.3、测试用例方法

10.3.1、等价类

把所有可能的数据划分为N个子集，在每个子集中抽取最具有代表性的数据来进行测试

等价类划分

• 有效等价类
  • 合理的，有意义的输入数据构成的集合
• 无效等价类
  • 不合理，无效的输入数据构成的集合

等价类分析的步骤

• 根据需求分别找出需求的条件，根据条件，分别找出有效等价类和无效等价类
• 对有效等价类和无效等价类进行编号
  • 有效等价类归为一个组A
  • 无效等价类归为一组B
• 选择测试用例，根据有效等价类选择正例，根据无效等价类选择反例
  • 正例
    • 输入符合需求有效的数据而编写的用例
  • 反例
    • 输入错误或无效的数据而编写的用例
  • 选择的规则
    • 设计一个新的测试用例数据,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；(用最少的用例去覆盖最多的有效等价类)
    • 设计一个新的测试用例数据,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止（用最多的用例去一一覆盖无效等价类）

10.3.2、边界值分析法

对等价类的补充，会选择等价类边缘值进行测试
边缘值

• 上点
  • 上点就是区间的端点值
• 离点
  • 上点最近的点称为离点（开内闭外）
    • 分两种情况
      • 开内
        • 如果是开区间的离点，就是开区间上点内测紧邻的点
          • 比如 6<长度<18则离点7,17
      • 闭外
        • 如果是闭区间离点，就是闭区间上点外侧紧邻的点
          • 比如6<=长度<=18则离点5,19
• 内点
  • 上点之间任意一点

10.3.3、场景法

模拟用户操作软件的业务流程的场景（对业务流程进行分析）
项目的业务流程场景分为两大类

• 基本流
  • 模拟正确的操作流程
• 备选流（错误流/异常流）
  • 模拟错误的操作流程

业务流程图

• 流程图工具： processon
  • 工具地址：https://processon.com/diagrams

10.3.4、错误推断法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

基于错误推断法补充测试用例，增加测试覆盖率

比如：充值 金额>0 并且50/100的倍数

错误推断法：依赖于经验、直觉、知识

10.3.5、因果图判定表

• 因果图判定表的使用场景

  • 需求中存在多个因子及对应的结果的情况下，一般使用因果图判定表法

• 因果图判定表分析的步骤

  • 列出所有的条件及结果
  • 画出判定表
    • 目的：覆盖不同条件组合下对应的不同的结果对应所有的场景
    • 判定表的组成结构
      • 条件桩
        • 列出需求中所有的条件
      • 动作桩
        • 列出需求中所有的结果
      • 条件项
        • 不同条件的组合
      • 动作项
        • 对应不同条件组合所对应的结果
      • 条件项到底有多少项
        • 如果每个条件桩有两个值，则条件项=2的N次幂（N值是条件桩的个数）
  • 简化判定表
    • 有相同结果，并且其中一项的值为任意值的情况下，不影响结果，那么这样的项就可以进行合并
  • 针对简化后的判定表的每种组合分别编辑对应的测试用例

10.3.6、正交实验法

因果关系非常庞大的情况下，一般就使用正交实验法进行测试
使用正交表进行测试

• 常见的正交表：https://www.docin.com/p-2228475212.html
• 正交表格式
  • L n (m的k次幂)
    • n指测试的次数，表格的行数
    • m指每个因子包含取值的个数
    • k指因子的个数
• 正交实验法测试步骤
  • 根据需求，选择需求中需要参与测试的的条件及对应参与测试条件的值
  • 选出对应的正交表
  • 根据正交表的每一行进行对应的测试

11、用例评审

11.1、什么是测试评审

定义：对用例进行评审

11.2、用例评审目的

• 用例的准确性
  • 用例覆盖的需求跟项目需求一致
• 用例的完整性
  • 用例应该覆盖所有的需求，尽可能的达到最高，不要出现漏测试

参与用例评审人员：测试人员、开发、产品、项目经理

11.3、用例评审两种方式

• 组内评审
  • 负责该项目测试的人员
• 组外评审
  • 测试以外的人员进行参与，一般开发、产品

12、测试执行

12.1、测试执行的前提条件

测试环境搭建好，并且冒烟测试（预测试）通过

12.2、怎样测试执行

运行被测项目，根据测试用例执行测试，如果实际结果和预期结果不一致，可能就是BUG

12.3、什么是bug

缺陷(错误)/漏洞/改进与建议/不符合需求

12.4、bug类型

bug是属于哪方面不符合需求导致的

bug常见的类型有哪些：

• 代码（功能）错误
  • 因为实现的功能跟需求不一致导致的这类的bug,这类bug是最多的
• 界面优化
  • 界面不好看，或者不合符用户使用习惯的这类BUG
• 设计缺陷
  • 与开发、产品需求文档不一致的

12.5、bug等级

1. 致命的（blocker ）
   • 常规操作引起的系统崩溃、死机、死循环、闪退
   • 造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
   • 涉及金钱计算
   • 阻断性测试，所有测试工作进行不下去（冒烟测试）
2. 严重错误（critical）
   • 重要功能不能实现
   • 错误的波及面广，影响到其它重要功能正常实现
   • 非常规操作导致的程序崩溃、死机、死循环、闪退
   • 外观(界面)难以接受的缺陷；
   • 密码明文显示；(界面+数据库)
   • 偶现的致命性bug
3. 一般错误：不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
   • 次要功能不能正常实现
   • 操作界面错误（包括数据窗口内列名定义、含义不一致）
   • 查询错误，数据错误显示
   • 简单的输入限制未放在前端进行控制
   • 删除操作未给出提示
   • 偶现的严重性bug
4. 细微错误：程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
   • 界面不规范
   • 辅助说明描述不清楚
   • 提示窗口文字未采用行业术语
   • 界面存在文字错误
5. 改进建议：可以提高产品质量的建议，包括新需求和对需求的改进

12.6、bug的生命周期及流程

1. 测试人员发现BUG并确认bug，提交bug单

   • 注意事项：环境及操作是否有问题；状态：激活/new/新建；转入2流程

2. 指派给开发/开发老大

   • 状态：指派；转入3流程

3. 开发确认bug

   • 是否是bug
     • 是
       • 开发确认BUG；状态：已确认；转入4流程
       • 重复BUG
         • 指明重复BUG的ID
         • 针对重复BUG的处理操作
           • 是重复BUG，关闭bug
             • 注意事项：不要提交重复BUG,避免提交重复BUG ,先搜索
           • 不是重复BUG,加备注描述不是重复的bug,重新激活BUG
     • 不是
       • 解决方案：设计如此 当前bug不是bug
         • 处理方案
           • 1、确认BUG
           • 2、对照需求，站在用户的角度，参考成熟产品，与开发沟通，说服开发
           • 3、产品、项目经理进行最后的确认，根据产品或项目经理的最终结果确定bug是重新激活还是关闭，记得都需要加备注
       • 解决方案：无法重现
         • 处理方案
           • 1、测试帮助开发重现bug
           • 2、自己的环境也不能重现， 跟踪3-5个版本，加备注 —关闭
         • 偶现bug
           • 1、尽可能的复现出bug(尽可能的还原当初的操作步骤及当初的数据环境)
           • 2、写出bug的复现率，出现的bug次数/总的测试次数
           • 3、持续跟踪3-5到版本

4. 开发确认bug,受理bug

   • 已解决；转入5流程
   • 不予解决
     • 参考bug优先级,如果界面bug ,建议性的bug—争议，尝试沟通，如果沟通无果，则跟产品进行最后的确认，最后加备注，关闭
   • 延期处理
     • 建议性bug,优先级低，改动太大，影响太大
     • bug是否影响用户的使用
     • 衡量时间，bug影响程度
     • 产品做最后的确认，把确认结果加到备注

5. 测试验证bug

   • 在解决的版本上进行验证bug完美解决；转入6流程
   • 如何验证bug
     • 1、在解决的版本上碱性验证bug是否解决
     • 2、与bug相关联的功能是否正常
   • 验证bug发bug没有完美解决
     • 重新激活bug

6. 关闭bug

12.7、bug的常用管理工具

• 禅道管理工具zentao
• bugzilla
• bugfree
• jira
• easybug
• Readmine

12.8、bug单包含哪些内容

• bug类型
• bug标题
  • 编写规划：bug的功能模块+bug的操作+bug的结果
  • 比如：【抖音直播/公屏信息发送】公屏输入“|”点击发送，发送的消息不显示“|”，而显示为空白
• bug严重程度
• 重现步骤
  • 详细写下发现bug的测试步骤。能指导开发重现这个bug，并且包含具体的测试数据
• bug预期结果
• bug实际结果
• 抄送给谁
• 附件

13、测试报告

13.1、什么是测试报告

对整个测试工作进行总结及软件质量进行评估的一份测试文档

13.2、测试报告包含什么内容

• 测试范围
• 测试环境
• 数据统计
  • bug数据
  • bug状态
  • bug类型统计
  • 测试阶段统计
  • 按功能模块统计
• 测试总结