《软件评测师教程笔记之第2章软件测试基础.doc》由会员分享，可在线阅读，更多相关《软件评测师教程笔记之第2章软件测试基础.doc（25页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第2章软件测试基础1、什么是软件测试测试（test）被当作一个常规的检验产品质量的生产活动。测试的含义为“为检验产品是否满足需求为目标”。“软件测试”的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。软件是由文档、数据以及程序组成的，那么软件测试就应该是对软件形成过程的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试。2、什么是软件质量ISO9126中定义的“软件质量”是：软件满足规定或潜在用户需求特性的总与。ISO14598中“软件质量”定义是：软件特性的总与，软件满足规定或潜在用户需求的能力。ISO9126定义的软件质量包括“内部质量”、“外部质量”、“使用质
2、量”三部分。也就是说，“软件满足规定或潜在用户需求的能力”要从软件在内部、外部与使用中的表现来衡量。3、软件测试是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。4、软件质量定义是：软件特性的总与，软件满足规定或潜在用户需求的能力。软件质量包括：内部质量、外部质量、使用质量三个部分。5、软件测试及质量保证的区别：质量保证（QA）质量保证的重要工作通过预防、检查及改进来保证软件质量。QA采用“全面质量管理”与“过程改进”的原理开展质量保证工作。关注软件质量的检查及测量。软件测试也及软件开发过程紧密相关，关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试员要“执行”软
3、件，对过程中的产物开发文档与源代码进行走查，运行软件，以找出问题，报告质量。对测试中发现的问题的分析、追踪与回归测试。软件测试是保证软件质量的一个重要环节。6、软件测试目的测试目的三个观点：测试是程序的执行过程，目的在于发现错误；一个好的测试用例在于能发现至今未发现的错误；一个成功的测试是发现了至今未发现的错误的测试；测试的目的，是想以最少的人力、物力与时间找出软件潜在的各种错误与缺陷，通过修正各种错误与缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷与错误造居的隐患所带来的商业风险。测试是对软件质量的度量及评价，以验证软件的质量满足用户的需求的程度，为用户选择及接受软件提供有力的依据。7、
4、软件测试原则所有的软件测试都应追溯到用户需求。应当把“尽早地与不断地进行软件测试”作为软件测试者的座左铭。完全测试是不可能的，测试需要终止。 在有限的时间与资源条件下，软件趋于完美，是不可能的。主要有三个原因： 软件入量太大； 输出结果太多； 路径组合太多。测试无法显示软件潜在的缺陷充分注意测试中的群集现象。程序员应避免检查自己的程序。尽量避免测试的随意性。（应该从工程的角度去理解软件测试，它是有组织、有计划、步骤的活动。）8、软件测试对象根据软件定义，软件包括程序、数据与文档，所以软件测试并不仅仅是程序测试。在软件编码结束后，对编写的每一个程序模块进行测试，称为模块测试或单元测试。在模块集成
5、后，对集成在一起模块组件，有时称为部件，进行测试，称为集成测试。在集成测试后，需要检测及证实软件是否满足软件需求说明书中规定的要求，称为确认测试。将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为系统测试。软件错误中，属于需求分析与软件设计的错误约为64%，属于程序编写的错误仅占36%。验证（verification）是保证软件正确实现特定功能的一系列活动与过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。确认（validation）是保证软件满足用户需求的一系列的活动与过程，目的是在软件开发完成后保证软件及用
6、户需求相符合。验证及确认都属于软件测试，它包括对软件分析、设计以及程序的验证与确认。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；在集成测试后，需要检测及证实软件是否满足软件需求说明书中规定的要求，称为“确认测试”。将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称
7、为“系统测试”。测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试与系统测试。9、软件测试分类按照开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试与验收测试。单元测试：单元测试又称模块测试，是针对软件设计的最小单位程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口与设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。集成测试：也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部
8、件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。确认测试：就是通过检验与提供客观证据，证实软件是否满足特定预期用途的要求。确认测试是检测及证实软件是否满足软件需求说明书中规定的要求。系统测试：它是为验证与确认系统是否达到其原始目标，而对集成的硬件与软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否（包括硬件、外设、网络与系统软件、支持平台等）正确配置、连接，并满足用户需求。验收测试：按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试及评审，决定是否接收或拒收系统。l 按照开发阶段划分 单元测试。单元测试又称模块测试，是针对程序模
9、块进行正确性检验的测试工作。 集成测试集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。冒烟测试也叫验证测试、提交测试。 确认测试确认测试是通过检验与提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测及证实软件是否满足软件需求说明书中规定的要求。 系统测试系统测试是为验证与确认系统是否达到其原始目标，而对集成的硬件与软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否与系统（包括硬件、外设、网络与系统软件、支持平台等）正确配置、连接
10、、并满足用户需求。 验收测试按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试及评审，决定是否接收或拒收系统。l 按照测试实施组织划分按照测试实施组织划分，软件测试可分为开发方测试、用户测试（Beta测试）、第三方测试。（1）开发方测试通常也叫“验证测试”或“测试”。验证测试是在软件开发环境下，由开发者检测及证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查及验证，可以与软件的“系统测试”一并进行。（2）用户测试在用户的应用环境下，用户通过运行与使用软件，检测及核实软件实现是否符合自己预期的要求。用户测
11、试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷及问题，并对使用质量进行评价。（3）第三方测试介于软件开发方与用户方之间的测试组织的测试。一般情况下是在模拟用户真实应用环境下，进行软件确认测试。l 按照测试技术划分按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试与动态测试。静态测试是指不运行程序，通过人工对程序与文档进行分析及检查：静态测试技术又称静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查，静态测试包括：走查、符号执行、需求确认等。动态测试是指通过人工或使用工具运行程序进行检查、分
12、析程序的执行状态与程序的外部表现。 （1）白盒测试通过对程序内部结构的分析、检测来寻找问题。了解程序结构与处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。（2）黑盒测试通过软件的外部表现来发现其缺陷与错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构与处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。（3）灰盒测试灰盒测试关注输出对于输入的正确性 静态测试它是指不运行程序，通过人工对程序与文档进行分析及检查； 静态测试技术又称静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程
13、序源代码等进行非运行检查，静态测试包括：走查、符号执行、需求确认等。 动态测试它是指通过人工或使用工具运行程序进行检查、分析程序的执行状态与程序的外部表现。 白盒测试又称结构测试。通过对程序内部结构的分析、检测来寻找问题。 黑盒测试通过软件的外部表现来发现其缺陷与错误。它是在程序界面处进行测试，它只是检查样序是否按照需求规格说明书的规定正常实现。10、软件测试过程模型 V模型它反映了测试活动及分析与设计的关系，从左到右，描述了基本的开发过程与测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段与开发过程期间各阶段的对应关系，如图所示，图中的箭头代表了时间方向，左边下
14、降的是开发过程各阶段，及此相对应的是右边上升的部分，即各测试过程的各个阶段。V模型指出，单元与集成测试是验证的程序设计，检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标； 测试员与用户进行软件的确认测试与验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。V模型存在一定的局限性，它仅仅是测试过程作为在需求分析、概要设计、详细设计及编码后的一个阶段。需求分析阶段隐藏的问题一直到后期的验收测试才被发现。V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试为了使整个
15、系统满足用户的需求。 W模型1、W模型建立V模型的局限性在于没有明确地说明早期的测试，不能表达“尽早地与不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是及此相并行的“V”。基于“尽早地与不断地进行软件测试”的原则，优点：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能与设计同样要测试。表达“尽早地与不断地进行软件测试”的原则。在V模型中增加软件与开发阶段应同步进行的测试。局限性：软件开发与测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这就无法支持迭代、自发
16、性以及变更调整。2、W模型应用它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能与设计同样要测试。只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试及开发是同步进行的，有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。参及前期工作的测试者可以预先估计问题与难度，这将可以显著地减少总体测试时间，加快项目进度。根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例。W模型也是有局限性。W模型与V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的，软件开发与测试保持一种
17、线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。 H模型1、H模型建立它将测试活动独立出来，形成一个完全独立的流程，将测试准备活动与测试执行活动清晰地表达出来。2、H模型应用软件测试不仅仅指测试的执行，还包括很多其他的活动。软件测试是一个独立的流程，贯穿产品整个生命周期，及其他流程并发地进行。软件测试要尽早准备，尽早执行。软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，及其他流程并发地进行。 其他模型1、
18、 X模型该模型定位了探索性测试。Marick对V模型最主要批评是V模型无法引导项目全部过程。他认为一个模型必须能处理开发的所有方面，包括交接、频繁重复的集成以及需求文档的缺乏等。2、前置测试模型它是一个将测试与开发紧密结合的模型，该模型提供了轻松的方式，可使你的项目加快速度。前置测试模型表达了以下的要点：（1）开发与测试相结合；前置测试模型将开发与测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。（2）对每一个交付内容进行测试；每一个交付的开发结果都必须通过一定的方式进行测试。（3）在设计阶段进行测试计划与测试设计；设计阶段是作测试计划与测试设计的最好时机。（4）测试与开
19、发结合在一起；前置测试将测试执行与开发结合在一起，并在开发阶段以编码测试编码测试的方式来表达。（5）让验收测试与技术测试保持相互独立。验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。10、软件生命周期测试策略 软件开发及软件测试软件开发的过程是一个自顶向下，逐步细化的过程。测试过程则是依照相反的顺序安排自底向上，逐步集成的过程。 软件测试策略测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试与系统测试。1、测试信息流测试过程需要以下三类输入：软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。测试配置：包括测试计划、测试用例、
20、测试驱动程序等。测试配置只是软件配置的一个子集。测试工具：2、分析设计阶段分析设计阶段的测试工作是评审及测试相结合的过程，主要包括需求说明书评测、概要设计说明书、详细设计说明书评测以及软件编码规范评测等。编制良好的需求说明书8条原则：功能及实现分离；要求使用面向处理的规格说明语言；描述该目标软件及系统的其他系统元素交互的方式；规格说明必须包括系统运行的环境；系统规格说明必须是一个认识的模型；规格说明必须是可操作的；规格说明必须容许不完备性并允许扩充；规格说明必须局部化与松散的耦合。（1）需求说明书评测 需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能与行为描述、性能需求与设计
21、约束的说明、性能需求与设计约束的说明、合适的验收标准，给出对目标软件的各种需求。需求说明书评测内容：系统定义的目标是否及用户的要求一致。系统需求分析阶段提供的文档资料是否齐全。文档中的所有描述是否完整、清晰、准确地反映用户要求； 及所有其他系统成份的重要接口是否都已经描述； 被开发项目的数据流及数据结构是否足够、确定； 所有图表是否清楚，在不补充说明时能否理解；主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 软件的行为与它必须处理的信息、必须完成的功能是否一致； 设计的约束条件或限制条件是否符合实际； 是否考虑了开发的技术风险； 是否考虑过软件需求的其他方案； 是否考虑过将来可能会
22、提出的软件需求； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认； 有没有遗漏、重复或不一致的地方； 用户是否审查了初步的用户手册或原型； 项目开发计划中的估算是否受到了影响。（1）需求说明书评测编制良好的需求说明书8条原则。原则1：功能及实现分离，即描述要“做什么”而不是“怎样实现”。原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。原则3：如果目标软件只是一个大系统中的一个元素，那么整个系统也包括在规格说明的描述之中。原则4：规格说明必须包括系统运行的环境。原则5：系统规格说明必须
23、是一个认识的模型，而不是设计或实现的模型。原则6：规格说明必须是可操作的。原则7：规格说明必须容许不完备性并允许扩充。原则8：规格说明必须局部化与松散的耦合。需求说明书的框架。需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能与行为描述、性能需求与设计约束的说明、合适的验收标准，给出对目标软件的各种需求。需求说明书评测内容。需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性与清晰性，以及其他需求给予评测。评测的主要内容是：（1）系统定义的目标是否及用户的要求一致；（2）系统需求分析阶段提供的文档资料是否齐全；（3）文档中的所有描述是否完整、清晰，准确地反映
24、用户要求；（4）及所有其他系统成份的重要接口是否都已经描述；（5）被开发项目的数据流及数据结构是否足够、确定；（6）所有图表是否清楚，在不补充说明时能否理解；（7）主要功能是否已包括在规定的软件范围之内，是否都已充分说明；（8）软件的行为与它必须处理的信息、必须完成的功能是否一致；（9）设计的约束条件或限制条件是否符合实际；（10）是否考虑了开发的技术风险；（11）是否考虑过软件需求的其他方案；（12）是否考虑过将来可能会提出的软件需求；（13）是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；（14）有没有遗漏、重复或不一致的地方；（15）用户是否审查了初步的用户手册或原型；（16
25、）项目开发计划中的估算是否受到了影响。（2）概要设计说明书评测设计说明书的框架 设计说明书的框架内容： （1）可追溯性（2）接口（3）风险（4）实用性（5）技术清晰度（6）可维护性（7）质量（8）各种选择方案（9）限制（10）其他具体问题为评测设计是否达到目标，必须建立衡量设计的技术标准。如下：主要评测内容：可追溯性；接口；风险；实用性；技术清晰度；可维护性；质量；各种选择方案；限制；其他具体问题。（1）设计出来的结构应是分层结构，从而建立软件成分之间的控制；（2）设计出来的结构应是分层结构，从而建立软件成分之间的控制；（3）设计应当既包含数据抽象，也包含过程抽象；（4）设计应当建立具有独立功
26、能特征的模块；（5）设计应当建立能够降低模块及外部环境之间复杂连接的接口；（6）设计应当根据软件需求分析获取的信息，建立可驱动、可重复的方法。（3）详细设计说明书评测及概要设计说明书基本相同。（4）软件编码规范评测程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构的输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。源程序文档化（1）符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。（2）程序的注释。注释分为序言性注释与功能性注释。（3）标准的书写格式。数据说明（1）
27、数据说明的次序应当规范化。（2）说明语句中变量安排有序化。（3）使用注释说明复杂数据结构。语句结构在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。输入与输出输入与输出信息是及用户的使用直接相关的。输入与输出的方式与格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段与设计阶段，就应基本确定输入与输出的风格。系统能否被用户接受，有时就取决于输入与输出的风格。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计与程序编码时都应考虑下列原则。输入与输出在设计与程序编码时
28、都应考虑下列原则。（1）对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；（2）检查输入项的各种重要组合的合理性，必要时报告输入状态信息；（3）使输入的步骤与操作尽可能简单，并保持简单的输入格式；（4）输入数据时，应允许使用自由格式输入；（5）应允许缺省值；（6）输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；（7）在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类与取值范围。同时，在数据输入的过程中与输入结束时，也要在屏幕上给出状态信息；（8）当程序设计语言对输入/输出格有严格要求时，应保持输入格式及输入语句要求的一致
29、性；（9）给所有的输出加注解，并设计输出报表格式。3、开发阶段（1）单元测试单元测试的内容：在进行单元测试时，测试者需要依据详细设计说明书与源程序清单，了解该模块的I/O条件与模块的逻辑结构，主要采用白盒测试的测试用例，辅之黑盒测试的测试用例。使之对任何合理的输入与不合理的输入，都能鉴别与响应。这要求对所有的局部的与全局的数据结构、外部接口与程序代码的关键部分，都要进行桌面检查与严格的代码审查。在单元测试中进行的测试工作如图2-9所示，需要在五个方面对所测模块进行检查。在进行单元测试时，测试者需要依据详细设计说明书与源程序清单，了解该模块的I/O条件与模块的逻辑结构，主要采用白盒测试的测试用例
30、，辅之以黑盒测试的测试用例，使之对任何合理的输入与不合理的输入，都能鉴别与响应。这要求对所有的局部的与全局的数据结构、外部接口与程序代码的关键部分，都要进行桌面检查与严格的代码审查。1）模块接口测试在单元测试的开始，应对通过所测模块的数据流进行测试。如果数据不能正确地输入与输出，就谈不上进行其他测试。为此，对模块接口可能需要如下的测试项目： 调用所测模块时的输入参数及模块的形式参数在个数、属性、顺序上是否匹配； 所测模块调用子模块时，它输入给子模块的参数及子模块中的形式参数在个数、属性、顺序上是否匹配；是否修改了只作输入用的形式参数；输出给标准函数的参数在个数、属性、顺序上是否正确；全局量的定
31、义在各模块中是否一致；限制是否通过形式参数来传送。2）局部数据结构测试设计测试用例以检查以下各种错误：不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量；错误的初始值或错误的缺省值；变量名拼写错或书写错；不一致的数据类型。3）路径测试常见的不正确计算有：运算的优先次序不正确或误解了运算的优先次序； 运算的方式错，即运算的对象彼此在类型上不相容； 算法错； 初始化不正确； 运算精度不够； 表达式的符号表示不正确。4）错误处理测试比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。模块与错误处理功能包含有错误或缺
32、陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误及实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。5）边界测试单元测试步骤：驱动模块（driver）相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后输出实测结果。桩模块（stub）也叫存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。（2）集成测试集成测试也叫做组装测试或联合测试。在单元测试的基础上，需要将所有模块按照概要设计说明书与详细设计说明书的要求进行组装。组成时需要
33、考虑的问题：1）在把各个模块连接起的时候，穿越模块接口的数据是否会丢失； 2）一个模块的功能是否会对另一个模块的功能产生不利的影响；3）各个子功能组合起来，能否达到预期要求的父功能；4）全局数据结构是否有问题； 5）单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统及系统需求规格说明之间的不一致。模块组装成为系统的方式。模块组装成为系统的方式有两种：一次性组装方式与增殖式组装方式。1）一次性组装方式它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终
34、得到要求的软件系统。2）增殖式组装方式这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。自顶向下的增殖方式。步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，及已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引新的错误的可能。最后，判断是否
35、所有的模块都已组装到系统中。自顶向下的增殖方式在测试过程中较早地验证了主要的控制与判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果选用按深度方向组装的方式，可以首先实现与验证一个完整的软件功能，可先对逻辑输入的分支进行组装与测试，检查与克服潜藏的错误与缺陷，验证其功能的正确性，就为其后对主要加工分支的组装与测试提供了保证。自底向上的增殖方式。提高测试效率。 进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：满足某些软件需求；在程序的模块结构中位于较高的层次（高层控制模块）；较复杂、较
36、易发生错误；有明确定义的性能要求。在做回归测试时，也应该集中测试关键模块的功能。集成测试的组织与实施。集成测试是一种正规测试过程，必须精心计划，并及单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：（1）采用何种系统组装方法来进行集成测试。（2）集成测试过程中连接各个模块的顺序。（3）模块代码编制与测试进度是否及集成测试的顺序一致。（4）测试过程中是否需要专门的硬件设备。集成测试完成的标志。集成测试完成的标志主要有以下几项。（1）成功地执行了测试计划中规定的所有集成测试。（2）修正了所发现的错误。（3）测试结果通过了专门小组的评审。集成测试需要提交的文档有集成测试计划、集成测试规格
37、说明书与集成测试分析报告。（3）确认测试确认测试的任务是验证软件的功能与性能及其他特性是否及用户的要求一致。对软件的功能与性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试与软件配置复查，确认测试一般由独立的第三方测试机构进行。进行有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的要求。在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类。（1）测试结果及预期的结果相符。这说明软件的部分功能或性能特征及需求规格说明书相符合，从而接受了这部分程序。（2）测试结果及预期的结果不符。这说明软件的这部分功能或性能特征及需求规格说明
38、不一致，因此要为它提交一份问题报告。软件配置复查。（4）系统测试系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，及计算机硬件、外设、某些支持软件、数据与人员等其他系统元素结合在一起，在实际或模拟运行（使用）环境下，对计算机系统进行一系统列测试。（5）验收测试4、软件验证及确认（V&V）过程软件的V&V过程是确定按照规定的软件过程开发的产品是否符合活动的要求，软件是否满足它的预期用途与用户需要。软件的V&V过程包括软件产品与过程的分析、评价、评审、审核、评估与测试。软件测试活动是软件V&V过程的一个组成部分。软件测试过程的任务及管理也要符合软件V&V过程的有关规定。（1）V&V
39、基本概念验证（Verfication）：通过检查与提供客观证据，证实规定的需求已满足。确认（Validation）：通过检查与提供客观证据，证实预期用途的需求是否得到满足。独立验证与确认：由在技术、管理与财务上及开发组织有规定程度独立性的组织执行的V&V过程。（2）软件V&V过程软件生存周期的V&V过程框架。软件开发过程的V&V概述。（3）软件V&V过程中的测试测试过程。需求V&V活动中的测试。2.8软件失效分类及管理2.8.1软件失效分类软件错误（software error）软件缺陷（software defect）软件故障（software fault）软件失效（software fai
40、lure）软件失效机理可描述为：软件错误软件缺陷软件故障软件失效（1）软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。（2）软件缺陷存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷激动。（3）软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。（4）软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。错误的广义定义是：不正确的事务与行为。错误是在系统运行时，引起或可能潜在地引起失效的缺陷，是一种面向
41、开发概念。软件缺陷：（1）软件未达到产品说明书中标明的功能； （2）软件出现了产品说明书中指明的不会出现的错误；（3）软件功能超出了产品说明书指明的范围；（4）软件未达到产品说明书虽未指出应达到的目标；（5）软件测试人员认为软件难以理解、不易使用、运行速度慢，或最终用户认为不好使用。产品说明书是软件缺陷的第一来源，也就出自于软件需求说明书本身的问题。设计方案（软件设计说明书）是软件缺陷第二来源。2.8.2缺陷及错误分布2.8.3缺陷及错误严重性与优先级软件存在的缺陷及错误会带来软件失败的风险，重要软件故障及失效会导致重大经济损失及灾难。给软件缺陷及错误划分严重性与优先级的通用原则是：（1）表示
42、软件缺陷所造成的危害的恶劣程度； （2）优先级表示修复缺陷的重要程度与次序；严重级：严重：系统崩溃、数据丢失、数据毁坏较严重：操作性错误、错误结果、遗漏功能一般：小问题、错别字、UI布局、罕见故障建议：不影响使用的瑕疵或更好的实现优先级：最高优先级：立即修复，停止进一步测试次高优先级：在产品发布之前必须修复中等优先级：如果时间允许应该修复最低等优先级：可能会修复，但是也能发布2.8.4软件错误跟踪管理软件测试的主要目的在于发现软件存在的错误（Bug），如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实
43、际的软件测试过程中，每个BUG都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。作为一个错误跟踪管理系统，需要正确记录错误信息与错误处理信息的全部内容。（1）BUG记录信息主要包括以下几项内容。测试软件名称测试版本号测试人名称测试事件测试软件与硬件配置环境发现软件错误的类型错误的严重等级详细步骤必要的附图测试注释（2）BUG处理信息处理者姓名处理时间处理步骤错误记录的当前状态2、软件错误的状态新信息（New）：测试中新报告的软件BUG打开（Open）：被确认并分配给相关开发人员处理。修正（Fixed）：开发人员已完成修正，等待测试人员验证。拒绝（Declined）拒绝修改BU
44、G延期（Deferred）：不在当前版本修复的错误，下一步修复。关闭（Closed）：BUG已被修复。3、错误管理流程4、错误流程管理原则2.9白盒测试2.10黑盒测试黑盒测试也称为功能测试，它是通过测试来检测每个功能是否都能正常使用。在完全不考虑内部结构与内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。主要针对软件界面与软件功能进行测试。黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。功能不正确或遗漏界面错误数据库访问错误性能错误初始化与终止错误黑盒测试用例设计方法包括等价类划分法、边界值
45、分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。2.11自动化测试2.11.1自动化测试的基本概念自动化测试的定义：通过测试工具或其他手段，按照测试工程师的预定计划对软件产品进行自动的测试，它是软件测试的一个重要的组成部分，它能够完成许多手工无法完成或难以实现的一些测试。正确、合理地实施自动化测试，能够快速、全在财对软件进行测试，从而提高软件质量，节省经费，缩短产品发布周期。2.11.2自动化测试的优势及局限1、自动化测试的优势避免重复测试，同时，还能完成大量手工无法完成的测试工作，如并发用户测试、大数据量测试、长时间运行可靠性测试等，优点：提高测试质量提高测试效率，缩
46、短测试工作时间提高测试覆盖率执行手工测试不能完成的测试任务更好地重现软件缺陷的能力更好地利用资源增进测试人员及开发人员之间的合作伙伴关系以下项目与环境中更适合使用自动化测试工具：需要反复进行的工作负载压力测试测试人员与开发人员有效合作借助测试管理工具，会取得事半功倍的效果。若需要进行测试系统后台或者内部的性能特性，进而进行故障定位与性能调优。2、自动化测试的局限性定制型项目周期很短的项目业务规则复杂的对象人体感观及易用性测试不稳定的软件涉及物理交互2.11.3选择合适的自动化测试工具1、自动化测试工具分类自动化测试工具分以下几类：负载压力测试工具功能测试工具白盒测试工具网络测试工具测试管理工具测试辅助工具2、自动化测试应用策略在测试过程中应用测试工具主要有以下几个目的：提高测试质量；减少测试过程中的重复劳动； 实现测试自动化，解决手工测试不能解