第一篇 理论篇
第1章软件测试概论
1.1概述
早期的测试等同于“调试”。
测试是为发现错误而执行的一个程序或者系统的过程。
测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。
1.3软件测试与软件项目的关系
软件测试的目的是为了发现软件中存在的错误，但是，其根本目的是为了提高软件质量，降低软件项目的风险。软件的质量风险表现在两个方面，一种是内部风险，一种是外部风险。内部风险是在即将销售的时候发现有重大的错误，从而延迟发布日期，失去市场机会；外部风险是用户发现了不能容忍的错误，引起索赔，法律纠纷，以及用于客户支持的费用甚至失去客户的风险。
软件测试只能证明软件存在错误，而不能证明软件没有错误。软件公司对软件项目的期望是在预计的时间、合理的预算下，提交一个可以交付的产品，测试的目的就是把软件的错误控制在一个可以进行产品交付/发布的程度上，可以交付/发布的产品并不是没有错误的产品，因此软件测试不可能无休止地进行下去，而是要把错误控制在一个合理的范围之内，因为软件测试也是需要花费巨大成本的。
1.5第三方测试
第三方测试是指独立于软件公司自身测试的测试。第三方测试机构的测试除了发现软件问题之外，还有对软件进行科学、公正的评价的职能，这就要求第三方测试机构要保持公正、廉洁、客观、科学、独立的态度。
第2章软件测试基础
1、什么是软件测试
测试（test）被当作一个常规的检验产品质量的生产活动。测试的含义为“为检验产品是否满足需求为目标”。
“软件测试”的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。
软件是由文档、数据以及程序组成的，那么软件测试就应该是对软件形成过程的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试。
2、什么是软件质量
ISO9126中定义的“软件质量”是：软件满足规定或潜在用户需求特性的总和。
ISO14598中“软件质量”定义是：软件特性的总和，软件满足规定或潜在用户需求的能力。
ISO9126定义的软件质量包括“内部质量”、“外部质量”、“使用质量”三部分。也就是说，“软件满足规定或潜在用户需求的能力”要从软件在内部、外部和使用中的表现来衡量。
3、软件测试是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。
4、软件质量定义是：软件特性的总和，软件满足规定或潜在用户需求的能力。
软件质量包括：内部质量、外部质量、使用质量三个部分。
5、软件测试与质量保证的区别：
质量保证（QA）质量保证的重要工作通过预防、检查与改进来保证软件质量。QA采用“全面质量管理”和“过程改进”的原理开展质量保证工作。关注软件质量的检查与测量。
软件测试也与软件开发过程紧密相关，关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试员要“执行”软件，对过程中的产物开发文档和源代码进行走查，运行软件，以找出问题，报告质量。对测试中发现的问题的分析、追踪和回归测试。软件测试是保证软件质量的一个重要环节。
6、软件测试目的
测试目的三个观点：
测试是程序的执行过程，目的在于发现错误；
一个好的测试用例在于能发现至今未发现的错误；
一个成功的测试是发现了至今未发现的错误的测试；
测试的目的，是想以最少的人力、物力和时间找出软件潜在的各种错误和缺陷，通过修正各种错误和缺陷
提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造居的隐患所带来的商业风险。
测试是对软件质量的度量与评价，以验证软件的质量满足用户的需求的程度，为用户选择与接受软件提供有力的依据。
7、软件测试原则
所有的软件测试都应追溯到用户需求。
应当把“尽早地和不断地进行软件测试”作为软件测试者的座左铭。
完全测试是不可能的，测试需要终止。
在有限的时间和资源条件下，软件趋于完美，是不可能的。主要有三个原因：
软件入量太大；
输出结果太多；
路径组合太多。
测试无法显示软件潜在的缺陷
充分注意测试中的群集现象。
程序员应避免检查自己的程序。
尽量避免测试的随意性。（应该从工程的角度去理解软件测试，它是有组织、有计划、步骤的活动。）
8、软件测试对象
根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。
在软件编码结束后，对编写的每一个程序模块进行测试，称为模块测试或单元测试。
在模块集成后，对集成在一起模块组件，有时称为部件，进行测试，称为集成测试。
在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，称为确认测试。
将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为系统测试。
软件错误中，属于需求分析和软件设计的错误约为64%，属于程序编写的错误仅占36%。
验证（verification）是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。
确认（validation）是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。
验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。
需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，称为“确认测试”。将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。
测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试和系统测试。
9、软件测试分类
按照开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试和验收测试。
单元测试：单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
集成测试：也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
确认测试：就是通过检验和提供客观证据，证实软件是否满足特定预期用途的要求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。
系统测试：它是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。
验收测试：按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。
- 按照开发阶段划分
- 单元测试。
单元测试又称模块测试，是针对程序模块进行正确性检验的测试工作。
- 集成测试
集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
冒烟测试也叫验证测试、提交测试。
- 确认测试
确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。
- 系统测试
系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接、并满足用户需求。
- 验收测试
按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。
- 按照测试实施组织划分
按照测试实施组织划分，软件测试可分为开发方测试、用户测试（Beta测试）、第三方测试。
（1）开发方测试
通常也叫“验证测试”或“α测试”。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。
（2）用户测试
在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。
（3）第三方测试
介于软件开发方和用户方之间的测试组织的测试。一般情况下是在模拟用户真实应用环境下，进行软件确认测试。
- 按照测试技术划分
按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。静态测试是指不运行程序，通过人工对程序和文档进行分析与检查：静态测试技术又称静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查，静态测试包括：走查、符号执行、需求确认等。动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。
（1）白盒测试
通过对程序内部结构的分析、检测来寻找问题。了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。
（2）黑盒测试
通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。
（3）灰盒测试
灰盒测试关注输出对于输入的正确性
- 静态测试
它是指不运行程序，通过人工对程序和文档进行分析与检查； 静态测试技术又称静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行检查，
静态测试包括：走查、符号执行、需求确认等。
- 动态测试
它是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。
- 白盒测试
又称结构测试。通过对程序内部结构的分析、检测来寻找问题。
- 黑盒测试
通过软件的外部表现来发现其缺陷和错误。它是在程序界面处进行测试，它只是检查样序是否按照需求规格说明书的规定正常实现。
10、软件测试过程模型
- V模型
它反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如图所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V模型指出，单元和集成测试是验证的程序设计，检测程序的执行是否满足软件设计的要求；
系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；
测试员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。
V模型存在一定的局限性，它仅仅是测试过程作为在需求分析、概要设计、详细设计及编码后的一个阶段。需求分析阶段隐藏的问题一直到后期的验收测试才被发现。
V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试为了使整个系统满足用户的需求。
- W模型
1、W模型建立
V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是与此相并行的“V”。基于“尽早地和不断地进行软件测试”的原则，
优点：
测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。
体现“尽早地和不断地进行软件测试”的原则。
在V模型中增加软件和开发阶段应同步进行的测试。
局限性：
软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这就无法支持迭代、自发性以及变更调整。
2、W模型应用
它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。
参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。
根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例。
W模型也是有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。
- H模型
1、H模型建立
它将测试活动独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
2、H模型应用
软件测试不仅仅指测试的执行，还包括很多其他的活动。
软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
软件测试要尽早准备，尽早执行。
软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。
- 其他模型
- X模型
该模型定位了探索性测试。
Marick对V模型最主要批评是V模型无法引导项目全部过程。他认为一个模型必须能处理开发的所有方面，包括交接、频繁重复的集成以及需求文档的缺乏等。
2、前置测试模型
它是一个将测试和开发紧密结合的模型，该模型提供了轻松的方式，可使你的项目加快速度。
前置测试模型体现了以下的要点：
（1）开发和测试相结合；前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。
（2）对每一个交付内容进行测试；每一个交付的开发结果都必须通过一定的方式进行测试。
（3）在设计阶段进行测试计划和测试设计；设计阶段是作测试计划和测试设计的最好时机。
（4）测试和开发结合在一起；前置测试将测试执行和开发结合在一起，并在开发阶段以编码——测试——编码——测试的方式来体现。
（5）让验收测试和技术测试保持相互独立。验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。
10、软件生命周期测试策略
- 软件开发与软件测试
软件开发的过程是一个自顶向下，逐步细化的过程。
测试过程则是依照相反的顺序安排自底向上，逐步集成的过程。
- 软件测试策略
测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试和系统测试。
1、测试信息流
测试过程需要以下三类输入：
软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。
测试配置：包括测试计划、测试用例、测试驱动程序等。测试配置只是软件配置的一个子集。
测试工具：
2、分析设计阶段
分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书、详细设计说明书评测以及软件编码规范评测等。
编制良好的需求说明书8条原则：
功能与实现分离；
要求使用面向处理的规格说明语言；
描述该目标软件与系统的其他系统元素交互的方式；
规格说明必须包括系统运行的环境；
系统规格说明必须是一个认识的模型；
规格说明必须是可操作的；
规格说明必须容许不完备性并允许扩充；
规格说明必须局部化和松散的耦合。
（1）需求说明书评测
需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。
需求说明书评测内容：
系统定义的目标是否与用户的要求一致。
系统需求分析阶段提供的文档资料是否齐全。
文档中的所有描述是否完整、清晰、准确地反映用户要求；
与所有其他系统成份的重要接口是否都已经描述；
被开发项目的数据流与数据结构是否足够、确定；
所有图表是否清楚，在不补充说明时能否理解；
主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
软件的行为和它必须处理的信息、必须完成的功能是否一致；
设计的约束条件或限制条件是否符合实际；
是否考虑了开发的技术风险；
是否考虑过软件需求的其他方案；
是否考虑过将来可能会提出的软件需求；
是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
有没有遗漏、重复或不一致的地方；
用户是否审查了初步的用户手册或原型；
项目开发计划中的估算是否受到了影响。
（1）需求说明书评测
编制良好的需求说明书8条原则。
原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。
原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。
原则3：如果目标软件只是一个大系统中的一个元素，那么整个系统也包括在规格说明的描述之中。
原则4：规格说明必须包括系统运行的环境。
原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
原则6：规格说明必须是可操作的。
原则7：规格说明必须容许不完备性并允许扩充。
原则8：规格说明必须局部化和松散的耦合。
需求说明书的框架。
需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。
需求说明书评测内容。
需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：
（1）系统定义的目标是否与用户的要求一致；
（2）系统需求分析阶段提供的文档资料是否齐全；
（3）文档中的所有描述是否完整、清晰，准确地反映用户要求；
（4）与所有其他系统成份的重要接口是否都已经描述；
（5）被开发项目的数据流与数据结构是否足够、确定；
（6）所有图表是否清楚，在不补充说明时能否理解；
（7）主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
（8）软件的行为和它必须处理的信息、必须完成的功能是否一致；
（9）设计的约束条件或限制条件是否符合实际；
（10）是否考虑了开发的技术风险；
（11）是否考虑过软件需求的其他方案；
（12）是否考虑过将来可能会提出的软件需求；
（13）是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
（14）有没有遗漏、重复或不一致的地方；
（15）用户是否审查了初步的用户手册或原型；
（16）项目开发计划中的估算是否受到了影响。
（2）概要设计说明书评测
设计说明书的框架
设计说明书的框架内容：
（1）可追溯性
（2）接口
（3）风险
（4）实用性
（5）技术清晰度
（6）可维护性
（7）质量
（8）各种选择方案
（9）限制
（10）其他具体问题
为评测设计是否达到目标，必须建立衡量设计的技术标准。如下：
主要评测内容：
可追溯性；接口；风险；实用性；技术清晰度；可维护性；质量；各种选择方案；限制；其他具体问题。
（1）设计出来的结构应是分层结构，从而建立软件成分之间的控制；
（2）设计出来的结构应是分层结构，从而建立软件成分之间的控制；
（3）设计应当既包含数据抽象，也包含过程抽象；
（4）设计应当建立具有独立功能特征的模块；
（5）设计应当建立能够降低模块与外部环境之间复杂连接的接口；
（6）设计应当根据软件需求分析获取的信息，建立可驱动、可重复的方法。
（3）详细设计说明书评测
与概要设计说明书基本相同。
（4）软件编码规范评测
程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构的输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。
源程序文档化
（1）符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。
（2）程序的注释。注释分为序言性注释和功能性注释。
（3）标准的书写格式。
数据说明
（1）数据说明的次序应当规范化。
（2）说明语句中变量安排有序化。
（3）使用注释说明复杂数据结构。
语句结构
在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。
输入和输出
输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。
输入和输出
在设计和程序编码时都应考虑下列原则。
（1）对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；
（2）检查输入项的各种重要组合的合理性，必要时报告输入状态信息；
（3）使输入的步骤和操作尽可能简单，并保持简单的输入格式；
（4）输入数据时，应允许使用自由格式输入；
（5）应允许缺省值；
（6）输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；
（7）在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；
（8）当程序设计语言对输入/输出格有严格要求时，应保持输入格式与输入语句要求的一致性；
（9）给所有的输出加注解，并设计输出报表格式。
3、开发阶段
（1）单元测试
单元测试的内容：
在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之黑盒测试的测试用例。
使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。
在单元测试中进行的测试工作如图2-9所示，需要在五个方面对所测模块进行检查。
在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。
1）模块接口测试
在单元测试的开始，应对通过所测模块的数据流进行测试。
如果数据不能正确地输入和输出，就谈不上进行其他测试。为此，对模块接口可能需要如下的测试项目：
调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；
所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；
是否修改了只作输入用的形式参数；
输出给标准函数的参数在个数、属性、顺序上是否正确；
全局量的定义在各模块中是否一致；
限制是否通过形式参数来传送。
2）局部数据结构测试
设计测试用例以检查以下各种错误：
不正确或不一致的数据类型说明；
使用尚未赋值或尚未初始化的变量；
错误的初始值或错误的缺省值；
变量名拼写错或书写错；
不一致的数据类型。
3）路径测试
常见的不正确计算有：运算的优先次序不正确或误解了运算的优先次序；
运算的方式错，即运算的对象彼此在类型上不相容；
算法错；
初始化不正确；
运算精度不够；
表达式的符号表示不正确。
4）错误处理测试
比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。模块和错误处理功能包含有错误或缺陷：
出错的描述难以理解；
出错的描述不足以对错误定位，不足以确定出错的原因；
显示的错误与实际的错误不符；
对错误条件的处理不正确；
在对错误进行处理之前，错误条件已经引起系统的干预等。
5）边界测试
单元测试步骤：
驱动模块（driver）相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后输出实测结果。
桩模块（stub）也叫存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。
（2）集成测试
集成测试也叫做组装测试或联合测试。在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
组成时需要考虑的问题：
1）在把各个模块连接起的时候，穿越模块接口的数据是否会丢失；
2）一个模块的功能是否会对另一个模块的功能产生不利的影响；
3）各个子功能组合起来，能否达到预期要求的父功能；
4）全局数据结构是否有问题；
5）单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。
子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
模块组装成为系统的方式。
模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。
1）一次性组装方式
它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。
2）增殖式组装方式
这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
自顶向下的增殖方式。步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引新的错误的可能。最后，判断是否所有的模块都已组装到系统中。
自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。
如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。
自底向上的增殖方式。
提高测试效率。
进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：
满足某些软件需求；
在程序的模块结构中位于较高的层次（高层控制模块）；
较复杂、较易发生错误；
有明确定义的性能要求。
在做回归测试时，也应该集中测试关键模块的功能。
集成测试的组织和实施。
集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
（1）采用何种系统组装方法来进行集成测试。
（2）集成测试过程中连接各个模块的顺序。
（3）模块代码编制和测试进度是否与集成测试的顺序一致。
（4）测试过程中是否需要专门的硬件设备。
集成测试完成的标志。
集成测试完成的标志主要有以下几项。
（1）成功地执行了测试计划中规定的所有集成测试。
（2）修正了所发现的错误。
（3）测试结果通过了专门小组的评审。
集成测试需要提交的文档有集成测试计划、集成测试规格说明书和集成测试分析报告。
（3）确认测试
确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查，确认测试一般由独立的第三方测试机构进行。
进行有效性测试。
有效性测试是在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的要求。
在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类。
（1）测试结果与预期的结果相符。这说明软件的部分功能或性能特征与需求规格说明书相符合，从而接受了这部分程序。
（2）测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
软件配置复查。
（4）系统测试
系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或模拟运行（使用）环境下，对计算机系统进行一系统列测试。
（5）验收测试
4、软件验证与确认（V&V）过程
软件的V&V过程是确定按照规定的软件过程开发的产品是否符合活动的要求，软件是否满足它的预期用途和用户需要。软件的V&V过程包括软件产品和过程的分析、评价、评审、审核、评估和测试。
软件测试活动是软件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.1软件失效分类
软件错误（software error）
软件缺陷（software defect）
软件故障（software fault）
软件失效（software failure）
软件失效机理可描述为：软件错误è软件缺陷è软件故障è软件失效
（1）软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。
（2）软件缺陷存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷激动。
（3）软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。
（4）软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。
错误的广义定义是：不正确的事务和行为。
错误是在系统运行时，引起或可能潜在地引起失效的缺陷，是一种面向开发概念。
软件缺陷：
（1）软件未达到产品说明书中标明的功能；
（2）软件出现了产品说明书中指明的不会出现的错误；
（3）软件功能超出了产品说明书指明的范围；
（4）软件未达到产品说明书虽未指出应达到的目标；
（5）软件测试人员认为软件难以理解、不易使用、运行速度慢，或最终用户认为不好使用。
产品说明书是软件缺陷的第一来源，也就出自于软件需求说明书本身的问题。
设计方案（软件设计说明书）是软件缺陷第二来源。
2.8.2缺陷与错误分布
2.8.3缺陷与错误严重性和优先级
软件存在的缺陷与错误会带来软件失败的风险，重要软件故障与失效会导致重大经济损失与灾难。给软件缺陷与错误划分严重性和优先级的通用原则是：
（1）表示软件缺陷所造成的危害的恶劣程度；
（2）优先级表示修复缺陷的重要程度和次序；
严重级：
严重：系统崩溃、数据丢失、数据毁坏
较严重：操作性错误、错误结果、遗漏功能
一般：小问题、错别字、UI布局、罕见故障
建议：不影响使用的瑕疵或更好的实现
优先级：
最高优先级：立即修复，停止进一步测试
次高优先级：在产品发布之前必须修复
中等优先级：如果时间允许应该修复
最低等优先级：可能会修复，但是也能发布
2.8.4软件错误跟踪管理
软件测试的主要目的在于发现软件存在的错误（Bug），如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。
在实际的软件测试过程中，每个BUG都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。
作为一个错误跟踪管理系统，需要正确记录错误信息和错误处理信息的全部内容。
（1）BUG记录信息
主要包括以下几项内容。
测试软件名称
测试版本号
测试人名称
测试事件
测试软件和硬件配置环境
发现软件错误的类型
错误的严重等级
详细步骤
必要的附图
测试注释
（2）BUG处理信息
处理者姓名
处理时间
处理步骤
错误记录的当前状态
2、软件错误的状态
新信息（New）：测试中新报告的软件BUG
打开（Open）：被确认并分配给相关开发人员处理。
修正（Fixed）：开发人员已完成修正，等待测试人员验证。
拒绝（Declined）拒绝修改BUG
延期（Deferred）：不在当前版本修复的错误，下一步修复。
关闭（Closed）：BUG已被修复。
3、错误管理流程
4、错误流程管理原则
2.9白盒测试
2.10黑盒测试
黑盒测试也称为功能测试，它是通过测试来检测每个功能是否都能正常使用。在完全不考虑内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。主要针对软件界面和软件功能进行测试。
黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。
功能不正确或遗漏
界面错误
数据库访问错误
性能错误
初始化和终止错误
黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
2.11自动化测试
2.11.1自动化测试的基本概念
自动化测试的定义：通过测试工具或其他手段，按照测试工程师的预定计划对软件产品进行自动的测试，它是软件测试的一个重要的组成部分，它能够完成许多手工无法完成或难以实现的一些测试。正确、合理地实施自动化测试，能够快速、全在财对软件进行测试，从而提高软件质量，节省经费，缩短产品发布周期。
2.11.2自动化测试的优势与局限
1、自动化测试的优势
避免重复测试，同时，还能完成大量手工无法完成的测试工作，如并发用户测试、大数据量测试、长时间运行可靠性测试等，优点：
提高测试质量
提高测试效率，缩短测试工作时间
提高测试覆盖率
执行手工测试不能完成的测试任务
更好地重现软件缺陷的能力
更好地利用资源
增进测试人员与开发人员之间的合作伙伴关系
以下项目和环境中更适合使用自动化测试工具：
需要反复进行的工作
负载压力测试
测试人员和开发人员有效合作借助测试管理工具，会取得事半功倍的效果。
若需要进行测试系统后台或者内部的性能特性，进而进行故障定位和性能调优。
2、自动化测试的局限性
定制型项目
周期很短的项目
业务规则复杂的对象
人体感观与易用性测试
不稳定的软件
涉及物理交互
2.11.3选择合适的自动化测试工具
1、自动化测试工具分类
自动化测试工具分以下几类：
负载压力测试工具
功能测试工具
白盒测试工具
网络测试工具
测试管理工具
测试辅助工具
2、自动化测试应用策略
在测试过程中应用测试工具主要有以下几个目的：
提高测试质量；
减少测试过程中的重复劳动；
实现测试自动化，解决手工测试不能解决的问题。
选择合适的自动化测试工具
建议以下几个方面来权衡：
（1）功能
报表功能
测试工具的集成能力
操作系统和开发工具的兼容性
（2）价格
（3）测试工具的长期投资考虑
测试工具的引入：
确定测试工具的应用时机；
确定测试重点；
确定测试目标和指标；
充分利用测试工具的优势；
加强对测试工程师的技能培训；
2.11.4功能自动化测试
1、测试原理
测试自动化测试工具基本上都是采取录制回放的方式来模拟用户的实际操作。在软件操作中点击图形用户界面上的对象时，测试工具会用一种类C或其他的脚本语言（TSL）生成一个测试脚本，该脚本记录了你的操作过程，然后测试工具就可回放刚才的操作过程。测试工具采取两种录制模式：
（1）环境判断模式
这种模式根据你选取的图形用户界面对象（如窗体、清单、按钮等），把你对软件的操作动作录制下来，每一次你对被测软件进行操作，测试脚本语言会记录并描述你选取的对象和你的操作动作。当你进行录制时，测试工具会对你选取的每个对象做惟一描述并写入相应的文件中。回放时，测试工具从指定文件中读取对象描述，并在被测软件中查找符合这些描述的对象并模拟用户使用鼠标选取该对象、用键盘输入数据的操作。
（2）模拟模式
这种模式记录鼠标点击、键盘输入和鼠标在二维平面上的精确运动轨迹。执行测试时，测试工具让鼠标根据轨迹运行。
通常情况下，其实施测试必须经历的几个操作步骤如下：
创建脚本。你可以通过录制、编程或两者同用的方式创建测试脚本。测试工具可以自动记录你的操作并生成所需的脚本代码，你还可以直接修改测试脚本以满足各种复杂测试的需求，录制测试时，在需要检查软件反应的地方插入检查点。在这个过程中，测试工具会自动捕捉数据，并将该数据作为期望结果储存下来。
调试脚本：脚本录制或编辑结束后，在调试模式下运行脚本。并可以设置中断点来监测变量，控制对象识别和隔离错误。
执行测试：脚本调试结束后，便可以在检验模式下测试被测软件。
结果分析：每次测试结束，测试工具都会把测试情况显示在测试结果报告中。
2.11.5负载压力自动化测试
负载测试是为了证明在与产品（预期）规模等同的数据库中处理给定的事务请求的容量下，系统功能与性能是否与需求规格说明中规定的，可接受的响应时间一致的测试过程。而压力测试则是使客户机在大容量情况下运行的测试过程，目的是查看应用将在何时何处出现中断，即识别系统的薄弱环节。
负载压力测试工具基本上都是采取录制回放的方式来模拟用户的实际操作的，而且测试工具一般都会有一个后台代理进程，通过该代理进程，测试工具可以监视并获取在各种通信协议下应用系统的客户与服务器的通信信息，测试工具会用一类C或者其他的脚本语言（TSL）生成一个测试脚本，该脚本记录了你对服务器的请求过程，然后测试工具就可以回放刚才的访问过程，接收服务器的响应，当然你也可以用手工编程生成这个脚本。
同时，控制台还可以通过服务器上开启的远程RPC服务，获取相关的资源使用信息，最后还可以收集测试数据。
在进行测试脚本录制与分配的过程中，应遵循如下几个原则。
脚本越小越好。
选择负载压力最高的业务功能进行测试。
选择所需要的操作进行录制。
测试工具模拟多用户并发访问可以有以下两种方式：
进程回放模式；
线程回放模式；
操作步骤如下：
协议选择：
创建测试脚本：
参数化测试数据
创建虚拟用户，设定负载方案
执行测试
结果分析
第3章软件质量与评价（软件测试标准）
3.1质量的定义
软件质量的定义：反映实体满足明确的隐含的需要的能力的特性的总和。
质量是多维的概念，包括：实体、实体的属性和对实体的观点。
质量是实体特性的总和，满足明确或隐含要求的能力。
3.2测度与度量
测量就需要首先建立质量指标体系或质量模型，然后使用特定测量方法才能实施测量。
在软件质量中用于测量一种量化的标度和方法即为“测度”，而名词的“度量”用来指测量的结果。
3.3软件质量模型
影响软件质量的因素可以分为两大类：可直接测量（如每个功能点的错误）和间接度量（如可用性、可维护性）。
McCall质量模型，集中在软件产品的三个重要方面：操作特性（产品运行）、承受可改变能力（产品修订）、新环境适应能力（产品变迁）。
我国的软件产品质量评价标准GB/T 16260-1996。它是一个分层质量模型，有6个影响质量的特性。
国际标准化组织1991年颁布了ISO-9126-1991标准《软件产品评价—质量特性及其使用指南》。我国也于1996发布了同样的软件产品质量评价标准GB/T16260-1996。它是一个分层质量模型，有6个影响质量的特性。如图3-3所示说明了质量特性与质量子特性的层次结构。
产品评价：注重软件质量评价的支持和评价过程；
产品质量：注重软件本身的质量度量模型。
软件质量评价的基本部分包括：质量模型、评价方法、软件的测量和支持工具。
标准的软件质量测度是这样建立的：软件质量模型分三个层次，第一层有6个影响软件质量的主要因素，称为“质量特性”。每个质量特性又可通过第二层的若干个子特性测量，第二层的每个子特性在评价时要定义并实施若干个度量。ISO9126资料性的附录中给出21个子特性。
3.4标准的发展
国际软件工程标准化组织将软件“产品评价”与“产品质量”分成两个标准，“产品评价”注重软件质量评价的支持和评价过程；“产品质量”注重软件本身的质量度量模型。
软件质量评价的基本部分包括：质量模型、评价方法、软件的测量和支持工具。
3.5GB/T18905产品评价
3.5.1GB/T18905基本组成
GB/T18905-2002《软件工程 产品评价》。该系列标准由以下6个部分组成。
GB/T18905.1《软件工程 产品评价》第1部分，概述。
GB/T18905.2《软件工程 产品评价》第2部分，策划和管理。
GB/T18905.3《软件工程 产品评价》第3部分，开发者用的过程。
GB/T18905.4《软件工程 产品评价》第4部分，需方用的过程。
GB/T18905.5《软件工程 产品评价》第5部分，评价者用的过程。
GB/T18905.6《软件工程 产品评价》第6部分，评价模块的文档编制。
3.5.2评价者用的过程（GB/T18905.5）
3.5.3关于评价支持
3.5.4通用评价过程
软件产品的一般评价过程是：确立评价需求，然后，规定、设计和执行评价。
3.5.5评价需求
软件质量评价的目的是为了直接支持开发和获得能满足用户和消费者要求的软件。最终目标是保证产品能提供所要求的质量，即满足用户（包括操作者、软件结果的接受者，或软件的维护者）明确和隐含的要求。
（1）评价中间产品质量的目的
决定（是否）接受分包商交付的中间产品；
决定某个过程的完成，以及何时把产品送交下个过程；
预计或估计最终产品的质量；
收集中间产品的信息以便控制和管理过程。
（2）评价最终产品质量的目的
决定（是否）接受产品；
决定何时发布产品；
与相互竞争的产品进行比较；
从众多可选的产品中选择一种产品；
使用产品时评估产品积极和消极的影响；
决定何时增强或替换该产品。
3.5.6确定要评价产品的类型
3.5.8规定质量模型
GB/T16260.1提供了一个通用模型，它定义了6种软件质量特性，包括功能性、可靠性、易用性、效率、可维护性和可移植性。
3.5.9规定评价
（1）选择度量
（2）测量的种类
评价有两个主要目的。
确定问题以便解决问题；
与可替换的产品进行比较，或对照需求比较产品质量。
（3）确立度量评定等级
（4）确立评估准则
3.6GB/T16260.1产品质量
GB/T16260-2003《软件工程 产品质量》。标准由以下4部分组成：
质量模型、外部度量、内部度量、使用质量度量。
3.6.1基本组成
GB/T16260-2003《软件工程 产品质量》。该系列标准由以下4部分组成。
GB/T16260.1《软件工程 产品质量》第1部分，质量模型。
GB/T16260.1《软件工程 产品质量》第2部分，外部质量。
GB/T16260.1《软件工程 产品质量》第3部分，内部质量。
GB/T16260.1《软件工程 产品质量》第4部分，使用质量度量。
3.6.2标准概述
1、标准的变化
2、标准之间的关系
GB/T18905.1概述是产品评价标准的总则，GB/T16260的评价过程与度量是遵循GB/T18905的。
3.6.3标准的范围
标准可从软件的获取、需求、开发、使用、评价、支持、维护、质量保证和审核相关的不同观点来确定和评价软件产品的质量。
本标准中定义的质量模型使用实例是：
确认需求定义的完整性；
确定软件需求；
确定软件设计目标；
确定软件测试目标；
确定质量保证准则；
为完整的软件产品确定验收准则。
3.6.4质量模型框架
1、软件质量特性与度量
质量特性和子特性（GB/T16260.1）；
外部度量（GB/T16260.2）；
内部度量（GB/T16260.3）。
2、质量途径
3、产品质量和生存周期
（1）用户的质量要求
可按使用质量的度量、外部度量或内部度量来规定质量需求。当验证产品时，这些由度量规定的需求应作为准则使用。
（2）外部质量需求
从外部观点来规定必须的质量级别，包括来源于用户质量要求（使用质量需求）。
（3）内部质量需求
内部质量需求是从产品的内部观点来规定必须的质量水平。
（4）使用质量
使用质量是从用户观点出发，来看待软件产品用于特定环境和条件下的质量。
（5）外部质量
外部质量是从外部观点出发的软件产品特性的总体。
（6）内部质量
内部质量是从内部观点出发的软件产品特性的总体。
3.6.5外部质量和内部质量的质量模型
外部质量和内部质量的质量模型软件，其质量属性划分为6种特性（功能性、可靠性、易用性、效率、维护性和可移植性），并进一步细分为一些子特性。
软件的每个质量特性和子特性都有定义。对于每个特性和子特性，软件的能力由可测量的一组内部属性决定，内部度量的示例在GB/T16260.3中给出。这些特性和子特性根据包含该软件的系统提供能力的程度从外部进行测量，外部度量的示例在GB/T16260.2中给出。
1、功能性
功能性是指在当软件在指定条下使用时，软件产品满足明确和隐含要求功能的能力。
（1）适合性
（2）准确性
（3）互操作性
（4）保密安全
（5）功能性依从性
2、可靠性
在指定条件下使用时，软件产品维持规定的性能级别的能力。
（1）成熟性
（2）容错性
（3）易恢复性
（4）可靠性依从性
3、易用性
易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
（1）易理解性
（2）易学性
（3）易操作性
（4）吸引性
（5）易用性依从性
4、效率
效率是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。
（1）时间特性
（2）资源利用性
（3）效率依从性
5、维护性
维护性是指软件产品可被修改的能力。修改可能包括修正、改进或软件适应环境、需求和功能规格说明中的变化。
（1）易分析性
（2）易改变性
（3）稳定性
（4）易测试性
（5）维护性依从性
6、可移植性
可移植性是指软件产品从一种环境迁移到另外一种环境的能力。
（1）适应性
（2）易安装性
（3）共享性
（4）易替换性
（5）可移植性依从性
适应性是指软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段，就可能适应不同的指定环境的能力。
（2）易安装性
易安装性是指软件产品在指定环境中被安装的能力。
（3）共存性
共存性是指软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。
（4）易替换性
易替换性是指软件产品在环境相同、目的相同的情况下替代另一个指定软件产品的能力。
（5）可移植性依从性
可移植性依从性是指软件产品依附于同可移植性相关的标准或约定的能力。
3.6.6使用质量的质量模型
使用质量是从用户角度看待的质量，其属性分为4种：有效性、生产率、安全性和满意度。
第4章软件测试过程与管理
4.1软件测试过程
软件的测试过程一般分成测试计划、测试设计与开发、测试实施、测试评审与测试结论等阶段。
软件测试过程是一种抽象的、遵循GB/T18905（ISO14598.5）《评价者用的过程（Process for Evaluator）》中定义软件评价过程的模型，是国际上共遵守的软件评测过程标准，是软件测试过程管理的精髓。为符合GB/T18905基本原理，仍保留“评价过程”的标准用户。
4.2评价过程的特性
（1）可重复性：由同一评价者按同一评价规格说明对同一产品进行重复地评价，应产生同一种可接受的结果。
（2）可再现性：由不同评价者按同一评价规格说明对同一产品进行评价，应产生同一种可接受的结果。
（3）公正性：评价应不偏向任何特殊的结果。
（4）客观性：评价结果应是客观事实，即不带有评价者的感情色彩或主观意见。
4.3评价过程
4.3.1评价活动
评价过程由下列5个活动组成：
（1）确立软件评价需求
（2）编制评价规格说明
（3）制定评价计划
（4）评价执行计划
（5）作评价结论
4.3.2评价过程的输入
请求者提供其需求，并作为评价需求的最初版本。
请求者提供下列评价过程的输入
（1）软件的说明书；
（2）软件的部件；
评价者提供下列评价过程输入。
（1）预先确定的评价规格说明；
（2）评价方法；
（3）评价工具；
4.3.3评价过程的输出
在评价期间，评价者提供下列输出产品：
（1）评价记录，包括评价计划和评价动作的记录；
（2）评价报告草案，包括评价需求，评价规格说明和综合的评价结果；
（3）经过评审的评价报告。
4.3.4评价过程需求
评价需求、评价规格说明和评价计划是评价过程的中间产品；评价记录和评价报告是评价过程的最终产品。
（1）评价需求：描述评价的目标，特别是描述了产品的质量需求。
（2）评价规格说明：确定对软件及其部件实行的所有分析和测量，标识要分析和测量的软件部件。
（3）评价计划：描述评价规格，说明需要实施的操作规程；描述评价所需用到的方法和工具。
（4）评价记录：评价执行计划时详细记载的动作组成；记录由评价者保留。
（5）评价报告：执行测量和分析的结果，以及能被重复和重新评价的必要信息。评价报告首先作为评审草案来发布，其最终版本将交给请求者。
4.4评价与生存周期的关系
评价软件产品可以在任何软件生存周期过程的范围内进行。特别是，评价能在软件获取、供应、开发、运行或维护过程中进行。
4.5评价过程的要求
4.5.1一般要求
1、组织和质量体系
2、请求者的职责
3、评价者的职责
4.5.2评价需求确立
1、评价需求确立的目的
2、评价需求分析
分析评价需求的活动由下列5个子活动组成：
（1）请求者提出评价需求建议；
（2）请求者说明评价覆盖范围；
（3）评价者分析评价原因和描述评价需求来响应请求者；
（4）评价者解释评价的保密范围和严格程度；
（5）评价者同意评价需求；
3、评价需求内容
（1）评价需求应包含对评价产品应用领域的描述，以及产品用途的描述。
（2）评价需求应由GB/T16260中定义为“质量特性”的一系列质量需求组成，还可能用到一些子特性。
（3）评价需求中的每项需求，都应提供要评价软件及部件的规格说明信息。
4、认可与报告
4.5.3评价规格说明
1、评价规格说明的目的
2、评价规格说明编制
编制评价规格说明的活动由下列3个子活动组成：
（1）分析产品的描述
（2）规定对产品及部件执行的测量
（3）按照评价需求验证编制的规格说明
3、评价规格说明的内容
评价规格说明应包括：
（1）评价范围，涉及在产品说明中标识的产品硬件；
（2）评价执行所需的信息，在产品说明中列出的软件部件及其他相关文档之间的相互引用；
（3）要执行的测量和验证的规格说明，以及对要评价的产品部件的引用；
（4）测量的验证的规格说明与评价需求之间，与引用标准或对所列的每个测量或验证的理由之间映射。
4、认可和报告
评价规格说明应作为请求者和测试者之间联合评审的结果予以认可。
4.5.4评价设计
1、评价设计目的
评价设计应把评价者使用的测量规程编成文档，以便评价执行规格说明中规定的测量。评价者应制定评价计划来描述执行指定的评价时所需的资源和执行各种动作时对这些资源的分配。
2、制定评价计划
制定评价计划的活动由3个子活动组成：
（1）把评价方法编成文档，起草计划；
（2）优化评价计划；
（3）根据可用资源安排评价动作的进度。
（4）评价计划的内容
3、认可和报告
4.5.5评价执行
软件样品登记的信息应至少包括：
（1）部件或文档的惟一标识符
（2）部件的名称或文档标题
（3）文档的状态（包括物理状态或变异状态）
（4）请求者提供样品的版本、配置和日期信息
（5）接收的日期。
1、评价执行目的
评价执行目的是根据评价需求，按照评价规格说明中的规定和评价计划，从对软件产品的测量和验证中获得结果，执行这些动作将完成评价报告和评价记录的草稿。
2、评价执行者的动作
为了执行计划的评价，评价者应做到以下几点。
1）管理请求者提供的产品部件；
2）管理评价动作所产生的数据（包括报告和记录）；
3）管理评价执行动作的工具。
此外，评价者还可以管理在评价者的承诺之外执行的评价动作；
（1）软件部件的管理
（2）评价数据管理
（3）工具使用的管理
（4）现场评价
（5）特定评价技术的需求
（6）评审和报告
4.5.6评价结论
1、评价结论的目的
2、评价报告的联答评审
3、评价数据和文档的处置
4.6配置管理
软件测试过程的配置管理和软件开发过程的配置管理是一样的。
软件测试配置管理包括4个最基本的活动：
（1）配置项标识
（2）配置项控制（变更控制）
（3）配置状态报告
（4）配置审计
4.6.1配置项标识
标识测试样品、标准、工具、文档（包括测试用例）、报告等配置项的名称和类型。
指出何时基准化配置项（置于基线控制之下）。
标识各配置项的所有者及储存位置。
4.6.2配置项控制
规定测试基线，对每个基线必须描述下列内容：
（1）每个基线的项（包括文档、样品和工具）；
（2）与每个基线有关的评审、批准事项以及验收标准。
规定何时何人创立新的基线，如何创立。
确定变更控制委员会的人员组成、职能（包括变更授权、确认与批准）、工作程序。
确定变更请求的处理程序和终止条件。
确定变量请求的处理过程中各测试人员执行变更的职能。
确定变更请求和所产生结果的对应机制。
确定配置项提取和存入的控制机制与方式。
4.6.3配置状态报告
定义配置状态报告形式、内容和提交方式。
确认过程记录和跟踪问题报告，更改请求，更改次序等。
确定测试报告提交的时间与方式。
4.6.4配置审计
确定审计执行人员和执行时机。
确定审计的内容与方式。
确定发现问题的处理方法。
配置管理是管理和调整变更（change）的关键，对于一个参与人员较多、变更较大的项目，它是至关重要的。
4.7测试的组织与人员
组织是指一个系统将材料、知识和方法组合起来，把各种不同的输入转换成有价值的输出。
4.7.1组织结构设计因素
测试组织结构设计因素包括：
垂直还是平缓；
市场还是产品；
集中还是分散；
分级还是分散；
专业人员还是工作人员；
功能还是项目；
4.7.3测试组织管理者
测试管理是很困难的，测试组织的管理者必须具备：
理解与评价软件测试政策、标准、过程、工具、培训和度量的能力；
领导一个测试组织的能力，该组织必须坚强有力、独立自主、办事规范没有偏见；
吸引并留住杰出测试专业人才的能力；
领导、沟通、支持和控制的能力；
测试时间、质量和成本控制的能力。
4.7.4集中管理的测试组织
4.7.5选择合理的组织方案
选择合理高效的测试组织结构方案的准则是：
（1）提供软件测试的快速决策能力；
（2）利于合作，尤其是产品开发与测试开发之间的合作；
（3）能够独立、规范、不带偏见地运作并具有精干的人员配置；
（4）有利于协调测试与质量管理的关系；
（5）有利于满足软件测试过程管理要求；
（6）有利于为测试技术提供专有技术；
（7）充分利用现有测试资源，特别是人；
（8）对测试者的职业道德和事业产生积极的影响。
4.7.6测试人员
1、测试人员的选择
测试人员的能力包括以下几项：
测试人员的能力包括以下几项。
（1）一般能力：包括表达、交流、协调、管理、质量意识、过程方法、软件工程等；
（2）测试技能及方法：包括测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等；
（3）测试规划能力：包括风险分析及防范、软件放行/接收准则制定、测试目标及计划、测试计划和设计的评审方法等；
（4）测试执行能力：包括测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具；
（5）测试分析、报告和改进能力：包括测试度量、统计技术、测试报告、过程监测及持续改进。
2、测试人员的激励
（1）X理论+Y理论
X理论：胡萝卜+大棒——迫使人们工作；
Y理论：经理的职能不是督促人们工作，而是使人们有可能工作。
（2）需要的层次（Maslow模型）
生存需要——工作职位、工资奖金、休息时间；
安全需要——公正待遇、应付工作的能力和信心；
社会需要——团队归属感，互相认同、理解和支持；
自尊需要——具有受人尊重/赏识的能力或/和业绩；
自我实现需要——成为自己期望的人物。
（3）人员激励的关键点
（4）人员自我激励
注意测试工作的7条效率原则：主动思考，积极行动；一开始就牢记目标，不迷失方向；重要的事情放在首位（但常常把紧急的事情放在首位）；先理解人，后被人理解；寻求双赢；互相合作，追求1+1>2；终生学习，自我更新，不断进步。
3、测试职业发展
4、人员的培训
（1）软件测试培训和内容分类
（2）制定测试人员培训计划
4.8软件风险分析
4.8.1软件测试与商业风险
软件公司的管理者制定整体软件开发战略时使用“计划—执行—检查—改进（PDCA）”循环理念，战略性的策略可以转为商业上的主动。
软件测试是一种用来尽可能降低软件风险的控制措施。
风险的定义为“伤害、损坏或损失的可能性：一种危险的可能或一种冒险事件。”
风险分析是一个对潜在问题识别和评估的过程，即对测试的对象进行优先级划分。
风险分析包括两个部分：
（1）发生的可能性——发生问题的可能性有多大；
（2）影响严重性——如果问题发生了会有什么后果。
通常风险分析采用两种方法：表格分析法和矩阵分析法。
4.9软件测试的成本管理
4.9.1测试费用有效性
“太少的测试是犯罪，而太多的测试是浪费。”对风险测试得过少，会造成软件的缺陷和系统的瘫痪；而对风险测试得过多，就会使本来没有缺陷的系统进行没有必要的测试，或者是对轻微缺陷的系统所花费的测试费用远远大于它们给系统造成的损失。
4.9.2测试成本控制
测试工作的主要目标是使测试产能最大化，也就是，要使通过测试找出错误的能力最大化，而检测次数最小化。测试实施成本组成部分包括：测试准备成本、测试执行成本和测试结束成本。
1、测试准备成本控制
测试准备成本控制的目标是使时间消耗总量、劳动力总量，尤其是准备工作所需的熟练劳动力总量最小化。准备工作一般包括：硬件配置、软件配置、测试环境建立，以及测试环境的确定等。
- 测试执行成本控制
测试执行成本控制的目标是使总执行时间和所需的测试专用设备尽可能地减少。
完全重新测试：
部分重新测试：
部分重新测试选择方法有两种：
（1）对由于程序变化而受到影响的每一部分进行重新测试；
（2）对与变化有密切和直接关系的部分进行重新测试。
3、测试结束成本控制
测试结束成本的控制是进行测试结果分析和测试报告编制、测试环境的清除与恢复原环境所需的成本，使所需的时间和熟练劳动力总量减少到最低限度。
4、降低测试实施成本
5、降低测试维护成本
4.9.3质量成本
1、质量成本要素
（1）一致性成本（Cost of Conformance）
一致性成本是指用于保证软件质量的支出，包括预防成本和测试预算，如测试计划、测试开发、测试实施费用。测试预算被称为审查费：
（2）非一致性成本（Cost of Conformance）
非一致成本是由出现的软件错误和测试过程故障（如延期、劣质的测试发布）引起的。这些问题会导致测试返工、补测、延迟。追加测试时间和资金就是一种由于内部故障引起的非一致成本。非一致成本还包括外部故障（软件遗留错误影响客户）引起部分。这些成本还包括技术支持小组预算，错误修正花费、产品收回、赔偿和销售成本。
4.9.4缺陷探测率（DDP）
（DDP Defect Detection Percentage）
缺陷探测率DDP是另一个衡量测试工作效率的软件质量成本的指标。
缺陷探测率是衡量测试投资回报的一个重要指标。
4.9.5测试投资回报举例
假设发现的错误为300个，测试过程的估算如下：
（1）单元测试阶段，软件开发人员发现及修改一个错误需要50元
（2）建立独立的测试进行集成和系统测试，开发人员修改后，测试人员再确认，一个错误需要300元
（3）在产品发布后，由客户发现，报告技术支持人员、相关开发人员修改，测试组再进行回归测试，一个错误需要2000元。
第一种情况：开发人员测试发现100个错误，而产品发布后客户发现错误200个，总成本405000元，缺陷探测率为33.3%
第二种情况：投资预算人员费用为60000元，测试环境使用费为8000元，测试投资（一致性成本）68000元；开发过程中开发人员修改100个错误外，测试过程中测试人员发现错误150个，而产品发布后客户发现50个错误。总质量成本下降到218000元，手工测试总质量成本节约了187000元，即为利润。
投资回报率（ROI）=节约的成本i-利润i/测试投资=405000-218000/68000*100%=275%
缺陷探测率（DDP）=(100+150)/(100+150+50)*100%=83.3%
第二篇 测试技术
第5章黑盒测试案例设计技术
5.1概述
黑盒测试中运用等价类划分、边界值分析、因果图法、判定表法、正交试验法、功能图法等测试用例设计方法的原理与实现，并从测试设计说明、测试用例说明、测试程序说明三个方面介绍如何编写测试用例。
5.2测试用例设计方法
5.2.1什么是测试用例
测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内，软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已修改完成。
所谓的测试用例设计就是将软件测试的行为活动，作一个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的，而设计软件测试的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。
使用测试用例的好处主要体现在以下几个方面：
（1）在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
（2）测试用例的使用令软件测试的实施重点突出、目的明确。
（3）在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
（4）功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断率升。
5.2.2等价类划分法
等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的要求和说明，即需求规格说明书。我们必须仔细分析和推敲说明书的各项需求，特别是功能需求。把说明中对输入的要求和输出的要求区别开来并加以分解。
等价类划分的方法是把程序的输入域分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。
等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的要求和说明，即需求规格说明书。我们必须仔细分析和推敲说明书的各项需求，特别是功能需求。
等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。
1、划分等价类和列出等价类表
等价类是指某个输入域的了集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试。
等价类划分有两种不同的情况：有效等价类和无效等价类。
有效等价类：指对程序的规格说明来说是合理的、有意义的输入数据结构的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
无效等价类：与有效等价类的定义恰巧相反。
（1）在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类。
（2）在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。
（3）在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
（4）在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
（5）在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
（6）在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。
2、确定测试用例
根据已列出的等价类表，按以下步骤确定测试用例：
（1）为每个等价类规定一个惟一的编号。
（2）设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖。
（3）设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。
5.2.3边界测试分析
1、边界分析
2、次边界条件
（3）其他一些边界条件
3、边界值的选择方法
对边界值设计测试用例，应遵循以下几条原则：
（1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
（2）如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、最大个数多1的数作为测试数据。
（3）根据规格说明的每个输出条件，使用前面的原则（1）。
（4）根据规格说明的每个输出条件，使用前面的原则（2）。
（5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
（6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。
（7）分析规格说明，找出其他可能的边界条件。
5.2.4错误推测法
错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误，有针对地设计测试用例的方法。
错误推测法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
5.2.5因果图法
1、因果图设计方法
因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。
利用因果图导出测试用例需要经过以下几个步骤：
（1）分析程序规格说明的描述中，哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价类，而结果是输出条件。
（2）分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
（3）标明约束条件。由于语法或环境的限制，并将其表示成连接各个原因与各个结果的“因果图”。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干个标准的符号标明约束条件。
（4）反因果法转换成判定表。
（5）为判定表中每一列表示的情况设计测试用例。
因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而增加。
5.2.6判定表驱动法
1、判定表组成
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
条件桩：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
动作桩：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
条件项：列出针对它所列条件的取值，在所有可能情况下的真假值。
动作项：列出在条件项的各种取值情况下应该采取的动作。
规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿也就有多少条规则，条件项和动作项就有多少列。
2、判定表建立
判定表的建立因该依据软件规格说明，步骤如下：
（1）确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故有2n种规则。
（2）列出所有的条件桩和动作桩。
（3）填入条件项。
（4）填入动作项。制定初始判定表。
（5）简化。合并相似规则或者相同动作。
Beizer指出了适合使用判定表设计测试用例的条件：
（1）规格说明以判定表的形式给出，或很容易转换成判定表。
（2）条件的排列顺序不影响执行哪些操作。
（3）规则的排列顺序不影响执行哪些操作。
（4）当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
（5）如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。
5.2.7正交试验法
- 正交试验设计方法
依据Galois理论，正交试验设计方法是从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试验设计方法。
简单对比法的最大优点就是试验次数少，例如：6因子5水平试验，在不重复时，只用5+(6-1)+(5-1)=25次试验就可以了。
2、正交试验测试用例设计步骤
利用正交试验设计测试用例的步骤如下：
提取功能说明，构造因子“——”状态表。把影响实验指标的条件称为因子，而影响实验因子的条件叫做因子的状态。
加权筛选，生成因素分析表。
利用正交表构造测试数据集，正交表的推导依据Galois理论。
5.2.8功能图法
1、功能图设计方法
功能图方法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。
测试用例生成规则：为了把状态迁移（测试路径）的测试用例与逻辑模型的测试用例组合起来，从功能图生成实用的测试用例，需定义下面的规则。一个结构化的状态迁移中，定义3种形式的循环：顺序、选择和重复。
5.2.9场景法
5.3.4测试程序说明
ANSI/IEEE829标准把测试程序定义为“明确指出为实现相关测试设计而执行具体测试用例和操作软件系统的全部步骤”。
第6章白盒测试技术
6.1白盒测试基本技术
6.1.1词法分析与语法分析
1、类型和单位分析
2、引用分析
3、表达式分析
对表达式进行分析，以发现和纠正在表达式中出现的错误。包括：
在表达式中不正确地使用了括号造成错误；
数组下标越界造成错误；
除数为零造成错误；
对负数开平方，或对π求正切造成错误。
4、接口分析
接口一致性是程序的静态错误分析和设计分析共同研究的题目。接口一致性的设计可以分析检查模块之间接口的一致性和模块与外部数据库之间接口的一致性。
程序关于接口的静态错误分析检查过程与实参在类型、函数过程之间接口的一致性，因此要检查形参与实参在类型、数量、维数、顺序、使用上的一致性；检查全局变量和公共数据区在使用上一致性。
6.1.3程序插桩技术
在软件动态测试中，程序插桩（Program Instrumentation）是一种基本的测试手段，有着广泛的应用。
Fortran程序为例，列举至少应该在哪些部位设置计数语句：
程序块的第一个可执行语句之前；
entry语句的前后；
有标号的可执行语句处；
do、do while、do until及do终端语句之后；
block-if、else if、else及endif语句之后；
logical if 语句处；
输入/输出语句之后；
call语句之后；
计算go to语句之后；
2、断言语句
6.2白盒测试方法
6.2.1代码检查法
代码检查包括桌面检查、代码审查和走查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等方面；发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。
6.2.4逻辑覆盖法
白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：
保证一个模块中的所有独立路径至少被使用一次；
对所有逻辑值均需测试true和false；
在上下边界及可操作范围内运行所有循环；
检查内部数据结构以确保其有效性；
逻辑覆盖是通对程序逻辑结构的遍历实现程序的覆盖。它是一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖（SC）、判定覆盖（DC）、条件覆盖（CC）、条件判定组合覆盖（CDC）、多条件覆盖（MCC）和修正判定条件覆盖（MCDC）。
1、语句覆盖（SC）
为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此，语句覆盖（Statement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。
因此一般认为语句覆盖是很弱的逻辑覆盖。
2、判定覆盖（DC）
比语句覆盖稍强的覆盖标准是判定覆盖（Decision Coverage）。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
3、条假覆盖（CC）
在设计程序中，一个判定语句是由多个条件组合而成的复合制定。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
4、条件判定组合覆盖（CDC）
条件判定组合覆盖的含义是：设计足够的测试用例，使得判定中每个条件的所有可以（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。
5、多条件覆盖（MCC）
多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
6、修正条件判定覆盖（MCDC）
它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的bool连接，每个条件对于判定的结果值是独立的。
6.2.5基本路径测试法
基本路径测试法步骤：
基本路径测试法适用于模块的详细设计及源程序，其主要步骤如下：
以详细设计或源代码作为基础，导出程序的控制流图；
计算得到的控制流图G的环路复杂性V（G）；
确定线性无关的路径的基本集；
生成测试用例，确保基本路径集中每条路径的执行。
6.2.6其他白盒测试方法
1、域测试
域测试（Domain Testing）是一种基于程序结构的测试方法。Howden曾对程序中出现的错误进行分类，他将程序错误分为域错误、计算型错误和丢失路径错误三种，这是相对于执行程序的路径来说的。
2、符号测试
符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，这一方法也是因此而得名的。
3、Z路径覆盖
4、程序变异
6.3.1最少测试用例数计算
6.3.2测试覆盖准则
第7章面向对象的软件测试技术
7.2面向对象技术
7.2.1对象和类
如果说传统的过程式编语言是以过程为中心，以算法为驱动的话，那么面向对象的编程语言则是以对象为中心，以消息为驱动的。用公式表示，过程式编程语言为：程序=算法+数据；面向对象编程语言为：程序对象+消息。
7.2.2封闭、继承和多态性
封闭是将数据和操作数据的函数衔接在一起，构成的一个具有类类型的对象的描述。封装要求一个对象应具备明确的功能，并且有一个或几个接口以便和其他对象相互作用。
继承即可以从一个类派生另一个类。派生类（也称子类）继承了其父类和祖先类的数据成员和成员函数。派生类可增加新的属性和新的操作。
多态性就是多种表现形式，具体来说，可以用“一个对外接口的，多个内在实现方法”表示。多态性的实现，一般通过在派生类中重定义基类的虚函数来实现。
| OOA Test：面向对象分析的测试 | OOD Test：面向对象设计的测试 |
| OOP Test：面向对象编程的测试 | OO Unit Test：面向对象单元测试 |
| OO Integrate Test：面向对象集成测试 | OO System Test：面向对象确认和系统测试 |
7.4面向对象软件的测试策略
7.4.1面向对象分析（OOA）的测试
对OOA阶段的测试划分为以下五个方面：
对认定的对象的测试；
对认定的结构的测试；
对认定的主题的测试；
对定义的属性和实例关联的测试；
属性是用来描述对象或结构所反映的实例的特性。而实例关联是反映实例集合间的映射关系。
对定义的服务和消息关联的测试；
7.4.2面向对象设计（OOD）的测试
结构化的设计方法：是面向作业的设计方法，它把系统分解以后，提出一组作业，这些作业是以过程实现系统的基础构造，把问题的分析转化为求解域的设计，分析结果是设计阶段的输入。
面向对象设计（OOD）采用“造型的观点”，以OOA为基础归纳出类，并建立类结构或进一步构造成类库，以实现分析结果对问题空间的抽象。
7.4.3面向对象编程（OOP）的测试
主要体现为以下两个方面（假设编程使用C++语言）
数据成员是否满足数据封装的要求。
类是否实现了要求的功能。
1、数据成员是否满足数据封装的要求
数据封装是数据和数据有关的操作的集合。检查数据成员是否满足数据封装的要求，基本原则是数据成员是否被外界（数据成员所属的类或子类以外的调用）直接调用。更直观地说，当改变数据成员的结构时，是否影响了类的对外接口，是否会导致相应的外界必须改动。值得注意的是，有时强制的类型转换会破坏数据的封装特性。
2、类是否实现了要求的功能
类所实现的功能都是通过类的成员函数执行的。在测试类的功能实现时，应该首先保证类成员函数的正确性。
7.4.4面向对象软件的单元测试
用于单元级测试的测试分析（提出相应的测试要求）和测试用例（选择适当的输入，达到测试要求），规模和难度等均远小于整个系统的测试分析和测试用例，而且强调对语句应该有100%的执行代码覆盖率。在设计测试用例选择输入数据时，可以基于以下两个假设：
如果函数（程序）对某一类输入中的一个数据正确执行，对同类中的其他输入也能正确执行。
如果函数（程序）对某一复杂度的输入正确执行，对更高复杂度的输入也能正确执行。
对父类中已经测试过的成员函数，有两种情况需要在子类中重新测试：
（1）继承的成员函数在子类中做了改动；（2）成员函数调用了改动过的成员函数的部分。
7.4.5面向对象软件的集成测试
具体设计测试用例，可参考下列步骤：
（1）先选定检测的类，参考OOD分析结果，仔细确定出类的状态和相应的行为，类或成员函数间传递的消息，输入或输出的界定等。
（2）确定覆盖标准。
（3）利用结构关系图确定待测类的所有关联。
（4）根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态，使用类的服务和期望产生什么行为等。
面向对象软件测试用例设计
（1）列出所要测试的对象的专门说明；
（2）列出将要作为测试结果运行的消息和操作
（3）列出测试对象可能发生的例外情况；
（4）列出外部条件（即为了正确对软件进行测试所必须有的外部环境的变化）。
（5）列出为了帮助理解和实现测试所需要的附加信息。
第8章应用负载压力测试
8.1负载压力测试概述
8.1.1负载压力基础概念
系统的负载压力是指系统在某种指定软件、硬件以及网络环境下承受的流量，例如并发用户数、持续运行时间、数据量等，其中并发用户数是负载压力的重要体现。当有大量用户同时使用时，可能会出现功能失效、性能衰减、甚至系统崩溃的现象。
8.1.2负载压力测试基础概念
负载压力测试是指在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的最大负载压力。
负载压力测试有助于确认被测系统是否能够支持性能需求，以及预期的负载增长等。负载压力测试不只是关注不同负载场景下的响应时间等指标，它也要通过测试来发现在不同负载场景下会出现的。
负载压力测试是性能测试的重要组成部分，负载压力测试包括并发性测试、疲劳强度测、大数据量测试等内容。
1、性能测试
2、性能评测
性能评测主要内容包括以下两项内容：
在真实环境下，检查系统服务等级的满足情况，评估并报告整个系统的性能。
对系统的未来容量作出预测和规划。
性能评测是性能调优的基础。
3、性能调优
性能调优的步骤如下：
查找形成系统瓶颈或者故障的根本原因；
进行性能调整和优化；
评估性能调整和效果；
在通常情况下，性能调优的过程是上述步骤循环执行的过程，以实现目标。
4、负载测试
负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
5、压力测试
压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试。
通俗地讲，压力测试是为了发现在什么条件下系统的性能变得不可接受。
压力测试是一种特定类型的负载测试。例如，访问一个页面的响应时间规定为不超过1秒，负载测试就是测试在响应时间为1秒时，系统所能承受的最大并发访问用户的数量，而压力测试就是测试系统在多大的并发访问用户数量下，响应时间不可接受，例如超过1分钟（定义为失效状态）。
6、并发性能测试
并发性能测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。
一个完整解决方案的角度考虑，并发性能测试概括为以下3类：
应用在客户端性能的测试；
应用在网络上性能的测试；
应用在服务器上性能的测试。
7、疲劳强度测试
通常是采用系统稳定运行情况下能够支持的最大并发用户数，或者日常运行用户数，持续执行一段时间业务，保证达到系统疲劳强度需求的业务量，通过综合分析交易执行指标和资源监控指标，来确定系统处理最大工作量强度性能的过程。一般情况下利用疲劳强度测试来模拟系统日常业务操作。
8、大数据量测试
分为两类：
独立的数据量测试指针对某些系统存储、传输、统计、查询等业务进行大数据量测试。
综合数据量测试指和压力性能测试、负载性能测试、疲劳性能测试相结合的综合测试。
8.1.3负载压力测试目的
负载压力测试的目的可以概括为以下几个方面：
在真实环境下检测系统性能，评估系统性能以及服务等级的满足情况。
预见系统负载压力承受力，在应用实际部署之前，评估系统性能。
分析系统瓶颈、优化系统。
测试工程师的建议是，调优的最终目的是各个指标的调整取得系统的平衡点，也即达到了系统性能的最佳点。
负载压力测试将为企业项目的实施提供信心，帮助用户正确地进行容量规划，实现软硬件投资合理化，最终交付高质量的系统，避免项目投产失败，保证用户的投资得到相应的回报。
8.1.4负载压力测试策略
利用商业化测试工具进行测试。
比如：LoadRunner、QALoad等
开发资源测试工具进行测试。
OPenSTA OpenSTA Users Home Page - Free Web Load and Stress Testing Tool
TestMaker http://www.pushtotest.com
Apache JMeter Apache JMeter - Apache JMeter™
8.1.5产品生命周期中负载压力测试计划
（1）在需求分析中充分关注负载压力性能
（2）从设计中得到负载压力性能指标
（3）开发阶段创建一个负载压力性能测试环境
（4）验收阶段在多等级范围内测试并调优
（5）运行阶段持续监控系统负载压力性能
8.1.6负载压力测试中的盲点
8.2负载压力测试解决方案
8.2.1并发性能测试
系统的并发性能是负载压力性能的最主要的组成部分，首先我们来讨论什么是“并发”。对一个系统来讲，某些业务操作对特定角色用户来讲存在很大的同时操作的可能性。
1、应用在客户端性能的测试
在客户端模拟大量并发用户执行不同业务操作，达到实施负载压力的目的。
采用负载压力测试工具来模拟大量并发用户，模拟机制如图8-2所示，主要组成部分包括主控台、代理机以及被测服务器，各部分采用网络连接。主控台负载管理各个代理以及收集各代理测试数据，代理负责模拟虚拟用户加压。在每次并发性能测试中，只有一台主控台，但可以有多个代理。
以LoadRunner负载压力测试工具为例，看看工具是如何实现的。
要模拟真实的负载压力做测试，必须创建方案，方案是用以模拟现实生活中用户的方式。方案包含有关如何模拟实际用户的信息：虚拟用户（Vuser）组、Vuser将运行的测试脚本，以及用于运行脚本的负载生成器计算机。
如果选择创建常规手动方案，则会将选择的每个脚本分配给Vuser组。然后，可以为每个Vuser组分配多个Vuser。可以指示某个组中的所有Vuser在同一台负载生成器计算机上运行相同的脚本，以也可为组中的各个Vuser分配不同的脚本和负载生成器。使用百分比模式创建手动方案，可以定义方案中要使用的Vuser总数，并为每个脚本分配负载生成器和占总数一定百分比的Vuser。
在一个面向目标的方案中，可定义五种类型的目标：虚拟用户数、每秒点击次数（仅Web Vuser）、每秒事务数、每分钟页面数（仅Web Vuser）或事务响应时间。
虚拟用户目标类型：测试应用程序可以同时运行多少个Vuser。
每秒点击次数、每分钟页面数或每秒事务数：测试服务器的稳定性。需要指定LoadRunner运行的Vuser范围（最大值、最小值），以及每秒事务数目标类型的“事务名称”。Controller（测试工具的主控台）将尽量使用最少数量的Vuser来达到定义的目标。如果使用最小Vuser数不能达到该目标，则Controller将逐渐增加Vuser数，直到达到所定义的最大数。如果使用指定的最大Vuser数仍不能达到指定的目标，Controller将增加Vuser数，并再次执行方案。
LoadRunner将根据定义的目标自动创建一个方案。在一个面向目标的方案中，可以定义五种类型的目标：
虚拟用户目标类型：测试应用程序可以同时运行多少个Vuser。
每秒点击次数、每分钟页面数或每秒事务数：测试服务器的稳定性。
事务响应时间目标类型：测试在期望的事务响应时间内可以同时运行多少个Vuser，在脚本中指定想要测试的事务的名称以及LoadRunner要运行的Vuser数量范围（最大值、最小值）。
2、应用在网络上性能的测试
这部分主要包括两部分内容，一是应用网络故障分析；二是网络应用性能监控。
应用网络故障分析的测试目标是显示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。通过测试，我们可以做到下面几点。
（1）优化性能；
（2）预测系统响应时间；
（3）确定网络带宽需求；
（4）定位应用程序和网络故障。
借助于网络故障分析工具，可以解决下列问题。
（1）使应用跨越多个网段的活动过程变得清晰；
（2）提供有关应用效率的统计数据；
（3）模拟最终用户在不同网络配置环境下的响应时间，决定应用投产的网络环境。
网络故障分析工具的工作机理，可以总结为“多个捕捉点，一个分析”。捕捉点即“Agent”，利用主控台“Agent Manager”进行分析，Agent被动监听数据包来实现实时数据采集，Agent Manager完成对所跟踪到的数据的分析，可以自由地捕捉代理放在不同的平台，例如，Windows或UNIX。如图8-3所示的主控台为Management Console，捕捉点为代理探针Probe。
如图8-4所示是一个典型的web架构应用部署图，我们可以在应用逻辑路径上进行多点数据采集，并且在任何两个节点间进行数据整合，测量分段的响应时间，分析应用故障。
3、应用在服务器上性能的测试
8.2.2疲劳强度测试
1、日常业务疲劳强度模拟
2、高峰业务疲劳强度模拟
8.2.3大数据量测试
1、大数据量测试类型
（1）独立数据量测试
（2）综合数据量测试
2、自动生成大数据量
3、大数据量管理
8.3负载压力测试指标
8.3.1交易处理性能指标
并发用户数指标
交易处理指标
（1）平均事务响应时间。
（2）每秒事务数。
（3）每秒事务总数。
（4）事务摘要。
（5）事务性能摘要。
（6）事务响应时间（负载下）
（7）事务响应时间（百分比）
（8）事务响应时间（分布）。
web请求指标
（1）每秒点击次数。
（2）点击次数摘要。
（3）吞吐量
（4）吞吐量摘要。
（5）HTTP状态代码摘要。
（6）每秒HTTP响应数。
（7）每秒下载页面数。
（8）每秒重试次数。
（9）重试次数摘要。
（10）连接数。
（11）每秒连接数。
（12）每秒SSL连接数。
web页面组件指标
（1）激活网页细分。
（2）页面组件细分。
（3）页面组件细分（随时间变化）
（4）页面下载时间细分
（5）页面下载时间细分（随时时间变化）
（6）第一次缓冲细分时间
（7）第一次缓冲时间细分（随时间变化）
（8）已下载组件大小。
8.4负载压力测试实施
8.4.2测试计划
1、分析应用程序
（1）确定系统组件
（2）描述系统配置
（3）分析使用模型
2、定义测试目标
（1）以可度量的指标制定目标
（2）确定测试的时间
3、计划方案实施
（1）定义性能度量的范围
（2）定义Vuser活动
（3）选择Vuser
（4）选择测试硬件和软件
8.4.3测试需要分析
1、测试需求内容
2、负载压力测试需求分析原理
3、需要分析方法
4、测试数据准备
5、自己动手编写测试工具
8.4.11结果评估与测试报告
1、交易处理性能评估
交易处理性能评估指标主要包括：
并发用户数。
一类是系统最佳性能的并发用户数，另一类是系统能够承受的最大并发用户数。
交易响应时间
该指标描述交易执行的快慢程度，这是用户最直接感受到的系统性能，也是故障定位迫切需要解决的问题。
交易通过率
指每秒钟能够成功执行的交易数。
吞吐量
指每秒通过的字节数，以及通过的总字节数。
点击率
描述系统响应请求的快慢。
2、资源占用性能评估
资源占用主要涉及服务器操作系统资源占用、数据库资源占用、中间件资源占用等内容，下面分别论述。
（1）服务器操作系统资源占用
将服务器操作系统资源占用监控指标概括为以下几个方面：
1）CPU
2）磁盘管理
3）内存
4）交换区SWAP
5）进程
6）安全控制
7）文件系统
（2）数据库资源占用监控指标包括
读写页面的使用情况
超出共享内存缓冲区的操作数
上一轮询期间作业等待缓冲区的时间。
共享内存中物理日志和逻辑日志的缓冲区的使用率
磁盘的数据块使用情况以及被频繁读写的热点区域。
用户事务或者表空间事务
数据库锁资源。
关键业务的数据表的表空间增长。
SQL执行情况
（3）中间控件资源占用监控
中间件主要包括：
Web中间件
应用中间件
交易中间件
其他中间件
3、故障分析
（1）故障分析重点内容
1）CPU问题
2）内存和高速缓存
3）磁盘（I/O）资源问题
4）配置参数
5）应用系统网络设置
6）数据库服务器故障定位
4、负载压力典型问题分析
非正确执行的处理
速度瓶颈与延迟
不能达到满意服务水平
接口页面不能正确地装载或者根本不能转载。
5、Web网站故障分析举例
数据库服务器性能问题及原因分析
（1）单一类型事务响应时间过长
1）数据库服务器负载过重
2）糟糕的数据库设计
3）事务粒度过大
4）批任务对普通用户性能的影响
（2）并发处理能力差
（3）锁冲突严重
（4）监视并记录性能相关数据
（5）定位资源占用较大的事务并做出必要的优化或调整
（6）定位锁冲突，修改锁冲突发生严重的应用逻辑
（7）进行必要的数据分布。
第9章Web应用测试
9.1Web系统测试概述
Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web系统。
9.1.1Web系统的构成
Web工程，它使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于web的系统。
这里谈到的web系统是指以Browser/Server的访问方式为主，包含客户端浏览器、web应用服务器、数据库服务器的软件系统。首先从技术实现上来讲，一般的B/S结构都是多层构架，有界面层、业务逻辑层、数据层。从结构上来讲，都有客户端部分、传输网络部分和服务器端部分。
一个典型的web系统的结构示意图如上图。
访问客户端：包含用户操作的浏览器及运行平台。最常见的一个例子就是Windows XP+IE6.0，另外，还有Windows及其他平台上的Netscape、Opera、Mozilla等浏览器。
Web应用服务器：用于发布web页面，接受来自客户端的请求，并把请求的处理结果返回客户端。一般采用的Web应用服务程序有各种版本Unix上的apache、weblogic；windows下tomcat、IIS等。
数据库：虽然数据库不是web系统一个必要的部分，但在现有的大多数Web系统中，数据库是一个重要的部分。数据库多为关系型数据库，常用的有Oracle、SQLServer、Sybase、Informix等。
网络及中间件：提供客户端的请求到web服务器的通道。网络可以是Internet/Intranet/Extranet网，也可能是局域网。中间件常常是传输中间件或交易中间件。
防火墙与CA认证：系统的安全性的一个保障系统，对于重要的系统是必不可少的。
9.1.2Web系统设计技术
1、静态页面与动态页面
全部使用HTML语言设计网页，保存在与Internet相连接的计算机内，任何连入互联网的用户都可以访问其中的信息，这种形式页面称作静态页面。
为实现个性化搜索、收发电邮、网上销售、电子商务等功能。必须使用更新的网络编程技术制作动态网页。所谓动态：指的是按照访问者的不同需要，对访问者输入的信息作出不同的响应的信息。
2、网络开发技术
网络开发技术一般指采用脚本语言进行编程的技术。
脚本语言具有和传统的编程语言相似的语法结构和风格，并且可以结合HTML语言共同使用。脚本语言与HTML语言具有非常好的兼容性，使用者可以直接在脚本代码中加入HTML标签，或者在HTML标签中加入脚本代码从而更好地实现页面控制。
使用不同技术编写的动态页面也被保存在Web服务器内。当客户端用户向Web服务器发出访问动态页面的请求时，Web服务器将根据用户所访问页面的后缀名确定该页面所使用的网络编程技术，然后把该页面提交给相应的解释引擎；解释引擎扫描整个页面找到特定的定界符，并执行位于定界符内的脚本代码以实现不同的功能，如访问数据库，发送电子邮件，执行算术或逻辑运算等，最后把执行结果返回Web服务器；最终，Web服务器把解释引擎的执行结果连同页面上的HTML内容以及各种客户端脚本一同传送到客户端。
ASP（Active Server Pages即动态服务器页面）asp实际上应当是一种脚本语言的服务端编写环境。Asp的核心技术是对组件和对象技术的充分支持。Asp的核心技术是对组件和对象技术的充分支持。通过使用asp的组件和对象技术，用户可以直接使用ActiveX控件，调用对象方法和属性。
JSP（Java Server Pages）是基于Java Servlet以及整个Java体系的web开发技术。符合“一次编写，多平台运行”的Java标准，实现平台和服务器的独立性，而且基于Jsp技术的应用程序，比基于asp的应用程序易于维护和管理。
ColdFusion采用一种被称做ColdFusion标识语言（CFML）的技术。
文字分析报告语言（PERL），是现在编写CGI程序最受欢迎的编程工具，它具有强大的字符串处理能力，特别适合用于分割处理客户端Form提交的数据串，而且可以与ColdFusion等多种流行的Web数据库处理软件相结合。使用perl既可以达到跨服务平台，又能方便地处理和使用数据库，还有perl是一种由解释器直接解释执行的语言。
超文本处理器（PHP）综合perl、java和C语言的精华，它是一种自由软件。
3、CGI（通用网关接口）程序
CGI程序与Web服务器的交互主要有两种数据交换方式。
在Unix或Linux下，是通过标准输入/输出来实现的，因此可以在程序中直接通过标准输入来取得客户端传来的请求和所传递的数据，然后在程序中对数据进行处理。
在windows平台下，CGI程序与web服务器的数据交互则是通过profile文件来进行的，profile的格式如同win.ini的格式一样。当web服务器接收到客户端的请求数据后，就把它们以key-value的ini文件格式保存至暂存文件以供CGI程序来接收。
4、J2EE
J2EE的全称是Java2EnterpriseEdition，J2EE是专门为企业应用制定的标准，企业可以用它来编制企业级的应用，它为企业应用提供了数据库存取，交易完整性，可靠消息传递等功能。
现在主流的一些J2EE应用服务器都可以支持企业应用所需的稳定性、可用性、安全性、可靠性、可扩展性等。
5、.NET
.Net以WebServices为核心，全面支持SOAP、UDDI和WSDL，并在底层实现了类似Java虚拟机的CLR（Common Language Runtime）和一套具有3500多个类的.net基础类库，以支持其开发语言VB、C#等，并在后端支持数据库SQLServer和Passport，.NET Studio组成了完整的解决方案。
6、WebServices
它是建立可互操作的分布操作应用程序的新平台。Web services是一场分布式计算模式的跃进，它真正要解决分布式计算的问题。WebServices技术成为企业与企业之间连接的桥梁，为跨企业、跨行业、跨地域的业务提供了技术的实现方法。
Web Services采用XML作为消息交换的格式，利用Internet上的通用传输协议（如http），提供标准的服务接口调用的方法，为客户提供灵活、方便、强大的web服务。
Web应用系统的设计、编码和实施三个阶段都是十分重要，现把对Web应用系统的测试分为Web应用设计测试、Web应用开发测试和Web应用运行测试。
9.1.3web系统的测试策略
按系统架构来分，可分为客户端的测试、服务器端的测试和网络上的测试；
按职能来分，可分为应用功能的测试、web应用服务的测试、安全系统的测试、数据库服务的测试；
按软件的质量特性来分，又可分为功能测试、性能测试、安全性测试、兼容性测试和易用性测试；
按照开发阶段来分，可分为设计的测试、编码的测试和系统的测试。
把web应用系统的测试分为web应用设计测试、web应用开发测试和web应用运行测试。
9.2web应用设计测试
依据web应用系统的架构，把对web设计的测试分为总体架构设计的测试、客户端设计的测试、服务器端设计的测试三个部分。
9.2.2总体架构设计的测试
1、采用瘦客户端或胖客户端是否适合需求
多数web新闻站点、门户网站及用于信息发布的web系统采用这种模式。这种模式适合于客户端没有特殊要求、用户量庞大并且分散的web应用系统。
胖客户端既运行应用程序的用户界面，又执行部分业务逻辑。银行客户系统、网络游戏、网上办公系统等web应用系统这种模式。适合于对安全性要求较高、交互操作频繁或业务逻辑复杂的web应用系统。
测试的任务就是验证设计中采用的模式是否符合系统需求。
2、确定web架构的组成部分是否满足需求
服务器端可能是简单的web应用服务器，也可能是中间件、数据库和安全服务器等组成的服务器群。在确定服务器端的组成部分时，需要考虑到成本、功能、安全性、容量要求、传输实时性等多个方面。对web架构设计的测试除了要验证web架构的组成部分是否满足上述需求外，还要检查各组成部分是否有搭配不兼容的地方。
3、服务器的配置及分布是否满足需求
服务器软件可能分布在若干个物理服务器单元上。
重点验证服务器端的配置和分布是否满足用户的功能、性能、成本等需求。
9.2.3客户端设计的测试
客户端设计主要是面向用户的，包括功能设置、信息组织结构设计和页面设计。对客户端设计的测试也将从这三方面进行。
1、功能设置的测试
（1）信息服务
（2）办公自动化
（3）Internet支持
2、信息组织结构设计的测试
信息组织结构设计主要有线性结构设计、分层结构设计和非线性结构设计三种。
3、页面设计的测试
对页面设计的测试可从以下几个方面进行：
页面的一致性如何；
在每个页面上是否设计友好的用户界面和直观的导航系统；
是否考虑多种浏览器的需要；
是否建立了页面文件的命名体系；
是否充分考虑了合适的页面布局技术，如层叠式表、表格和结构等。
9.2.4服务器端的设计的测试
1、容量规划的测试
大多数进程被划分为两类：输入输出限制（I/O-bound）和CPU限制（CPU-bound）用于静态HTML的常常是I/O-bound，从硬盘检索文件的速度受到速率的限制，同时文件从网络接口移出时受到该速度的限制。动态HTML它常常是CPU-bound的，也就是说它用于产生页面的时间要比将页面移出网络接口的时间要长。依赖于数据库查询的动态内容常常受到数据库速度的限制，数据库又通常是I/O-bound的，因为它需要从硬盘上检索数据。
进行容量规划是非常必要和重要的，它和web应用系统的性能是息息相关的。对容量规划的测试也非常必要，评价容量规划设计的关键在于：将所要求的延迟和带宽与该体系结构中每一个环节的定额容量作一比较，每个组成部分都必须满足这些要求，其中还必须要考虑到系统各部分之间可能产生的内耗，以及对该体系的生命周期可能增加的负载。对容量规划的测试方法是，检查容量规划是否满足用户的需求，可以从以下几个方面进行检查。估算点击率是否满足需求。
点击率就是每秒HTTP的请求数，也叫每秒被访问的次数。对点击率的估算采用8020原理和UCML方法。
- 估算延迟的流量是否满足需求。
点击率就是每秒HTTP的请求数，也叫每秒被访问的次数。
- 估算web应用系统所需服务器的资源消耗。
服务器的内存是需要重点考虑，经常是性能瓶颈所在。当内存不足时，有的进程会转移到硬盘上去运行，造成性能急剧下降。估算所需的内存需要考虑几个方面：操作系统所需内存、web高速缓存所需内存、CGI所需内存等。
2、安全系统设计的测试
安全是贯穿web应用系统设计、运行、管理等全过程的一个非常重要的因素，需要从多方面考虑，才能制定出一个较为完善的安全策略，保证web应用安全运行。一般从以下几个方面进行审核和评估：
（1）常识性安全策略；
（2）使用加密技术；
（3）构造防火墙；
（4）构建网络防毒体系。
3、数据库设计的测试
9.3Web应用开发测试
9.3.1Web应用开发测试概述
9.3.2代码测试
对web应用系统的代码测试主要包括以下几个方面：
1、源代码规则分析
主要方法是使用基于规则检查的工具，读取输入的源代码，然后将源代码与编码标准或语言规则相对照，以找出存在于两者之间的不一致性，或者存在于源代码当中潜在错误。
2、链接测试
链接测试可分为三个方面。
首先，测试所有链接是否按指示的那样确实链接到该链接的页面；
其次，测试所链接的页面是否存在；
最后，保证web应用系统上没有孤立的页面。
3、框架测试
主要检查以下几个方面：
是否可随浏览窗口的变化自动调整大小；
在当前窗口不能完全显示内容时是否提供滚动条功能；
能否在正确的目标框架中打开新页面。
4、表格测试
主要检查表格能否随浏览器窗口的变化或页面的变化自动调整大小。
5、图形测试（Graphics）
9.3.3组件测试
所谓web组件是指这样一个软件单元：它被用于web系统中，通常嵌入页面中，有些组件为完成一个特定的功能而存在于web页面中或服务器上，用户的使用请求可以通过浏览器的解释传递给组件，组件执行的结果经浏览器传递给用户。
1、表单（Forms）测试
2、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或存储登录等信息。
3、脚本测试
4、CGI测试
5、ASP测试
ASP实际上一种含有脚本命令的文本文件，在测试ASP时需要注意以下几个方面：
注意浏览器的缓存问题。缓存设置有时会影响到某些ASP的执行。
正确设置超时。超时会导致一些ASP页面失效，从而不能正确执行。
一些ASP的性能测试非常必要，如非常频繁的数据库查询等。
6、ActiveX控件测试
ActiveX控件是客户端技术，实际上类似于win32程序中的OCX控件，也是一种很常用的控件，在很多web系统设计中都会用到。注意以下几个方面：
ActiveX只能用于Windows客户端；
ActiveX应用是编译后的应用，在用户浏览时需要下载到客户端运行，客户端的安全设置可能会影响到ActiveX控制的使用。
由于用户有权拒绝使用ActiveX控件，若控件没有下载，web系统的功能受影响的程度。
要专门进行ActiveX控件的安装与测试，考察安装与卸载过程是否能顺利进行。
测试之前需要确认测试环境中没有旧版本的控件，若有，一定要卸载后进行重新安装测试。
9.3.4使用Junit 进行单元测试
1、单元测试的编写原则
在进行Junit单元测试框架的设计时，设定了如下三个总体目标：
（1）简化测试框架的编写，这种简化包括测试框架的学习和实际测试单元的编写；
（2）使测试单元保持持久性；
（3）可以利用已有的框架来编写相关的框架。
2、如何确定单元测试
3、如何编写单元测试
4、如何维护单元测试
9.4Web应用运行测试
9.4.1Web应用运行测试概述
相同之处体现在下面几个方面。
测试内容基本相同：
某些项目的测试方法基本相同：
测试手段基本相同：
9.4.2功能测试
考虑到Web应用本身的特点，其功能测试还要注意以下几个方面。
客户端的选择。
客户端浏览器的配置。
客户端显示设置。
内容测试。
Web应用功能测试的自动化技术，一个是web应用链接质量保证技术，另一个是Web应用功能测试技术。
1、Web应用链接质量保证技术
要保证每个链接的质量，需要做好三件事情：
（1）该链接将用户带到它所说明的地方；
（2）被链接页面是存在的；
（3）保证Web应用系统上没有孤立的页面。
2、Web应用功能测试技术
主要步骤包括：创建测试脚本、插入检查点、运行测试以及分析结果。
9.4.3易用性测试
要评估一个Web系统是否易用，首先要分析最终用户的情况。用户的情况决定了Web系统在易用性方面需要花费多少时间，以及易用性设计的方向。从用户角度讲，我们主要考虑以下几个方面的情况。
用户的计算机使用经验；
用户对浏览器以及Web的使用经验；
用户的业务专业知识。
确定了最终用户使用的基础情况，我们就可以有针对性地测试一个web系统的易用性了。我们把Web系统的易用性测试分为三个方面进行测试：
界面测试；
在开始进行界面测试之前，我们需要重点调研两个问题：
Web应用系统的最终用户群是谁；
Web应用界面的设计策略是什么。
（1）页面中各元素布局的协调性；
（2）不同页面风格的统一性；
（3）用户在界面中操作的便利性；
（4）界面动态操作测试；主要测试方面：
1）屏幕分辨率设置的影响；
2）浏览窗口最大化/最小化的影响；
3）选定目标元素的置中与缩放。
辅助功能测试；
（1）使用说明。
（2）导航。
（3）站点地图。
（4）帮助。
图形测试。
9.4.4负载压力测试
Web系统的性能包含哪些方面呢？
客户端向服务器发出一个请求；
服务器分配请求并进行处理。
服务器把处理的结果反馈给客户端。
客户端对结果进行分析，显示出来或进一步执行。
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线处理的数据量。负载测试应该安排在Web系统发布之后，在实际的网络环境中进行测试。
一般压力测试包含如下步骤：
确定交易执行响应时间。
估计Web系统能够承受的最大并发用户数量。
模拟用户请求，以一个比较小的负载开始，逐渐增加模拟用户的数量，直到系统不能承受负载为止。
如果负载没有达到需求，那么应该优化这个Web程序。
9.4.5客户端配置与兼容性测试
1、配置测试与兼容性测试概述
面向用户的配置测试与兼容性测试可分为三个方面：
（1）浏览器的配置测试；
（2）平台兼容性测试；
（3）浏览器兼容性测试。
9.4.6安全性测试
一个完整的Web安全体系测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密、参数操作、异常管理、审核和日志记录等几个方面入手。
1、安全体系测试
（1）部署与基础结构
网络是否提供了安全的通信。
部署拓扑结构是否包括内部防火墙。
部署拓扑结构中是否包括远程应用程序服务器。
基础结构安全性要求的限制是什么。
目标环境支持怎样的信任级别。
（2）输入验证
如何验证输入
测试时应考虑下列问题，帮助识别潜在的漏洞。
是否清楚入口点；
是否清楚信任边界；
是否验证Web页输入
是否对传递到组件或Web服务的参数进行验证。
是否验证从数据库中检索的数据。
是否将方法集中起来。
是否依赖客户端的验证。
如何处理输入
1、应用程序是否易规范化问题的影响。
2、应用程序是否易受SQL注入攻击。
3、应用程序是否易受XSS攻击。
（3）身份验证
测试中需要考虑下列问题，确定在应用程序进行身份验证 的方法中的潜在漏洞。
是否区分公共访问和受限访问。
1、设计是否要求特权最少的账户。
2、应用程序是否要维护服务账户凭据。
如何验证调用者身份。
如何验证数据库的身份。
是否强制使用强账户管理措施。
如何向最终用户授权。
如何在数据库中授权应用程序。
如何将访问限定于系统级资源。
是否支持远程管理。
是否保证配置存储的安全。
是否隔离管理员特权。
测试中要考虑下列问题，帮助验证应用程序处理敏感数据的方法。
是否存储机密信息。
如何存储敏感数据。
是否在网络中传递敏感数据。
是否记录敏感数据。
（4）授权
（5）配置管理
（6）敏感数据
（7）会话管理
（8）加密
（9）参数操作
（10）异常管理
（11）审核和日志记录
检查应用程序的审核和日志记录方法。
2、应用及传输安全
Web应用系统的安全性从使用的角度可分为应用级的安全与传输级的安全，安全性测试也可从这两个方面入手。
应用级的安全测试的主要目的是查找Web应用系统自身程序设计中存在的安全隐患，主要测试区域如下：
注册与登录；
在线超时；
操作留痕；
备份与恢复。
传输级的安全测试是考虑到Web系统的传输的特殊性，重点测试数据经客户端传送到服务器可能存在的安全漏洞，以及服务器防范非法访问的能力。一般测试项目包括以下几个方面：
HTTPS和SSL测试；
服务器端的脚本漏洞检验；
防火墙测试。
第10章网络测试
10.1网络测试概述
10.1.1网络测试发展
1、网络测试的对象从网络层向应用层过渡
测试的目的就是要确保网络能够承载各种各样的应用。网络上加载不同应用的情况进行测试。
2、测试重点将逐渐转向可靠性测试
3、网络的安全性测试将得到重视
10.1.2网络测试意义
网络是信息系统信息共享、信息传递的基础。建立高效、稳定、安全、可靠、互操作强、可预测、可控的网络是网络研究的最终目标，而网络测试是获得网络行为第一手指标参数的有效手段。
网络测试正是一种可以有效提高网络系统及网络应用运行质量的方法，在测试和测试的基础上，建立网络行为模型，并用模拟仿真的方法建立理论到实际的桥梁，是理解网络行为的有效途径。
10.1.3网络安全生命周期测试策略
网络建设生命周期可分为三个阶段，即网络规划设计阶段、网络实施阶段以及网络与应用系统集成阶段。
规划设计阶段主要的测试目的是利用网络仿真技术测试设计方案，以及对网络设备进行评估测试，为网络选型提供依据；网络实施阶段的主要测试目的是保证系统可用性和稳定性：网络与应用系统集成阶段的主要测试目的是为了保证应用系统在网络平台上的性能。
网络实施阶段的主要测试目的是为了保证应用系统在网络平台上的性能。
1、规划设计阶段
一方面可以采用网络仿真的方法，评估网络系统规划设计是否合理、是否满足应用系统的运行需求，从而给业主和设计人员提供合理的规划建议；
另一方面通过测试评估选择网络设备，优化网络配置，并在模拟实际网络运行的情况下进行性能、稳定性、互操作性测试。
2、网络实施阶段
在网络实施阶段，必须考虑网络的可用性，即网络是否连通、各项网络性能是否达到规划的设想和设计质量要求等。
3、网络与应用系统集成阶段
主要是指应用系统的开发，在开发完成且经过一定的功能和性能测试，证实运行基本稳定后，将程序应用到网络上进行网络级测试，考察多用户并发访问性能、系统响应时间、应用对网络资源的占用情况等。
网络建设生命周期可分为三个阶段：
网络规划设计阶段主要的测试目的是利用网络仿真技术测试设计方案，以及对网络设备进行评估测试，为网络选型提供依据；
网络实施阶段的主要测试目的是保证系统可用性和稳定性；
进行网络质量测试，包括吞吐量、包转发率、丢包率等。在网络实施阶段，必须考虑网络的可用性，即网络是否连通、各项网络性能是否达到规划的设想和设计质量要求等。
网络与应用系统集成阶段的主要测试目的是为了保证应用系统在网络平台上的性能。
10.2网络仿真技术
网络仿真技术有时也称为网络模拟技术或者网络预测技术。
它是一种通过建立网络设备、链路和协议模型，并模拟网络流量的传输，从而获取网络设计或优化所需要的网络性能数据的仿真技术。
网络仿真是一种利用数据建模和统计分析的方法模拟网络行为，从而获取特定的网络特性参数的技术。数学建模包括网络建模（网络设备、通信链路等）和流量建模两个部分。
建模中最基本的概念就是同等性。建模的过程实际上是将实际的系统映射到仿真环境中，仿真环境对实际系统的逼真程度，直接影响传真结果的有效性。
网络仿真采用基于包的建模机制来模拟实际物理网络中包的流动，包括在网络设备间的流动和网络设备内部的处理过程；模拟实际网络协议中的组包和拆包的过程，可以生成、编辑任何标准或定义的包格式，利用调试功能，还可以在模拟过程中察看任何特定包的包头（Header）和净荷（Payload）等内容。
10.2.3网络仿真技术应用
1、网络仿真在网络规划设计中的应用
网络仿真能够为网络的规划、设计提供可靠的定量依据。
网络仿真技术能够迅速地建立起现有网络的模型，并能够方便地修改模型并进行仿真，这使得网络仿真非常适用于预测网络的性能，回答“what …… if ……”这样的问题。
网络仿真能够验证实际方案或比较多个不同的设计方案。
2、网络仿真在企业网络管理和优化中的应用
3、网络仿真在网络研发中的应用
4、仿真的网络预测功能
10.2.4网络仿真软件
1、OPNET网络仿真软件
（1）OPNET介绍
OPNET的产品包括：
Modeler主要面向设计和研究通信网络、设备、协议和应用，支持所有网络类型和技术。
IT Guru是一个核心网络仿真软件包。
SP Guru面向电信运营等的智能化网络管理、规划以及优化，是一个能够辨识整个网络的独特软件产品，包括网络中的路由器、交换机、协议、服务器以及各种应用业务。
WDM Guru是一个先进的网络规划解决方案，使得业务提供商和网络设备制造商设计出健壮的且节约成本的光纤网络，并为测试产品提供了一个虚拟的光纤网络环境。
OPNET附加功能模块
OPNET开发包和NetBizODK是一个更底层的开发平台。
OPNET模型分为Network、Node和Process三个层次。
2、NS网络仿真软件
10.3网络质量测试
物理层：通过链路来传送比特信息，定义了用户应用程序数据如何转换为1和0并在物理介质中传递。
数据链路层：通过物理链路来传输成块的信息。它主要负责以下任务：数据出错校验、协调共享媒体的使用（如在一个LAN中）以及编址（当多个系统都可以访问时，如在某个LAN中。）另外，不同的链路通常也有不同的数据链路实现：而且，同一个节点可以支持几种不同的数据链路层协议，节点所连的每一类链路都有自己的协议。以太网、令牌环和帧中继均为数据链路层的实例。
网络层：使得网络中的任何一对系统间都可以相互通信。个全互联的网络是指其中的每一个节点都和其他节点直接相连，但是这种拓扑结构不可能用于有很多节点的情况。网络层处理的主要任务是：路由计算、数据包的分段和重组（当网络中的不同链路有不同的最大包大小限制时）和拥塞控制。
传输层：传输层在两个系统之间建立一条可靠的通信链路。它主要处理一些由网络层引起的错误，如包丢失和重复包等错误，以及对包进行重新排序、分段和重装。另外，也有助于传输层在网络发生拥塞时可以相应地降低发送数据的速率。
会话层：提供的服务超出了传输层提供的简单全双工可靠通信流。
表示层：为应用程序（在应用层中）进行数据格式转换和数据加解密提供了一种普通的方法。表示层具有转换机制，可在ASCII文本数据格式与Unicode格式间转换，也包括图像文件的压缩技术，如GIF和JPEG。
这一层的设计目的是为了对数据的表示取得一致，这样人们就可以定义自己的数据结构，而不必担心比特/字节顺序或浮点数该如何表示之类的问题了。
应用层：它为最终用户提供应用环境。应用包括文件传输、虚拟终端及web浏览等，在一个节点上通常有多个应用程序同时运行。
10.3.2网络测试指标
在对物理层、数据链路层和网络层进行测试时，如以太网、物理层的测试包括碰撞分析、错误统计和是否有随机能量、无格式的帧和信号回波等，数据链路层的测试包括流量分析、错误帧（FCS错误帧、长帧、短帧和延迟碰撞）统计等，网络层的测试包括响应时间测试、网络层协议分析、IP路由分析等。
对网络设备和TCP/IP网络的检测主要包括以下基本技术指标。
吞吐量：是指被测试设备或被测试系统在不丢包的情况下，能够达到的最大包转发速率。吞吐量测试是在每一对端口上，以全线速率在测试设置规定的时间段内生成传输流。
丢包率：通过测量由于缺少资源而未转发的包的比例来显示高负载状态下系统的性能。如果在任何端口上丢失包的话，将负载减少50%并重新开始测试。然后，用二分搜索法搜索没有包丢失发生时的最大速率。这个速率就是被测试设备的吞吐量，它是按测试设置中规定的每种包长度测试得出的。
延时：是指测量系统在有负载条件下转发数据包所需的时间。对存储转发设备来说，测量的延时是指从输入帧的最后一个比特达到输入端口的时刻，到输出帧的第一个比特出现在输出端口上的时刻的时间间隔。对于直通式设备来说，延时是指从输入帧的第一比特达到输入端口的时刻，到输出帧的第一比特达到输入端口的时刻，到输出帧的第一比特出现在输出端口的时刻的间隔。
在测试过程中，测量每对端口上的每一个包的延时，对于存储转发（Store-and-Forward）设备来说，测量的延时是指从输入帧的最后一个比特达到输入端口的时刻，到输出帧的第一个比特出现在输出端口上的时刻的时间间隔。对于直通式（Cut-Through）设备来说，延时是指从输入帧的第一比特达到输入端口的时刻的间隔。测试设置中规定 的每一种长度的包都要进行延时测试。
背靠背性能：是指通过以最大帧速率发送突发传输流，并测量无包丢失时的最大突发（Burst）长度（总包数量）来测试缓冲区容量。测试设置中规定的每一种包长度要进行背到背性能测试。
网络质量测试的指标：
（1）TCP/IP4-7层负载均衡
连接建立数：本测试以设定速率执行TCP连接建立。还可同时测试保持TCP连接的最大数量。
会话速率：本测试以设定速率执行TCP连接建立与拆除。
连接数量：测试检测峰值HTTP速率。当一个连接建立后，客户机与服务器之间就出现HTTP事务处理。
（2）IP语音网络测试
测试当语音和数据流经过被测试设备时的语音和数据流的包丢失、单向延时以及延时抖动。此外，得出的参数还被用于为每条语音流生成语音质量评估分析。
（3）宽带xDSL网络性能测试
帧测试；
1）帧丢失。通过测试量由于缺少资源而没有转发的帧的比例，显示给定负载条件下被测试设备的性能。
2）帧延时。测量每端口、每VPI/VCI的每个测试帧的延时。
3）吞吐量。根据RFC1242和RFC2544测量网络吞吐量。
端到端IP测试；
1）端到端吞吐量。
2）延时。
信元测试；
1）信元丢失。测量ATM（异步传输模式）在测试中，帧与信元的长度相等。测试测量传输帧与接收到的帧之间的差。（仅适用于ATM端到端传输。）
2）信元测试。利用ATM信元特征，测试不同终点之间的延时。
PPP容量测试
1）测量建立N个PPP（点对点协议）会话所需时间。
2）测量建立不同PPP会话时的最小、最大和平均延时。
3）发送PPP上的IP帧，测试吞吐量和包丢失。
ATM完整性
进行信元错误率（CER）测试，确定能过ADSL-ATM网络传送的ATM信元传输的准确性。报告收到的AAL5CRC错误帧数量。
（4）VPN网络测试
最大隧道创建数量：VPN系统能够创建的最大隧道的数量。
包丢失：在每条隧道上的数据包丢失。
延时：在每条隧道上的包延迟。
响应时间：在每条隧道上的应用响应时间。
（5）路由测试
支持BGP4/OSPF/RIP路由协议。
对路由进行压力测试，测试路由的性能。
10.3.3网络测试类型
（1）网络可靠性测试：使被测试网络在较长时间内（通常是24-72小时）经受较大负载，通过监视网络中发生的错误和出现的故障，验证在高强度环境中网络系统的存活能力，也就是它的可靠性。
（2）网络可接受性测试：可接受性测试是在系统正式实施前的“试运行”。
（3）网络瓶颈测试：测试中需要测试和计算系统的最大吞吐量，然后再在单个网络组件上进行该项测试，明确各自的最大吞吐量。
（4）网络容量规划测试：该项测试要逐渐增加网络负载，直到网络的运行性能或吞吐量下降至不能达到设计水平的要求为止。
（5）网络升级测试：升级测试是将硬件或软件的新版本与当前版本在性能、可靠性和功能等方面进行比较，同时验证产品升级对网络的性能是否会有不良影响。
（6）网络功能/特性测试：
（7）网络吞吐量测试：吞吐量测试检测的是每秒钟传输数据的字节数和数据报数，用于检测服务器、磁盘子系统、适配卡/驱动连接、网桥、路由器、集线器、交换器和通信连接。
（8）网络响应时间测试：
（9）衰减测试：衰减测试是测试贯穿整个通信连接或者信道的信号衰减。
（10）网络配置规模测试：利用应用程序响应时间测试和吞吐量测试的测试结果来确定网络组件的规模，还可利用测试结果和测试者自身对网络体系结构和网络操作的知识，来调整特定的系统配置组件，改变网络的运行性能。
（11）网络设备评估测试：产品评估主要是比较各个产品，进行这种测试时，除了待测设备之外，网络中的其他组件都要求保持不变。
以下3个测试任务是公认的最重要的测试任务：
（1）吞吐量测试：它是标识网络设备、子网和全局网络运行性能的重要指标
（2）可接受性测试：是对将要使用的网络的验收，其重要性和必要性是显然的。
（3）升级测试：运动是永恒的，网络系统永恒的主题是升级换代，升级测试也要不断进行，不要主观地认为升级后的网络一定比原来的好。
10.3.4网络测试对象
网络测试不可能对整个网络的所有设备和组件进行全部的测试，可根据日常监测的有关网络系统的数据，大致划分出网络易出故障的部分：关注新的网络组件（如设备和应用程序等）：采用逐步测试的方式，按一定顺序进行。
网络测试对象包括4种类型：
（1）网络平台包括网络操作系统、文件服务器和工作站；
（2）应用层是指应用程序的客户端、桌面操作系统和数据库软件等；
（3）子系统主要是指路由器、集线器、交换机和网桥；
（4）全局网路径则是整个网络系统中重要的点对点路径。
网络测试对象还可以进一步细分为7个网络子系统，如下几项：
（1）文件服务器：主要针对服务器的硬件和网络操作系统。
（2）工作站：网络性能直接受网络工作站的网卡、协议、缓冲区、视频刷新和桌面管理的影响。
（3）网络操作系统：网络操作系统中有很多部分需要测试。
（4）应用程序、客户/服务器数据库和工作站桌面软件：应用程序最重要的测试任务是稳定性、响应时间、容量、功能和升级测试。
（5）路由器、集线器、交换机和网桥：从测试的角度看，这类产品的硬件和软件被看作子系统。
（6）网段：一旦各网络子系统分别进行了测试，就要把它们组合到一起，并使组合后的模拟网段尽可能体现出运行网段的典型特征。
（7）全局网：网段测试通过后，就要把网段放到网络中进行全局网测试。
10.3.5网络测试的基础方法
典型的网络设备测试的方法有两种：第一种是将设备放在一个仿真的网络环境中，通过分析该产品在网络中的行为对其进行测试；第二种方法是使用专用的网络测试设备对产品进行测试。
分析和解决网络性能问题时，通常有这么几个分析的模型和方法，如下所示。
七层网络结构分析模型法：
网络连接结构的分析法：从网络的连接构成来看可以大致分成客户端、网络链路、服务器端三个模块。
10.3.6网络测试标准及工具
1、测试标准
2、测试工具
（1）物理线缆测试仪
常见的测试项目主要有线缆长度、衰减、阻抗、串扰、反射和噪声等。
（2）网络运行模拟工具
（3）协议分析仪：协议分析仪是定位和排除故障的关键工具，可以捕获网络上的数据报或数据帧。一个数据包或数据帧主要包含三方面信息：源地址和目的地址、数据、控制位。
（4）专用网络测试设备：专用的软硬件结合的测试设备，能够对网络设备、网络子网以及整个网络系统提供综合测试，具有典型的三大功能：数据捕获、负载产生和智能分析。
（5）网络协议的一致性测试工具
（6）网络应用分析测试工具
10.4网络应用测试
10.4.1网络应用监控
1、概述
网络监测功能一般是通过将网络探测器设备安装在网络的某一网段上采集数据实现的。
2、网络应用监控目标
3、网络应用监控原理
4、网络应用监控工具
Network Vantage是一个全面应用监控和报告产品，它帮助发现和优化网络上的应用性能。
Sniffer是另一种网络监控工具，它可以实现如下功能：
1）捕捉网络流量；
2）诊断问题；
3）监控现实情况下的网络活动；
4）针对网络上单独的工作站、会话以及部分网络，搜集详细的使用和错误信息；
5）存储历史的使用和错误信息用于基线分析；
6）产生可见或可视的报警信息；
7）利用工具在网络上打探针，模拟流量、测量响应时间、计算跳转以及定位问题。
10.4.2网络故障分析
1、网络故障诊断步骤
一般故障诊断模式如下：
（1）当分析网络故障时，首先要清楚故障现象；
（2）收集需要的用于帮助隔离可能故障原因的信息；
（3）根据收集到的情况考虑可能的故障原因；
（4）根据最后的可能的故障原因，建立一个诊断计划；
（5）执行诊断计划，认真做好每一步测试和观察，直到故障症状消失；
（6）每改变一个参数都要确认其结果。
2、软件问题的诊断
重点考虑以下几个方面的测试：
优化应用程序的性能；
预测响应时间；
确实网络带宽需求；
在应用程序领域和网络领域分别进行故障定位。
（1）网络应用分析的关键因素
包括：会话信息、包信息、响应时间信息、负载信息、高峰信息、线程信息等。
会话信息：指应用程序节点之间的会话信息，会话信息主要包括会话往返行程和会话流量信息。
1）往返行程。一个往返行程是一对节点之间的一系列帧请求/回应。
2）流量信息。会话的流量信息包括节点之间传输的字节数或者帧数目。
包信息：可以先对包信息进行解码，然后分析包的详细信息，还可以分析包与包之间的关系、一个时间段内包的数量和包尺寸平均大小，以及包与线程的关系等。
响应时间信息：客户端响应时间、网络传输时间以及服务器（包括web服务器、应用服务器、数据库服务器）的处理时间，为分段定位故障提供依据。
负载信息：有效负载与其他负载的比例，来评估与业务相关的流量效率。
高峰信息：需要明确高峰发生的时刻以及高峰期的流量，以确定广域网的容量要求，所表示了一个应用的平均流量和高峰流量。
线程信息：每个线程中都包含了一组包信息，所以可以分析线程和包之间的关联。可以对某个线程进行分析，也可以对线程之间的关系进行分析。
响应时间预测：要完成这项工作需要定义三类参数，分别是带宽、背景负载（利用率）以及延迟。要完成这项工作需要定义三类参数，分别是带宽、负载、延迟参数下预测某个会话的响应时间。
带宽模拟：模拟的目的是为系统传输选择一个合适的带宽，使得系统的峰值流量可以接受。
（2）故障定位举例
3、硬件问题的诊断
（1）物理层及其诊断
故障主要表现在设备的物理连接方式是否恰当、连接电缆是否正确、MODEM或CSU/DSU等设备的配置及操作是否正确等方面。
确定路由器端口物理连接是否完好的最佳方法是，使用show interface命令，检查每个端口的状态，解释屏幕输出信息，查看端口状态、协议建立状态和EIA状态。
（2）数据链路层及其诊断
查找和排除数据链路层的故障，需要查看路由器的配置，检查连接端口的共享同一数据链路层封装情况。每对接口要和与其通信的其他设备有相同的封装。通过查看路由器的配置检查其封装，或者使用show命令查看相应接口的封装情况。
（3）网络层及其诊断
网络层提供建立、保持和释放网络层连接的手段，包括路由选择、流量控制、传输确认、中断、差错及故障恢复等。
排除网络层故障的基本方法是：沿着从源到目标的路径，查看路由器路由表，同时检查路由器接口的IP地址。如果路由没有在路由表中出现，应该通过检查来确定是否已经输入适当的静态路由、默认路由或者动态路由。然后手工配置一些丢失的路由，或者排除一些动态路由选择过程的故障，包括RIP或者IGRP路由协议出现的故障。
第11章安全测试与评估
11.1概述
软件安全性是与防止程序及数据的非授权故意或意外访问的能力有关的软件属性。
11.2测试与评估内容
11.2.1用户认证机制
用户认证就是指软件系统用户在使用软件或系统时，必须提供用户身份证明，然后软件系统根据用户数据库的资料，开发放特定的权限给登录用户。
目前主要的用户认证机制有如下几种：
数字证书；
智能卡；
双重认证；
安全电子交易（SET）协议。解决信用卡电子付款的安全保障性问题：保证信息的机密性，保证信息安全传输，不能被窃听，只有收件人才能得到和解密信息。
11.2.2加密机制
密码技术主要用于密码的保护、数据的传输过程中的安全保护、数据存储过程的安全防护等。
11.2.3安全防护策略
安全防护策略是软件系统对抗攻击的主要手段，安全防护策略主要有安全日志、入侵检测、隔离防护、漏洞扫描等。
安全日志是记录非法用户的登录名称、操作时间及内容等信息，以便于发现问题并提出解决措施。安全日志仅记录相关信息，不对非法行为作出主动反应，因此属于被动防护的策略。
入侵检测系统是一种主动的网络安全防护措施，它从系统内部和各种网络资源中主动采集信息，从中分析可能的网络入侵或攻击。一般来说，入侵检测系统还应对入侵行为作出紧急响应。
漏洞扫描就是对软件系统及网络系统进行与安全相关的检测，可以找出安全隐患和可被黑客利用的漏洞。
隔离防护是将系统中的安全部分与非安全部分进行隔离的措施，即隔离网闸和防火墙。隔离网闸，主要目的在于实现内网和外网的物理隔离，防火墙是相对成熟的防护技术，主要用于内网和外网的逻辑隔离。
11.2.4数据备份与恢复手段
数据备份与恢复技术通常会涉及以下几个方面：
存储设备：磁盘阵列、磁带机、光盘库、SAN设备。
存储优化：DAS、NAS、SAN
存储保护：磁盘阵列、双机容错、集群、备份与恢复
存储管理：数据库备份与恢复、文件与卷管理、复制、SAN管理。
11.2.5防病毒系统
1、集中式管理、分布式杀毒
对局域网进行远程集中式安全管理，统一升级杀毒引擎和病毒定义，并可通过账号和口令设置移动控制台。并采用先进的分布技术，利用本地资源和本地杀毒引擎，对本地节点的所有文件全面、及时、高效地查杀病毒，同时保障用户的隐私，减少网络传输的负载，避免因大量传输文件而引起网络拥塞。杀毒软件中心较为流行的两种集中管理方式如下：
以策略为中心；
以服务器为中心
2、数据库技术、LDAP技术的应用
使用数据库技术、LDAP技术进行策略和日志的存储、用户管理等，不但增强了用户管理能力、策略组织能力、提高了策略调用速度，而且便于以后向日志分析等方面扩展。
3、多引擎支持
4、不同操作系统的防护
5、远程安装或分发安装
11.3安全系统测试策略
11.3.1基本安全保护系统测试
基本安全保护系统一般采用防火墙、入侵检测、漏洞扫描、安全审计、病毒防治、Web信息防篡改、物理安全等基础安全技术，以保障应用系统的安全。
设计的测试点如下：
防火墙
（1）是否支持交换和路由两种工作模式；
（2）是否支持对HTTP、FTP、SMTP等服务类型的访问控制；
（3）是否考虑到防火墙的冗余设计；
（4）是否支持对日志的统计分析功能，同时，日志是否可以存储在本地和网络数据库上；
（5）对防火墙本身或受保护网段的非法攻击系统，是否提供多种告警方式以及多种级别的告警。
入侵监测系统
（1）能否在检测到入侵事件时，自动执行切断服务、记录入侵过程、邮件报警等动作；
（2）是否支持攻击特征信息的集中式发布和攻击取证信息的分布式上载；
（3）能否提供多种方式对监视引擎和检测特征的定期更新服务；
（4）内置的网络能否使用状况监控工具和网络监听工具。
漏洞扫描
能否定期或不定期地使用安全性分析软件，对整个内部系统进行安全扫描，及时发现系统的安全漏洞、报警，并提出补救建议。
病毒防治
（1）能否支持多种平台的病毒防治；
（2）能否支持对服务器的病毒防治；
（3）能否支持对电子邮件附件的病毒防治；
（4）能否提供对病毒特征信息和检测引擎的定期在线更新服务；
（5）防病毒范围是否广泛，是否包括UNIX、Windows、Linux系统等操作系统。
安全审计
（1）能否进行系统数据收集，统一存储，集中进行安全审计；
（2）是否支持基于PKI的应用审计；
（3）是否支持基于XML的审计数据采集协议；
（4）是否提供灵活的自定义审计规则。
Web信息防篡改系统
（1）是否支持多种操作系统；
（2）是否具有集成发布与监控功能，使系统能够区分合法更新与非法篡改；
（3）是否可以实时发布和备份；
（4）是否具备自动监控、自动恢复、自动报警的能力；
（5）是否提供日志管理、扫描策略管理和更新管理。
⑦管理安全：对相关的人员、技术和操作进行管理，总揽以上各安全要素并进行控制。
安全性测试策略针对这7个层次进行测试和评估。
11.3.2安全系统防护体系
对业务系统进行全面保障的安全体系，主要体现在以下7个层次
（1）实体安全
（2）平台安全
（3）数据安全
（4）通信安全
（5）应用安全
（6）运行安全
（7）管理安全
安全性测试策略针对这7个层次进行测试和评估
1、证书业务服务系统测试
2、证书查询验证服务系统测试
3、密钥管理系统测试
4、密码服务系统测试
5、可信授权服务系统测试
6、可信时间戳服务系统测试
7、网络信任域系统测试
8、故障恢复与容灾备份测试
9、安全产品的选择
11.4安全性测试方法
11.4.2漏洞扫描
漏洞扫描器是一种自动检测远程或本地主机安全性弱点的程序。分来两种类型：主机漏洞扫描器（Host Scanner）和网络漏洞扫描器（Network Scanner）。主机漏洞扫描器是指在系统本地运行检测系统漏洞的程序，网络漏洞扫描器是指基于网络远程检测目标网络和主机系统漏洞的程序。
11.4.3模拟攻击试验
11.4.4侦听技术
11.5软件产品安全测试
软件产品安全测试侧重于以下两方面：用户对数据或业务功能的访问控制，数据存储和数据通信的远程安全控制。
11.5.1用户管理和访问控制
1、用户权限控制
2、操作系统安全性的测试
3、数据库权限的测试
11.5.2通信加密
目前使用的加密技术包括：VPN技术、对称加密算法、非对称加密算法、HASH算法等。
11.5.3安全日志测试
日志应当记录所有用户访问系统的操作内容，包括登录用户名称、登录时间、浏览数据动作、修改数据动作、删除数据动作、退出时间、登录机器的IP等。
第12章兼容性测试
12.1兼容性测试概述
兼容性测试将验证软件与其所依赖的环境的依赖程度，包括对硬件的依赖程度，对平台软件、其他软件的依赖程度等。
12.2兼容性测试环境的准备
测试中的硬件环境指进行测试所必需的服务器、客户端、网络连接设备，以及打印机、扫描仪等辅助硬件设备所构成的环境；软件环境则指被测软件运行所需的操作系统、数据库、中间件、浏览器及与被测软件共存的其他应用软件等构成的环境。
12.3硬件兼容性的测试
12.3.1硬件兼容性测试的目的
所有软件都需向用户说明其运行的硬件环境，对于多层结构的软件系统来说，需要分别说明其服务器端、客户端以及网络所需的环境。测试的目的就是确认这些对于硬件环境的描述是否正确、合理。
硬件兼容性测试需确认以下几点：
1、最低配置是否能够满足系统运行的需要。所有的软件功能必须能够完整地实现，软件运行速度、响应时间应在用户能够忍受的范围内。
2、在推荐配置下系统的响应迅速。应当注意的是，推荐配置必须合理，一味地追求高配置，一方面可能掩盖软件的性能缺陷，另一方面限制了软件的应用范围，也是不合理的。
3、考察软件对运行硬件环境有无特殊说明。 有些软件可能在不同的硬件环境中出现不同的运行结果或是在某些环境下根本就不能执行。
4、为了满足不同的使用需求，软件系统能否运行在多种硬件配置环境下，并且系统功能和性能都能满足设计需求。
12.3.2与整机的兼容性
整机兼容性测试将确认软件要求的最低配置和推荐配置的合理性和正确性。主要指标包括对机型的要求和对CPU、内存、硬盘的要求，其他还包括对RAID的支持、对SCSI的支持等。
CPU：各类软件的最低配置和推荐配置都必须注明对CPU的要求。包括CPU类型和主频的要求。Intel主流CPU的性能差别主要体现在频率、缓存两个方面。频率分为主频和外频两部分，缓存因素分为缓存容量、缓存速度、缓存潜伏时间三部分。应用软件及客户端软件对CPU的推荐配置要求应当比目前主流CPU略低，服务器端的最低配置必须能够使软件正常工作。推荐配置应保证软硬件构成系统在正常业务的压力负载下，CPU资源占用平均值不超过75%。
内存：内存容量直接影响着软件的运行效率。内存参数的设置对性能的影响，集中在CAS（列地址选通脉冲）、RAS（行地址选通脉冲）的设置上。
硬盘：特殊软件要考虑硬盘的转速、缓存容量、寻址时间等参数。
12.3.3与板卡及配件的兼容性
一般情况下，板卡和配件与软件的兼容性需要考虑以下几个方面。
独立板卡：而操作系统与各类板卡的兼容不仅仅体现在“能用”上，还必须达到“好用”。
主板芯版组：针对不同芯板组开发的驱动程序效率不同。对于集成主板，由于各部分的相互影响，往往会对被测桌面操作系统的兼容性造成挑战。
驱动程序中的自由软件。
12.3.4与打印机的兼容性
打印机兼容性的测试对于操作系统、办公软件、网站和其他打印功能比较重要的软件来说，都是不可缺少的。
对于不同厂商、不同型号的打印机需要分别进行测试。
打印机兼容性测试主要包括以下项目：
1、安装或能够调用系统安装的打印机；
2、能打印测试页；
3、能选择不同幅面的纸张；
4、能选择打印精度（打印分辨率）；
5、纸张横、纵打印调整功能；
6、逐页打印功能；
7、多份打印功能；
8、可以进行打印机的维护（比如更换墨水、清洗打印头等）；
9、具备双面打印器的打印机能够实现自动双面打印功能；
10、网络打印机能够实现网络打印功能。
12.4软件兼容性测试
12.4.1与操作系统的兼容性
操作系统兼容性的测试内容不仅包括安装，还需对关键流程进行检查。
（1）windows平台：对于B/S结构的客户端，至少需在win98、winME、win2k、winXP上进行测试英文版和中文版需分别测试，在英文操作系统上测试中文版软件时，要特别注意是否会出现英文信息或乱字符，在中文版操作系统上测试英文软件时，注意是否存在提示文字不能完全显示的现象。测试前要保证测试环境中所有的补丁都已安装，在用户文档中也应给出提示。如果有必要进行更严格的测试，则可增加对不同版本补丁的兼容性测试。
（2）Linux平台：作为自由软件，其核心版本是惟一的，而发行版本则不受限制。需要对多发行商、多版本进行测试，用户文档中的内容应明确至发行商和版本号。
（3）unix平台：Unix平台也存在着Solaris、IBM、HP等多厂商的多版本，不过由于在这些unix平台上运行的软件往往至少需要重新编译才能运行，所以只需按软件的承诺选择测试环境即可。
（4）Macintosh：使用这类系统的往往是图形专用软件。对于web站点也需要进行macintosh系统下的测试，有些字体在这个系统下可能不存在，因此需要确认选择备用字体。
12.4.2与数据库的兼容性
ODBC（Open Data Base Connectivity，开放数据库互连）最大优点是其互操作能力强，理想情况下，每一个驱动程序和数据源应支持完全相同的ODBC函数调用和SQL语句，使得ODBC应用程序可以操作所有的数据库系统。不同的数据库系统对SQL语法的支持程度各不相同，实现的ODBC规范所定义的功能也会有所不同。
JDBC（Java Data Base Connectivity，Java数据库连接）。同样，各个数据库对JDBC的支持也并不相同。
数据库兼容性测试要点如下：
（1）完整性测试。检查原数据库中各种对象是否全部移入新数据库，同时比较数据表中数据内容数是否相同。
（2）应用系统测试。模拟普通用户操作应用的过程，对应用进行操作并检查运行结果，从以往的测试经验来看，如果开发中使用了存储过程，那么在数据库移植时最容易出现问题。
（3）性能测试。上两项测试通过后，针对服务器、数据库进行性能测试，并与在原数据库下记录的性能基准数据进行比照，找出性能方面的问题，并有针对性地进行性能优化。
12.4.3与中间件的兼容性
涉及中间件的系统一般已不是一个单纯的软件，而是一个有一定规模的系统了。中间件兼容性的测试方法与数据库兼容性的测试方法大同小异。
12.4.4与浏览器的兼容性
12.4.5与其他软件的兼容性
除了以上各项软件的兼容性以外，我们还需要考虑以下问题。
与支持软件的兼容性。这些被测软件运行所必须的其他软件都应当进行兼容性测试，测试中要对其所依赖的软件的各个版本分别进行测试。
与其他同类软件的兼容性。判断与其他同类软件安装在同一系统上，同时使用，是否会造成其他软件运行错误，或本身能否正确实现其功能。
与其他非同类软件的兼容性。
12.5数据兼容性测试
12.5.1不同数据格式的兼容性
数据兼容是指软件之间能否正确地交互和共享信息。制定数据兼容性测试用例时可以参考以下几项内容：
（1）在被测软件中与其他程序间复制粘贴的文字是否正确？带格式的文字呢？表格呢？图形呢？
（2）在以前的版本下保存的文字在新的版本中是否能被打开；所有的特点是否都能被保留；包含新特性的新版本文件在旧系统中是否能被打开；新特性在旧版本中将如何解释。
（3）被测软件是一个系列软件中的一个吗，与本系列中的软件以何种形式交换数据。
（4）与同类软件间能否进行数据交换，软件是否提供对其化常用数据格式的支持。
（5）测试中需要明确业界有没有针对被测软件内容进行数据交换定义的标准或规范。
12.5.2XML符合性
XML，可扩展标记语言是一种元标记语言，它使用简单灵活的标准格式。XML主要有3个组成元素：Schema（模式）、XSL（可扩展样式语言）和XLL（可扩展链接语言），其中Schema规定了XML文件的逻辑结构，定义了XML文件的元素、元素的属性以及元素和元素属性之间的联系，它可以帮助XML的分析程序校验XML文件标记的合法性：XSL是用于规定XML文档样式的语言，它能在客户端使用web浏览器改变文档的表示法，从而不需要再与服务器进行交互通信；XLL将进一步扩展目前web上已有的简单链接。
XML测试的需求往往来自于业界已有的数据格式规范，一般是一套Schema文件。其测试步骤一般为：
在测试工具中建立标准模板；
用被测软件按要求导出数据；
将导出的数据与标准模板进行对比匹配测试；
输出测试结果。
测试中用到的数据比较工具可采用已有的XML解析器如XMLSPY，或有针对性地开发出一些专用工具。
12.6平台化软件兼容性测试
12.6.1平台化软件概述
平台化软件是指用来构建与支撑应用软件的独立软件系统。软件平台有两个基本要素，即支撑环境和开发体系。其中支撑环是指应用软件系统开发与运行的基本条件，开发体系是指开发与维护管理应用软件的工具与方法。它又可以分为技术支撑型平台软件和应用实现平台软件两种类型的平台。
平台软件的结构：
（1）技术支撑型平台：为软件系统研发提供通用技术基础架构，主要面向软件开发人员，主要包含应用软件的运行支持体系和上层开发的工具，上层应用系统由用户进行研发。
（2）应用实现型平台：指用来构建与支撑应用软件的独立软件系统。主要面向应用软件的终端用户。
（3）应用的广泛性：平台化软件的功能更加全面、覆盖面更加广泛。
（4）平台化软件的各种信息统一存储，实现管理信息的共享，从而提高各级组织内部有效的协作和快速反应。
（5）良好的开发性：平台化软件是建立在共同平台上的一个系统，模拟相互之间既具有较强的独立性，又可以独立使用，通过统一的数据接口可实现相互间的无缝集成，同时可以实现一致的对外接口。
（6）快捷的适应性：平台化软件的上层应用开发工具可以实现免编程的应用系统修改，具有更快捷、方便的适应能力。
12.6.2平台化软件的兼容性测试策略
跨硬件平台能力：在不同规模的硬件平台上进行测试，如从32位机到64位机，从单机到集群运行。
跨操作系统能力：平台化软件应可以部署在各种流行的操作系统上，包括windows、linux、unix等。
支持多种数据库系统
客户端兼容性测试
数据兼容性测试
12.7新旧系统数据迁移测试
数据迁移，就是将这些历史数据进行清理、转换，并装载到新系统中的过程。
12.7.2新旧系统数据迁移的实现与测试
数据迁移的实现可以分为三个阶段：数据迁移前的准备、数据迁移的实施和数据迁移后的校验。
为了保证数据的安全性，在测试和实施时还可以考虑以下措施：
（1）在实际运行环境之外搭建模拟环境，导入部分或全部数据，在模拟环境中进行一次或数次模拟迁移尝试。测试不仅要包括旧系统向新系统的迁移，还需进行新系统到旧系统的反回迁移，以确保在迁移过程失败时，可以及时恢复旧系统。在测试过程中还要详细记录遇到的问题，研究解决方法，并预测迁移风险。
（2）将现有数据进行备份，检查备份数据的正确性：作两套备份，比较两份备份，以保证备份数据完整可靠。
（3）如果有备份系统，则先将备份系统升级到新系统，保持主服务器的旧系统不动，切换至备份服务器运行一周，若一切正常再升级主服务器，升级成功后切换至主服务器运行。
第13章标准符合性测试
13.1概述
标准符合性测试就是测量产品的功能和性能指标，与相关国家标准或行业标准所规定的功能和性能指标之间符合程度的测试活动。它区别于一般的测试，标准符合性测试依据和测试规程一定是国家标准或行业标准，而不是实验室自定义的或其他的有关文件。
标准符合性测试通常有两种方式，一是自律测试，二是权威测试。前者由应用开发者利用适当的工具对自己开发的产品进行测试，测试工具通常由行业协会提供，有的还可从网上免费获取或自主开发测试程序；后者则是委托授权的机构对厂商的产品进行测试，测试机构将出具规范化的测试报告，作为进一步产品标准化认证的技术依据，即第三方认证（从事信息技术产品认证工作的第三方合格评定组织，依据我国已发布的信息技术产品强制性标准、推荐性标准和国家有关产品认证的法律、法规和规章，代表国家对相关产品及相关设备进行认证和检测工作）。
13.2标准符合性测试主要分类
1、数据内容类标准
这类标准主要描述用于数据交换与互操作的数据格式或内容规范。
2、通信协议类标准
这类标准主要描述用于数据通信与传输的接口数据格式。
3、开发接口类标准
所谓SQL标准符合性测试：即测试数据库管理系统与SQL标准的符合程度，分为语法级、语义级；
ODBC规范为应用程序提供了一套高层调用接口规范和基于动态链接的运行支持环境；
JDBC规范为Java语言访问关系数据库提供了一个编程接口规范，它由一组用Java编程语言编写的类和接口组成。
4、信息编码类标准
如GB18030汉字编码标准，它是为了适应信息处理、信息交换的应用，对字符集提出了多文种、大字量、多用途的要求而定义的。
开发接口类标准：
1、SQL标准符合性测试
2、ODBC标准
3、JDBC标准
13.4测试实施
一般说，标准符合性测试可以按以下步骤实施：
（1）阅读和理解标准；
（2）确定测试工具；
（3）确定用例文件；
（4）执行用例文件；
（5）分析测试结果。
在测试结果的分析与评价上主要有两种形式：一种认为要全部符合标准才算通过，即yes or no方式；一种则通过测试符合标准的程度来判定。
第14章易用性测试
14.1概述
可用性之外还要有很好的易用性，最终用户是否感到软件容易使用，直接决定了一个软件能否取得市场的成功。
Windows关键在于它美观易用。
有的系统问题的关键在于该系统没能很好地体现用户的使用习惯，不符合行业特点。
易用性是指软件产品被理解、学习、使用和吸引用户的能力。软件是否易用、“友好”已经成为软件质量的一个重要体现。易用性涉及到易理解性、易学习性、美观性、一致性、业务符合性等方面。
易用性测试不仅是针对应用程序的测试，而且还要包括用户手册等系列文档。易用性四部分：安装测试、功能易用性测试、界面测试、辅助系统测试。
14.2安装测试
除嵌入式软件之外，安装是软件产品实现其功能的第一步。
安装测试的方法很简单，就是按照用户安装手册安装软件，来评估安装过程的易用性、正确性。注意以下几个方面：
（1）安装手册的评估。一般来说，安装手册需要对安装平台、安装过程需注意的事项以及需手动配置的部分进行详细说明；
（2）安装的自动化程度测试。一般来说，软件的安装程序尽量要做到“全自动化”，即使在不得已的情况下需要进行手动的配置，也要采取一些措施，比如选择框方式等，使手动配置变得简便和明确。
（3）安装选项和设置的测试。比如安装路径等。安装测试时需要对不同的选项和设置方案进行测试，验证各种方案是否都能安装成功。
（4）安装过程的中断测试。如果因为断电、文件冲突或读写错误导致安装过程的非正常中断，有可能使已进行的安装工作前功尽弃。一个好的自动化安装程序应该能记忆安装的过程，当恢复安装时，安装程序能自动进行检测，并从“断点”继续安装。
（5）安装顺序测试。不同的安装顺序常常会导致安装失败，或者会引起一些不可预料的错误，如，先安装客户端后安装服务器，会导致某些软件的客户端与服务器连接不上。若《安装手册》中未明确指出安装顺序，则需要测试不同顺序的安装过程。
（6）多环境安装测试。不同应用环境下安装的情况也不一样，至少要在标准配置、最低配置和笔记本电脑三种环境中进行安装测试。有些系统级的软件常常在笔记本电脑上安装时发生错误。
（7）安装的正确性测试。在上述的安装测试后，需要进行简单的使用以验证安装的正确性。还要考察对其他应用程序的影响。
（8）修复安装测试与卸载测试。修复安装测试指软件使用后，根据需要添加或删除软件的一些组件或者修复受损的软件。进行修复安装测试时，需检查修复对软件有无不良的影响，例如，修复可能造成系统数据丢失。卸载测试重点检查卸载是否完全，不能完全卸载时有无明确提示信息等。
14.3功能易用性测试
功能易用性测试项，如下：
（1）业务符合性：软件必须符合其所服务的领域的业务逻辑。要求软件的界面风格、表格设计、业务流程、数据加密机制等的设计必须符合相关的法律法规、业界标准规范以及使用人员的习惯。
（2）功能定制性：适应用户需求的不断变化，软件功能应当能够灵活定制。
（3）业务模块的集成度：在一个系统中业务模块之间有可能存在较紧密的关联。
（4）数据共享能力：“一次输入、多处应用”不仅能够减少用户的重复输入工作，更有效地保证了数据的正确性。最大程度的减少用户的重复输入，同时保证数据传递的一致性。
（5）约束性：对于流程性比较强的业务操作，上一步操作完成之后，要强制进行下一步操作，这时需要软件以向导或与屏蔽无关操作的方式来限制用户的操作；另外，应以屏蔽或提示的方式阻止用户输入非法字符或进行损害数据和系统的操作，这样才能有效地避免用户犯错误，同时也减少了系统出现异常的概率，提高系统的安全可靠性。
（6）交互性：包括用户操作的可见性和系统对用户的反馈。对于用户的每一步操作都应有所回应或者提示，使用户清晰地看到系统的运行状态。对于用户来说，这种回应与提示是对用户操作的认可与尊重，更有助于用户确定下一步操作该如何进行。
（7）错误提示：关键操作完成后或数据删除等操作前给出明确提示，操作错误或系统出现错误时，给出的出错信息中提供差错产生的原因，并指示如何进入正确的步骤，帮助用户从错误中恢复。
14.4用户界面测试
用户界面测试主要核实用户与软件之间的交互，验证用户界面中的对象是否按照预期的方式运行，并符合国家或行业的标准。
用户界面测试可分为整体界面测试和界面中的元素测试。界面中的元素主要包括窗口、菜单、图标、文字、鼠标等。
14.4.1界面整体测试
界面整体测试是指对界面的规范性、一致性、合理性等进行测试和评估。
1、规范性测试
软件的界面要尽量符合现行标准和规范，并在应用软件中保持一致。
如IBM、Microsoft、Apple标准，这些标准已经基本包含“菜单条、工具栏、工具箱、状态栏、滚动条、右键快捷菜单”的标准格式。
在界面测试中，测试工程师应该严格遵循这些标准和规范设计界面规范性测试用例。
2、合理性测试
界面的合理性是指界面是否与软件功能相融洽，界面的颜色和布局是否协调等。
空间使用应当形成一种简洁、有序、易于操作的布局，使信息组织具有艺术性。
测试软件界面的合理性一般通过观察进行，举例如下：
界面中元素的文字、颜色等信息是否与功能不一致；
前景与背景色搭配是否合理协调，反差是不是太大；
界面中的元素大小和布局是否协调；
窗口的比例是否合适。
3、一致性测试
一致性既包括使用标准的控件，也指相同的信息表现方法，如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致。一致性既包括使用标准的控件，也指相同的信息表现方法。好的软件界面都具有相似的界面外观、布局、交互方式以及信息显示等。界面保持高度一致性，用户可以减少过多的学习和记忆量，从而降低培训和支持成本。
对于不同的平台测试软件界面的一致性可以用下面的方法：在不同分辨率下，观察界面的美观程度，分别在800*600，1024*768，1152*865，1280*768，1280*1024，1200*1600大小的字体下进行测试。
在测试界面一致性时应该注意以下几点因素。
布局是否一致，如所有窗口按钮的位置和对齐方式要一致；
标签和讯息的措辞是否一致，如在提示、菜单和帮助中产生相同的术语；
界面外观是否一致，如控件的大小、颜色、背景和显示信息等属性要一致；
操作方法是否一致，
颜色的使用是否一致，
快捷键在各个配置项上语义是否保持一致。
4、界面定制性测试
因此需要对界面的可定制性进行测试，测试中可参考以下几项测试内容。
界面元素的可定制性；
工具栏的可定制性；
统计检索的可定制性；
报表的可定制性；
14.4.2界面元素测试
1、窗口测试
2、菜单测试
设计菜单界面测试用例主要应从以下几点考虑。
是否符合需求；
菜单项的措辞是否准确；
菜单项的顺序是否合理；
图形的布局是否一致。
3、图标测试
图标是否符合常规的表达习惯；
不同的目标是否采用不同的图标。
图标是否具有清晰的轮廓，轮廓清晰的图标可保证图像在不同背景在不同背景色上都具有较好效果。
注意图标的尺寸，建议图标的尺寸小一些较好。
建议图标的外形与实际功能相似，应尽量避免抽象。
在图标上是否加有标注。
4、鼠标测试
文字测试是测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；
14.4.3界面测试典型用例
14.5辅助系统测试
14.5.1帮助测试
14.5.2向导测试
14.5.3信息提示
第15章可靠性测试
15.1软件可靠性与可靠性测试
15.1.1软件可靠性概述
可靠性（reliability）是指产品在规定的条件下和规定的时间内完成规定功能的能力。
固有可靠性是通过设计、制造赋予产品的可靠性；使用可靠性既受设计、制造的影响，又受使用条件的影响。一般使用可靠性总低于固有可靠性。
软件可靠性定义：在规定的条件下，在规定的时间内，软件不引起系统失效的概率，该概率是系统输入和系统使用的函数，也是软件中存在缺陷的函数；系统输入将确定是否会遇到已存在的缺陷（如果缺陷存在的话）。
在规定的时间周期内，在所述条件下程序执行所要求的功能的能力。
我们来分析一下软件可靠性的框架性定义。
（1）规定的时间。
（2）规定的条件。
（3）所要求的功能。
（4）软件可靠性定义具有以下特点：
1）用内在的“缺陷”和外在的“失效”的关系来描述可靠性，更能深刻地体现软件的本质特点。
2）定义使人们对软件可靠性进行量化评估成为可能。
3）用概率的方法去描述可靠性是比较科学的。
15.1.3软件可靠性的定量描述
1、规定时间
15.1.6广义的可靠性测试与狭义的可靠性测试
可靠性测试的目的可归纳为以下三个方面：
（1）发现软件系统在需求、设计、编码、测试、实施等方面的各种缺陷。
（2）为软件的使用和维护提供可靠性数据。
（3）确认软件是否达到可靠性的定量要求。
15.2软件可靠性建模
15.2.2软件可靠性建模方法
一个软件可靠性模型通常由以下几部分组成。
（1）模型假设。
（2）性能度量。
（3）参数估计方法。
（4）数据要求。
一个好的软件可靠性模型应该具有如下重要特性。
（1）基于可靠的假设
（2）简单
（3）计算一些有用的量
（4）给出未来失效行为的好的映射
（5）可广泛应用。
15.3软件可靠性测试
软件可靠性测试由可靠性目标少确定、运行剖面的开发、测试用例的设计、测试实施、测试结果的分析等主要活动组成。
一个典型的测试用例应该包括下列组成部分。
测试用例标识；
被测对象；
测试环境及条件；
测试输入；
操作步骤；
预期输出；
判断输出结果是否符合的标准；
测试对象的特殊需求。
测试报告应具备如下内容：
软件产品标识；
测试环境配置（硬件和软件）
测试依据；
测试结果；
测试问题；
测试时间。
15.4.4软件可靠性的评估和预测
判断是否达到了可靠性目标，是否达到了软件付诸使用的条件，
软件可靠性设计技术主要有容错设计、检错设计、降低复杂度设计等技术。
1、容错设计技术
恢复块设计；
N版本程序设计；
冗余设计；
2、检错技术
采用检错设计技术要着重考虑几个要素：检测对象、检测延时、实现方式、处理方式。
3、降低复杂度设计
第16章文档测试
16.1文档测试的范围
软件产品由可运行的程序、数据和文档组成。文档是软件的一个重要组成部分。
在软件的整人生命周期中，会用到许多文档，在各个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依据。软件文档的分类结构图如下图所示：
软件文档分类包括用户文档、开发文档、管理文档。
用户文档：用户手册、操作手册、维护修改建议；
开发文档：软件需求说明书、数据库设计说明书、概要设计说明书、详细设计说明书、可行性研究报告；
管理文档：项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告。
可行性研究报告：项目在技术、经济和社会因素上的可行性，评述达到目标各种实施方案，说明论证选定方案的理由。
项目开发计划：为软件项目实施方案制定出具体计划，应该包括各部分工作的人员、进度、经费预算、所需硬、软件等。项目开发计划提供给管理部门，作为开发阶段的评审的参考。
软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。是用户与开发人员对软件需求取得共同理解的基础上达成的协议，是实施开发工作的基础。
数据库设计说明书：只对使用数据库的软件适用，该说明书应给出数据库的整体架构及各个数据表中的逻辑关系。
概要设计说明书：它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计奠定基础。
详细设计说明书：
用户手册：本手册详细描述软件的功能、性能和用户界面，使用户了解如何使用该软件。
测试计划：计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
测试计划：计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明。对测试结果加以分析，并提出测试的结论意见。
开发进度月报：该月报是软件人员按月向管理部门提交的项目进展情况报告。报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。
项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力。此外还需对开发工作作出评价，总结出经验和教训。
操作手册：本手册为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。
维护修改建议：软件产品投入运行以后，发现了需对期进行修正、更改等的问题，应将存在的问题、修改的考虑以及修改的估计影响作详细的描述，写成维护修改建议，提交审批。
16.2用户文档的内容
当用户文档仅含一个Readme文件时，文档的测试只需要对其进行拼写检查，确认其中涉到的技术准确无误，最多对Readme文件进行病毒扫描，确保其不带病毒就足够了。
（1）包装上的文字和图案；
（2）宣传材料、广告及其他插页；
（3）授权/注册登记表；
（4）最终用户许可协议；
（5）标签和不干胶条；
（6）安装和设置指导；
（7）用户手册；
（8）联机帮助；
（9）指南、向导。
（10）样例、示例和模板；
（11）错误提示信息。
拼写检查是指在选定文本、一篇完整文章，一个出版物的全部文章，或所有打开的出版物的全部文章中检查和帮助修正拼写和基本的语法错误。
16.3用户文档的作用
对于软件测试人员来说，对待用户文档要像对待程序一样给予同等关注和投入，因为对于用户来说，文档和程序同样重要。
充分有效的文档有如下优点：
（1）改善易安装性。清晰、正确的安装指南是产品文档中最为重要的部分之一。
（2）提高软件的易用性。高效的文档往往是面向任务，有些软件文档面向特征的用户手册会独立地描述功能特征，按菜单顺序，甚至按字母顺序逐个描述功能。
（3）改善软件可靠性。
（4）促进销路。
（5）降低技术支持的费用。不正确的指导会浪费用户不必要的时间和精力，也给开发商增加了法律上的风除。
16.4用户文档测试需要注意的问题
（1）文档常常得不到足够的重视，文档的开发缺乏足够的资金和技术支持，而文档的测试更得不到重视。
（2）编写文档的人可能并不是软件特性方面的专家，对软件功能可能了解得并不深入。保证文档中所包含信息的质量，并随着产品的更新而更新。更重要的是，测试可发现并指出程序中难以使用或难以理解之处，让文档作者在文档中作出更好的解释。
（3）Readme是将最后的改动通知用户的方式。它能使文档保持到最后一刻发布，从而保证与软件程序的同步。
（4）文档测试不仅仅是对文字的校对，更可以辅助找到更多的程序错误。例如：功能实现错误、易用性不好、用户手册与程序实现不吻合等问题。
16.5用户文档测试的要点
文档测试分为两类，若是非程序，其测试可以视为技术校对。如果文档和程序紧密结合，帮助系统，就要进行与程序测试类似的测试。
应像最仔细的用户那样，认真阅读，跟随每个步骤，检查每个图形，？？？
文档测试中，对于如下几个方面需要特别关注。
（1）读者群。
（2）术语。
（3）正确性。
（4）完整性。
（5）一致性。
（6）易用性。
（7）图表与界面截图。
（8）样例和示例。
（9）语言。
（10）印刷与包装。
16.6针对用户手册的测试
在对用户手册进行测试时，应拿着它坐在计算机前，进行如下操作。
准确地按照手册的描述使用程序。检查计算机对错误的处理和手册对错误处理的描述应当占用测试人员的大部分精力。（准确地按照手册的描述使用程序。）
尝试每一条建议。
检查每条陈述。
查找容易误导用户的内容。
16.7针对在线帮助的测试
帮助文档的测试在很大程度上与用户手册测试相同，但帮助并不只是用户手册的电子版，因此再给出以下几点补充说明。
准确性。
帮助是文档编写和程序编写的结合。不仅要检查文本的准确性，还要检查程序的可靠性。
帮助索引。如果帮助系统包含索引或主题列表，允许用户由索引进入到主题中，测试人员就必须逐条进行检查。
超链接。测试人员必须对每个链接都测试到。
链接的意义。索引和链接的条目应当是有意义的，测试人员需要发现是否有一些帮助主题未出现在索引里，或出现的名称不恰当。
帮助的风格。帮助文本需要比用户手册更为简洁，风格更为简单。良好的帮助系统应该是面向任务或面向操作的，它必须提供一些有意义的信息，让用户能立即开始或继续他的操作。
第三篇 测试案例
第17章 功能测试
以业务流和数据流为主驱动的方法设计用例。
第18章 白盒测试
在静态测试中测试内容包括静态结构分析和代码质量度量。
在动态测试中测试内容为覆盖率测试。
第19章数据库测试
数据库发展的特点是概括为“四高”：数据库管理系统具有高可靠性、高性能、高可伸缩性和高安全性。
数据库管理系统测试分解为四个方面：产品确认测试、标准符合性测试、基准性能测试和应用综合测试。
产品确认测试内容：
1、系统功能测试
（1）安装与配置
（2）数据库存储管理
（3）模式对象管理
2、可靠性测试
（1）数据库备份
（2）故障恢复
（3）运行稳定性
（4）数据库复制
3、安全性测试
（1）用户及口令管理
（2）授权和审计管理
4、扩展性测试
（1）数据库系统的跨平台支持
（2）CPU加速比
第20章 负载压力测试及故障定位与分析
1、测试需求分析
系统实施两次性能测试。第一次性能测试为性能检测与故障定位；第二次性能测试为对调优之后的效果进行评估。
局域网测试主要内容：重点定位应用系统以及软、硬件支撑环境故障。
广域网测试主要内容：重点测试网络环境对应用系统的影响，定位网络故障，分析网络品质。
（2）UCML负载压力需求分析方法
3、测试案例分析要素
（1）任务分布情况
主要关注如下内容。
交易任务种类；
在一天的某些特定时刻系统都有哪些主要操作。
（2）交易混合情况
主要关注的内容包括：
系统日常业务主要有哪些操作，高峰期主要有哪些操作。
数据库操作有多少。
如果任务失败，那么商业风险有多少。
（3）用户概况
主要关注的如下内容：
哪些任务是每个用户都要执行的。
针对每个用户组，不同任务的比例如何。
4、测试结果处理与分析
测试原始数据的统计与整理；
测试结果分析；
测试故障定位。
（1）测试报告
在第一次性能测试结束时，出故障定位测试报告。第二次性能测试结束时，出性能测试与评估报告。
（2）结论
并发执行报错主要包括：网络传输错误、请求超时错误以及服务器响应错误。
附测试工具介绍
1、配置/过程管理工具
TestDirector：测试管理系统
AllChange：变更管理和配置管理集成一体
IRqA：需求管理工具
DOORS：需求管理工具
CM Synergy：基于任务的配置管理
ChangeSynergy：变更需求跟踪和报告系统
McCabe TrueChange：软件配置管理工具
T-Plan：测试过程管理工具
2、功能测试工具
WinRunner、SilkTest
3、性能测试工具（系统强度测试工具）
LoadRunner、SilkPerformer
Benchmark factory：高扩展性的强化测试、容量规划和性能优化工具
JProbe：J2EE性能测试和诊断工具
4、白盒、嵌入式测试工具
TAU Logiscope：嵌入式软件测试工具集
McCabe IQ：静态分析/软件质量度量工具集
PRQA C/C++：代码规则静态检测工具
C Verifier：C程序验证器
ASG-SmartTest
Cantata++：单元/集成测试工具
UniTester：汇编语言单元测试工具
5、软件开发工具
Telelogic TAU Generation2：基于UML2.0语言的系统工程和软件工程开发环境。
Real-Time Studio：适合于多用户进行项目开发的开发工具。
6、其他
SilkTest International：测试平台
Bender-RBT：需求分析/测试用例生成工具
ADS-2系统测试平台
Datafactory数据库装载工具
EasyLinux Development Kit for ARM
7、仪器仪表
安捷伦N3900A模块化光网络测试仪
FrameScope350局域网性能分析仪
LANpilot掌上型网络分析仪
SuperLink网络测试仪
WireScope350线缆认证测试仪
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
