1. 方向（一）:功能测试+接口测试
2. 方向（二）:功能测试+性能测试
3. 方向（三）:功能测试+ web自动化

C/S架构(客户端)：比如微信、QQ

B/S架构(浏览器)：browser-server浏览器服务器比如淘宝京东

预发布环境（UAT 环境）验收测试进行的环境

Vaild：V 有效，Invalid：I 无效

动态测试：运行被测系统而进行的测试

静态测试：不需要运行被测系统，而进行的测试（界面检测、文档检测、代码走查）

功能测试：验证软件的业务功能是否符合需求

界面测试：被测系统界面与原型图是否一致

安全测试：对被测系统的安全进行测试（对账号进行输入用户名密码、是否允许输入、sql 注入）

兼容性测试：被测系统不同的测试环境下是否正常

易用性测试：被测系统各个功能是否操作方便，是否容易理解、容易上手

性能测试（负载测试、压力测试）：某个特定时间，用户数量剧增，软件是否正常

冒烟测试：批量开始测试之前，执行业务正向用例，验证软件是否具备可测性。一般由开发或测试主管负责

回归测试：开发对存在的问题的功能进行修改后，再一次进行的测试

探索性测试：根据自己的项目经验而进行的随意测试

测试点：软件包含多个功能点，每个功能点包含多个子功能（测试点），测试点是软件功能细分的最小单元

it：集成测试，st：系统测试，uat：验收测试

DRAFT：初稿，MODIFY：修订，RELEASE：终稿

软件测试定义：使用技术手段验证软件是否满足需求

常见测试分类

按阶段划分

单元测试：针对程序源代码进行测试，确保各单元模块被正确的编译，比如有具体到模块的测试，也有具体到类，函数、方法的测试等

集成测试：又称接口测试，针对模块之间访问地址进行测试。----比如说注册和充值这两个功能是否能够连通

系统测试：针对程序功能、非功能（界面、文档、兼容性、易用性、性能）进行测试

验收测试：主要分为内测、公测，使用不同人群来发掘项目缺陷。

Alpha 测试：把用户请到开发方进行测试，测试环境受到开发方控制，测试人数不多，测试时间集中

Beta 测试：测试环境不受到开发方控制，测试人数较多，测试时间不集中

按代码可见度划分

黑盒测试

不关注源代码，针对程序UI功能进行测试。也是功能测试

白盒测试

全部代码可见，UI 界面不可见（注重内部逻辑）也是单元测测试

灰盒测试

针对程序部分代码进行测试（接口），功能可见，也是接口测试

模型

开发模型

• 瀑布模型（一般不使用）
  • 问题定义及规划（需求规格说明书 SRS）–>需求分析–>设计–>编码–>测试–>运行维护
  • 特点：自上而下，有顺序性
  • 缺点：测试介入较晚，回溯成本较高
• V 模型
  • 
• 敏捷开发模型
  • 迭代周期短，整个项目分为多个独立小项目

测试模型

质量模型（衡量一个优秀软件的维度）

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

测试流程

1. 需求评审
2. 计划编写
3. 用例设计
4. 用例执行
5. 缺陷管理
6. 测试报告

用例设计编写格式

1. 用例编号：：项目简称 _ 功能 _ 编号
2. 用例标题：预期结果（测试点）
3. 项目/模块：对应一个功能模块(细分功能)
4. 优先级：P0 ~ P4（P0 最高）
5. 前置条件：需要满足一些前提条件，否则用例无法执行
6. 测试数据：需要加工的输入信息，根据具体情况来设计
7. 测试步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
8. 预期结果：执行用例期望得到的结果(预期结果唯一，不能出现“是否或者”）

用例设计方法（黑盒测试）

等价类划分法

根据相同特征数据集合进行划分

有效等价类（合法输入）和无效等价类（非法输入）

正向：一次尽可能将多个正确数据组合

逆向（错误）：一次只能覆盖一个

适用场景：需要有大量数据测试输入，但是没法穷举测试的地方（如输入框、下拉列表、单选复选框）

步骤：

1. 明确需求
2. 确定有效和无效等价类（长度、类型、规则）
3. 提取数据编写测试用例

案例：验证手机号合法性

• 区号：空或者是三位数字
• 前缀码：非“0”且非“1”开头的三位数字
• 后缀码：四位数字
• 

边界值分析法

在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）

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

上点：边界上的点(正好等于)（必选）

离点：距离上点最近的点(刚好大于、刚好小于)（闭外开内）

内点：范围内的点(区间范围内的数据)（取中间数）（必选）

测试类似账号密码默认加上：空和已存在

步骤：

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

需求：通过边界值法验证QQ号码的合法性

6~10位自然数

因果图法

当需求中存在多个条件，不同条件中存在不同的结果

列出需求中的因子（条件）和结果

转换为判定表：将因果图转化为判定表，覆盖所有组合。

判定表法

解决多条件依赖的问题

条件桩：列出问题中的所有条件，列出条件的次序无关紧要。

动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束。

条件项：列出条件对应的取值，所有可能情况下的真假值。

动作项：到出条件项的、各种取值情况下应该采取的动作结果。

判定表中贯穿条件项和动作项的一列就是一条规则

假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方种规则

使用场景：

• 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系
• 判定表一般适用于条件组合数量较少的情况 （比如 4 个条件以下）

需求（⽂件修改） ：

• 输入的第一列字符必须是A或B
• 第二列字符必须是一个数字
• 如果第一列字符不正确，则给出信息L
• 如果第二列字符不正确，则给出信息M
• 如果两列字符输入正确，则修改文件成功

场景法（流程图法）

基于用户实际使用场景设计测试用例，模拟端到端的业务流程，验证系统的交互和功能完整性。

画流程图（格式）

步骤：

1. 分析用户业务流程。
2. 设计覆盖主流程、备选流程和异常流程的测试场景。

错误推测法（反推法）

基于经验或直觉推测可能出错的场景，针对性设计测试用例。通常结合历史缺陷数据或常见编程错误。

测试文件上传功能：

上传超大文件、空文件、病毒文件、重复文件名等。

适用场景：经验丰富的测试人员、回归测试或补充其他测试方法。

正交实验法

因果关系比较庞大的情况下，条件很多，组合很多，输出结果很多

什么是bug：漏洞缺陷+改进建议+不符合需求

Bug 等级

• 致命错误：—blocker
  • 常规操作引起的系统崩溃、死机、死循环、闪退
  • 造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
  • 涉及金钱计算
  • 阻断性测试，所有测试工作进行不下去（冒烟测试）
• 严重错误：critical
  • 重要功能不能实现；
  • 错误的波及面广，影响到其它重要功能正常实现
  • 非常规操作导致的程序崩溃、死机、死循环、闪退
  • 外观(界面)难以接受的缺陷；
  • 密码明文显冠； (界面+数据库)
  • 偶现的致命性bug
• 一般错误：major最多
  • 不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
  • 次要功能不能正常实现
  • 操作界面错误（包括数据窗口内列名定义、含义不一致）；
  • 查询错误，数据错误显示；
  • 简单的输入限制未放在前端进行控制；
  • 删除操作未给出提示；
  • 偶现的严重性bug

缺陷管理

项⽬管理⼯具-管理缺陷 (禅道、 JIRA、 TFS)

Excel管理缺陷

缺陷核⼼要素

• 缺陷的标题
• 缺陷的预期结果
• 缺陷的预置条件
• 缺陷的实际结果
• 缺陷的复现步骤
• 缺陷的必要附件

缺陷提交要素

缺陷报告编号

严重程度

• 严重（S1）：主功能
• 一般（S2）：次要功能
• 微小（S3）：易用性、界面
• 建议（S4）：建议性问题

缺陷优先级

• Priority0:24小时之内解决
• Priority1：发布前必须修复
• Priority2：可以在下一个版本中修复

Bug类型

缺陷状态

• new:新建
• Open:打开
• Closed:关闭
• Postponed:延期

缺陷编写

缺陷标题

• 方式1：测试数据+执行结果（预期）
• 方式2：测试数据+执行结果（需求）
• 方式3：测试数据+预期+执行结果

缺陷提交流程