软件测试的分类(按阶段分类)：

单元测试、集成测试、系统测试、验收测试

1. 单元测试是其他阶段的基础，测试对象是最小的可测试单元
2. 集成测试是关注每个最小单元模块的接口和子系统的集成
3. 系统测试是把整个系统组装后在真实运行环境下对整个系统进行全面的评估
4. 验收测试强调从用户角度对这个系统软件认可的验收

集成测试：

• 集成测试的实施方案：

1. Big Bang
2. 自顶向下
3. 自底向上
4. 核心系统集成
5. 高频集成(持续集成)

• 集成测试与单元测试的区别：

1. 测试对象不同
2. 测试依据不同(集成测试依据是概要设计文档，单元测试依据是详细设计文档)
3. 测试方法不同

系统测试：

•  关注点：

1. 系统本身的使用
2. 系统与其他相关系统间的连通
3. 系统在不同使用压力下的表现
4. 系统在真实使用环境下的表现

• 系统测试与集成测试的区别：

1. 测试对象不同
2. 测试时间不同
3. 测试内容不同
4. 测试角度不同

验收测试(交付测试)：

•  细分分类：

1. 用户验收测试(开发方)
2. 运行验收测试(运维)
3. 合同和规范验收测试
4. alpha测试(用户,开发者提供环境)
5. Beta测试(脱离开发者提供的环境,用户环境)

软件测试的分类(按测试手段分类)：

1. 测试对象可见度：黑盒测试、白盒测试
2. 测试状态：静态测试、动态测试
3. 测试执行方式：手工测试、自动化测试

黑盒测试：

 不打开盒子，考虑外部结构，不考虑内部逻辑，检查功能

• 优点:

1. 容易实施，不需要关注内部的实现
2. 更贴近用户的使用角度

• 缺点:

1. 测试覆盖率较低，一般只能覆盖不到40%
2. 针对黑盒的自动化测试，复用率较低，维护成本较高

• 测试什么？

1. 是否有不正确或者遗漏的功能
2. 在接口上，输入是否能正确的接受，能否输出正确的结果
3. 是否有数据结构错误或外部信息(例如数据文件)访问错误
4. 性能上是否能够满足要求

• 黑盒测试的主要设计方法：

1. 等价类划分法
2. 流程分析法
3. 状态迁移图法
4. 正交试验分析法
5. 因果图法
6. 错误推测法
7. 边界值分析法

白盒测试(结构化测试、透明盒测试)：

 打开盒子，考虑内部逻辑

•  主要的逻辑单位：

   语句、条件、条件组合、分支、路径

• 优点：

1. 迫使测试人员去仔细思考软件的实现，理解原理
2. 可以检测代码中的每条分支和路径
3. 揭示隐藏在代码中的错误
4. 对代码的测试比较彻底

• 缺点：

1. 昂贵
2. 无法检测代码中遗漏的路径和数据敏感性错误
3. 不能直接验证需求的正确性

• 白盒测试的主要测试方法：

     代码检测法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法 

灰盒测试：

 介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现(系统软件层)

静态测试：

  方式：互审、走查、会议

手工测试：

  众包测试、探索式测试

自动化测试：

  单元测试、接口测试、性能测试等

• 手工测试与自动化测试的区别:

软件测试的分类(按测试模式分类)：

 瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等

瀑布模型：

项目计划—>需求分析—>软件设计—>程序开发—>软件测试—>集成维护

• 优点：

1. 强调需求、设计的作用
2. 前一阶段完成后，只需关注后续阶段
3. 为项目提供了按阶段划分的检查点，里程碑清晰
4. 文档规范

• 缺点：

1. 难以适应需求的频繁变化
2. 项目周期后段才能看到成果
3. 强制的里程碑、完成时间点
4. 文档工作量大

V模型：

 需求分析—>概要设计—>详细设计—>软件编码—>单元测试—>集成测试—>系统测试—>验收测试

W模型：

 X模型：

 H模型：

1e378 敏捷测试：

 Agile Testing--遵循敏捷宣言的一种测试实践

• 敏捷宣言：

1. 个体与交互  重于 过程和工具
2. 可用的软件 重于 完备的文档
3. 客户协作 重于 合同谈判
4. 响应变化 重于 遵循计划

   （在每对比较中，后者并非全无价值，但我们更看重前者）

强调从客户角度进行测试
重点关注迭代测试新功能，不在强调测试阶段
尽早测试，不间断测试，具备条件即测试
强调持续反馈
预防缺陷重于发现缺陷

• 敏捷测试与传统测试的区别：

基于脚本的测试-SBT

1. Script-based Testing
2. Scripted Testing(ST)
3. Exploratory Testing(ET)

• 探索式测试(ET)

1.  完全抛开测试脚本的测试
2.  它是一种测试风格、思维而不是一种测试技术

• ST和ET的区别：

• 探索式测试的优点：

1. 更能激发测试人员的创造性和工作乐趣
2. 增加了发现新的或较深入Bug的可能性
3. 在较短时间内找到更多Bug以及对SUT作一个快速的评估
4. 有利于更加有效地实施自动化
5. 更加适用于敏捷项目
6. 减少了在简单、繁复上用例的无谓编写时间

• 探索式测试的缺点：

1. 测试管理上有局限性，较难协调和控制
2. 对于Bug的重复利用和重视上作用有限
3. 对测试人员的测试技能和业务知识深度依赖较大
4. 只有在SUT已完全可用的前提下才更有作用
5. ET的生产率很难定义
6. ET本身较难进行自动化

• 局部探索式测试：

 输入 状态  代码路径  用户数据 执行环境

• 全局探索式测试：

• 执行探索式测试

    
基于风险的测试-RBT(Risk-based  Testing)

一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型

• 风险：

质量风险、管理风险
风险级别 = 风险可能性 * 风险严重度

• 识别风险：

可能性：复杂性、时间压力、高变更率、技能水平、地理分散度
严重程度：使用频率、失效可视性、商业损失、组织负面影响和损害、社会损失和法律责任
风险要素分=Sum(单项权重*得分)

基于模型的测试-MBT

 主要MBT工具：Spec Explorer(Microsoft)、GraphWalker(OpenSource)、Tcases(OpenSource)、modeljunit(OpenSource)