系统分析师学习笔记（十五）

系统实现与测试

系统实现概述

程序设计方法

1.结构化程序设计
SP采用自顶向下、逐步求精的设计方法和单入口、单出口的控制结构。在设计一个模块的实现算法时，先考虑整体后考虑局部，先抽象后具体，通过逐步细化，最后得到详细的实现算法。

单入口、单出口的控制结构，使程序的静态结构和动态执行过程一致，具有良好的结构，增强了程序的可读性。

任何单入口、单出口、没有死循环的程序都能用三种基本的控制结构来构造，这三种基本的控制结构是顺序结构、IF_THEN_ELSE型分支结构（选择结构）和DO_WHILE型循环结构。

2.面向对象的程序设计
OOP是OO方法学从诞生、发展到走向成熟的第一片领地，也是使OO方法最终落实的重要阶段。在一个比较理想的OOP程序中，问题域中有哪些值得注意的事物，程序中就有哪些对象；问题域中的事务之间是什么关系，程序中的对象之间就具有什么关系。

3.面向方面的程序设计
面向方面的程序设计（Aspect-Oriented Programming，AOP）是一种通过预编译方式和运行期动态代理技术，实现在不修改源代码的情况下为程序动态、统一添加功能的程序设计技术。

4.可视化程序设计
利用程序设计工具所提供的各种控件，像搭积木式地构造应用程序的各种界面。这种程序设计方法称为可视化程序设计（Visual Programming，VP）。VP最大的优点是程序员可以不用编写或只需编写很少的程序代码，就能完成应用程序的设计，从而极大地提高设计人员的工作效率。

程序设计语言与风格

1.程序设计语言的选择
选择OOPL时，还应重点考虑其是否支持OO方法的主要特征，以及类库和开发环境等。

（1）封装性。封装是一种信息隐蔽技术，是指将数据和算法捆绑成一个整体，存取数据时只需知道其算法的外部接口，而无须了解数据的内部结构。C++通过建立类来支持封装性和信息隐蔽。
（2）继承性。继承性是指一种事物保留了另一种事物的全部特征，并且具有自身的独有性质。C++采用继承来支持复用。
（3）多态性。多态性是指当多种事物继承自同一种事物时，同一操作在它们之间表现出不同的行为。C++使用函数重载、模板和虚函数等概念来支持多态性。

2.程序设计风格

（1）与可理解性相关的良好程序设计风格包括有意义的标识符、详细的注解和程序的视觉组织、清晰规范的数据说明和简单明了的语句构造，以及有效、合理、交互化与可视化的I/O设计等。
（2） 与可复用性相关的良好程序设计风格包括提高功能的内聚、减小功能的规模、保持功能的一致性、将接口与实现分开、尽量不使用全局变量和利用继承机制等。
（3）与可扩展性相关的良好程序设计风格包括封装实现策略、利用多态性机制、避免使用多分支语句和精心设计公有服务等。
（4） 与健壮性相关的良好程序设计风格包括预防用户的错误操作、检查参数的合法性、不要预先确定限制条件和先测试后优化等。

软件测试概述

软件测试的目的是验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。通过测试，发现软件缺陷，为软件产品的质量测量和评价提供依据。

测试用例设计的原则有基于测试需求的原则、基于测试方法的原则、兼顾测试充分性和效率的原则、测试执行的可再现性原则；每个测试用例应包括名称和标识、测试追踪、用例说明、测试的初始化要求、测试的输入、期望的测试结果、评价测试结果的准则、操作过程、前提和约束、测试终止条件。

测试自动化

1.自动化测试的特点
自动化测试具有如下优点：

（1）提高测试执行的速度。以测试人员执行一个测试用例为例，阅读测试步骤需要20秒，理解测试目的需要5秒，准备测试数据需要10秒，执行测试需要5秒，填写测试结果需要10秒。也就是说，不包括系统等待时间，以及可能有错误需要报告错误的时间，测试人员执行一个测试用例平均需要大约50秒的时间。如果一次性准备好以上所需的脚本和测试数据，然后用测试工具来完成同样的工作，5秒钟即可达到同样效果。
（2）提高工作效率。由于自动化测试工具的运行，节省出的时间可以让测试人员重新计划和安排测试工作，设计新的测试用例，开发新的测试工具。
（3）保证测试结果的准确性。测试过程是枯燥而繁琐的，任何一点疏忽都可能导致测试结果不准确而需要返工。而测试工具不同，完成的脚本会准确地记录测试过程中发生的一切。
（4）连续运行测试脚本。测试工具可以24小时运行测试脚本，不间断的进行测试，这是测试人员所不能比拟的。而测试人员要做的就是第二天早上收集测试数据，看看系统有哪些问题。
（5）模拟现实环境下受约束的情况。测试过程基本上是模拟真实环境执行相关操作，然而有些情况是很难完全模拟的。

2.测试用例的生成
脚本的基本结构主要有以下五种：

（1）线性脚本。线性脚本是录制手工测试的测试用例时得到的脚本，这些脚本是未作修改的。
（2）结构化脚本。结构化脚本类似于SP，具有各种逻辑结构，包括选择型结构、分支结构、循环迭代结构，而且具有函数调用功能。结构化脚本具有很好的可用性和灵活性，易于维护。
（3）共享脚本。共享脚本是指一个脚本可以被多个测试用例使用，即脚本语言允许一个脚本调用另一个脚本。
（4）数据驱动脚本。数据驱动脚本是指将测试输入存储在独立的数据文件中，而不是脚本中。这样，脚本可以针对不同的数据输入实现多个测试用例。
（5）关键字驱动脚本。关键字驱动脚本是数据驱动脚本的逻辑扩展，它用测试文件描述测试用例，它说明测试用例做什么，而不是如何做。关键字驱动脚本允许使用描述性的方法，只需要提供测试用例的描述，即可生成测试用例。

3.自动化测试工具

（1）单元测试工具。单元测试工具主要包括C/C++测试工具（例如，Panorama C++和C++Test等）、Java开源测试框架JUnit、内存资源泄漏检查工具（例如，Numega的BounceChecker和Rational的Purify等）、代码覆盖率检查工具（例如，Numega的TrueCoverage、Rational的PureCoverage和TeleLogic的LogiScope等）、代码性能检查工具（例如，LogiScope的Macabe等）和软件纠错工具（例如，Rational Purl等）。
（2）负载和性能测试工具。负载和性能测试工具是软件测试中作用最大的工具，可以完成一些难以用手工实现的测试，常用工具包括Mercury Interactive的LoadRunner和Compuware的QALoad，以及IBM Rational的SQA Load、Performance和Visual Quality。
（3）GUI功能测试工具。GUI功能测试工具主要用于回归测试，主要工具包括MercuryInteractive的WinRunner和Compuware的QARun，以及IBM Rational的SQA Robot和Microsoft的Visual Test Suite等。
（4）基于Web应用的测试工具。基于Web应用的测试工具主要进行链接检查、HTML检查、Web功能和安全性等方面的测试。主要的测试工具包括MI公司的Astra系列和RSW公司的E-TestSuite，以及WorkBench、Web Application Stress（WAS）Tool和Link Sleuth等。

软件调试

软件调试是一个相当艰苦的过程，究其原因，除了开发人员心理方面的障碍外，还因为隐藏在程序中的错误具有下列特殊的性质：

（1）错误的外部征兆远离引起错误的内部原因，对于高度耦合的程序结构，此类现象更为严重。
（2）纠正一个错误造成了另一个错误现象（暂时）的消失。
（3）某些错误征兆只是假象。
（4）因操作人员一时疏忽造成的某些错误征兆不易追踪。
（5）错误是由于分时而不是程序引起的。
（6）输入条件难以精确地再构造（例如，某些实时应用的输入次序不确定）。
（7）错误征兆时有时无，此现象对嵌入式系统尤其普遍。
（8）错误是由于把任务分布在若干台不同处理机上运行而造成的。

1.排错的方法

（1）蛮力法（brute force）。蛮力法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它，其主要思想是“通过计算机找错”。例如，输出存储器、寄存器的内容，在程序中安排若干个输出语句等，凭借大量的现场信息，从中找到出错的线索。虽然最终也能成功，但难免要耗费大量的时间和精力。
（2）回溯法（backtracking）。回溯法是从出现错误征兆处开始，人工沿控制流程往回追踪，直至发现出错的根源。不幸的是，程序变大后，可能的回溯路线显着增加，以致人工进行完全回溯可望而不可及。
（3）原因排除法（cause eliminations）。原因排除法是通过演绎和归纳，以及二分法来实现的。对和错误发生有关的数据进行分析，可寻找到潜在的原因。先假设一个可能的错误原因，然后利用数据来证明或者否定这个假设；也可以先列出所有可能的原因，然后进行检测来一个个地进行排除。如果最初的测试表明某个原因看起来很象的话，那么就要对数据进行细化来精确定位错误。

2.与软件测试的区别
软件调试与测试的区别主要体现在以下几个方面：

（1）测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误。
（2）调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同。
（3）测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；调试从一个未知的条件开始，结束的过程不可预计。
（4）测试过程可以事先设计，进度可以事先确定；调试不能描述过程或持续时间。

软件测试方法

软件测试方法可分为静态测试和动态测试，其中动态测试一般采用白盒测试和黑盒测试方法。

静态测试

静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。

1.桌前检查
由程序员检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析和检验，并补充相关的文档，目的是发现程序中的错误。

2.代码审查
代码审查是由若干程序员和测试人员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查的过程可以分为两个步骤：

第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查是否存在错误。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。

3.代码走查
代码走查与代码审查基本相同，其过程也分为两个步骤：

第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。
第二步，开会的程序与代码会审不同，不是简单地读程序和对照错误检查单进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用。

4.静态分析
在静态测试中，主要是对程序代码进行静态分析，包括控制流分析、数据流分析、接口分析和表达式分析。

（1）控制流分析。控制流分析是指使用控制流程图检查被测程序控制结构的过程。
（2）数据流分析。数据流分析是指使用控制流程图分析数据各种异常情况的过程，包括数据初始化、赋值或引用过程中的异常。
（3）接口分析。接口分析主要包括模块之间接口的一致性分析、模块与外部数据库及其他软件配置项之间的一致性分析、子程序和函数之间的接口一致性分析等。
（4）表达式分析。表达式分析用于检查程序代码中的表达式错误。

白盒测试

白盒测试也称为结构测试，主要用于软件单元测试阶段。它的主要思想是，将程序看作是一个透明的白盒，测试人员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按预定要求正确工作。

1.控制流测试
控制流测试根据程序的内部逻辑结构设计测试用例，常用的技术是逻辑覆盖，即使用测试数据运行被测程序，考察对程序逻辑的覆盖程度。

（1）语句覆盖。语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。很显然，语句覆盖是一种很弱的覆盖标准。
（2）判定覆盖。判定覆盖也称为分支覆盖，它是指不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）都至少执行一次。判定覆盖比语句覆盖强，但对程序逻辑的覆盖程度仍然不高。
（3）条件覆盖。条件覆盖是指不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取得各种可能的结果。条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖。
（4）条件/判定覆盖。同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。它的含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。
（5）条件组合覆盖。条件组合覆盖是指选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。显然，满足条件组合覆盖的测试用例，也一定满足判定/条件覆盖。因此，条件组合覆盖是上述5种覆盖标准中最强的一种。然而，条件组合覆盖还不能保证程序中所有可能的路径都至少遍历一次。
（6）修正的条件/判定覆盖。修正的条件/判定覆盖需要足够的测试用例来确定各个条件能够影响到包含的判定结果。首先，每个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and和or）连接的布尔条件，每个条件对于判定的结果值是独立的。
（7）路径覆盖。路径覆盖是指选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路路径至少经过一次）。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件覆盖和条件组合覆盖。

2.数据流测试
数据流测试使用控制流程图对变量的定义和引用进行分析，可以发现的错误包括引用未定义的变量、未曾使用的定义、对未使用变量再次赋值、数组越界或条件判断中的条件错误、不正常的程序执行路径、不可执行的代码等。

3.程序变异测试
程序变异测试是一种错误驱动测试，是针对某类特定程序错误的。错误驱动测试主要有两种，即程序强变异和程序弱变异。

给定一个程序P 和一个测试数据集T，程序变异测试的测试过程由如下步骤组成：

（1）产生被测程序P的一组变异体（mutant）。将程序P代码中的一处作合乎语法的变更，所产生的程序就是程序P的一个变异体。
（2）对原来的程序及其变异体都使用同一组测试数据进行测试，并记录它们在每一个输入值上的输出结果。如果一个变异体在某个输入上与原来的程序产生不同的输出值，则称该变异体被该输入数据“杀死”了。若一个变异体在所有的测试数据上都与原来的程序产生相同的输出，则称其为“活的”。
（3）对活的变异体进行分析，检查其是否与原来的程序等价。
（4）对与原来的程序不等价的变异体进行进一步的测试，直至充分性度量达到令人满意的程度。

一个变异体可能在两种情况下是活的：第一，它可能等价于原来的程序；第二，测试数据可能不够充分。如果有大量的变异体是活的，那么就没有理由仅从测试结果来说明这些变异体是错误的而原来的程序是正确的。从这个意义上来说，程序变异能够揭示一个测试数据集的弱点。在变异体充分度较低的情况下，应该产生一批新的测试数据，进行进一步的测试，直至充分度达到令人满意的程度。

黑盒测试

黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试阶段。黑盒测试将软件看作是一个不透明的黑盒，完全不考虑（或不了解）程序的内部结构和处理算法，而只检查软件功能是否能按照SRS的要求正常使用，软件是否能适当地接收输入数据并产生正确的输出信息，软件运行过程中能否保持外部信息（例如，文件和数据库等）的完整性等。

黑盒测试根据SRS所规定的功能来设计测试用例，一般包括功能分解、等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。

1.功能分解
功能分解是将SRS中的每个功能加以分解，确保各个功能被全面测试。首先使用程序设计中的功能抽象方法把程序分解为功能单元，然后使用数据抽象方法产生测试每个功能单元的数据。

2.等价类划分
在设计测试用例时，等价类划分是用得最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合，对于一个等价类中的输入值来说，它们揭示程序错误的作用是等效的。也就是说，如果等价类中的一个输入数据能检测出一个错误，那么等价类中的其他输入数据也能检测出同一个错误；反之，如果等价类中的一个输入数据不能检测出某个错误，那么等价类中的其他输入数据也不能检测出这一错误（除非这个等价类的某个子集还属于另个一等价类）。

如果一个等价类内的数据是符合要求的、合理的数据，则称这个等价类为有效等价类。有效等价类主要用来检验软件是否实现了SRS中规定的功能；如果一个等价类内的数据是不符合要求的、不合理或非法的数据，则称这个等价类为无效等价类。无效等价类主要用来检验软件的容错性。

在黑盒测试中，利用等价类划分方法设计测试用例的步骤是：

（1）根据软件的功能说明，对每一个输入条件确定若干个有效等价类和若干个无效等价类，并为每个有效等价类和无效等价类编号。
（2）设计一个测试用例，使其覆盖尽可能多的尚未被覆盖的有效等价类。重复这一步，直至所有的有效等价类均被覆盖。
（3）设计一个测试用例，使其覆盖一个尚未被覆盖的无效等价类。重复这一步，直至所有的无效等价类均被覆盖。

3.边界值分析
经验表明，软件在处理边界情况时最容易出错。设计一些测试用例，使软件恰好运行在边界附近，暴露出软件错误的可能性会更大一些。在实际测试工作中，将等价类划分法和边界值分析法结合使用，能更有效地发现软件中的错误。

4.判定表
判定表最适合描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同的动作。判定表通常由以下四个部分组成：

（1）条件桩。条件桩列出问题的所有条件，通常认为列出的条件次序无关紧要。
（2）动作桩。动作桩列出问题规定可能采取的操作，这些操作的排列顺序没有约束。
（3）条件项。条件项列出针对条件桩中条件的取值，在所有可能情况下的真假值。
（4）动作项。动作项列出在条件项的各种取值情况下应该采取的动作。

5.因果图
因果图法根据输入条件与输出结果之间的因果关系来设计测试用例，它首先检查输入条件的各种组合情况，并找出输出结果对输入条件的依赖关系，然后，为每种输出条件的组合设计测试用例。

6.状态图
一个程序的功能说明通常由静态说明和动态说明组成。前者描述了输入条件与输出条件之间的对应关系，后者描述了输入数据的次序或迁移的次序。在状态图中，由输入数据和当前状态共同决定输出数据和后续状态。根据状态图设计测试用例可以弥补静态逻辑功能模型的不足。

7.随机测试
随机测试是指测试输入数据是在所有可能输入值中随机选取的，测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难，多用于可靠性测试和系统强度测试中。

8.错误推测
错误推测法主要依靠测试人员的经验和直觉，从各种可能的测试用例中选出一些最可能引起程序出错的用例。

9.正交实验法
正交实验法是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种设计方法。利用正交实验法设计测试用例时，首先要根据被测软件的SRS，找出影响功能实现的操作对象和外部因素，并将其当作因子，而把各个因子的取值当作状态，生成二元的因素分析表。然后，利用正交表进行各因子的状态组合，构造有效的测试输入数据集，并由此建立因果图。这样，得出的测试用例数目将大大减少。

测试的类型

软件测试可分为单元测试、集成测试、配置项测试、系统测试、验收测试和回归测试等类别。

单元测试

1.单元测试基础
单元测试着重从模块接口、局部数据结构、重要的执行通路、出错处理通路和边界条件等方面对模块进行测试。模块的内聚程度高可以简化单元测试过程。如果每个模块只完成一种功能，则需要的测试用例数目将明显减少，模块中的错误也更容易预测和发现。

2.单元测试策略
单元测试策略主要包括自顶向下的单元测试、自底向上的单元测试、孤立测试和综合测试策略。

（1）自顶向下的单元测试。自顶向下的单元测试先测试上层模块，再测试下层模块。由于测试下层模块时它的上层模块已测试过，所以不必另外编写驱动模块。
（2）自底向上的单元测试。自底向上的单元测试先测试下层模块，再测试上层模块。由于测试上层模块时它的下层模块已测试过，所以不必另外编写桩模块。
（3）孤立测试。孤立测试不需要考虑每个模块与其他模块之间的关系，逐一完成所有模块的测试。由于各模块之间不存在依赖性，单元测试可以并行进行，但因为需要为每个模块单独设计驱动模块和桩模块，增加了额外的测试成本。
（4）综合测试。上述三种单元测试策略各有利弊，一种方法的优点恰好对应于另一种方法的缺点，实际测试时可根据软件特点和进度安排情况，将几种测试方法混合使用。

3.单元测试分析
单元测试分析一般应采用静态测试分析与动态测试分析相结合的方法。

集成测试

集成测试的目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。集成测试的技术依据是软件概要设计文档。除应满足一般的测试准入条件外，进行集成测试前还应确认待测试的模块均已通过单元测试。

1.集成测试策略
集成测试的策略主要包括基于分解的集成策略、基于功能的集成策略和基于调用图的集成策略等。

（1）基于分解的集成策略。基于分解的集成策略可分为非渐增式和渐增式两种。非渐增式集成测试也称大突击测试或一次性集成测试，是先测试所有的模块，然后一次性把所有模块集成到一起，将程序作为一个整体来测试；渐增式集成测试是将单元测试和集成测试合并到一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它与已经测试好的模块组合在一起进行测试，每次增加一个模块，直到所有模块被集成在程序中。
（2）基于功能的集成策略。基于功能的集成策略是从软件功能角度出发，按照功能的关键程度组织模块的集成顺序。首先，确定功能的优先级别；然后，分析优先级最高的功能路径，把该路径上的所有模块集成到一起，必要时使用驱动模块和桩模块；最后，增加一个关键功能，重复上面的步骤，直到所有模块都被集成到被测系统中。
（3）基于调用图的集成策略。模块调用图是一种有向图，结点表示程序模块，边表示程序调用。基于调用图的集成方式有两种，即成对集成和相邻集成。成对集成是指对应调用图的每条边建立并执行一个集成测试会话，使用实际代码来代替驱动模块和桩模块；相邻集成就是对每个邻居建立并执行一个测试会话，使用实际代码来代替驱动模块和桩模块，从而减轻驱动模块和桩模块开发的工作量。

2.集成测试分析
在进行集成测试设计之前，应首先进行集成测试分析。集成测试分析既包括对被测软件本身的分析（例如，架构分析、模块分析和接口分析等），也包括对测试可行性和测试策略的分析。

（1）软件特性分析。根据软件设计文档（含接口设计文档）规定的软件功能、性能、状态、接口、数据结构和设计约束等要求，分析确定集成测试中需要测试的软件特性。
（2）架构分析。架构分析一般分为两步，首先，跟踪需求分析，对要实现的系统划分出结构层次图；其次，分析各个构件之间的依赖关系，据此确定集成测试模块的大小。
（3）模块分析。一个合理的集成模块划分应该满足以下几点：被集成的模块之间的关系必须密切；可以方便地隔离集成模块的外围模块；能够简便地模拟外围模块向集成模块发送消息；外围模块向集成模块发送的消息能够模拟实际环境中的大多数情况。
（4）接口分析。软件系统中的接口可以划分为内部接口和外部接口两大类。内部接口是指系统内部各模块交互的接口，这是集成测试的重点。内部接口主要包括函数或方法接口、消息接口、类接口和其他接口；外部接口是指系统与外部（硬件、人和其他软件）交互的接口，这类接口的测试一般会延续到系统测试阶段来完成。接口分析的重点是对穿越接口的数据进行分析，在数据分析的过程中，可以直接产生测试用例。
（5）可测试性分析。可测试性是软件系统的重要特性之一，可测试性分析应该在需求分析阶段进行。在集成测试阶段，分析可测试性主要是为了平衡随着集成范围的增加而导致的可测试性下降。
（6）测试充分性分析。根据软件的重要性和完整性级别，分析确定集成测试应覆盖的范围和每个范围所要求的覆盖程度。
（7）测试终止条件分析。分析和确定集成测试过程正常终止和异常终止的条件。
（8）测试技术分析。分析和确定集成测试需要的技术与方法，例如，测试数据生成与验证技术、测试数据输入技术、测试结果获取技术和增量测试的集成策略等。
（9）测试资源分析。分析和确定用于集成测试的资源要求，例如，硬件资源、软件资源和人力资源等。
（10）风险分析。对集成测试进行风险分析与评估，并制订应对措施。

系统测试

系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。系统测试的技术依据是用户需求或开发合同，除应满足一般测试的准入条件外，在进行系统测试前，还应确认被测系统的所有配置项已通过测试，对需要固化运行的软件还应提供固件。

一般来说，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。

1.性能测试的目的
性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，并优化软件，最后起到优化系统的目的。具体来说，包括以下四个方面：

（1）发现缺陷。软件的某些缺陷与软件性能密切相关，针对这些缺陷的测试一般需要伴随着性能测试进行。
（2）性能调优。与调试不同，性能调优并不一定针对发现的性能缺陷，也可能是为了更好地发挥系统的潜能。
（3）评估系统的能力。软件性能测试不仅需要测试软件在规定条件下是否满足性能需求，往往还需要测试能够满足性能需求的条件极限。
（4）验证稳定性和可靠性：在一定负载下测试一定的时间，是评估系统稳定性和可靠性是否满足要求的唯一方法。

2.性能测试的分类
根据测试目的不同，性能测试主要包括压力测试、负载测试、并发测试和可靠性测试等。

（1）负载测试和压力测试。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或不能接收的性能点，来获得系统能提供的最大服务级别的测试。负载测试和压力测试可以结合进行，统称为负载压力测试。
（2）强度测试。强度测试是在系统资源特别低的情况下考查软件系统运行情况。
（3）并发测试。并发测试也称为容量测试，主要用来确定系统可处理的同时在线的最大用户数。
（4）可靠性测试。可靠性测试是指通过测试系统可靠性的各种指标（例如，MTTF和可用性等），来验证系统的可靠性。

3.性能测试通用模型
PTMG（Performance Testing General Model，性能测试通用模型）是关于性能测试过程的一个模型，其主要步骤包括测试前期的准备、引入测试工具、制定测试计划、测试设计与开发、测试执行与管理，以及测试结果分析。

4.性能测试分析
性能测试分析包括性能下降曲线的分析和性能计数器的分析。性能计数器分析的重点是观察参数，包括内存、处理器、磁盘I/O和进程等；性能下降曲线指的是性能指标随用户数的增加而变化的曲线，如果随着用户数的增加而下降，则称为性能下降曲线。在分析的时候会将曲线划分为不同的区间：

（1）性能平坦区。性能平坦区表示软件运行的正常状态，其表现为：随着用户数增加，平均响应时间基本不变或略有增加，吞吐量保持明显上升的区间。
（2）性能轻微下降区。性能轻微下降区是性能接近临界值时的曲线表示，其表现为：随着用户数增加，平均响应时间开始明显增加；而吞吐量基本不上升，甚至开始下降。通常把平坦区和轻微下降区交界处的用户数量定义为最大建议用户数，也就是系统容量的快照。
（3）性能急剧下降区。性能急剧下降区是超过系统能力区间时的曲线表示，其表现为：随着用户数的增加，响应时间超过用户容忍范围；吞吐量也急剧下降。观察性能急剧下降区的目的是为了定义性能瓶颈。

其他测试类型

1.配置项测试
配置项测试的对象是软件配置项，配置项测试的目的是检验软件配置项与SRS的一致性。配置项测试的技术依据是SRS（含接口需求规格说明）。除应满足一般测试的准入条件外，在进行配置项测试之前，还应确认被测软件配置项已通过单元测试和集成测试。

2.确认测试
确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度，通常包括以下四种类型：

（1）内部确认测试。内部确认测试主要由软件开发组织内部按照SRS进行测试。
（2）Alpha测试和Beta测试。对于通用产品型的软件开发而言，Alpha测试是指由用户在开发环境下进行测试，通过Alpha测试以后的产品通常称为Alpha版；Beta测试是指由用户在实际使用环境下进行测试，通过Beta测试的产品通常称为Beta版。一般在通过Beta测试后，才能把产品发布或交付给用户。
（3）验收测试。验收测试是指针对SRS，在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。验收测试的目的是，在真实的用户工作环境下，检验软件系统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外，在进行验收测试之前，应确认被测软件系统已通过系统测试。

3.回归测试
回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。回归测试的对象主要包括以下四个方面：

（1）未通过软件单元测试的软件，在变更之后，应对其进行单元测试。
（2）未通过配置项测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试和配置项测试。
（3）未通过系统测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试、配置项测试和系统测试。
（4）因其他原因进行变更之后的软件单元，也首先应对变更的软件单元进行测试，然后再进行相关的软件测试。

面向对象系统的测试

面向对象系统的测试策略

1.OOA的测试
OOA直接映射问题空间，将问题空间中的实例抽象为对象，用对象的结构反映问题空间的复杂实例和复杂关系，用属性和操作表示实例的特性和行为。OOA的结果是为后续阶段类的实现、类层次结构的组织和实现提供平台。对于一般的分析模型，可以从两个方面进行测试，分别是测试分析模型是否满足软件需求，以及测试分析模型是否符合OO方法的要求。

2.OOD的测试
OOA和OOD的测试方式与软件分析设计模型的形式密切相关，如果分析设计模型完全是纸面的（即分析设计文档），测试主要以文档审查的方式进行；如果分析设计模型的整体或部分可以模拟运行，测试还可以建立在模拟运行的基础上。

3.OOP的测试
OO系统的开发过程通常是一个迭代与渐进的过程，其测试活动也是迭代与渐进的。测试活动实际上只是一系列相关测试任务的集合，时间上并不一定是连贯的，测试活动之间也是犬牙交错而非首尾相接的。一般情况下，在系统渐进的每一步，都应循环地执行各个测试活动中的某些任务。也就是说，OO系统的测试，实际上是一个螺旋式上升的过程。

面向对象系统的单元测试

OO系统的单元测试包括方法层次的测试、类层次的测试和类树层次的测试。

1.方法层次的测试
方法层次的测试类似于传统软件测试中对单个函数的测试，常用的测试技术包括等价类划分测试、组合功能测试（基于判定表的测试）、递归函数测试和多态消息测试等。

2.类层次的测试
OO系统很难对单个成员方法进行充分的测试，具有良好封装性的类成为单元测试的基本对象。类层次的测试主要包括不变式边界测试、模态类测试和非模态类测试。

（1）不变式边界测试。类的属性的某些状态可能不会出现，称为类不变式。不变式边界测试首先要准确定义类的不变式，其次再寻找方法的调用序列以违反类不变式，这些调用序列即可作为测试用例。
（2）模态类测试。模式类是指该类处于特定的状态下时，只能接受对某些特定方法的调用。通常要对类的状态进行建模，获得状态图，并根据状态图生成调用序列来覆盖状态图上的边和路径，每个调用序列可以作为该类的一个测试用例。
（3）非模态类测试。非模态类是指该类处于任何状态下时，均可接受对所有方法的调用。非模态类的测试策略有两种，分别是随机生成方法的调用序列，以及针对性地生成方法的调用序列。

3.类树层次的测试
类树层次的测试主要包括多态服务测试和展平测试。多态服务测试是指在对子类进行测试时，从其父类测试用例集（如果已存在）中选取涉及多态方法的测试用例，并把子类的实例当作父类的实例进行测试；展平测试是指将子类自身定义的方法和属性，以及从父类和祖先类继承来的方法和属性组成一个新类，并对其进行测试。

面向对象系统的集成测试

1.传统的集成测试策略
OO系统的集成测试可以借鉴传统软件测试中所应用的几种行之有效的集成测试策略。

（1）大突击集成。大突击集成是一种非渐增式集成，通常先测试所有的类，然后把所有类一次集成到一起进行测试。大突击集成的优点是可以提高测试效率，其缺点是测试难以充分进行，增加了调试难度。只有在整个软件的可靠性有了基本保障时，才可以考虑大突击集成测试。
（2）自底向上集成与自顶向下集成。自底向上集成与自顶向下集成均为渐增式集成，每次按某种次序选择一个（或几个）尚未测试的类，与已经测试好的类集成在一起进行测试，直到所有的类被集成。自底向上集成先测试底层类（不依赖于其他类的类），再测试上层类（依赖于已测试类的类）。由于在测试上层类时它所依赖的下层类已测试过，所以不必编写测试桩代码，但需要开发大量的测试驱动代码；自顶向下集成先测试上层类，再测试下层类。由于在测试下层类时它的上层类已测试过，所以不必另外编写测试驱动代码，但需要开发大量的测试桩代码。
（3）夹层式集成。夹层式集成是针对层次结构风格的软件系统所采用的集成策略。集成时可以从底层或顶层开始，每次向上或向下集成新的一层；也可以从底层和顶层同时开始向上和向下集成，最后集成某一中间层。夹层式集成也需要开发大量的测试驱动代码或（和）测试桩代码。

2.协作集成
协作集成是指在集成测试时针对系统完成的功能，将可以相互协作完成特定系统功能的类集成在一起进行测试。协作集成的优点是，开发测试驱动代码和测试桩代码的开销较少，其缺点是在协作关系比较复杂、被测集成体很大时，测试难以充分进行；与自底向上集成和自顶向下集成相比，协作集成通常是不完备的。协作集成的选择前提是，类间的主要协作关系可以明确辩识，以及每个功能只需要少数类协作即可完成。

3.基于使用的集成
基于使用的集成首先测试那些几乎不使用其他类的类（称为独立类）并开始构造系统，在独立类测试完成后，再测试下一层的使用独立类的类（称为依赖类）。这个依赖类层次的测试序列一直持续到构造完整个系统。基于使用集成的优缺点类似于自底向上的集成。

4.类之间连接的测试
集成策略确定之后，还需要关注如何充分测试类之间的各种连接，包括类关联的多重性测试、受控异常测试、往返场景测试和模态机测试。

（1）类关联的多重性测试。在OO系统中，类之间的关联关系存在多重性方面的限制。多重性测试关注的重点是与连接关系有关的增、删、改操作，通常可考虑可能会导致多重性限制被破坏的调用序列构成的测试用例。测试时还应注意连接的实现方式，因为特定的实现会隐含特定的多重性。
（2）受控异常测试。OO系统允许出现异常情况时控制流跳转到特定的位置。由于异常的抛出和接收可以被放在不同的类中，实际上形成了类之间隐含的依赖关系，测试时需要尽可能地覆盖这些隐式的依赖关系。有时需要编写异常模拟程序用来产生这些异常，以便测试到异常的处理代码。
（3）往返场景测试。在OO系统中，一段代码可能用于多个场景，充分的测试应该保证该段代码在每个场景的测试中都得到完全的覆盖。往返场景测试就是把与实现特定场景相联系的代码抽取出来，针对这些代码设计具有完全覆盖的测试用例集。往返场景测试可以不基于代码而基于顺序图，从而使测试人员在设计测试用例时更关注类之间的交互关系和控制结构。
（4）模态机测试。模态机测试类似于类层次的模态类测试，但模态类测试只针对一个类，而模态机测试则针对多个类，实际上是把多个类看作是一个大的模态类，而且该类遵循一个全局的状态图。

软件测试的组织

科学的组织与有效的管理，是软件测试成功的重要保证。

1.测试的组织

（1）单元测试一般由软件的供方或开发组织并实施，也可委托第三方进行。
（2）集成测试一般由软件供方组织并实施，测试人员与软件开发应相对独立，也可委托第三方进行。
（3）软件配置项测试应保证其独立性，一般由软件的供方组织，由独立于软件开发的人员实施，软件开发人员配合。如果配置项测试委托第三方实施，一般应委托国家认可的第三方测试机构。
（4）系统测试按合同规定要求执行，一般由软件的需方或软件的开发方组织，由独立于软件开发的人员实施，软件开发人员配合。如果系统测试委托第三方实施，一般应委托国家认可的第三方测试机构。
（5）验收测试应由软件的需方组织，由独立于软件开发的人员实施。如果验收测试委托第三方实施，一般应委托国家认可的第三方测试机构。
（6）回归测试的组织管理与其所对应软件测试类别的组织管理相同或相似。

2.测试的过程
软件测试的过程一般包括测试策划、测试设计、测试执行和测试总结等四项活动。

（1）测试策划。测试策划主要是进行测试需求分析，包括确定需要测试的内容或质量特性；确定测试的充分性要求；提出测试的基本方法；确定测试的资源和技术需求；进行风险分析与评估；制定测试计划。
（2）测试设计。测试设计的主要工作包括依据测试需求，分析并选用已有的测试用例或设计新的测试用例；获取并验证测试数据；根据测试资源、风险等约束条件，确定测试用例执行顺序；获取测试资源，开发测试软件；建立并校准测试环境；进行测试就绪评审，主要评审测试计划的合理性和测试用例的正确性、有效性和覆盖充分性，评审测试组织、环境和设备工具是否齐备并符合要求。
（3）测试执行。测试执行的主要工作包括执行测试用例，获取测试结果；分析判定测试结果，并根据不同的结果采取相应的措施；对测试过程的正常或异常终止情况进行核对，并根据核对结果，对未达到测试终止条件的测试用例，决定是停止测试，还是需要修改或补充测试用例集，并进一测试。
（4）测试总结。测试总结的主要工作包括整理和分析测试数据；评价测试效果，描述测试状态（包括实际测试与测试计划的差异、测试充分性分析、未能解决的测试事件等）；评价被测软件项，描述被测软件项的状态（包括被测软件与需求的差异、发现的软件差错等）；完成测试报告，并通过测试评审。

3.测试的管理
软件测试的管理包括过程管理、配置管理和评审工作。

（1）过程管理。过程管理包括测试活动管理和测试资源管理。软件测试应由相对独立的人员进行。根据软件项目的规模、完整性级别和测试类别，软件测试可由不同机构组织实施。一般情况下，软件测试人员应包括测试项目负责人、测试分析员、测试设计员、测试程序员、测试员、测试系统管理员和配置管理员等。
（2）配置管理。应按照软件配置管理的要求，将测试过程中产生的各种工作产品纳入配置管理。由开发组织实施的软件测试，应将测试工作产品纳入软件项目的配置管理；由独立测试组织实施的软件测试，应建立配置管理库，将被测试对象和测试工作产品纳入配置管理。
（3）评审。测试过程中的评审包括测试就绪评审和测试评审。测试就绪评审是指在测试执行前对测试计划和测试说明等进行评审，评审测试计划的合理性和测试用例的正确性、完整性和覆盖充分性，以及测试组织、测试环境和设备、工具是否齐全并符合技术要求等；测试评审是指在测试完成后，评审测试过程和测试结果的有效性，确定是否达到测试目的，主要对测试记录和测试报告进行评审。