对主要的测试类别都是按：
“测试对象和目的”、
”测试的组织和管理“、
”技术要求“、
”测试内容“、
”测试环境“、
”测试方法“、
”准入条件“、
”准出条件“、
”测试过程“、
”输出文档“
等条目做出要求。
软件测试过程一般包括四项活动：测试策划、测试设计、测试执行、测试总结。
（1）测试策划
主要是进行测试需求分析。
（2）测试设计
依据测试需求，分析并选用已有的测试用例或设计新的测试用例。
（3）测试执行
执行测试用例。
（4）测试总结
整理和分析测试数据。
与ISTQB的基本测试过程比较：
（1）计划于控制
（2）测试分析和设计
（3）测试实施和执行
（4）分析出口准则（测试退出条件）和报告
（1）静态测试方法
静态测试方法包括检查单和静态分析方法
（2）动态测试方法
动态测试方法一般采用白盒测试方法和黑盒测试方法
（1）具有测试合同（或项目计划）
（2）具有软件测试所需的各种文档
（3）所提交的被测软件受控
（4）软件源代码正确通过编译或汇编
（1）已按要求完成了合同（或项目计划）所规定的软件测试任务
（2）实际测试过程遵循了原定的软件测试计划和软件测试说明
（3）客观、详细地记录了软件测试过程和软件测试中发现的所有问题
（4）软件测试文档齐全、符合规范
（5）软件测试的全过程自始至终在控制下进行
（6）软件测试中的问题或异常有合理解释或正确有效的处理
（7）软件测试工作通过了测试评审
（8）全部测试软件、被测软件、测试支持软件和评审结果已纳入配置管理
在测试执行前，对测试计划和测试说明等进行评审。
评审的具体内容和要求应包括：
（1）评审测试文档内容的完整性、正确性和规范性
（2）通过比较测试环境与软件真实运行的软件、硬件环境的差异，评审测试环境要求是否正确合理，满足测试要求
（3）评审测试活动的独立性
（4）评审测试项选择的完整性和合理性
（5）评审测试用例的可行性、正确性和充分性
在测试完成后，评审测试过程和测试结果的有效性，确定是否达到测试目的。
主要对测试记录、测试报告进行评审。
具体内容和要求应包括：
（1）评审文档和记录内容的完整性、正确性和规范性
（2）评审测试活动的独立性和有效性
（3）评审测试环境是否符合测试要求
（4）评审测试记录、测试数据以及测试报告内容与实际测试过程和结果的一致性
（5）评审实际测试过程与测试计划和测试说明的一致性
（6）评审未测试项和新增测试项的合理性
（7）评审测试结果的真实性和正确性
（8）评审对测试过程中出现的异常进行处理的正确性
软件测试文档一般包括：
测试计划、
测试说明（需要时进一步细分为 测试设计说明、 测试用例说明 和 测试规程说明）、
测试项传递报告、
测试日志、
测试记录、
测试问题报告（也称测试事件报告）、
测试总结报告。
（1）对任何软件都存在有限的充分测试集合
（2）如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。
这一特定称为单调性。
（3）即使对软件所有成分都进行了充分的测试，也并不表明整个软件的测试已经充分了。
这一特性称为非复合性。
（4）即使对软件系统整体的测试是充分的，也并不意味软件系统中各个成分都已经充分地得到了测试。
这个特性称为非分解性。
（5）软件测试的充分性应该与软件的需求和软件的实现都相关。
（6）软件越复杂，需要的测试数据就越多。
这一特性称为复杂性。
（7）测试得越多，进一步测试所能得到的充分性增长就越少。
这一特性称为回报递减率。
单元测试
又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。
其目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求，发现单元内可能存在的各种差错。
测试对象
测试对象是可独立编译或汇编的程序模块（或称为软件构件或在面向对象设计中的类）
只测单元的内部行为，单元间接口不在此时测
在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试
测试组织和管理
软件单元测试的技术依据是软件设计文档（或详细设计文档）
技术要求
、
测试策略
单元测试需要从程序的内部结构出发设计测试用例，多采用白盒测试技术为主、黑盒为辅。
多个模块可以平行地独立进行单元测试。
驱动模块和桩模块
模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，应为测试模块开发一个驱动模块（driver）和若干个桩模块（stub）。
（1）驱动模块
用于模拟被测模块的上级模块，在大多数场合称为”主程序“
驱动模块接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，”主程序“显示”进入-退出“消息。
（2）桩模块
也称存根程序，用于模拟被测模块的调用模块。
（1）模块接口测试
应首先对通过被测模块的数据流进行测试。
只有在数据能正确流入、流出模块的前提下，其他测试才有意义。
（2）局部数据结构测试
检查局部数据结构是为了保证临时存储在模块中的数据在程序执行过程中完整、正确。
局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
a. 不正确或不一致的数据类型说明
b. 使用尚未赋值或尚未初始化的变量
c. 错误的初始值或错误的缺省量
d. 变量名拼写错误或书写错
e. 上溢、下溢（数组越界）或地址异常（非法指针）
（3）路径测试
在模块中应尽可能地对每一条独立执行路径进行测试，满足某覆盖标准。
（4）错误处理测试
一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：
a. 出错的描述是否难以理解
b. 在对错误进行处理之前，错误条件是否已经引起系统的干预
c. 所提供的差错描述信息不足以确定造成差错的位置或原因
d. 显示的错误与实际的错误是否相符
e. 对错误条件的处理正确与否
f. 意外的处理不当
g. 联机条件处理（即交互处理等）不正确
（5）边界测试
边界测试是单元测试中最后、也是最重要的一项任务。
软件经常在边界上失效，应采用边界值分析技术，注意数据流、控制流中边界出错的可能性。
如果对模块有性能要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块性能的因素。
（6）功能、性能、内存使用
a. 功能
应对软件设计文档规定的软件单元的功能逐项进行测试。
b. 性能
按软件设计文档的要求，对软件单元的性能（如精度、事件、容量等）进行测试。
c. 内存使用
检查内存的使用情况，特别是动态申请的内存在使用上的错误（如指针越界、内存泄漏等）。
软件单元测试完成后形成的文档一般应有：
软件单元测试计划
软件单元测试说明
软件单元测试报告
软件单元测试记录
软件单元测试问题报告
术语
集成测试
也称为组装测试、联合测试，是将模块按照设计要求组装起来进行测试，主要目标是发现于接口有关的问题。
部件测试
子系统的组装测试特别称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
测试对象
软件集成测试的对象包括：
（1）任意一个软件单元集成到计算机软件系统的组装过程
（2）任意一个组装得到的软件系统
测试的组织和管理
软件集成测试的技术依据是软件设计文档（软件结构设计文档）。
待集成的软件单元已通过单元测试。
技术要求
（未完）
（1）在模块组装后查找模块间接口的错误
（2）模块间数据交换是否丢失、有错（通讯、数据内容、时序等）
（3）各个子功能组合起来，能否达到预期要求的父功能
（4）全局数据结构是否有问题
（5）单个模块的误差累计，是否会放大，从而达到不能接收的程度
在单元测试的同时可进行组装测试，发现并派出在模块连接中可能出现的问题，最终构成要求的软件系统
通常，把模块组装成系统的方式有两种：一次性组装方式（big bang，大爆炸）、增殖性组装方式
是一种非增殖性式组装方式，也叫做整体拼装。
非增式测试方法采用一步到位的方法来构造测试：对所有模块进行个别的单元测试后，按程序结构图将各模块联接起来，把联接后的程序当作一个整体进行测试。
又称渐增式组装。
首先对一个个模块进行模块测试，然后将这些模块组装成较大的系统；在组装过程中边连接边测试，以发现连接过程中产生的问题。
增式测试把单元测试与集成测试结合起来进行，将模块逐步集成起来，逐步完成集成测试。
实施方法：
自顶向下结合
自底向上结合
混合式（三明治）
其他：基于调用图的集成测试（成对集成、邻居集成）、基于独立路径的集成
3.2.1 自顶向下增式方式
集成步骤
（1）主控模块作为测试驱动，所有与主控模块直接相连的模块用桩模块替换，并对主模块进行测试；
（2）根据集成的方式（深度或广度），每次用一个实际模块替换相应的桩模块；
（3）在每个模块被集成时，都必须已经进行了单元测试；
（4）进行回归测试以确定集成新模块后没有引入错误
上述过程从第2步重复进行，直到整个系统结构被集成完成。
3.2.2 自底向上增式测试
工作程序
（1）组装从最底层的模块开始，组合成一个构件，用以完成指定的软件子功能；
（2）编制驱动程序，协调测试用例的输入与输出；
（3）测试继承后的构件；
（4）按程序结构向上组装测试后的构件，同时去掉驱动程序
3.3.3 混合增殖式测试
（未完）
（1）成功地执行了测试计划中规定的所有集成测试；
（2）修正了所发现的错误；
（3）测试结果通过了专门小组的评审。
软件集成测试完成后形成的文档一般应有：
软件集成测试计划
软件集成测试说明
软件集成测试报告
软件集成测试记录和/或测试日志
软件集成测试问题报告
确认测试也称为软件合格性测试、配置项测试
确认测试
确认测试的任务是验证软件的功能和性能及其特性是否与用户的要求一致。
对软件的功能和性能要求在软件需求规格说明中已经明确规定，它是软件确认测试的基础。
测试对象
软件配置项。
软件配置项是为独立的配置管理而设计的并且能满足最终用户功能的一组软件。
确认测试包括有效性测试和软件配置审查。
技术要求
（未完）
检验软件配置项与软件需求规格说明的一致性。
GB/T15532-2008中，系统测试内容主要依据GB/T 16260.1规定的质量特性来进行，有别于传统的测试内容，测试内容主要从：
功能性（适合性、准确性、互操作性、安全保密性）
可靠性（成熟性、容错性、易恢复性）
易用性（易理解性、易学性、易操作性、吸引性）
效率（时间特性、资源利用性）
维护性（易分析性、易改变性、稳定性、易测试性）
可移植性（适应性、易安装性、共存性、易替换性）
依从性
等方面来考虑。
任务
验证被测软件是否满足需求规格说明书列出的需求。
测试内容
大体可归为界面、数据、操作、逻辑、接口等几方面。
使用技术
是在模拟的环境（可能就是开发的环境）下，运用黑盒测试技术。
软件配置复查的目的
保证：
（1）软件配置的所有成分都齐全
（2）格方面的质量都符合要求
（3）具有维护阶段要必需的细节
（4）已经编排好分类的目录
软件配置复查的主要内容是文件资料。
文件资料
用户所需资料（用户手册、操作手册）
设计开发资料（各阶段产品：需求规格说明书、设计说明书）
源程序及测试资料（测试说明书、测试报告）
确认测试完成后形成的文档：
软件配置项测试计划
软件配置项测试说明
软件配置项测试报告
软件配置项测试记录和/或测试日志
软件配置项问题报告
系统测试
系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的测试。
进行系统测试的原因
在投入运行前完成系统测试，是为了保证各组成部分不仅能单独的得到检验，而且在系统各部分协调工作的环境下也能正常工作。
测试对象
系统测试的对象是完整的、集成的计算机系统，重点是新开发的软件配置项的集合。
测试目的
通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。
系统测试的测试用例应根据需求分析规格说明来设计，并在实际使用环境下来运行。
GB/T15532-2008中，系统测试内容主要依据GB/T 16260.1规定的质量特性来进行，有别于传统的测试内容，测试内容主要从：
功能性（适合性、准确性、互操作性、安全保密性）
可靠性（成熟性、容错性、易恢复性）
易用性（易理解性、易学性、易操作性、吸引性）
效率（时间特性、资源利用性）
维护性（易分析性、易改变性、稳定性、易测试性）
可移植性（适应性、易安装性、共存性、易替换性）
依从性
等方面来考虑。
系统测试完成后形成的文档一般应有：
系统测试计划
系统测试说明
系统测试报告
系统测试记录和/或测试日志
系统测试问题报告
验收测试
也称为交付测试，检查软件能否按合同要求进行工作，即是否满足软件合同中的确认标准。
测试对象
完整的、集成的计算机系统
测试目的
在真实的用户（或称系统）工作环境下检验完整的软件系统，是否满足软件开发技术合同（或软件需求规格说明）规定的要求。
其结论是软件的需方确定是否接收该软件的主要依据。
测试的组织和管理
验收测试应由软件的需方组织，由独立于软件开发的人员实施。
软件验收测试的技术依据是软件研制合同（或用户需求或系统需求）
技术要求、测试内容
同系统测试。
组织机构
测试地点
覆盖范围
实施人员
在通过系统测试后
商业现货软件可在安装或集成时进行
组件的可用性验收测试可在组件测试时进行
验收测试范围广，取决于被测程序。
验收测试完成后的文档一般有：
验收测试计划
验收测试说明
验收测试报告
验收测试记录
验收测试问题报告
回归测试可出现在上述每个测试类别中，并贯穿于整个软件生存周期。
回归测试
在集成测试策略的环境中，回顾测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用或引发新的问题。
在更广的环境里，回归测试就是用来保证（由于测试或其他原因的）改动不会带来不可预料的行为或另外的错误。
测试对象
回归测试的对象包括：
（1）未通过单元测试的软件，在变更之后，应对其进行单元测试；
（2）未通过配置项测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试和配置项测试；
（3）未通过系统测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试、软件配置项测试和系统测试；
（4）因其他原因进行变更后的软件单元，也首先应对变更的软件单元进行测试，然后再进行相关的软件测试。
测试目的
（1）测试软件变更之后，变更部分的正确性和对变更需求的符合性；
（2）测试软件变更之后，软件原存的、正确的功能、性能和其他规定的要求的不损害性。
（未完）
