l  软件测试：功能测试、性能测试

【软件= 程序 + 文档 + 数据

程序     实现软件的源代码（功能需求、性能需求、界面需求）

文档     需求规格、说明书、用户手册、安装手册、使用说明书…

数据     驱动程序、硬件设备

测试   检测被测目标实际结果与预期的结果是否一致。】

l  定义软件测试

人工和自动手段来运行或测试，检验是否满足规定的需求及其的差别；

为了发现错误而执行程序的过程；

测试方案（方法与设计）及用例；

l  软件测试含义：

1、是一个过程；

2、可以以人工或工具测试；

3、可以运行也可不运行；

4、不仅仅为了发现错误；

l  一个好的测试程序

是项目的主要成本；

可以极大地定义需求和设计；

使修改缺陷成本降低；

有助于发现许多问题；

l  软件测试的目的：

1. 发现软件存在的缺陷；（证明）
2. 协助修改缺陷并对现有的质量信息进行分析；（检测）
3. 预防软件产生的风险；（预防）

l  软件测试的主要工作

1. 检视代码、评审开发文档
2. 进行测试设计、写作测试文档（测试计划、方案、用例等）
3. 执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到了修正
4. 通过测试度量软件的质量

软件生命周期：计划、开发、维护

计划         问题的定义（系统的目标与范围说明书）、可行性研究（技术、资金、资源）【可行性研究报告】【项目实施计划】

开发     需求分析（需求规格说明书）、设计【总体设计（概要设计说明书）、详细设计（详细设计说明书）】、编码（编写源代码）、测试（单元测试（参照详细设计说明书LLD）、集成测试（参照概要设计说明书HLD）、系统测试(需求规格说明书SRS））

维护      运行

l  软件项目组人员组成：

分析人员；设计人员；开发人员；

测试人员；

配置管理人员（CMO）；

SQA（质量保证人员）；

l  常见软件研发流程：

瀑布模型：

瀑布模型的缺点：

开发模型是线性的，用户只能到整个过程的末期才能见到开发成果；

测试介入比较晚；

不能适应需求的变化；

瀑布模型的优点：

适于小型项目；

为项目提供了按阶段划分的检查点；（规定自上而下、相互衔接的固定次序）

一个阶段完成后，只需关注后续阶段；

螺旋模型：4个阶段

1. 制定计划
2. 风险分析
3. 实施（开发和测试）
4. 客户评价

螺旋模型的优点：

设计上的灵活性；

有利于大型软件开发；

提高了开发的质量和效率；

可控性；

螺旋模型的缺点：

需要相当丰富的风险评估经验和专门的知识；

开发过程一般不能逆转；

实际项目开发很难严格的按模型进行；

 l   

软件缺陷：静态存在于软件工作产品（文档、代码）中的错误；

          （软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。）

Bug：   代码中的缺陷；  

        （因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。）

 常见的引入缺陷的原因：

1. 开发过程缺乏有效的沟通，或者没有沟通；
2. 软件复杂度越来越高；
3. 编程中产生错误；
4. 需求不断变更；
5. 项目进度的压力；
6. 不重视开发文档；
7. 软件开发工具本身隐藏的问题；

缺陷类型：

遗漏： 规定或预期的需求未体现在产品中

错误： 未将规格说明正确实现

额外的实现： 规格说明并未规定的需求被纳入产品，得到实现

l  测试阶段划分：了解对象和参照

单元测试    软件基本组成单元；目的是检测软件模块对【详细设计说明书】的符号程度；

集成测试    在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作；目的是检测软件模块对【概要设计说明书】的符号程度；

系统测试    将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作；目的对【需求规格说明书】；

l   

单元测试属于 白盒测试；

集成测试属于 灰盒测试；

系统测试属于 黑盒测试；

l  考察范围不同

单元测试        单元内部的数据结构、逻辑控制、异常处理等；

集成测试        模块之间的接口和接口数据传递关系，以及模块组合后的整体功能；

系统测试        整个系统相对于需求的符合度；

l  评估基准不同：

单元测试              主要是逻辑覆盖率

集成测试              主要是接口覆盖率

系统测试              主要是测试用例对需求规格的覆盖率

回归测试贯穿整个测试，可以在任何一个阶段；目的验证缺陷得到了正确的修复，同时对系统其他模块没有任何影响；

l  回归测试策略：

一、完全重复测试（优点降低风险，缺点耗资成本大）

二、选择性重复测试

1. 1.         覆盖修改法         针对被修改的部分
2. 2.         周边影响法         被修改的部分与间接影响的部分
3. 3.         指标达成方法       不确定影响范围情况下

l  回归测试流程

1. 在测试策略制定阶段，制定回归测试策略；（制定策略）
2. 确定需要回归测试的版本；（确认版本）
3. 回归测试版本发布，按照回归测试策略执行回归测试；（按策略执行）
4. 回归测试通过，关闭缺陷跟踪单、问题单；（通过，关闭缺陷跟踪单）
5. 回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试；（不通过，重新返回修改）

软件正式发布前用户参与的一些测试：

验收测试： 参照合同、需求规格说明书、

α测试 参与人员是用户、开发、测试人员在内部进行测试

β测试  参与人员是用户，在外部进行测试（实际使用环境下进行）

测试过程阶段划分：

测试计划阶段（时间进度安排表）：测试计划

测试设计阶段：测试方案

测试实现阶段：测试用例、规程

测试执行阶段：测试报告

测试过程模型：

测试H模型（适于任何流程）： 测试准备（需求分析、计划、设计、编码、验证）

                            测试执行（运行、报告、结果分析）

测试V模型：需求分析   概要设计    详细设计     编码    代码审查   执行单元测试    执行集成测试    执行系统测试；

实现了测试设计和测试执行相分离；

测试W模型：开发和测试同时进行；

验证（过程）与确认（结果）

l  五大模型概要：

l  需求分析阶段的主要任务：

1、  完成SRS

2、  需求评审

3、  需求跟踪

4、  计划

5、  计划评审

软件测试工程师职责：

1、  搭建测试环境

2、  执行测试用例

3、  发现缺陷后提交缺陷报告

4、  回归测试

5、  每天提交测试日报

6、  测试报告及系统测试预测试报告写作

7、  参加测试报告的评审

8、  参加转系统测试评审