软件测试过程
单元测试
单元测试是针对软件基本组成单元(软件设计最小单位)来进行正确性检测的测试工作
单元测试的目的是检测软件模块对《详细设计说明书》的符合程度
集成测试
是在单元测试的基础上，将所有模块按照概要设计要求组成为子系统或系统，验证组装功能以及模块间接口是否正确的测试工作
集成测试目的是检测软件模块对《概要设计说明书》的符合程度
（主要是来测接口的）
系统测试
系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起， 在实际运行(使用)环境下，对计算机系统进行一系列的测试工作
系统测试的目的在于通过与《需求规格说明书》作比较，发现软件与
系统需求定义不符合或与之矛盾的地方
单元、集成、系统测试的比较
测试方法不同
单元测试属于白盒测试范畴
集成测试属于灰盒测试范畴
系统测试属于黑盒测试范畴
考察范围不同
单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等
集成测试主要测试模块之间的接口和接口数据传递关系，以及模块
组合后的整体功能
系统测试主要测试整个系统相对于需求的符合度
评估基准不同
单元测试的评估基准主要是逻辑覆盖率
集成测试的评估基准主要是接口援盖率
系统测试的评估基准主要是测试用例对需求规格的覆盖率
回归测试
过程：
回归测试可以发生在任意一个阶段，包括单元测试、集成测试、系统测试
回归测试流程：
以下流程适合于单元测试、集成测试和系统测试
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单(问题单)
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
回归测试策略
完全重复测试 ：
重新执行所有在前期测试阶段建立的测试用例，来确认问题修
改的正确性和修改的扩散局部影响性
选择性重复测试：
即有选择地重新执行部分在前期测试阶段建立的测试用例，来
测试被修改的程序
选择性重复测试
覆盖修改法
即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。
周边影响法：
该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。该方法比覆盖修改法更充分一点。
"指标达成方法：
这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。
**风险识别法：**
调测试用例等级高的或用户访问高的用例进行测试
回归测试自动化
(1)回归测试是-个重用以前成果的测试，很难预料到要经过多少次回归系统才能达到满意的水平，结果，这种回归测试将可能演变成一种重复的、 令人心烦意乱的工作，效果与人员的积极性将大打折扣，因此，在回归测试道路上的自动化便是我们工作的追求
(2)回归测试的自动化法包括测试程序的自动运行、自动配置，测试用例的管理和自动输入，测试的自动执行，测试信息与结果的自动采集，测试结果的自动比较和结论的自动输出，尤其前面提到的各类数据的共享决策
(3)对系统测试功能比较简单、测试界面相对稳定并且测试用例良好组织的测试来说，采用“捕捉回放”工具是比较合适的，这类工具有QTP、Robot、 SilkTest等
(4)为了实现测试用例的自动化并实现测试结果的自动判断，脚本化的、包含控制结构、内部实现结果判断的测试用例是唯一的选择，此类脚本语言有TCL、Python、 Perl等
(5)对于特定系统的、复杂的测试来讲，如果没有通用的商用工具可供选择，探索开发专用的自动化测试工具是灵活且易于扩充的方法
(6)回归测试的自动化(或者说工具化)的问题是个需要尽 早考虑的问题，在做测试方案时就要考虑这种可能性，必要时要投入资源进行开发，能形成可供继承与推广的工具则是最终目的
其他测试阶段
单元测试、集成测试、系统测试是软件开发过程中在软件组织内部进行的测试阶段
软件正式发布前还可能进行有用户参与的其他一些测试，如:
- 验收测试
- α(ALPHA)测试
- β (BETA)测试
验收测试
- (时间)在通过了内部系统测试及软件配置审查之后，就可以开始
- (人员)验收测试验收测试是以用户为主的测试，验收组应该由项目组成员、用户代表等组成模拟用户环境进行
- (地点)验收测试根据合同、《需求规格说明书》 或《验收测试计划》对成品进行验收测试
- (依据和结果)验收测试的结果有两种情况：
- 软件功能、性能等质量特性与用户的要求一致，软件可以接受
- 软件功能、性能等质量特性与用户的要求有差距，不被用户接受
α测试
- α测试是由用户在开发环境下（时间）进行的测试，也可以是开发机构内部的用户在模拟实际操作环境（地点）下进行的测试
- α测试时，软件在一个自然设置状态下使用。开发者坐在用户旁（人员），随时记下错误情况和使用中的问题。这是在（特点）受控制的环境下进行的测试
- α:测试的目的主要是评价软件产品的FLURPS (即功能、局域化、可用性、可靠性、性能和技术支持)
β测试
- β测试是由软件的（人员）多个用户在一个或多个用户的(时间)实际使用环境下进行的测试
- 与α测试不同的是，β测试时开发者通常不在测试现场。因而，β测试是在开发者(特点)无法控制的环境下进行的软件现场应用
一般先做α测试、再做β测试
测试过程阶段划分
测试计划阶段（测试经理） —— 测试计划
测试设计阶段（测试主管） —— 测试方案
测试实现阶段（中高级测试工程师） —— 测试用例、测试规程
测试执行阶段（初级工程师） —— 测试报告
单元测试（UT）、集成测试（IT）、系统测试（ST）每个测试阶段都有4个阶段的划分：
主要的测试文档
- 测试计划:指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。（做什么（组织层面））
- 测试方案:指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。（怎么做（技术方面））
- 测试用例:指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。（用例是一个评估标准）
- 测试规程:指明执行测试时测试活动序列的文档。（上一个测试结果是下一个测试条件）
- 测试报告:指明执行测试结果的文档。
- 测试日报:每天测试执行情况的记录和总结。
测试过程规范
CMM关于过程的要素
- 角色（Roles）
- 入口准则(Entry Criteria)
- 输入(Inputs)
- 活动(Activities)
- 输出(Outputs)
- 出口准则(Exit Criteria)
- 评审和审计(Reviews and Audits)
- 可管理和受控的工作产品( Work Products Managed and Controlled)
- 测量(Measurements)
- 书面规程(Documented Procedures)
- 培训(Training)
- 工具(Tools)
系统测试各个阶段的输入、输出
需求分析阶段的主要任务
- 需求分析，完成SRS（《软件需求规格说明书》）
- 软件需求规格说明书的评审
- 进行需求跟踪
- 系统测试计划（任务安排、工作量）
- 系统测试计划的评审
需求分析的困难：
- 交流困难，客户交流，开发交流
- 需求分析是不断变化的
- 后续影响比较复杂
需求分析需要考虑：可行性
需求阶段的角色和职责
软件开发项目经理
A、带领项目组分析审核工作任务书;
B、带领项目组与系统工程师进行需求交流并进行分析和文档化;
C、组织SRS文档评审:
D、组织需求跟踪:
软件开发工程师
A、完成SRS文档:
B、完成需求跟踪;
C、参加SRS review;
D、根据SRS评审专家意见，修改SRS文档;
E、参加系统测试计划的评审;
软件经理
A、在SRS评审结束后，批准SRS文档;
QA
A、监督项目组遵循需求管理流程:
B、参加相关文档review;
C、保证相关组参加文档review ;
CCB的负责人
A、控制需求的变更
软件测试项目经理
A、参与开发人员的软件需求分析，提出可测试性需求;（测什么、不测什么、可不可测等）
B、组织人员参与SRS的评审工作;
C、软件系统测试计划写作;
D、组织系统测试计划的评审;
E、组织本阶段测试需求跟踪;
软件测试工程师
A、参与SRS评审工作;
B、协助软件测试项目经理完成软件系统测试计划写作;
C、参加系统测试计划的评审;
D、完成本阶段测试需求跟踪;
UT/IT/ST执行阶段的角色和职责
开发组项目经理
A.确保缺陷分发给相关软件工程师井监督及时得到解决:
B、提出转系统测试申请;
软件开发人员
A、修正缺陷;
B、验证相关的缺陷已经被修正;
C、参加各阶段测试报告的评审;
软件测试项目经理
A、组织所有的测试执行活动，安排井监督测试执行任务;
B、确保选择适合的测试工具以及测试环境的建立;
C、确保缺陷分发给相关软件工程师井及时得到解决;
D、组织测试报告和系统测试预测试报告的写作;
E、组织测试报告的评审;
F、组织转系统测试评审;
软件测试工程师
A、搭建测试环境;
B、执行测试用例;
C、发现缺陷后提交缺陷报告;
D、回归测试;
E、每天提交测试日报;
F、测试报告及系统测试预测试报告写作;
G、参加测试报告的评审;
H、参加转系统测试评审;