备战软考第一篇章

前言

决定要参加明年的软考了，所以之后的一些文章大部分应该都算是我备战软考的笔记了。在软考的教程上做一下摘抄，加深印象。有想要详细了解的朋友可以直接去找软考的教程看一看。
然后还要说一下软考这个东西，如果允许的话，建议有时间有条件的朋友还是考一下比较好。这个考试如果你是有工作经验的其实还是比较好过的。据说通过率在25%左右。。。。。

基础篇

软件测试与软件质量

什么是软件测试

在工业制造和生产中，测试被当作一个常规的检验产品质量的生产活动。测试的含义为“以检验产品是否满足需求为目标”。而软件测试活动包含了很多重要的任务，即发现错误。
软件测试的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。
软件是由文档、数据以及程序组成的。那么软件测试就应该是对软件形成过程的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试。

什么是软件质量

1991年软件产品质量评价标准ISO 9126中定义的“软件质量”是：软件满足规定或潜在用户需求特性的总和。
一般对“质量”的理解是一个实体的“属性”，“属性”好就是质量好的。但是“属性”是内在特性，内在特性好，不一定能胜任和完成好用户的任务，因此，软件质量也是关于软件特性具备“能力”的体现。
2001年，软件“产品质量”国际标准ISO 9126定义的软件质量包括“内部质量”、“外部质量”、和“使用质量”三部分。也就是说，“软件满足规定或潜在用户需求的能力”要从软件在内部、外部和使用中的表现来衡量。

软件质量和软件测试的区别

质量保证（QA）：质量保证的重要工作通过预防、检查与改进来保证软件质量。QA采用“全面质量管理”和“过程改进”的原理开展质量保证工作。所关注的是软件质量的检查与测量。QA的工作是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求，因此主要着眼于软件的开发活动中的过程、步骤和产物，而不是对软件进行剖析找出问题或评估。
软件测试：测试关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试人员要“执行”软件，对过程的产物——开发文档和源代码进行走查，运行软件，以找出问题，报告质量。

软件测试的目的

测试的目的，是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。
此外，通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。同时，通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。
当然，通过最终的验收测试，也可以证明软件满足了用户的需求，树立人们使用软件的信心。

软件测试原则

1. 所有的软件测试都应追溯到用户需求（软件地目的是使用户完成预定地任务，并满足用户地需求，而软件测试所揭示地缺陷和错误使软件达不到用户地目标，满足不了用户需求）
2. 应尽早地和不断地进行软件测试（由于软件地复杂性和抽象性，在软件生命周期各个阶段都可能产生错误，所以不应把软件测试仅仅看作使软件开发的一个独立阶段的工作，而应当把它贯穿到软件开发的各个阶段中。）
3. 完全测试是不可能地，测试需要终止（想要进行完全的测试，在有限的时间和资源条件下，找出所有的软件缺陷和错误，使软件趋于完美，使不可能的）
4. 测试无法显示软件潜在地缺陷（进行测试是可以查找并报告发现的软件缺陷和错误，但不能保证软件的缺陷和错误全部找到，继续进一步测试可能还会找到一些，也就是说测试只能证明软件存在错误而不能证明软件没有错误）
5. 缺陷存在集群现象（经验表明，测试后程序中残存的错误数目与该程序中以及发现的错误数目或检错率成正比。根据这个规律，应当对错误集群的程序段进行重点测试，以提高测试投资的效益）
6. 避免程序员检查自己地程序（基于心里因素，人们认为揭露自己程序中的问题总不是一件愉快的事，不愿否认自己的工作；由于思维定势，人们难于发现自己的错误，因此，为达到测试目的，应由客观，公正，严格的独立部门进行测试）
7. 尽量避免测试地随意性（应该从工程的角度去理解软件测试，他是有组织，有计划，有步骤地活动）

软件测试对象

根据软件定义，软件包括程序，文档和数据。所以软件测试并不仅仅是程序测试。软件测试应贯穿于整个软件生命周期中。在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。需求分析，概要设计，详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明，概要设计规格说明，详细设计规格说明以及源程序，都应成为软件测试的对象。

软件测试分类

按照全生命周期的软件测试概念，测试对象应该包含软件设计开发的各个阶段的内容。

按照开发阶段分

按照开发阶段划分软件测试可以分为：单元测试，集成测试，系统测试，确认测试和验收测试。
1.单元测试
单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现设计说明中的模块功能、性能、接口和设计的约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
2.集成测试
集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序不见或整个系统。
集成测试的过程是一个持续的过程，会形成很多个临时版本，在不断的集成过程中，功能集成的稳定性是真正的挑战。在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。冒烟测试也叫版本验证测试、提交测试。
3.确认测试
确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试时检测与证实软件是否满足软件需求说明书中规定的要求。
4.系统测试
系统测试为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试时在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台）正确配置、连接，并满足用户需求。
5.验收测试
按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

按照测试实施组织划分

按照测试实施组织划分，软件测试可分为开发方测试、用户测试（β测试）、第三方测试。
1.开发方测试
通常也叫“验证测试”或“α测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下，有开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要求要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。
2.用户测试
在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况用户测试不是指用户的“验收测试”，而是指用户的使用性测试，有用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。
3.第三方测试
介于软件开发方和用户方之间的测试组织的测试。第三方测试也成为独立测试。软件质量工程强调开展独立验证和确认（IV&V）活动。IV&V是由在技术、管理和财务上与开发组织具有规定程度独立的组织执行验证和确认过程。软件第三方测试也就是由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。

按照测试技术划分

按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。静态测试是指不运行程序，通过人工对程序和文档进行分析与检查：静态测试技术又称为静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查，静态测试包括：走查、符号执行、需求确认等。动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。
1.白盒测试
通过对程序内部结构的分析，检测来寻找问题。白盒测试可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明书的规定正常进行。白盒测试又称结构测试。
2.黑盒测试
通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象堪称一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试实在程序界面处进行测试，他只是检查程序是否按照需求规格说明书的规定正常实现。
3.灰盒测试
介于白盒测试和黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细，完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。

软件测试过程模型

在软件开发几十年的实践过程中，人们总结了很多的开发模型。这些模型对于软件开发过程具有很好的指导作用。由此软件测试专家通过测试实践总结出了很多很好的测试模型。由于测试与开发的结合非常紧密，在这些测试模型中也都把开发过程进行了很好的总结，体现了测试与开发的融合。

V模型

V模型是最具有代表意义的测试模型，在传统的开发模型中，人们常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段。人们认为测试只是一个收尾工作，而不是主要的过程。V模型就是对此种认知的改进。V模型反映了测试活动与分析和设计的关系。从左到右描述了基本的开发过程和测试行为，明确地标明了测试过程中存在不同级别，清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

V模型指出，单元和集成测试是验证的程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行的软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。

W模型

V模型的局限性在于没有明确的说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型。相对于V模型，W模型更科学。W模型可以说是V模型自然而然地发展，他强调：测试伴随着整个软件开发周期，而且测试对象不仅仅是程序，需求、功能和设计同样要测试。这样，只要相应地开发活动完成，我们就可以开始执行测试，可以说测试与开发是同步进行地，有利于尽早地发现问题。

如果测试文档能尽早提交，那么就有了更多地检查和检阅地事件，这些文档还可用于评估开发文档。
W模型地局限性在于把软件地开发视为需求、设计、编码等一系列串行地活动。需要有严格地指令标识上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。

H模型

为了解决V模型和W模型地问题，有专家提出了H模型。他将测试活动完全独立出来，形成一个完全独立地流程，将测试准备活动和测试执行活动清晰地体现出来。

图示演示了证整个生产周期中莫格层次上地一次测试“微循环”。图中地其他流程可以是任意开发流程。例如，设计流程和编码流程。
概括地说，H模型揭示了：
软件测试不仅仅指测试地执行，还包括很多其他地活动。
软件测试是一个独立地流程，贯穿产品整个生命周期，与其他流程并发地进行。
软件测试要尽早准备，尽早执行
软件测试是根据被测物地不同而分层次进行地。不同层次地测试活动可以是按照某个次序先后进行地，也可能是反复地。

软件生命周期测试策略

软件开发与软件测试

软件开发过程是一个自上而下，逐步细化地过程。首先，在软件计划阶段定义了软件地作用域，然后进行软件需求分析，建立软件地数据域、功能和性能需求、约束及一些有效性准则。接着进入软件开发，进行软件设计，把设计用某种程序设计语言转换成程序代码。而测试过程则是依照相反地顺序安排自下向上，逐步集成地过程。低一级测试为上一级测试准备条件。当然不排除两者平行地进行测试。

首先，对每一个程序模块进行单元测试，消除程序模块内部逻辑上和功能上地错误和缺陷。在对照软件设计进行集成测试，检测和排除子系统结构上地错误。随后再对照需求，进行确认测试。最后从系统整体出发，运行系统，看是否满足要求。

软件测试策略

1.测试信息流
测试信息流的测试过程需要一下三类输入：

软件配置：包括软件需求规格说明书、软件设计规格说明、源代码等。
测试配置：包括测试计划、测试用例、测试驱动程序等。
测试工具：为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。
测试之后，要对所有测试结果进行分析，即将实测的结果与预期的结果进行比较。如果发现出错的数据，就意味着软件有错误，就需要开始排错。即对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关文档。修正后的文档一般都要经过再次测试，直到通过测试为止。
2.分析设计阶段
分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。
（1）.需求说明书评测
编制良好的需求说明书的8条原则：
原则一：功能与实现分离，即描述要“做什么”而不是“怎样实现”。
原则二：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，
原则三：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明书之中。描述该目标软件与其他系统元素交互方式
原则四：规格说明必须包括系统运行的环境
原则五：系统规格说明必须是一个认识的模型，而不是设计或实现的模型
原则六：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明
原则七：规格说明必须容许不完备性并允许扩充
原则八：规格说明必须局部化和松散的耦合。他所包含的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落。同时规格说明应被松散的构造。以便能够很容易的加入和删去一些段落。
需求说明书评测内容：
系统定义的目标是否与用户的要求一致
系统需求分析阶段提供的文档资料是否齐全
文档中的所有描述是否完整、清晰，准确的反应用户要求
与所有其他系统成分的重要接口是否都已经描述
被开发项目的数据流与数据结构是否都已经描述
所有图表是否清楚，再不补充说明是能否理解
主要功能是否已包括在规定的软件范围之内，是否都已充分说明
软件的行为和他必须处理的信息、必须完成的功能是否一致
设计的约束条件或限制条件是否符合实际
是否考虑了开发的技术风险
是否考虑过软件需求的其他方案
是否考虑过将来可能会提出的软件需求
是否详细制定了检验标准，他们能否对系统定义是否成功进行确认
有没有遗漏、重复或不一致的地方
用户是否审查了初步的用户手册或原型
项目开发计划中的估算是否受到了影响。
（2）概要设计说明书评测
概要设计说明书评测内容：
可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成分是否可追溯到某一项需求
接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否以及明确定义。模块是否满足高内聚和低耦合的要求
风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现
实用性：即确认该软件设计对于需求的解决方案是否实用
技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达
可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护
质量：即确认该软件设计是否表现出良好的质量特征
各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么
限制：评估对该软件的显示是否显示，是否与需求一致
其他具体问题：对于文档、可测试性、设计过程等进行评估

为了评测设计是否达到目标，建立了衡量设计的技术标准：
设计出来的结构应是分层结构，从而建立软件成分之间的控制
设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件
设计应当包含数据抽象，也包含过程抽象
设计应当建立具有独立功能特征的模块
设计应当建立能够降低模块与外部环境之间复杂连接的接口
设计应能根据软件需求分析获取的信息，建立可驱动，可重复的方法。
（3）详细设计说明书评测
清晰性：
所有单元或过程说的目的是否都已文档化
包括了数据流、控制流、和接口的单元设计是否已清晰地说明
完整性：
是否已定义和初始化所有地变量、指针和常量
是否已描述单元地全部功能
是否已详细说明用来实现该单元地关键算法
是否已列出该单元地调用
依从性：
该文档是否遵循了该项目已文档化地标准
是否采用了所要求地方法和工具来进行单元设计
一致性：
数据元素地命名和使用在整个单元和单元接口之间是否一致
所有接口地设计是否互相一致和更高级别文档一致
正确性：
是否处理所有条件
是否争取地规定了分支
数据使用：
是否所有声明地数据都被实际使用到
是否所有该单元地数据结构都被详细说明
是否所有修改共享数据或文件地程序都考虑到了其他程序对该共享数据或文件地存取权限
是否所有逻辑单元、事件标志和同步标志都被定义和初始化
接口：
接口参数在数量、类型和顺序上是否匹配
是否所有地输入和输出都被正确定义和检查
是否传递参数序列都被清晰地描述
是否所有参数和控制标志由已描述地单元传递或返回
是否详细说明了参数地度量单位、取值范围、正确度和精度
共享数据区域即其存取规定地映射是否一致
可维护性：
单元是否具有高内聚度和低耦合度
性能：
是否该单元地所有约束都被详细说明
可靠性：
初始化是否使用到缺省值，缺省值是否正确
是否在内存访问的时候执行了边界检查来确保只是改变了目标存储文职
是否执行输入、输出、接口和结果地错误检查
是否对所有错误情况都发出有意义地信息
对特殊情况返回地代码是否和已规定地全局定义地返回代码相匹配
是否考虑到意外事件
易测性：
是否能够对每个单元进行测试、演示、分析或检查来说明他们是满足需求地
该设计是否包含检查点来帮助测试
是否所有地逻辑都能被测试
是否已描述测试程序、测试数据集和测试结果
可追溯性：
是否设计地每一部分都能追溯到其他项目文档地需求、也能追溯到更高级别文档地需求
是否所有地设计决定都能追溯到权衡考虑
单元需求是否都能上溯到更高级别地文档，更搞级别地文档地需求是否以及在单元中体现
（4）软件编码规范评测
程序实际上也是一种工人阅读的文章，有一个文章风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。
源程序文档化：
符号名的命名。符号名就是标识符，包括模块名、变量名、标号名、子程序名、数据区名以及缓冲区名等。这些名字应能反映他所代表的 实际东西，应有一定的实际意义。如：表示次数的量用Times，表示总量的用Total等
程序的注释。夹在程序中的注释是程序员日后与程序读者之间通信的重要手段。注释不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。
标准得书写格式。视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算得优先性，减少编码得错误：自然得程序段之间可用空行隔开；移行也叫做向右缩格。是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中得程序段语句向右作阶梯式移行。使程序得逻辑结构更加清晰。
数据说明：
数据说明得次序应当规范化。数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明得次序与语法无关，其次序使任意得。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。
说明语句中变量安排有序化。当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。
使用注释说明复杂数据结构。如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。
语句结构：
在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。
输入和输出：
输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户到来的麻烦。因此，在软件需求分析阶段和设计阶段，就应当基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。
对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；
检查输入项的各种重要组合的合理性，必要时报告输入状态信息
是输入的步骤和操作尽可能简单，并保持简单的输入格式
输入数据时，应允许使用自由格式输入
应允许缺省值
输入一批数据时，最好使用输入结束标志，而不是由用户指定输入数据数目
在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。
当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性
给所有的输出加注解，并设计输出报表格式
3.开发阶段
（1）单元测试
单元测试又称模块测试，是针对软件设计最小的单位——程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块地I/O条件和模块地逻辑结构，主要采用白盒测试地测试用例，辅之以黑盒测试地测试用例，使之对任何合理地输入和不合理地输入，都能鉴别和相应，这要求对所有地局部地和全局地数据结构、外部接口和程序代码地关键部分，都要进行桌面检查和严格地代码审查。
模块接口测试
在单元测试地开始，应对通过所测模块地数据流进行测试，如果数据不能正确地输入和输出，就谈不上进行其他测试。未此，对模块接口可能需要如下地测试项目：调用所测模块时地输入参数与模块地形式参数在个数、属性、顺序上是否匹配；所测模块调用子模块时，他输入个子模块地参数与子模块中的形式参数在个数、属性、顺序上是否匹配。是否修改了只作输入用的形式参数：输出给标准函数的参数在个数、属性、顺序上是否正确，全局量的定义在各模块中是否一致，限制是否通过形式参数来传送。
局部数据结构测试
模块的局部数据结构时最常见的错误来源，应设计用例以检查一下各种错误：不争取或不一致的错误类型说明；使用尚未赋值成功或尚未初始化的变量；错误的初始值或错误的缺省值；变量名拼写错或书写错；不一致的数据类型
路径测试
由于通常不可能做到穷举测试，所以在单元测试期间要选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
常见的不正确计算有：运算的优先次序不正确或误解了运算的优先次序；运算的方式错，及运算的对象彼此在类型上不相容；算法错；初始化不正确；运算精度不够；表达式的符号表示不正确。
常见的比较和控制流错误有：不同数据类型的相互比较；不正确的逻辑运算符或优先次序；因浮点数运算精度问题而造成的两值比较不等；关系表达式中不正确的变量和比较符；当遇到发散的迭代时不能中止的循环；不适当的修改了循环变量等。
错误处理测试
比较完善的模块设计要求能遇见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。这种出错处理也应当是模块功能的一部分。
若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。
边界测试
在边界上出现错误时常见的。如：循环次数的错误，还有取最大值和最小值时也容易出错。因此需要特别注意等于、大于、小于这种判断。
此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。
（2）集成测试
集成测试也叫做组装测试或联合测试。通常在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
组装时需要考虑的问题：
在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
一个模块的功能是否会对另一个模块的功能产生不利的影响；
各个子功能组合起来，能否达到预期要求的父功能；
全局数据结构是否有问题；
单个模块的误差累积起来，是否会放大，以致达到不能接受的程度；
在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有一下几种特征之一：
满足某些软件需求
在程序的模块结构中位于较高的层次；
较复杂、较易发生错误；
有明确定义的性能要求
集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑到：
采用何种系统组装方法来进行集成测试；
集成测试过程中连接各个模块的顺序；
模块代码编制和测试进度是否与集成测试的顺序一致；
测试过程中是否需要专门的硬件设备；
集成测试完成的标志：
成功的执行了测试计划中规定的所有集成测试
修正了所发现的错误
测试结果通过了专门小组的评审
（3）确认测试
确认测试的任务时雁阵软件的功能和性能以及其他特性是否与用户要求的一致，对软件的功能和性能要求在软件需求规格说明书中明确规定。确认测试一般包括有效性测试和软件配置复查，确认测试一般由独立的第三方测试机构进行。
进行有效性测试
有效性测试是在模拟环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。为此，需要制定测试计划、测试步骤以及具体的测试用例。同时，对软件的可移植性，可靠性、易用性、兼容性、可维护性等需求也要进行测试，确认是否满足。
在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类。
1.测试结果与预取结果相符。说明软件的这部分功能或性能特征与需求规格说明书相符合，从而接受了这部分程序。
2.测试结果与预期结果不符。说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为他提交一份问题报告。
软件配置复查
软件配置复查的目的时保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。
在测试的过程中，还应当严格遵守用户手册和操作手册中规定的步骤，一边检查文档资料的完整性和正确性。
（4）系统测试
系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行环境下，对计算机系统进行一系列测试。
系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方
（5）验收测试
验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试。