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