【目录】

• 测试概念
• 测试目的
• 测试分类
• • 按测试阶段划分
  • 按代码可见度划分
  • 扩展-总结
  • 扩展-测试策略
• 质量模型
• 测试模型
• • W模型
• 测试流程
• • 需求分析
  • 测试计划
  • 编写用例
  • 执行用例
  • 缺陷管理
  • 测试报告
• 测试用例
• • 用例概念
  • 用例考虑点
  • 用例作用
  • 用例格式（八大要素）
  • 参考用例
  • 扩展-验证码测试点
  • 扩展-注册测试点
  • 注意！
• 测试用例设计方法
• • 等价类划分法
  • 边界值分析法
  • 判定表法
  • 场景法
  • 错误推测法
• 缺陷
• • 缺陷的定义
  • 缺陷的评判标准
  • 缺陷产生的原因
  • 软件缺陷的生命周期
  • 缺陷描述的核心内容
  • 缺陷提交要素
  • 怎么区分前后端缺陷
  • 缺陷报告实例
  • 缺陷跟踪流程
  • 扩展-发现bug后首先怎么办？
  • 提交缺陷的注意事项
  • 缺陷管理工具（常见禅道、jira，这里以禅道为例）
  • 注意！

测试概念

使用技术手段验证软件是否满足需求。

测试目的

保障软件质量。用最少的人力、物力、财力，找到软件中的问题从而降低商业风险。

测试分类

• 按测试阶段划分

  • 单元测试：针对程序源代码进行测试，通常由开发自己完成。
  • 集成测试：又称接口测试，主要针对模块与模块或系统与系统之间的接⼝进⾏验证。
  • 系统测试：对整个系统进行测试，包括功能、兼容、文档等。
  • 验收测试：主要分为内测、公测，使用不同人群来发觉项目缺陷。

• 按代码可见度划分

  • 黑盒测试：看不见源代码，主要对程序功能进行测试。（系统测试）
  • 灰盒测试：看见部分代码，主要对程序接口进行测试。（集成测试）
  • 白盒测试：看见全部代码，主要对程序源代码进行测试 。（单元测试）

• 扩展-总结

  • 系统测试和⿊盒测试重点核⼼是功能测试
  • 集成测试和灰盒测试⼜称接口测试
  • 单元测试和⽩盒测试是对代码进⾏测试
  • ⾃动化测试归属功能测试
  • 性能测试、安全测试归属专项测试

• 扩展-测试策略

  冒烟测试：⼤规模执⾏测试之前，针对程序主功能进⾏验证，保证程序具备可测性。（所以提测标准应当是冒烟测试通过）

质量模型

重点：功能、兼容、性能、易用、安全
（软件质量模型为我们提供了测试要考虑、覆盖的方面）

测试模型

• W模型

  W模型直观表现出开发与测试的并行关系
  

测试流程

1、需求分析
2、测试计划
3、编写⽤例
4、执⾏⽤例
5、缺陷管理
6、测试报告

• 需求分析

  阅读需求文档，记录不明确之处
  确定各部⻔对需求理解⼀致！这个非常重要！
  站在不同⻆度对需求进⾏（查漏补缺）

• 测试计划

  (一般每个公司有自己的测试计划模板)

  核⼼：
  1、测什么：测试⽬标及范围
  2、谁来测：⼈员进度安排
  3、怎么测：测试策略、测试⼯具

• 编写用例

  说明：设计执⾏测试的⽂档

• 执行用例

  说明：执⾏测试的⽂档

• 缺陷管理

  说明：提交->验证->关闭

• 测试报告

  说明：测试⽬标、测试过程、缺陷统计、缺陷分析、测试总结

测试用例

• 用例概念

  用户使用的案例（尽可能地考虑完全用户实际使用场景）

• 用例考虑点

  从质量模型出发来考虑（功能、性能、兼容、易⽤、安全）

• 用例作用

  防止漏测
  实施测试的标准

• 用例格式（八大要素）

  

• 参考用例

  

• 扩展-验证码测试点

  验证码测试点固定4个：为空、正确、错误、过期

• 扩展-注册测试点

  

• 注意！

  用例标题一般格式为：预期结果（测试点），比如上面那个例子

测试用例设计方法

• 等价类划分法

  说明：在所有测试数据中，将具有某种共同特征的数据集合进行划分，划分为有效等价类和无效等价类。

  有效等价类：满足需求的数据集合，取典型数据即可
  无效等价类：不满足需求的数据集合，取典型数据即可（注意无效等价类的控制单一变量原则！如案例2所示）

  步骤：
  1.明确需求
  2.确定有效和⽆效等价类
  3.提取数据编写⽤例

  案例1：验证账号合法性，要求账号为6-10位自然数（如下，可划分出1个有效等价类和2个无效等价类）
  

  案例2：验证某城市电话号码正确性，要求区号为空或三位数字、前缀码为非0非1开头的三位数字、后缀码为四位数字（如下，可划分出2个有效等价类和8个无效等价类）
  

• 边界值分析法

  说明：选取正好等于、刚好大于、刚好小于边界的值作为测试数据。（边界值分析法常与等价类划分法配合使用）

  上点：边界上的点（正好等于） ，必选（不考虑区间开闭）
  离点：离边界最近的点（刚好大于、刚好小于） ，开内闭外（开区间选择内部离点、闭区间选择外部离点）
  内点：边界内的点（区间范围内的数据），必选（建议选择中间范围）
  例如范围-99~99：（一般一个区间最多验证这七个点）

  步骤：
  1.明确需求
  2.确定有效和⽆效等价类
  3.确定边界范围
  4.提取数据编写⽤例

  案例：验证标题长度，要求（0，30]
  

• 判定表法

  定义：一种以表格形式表达多条件逻辑判断的工具。适用于有多个输入条件/输入结果，输入条件之间有组合关系，输入条件与输出结果之间有依赖关系，且条件组合数量较少的情况（4个条件以下，条件多用正交表法或因果图法“基本不用，现在软件为了用户体验很少做成那样”）

  组成：
  
  例如“若用户欠费或关机则不允许主被叫”的判定表：（判定表中贯穿条件项和动作项的一列就是一条规则）
  

  步骤：
  

  案例：
  
  

• 场景法

  流程图工具（网页版）：https://processon.com/
  流程图工具（Windows）：visio

  说明：场景法也叫流程图法，是用流程图描述用户的场景，然后通过覆盖流程路径来设计测试用例（对测试的意义体现在：平时测试都是单个功能点进行测试，容易忽略多个功能的组合测试）

  案例：ATM
  
  

• 错误推测法

  定义：通过经验推测系统可能出现的问题

  使用场景：
  1.时间紧任务量大时，根据之前类似项目经验找出易出错的模块重点测试
  2.时间宽裕，复测之前问题较多的模块

缺陷

• 缺陷的定义

  软件在使用过程中存在的任何问题都叫缺陷，简称bug。

• 缺陷的评判标准

  

• 缺陷产生的原因

  

• 软件缺陷的生命周期

  

• 缺陷描述的核心内容

  

• 缺陷提交要素

  （通过缺陷管理⼯具与开发交流使⽤，就是工具里面选的那些，每个公司设的可能不一样）
  

• 怎么区分前后端缺陷

  1、如果是界⾯或兼容性的错误为前端bug 2、如果是功能错误区分前端和后端bug,需要抓包查看请求和响应。

• 缺陷报告实例

  

• 缺陷跟踪流程

  

• 扩展-发现bug后首先怎么办？

  确认bug可复现

• 提交缺陷的注意事项

• 缺陷管理工具（常见禅道、jira，这里以禅道为例）

  地址：禅道（https://demo.zentao.net/my/）
  特点：国产、免费、开源、简单、轻量级、三管融合（产品管理、项目管理、质量管理）
  各人员使用的流程：
  

  缺陷管理：
  
  
  用例管理：
  
  

• 注意！

  缺陷标题目的是让开发读懂，要尽量可读、简洁、易懂，建议为步骤+实际+预期 or 步骤+实际+需求（我习惯前一种）