• 需求分析
• 测试计划
  • 接口测试
  • 性能测试
• 用例编写
  • 验证项目是否符合需求的操作文档
• 用例执行
• 缺陷管理
• 测试总结

1. 单元测试
   • 针对程序源代码进行测试
2. 集成测试
   • 又称接口测试 ，针对模块之间访问地址进行测试
3. 系统测试
   • 对整个系统进行功能、兼容、文档等测试
4. 验收测试
   • 主要分为内测、公测

• 黑盒、灰盒、白盒

• 功能、性能、兼容、易用、安全、可靠性、移植性、维护性

1. 定义：为测试项目而设计的执行文档
   • 防止漏测
   • 实施测试的标准
2. 用例设计编写格式
   • 用例编号：项目模块编号
   • 用例标题：预期结果（测试点）
   • 项目/模块：所属项目和模块
   • 优先级：表示用例的重要程度或者影响力
     P0~P4（P0最高，用户的使用频率）
   • 前置条件：执行此条用例，有哪些前置条件
   • 测试步骤：描述操作步骤
   • 测试数据：操作的数据，没有为空
   • 预期结果：期望达到的结果

     3.1、等价类划分—能对穷举场景设计测试点（类型 ）

3. 有效等价（有效等价取1个值）
4. 无效等价（每个无效集合取1个）

• 长度、类型、规则
• 重点：
  1. 正向用例：一条尽可能覆盖多条
  2. 逆向用例：每一条数据，都是一条单独用例

     3.2、边界值分析方法—解决边界位数限制问题（位数 ）

1. 边界范围节点
   1. 上点：边界上的点
   2. 离点：距离上点最近的点
   3. 内点：范围内的点 （开内闭外）
2. 提示：
   1. 有关范围限制，最多5条用例（暂时未优化）
   2. 边界值能解决位数限制问题，但是不能解决类型问题（要结合等价类）

      3.3、判定表法—有条件依赖关系

3. 定义：是一种以表格形式表达多条件逻辑判断的工具
   1. 条件桩：列出问题中的所有条件，列出条件的次序无关紧要
   2. 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
   3. 条件项：
   4. 动作项：
4. 规则：
   1. 判定表中贯穿条件项和动作项的一列就是一条规则
   2. 假设有n个条件，每个条件的取值有两个（0，1），全组合有2的n次方种规则
   3. 判定表法适合4个以内条件依赖关系，超过应采用（正交法）来解决

      3.4、场景法

5. 定义：又称流程图法，业务用例是根据流程图进行梳理的
6. 先测试业务，再测试单功能

   3.5、错误推荐法

7. 定义：通过经验推测系统可能出现的问题
8. 主要用于所有用例都覆盖完成，并且bug都修复完成，离上线还有一段时间，再用错误推荐法去覆盖主要业务和未测试的功能。

4.1缺陷介绍

1. 定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug
2. 判定标准：
   1. 少功能
   2. 功能错误
   3. 多功能
   4. 隐形功能错误（预期结果）
   5. 不易使用（软件测试人员）
3. 缺陷产生的原因：
   1. 需求
   2. 设计
   3. 编码
   4. 运行
4. 缺陷提交要素
   1. 缺陷报告编号
   2. 严重程度
      1. 严重：主功能
      2. 一般：次要功能
      3. 微小：易用性、界面
      4. 建议：建议性问题
   3. 缺陷优先级
   4. Bug类型
   5. 缺陷状态