测试阶段划分
单元测试（Unit Testing）
针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作。（检测软件模块对《详细设计说明书（LLD）的符合度》）。
集成测试（Integration Testing）
在单元测试的基础上，将所有模块按照概要设计组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作。（检测软件模块对《概要设计说明书（HLD）的符合度》）
系统测试（System Testing）
将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作。（通过与《需求规格说明书（SRS）》作比较，发现软件与系统需求定义不符合或之矛盾的地方）
单元、集成、系统测试的比较
1） 测试方法不同
单元测试属于白盒测试范畴
集成测试属于灰盒测试范畴
系统测试属于黑盒测试范畴
2） 考察范围不同
单元测试主要测试单元内部的数据结构、逻辑结构、异常处理等
集成测试主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能
系统测试主要测试整个系统相对于需求的符合度
3） 评估基准不同
单元测试主要是逻辑覆盖率
集成测试主要是接口覆盖率
系统测试主要是测试用例对需求规格的覆盖率
回归测试（Regression Testing）
目的：验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。
（注：回归测试可以发生在任何一个阶段）
回归测试策略
1） 完全重复测试
重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性。
2） 选择性重复测试
即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序
a) 覆盖修改法
即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法
b) 周边影响法
该方法不但包含覆盖修改法确定的测试用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响，该方法比覆盖修改法更充分一点。
c) 指标达成法
这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改的部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。
回归测试流程（适用于单元测试，集成测试，系统测试）
1） 在测试策略制定阶段，制定回归测试策略
2） 确定需要回归测试的版本
3） 回归测试版本发布，按回归测试策略执行回归测试
4） 回归测试通过，关闭缺陷跟踪单（问题单）
5） 回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
（注：回归测试比较适合使用自动化工具）
其他测试阶段
1） 验收测试
a) 验收测试是以用户为主的测试，验收组应该由项目组成员，用户代表等组成
b) 在通过内部系统测试及软件配置审查后，就可以开始验收测试
c) 验收测试原则上在用户所在地进行，但经用户同意也可以在公司内模拟用户环境
d) 验收测试根据合同、《需求规格说明书》或《验收测试计划》对产品进行验证
e) 结果两种（接受与不接受）
2） Alpha测试（属于验收测试）
由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。
目的主要是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和技术支持等）
3） Beta测试（属于验收测试）
由软件的多个用户在一个或多个用户的实际环境下进行测试
Alpha测试和Beta测试的区别
Alpha测试过程可控，但是参与人数有限；Beta测试参与人数巨大，但是过程不可控。
测试过程模型
测试过程阶段划分
1） 测试计划阶段：测试计划
2） 测试设计阶段：测试方案
3） 测试实现阶段：测试用例、测试规程
4） 测试执行阶段：测试报告
主要测试文档
测试计划：指明测试范围、方法、资源、以及相应测试活动的时间进度安排表的文档。
测试方案：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。
测试用例：指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。
测试规程：指明执行测试时测试活动序列的文档。（后执行用例的输入是先执行用例的输出）
测试报告：指明执行测试结果的文档。（注：1）将工作过程表现出来 2）表明个人对测试对象的态度）
测试日报：每天测试执行情况的记录和总结。
常见的测试过程模型
1） 瀑布模型
缺陷：
a) 测试介入太晚
b) 工作效率低
c) 成本巨大
2） H模型
优点：
a) 测试与其他流程并发的进行
b) 测试准备和测试执行分开
V&V模型
优点：
a) 测试与其他流程并发的进行
b) 测试准备和测试执行分开
c) 测试过程子阶段与开发过程子阶段一一对应。
V&V的含义
验证（Verification）和确认（Validation）
验证：（“Are we building the product right?”）
1） 验证是保证软件正确地实现特定功能的一系列活动
2） 验证是检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致
确认：（“Are we building the right product?”）
1） 确认是指保证所生产的软件可追溯到用户需求的一系列活动
2） 确认是检测每一阶段的工作产品是否与最初定义的软件需求规格相一致
测试过程规范
CMM关于过程的要素
1） 角色（Roles）：人
2） 入口准则（Entry Criteria）：执行活动所必须满足的条件
3） 输入（Inputs）：完成某活动所需要加工或参考的资料、原材料
4） 活动（Activities）：流程由一系列有相互关系的活动组成
5） 输出（Outputs）：完成某活动后所提交的工作产品
6） 出口准则（Exit Criteria）：完成或退出某活动所必须满足的条件
7） 评审和审计（Reviews and Audits）
8） 可管理和受控的工作产品（Work Products Managed and Controlled）
9） 测量(Measurements)：客观指标（一组数据）
10） 书面规程（Documented Procedures）
11） 培训（Training）：技术支持
12） 工具（Tools）：辅助说明
13） 职责：权责定义
14） 模板：标准格式
15） 检查表（Checklist）：要点列表
