1 测试过程
1.1 测试阶段划分
测试阶段划分：需求测试（重点）、单元测试、集成测试、系统测试（重点）、验收测试、回归测试
需求测试
定义：通过评审来测试需求（通过不同级别不同类型的评审来避免人员意见）
单元测试
定义：针对软件基本组成单元（软件的最小组成单元：函数，语句块等）来进行正确性检验的测试工作
目的：检测软件模块对《详细设计说明书》的符合程度
集成测试
定义：将所有模块按照《概要设计说明书》的要求组装成子系统或者系统，验证组装后的功能以及模块间接口是否正确的功能
目的：检测软件模块对《概要设计说明书》的符合程度
系统测试
定义：将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员（用户）等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机进行一系列的测试工作
目的：通过与《需求规格说明书》作比较，发现软件与系统需求定义不符合或与之矛盾的地方
回归测试
定义：软件在测试或其他活动中发现的缺陷经过修改后，应该进行回归测试（Regression Testing）
目的：验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能
回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试
回归测试过程信息流：
回归测试策略：
完全重复测试：重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性。
选择性重复测试：（新发现的缺陷用例，和覆盖主要功能的用例）有选择性重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序。
选择性重复测试的方法：
① 覆盖修改法：针对被修改的部分，选取或重新构造测试用例，验证有没有错误再次发生的用例选择方法；
② 周边影响法：该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。周边覆盖法比覆盖修改法更充分一点；
③ 指标达成方法：这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改代码部分100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。
回归测试的流程：（以下流程适合单元测试、集成测试和系统测试）
① 在测试策略制度阶段，制定回归测试策略；
② 确定需要回归测试的版本；
③ 回归测试版本发布，按照回归测试策略执行回归测试；
④ 回归测试通过，关闭缺陷跟踪单；
⑤ 回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再提交测试人员回归测试。
回归测试自动化：
① 回归测试是重用以前成果的测试，很难预料要经过多少次回归系统才能达到满意的水平，结果，这种回归测试将可能演变成为一种重复的、令人心烦意乱的工作，效果与人员的积极性大打折扣，因此，在回归测试道路上的自动化便是我们工作的追求；
② 回归测试的自动化法包括测试程序的自动运行、自动配置，测试用例的管理和自动输入，测试的自动执行，测试信息与结果的自动采集，测试结果的自动比较和结果的自动输出，尤其前面提到的各类数据的共享决策；
③ 对系统测试功能比较简单、测试界面相对稳定并且测试用例良好组织的测试来说，采用“捕捉回放”工具比较合适，这类工具有QTP、Robot、SilkTest等；
④ 为了实现测试用例的自动化并实现测试结果的自动判断，脚本话的、包含控制结构、内部实现结果判断的测试用例是唯一的选择，此类脚本语言有TCL、Python、Perl等；
⑤ 对特定系统的、复杂的测试来讲，如果没有通用的商用工具可供选择，探索开发专用的自动化测试工具是灵活且 易于扩充的方法；
⑥ 回归测试的自动化（或者说工具化）的问题是一个需要尽早考虑的问题，在做测试方案时就要考虑这种可能性，必要时要投入资源进行开发，能形成可供继承的工具则是最终目的。
单元测试、集成测试和系统测试是软件开发过程中在软件组织内部进行的测试阶段。软件发布前还可能进行用户参与的其他一些测试，如：验收测试、α测试、β测试。
验收测试
在通过了系统内部测试及配置审查之后，就可以开始验收测试。
验收测试是以用户为主的测试，验收组应该由项目组成员、用户代表等组成。
验收测试原则在用户所在地进行，如经用户同意也在公司内模拟用户环境进行。
验收测试根据合同、《需求规格说明书》或验收测试计划对成品进行验收测试。
验收测试的结果有两种情况：
① 软件功能、性能等质量特征与用户要求的一致，软件可以接受；
② 软件功能、性能等质量特征与用户要求有差距，不被用户接受。
α测试
定义：用户在开发环境进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。是可控制环境，开发测试人员可以修改控制的环境。α测试时，软件在一个自然状态下使用，开发者在旁，随时记录错误情况和使用中的问题。这是在受控的环境下进行的测试。
目的：评价软件产品的FLURPS（功能，局域化，可用性，可靠性，性能和技术支持）
β测试
定义：由软件的多个用户在一个或多个用户的实际环境下进行的测试。与α测试不同的是，β测试时开发者通常不在现场，因而，β测试是在开发者无法控制的环境下进行的软件现场应用。
单元测试，集成测试，系统测试的比较
测试方法不同
单元测试属于白盒测试
集成测试属于灰盒测试
系统测试属于黑盒测试
考察范围不同
单元测试主要测试单元内部的数据结构，逻辑控制，异常处理 等
集成测试主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能
系统测试主要测试整个系统相对于需求的符合度
评估基准不同
单元测试的评估基准主要是逻辑覆盖率
集成测试的评估基准是接口覆盖率
系统测试的评估基准主要是测试用例对需求规格的覆盖率
1.2 测试过程模型
测试过程阶段划分
测试计划阶段：测试计划
测试设计阶段：测试方案
测试实现阶段：测试用例、测试规程
测试执行阶段：测试报告
主要的测试文档
测试计划：指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档
测试方案：指明为完成软件或软件集成特征的测试而进行的设计测试方法的细节文档
测试用例：指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档
测试规程：指明执行测试时测试活动序列的文档
测试报告：指明测试执行结果的文档
测试日报：每天测试执行情况的记录和总结
常见测试过程模型：瀑布模型、H模型、V&V模型
瀑布模型
H模型：
H模型测试分两类活动：
① 测试准备活动，包括测试需求分析、测试计划、测试设计、测试编码、测试验证
② 测试执行活动，包括测试运行、测试报告、测试结果分析等
H模型的特点：
① 软件测试不仅仅指测试执行，还包括许多其他测试活动
② 测试是一个独立的流程，贯穿产品整个周期，与其他流程并发地进行
③ 测试要尽早准备，尽早执行
④ 各个不同阶段的测试除了简单的时间上的先后关系外，还存在触发、反复、迭代和增量关系
V&V模型
V&V模型的特点
① 实现了测试设计和测试执行相分离
② 揭示了软件测试活动分层和分阶段的本质特性，测试执行的顺序与开发活动相反
验证与确认：
验证（Verification）：
① 保证软件正确地实现特定功能的一系列活动
② 检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致
确认：
① 保证所生产的软件可追溯到用户需求的一系列活动
② 检测每一阶段的工作产品是否与最初定义的需求规格相一致
验证与确认的关系图
1.3 测试过程规范
CMM关于过程的要素
角色、入口准则、输入、活动、输出、出口准则、评审和审计等
集成测试过程
概要设计——详细设计——执行集成测试
概要设计
输入：SRS、系统测试计划
输出：集成测试计划、系统测试方案、系统测试用例、预测试项、规程、阶段报告
详细设计
输入： SRS、系统测试计划、系统测试方案、集成测试计划
输出：单元测试计划、集成测试方案、集成测试用例、集成测试规程、阶段报告
执行集成测试：
输入： 单元测试报告、集成测试计划、集成测试方案、集成测试用例、集成测试规程
输出：集成测试报告、阶段报告
集成测试过程与开发阶段
概要设计（集成测试计划）——详细设计（集成测试设计、实现）——集成测试执行
集成测试各阶段的输入、输出
集成测试计划阶段：
输入：软件测试计划、概要设计说明书（HLD）
输出：集成测试计划
集成测试设计阶段：
输入：概要设计说明书（HLD）、集成测试计划
输出：集成测试方案
集成测试实现阶段：
输入：软件测试计划、详细设计说明书
输出：单元测试计划
集成测试执行阶段：
输入：详细设计说明书、单元测试计划
输出：单元测试方案
单元测试过程
详细设计——编码——执行单元测试
单元测试各阶段的输入、输出
单元测试计划阶段：
输入：软件测试计划、详细设计说明书（LLD）
输出：单元测试计划
单元测试设计阶段：
输入：详细设计说明书（LLD）、单元测试计划
输出：单元测试方案
单元测试实现阶段：
输入：单元测试计划、详细设计说明书、单元测试方案
输出：单元测试用例、单元测试规程
单元测试执行阶段：
输入：单元测试方案、单元测试计划、单元测试用例、单元测试规程
输出：单元测试报告、缺陷报告
需求分析阶段的主要任务
① 需求分析，完成SRS
② SRS的评审
③ 进行需求跟踪
④ 系统测试计划
⑤ 系统测试计划的评审
需求阶段的角色和职责
软件测试工程师：
① 参与SRS评审工作
② 协助软件测试项目经理完成软件系统测试计划写作
③ 参加系统测试计划的评审
④ 完成本阶段测试需求跟踪
概要设计阶段的主要任务
① 完成HLD
② 概要设计的评审
③ 系统测试方案、用例的设计
④ 系统测试方案、用例的评审
⑤ 需求跟踪更新
⑥ 集成测试计划
⑦ 集成测试计划评审
概要设计阶段的角色和职责
软件测试工程师：
① 参与HLD评审
② 参与集成测试计划的评审
③ 进行系统测试方案、用例的设计
④ 参与系统测试方案、用例的评审
⑤ 完成本阶段测试需求跟踪
详细设计阶段的主要任务
① 进行软件详细设计，完成LLD
② 详细设计的评审
③ 集成测试的方案、用例的设计
④ 集成测试的方案、用例的评审
⑤ 需求跟踪更新
⑥ 单元测试计划
⑦ 单元测试计划评审
详细设计阶段的角色和职责
软件测试工程师：
① 进行软件详细设计，完成LLD文档
② 详细设计的评审
③ 集成测试方案、用例的设计
④ 集成测试方案、用例的评审
⑥ 需求跟踪更新
⑦ 单元测试计划
⑧ 单元测试计划评审
软件编码阶段的主要任务
① 软件编码
② 代码静态质量检查
③ 代码评审
④ 单元测试方案、用例设计
⑤ 单元测试方案、用例评审
软件编码阶段的角色和职责
软件测试工程师：
① 参与代码评审
② 进行单元测试方案、用例设计
③ 单元测试方案、用例评审
④ 完成本阶段测试需求跟踪
集成测试执行阶段的主要任务
① 集成测试用例执行
② 集成测试缺陷记录、修复
③ 集成测试日报写作
④ 集成测试缺陷的回归测试
UT/IT/ST执行阶段的角色和职责
软件测试工程师：
① 搭建测试环境
② 执行测试用例
③ 发现缺陷后提交缺陷报告
④ 回归测试
⑤ 每天提交测试日报
⑥ 测试报告及系统测试预测试报告写作
⑦ 参与测试报告的评审
⑧ 参与转系统测试评审
2 测试方法
测试方法的分类：
按方法区分：白盒测试、灰盒测试、黑盒测试
按照是否执行被测程序区分：静态测试、动态测试
根据执行测试的方式区分：人工测试、自动化测试
2.1 白盒测试
定义：依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能的实现情况。白盒测试是基于程序结构的逻辑驱动测试。
为什么要进行白盒测试
它一般在测试前期进行，通过达到一定的逻辑覆盖率使软件内部逻辑控制结构上的问题能够基本得到消除
保证内部逻辑结构达到一定的覆盖程度，能够给予软件代码质量更大的保证，白盒测试发现问题后解决问题成本较低
白盒测试的常用技术
静态分析技术：控制流分析技术，数据流分析技术，信息流分析技术（不执行代码）
动态分析技术：逻辑覆盖率测试（分支测试，路经测试），程序插装
控制流相关概念
程序元素：一个程序元素通常是一个条件，一个简单的语句或者一块语句（多个连续语句）
控制流关系：一个程序的控制流关系，叙述了程序元素和它们执行的次序之间的联系
控制流图：对应于控制流关系的图
控制流矩阵：由控制流图得到，反映相邻程序元素之间的先后顺序关系
控制流分析的步骤
1.确定所有程序元素
2.根据程序元素之间的相互关系得到控制流图
3.将控制流图转换成控制流矩阵
4.通过数据结构的形式把控制流矩阵表示出来
控制流分析能发现的问题
转向并不存在的标号
没有用的语句标号
从程序入口进入后无法达到的语句
不能达到停机语句的语句
数据流相关概念
数据定义：如果程序中某一语句执行时能改变某程序变量V的值，则称V是被该语句定义的
数据的引用：如果一语句的执行引用了内存中变量V的值，则说该语句引用变量V
数据流分析步骤
1.根据代码得到数据流表
2.分析数据流表找到以下两种错误：
3.变量未定义但被引用
4.变量定义但未被引用
信息流分析
可以导出程序的信息流的关系，为软件开发的确认提供了工具。
通过以下三个关系表给出：
输入变量和语句关系：输入变量直接或间接影响语句的执行
语句和输出变量关系：语句执行直接或间接影响变量的输出
输入和输出变量关系：输入变量直接或间接影响输出变量
信息流分析步骤
根据代码得到三个关系表
分析输入变量和语句关系表
分析语句和输出变量关系表
分析输入和输出变量关系表
逻辑覆盖测试
根据覆盖的对象不同：
语句覆盖
判定覆盖
条件覆盖
判定—条件覆盖
路径覆盖
,,,,,,
程序插装
我们在调试程序，常常要在程序中打印一些语句，其目的在于，希望执行程序时，打印出我们最关系的信息。进一步通过这些信息了解执行过程中程序的一些动态特征。比如，程序实际执行路径，或是特定变量在特定时刻的取值。
从这一思想发展出的程序插桩技术能够按用户的要求，获取程序的各种信息，成为测试工作的有效手段。程序插桩简单地说就是借助往被测程序中插入操作来实现测试目的的方法。
白盒测试的特点
优点：
1.迫使测试人员去自觉地思考软件的实现
2.可以检测代码中的每条分支和路径
3.揭露隐藏在代码中的错误
4.对代码的测试比较彻底
5.实现代码结构上的最优化
缺点：
1.昂贵
2.无法检测代码中遗漏的路径和数据敏感性错误
3.不验证规格的正确性
2.2 黑盒测试
定义：只考虑其整体特性，不考虑其内部具体实现，是基于规格的测试
对象: 系统，子系统，子模块，函数
黑盒测试类型和质量模型
来源于质量模型
将软件的特性和质量特性结合起来就得到了测试类型
一个软件特性可以和一个质量特性结合得到一个测试类型
一个软件特性可以和多个不同的质量特性结合得到多个不同的测试类型
常见的黑盒测试方法
等价类划分法
边界值分析法
因果图分析法
判定表法
状态迁移法
错误猜测法
………
注：不管是什么测试方法，都是为了减少测试时的测试用例数，都是为了用尽量少的测试用例去完成测试，去发现更多问题。
黑盒测试的特点
1.对于更大的代码单元来说，比白盒测试效率更高
2.测试人员不需要了解实现细节
3.测试人员和编码人员彼此独立
4.从用户和编码人员视角进行测试，很容易被大家理解和接受
5.有助于暴露任何规格不一致或有歧义的问题
6.测试用例可以再规格完成之后马上进行
7.只有一小部分可能的输入被测试到 ，要测试每个可能的输入流几乎是不可能的
8.没有清晰和简明的规格，测试用例很难设计
9.沟通不到位会有问题
10.会有很多程序路径没有被测试到
11.不能直接针对特定的程序段，这些程序段可能非常复杂
2.3 灰盒测试
既利用被测对象的整体特性信息，又利用被测对象的内部具体实现信息，如:集成测试和系统测试时借助Log信息
2.4 静态测试和动态测试
静态测试：不运行被测试软件系统，而采用其他手段和技术进行检测的一种测试技术。例如：代码走读、文档评审、程序分析
动态测试：按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件系统进行检测的一种测试技术。常用技术有动态分析技术。
静态分析技术
定义：不通过执行程序而分析程序执行的技术
功能：检查软件的表示和描述是否一致，没有冲突或者没有歧义，它纠正软件系统在描述、表示和规格上的错误，因此是任何进一步测试执行的前提
三种不同的程序测试可能性：
考虑程序是否满足编码规则，语法上是否具有一致性和完整性
考虑文档描述是否规范、准确、便于查询
考虑程序和文档之间的一致性
静态分析技术结构
手工静态分析-同行评审
静态分析技术中的一个重要的手工技术是同行评审，根据形式正规程度分为：正规检视、技术评审和走查。
同行评审的对象：计划、需求文档、设计图、代码等
自动化静态分析
静态验证：检测规格到程序实现之间转换上的问题，验证器需要有形式化的规格和规格的形式化定义，静态验证比较程序提供的实际值和在规范文档中被预定义的目标值。
语法分析器：是一个基本的自动化静态分析工具，把程序、文档文本分解成独立的语句。当在内部检查程序、文档文本的时候，语句一致性被进行了检查。
符号执行器：在符号短语中分析一个程序在给定路径上做的事情，它模拟程序的执行，计算程序在不同位置上变量的事，适合于相数学算法的分析。
动态分析技术
定义：对软件系统运行行为进行分析，包含程序在受控的环境下使用特定的输入进行正式的运行，和期望的结果比较以检查系统运行是正确还是不正确。
常用的动态分析技术
路径测试
分支测试
性能测试
……
常用动态分析类型及功能
|
动态分析类型 |
功能 |
|
测试覆盖率分析 |
测试对代码的检测范围 |
|
跟踪 |
跟踪程序执行期间的所有路径，如变量的值 |
|
调整 |
度量程序执行过程中使用的资源 |
|
模拟 |
模拟系统的一部分，如无法获得的代码或硬件 |
|
断言检查 |
测试在复杂逻辑结构中是否某个条件已经被给出 |
人工测试和自动化测试
人工测试：测试活动由人来完成，狭义上是指测试执行由人工完成
自动化测试：指通过计算机模拟人的测试行为，替代人的测试活动，狭义上是指测试执行由计算机来完成
注：适用于重复多次、机械化的操作、大量的数据执行等。
适合自动化的活动
自动化测试执行
自动化测试检查
自动化测试的意义
对程序新版本前一版本执行的测试，提高回归测试效率
可以运行更多更频繁的测试，如冒烟测试
可以执行手工测试困难或不可能做的测试，如大量的重复操作或集成测试
更好地利用资源，如测试仪器或被测对象
自动化测试的限制
不能取代手工测试，只能提高测试效率，不能提高测试有效性（不能发现更多缺陷）
手工测试比自动化测试发现的缺陷更多
对测试设计依赖性极大，测试设计的不好会遗漏问题
自动化测试对软件开发具有很大的依赖性，开发上出现变更可能导致前面的自动化测试完会失效
工具本身并不具备想象力，工具不具有智能