【定义类】软件测试基础二 （软件测试工程师）

测试阶段

        . 可靠性测试（含于集成测试、系统测试）；

        . 排错；

        . 可靠性建模；

        . 可靠性评价；

        . 调整可靠性活动计划；

        . 收集可靠性数据；

        . 明确后续阶段的可靠性活动的详细计划；

        . 编制可靠性文档。

 

  单元测试

       单元测试又称模块测试，是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

       . 单元测试的内容。

       在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。

       在单元测试中进行的测试工作如下图所示，需要在五个方面对所测模块进行检查。

       

       单元测试的工作

       ①模块接口测试。

       在单元测试的开始，应对通过所测模块的数据流进行测试。如果数据不能正确地输入和输出，就谈不上进行其他测试。为此，对模块接口可能需要如下的测试项目：调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；是否修改了只作输入用的形式参数；输出给标准函数的参数在个数、属性、顺序上是否正确；全局量的定义在各模块中是否一致；限制是否通过形式参数来传送。

       当模块通过外部设备进行输入/输出操作时，必须附加如下的测试项目：文件属性是否正确；OPEN语句与CLOSE语句是否正确；规定的I/O格式说明与I/O语句是否匹配；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写/输入错误，以及I/O错误是否检查并做了处理。

       ②局部数据结构测试。

       模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误：不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量；错误的初始值或错误的缺省值；变量名拼写错或书写错；不一致的数据类型。可能的话，除局部数据之外的全局数据对模块的影响也需要查清。

       ③路径测试。

       由于通常不可能做到穷举测试，所以在单元测试期间要选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试，可以发现大量的路径错误。

       常见的不正确计算有：运算的优先次序不正确或误解了运算的优先次序；运算的方式错，即运算的对象彼此在类型上不相容；算法错；初始化不正确；运算精度不够；表达式的符号表示不正确。

       常见的比较和控制流错误有：不同数据类型的相互比较；不正确的逻辑运算符或优先次序；因浮点数运算精度问题而造成的两值比较不等；关系表达式中不正确的变量和比较符；“差1”错，即不正确地多循环一次或少循环一次；错误的或不可能的循环中止条件；当遇到发散的迭代时不能中止的循环；不适当地修改了循环变量等。

       ④错误处理测试。

       比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。这种出错处理也应当是模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。

       ⑤边界测试。

       在边界上出现错误是常见的。例如，在一段程序内有一个n次循环，当到达第n次重复时就可能会出错。另外，在取最大值或最小值时也容易出错。因此，要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。

       此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。

       虽然模块测试通常是由编写程序的人自己完成的，但是项目负责人应当关心测试的结果。所有测试用例和测试结果都是模块开发的重要资料，必须妥善保存。

       总之，模块测试针对的程序规模较小，易于查错；发现错误后容易确定错误的位置，易于排错，同时多个模块可以并行测试。做好模块测试可为后续的测试打下良好的基础。

       . 单元测试的步骤。

       通常单元测试是在编码阶段进行的。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。

       模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：

       驱动模块（driver）——相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实测结果。

       桩模块（stub）——也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

       所测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如下图所示。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产品的一部分一同交付，而且它们的编写需要一定的工作量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了能够正确地测试软件，桩模块可能需要模拟实际子模块的功能，这样，桩模块的建立就不是很轻松了。

       

       单元测试的测试环境

       模块的内聚程度高，可以简化单元测试过程。如果每一个模块只完成一种功能，则需要的测试用例数目将明显减少，模块中的错误也容易被预测和发现。

       当然，如果一个模块要完成多种功能，且以程序包（package）的形式出现的也不少见，这时可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

集成测试

       集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

       . 组装时需要考虑的问题。

       ①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

       ②一个模块的功能是否会对另一个模块的功能产生不利的影响；

       ③各个子功能组合起来，能否达到预期要求的父功能；

       ④全局数据结构是否有问题；

       ⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。

       因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。

       子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。

       选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。

       . 模块组装成为系统的方式。

       模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。

       ①一次性组装方式（big bang）。

       它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。

       

       一次性组装方式

       在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。

       ②增殖式组装方式。

       这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。

       . 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。

       

       自顶向下的增殖方式

       自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。

       . 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。

       以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。

       

       一次性组装方式

       

       自底向上的增殖方式

       . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。

       自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。

       自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。

       在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：

       . 满足某些软件需求；

       . 在程序的模块结构中位于较高的层次（高层控制模块）；

       . 较复杂、较易发生错误；

       . 有明确定义的性能要求。

       在做回归测试时，也应该集中测试关键模块的功能。

       . 集成测试的组织和实施。

       集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：

       ①采用何种系统组装方法来进行集成测试。

       ②集成测试过程中连接各个模块的顺序。

       ③模块代码编制和测试进度是否与集成测试的顺序一致。

       ④测试过程中是否需要专门的硬件设备。

       解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。

       在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。

       . 集成测试完成的标志。

       集成测试完成的标志主要有以下几项。

       ①成功地执行了测试计划中规定的所有集成测试。

       ②修正了所发现的错误。

       ③测试结果通过了专门小组的评审。

       集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。

       在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。

       集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。

 

 

 组装测试

        组装测试也被称为集成测试。即使所有模块都通过了测试，但在组装之后，仍可能会出现问题：通过模块的数据被丢失；一个模块的功能对其他模块造成有害的影响；各个模块被组合起来后没有达到预期功能；全局数据结构出现问题；另外单个模块的误差可以接受，但模块组合后，可能会出现误差累积，最后达到不能接受的程度，所以需要组装测试。

        通常，组装测试有两种方法：一种是分别测试各个模块，再把这些模块组合起来进行整体测试，这种方法被称为非增量式集成。另一种是把下一个要测试的模块组合到已测试好的模块中，测试完后再将下一个需测试的模块组合进来进行测试，逐步把所有模块组合在一起，并完成测试。该方法被称为增量式集成。非增量式集成可以对模块进行并行测试，能充分利用人力，以加快工程进度。但这种方法容易混乱，出现的错误不容易被查找和定位。增量式测试的范围是一步步扩大的，所以错误容易被定位，而且已测试的模块可在新的条件下进行测试，程序测试得更彻底。

        增量式测试技术有自顶向下的增量方式和自底向上的增量方式两种测试方法。

        （1）自顶向下的增量方式。

        自顶向下的增量方式是模块按程序的控制结构，从上到下的组合方式。再增加测试模块时有先深度后宽度和先宽度后深度两种次序。如下图所示的自顶向下组合示例中，先深度后宽度的方法是把程序结构中的一条主路径上的模块相组合，测试顺序可以是M1→M2→M5→M6→M3→M7→M4。先宽度后深度的方法是把模块按层进行组合，测试顺序是M1→M2→M3→M4→M5→M6→M7。组装过程可分成以下步骤：

         

        自顶向下的组合示例

        .用主模块作为驱动模块，与之直接相连的模块用桩模块代替。

        .根据所选的测试次序，用下一个模块替换所用的桩模块；而新引入模块的直接下属模块用桩模块代替，构成新的测试对象。

        .结合一个模块测试一个模块。为了避免引入新模块产生新问题，需要进行回归测试，即重复部分或全部已经进行过的测试。

        .所有模块是否已经被组合到系统中，并完成测试。如果没有完成测试，则返回到第二步，重复进行；如果完成测试，则停止测试。

        自顶向下的增量方式可以较早地验证控制和判断点，如果出现问题可及时进行纠正。在测试时不需要编写驱动模块，但需要桩模块。另外，如果高层模块对下层模块依赖性很大，需要返回大量信息，在用桩模块代替时，桩模块的编写就相对复杂，必然会增加开销。这时可以用下面介绍的自底向上的增量方式。

        （2）自底向上的增量方式。

        自底向上的增量方式是从最底层的功能模块开始，边组合边测试，从下向上地完成整个程序结构的测试。其步骤可以概括为：

        .将最底层的模块组合成能完成某种特定功能的模块簇，为每个模块簇设计驱动程序，用驱动程序来控制并进行测试。

        .按从下向上的方向，用实际模块替换相对应的驱动程序，组成新的模块簇，再为该模块簇设计驱动程序，用新的驱动程序进行控制和测试。

        .所有模块是否已经被组合到系统中，并完成测试。如果没有完成测试，则返回到第二步，重复进行；如果完成测试，则停止测试。

        自底向上的增量方式可以较早地发现底层关键性模块出现的错误。在测试时不需要缩写桩模块，但需要驱动模块。另外，这种方式对程序中的主要控制错误的发现相对较晚。

        组装测试的方法选择取决于软件的特点和进度安排。在工程中，通常将这两种方法结合起来使用，即对位于软件结构中较上层的使用自顶向下的方法，而对于较底层的使用自底向上的方法。

 

 

确认测试

        确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查，确认测试一般由独立的第三方测试机构进行。

        . 进行有效性测试。

        有效性测试是在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。为此，需要制定测试计划、测试步骤以及具体的测试用例。通过实施预定的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到。所有的文档都是正确且便于使用的。同时，对其他软件需求，例如可移植性、可靠性、易用性、兼容性、可维护性等，也都要进行测试，确认是否满足。

        在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类。

        ①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而接受了这部分程序。

        ②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。

        . 软件配置复查。

        软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。

        在确认测试的过程中，还应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查文档资料的完整性和正确性。

 

       系统测试

        系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行（使用）环境下，对计算机系统进行一系列测试。

        系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。

 

       验收测试

        验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试。

        目前在国内实际软件开发，特别是系统集成的过程中，验收测试往往在系统测试完成后、项目最终交付前进行。验收测试的测试计划、测试方案与测试案例一般由开发方制定，由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与确认测试及系统测试不同的是，验收测试往往不是对系统的全覆盖测试，而是针对用户的核心业务流程进行的测试；同时，测试的执行人员也不是开发方的测试组成员，而是由用户方的使用人员完成。

        近年来，越来越多的开发方及用户方认识到对项目进行最终验收测试的重要意义，因此，由第三方完成的专业化全覆盖型技术测试得到了广泛应用。由专门从事测试工作的第三方机构，根据系统的需求分析、用户手册、培训手册等，在开发人员及最终使用人员的配合下，完成对系统全面的测试工作。

 

       用户测试

        用户测试是指让实际用户参与的测试方法。该方法需要找到各类典型的用户代表进行实际操作，主要目的是发现问题、确保用户易于使用、符合用户的要求。

 

回归测试

        回归测试是一种验证已变更的系统的完整性与正确性的测试技术，是指重新执行已经做过的测试的某个子集，以保证修改没有引入新的错误或者没有发现出于更改而引起之前未发现的错误，也就是保证改变没有带来非预期的副作用。

               回归测试的实施前提

               （1）当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，则可能会遗漏对这些错误的修改。

               （2）开发者对错误理解得不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败。

               （3）修改还有可能产生副作用，导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。

               回归测试与一般测试的比较

               通常从下面5点比较回归测试与一般测试：测试用例的新旧、测试范围、时间分配、完成时间和执行效率。

               （1）测试用例的新旧。一般测试主要依据系统规格说明书和测试计划，测试用例都是新的；而回归测试依据的可能是更改了的规格说明书、修改过的程序和需要更新的测试计划，因此测试用例大部分都是旧的。

               （2）测试范围。一般测试的目标是检测整个程序的正确性；而回归测试的目标是检测被修改的相关部分的正确性。

               （3）时间分配。一般测试所需时间通常在软件开发之前预算；而回归测试所需的时间（尤其是修正性的回归测试）往往不包含在整个产品进度表中。

               （4）完成时间。由于回归测试只需测试程序的一部分，完成所需时间通常比一般测试所需时间少。

               （5）执行效率。回归测试在一个系统的生命周期内往往要多次进行，一旦系统经过修改就需要进行回归测试。

 

 

软件质量保证

       软件质量保证包括与以下7个主要活动相关的各种任务。

       （1）应用技术方法。软件质量保证首先从一组技术方法和工具开始，这些方法和工具帮助分析人员形成高质量的规格说明和高质量的设计。

       （2）进行正式的技术评审。这是一种由技术人员实施的程式化会议，其唯一的目的是揭露质量问题。

       （3）测试软件。软件测试组合了多种测试策略，这些测试策略带有一系列有助于有效地检测错误的测试用例及设计方法。

       （4）标准的实施。多数情况下，标准由客户或某些章程确定。与标准是否一致的评估可以被软件开发者作为正式技术评审的一部分来进行。

       （5）控制变更。变更控制过程通过对变更的正式申请、评价变更的特性和控制变更的影响等直接提高软件的质量。变更控制应用于软件开发期间和较后的软件维护阶段。

       （6）计量。其包括某些技术上的和面向管理的计量。

       （7）记录保存和报告。为软件质量保证提供收集和传播软件质量保证信息的过程。评审、监察、变更控制、测试和其他软件质量保证活动的结果必须变成项目历史记录的一部分，并且应当把它传播给需要知道这些结果的开发人员。

质量保证

              质量保证是指为保证系统或产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的产品。在系统质量方面强调三个要点：首先系统必须满足用户规定的需求，与用户需求不一致的系统，就无质量可言；其次系统应遵循规定标准所定义的一系列开发准则，不遵循这些准则的系统，其质量难以得到保证；最后系统还应满足某些隐含的需求，例如希望有好的可理解性、可维护性等，而这些隐含的需求可能未被明确地写在用户规定的需求中，如果系统只满足它的显性需求而不满足其隐含需求，那么该系统的质量是令人担忧的。

              质量保证包括7个主要活动相关的各种任务，分别是应用技术方法、进行正式的技术评审、测试系统、标准的实施、控制变更、度量（metrics）、记录保存和报告。

 质量保证

       系统质量是指反映系统或产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行的独立的检查活动，由质量保证、质量规划和质量控制三个主要活动构成。质量保证是指为保证系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是开发高质量的系统。

              质量特性

              讨论系统质量首先要了解系统的质量特性。已经有多种软件质量模型来描述软件质量特性，目前较多采用的如ISO/IEC 9126软件质量模型和Mc Call软件质量模型。ISO/IEC 9126已经被ISO/ICE 25010系统和软件质量模型所取代，其主要改进包括将兼容性作和安全性作为质量特性，ISO/IEC 25012数据质量模型与ISO/IEC 25030使用质量模型作为补充。

                     ISO/ICE 25010系统和软件质量模型

                     ISO/ICE 25010系统和软件质量模型包含8个质量特性，每个特性由一组相关的质量子特性组成，如下图所示。该产品质量模型既可以用于软件，又可以用于任何包含软件的计算机系统。

                     

                     产品质量模型

                     其中，各质量特性和质量子特性的含义如下。

                     （1）功能适合性（functional suitability）。与一组功能及其指定的性质的存在有关的一组属性。功能是指满足规定或隐含需求的那些功能。

                     .功能完整性（functional completeness）：与对规定任务和用户目标加以实现的功能是否完整有关的属性。

                     .功能适当性（functional appropriateness）：与对规定任务和用户目标能否提供一组功能以及这组功能是否适合有关的属性。

                     .功能正确性（functional correctness）：与能够得到正确或相符的结果或效果有关的产品或系统属性。

                     （2）性能效率（performance efficiency）。在规定条件下，系统的性能水平与所用资源量之间的关系有关的一组属性。

                     .时间特性（time behavior）：与响应和处理时间以及软件执行其功能时的吞吐量有关的属性。

                     .资源利用率（resource utilization）：与系统执行其功能时所使用的资源量以及使用资源的类型有关的属性。

                     .容量（capacity）：与系统满足特定需求时指标参数的最大限制有关的属性。

                     （3）兼容性（compatibility）。与系统或组件与其他系统或组件进行信息交换，或在不同软硬件环境中执行所需功能有关的一组属性。

                     .共存性（co-existence）：与同其他系统运行在同一环境使用相同的资源而不相互影响的能力相关的属性。

                     .互操作性（interoperability）：与同其他指定系统进行交互操作的能力相关的属性。

                     （4）易用性（usability）。与为使用所需的努力和由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性。

                     .可识别性（appropriateness recognizability）：与用户识别系统是否满足需求有关的属性。

                     .易学性（learnability）：与用户为学习使用产品（例如操作控制、输入、输出）的有效性、效率、风险和满意度相关的属性。

                     .易操作性（operability）：与用户为进行操作和操作控制所付出的努力有关的属性。

                     .错误防御（user error protection）：与阻止用户错误输入有关的属性。

                     .界面美观性（user interface aesthetics）：与系统用户界面使用户进行愉快满意交互有关的属性。

                     .可访问性（accessibility）：与用户可访问系统完成特定目标的范围和能力有关的属性。

                     （5）可靠性（reliability）。与在规定的一段时间内和规定的条件下，系统维持在其性能水平有关的能力。

                     .成熟性（maturity）：与正常操作情况下满足可靠性需求有关的属性。

                     .可用性（availability）：与系统运行可用使用能力有关的属性。

                     .容错性（fault tolerance）：与在系统错误或违反指定接口的情况下，维持指定的性能水平的能力有关的属性。

                     .易恢复性（recoverability）：与在故障发生后，重新建立其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需的时间和努力有关的属性。

                     （6）安全性（security）。与避免对程序及数据的非授权故意或意外访问的能力有关的系统属性。

                     .机密性（confidentiality）：与系统确保只有授权才能访问其数据能力有关的属性。

                     .完整性（integrity）：与系统防止未经授权对数据和程序进行访问和修改能力有关的属性。

                     .不可抵赖性（non-repudiation）：与对系统使用行为及发生时间真实性有关的属性。

                     .可审计性（accountability）：与对系统使用行为进行追踪有关的属性。

                     .真实性（authenticity）：与证明主体或资源身份是所声称的身份有关的属性。

                     （7）可维护性（maintainability）。与进行规定的修改所需要的努力有关的一组属性。

                     .模块性（modularity）：与所组成系统的模块独立性有关的属性。

                     .可复用性（reusability）：与模块用于其他系统有关的属性。

                     .易分析性（analyzability）：与为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的属性。

                     .易修改性（modifiability）：与进行修改、排错或适应环境变换所需努力有关的属性。

                     .易测试性（testability）：为确认经修改系统所需努力有关的属性。

                     （8）可移植性（portability）。与系统可从某一环境转移到另一环境的能力有关的一组属性。

                     .适应性（adaptability）：与系统转移到不同环境时的处理或手段有关的属性。

                     .易安装性（installability）：与在指定环境下对系统进行安装／卸载所需努力有关的属性。

                     .易替换性（replaceability）：与一产品在该软件环境中用来替代指定的其他软件的可能和努力有关的属性。

                     Mc Call软件质量模型

                     Mc Call软件质量模型从软件产品的运行、修正、转移三个方面确定了11个质量特性，如下图所示。Mc Call也给出了一个三层模型框架，第一层是质量特性，第二层是评价准则，第三层是度量指标。

                     

                     Mc Call软件质量模型

 

功能性

        功能性是指当软件在指定条件下使用时，软件产品满足明确和隐含要求功能的能力。

               适合性

               适合性是指软件产品为指定的任务和用户目标提供一组合适的功能的能力。

               准确性

               准确性是指软件产品具有所需精确度的正确或相符的结果及效果的能力。

               互操作性

               互操作性是指软件产品与一个或更多的规定系统进行交互的能力。

               保密安全

               保密安全是指软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，但不拒绝授权人员或系统对它们的访问。

               功能性依从性

               功能性依从性是指软件产品依附于同功能性相关的标准、约定或法规以及类似规定的能力

       适合性

        适合性是指软件产品为指定的任务和用户目标提供一组合适的功能的能力。

       准确性

        准确性是指软件产品具有所需精确度的正确或相符的结果及效果的能力。

       互操作性

        互操作性是指软件产品与一个或更多的规定系统进行交互的能力。

       成熟性

        成熟性是指软件产品避免因软件中错误的发生而导致失效的能力。

       易学性

        易学性是指软件产品使用户能学习它的能力。

 

 

兼容性

        兼容性是指一个系统的硬件或软件与另一个系统或多种操作系统的硬件或软件的兼容能力，是指系统间某些方面具有的并存性，即两个系统之间存在一定程度的通用性。兼容是一个广泛的概念，包括数据和文件的兼容、程序和语言级的兼容、系统程序的兼容、设备的兼容，以及向上兼容和向后兼容等。

        除了上述性能指标之外，还有其他性能指标，如综合性能指标如吞吐率、利用率；定性指标，如保密性、可扩充性；功能特性指标，如文字处理能力、联机事务处理能力、I/O总线特性、网络特性等。

 

       可用性

        可用性（Availability）是指合法许可的用户能够及时获取网络信息或服务的特性。例如，网站能够给用户提供正常的网页访问服务，防止拒绝服务攻击。可用性是常受关注的网络信息系统CIA三性之一，其中A代表可用性（Availability）。对于国家关键信息基础设施而言，可用性至关重要，如电力信息系统、电信信息系统等，要求保持业务连续性运行，尽可能避免中断服务。

 

可用性测试

        可用性是指系统正常运行的能力和用户接受的程度，一般用如下公式表示。

        可用性=平均正常工作时间／（平均正常工作时间+平均修复时间）

        影响可用性的因素有如下几个：

        （1）不充分的测试。

        （2）更改管理问题。

        （3）缺少在线监视和分析。

        （4）操作错误。

        （5）弱编码。

        （6）与外部服务或应用程序的交互。

        （7）不同的操作条件（使用级别更改、峰值重载）。

        （8）异常事件（安全性失败、广播风暴）。

        （9）硬件故障（硬盘、控制器、网络设备、服务器、电源、内存和CPU）。

        （10）环境问题（电源、冷却、火、洪水、灰尘、自然灾害）。

        下面给出提高系统可用性的一些办法。

        （1）使用集群。集群是指将至少两个系统连接到一起，像一个系统那样工作。当某一系统出现失效时，集群提供即时故障转移服务。

        （2）使用网络负载平衡。当检测某服务器失败后，网络负载平衡自动将通信量重新分发给仍然运行的服务器。

        （3）使用服务级别协议。可用性指标的期望服务级别要求达到4个或5个“9”。例如，“该应用程序应每周运行7天，每天24小时，年可用性为99.99%”是指全年不能正常工作的时间仅仅只有52分钟，不足1个小时。

        （4）提供实时的监视。监视系统的工作负荷和失败数据，实时监视对于发现趋势和改善服务至关重要。

        （5）使用数据备份，保证数据安全。

        （6）检查所有的安全计划。安全性是确保应用程序服务只对有权使用系统的用户可用，还意味着使得应用程序使用的所有分布式组件和资源受到保护。

 

       易用性

        易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。

               易理解性

               易理解性是指软件产品使用户能理解软件是否合适以及如何能将软件用于特定的任务和使用环境的能力。

               易学性

               易学性是指软件产品使用户能学习它的能力。

               易操作性

               易操作性是指软件产品使用户能操作和控制它的能力。

               吸引性

               吸引性是指软件产品吸引用户的能力。

               易用性依从性

               易用性依从性是指软件产品依附于同易用性相关的标准、约定、风格指南或规定的能力。

可移植性

        可移植性是指软件产品从一种环境迁移到另外一种环境的能力。

               适应性

               适应性是指软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段，就可能适应不同的指定环境的能力。

               易安装性

               易安装性是指软件产品在指定环境中被安装的能力。

               共存性

               共存性是指软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。

               易替换性

               易替换性是指软件产品在环境相同、目的相同的情况下替代另一个指定软件产品的能力。

               可移植性依从性

               可移植性依从性是指软件产品依附于同可移植性相关的标准或约定的能力。

 

  可靠性

        在指定条件下使用时，软件产品维持规定的性能级别的能力。

               成熟性

               成熟性是指软件产品避免因软件中错误的发生而导致失效的能力。

               容错性

               容错性是指在软件发生故障或者违反指定接口的情况下，软件产品维持规定的性能级别的能力。

               易恢复性

               易恢复性是指在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。

               可靠性依从性

               可靠性依从性是指软件产品依附于同可靠性相关的标准、约定或规定的能力。

   成熟性

        成熟性是指软件产品避免因软件中错误的发生而导致失效的能力。

       容错性

        容错性是指在软件发生故障或者违反指定接口的情况下，软件产品维持规定的性能级别的能力。

       易恢复性

        易恢复性是指在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。

       有效性

        有效性是指软件产品在指定的使用环境下，使用户获得满足准确度和完整性要求的规定目标的能力。

 

       可靠性测试

        软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会（IEEE）将软件可靠性定义为：系统在特定的环境下，在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性，以及可维护性等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。

        可靠性测试一般伴随着强壮性测试，是评估软件在运行时的可靠性，通过测试确认平均无故障时间（Mean Time to Failure，MTTF）、故障发生前平均工作时间（Mean-Time-To-First-Failure，MTTFF）或因故障而停机的时间（Mean Time To Repairs，MTTR）在一年中应不超过多少时间。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。

 

       安全性

        安全性是指软件产品在指定使用环境下，获得可接受的对人类、事务、软件、财产或环境有害的风险级别的能力。

 

       安全性测试

        测试应用程序的体系结构和设计可以消除很多与设计有关的漏洞，从而提高应用程序的整体安全性。设计时修复漏洞要比在开发后期解决问题更为简单，也更经济，因为开发后期可能要进行大量的重新工程处理。开发时如果考虑一些与目标部署环境相关的设计以及该环境定义的安全策略，可确保应用程序的部署更加平稳和安全。如果应用程序已创建完毕，安全测试可修复漏洞并完善未来的设计。

        一个完整的Web安全体系测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密、参数操作、异常管理、审核和日志记录等几个方面入手。

               安全体系测试

                      部署与基础结构

                      检验底层网络和主机基础结构提供给应用程序的安全设置，然后检验运行环境要求的所有限制。此外，考虑部署的拓扑结构以及中间层应用程序服务器、外围区域以及内部防火墙对设计的影响。检验下列问题，确定可能存在的部署和基础结构问题。

                      . 网络是否提供了安全的通信。

                      数据在客户端与服务器（或服务器与服务器）之间传输时最易受到攻击。网络负责数据传输的完整性和私密性。如果必须保证数据安全，可使用适当的加密算法。此外，还必须确保网络设备安全。因为这是维护网络完整性所必需的。

                      . 部署拓扑结构是否包括内部防火墙。

                      如果内部防火墙将Web服务器与应用程序服务器（或数据库服务器）分隔开来，则需要考虑下列问题，确保设计能适应这种配置。

                      ①下游服务器如何验证Web服务器的身份；

                      ②如果使用域账户和Windows身份验证，防火墙是否打开了必要的端口；

                      ③是否使用分布式事务；

                      ④如果Web服务器使用DTC（Microsoft Distributed Transaction Coordinator）的服务来启动分布式事务，内部防火墙是否为DTC通信打开了必要的端口。

                      . 部署拓扑结构中是否包括远程应用程序服务器。

                      如果部署拓扑结构包括了一个物理远程中间层，则需要考虑下列问题。

                      ①是否使用企业服务。如果是，是否已限制了DCOM端口范围，内部防火墙是否打开了这些端口。

                      ②是否使用．NET远程处理。

                      ③远程处理用在受信服务器方案中，网络是否支持IPSec策略。

                      ④ASP.NET承载远程组件是否支持身份验证和授权。

                      ⑤是否使用Web服务，如果是，中间层Web服务如何验证Web应用程序的身份。Web应用程序是否通过在Web服务代理中配置凭据来使Web服务验证Web服务器的身份，如果否，Web服务如何明确调用者。

                      . 基础结构安全性要求的限制是什么。

                      设计是否假定主机基础结构安全限制要失效。例如，安全限制可能要求根据所需的服务、协议或账户特权来对设计进行权衡。需要考虑下列问题。

                      ①是否依赖可能不可用的服务或协议。开发和测试环境中可用的服务和协议可能在生产环境中不可用。

                      ②是否依赖敏感的账户特权。设计应尽量使用特权最少的进程、服务和用户账户。

                      ③要执行的操作是否要求可能不被许可的敏感特权。例如，应用程序是否要创建线程级模拟令牌来创建资源访问的服务身份。这项操作要求“作为操作系统的一部分”特权，而该特权不应授予Web服务器进程（因为可能增加进程被利用的风险）。如果需要此功能，设计应对更高级别的特权进行划分，例如，在进程外的企业服务应用程序中。

                      . 目标环境支持怎样的信任级别。

                      运行环境的代码访问安全信任级别决定了代码可访问的资源，以及它能执行的特权操作。请检查运行环境支持的信任级别。如果允许Web应用程序以完全信任级别运行，代码将能够访问操作系统安全性许可的任何资源。

                      如果Web应用程序必须以受限信任级别运行，则代码能访问的资源类型以及能执行的特权操作都将受到一定的限制。在部分信任案例中，设计应对特权代码进行沙盒（sandboxing）处理。此外，还应使用不同的程序集来分隔特权代码。这样，可以对特权代码和应用程序的其余部分单独配置特权代码，然后授予必要的附加代码访问权限。

                      注意：如果应用程序部署在共享服务器（或应用程序将由宿主公司运行），信任级别通常是个问题。此时，需要检查安全策略，然后确定Web应用程序的信任级别。

                      输入验证

                      需要对应用程序验证输入内容的方式进行检验，因为很多Web应用程序攻击都故意使用格式错误的输入。SQL注入、跨站点脚本（XSS）、缓冲区溢出、代码注入以及无数其他拒绝服务和特权提升攻击都可利用输入验证中的漏洞。下表中重点列出了常见的输入验证漏洞。

                      

                      常见的输入验证漏洞

                      测试时应考虑下列问题，以帮助发现潜在的输入验证安全问题。

                      . 如何验证输入。

                      设计指定的输入验证方法是什么？首先，设计必须展示策略。应用程序应对收到的所有输入进行约束、拒绝和净化。约束输入是最佳的方法，因为针对已知有效类型、模式和范围对数据进行验证，要比通过查找已知坏字符来验证数据简单得多。

                      测试时应考虑下列问题，帮助识别潜在的漏洞。

                      ①是否清楚入口点。

                      确保设计标出了应用程序的入口点，以便跟踪各个输入字段的操作。可考虑Web页输入、输入到组件和Web服务，以及从数据库输入。

                      ②是否清楚信任边界。

                      如果输入是从信任边界内受信源传递的，并非总要验证输入；但如果输入是从不受信任的源传递的，必须验证输入。

                      ③是否验证Web页输入。

                      不要将最终用户看作受信任的数据源。确保对正常和隐藏的表单字段、查询字符串和cookie都进行验证。

                      ④是否对传递到组件或Web服务的参数进行验证。

                      如果不进行验证，惟一的安全条件就是数据接收自当前信任边界之内。但是，如果使用深层防御策略，则需要使用多层验证。

                      ⑤是否验证从数据库中检索的数据。

                      这种形式的输入也应验证，特别是当其他应用程序也写入该数据库时。不要对其他应用程序的数据验证程度进行假设。

                      ⑥是否将方法集中起来。

                      对于相同类型的输入字段类型，检验使用的是否是相同的验证和筛选库，确保一致地执行验证规则。

                      ⑦是否依赖客户端的验证。

                      客户端验证可用于降低到服务器的回程数量，但不能依靠它来维护安全性，因为它很容易被忽略。需要在服务器验证所有的输入。

                      . 如何处理输入。

                      检查应用程序处理输入的方式，不同类型的处理可能导致不同类型的漏洞。例如，如果在SQL查询中使用输入，应用程序可能易受SQL注入的攻击。

                      测试中考虑下列问题，帮助发现潜在的漏洞。

                      ①应用程序是否易受规范化问题的影响。

                      检查应用程序是否使用基于输入的名称来制定安全决策。例如，应用程序是否接受用户名、文件名或URL。由于名称的表示方法多种多样，以上各项都极易造成规范化错误问题。如果应用程序接受输入作为名称，则应确保对它们进行验证并在处理之前将它们转换为规范的表示法。

                      ②应用程序是否易受SQL注入攻击。

                      密切注意形成SQL数据库查询的所有输入字段。确保对这些字段的类型、格式、长度和范围进行正确的验证。此外，检查查询的生成方式。如果使用参数化的存储过程，输入参数将被当作文本，而不会当作可执行代码。这是降低风险的一种有效措施。

                      ③应用程序是否易受XSS攻击。

                      如果在HTML输出流中包括输入字段，可能受到XSS攻击。确保对输入进行验证，并对输出进行编码。密切注意系统对接受一定范围HTML字符的输入字段的处理方法。

                      身份验证

                      检查应用程序验证调用者身份的方法，在何处使用身份验证，如何确保凭据在存储中或通过网络传递的安全。身份验证中的漏洞可能导致应用程序易受哄骗攻击、词典攻击、会话劫持等。下表重点列出了常见的身份验证漏洞。

                       

                      常见的身份验证漏洞

                      测试中需要考虑下列问题，确定在应用程序进行身份验证的方法中的潜在漏洞。

                      . 是否区分公共访问和受限访问。

                      如果应用程序既有不要求身份验证的公共区域，也有要求身份验证的受限区域，检查站点设计区分二者的方法。必须为受限的页和资源使用单独的子文件夹，然后在IIS中将它们配置为要求SSL来确保安全。这种方法允许只在需要的地方使用SSL来确保敏感数据和身法验证cookie的安全性，从而避免了因在整个站点中使用SSL而造成的附加性能负担。

                      . 是否明确服务账户要求。

                      设计应明确连接不同资源（包括数据库、目录服务和其他类型的网络资源）的服务账户范围。设计中不能使用单个的、有高度特权的账户（有足够的权限连接多种不同类型的资源）。

                      ①设计是否要求特权最少的账户。

                      检查设计并准确标识各账户执行特定功能所需的特权，然后在任何情况下都使用特权最少的账户。

                      ②应用程序是否要维护服务账户凭据。

                      如果是，确保加密这些凭据，然后保存在受限的位置中。例如，保存在有受限访问控制列表（ACL）的注册表项。

                      . 如何验证调用者身份。

                      测试时考虑与调用者身份验证相关的下列事项。具体事项由设计中使用的身份验证类型决定。

                      ①是否在网络中传递明文凭据。如果使用表单或基本身份验证（或使用Web服务并在SOAP头中传递凭据），确保使用SSL来保护传输中的凭据。

                      ②是否实现自己的用户存储。如果是，检查用户凭据的存储位置和存储方式。一种常见错误是将明文或加密密码保存在用户存储中。实际上，必须保存密码的哈希值来进行身份验证。

                      如果根据SQL Server用户存储验证凭据，密切注意用户名和密码的输入。检查是否存在恶意注入的SQL字符。

                      ③是否使用表单身份验证。如果是，除使用SSL保护凭据外，还应使用SSL来保护身份验证cookie。此外，还要检查设计是否使用受限的会话生存期来抵御cookie重播攻击，并确保加密cookie。

                      . 如何验证数据库的身份。

                      如果应用程序要连接数据库，检查使用的身份验证机制、打算使用的账户（一个或多个），以及如何在数据库中授权应用程序。

                      明确下列问题有助于对数据库身份验证进行评价。

                      ①是否使用SQL身份验证。

                      在理想情况下，设计使用Windows身份验证来连接SQL Server，因为这种方法本身更加安全。如果使用SQL身份验证，检查在网络中和数据库连接字符串中确保凭据安全的方法。

                      如果网络基础结构不提供IPSec加密通道，确保在数据库中安装服务器证书来提供自动SQL凭据加密。此外，还要检验确保数据库连接字符串安全的方法，因为这些字符串中包含SQL账户的用户名和密码。

                      ②是否使用进程账户。

                      如果使用应用程序的进程账户并使用Windows身份验证连接SQL服务器，应在设计中使用特权最少的账户。本地ASP.NET账户便是为此提供的，尽管对于本地账户来说，用户需要在数据库服务器上创建一个相同的账户。

                      如果打算使用域账户，首先确保它是特权最少的账户，然后打开相关的端口来确保所有相关防火墙都支持Windows身份验证。

                      ③是否使用服务账户。

                      如果设计要求使用多个身份来支持数据库中的高粒度授权，则需要检查保存账户凭据（在理想情况下，这些凭据使用数据保护API（DPAPI）加密并保存在安全注册表项中）的方法，以及使用服务身份的方法。

                      此外，还要检查使用哪些进程通过该服务账户创建模拟的安全上下文。该操作不应由Microsoft Windows 2000中的ASP.NET应用程序进程来完成，因为它将强制提升进程账户的特权，并授予“作为操作系统的一部分”特权。这种情况必须尽量避免，它将大大增加风险。

                      ④是否考虑使用匿名Internet用户身份。

                      对于使用表单或Passport身份验证的应用程序而言，可为各个程序配置单独的匿名用户账户。然后，启用模拟并使用匿名身份来访问数据库。该方法适于对同一服务器的不同应用程序进行单独的授权和身份跟踪。

                      ⑤是否使用原始用户身份。

                      如果设计要求模拟原始调用者，必须考虑该方法是否能提供足够的伸缩性，因为连接池是无效的。另一种备选方法是，通过受信的查询参数在应用程序级流动原始调用者身份。

                      ⑥如何保存数据库连接字符串。

                      如果数据库连接字符串硬编码，或以明文形式保存在配置文件或COM+目录中，则很容易受到攻击。实际上，应加密它们，然后限制对加密数据的访问。

                      . 是否强制使用强账户管理措施。

                      如果应用程序使用Windows身份验证，Windows安全策略将强制使用强密码、受限登录和其他最佳账户管理策略。其他情况，则由应用程序层负责这些措施。测试要考虑与应用程序账户管理相关的下列问题。

                      ①应用程序是否强制使用强密码。

                      例如，ASP.NET Web页是否使用正则表达式来验证密码复杂性规则。

                      ②是否限制失败登录的次数。

                      这样做有助于对抗词典攻击。

                      ③是否在故障发生后公开过多的信息。

                      确保不显示类似“不正确的密码”这样的消息，因为它将告诉恶意用户：用户名是正确的。结果，恶意用户便可集中精力破解密码。

                      ④是否强制定期更改密码。

                      如果不强制定期更改密码，用户极有可能不更改自己的密码，结果风险更高。

                      ⑤是否能在泄露发生时迅速禁用账户。

                      如果账户泄露，是否能方便地禁用账户来防止攻击者继续使用账户。

                      ⑥应用程序是否记录登录企图。

                      记录失败的登录企图是检测攻击者试图侵入的有效方法。

                      授权

                      检查应用程序是如何向用户授权的。还要检验应用程序在数据库中是如何被授权的，以及如何控制系统级资源的访问。授权中的漏洞可能导致信息泄漏、数据篡改及特权提升。使用深层防御策略是一种重要的方法，它可应用于应用程序的授权策略中。下表重点列出了常见的授权漏洞。

                       

                      常见的授权漏洞

                      测试中需要考虑下列问题，帮助验证应用程序设计的授权策略。

                      . 如何向最终用户授权。

                      应在设计时从两种角度考虑授权。首先，考虑最终用户授权。哪些用户可访问哪些资源，并执行哪些操作。其次，如何防止恶意用户使用应用程序访问系统级资源。考虑下列问题，验证应用程序的授权策略。

                      ①是否使用深层防御策略。

                      确保设计不依赖于单个网关守卫来加强访问控制。考虑该网关守卫失败（或攻击者设法忽略它）时发生的情况。

                      ②使用了哪些网关守卫。

                      可能的选择有IISWeb权限、NTFS权限、ASP.NET文件授权（仅适用于Windows身份验证）、URL授权和用户权限请求。如果不使用某个特定类型，需要明确不使用的理由。

                      ③是否使用基于角色的方法。

                      如果是，如何维护角色列表，维护角色列表所需的管理界面安全性如何。

                      ④角色是否提供足够的特权隔离。

                      设计是否提供了适当的粒度，使不同用户角色的关联特权得到充分的隔离。避免出现仅为满足特定用户需要而授予角色较高特权的情况。

                      . 如何在数据库中授权应用程序。

                      在应用程序中连接数据库的账户必须有受限的能力，只需满足应用程序的要求即可，不要再高了。

                      应用程序是否使用存储过程来访问数据库呢？建议应用程序使用存储过程来访问数据库，因为一般用户只能授予应用程序登录访问特定存储过程的权限。可以限制登录不在数据库中直接执行创建/读取/更新/删除（CRUD）操作。

                      . 如何将访问限定于系统级资源。

                      设计应用程序时，应考虑应用程序在可访问系统级资源方面的限制。只能授予应用程序访问最低限度的资源。这是缓解风险的一种策略，可在应用程序遭受攻击时限制受损程度。考虑下列问题。

                      ①设计是否使用代码访问安全性。

                      代码访问安全性提供了一种资源约束模型，该模型可防止代码（和Web应用程序）访问特定类型的系统级资源。如果使用代码访问安全性，设计必将受到影响。明确是否在设计规划中包括代码访问安全性，然后通过对特权代码进行隔离和沙盒处理（sandboxing），并将资源访问代码置于自己独立的程序集中，从而进行相应的设计。

                      ②应用程序使用哪些身份。

                      设计必须明确应用程序使用的所有身份，包括进程身份和所有模拟身份（包括匿名Internet用户账户和服务身份）。此外，设计还要指出这些身份要访问的资源。

                      在部署时，可对系统级资源配置正确的ACL，确保应用程序的身份只能访问所需的资源。

                      配置管理

                      如果应用程序提供了可配置的管理界面，要检查确保管理界面安全的方法。此外，还要检查如何确保敏感配置数据的安全。下表显示了常见的配置管理漏洞。

                      

                      常见的配置管理漏洞

                      测试时考虑下列问题，帮助验证应用程序设计在配置管理方面的方法。

                      . 是否支持远程管理。

                      如果设计指定了远程管理，必须确保管理界面和配置存储的安全，因为这些操作本身非常敏感，而且通过管理界面访问的数据也很敏感。考虑与远程管理设计相关的下列问题。

                      ①是否使用强身份验证。

                      必须要求对所有管理界面用户进行身份验证。使用强身份验证，如Windows或客户端证书身份验证。

                      ②是否加密网络通信数据。

                      使用经过加密的信道，如IPSec或虚拟专用网络（VPN）连接提供的通道。不支持不安全通道中的远程管理。IPSec允许对可用来管理服务器的客户计算机的身份和数量进行限制。

                      . 是否保证配置存储的安全。

                      明确应用程序的配置存储，然后检查限制访问这些存储的方法，以及确保存储中数据安全的方法。

                      ①配置存储是否在Web空间中。

                      对于保存在Web空间文件中的配置数据，其安全性要低于保存在Web空间之外的数据。主机配置错误或未发现的Bug都可能导致攻击者通过HTTP检索，并下载配置文件。

                      ②配置存储中的数据是否安全。

                      确保在存储中加密关键的配置数据项（如数据库连接字符串、加密密钥和服务账户凭据）。

                      ③如何限制对配置存储的访问。

                      确保管理界面提供必要的授权，只有经过验证的管理员才可访问并操作这些数据。

                      . 是否隔离管理员特权。

                      如果管理界面支持不同的功能（如站点内容更新，服务账户重新配置和数据库连接详细信息），要确认管理界面支持基于角色的授权，从而区分内容开发人员和操作员或系统管理员。例如，不必许可更新静态Web站点的人改变客户的信用额度或重新配置数据库连接字符串。

                      敏感数据

                      检查应用程序对存储中、应用程序内存中以及网络中的敏感数据的处理方法。下表显示了与处理敏感数据相关的常见漏洞。

                      

                      敏感数据处理中的常见漏洞

                      测试中要考虑下列问题，帮助验证应用程序处理敏感数据的方法。

                      . 是否存储机密信息。

                      机密信息包括了应用程序的配置数据，如账户密码和加密密钥。如果可能，明确其他避免保存机密信息的设计方法。如果要处理机密信息，由系统平台处理它们，尽可能不在应用程序中承担这一任务。如果确实要保存机密信息，则要考虑下列问题。

                      ①是否能避免存储机密信息。

                      如果使用其他的实施技术，是否能避免存储机密信息。例如，如果只需了解用户是否知道密码，则无需存储密码。或者，仅保存单向的密码哈希值。

                      此外，如果使用Windows身份验证，可通过嵌套凭据来避免存储连接字符串。

                      ②如何存储机密信息。

                      如果使用加密，如何确保加密密钥的安全。考虑使用系统平台提供的DPAPI加密，这种加密能替用户完成密钥管理。

                      ③在何处保存机密信息。

                      检查应用程序保存加密数据的方法。要获得尽可能高的安全性，应使用Windows ACL限制对加密数据的访问。确认应用程序不以明文或源代码形式存储机密信息。

                      如果使用本地安全机构（LSA），检索机密信息的代码必须使用管理员特权才可以运行，这将增加风险。另一种不要求扩展特权的方法是使用DPAPI。

                      ④如何处理机密信息。

                      检验应用程序访问机密信息的方法，以及它们以明文形式存留在内存中的时间。机密信息通常应根据需要检索，并尽快使用，然后丢弃。

                      ⑤是否在cookie中存储机密信息。

                      如果是，应确保cookie是加密的，且不会永久保存在客户计算机中。

                      . 如何存储敏感数据。

                      如果存储了敏感的应用程序数据（如客户信用卡详细信息），检查数据保护方法。

                      ①使用怎样的加密算法。

                      应使用强加密算法来加密。例如，使用较长的密钥（如Triple DES）。

                      ②如何确保加密密钥的安全性。

                      数据的安全性与加密密钥安全性同等重要。因此，检查确保密钥安全的方法。在理想状况下，使用DPAPI加密密钥并保存在受限位置（如注册表项中）来确保安全。

                      . 是否在网络中传递敏感数据。

                      如果通过网络传递敏感数据，应确保通过应用程序加密这些数据，或通过加密的通信链接来传递它们。

                      . 是否记录敏感数据。

                      检查应用程序（或主机）是否在明文日志文件中记录用户账户密码这样的敏感数据。通常，必须避免这样做。确保应用程序不在查询字符串中传递敏感数据，因为查询字符串会被记录，并可在客户端浏览器地址栏中直接看到。

                      会话管理

                      由于Web应用程序基于无状态的HTTP协议生成，因此会话管理是应用程序级任务。检查应用程序的会话管理方法，因为它将直接影响应用程序的整体安整。下表显示了与会话管理相关的常见漏洞。

                      

                      常见的会话管理漏洞

                      测试中需要考虑下列问题，帮助验证应用程序处理敏感数据的方法。

                      . 如何交换会话标识符。

                      检查应用程序管理用户会话的会话标识符，以及这些会话标识符的交换方式。考虑下列问题。

                      ①是否通过未加密的通道传递会话标识符。

                      如果使用会话标识符（如cookie中包含的令牌）跟踪会话状态，检查是否仅通过加密的通道（如SSL）传递标识符或cookie。

                      ②是否加密会话cookie。

                      如果使用表单身份验证，确保应用程序使用“”元素中的protection="All"属性加密身份验证。建议同时使用SSL和这种方法，以便降低XSS攻击的风险，XSS攻击可设法窃取用户的身份验证cookie。

                      ③是否在查询字符串中传递会话标识符。

                      确保应用程序不在查询字符串中传递会话标识符。这些字符串可在客户端轻易修改，使用户能作为另一用户访问应用程序，访问其他用户的私有数据，并可能提升特权。

                      . 是否限制会话生存期。

                      检查应用程序认为会话标识符有效的时间。应用程序应限制这段时间的长度，以降低会话劫持和重播攻击的威胁。

                      . 如何确保会话状态存储的安全。

                      检查应用程序存储会话状态的方法。会话状态可存储在Web应用程序进程、ASP.NET会话状态服务，或SQL Server状态存储中。如果使用远程状态存储，请确保Web服务器到该远程存储的链接使用IPSec或SSL加密，以保护在网络中传输的数据。

                      加密

                      如果应用程序使用加密来提供安全性，检查加密的内容以及加密的使用方法。下表显示了与加密有关的常见漏洞。

                      

                      常见的加密漏洞

                      测试中需要考虑下列问题，帮助验证应用程序处理敏感数据的方法。

                      . 为何使用特定的算法。

                      加密只有在正确使用时才能提供真正的安全保障。不同作业使用不同的算法。算法的程度也非常重要。考虑下列问题，评价所使用的加密算法。

                      ①是否开发自己的加密技术。

                      不应开发自己的加密技术。众所周知，加密算法和例程的开发非常难，而且很难成功。自定义实施的安全保护一般很弱，基本上不如久经考验的系统平台服务提供的安全措施。

                      ②是否使用合适的密钥大小来应用正确的算法。

                      检查应用程序使用的算法及使用该算法的目的。较大的密钥可提供较高的安全性，但会影响性能。对于在数据存储中长时间保存的永久数据，较强的加密非常重要。

                      . 如何确保加密密钥的安全性。

                      加密数据的安全与密钥的安全同等重要。要破解加密数据，攻击者必须能检索出密钥和密码文本。因此，需要检查设计，确保加密密钥和加密数据的安全。考虑下列评价问题。

                      ①如何确保加密密钥的安全。

                      如果使用DPAPI，将由系统平台为用户管理密钥。其他情况下，则由应用程序负责密钥管理。检查应用程序确保加密密钥安全的方法。一种较好的方法是，使用DPAPI加密其他加密形式所需的加密密钥。然后，安全地保存加密密钥，例如，将其放在配置了受限ACL的注册表项目下。

                      ②回收密钥的频率如何。

                      不能滥用密钥。同一密钥使用的时间越长，被发现的可能性就越高。设计是否考虑了怎样回收密钥、回收的频率，以及如何将它们分发并安置在服务器中。

                      参数操作

                      检查应用程序使用参数的方法。这些参数包括了在客户端和服务器间传递的表单字段、查询字符串、cookie、HTTP头和视图状态。如果使用像查询字符串这样的参数传递敏感数据（如会话标识符），恶意客户端可轻松使用简单的参数操作逃避服务器端检查。下表显示了常见的参数操作漏洞。

                      

                      常见的参数操作漏洞

                      测试中需要考虑下列问题，以帮助确保您的设计不受参数操作攻击影响。

                      . 是否验证所有的输入参数。

                      确保应用程序验证所有的输入参数，包括正常和隐藏的表单字段、查询字符串和cookie。

                      . 是否在参数中传递敏感数据。

                      如果应用程序在参数（如查询字符串或表单字段）中传递敏感数据，应检查应用程序使用这种方法而不是更安全的方法（传递会话标识符）的原因。例如，在加密的cookie中传递会话标识符。使用这些信息将会话与在服务器状态存储中维护的用户状态相关联。考虑下列评价问题。

                      ①是否加密包含敏感数据的cookie。

                      如果应用程序使用包含敏感数据的cookie，如用户名或角色列表，确保它是经过加密的。

                      ②是否在查询字符串或表单字段中传递敏感数据。

                      不能这样做，因为就操作查询字符串或表单字段中的数据而言，没有简便的方法可用。实际操作过程中，应考虑使用加密的会话标识符，然后将敏感数据保存在服务器的会话状态存储中。

                      ③是否保护视图状态。

                      如果Web页或控件使用视图状态在HTTP请求之间维持状态，确保视图状态经过加密，并使用消息验证代码（MAC）检查其完整性。用户可在计算机级配置该设置，也可按页配置。

                      . 是否为了安全问题而使用HTTP头数据。

                      确保Web应用程序不根据HTTP头中的信息制定安全决策，因为攻击者可轻松地操作头数据。不要依赖HTTP引用站点字段的值来检查源于页的请求是否由Web应用程序生成，这将带来漏洞。这种操作本身很不安全，因为引用站点字段可在客户端轻松更改。

                      异常管理

                      检查应用程序处理错误的方法。应前后一致地使用结构化的异常处理。同样，确保应用程序不在发生异常时公开太多信息。下表显示了两大异常管理漏洞。

                      

                      常见的异常管理漏洞

                      测试时应考虑下列问题，以确保设计不易受到异常管理安全漏洞的影响。

                      . 是否使用结构化的异常处理。

                      检查应用程序如何使用结构化的异常处理。设计应强制在整个应用程序中使用一致的结构化异常处理。这将创建更强大的应用程序，使应用程序不易处在暴露安全漏洞的不一致状态下。

                      . 是否向客户端公开了太多的信息。

                      确保恶意用户无法利用错误信息中的细节信息，考虑下列问题。

                      ①是否在服务器中捕获、处理和日志记录异常。

                      确保应用程序不会将内部异常情况传播到应用程序边界以外。异常应在服务器中捕获并记录日志。如果必要，应向客户端返回常规错误信息。

                      ②是否使用集中的异常管理系统。

                      在应用程序中一致处理并日志记录异常的最佳方法是，使用正式的异常处理系统。还可将该系统与操作组监视系统性能的监控系统相结合。

                      ③是否定义了一组自定义错误信息。

                      设计必须明确，应用程序在发生严重错误时使用自定义的错误信息。确保这些消息中不包含任何可能被恶意用户利用的敏感数据。

                      审核和日志记录

                      检查应用程序的审核和日志记录方法。除了防止抵赖之外，定期分析日志文件有助于识别入侵迹象。下表显示了常见的审核和日志记录漏洞。

                      

                      常见的审核和日志记录漏洞

                      测试中需要考虑下列问题，帮助验证应用程序审核和日志记录的方法。

                      . 是否明确了要审核的关键活动。

                      设计必须定义要审核的活动。考虑下列问题：

                      ①是否审核失败的登录尝试。

                      这允许用户检测入侵和密码破解企图。

                      ②是否审核其他关键操作。

                      确保审核其他关键事件，包括数据检索、网络通信和管理功能（如启用和禁用日志记录）。

                      . 是否考虑过如何流动原始调用者身份。

                      设计必须确保跨多个应用程序层来进行审核活动。为此，原始调用者的身份必须在每个层都可用。

                      ①是否跨应用程序层进行审核。

                      检验每个层是否都按预期计划对活动进行审核。

                      ②如何同步多个日志。

                      日志文件是证明个人犯罪行为和解决抵赖问题的法律程序所必需的。通常，在访问资源的时候，如果由访问资源的同一例程生成审核，则审核最具权威性。确认应用程序设计中与日志文件同步相关的问题，然后记录某种形式的请求标识符，确保多个日志文件条目可互相关联，并能关联至同一请求。

                      ③如何流动原始调用者身份。

                      如果不在操作系统级流动原始调用者身份（例如，由于此方法伸缩性有限），应明确应用程序如何流动原始调用者身份。对于跨层审核，这是必需的（对于授权来说，可能同样必需）。

                      此外，如果多个用户映射到同一应用程序角色，应确保应用程序记录原始调用者的身份。

                      . 是否考虑过保护日志文件管理策略。

                      检查应用程序设计是否考虑到日志文件的备份、存档和分析。日志文件必须定期存档来确保不被充满；如果充满，应开始回收。而且，还要经常分析日志文件来检测入侵迹象。此外，确保执行备份的账户都是特权最少的，确保仅为备份而公开的所有附加信道安全。

               应用及传输安全

               Web应用系统的安全性从使用的角度可分为应用级的安全与传输级的安全，安全性测试也可从这两个方面入手。

               应用级的安全测试的主要目的是查找Web应用系统自身程序设计中存在的安全隐患，主要测试区域如下。

               . 注册与登录：现在的Web应用系统基本采用先注册，后登录的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否存在大小写敏感，可以试多少次的限制，是否可以不登录而直接浏览某个页面等。

               . 在线超时：Web应用系统是否有超时的限制，也就是说，用户登录后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登录才能正常使用。

               . 操作留痕：为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件，是否可追踪。

               . 备份与恢复：为了防范系统的意外崩溃造成的数据丢失，备份与恢复手段是一个Web系统的必备的功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段，如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求，某些实时系统经常会采用双机热备或多机热备。除了对于这些备份与恢复方式进行验证测试以外，还要评估这种备份与恢复方式是否满足Web系统的安全性需求。

               传输级的安全测试是考虑到Web系统的传输的特殊性，重点测试数据经客户端传送到服务器端可能存在的安全漏洞，以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。

               . HTTPS和SSL测试：默认的情况下，安全HTTP（Secure HTTP）通过安全套接字SSL（Secure Socket Layer）协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别，但从某种意义上来说，安全性的保证是以损失性能为代价的。除了还要测试加密是否正确，检查信息的完整性和确认HTTPS的安全级别外，还要注意在此安全级别下，其性能是否达到要求。

               . 服务器端的脚本漏洞检验：存在于服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。这可以通过设计一些相应的测试案例来进行验证。

               . 防火墙测试：防火墙是一种主要用于防护非法访问的路由器，在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题，但这里所涉及的只是对防火墙的功能、设置进行测试，以判断是否满足本Web系统的安全需求。

 

 

  测试用例设计方法

        初涉软件测试者可能认为拿到软件后就可以立即进行测试，并希望马上找出软件的所有缺陷，这种想法就如同没有受过工程训练的开发工程师急于去编写代码一样。软件测试也是一个工程，也需要按照工程的角度去认识软件测试，在具体的测试实施之前，我们需要明白我们测试什么，怎么测试等，也就是说通过制定测试用例指导测试的实施。

               什么是测试用例

               所谓的测试用例设计就是将软件测试的行为活动，作一个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。

               简单地说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内，软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已修改完成。

               因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。

               使用测试用例的好处主要体现在以下几个方面。

               ①在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

               ②测试用例的使用令软件测试的实施重点突出、目的明确。

               ③在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。

               ④功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。

               具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。应该说，这些方法是比较实用的，但采用什么方法，在使用时自然要针对开发项目的特点对方法加以适当的选择。下面我们讨论几种常用的方法。

               等价类划分法

               等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的要求和说明，即需求规格说明书。我们必须仔细分析和推敲说明书的各项需求，特别是功能需求。把说明中对输入的要求和输出的要求区别开来并加以分解。

               由于穷举测试工作量太大，以至于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为测试用例。例如，在不了解等价分配技术的前提下，我们做计算器程序的加法测试时，测试了1＋1，1＋2，1＋3和1＋4之后，还有必要测试1＋5和1＋6吗，能否放心地认为它们是正确的？我们感觉1＋5和1＋6，与前面的1＋1，1＋2都是很类似的简单加法。

               等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误（除非等价类中的某些例子属于另一等价类，因为几个等价类是可能相交的）。使用这一方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。

                      划分等价类和列出等价类表

                      等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试。

                      因此，可以把全部输入数据合理地划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。等价类划分有两种不同的情况：有效等价类和无效等价类。

                      有效等价类：指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

                      无效等价类：与有效等价类的定义恰巧相反。

                      设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。

                      下面给出6条确定等价类的原则：

                      ①在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类。

                      ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。

                      ③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

                      ④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

                      ⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

                      ⑥在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。

                      在确立了等价类之后，建立等价类表，列出所有划分出的等价类如下表所示。

                      

                      等价类表示例

                      确定测试用例

                      根据已列出的等价类表，按以下步骤确定测试用例：

                      ①为每个等价类规定一个惟一的编号。

                      ②设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖。

                      ③设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。

                      在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。请看一些例子。

                      在两数相加用例中，测试1＋13和1＋99999999似乎有点不同。这是一种直觉，一个是普通加法，而另一个似乎有些特殊，这个直觉是对的。程序对1和最大数值相加的处理和对两个小一些的数值相加的处理有所不同。后者必须处理溢出情况。因为软件操作可能不同，所以这两个用例属于不同的等价区间。

                      如果具有编程经验，就可能会想到更多可能导致软件操作不同的“特殊”数值。如果不是程序员，也不用担心，你很快就会学到这种技术，无须了解代码细节就可以运用。

                      如下图所示是复制的多种方法，给出了选中编辑菜单后显示复制和粘贴命令的计算器程序。每一项功能（即复制和粘贴）有5种执行方式。要想复制，可以单击复制菜单命令，键入C，按Ctrl＋C或Ctrl＋Shift＋C组合键。任何一种输入途径都会把当前数值复制到剪贴板中，一一执行同样的输出操作，产生同样的结果。

                      

                      复制的多种方法

                      如果要测试复制命令，可以把这5种输入途径划分减为3个，单击菜单命令，键入C和按Ctrl＋C组合键。对软件质量有了信心之后，知道无论以何种方式激活复制功能都工作正常，甚至可以进一步缩减为1个区间，例如按Ctrl＋C组合键。

                      再看下一个例子。看一下在标准的另存为对话框（如下图所示）中输入文件名称的情形。

                      

                      存盘对话框

                      Windows文件名可以包含除了“、”、“/”、“：”、“.”、“？”、“<>”和“＼”之外的任意字符。文件名长度是1~255个字符。如果为文件名创建测试用例，等价区间有合法字符、非法字符、合法长度的名称、过长名称和过短名称。

                      例题：根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例。“一个程序读入3个整数，把这3个数值看作一个三角形的3条边的长度值。这个程序要打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的”。

                      我们可以设三角形的3条边分别为A, B, C。如果它们能够构成三角形的3条边，必须满足：

                      A>0，B>0，C>0，且A＋B>C, B＋C>A, A＋C>B。

                      如果是等腰的，还要判断A＝B，或B＝C，或A＝C。

                      如果是等边的，则需判断是否A＝B，且B＝C，且A＝C。

                      列出等价类表，如下表所示。

                      

                      等价类表

                      设计测试用例：输入顺序是【A, B, C】，如下表所示。

                      

                      测试用例

                      请记住，等价分配的目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。因为，选择了不完全测试，就要冒一定的风险，所以必须仔细选择分类。

                      关于等价分配最后要讲的一点是，这样做有可能不客观。科学有时也是一门艺术。测试同一个复杂程序的两个软件测试员，可能会制定出两组不同的等价区间。只要审查等价区间的人都认为它们足以覆盖测试对象就可以了。

               边界值分析法

               人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上的，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。例如，在做三角形计算时，要输入三角形的3个边长A、B和C。这3个数值应当满足A>0、B>0、C>0、A＋B>C、A＋C>B、B＋C>A，才能构成三角形。但如果把6个不等式中的任何一个大于号“>”错写成大于等于号“≥”，那就不能构成三角形。问题恰恰出现在容易被疏忽的边界附近。这里所说的边界是指相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。

                      边界条件

                      我们可以想象一下，如果在悬崖峭壁边可以自信地安全行走，平地就不在话下了。如果软件在能力达到极限时能够运行，那么在正常情况下一般也就不会有什么问题。

                      边界条件是特殊情况，因为编程从根本上说不怀疑边界有问题。奇怪的是，程序在处理大量中间数值时都是对的，但是可能在边界处出现错误。下面的一段源代码说明了在一个极简单的程序中是如何产生边界条件问题的。

                      

                      这段代码的意图是创建包含10个元素的数组，并为数组中的每一个元素赋初值-1。看起来相当简单。它建立了包含10个整数的数组data和一个计数值i。For循环是从1~10，数组中从第1个元素到第10个元素被赋予数值-1。那么边界问题在哪儿呢？

                      在大多数开发语言脚本中，应当以声明的范围定义数组，在本例中定义语句是dim data（10）as interger，第一个创建的元素是data（0），而不是data（1）。该程序实际上创建了一个从data（0）~data（10）共11个元素的数组。程序从1~10循环将数组元素的值初始化为-1，但是由于数组的第一个元素是data（0），因此它没有被初始化。程序执行完毕，数组值如下：

                      

                      注意data（0）的值是0，而不是-1。如果这位程序员以后忘记了，或者其他程序员不知道这个数据数组是如何初始化的，那么他就可能会用到数组的第1个元素data（0），以为它的值是-1。诸如此类的问题很常见，在复杂的大型软件中，可能导致极其严重的软件缺陷。

                      次边界条件

                      上面讨论的普通边界条件是最容易找到的。它们在产品说明书中有定义，或者在使用软件的过程中确定。而有些边界在软件内部，最终用户几乎看不到，但是软件测试仍有必要检查。这样的边界条件称为次边界条件或者内部边界条件。

                      寻找这样的边界不要求软件测试员具有程序员那样阅读源代码的能力，但是要求大体了解软件的工作方式。2的乘方和ASCII表就是这样的例子。

                             2的乘方

                             计算机和软件的计数基础是二进制数，用位（bit）来表示0和1，一个字节（byte）由8位组成，一个字（word）由两个字节组成等。下表中列出了常用的2的乘方单位及其范围或值。

                             

                             软件中2的乘方

                             上表中所列的范围和值是作为边界条件的重要数据。除非软件向用户提出这些范围，否则在需求文档中不会指明。然而，它们通常由软件内部使用，外部是看不见的，当然，在产生软件缺陷的情况下可能会看到。

                             在建立等价区间时，要考虑是否需要包含2的乘方边界条件。例如，如果软件接受用户输入1~1000范围内的数字，谁都知道在合法区间中包含1和1000，也许还要有2和999。为了覆盖任何可能的2的乘方次边界，还要包含临近双位边界的14、15和16，以及临近字节边界的254、255和256。

                             ASCII表

                             另一个常见的次边界条件是ASCII字符表。如下表所示是部分ASCII值表的清单。

                             

                             部分ASCII值表

                             注意，上表不是结构良好的连续表。0~9的后面ASCII值是48~57。斜杠字符（/）在数字0的前面，而冒号字符“：”在数字9的后面。大写字母A~Z对应65~90。小写字母对应97~122。这些情况都代表次边界条件。

                             如果测试进行文本输入或文本转换的软件，在定义数据区间包含哪些值时，参考一下ASCII表是相当明智的。例如，如果测试的文本框只接受用户输入字符A~Z和a~z，就应该在非法区间中包含ASCII表中这些字符前后的值@、［、和｛。

                             其他一些边界条件

                             另一种看起来很明显的软件缺陷来源是当软件要求输入时（比如在文本框中），不是没有输入正确的信息，而是根本没有输入任何内容，只按了Enter键。这种情况在产品说明书中常常被忽视，程序员也可能经常遗忘，但是在实际使用中却时有发生。程序员总会习惯性地认为用户要么输入信息，不管是看起来合法的或非法的信息，要么就会选择Cancel键放弃输入，如果没有对空值进行好的处理的话，恐怕程序员自己都不知道程序会引向何方。

                             正确的软件通常应该将输入内容默认为合法边界内的最小值，或者合法区间内的某个合理值，否则，返回错误提示信息。

                             因为这些值通常在软件中进行特殊处理，所以不要把它们与合法情况和非法情况混在一起，而要建立单独的等价区间。

                      边界值的选择方法

                      边界值分析是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果。边界值分析法不仅重视输入条件边界，而且也适用于输出域测试用例。

                      对边界值设计测试用例，应遵循以下几条原则：

                      ①如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。

                      ②如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据。

                      ③根据规格说明的每个输出条件，使用前面的原则①。

                      ④根据规格说明的每个输出条件，应用前面的原则②。

                      ⑤如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

                      ⑥如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。

                      ⑦分析规格说明，找出其他可能的边界条件。

               错误推测法

               错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。

               错误推测法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。例如，设计一些非法、错误、不正确和垃圾数据进行输入测试是很有意义的。如果软件要求输入数字，就输入字母。如果软件只接受正数，就输入负数。如果软件对时间敏感，就看它在公元3000年是否还能正常工作。还有，例如，在单元测试时曾列出的许多在模块中常见的错误，以前产品测试中曾经发现的错误等，这些就是经验的总结。另外，输入数据和输出数据为0的情况，或者输入表格为空格或输入表格只有一行，这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

             因果图法

       前节介绍的等价类划分方法和边界值分析法都是着重考虑输入条件，并没有考虑到输入情况的各种组合，也没考虑到各个输入情况之间的相互制约关系。如果在测试时必须考虑输入条件的各种组合，可能的组合数将是天文数字。因此必须考虑描述多种条件的组合，相应地产生多个动作的形式来考虑设计测试用例，这就需要利用因果图。在软件工程中，有些程序的功能可以用判定表的形式来表示，并根据输入条件的组合情况规定相应的操作。很自然，应该为判定表中的每一列设计一个测试用例，以便保证测试程序在输入条件的某种组合下，操作是正确的。

              因果图设计方法

              因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。

              利用因果图导出测试用例需要经过以下几个步骤：

              ①分析程序规格说明的描述中，哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价类，而结果是输出条件。

              ②分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。

              ③标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干个标准的符号标明约束条件。

              ④把因果图转换成判定表。

              ⑤为判定表中每一列表示的情况设计测试用例。

              因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而增加。

              事实上，在较为复杂的问题中，这个方法常常是十分有效的，它能有力地帮助我们确定测试用例。当然，如果哪个开发项目在设计阶段就采用了判定表，也就不必再画因果图了，而是可以直接利用判定表设计测试用例了。

              通常在因果图中，用Ci表示原因，Ei表示结果，其基本符号如下图所示。各结点表示状态，可取“0”或“1”值。“0”表示某状态不出现，“1”表示某状态出现。

             

              因果图的基本图形符号

              ①恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现。

              ②非（~）：若原因出现，则结果不出现；若原因不出现，则结果出现。

              ③或（∨）：若几个原因中有1个出现，则结果出现；若几个原因都不出现，则结果不出现。

              ④与（∧）：若几个原因都出现，结果才出现。若其中有1个原因不出现，则结果不出现。

              为了表示原因与原因之间、结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。从输入（原因）考虑，有4种约束，例如：（a）、（b）、（c）、（d）。从输出（结果）考虑，还有1种约束，例如：（e），如下图所示。

             

              因果图的约束符号

              ①E（互斥）：表示a、b两个原因不会同时成立，两个中最多有一个可能成立。

              ②I（包含）：表示a、b、c这3个原因中至少有一个必须成立。

              ③O（惟一）：表示a和b当中必须有一个，且仅有一个成立。

              ④R（要求）：表示当a出现时，b必须也出现。a出现时不可能b不出现。

              ⑤M（屏蔽）：表示当a是1时，b必须是0。而当a为0时，b的值不定。

              因果图测试用例

              例如：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”或“红茶”按钮，相应的饮料就送出来。若投入的是两元硬币，在送出饮料的同时退还5角硬币。

              分析这一段说明，我们可以列出原因和结果。

              原因：①投入1元5角硬币；②投入2元硬币；

              ③按“可乐”按钮；④按“雪碧”按钮；⑤按“红茶”按钮。

              中间状态：①已投币；②已按钮。

              结果：①退还5角硬币；②送出“可乐”饮料；

              ③送出“雪碧”饮料；④送出“红茶”饮料。

              根据原因和结果，我们可以设计这样一个因果图（如下图所示。）

             

              因果图

              转换为测试用例，如下表所示，每一列可作为确定测试用例的依据。

             

              5-6

               判定表驱动法

               前面因果图方法中已经用到了判定表。判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。在程序设计发展的初期，判定表就已被用作编写程序的辅助工具了。它可以把复杂的逻辑关系和多种条件组合的情况表达得较明确。

                      判定表组成

                      判定表通常由4个部分组成，如下图所示。

                      

                      判定表

                      . 条件桩（condition stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。

                      . 动作桩（action stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

                      . 条件项（condition entry）：列出针对它所列条件的取值，在所有可能情况下的真假值。

                      . 动作项（action entry）：列出在条件项的各种取值情况下应该采取的动作。

                      . 规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，条件项和动作项就有多少列。

                      判定表建立

                      判定表的建立因该依据软件规格说明，步骤如下：

                      ①确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故有2n种规则。

                      ②列出所有的条件桩和动作桩。

                      ③填入条件项。

                      ④填入动作项。制定初始判定表。

                      ⑤简化。合并相似规则或者相同动作。

                      Beizer指出了适合使用判定表设计测试用例的条件：

                      ①规格说明以判定表的形式给出，或很容易转换成判定表。

                      ②条件的排列顺序不影响执行哪些操作。

                      ③规则的排列顺序不影响执行哪些操作。

                      ④当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

                      ⑤如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

               正交试验法

               利用因果图来设计测试用例时，作为输入条件的原因与输出结果之间的因果关系，有时很难从软件需求规格说明中得到。往往因果关系非常庞大，导致利用因果图而得到的测试用例数目多得惊人，给软件测试带来沉重的负担。为了有效地、合理地减少测试的工时与费用，可利用正交试验法进行测试用例的设计。

                      正交试验设计方法

                      依据Galois理论，正交试验设计方法是从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试验设计方法。

                      正交试验法，就是使用已经造好了的表格“——”正交表来安排试验并进行数据分析的一种方法。它简单易行并且计算表格化，应用性较好。下边通过一个例子来说明正交试验法。

                      例题：为提高某化工产品的转化率，选择了三个有关因素进行条件试验，反应温度（A），反应时间（B），用碱量（C），并确定了它们的试验范围如下。

                      . A：80~90℃；

                      . B：90~150分钟；

                      . C：5%~7%。

                      试验目的是搞清楚因子A、B、C对转化率有什么影响，哪些是主要的，哪些是次要的，从而确定最适生产条件，即温度、时间及用碱量各为多少才能使转化率最高。这里，对因子A、B和C，在试验范围内都选了三个水平，如下所示。

                      . A：A1=80℃，A2=85℃，A3=90℃；

                      . B：B1＝90分钟，B2＝120分钟，B3＝150分钟；

                      . C：C1=5%，C2=6%，C3=7%。

                      当然，在正交试验设计中，因子可以是定量的，也可以是定性的。而定量因子各水平间的距离可以相等，也可以不相等。这个三因子三水平的条件试验，通常有两种试验方法：

                      ①取三因子所有水平之间的组合，即A1B1C1，A1B1C2，A1B2C1，……，A3B3C3，共有33＝27次试验。用下图表示立方体的27个节点。这种试验法叫做全面试验法。

                      

                      全面试验法取点

                      全面试验对各因子与指标间的关系剖析得比较清楚。但试验次数太多。特别是当因子数目多，每个因子的水平数目也很多时，试验量非常大。如选6个因子，每个因子取5个水平时，如欲做全面试验，则需56＝15625次试验，这实际上是不可能实现的。如果应用将要介绍的正交试验法，只做25次试验就行了。而且在某种意义上讲，这25次试验代表了15625次试验。

                      ②简单对比法，即变化一个因素而固定其他因素，如首先固定B、C于Bl、Cl，使A变化：

                      

                      如得出结果A3最好，则固定A于A3，C还是Cl，使B变化：

                      

                      得出结果以B2为最好，则固定B于B2，A于A3，使C变化：

                      

                      试验结果以C2为最好。于是就认为最好的工艺条件是A3B2C2。

                      这种方法一般也有一定的效果，但缺点很多。首先这种方法的选点代表性很差，如按上述方法进行试验，试验点完全分布在一个角上，而在一个很大的范围内没有选点，因此这种试验方法不全面，所选的工艺条件A3B2C2不一定是27个组合中最好的。其次，用这种方法比较条件好坏时，是把单个的试验数据拿来，进行数值上的简单比较，而试验数据中必然包含着误差成分，所以单个数据的简单比较不能剔除误差，必然造成结论的不稳定。

                      简单对比法的最大优点就是试验次数少，例如，6因子5水平试验，在不重复时，只用5＋（6-1）×（5-1）＝5＋5×4＝25次试验就可以了。

                      考虑兼顾这两种试验方法的优点，从全面试验的点中选择具有典型性、代表性的点，使试验点在试验范围内分布得很均匀，能反映全面情况。但我们又希望试验点尽量地少，为此还要具体考虑一些问题。如上例，对应于A有A1、A2、A3 3个平面，对应于B、C也各有3个平面，共9个平面。则这9个平面上的试验点都应当一样多，即对每个因子的每个水平都要同等看待。具体来说，每个平面上都有3行、3列，要求在每行、每列上的点一样多。这样，作出如下图所示的设计，试验点用⊙表示。我们看到，在9个平面中每个平面上都恰好有3个点，而每个平面的每行每列都有1个点，而且只有1个点，总共9个点。这样的试验方案，试验点的分布很均匀，试验次数也不多。

                      

                      正交试验设计图例

                      当因子数和水平数都不太大时，尚可通过作图的办法来选择分布很均匀的试验点。但是因子数和水平数多了，作图的方法就不行了。试验工作者在长期的工作中总结出一套办法，创造出所谓的正交表。按照正交表来安排试验，既能使试验点分布得很均匀，又能减少试验次数，而且计算分析简单，能够清晰地阐明试验条件与指标之间的关系。用正交表来安排试验及分析试验结果，这种方法叫正交试验设计法。

                      一般用L代表正交表，常用的有L8（27）、L9（34）、L16（45）、L8（4×24）等。此符号各数字的意义如下。

                      例如：L8（27），其中，7为此表列的数目（最多可安排的因子数）；2为因子的水平数；8为此表行的数目（试验次数）。

                      又例如：L18（2×37），有7列是3水平的，有1列是2水平的，L18（2×37）的数字告诉我们，用它来安排试验，做18个试验最多可以考察1个2水平因子和7个3水平因子。

                      在行数为mn型的正交表中（m, n是正整数），试验次数（行数）＝Σ（每列水平数-1）＋1，如L8（27），8=7×（2-1）＋1，利用上述关系式可以从所要考察的因子水平数来决定最低的试验次数，进而选择合适的正交表。比如要考察5个3水平因子及一个2水平因子，则起码的试验次数为5×（3-1）＋1×（2-1）＋1＝12（次），这就是说，要在行数不小于12，既有2水平列又有3水平列的正交表中选择，L18（2×37）适合。正交表具有两条性质：每一列中各数字出现的次数都一样多；任何两列所构成的各有序数对出现的次数都一样多。所以称之为正交表。

                      例如，在L9（34）中（如下表所示），各列中的1、2、3都各自出现3次；任何两列，例如第3、4列，所构成的有序数对从上向下共有9种，既没有重复也没有遗漏。其他任何两列所构成的有序数对也是这9种各出现一次。这反映了试验点分布的均匀性。

                      

                      L9（34）正交表

                      试验方案应该如何设计呢？安排试验时，只要把所考察的每一个因子任意地对应于正交表的一列（一个因子对应一列，不能让两个因子对应同一列），然后把每列的数字“翻译”成所对应因子的水平。这样，每一行的各水平组合就构成了一个试验条件（不考虑没安排因子的列）。对于上例，因子A、B、C都是3水平的，试验次数要不少于3×（3-1）＋1＝7（次），可考虑选用L9（34）。因子A、B、C可任意地对应于L9（34）的某三列，例如A、B、C分别放在1、2、3列，然后试验按行进行，顺序不限，每一行中各因素的水平组合就是每一次的试验条件，从上到下就是这个正交试验的方案，如下表所示。这个试验方案的几何解释正好是正交试验设计图例。

                      

                      试验方案

                      3个3水平的因子，做全面试验需要33＝27次试验，现用L9（34）来设计试验方案，只要做9次，工作量减少了2/3，而在一定意义上代表了27次试验。

                      正交试验测试用例设计步骤

                      利用正交试验设计测试用例的步骤如下。

                      . 提取功能说明，构造因子“——”状态表。把影响实验指标的条件称为因子，而影响实验因子的条件叫做因子的状态。利用正交试验设计方法来设计测试用例时，首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当做状态。对软件需求规格说明中的功能要求进行划分，把整体的、概要性的功能要求进行层层分解与展开，分解成具体的、有相对独立性的基本的功能要求。这样就可以把被测试软件中所有的因子都确定下来，并为确定因子的权值提供参考的依据。确定因子与状态是设计测试用例的关键。因此，要求尽可能全面地、正确地确定取值，以确保测试用例的设计做到完整与有效。

                      . 加权筛选，生成因素分析表。对因子与状态的选择可按其重要程度分别加权。可根据各个因子及状态作用的大小、出现频率的大小以及测试的需要，确定权值的大小。

                      . 利用正交表构造测试数据集，正交表的推导依据Galois理论。

                      利用正交试验设计方法设计测试用例，与使用等价类划分、边界值分析、因果图等方法相比，有以下优点：节省测试工作工时；可控制生成的测试用例的数量；测试用例具有一定的覆盖率。

                      正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面，我们要选择哪种组合方式是最好的，每个参数可能就是一个因子，参数的不同取值就是水平，这样我们可以采用正交试验法设计出最少的测试组合，达到有效的测试目的。

               功能图法

               一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序，由于存在大量的组合情况，因此，仅用静态说明组成的规格说明对于测试来说往往是不够的，必须用动态说明来补充功能说明。

                      功能图设计方法

                      功能图方法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成。

                      . 状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。

                      . 逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。

                      功能图方法实际上是一种黑盒、白盒混合用例设计方法。

                      功能图方法中要用到逻辑覆盖和路径测试的概念和方法，属白盒测试方法中的内容。逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法，该方法要求测试人员对程序的逻辑结构有清楚的了解。由于覆盖测试的目标不同，逻辑覆盖可分为：语句覆盖、判定覆盖、判定-条件覆盖，条件组合覆盖及路径覆盖。下面我们指的逻辑覆盖和路径是功能或系统水平上的，以区别于白盒测试中的程序内部的，如下图及下表所示。

                      

                      功能图

                      

                      判定表

                      

                      功能图法生成测试用例

                      功能图由状态迁移图和布尔函数组成。状态迁移图用状态和迁移来描述一个状态，指出数据输入的位置（或时间），而迁移则指明状态的改变，同时要依靠判定表和因果图表示的逻辑功能。

                      采用什么样的方法生成测试用例？从功能图生成测试用例，得到的测试用例数是可接受的。问题的关键是如何从状态迁移图中选取测试用例。若用节点代替状态，用弧线代替迁移，状态迁移图就可转化成一个程序的控制流程图形式。问题就转化为程序的路径测试问题（白盒测试范畴概念）了。

                      测试用例生成规则：为了把状态迁移（测试路径）的测试用例与逻辑模型的测试用例组合起来，从功能图生成实用的测试用例，需定义下面的规则。一个结构化的状态迁移中，定义3种形式的循环：顺序、选择和重复。但分辨一个状态迁移中的所有循环是有困难的。

                      从功能图生成测试用例的过程如下。

                      . 生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试库由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。

                      . 测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径。

                      . 测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是视状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据组合。

                      . 测试用例的合成算法：采用条件构造树。

               场景法

               现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

               提出这种测试思想的是Rational公司，并在RUP2000中文版中有详尽的解释和应用。

               用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。

                      基本流和备选流

                      如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

                      按照如下图中所示的每个经过用例的路径，可以确定以下不同的用例场景。

                         

                      基本流和备选流

                      场景1：基本流；

                      场景2：基本流、备选流1；

                      场景3：基本流、备选流1、备选流2；

                      场景4：基本流、备选流3；

                      场景5：基本流、备选流3、备选流1；

                      场景6：基本流、备选流3、备选流1、备选流2；

                      场景7：基本流、备选流4；

                      场景8：基本流、备选流3、备选流4。

                      注：为方便起见，场景5、6和8只考虑了备选流3循环执行一次的情况。

                      需要说明的是，为了能清晰地说明场景，我们所举的例子都非常简单，在实际应用中，测试用例很少如此简单。

                      ATM例子

                             例子描述

                             如下图所示是ATM例子的流程示意图。

                               

                             ATM流程示意图

                             如下表所示，包含了如上图中所示提款用例的基本流和某些备用流。

                              

                             用例流

                              

                             场景设计

                             如下表所示是生成的场景。

                              

                             场景设计

                             注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入表中。

                             用例设计

                             对于这7个场景中的每一个场景都需要确定测试用例，一般采用矩阵或决策表来确定和管理测试用例。如下表所示是一种通用格式，其中行代表各个测试用例，列代表测试用例的信息。本例中的测试用例包含测试用例ID、场景/条件、测试用例中涉及的所有数据元素和预期结果等项目。首先确定执行用例场景所需的数据元素，然后构建矩阵，最后要确定包含执行场景所需的适当条件的测试用例。在下面的矩阵中，V表示这个条件必须是有效的才可执行基本流，I表示这种条件下将激活所需备选流，n/a表示这个条件不适用于测试用例。

                              

                             测试用例表

                             在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例CW1被称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由CW2~CW6表示。虽然CW2~CW6相对于基本流而言都是负面测试用例，但它们相对于备选流2~4而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例，就是CW1-基本流。

                             每个场景只有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场景4-PIN有误，至少需要三个正面测试用例，以激活场景4：

                             ①输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3-输入PIN。

                             ②输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

                             ③最后一次输入时输入了“正确”的PIN。备选流在步骤5-输入金额处重新加入基本流。

                             注意，在上面的矩阵中，无需为条件输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看V和I，这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个无效的条件I，这表明测试用例还不完全，如场景6-不存在的账户/账户类型有误和场景7-账户余额不足就缺少测试用例。

                             数据设计

                             一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

                              

                             测试数据表

                             测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。

                             以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括以下内容。

                             场景6——账户不存在/账户类型有误：未找到账户或账户不可用；

                             场景6——账户不存在/账户类型有误：禁止从该账户中提款；

                             场景7——账户余额不足：请求的金额超出账面金额。

                             在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：

                             ①无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）；

                             ②无法读卡（读卡机堵塞、脱机或出现故障）；

                             ③账户已消户、冻结或由于其他方面原因而无法使用；

                             ④ATM内的现金不足或不能提供所请求的金额（与CW3不同，在CW3中只是一种币值不足，而不是所有币值都不足）；

                             ⑤无法联系银行系统以获得认可；

                             ⑥银行网络离线或交易过程中断电。

                             结论：所有从事软件测试和即将从事软件测试的人大都是从黑盒测试做起的，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，它能极大地提高测试效率和测试覆盖度，认真掌握这些方法的原理，有效提高测试水平，积累更多的测试经验，这是测试人员最宝贵的财富。

               测试方法选择的综合策略

               测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，在实际测试中，往往是综合使用各种方法才能有效地提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效地提高测试水平。

               以下是各种测试方法选择的综合策略，可供读者在实际应用过程中参考。

               ①首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。

               ②在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。

               ③可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。

               ④对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

               ⑤如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。

               ⑥对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

               ⑦功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。

               ⑧对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。

 

       用例设计

        对于这7个场景中的每一个场景都需要确定测试用例，一般采用矩阵或决策表来确定和管理测试用例。如下表所示是一种通用格式，其中行代表各个测试用例，列代表测试用例的信息。本例中的测试用例包含测试用例ID、场景/条件、测试用例中涉及的所有数据元素和预期结果等项目。首先确定执行用例场景所需的数据元素，然后构建矩阵，最后要确定包含执行场景所需的适当条件的测试用例。在下面的矩阵中，V表示这个条件必须是有效的才可执行基本流，I表示这种条件下将激活所需备选流，n/a表示这个条件不适用于测试用例。

         

        测试用例表

        在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例CW1被称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由CW2~CW6表示。虽然CW2~CW6相对于基本流而言都是负面测试用例，但它们相对于备选流2~4而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例，就是CW1-基本流。

        每个场景只有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场景4-PIN有误，至少需要三个正面测试用例，以激活场景4：

        ①输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3-输入PIN。

        ②输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

        ③最后一次输入时输入了“正确”的PIN。备选流在步骤5-输入金额处重新加入基本流。

        注意，在上面的矩阵中，无需为条件输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看V和I，这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个无效的条件I，这表明测试用例还不完全，如场景6-不存在的账户/账户类型有误和场景7-账户余额不足就缺少测试用例。

 

 

 测试用例设计

               白盒测试的测试用例设计

               白盒测试是对软件的过程性细节做详细检查。通过对程序内部结构和逻辑的分析来设计测试用例。适合于白盒测试的设计技术主要有：逻辑覆盖法、基本路径测试等。下面将介绍逻辑覆盖法。

               逻辑覆盖（Logic Coverage）是以程序内部的逻辑结构为基础的测试技术。它考虑的是测试数据执行（覆盖）程序的逻辑程度。由于穷举测试是不现实的，因此，只希望覆盖的程度更高些。根据覆盖情况的不同，逻辑覆盖可分为：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、多重覆盖、路径覆盖。在讨论这几种覆盖时，均以下图所示的程序段为例。这是一个非常简单的程序，共有两个判断、4条不同路径。为了方便起见，分别对第一个判断取假分支，对第一个判断取真分支，对第二个判断取假分支，对第二个判断取真分支并分别命名为b、c、d和e。4条路径表示为abd、acd、abe和ace。其Pascal程序为：

                

                

               被测试程序的流程图

               （1）语句覆盖。

               语句覆盖（Statement Coverage）就是设计若干个检测用例，使得程序中的每条语句至少被执行一次。在所举的示例中，只要选择能通过路径ace的测试用例即可。如：

                

               语句覆盖对程序的逻辑覆盖程度很低，如果把第一个判断语句中的AND错写成OR，或把第二个判断语句中的OR错写成AND，用上面的测试用例是不能发现问题的。这说明语句覆盖有可能发现不了判断条件中算法出现的错误。

               （2）判定覆盖。

               判定覆盖（Decision Coverage）也被称为分支覆盖，就是设计若干个检测用例，使得程序中的每个判断的取真分支和取假分支至少被执行一次。对上述被测程序来说，需要设计测试用例覆盖路径acd和abe（或abd和ace）。可以选择如下的输入数据：

                

               还可以选择另外两组输入数据：

                

               判断覆盖比语句覆盖的程度稍高，因为如果通过了每个分支的测试，则各语句也都被执行了。但仍有不足，如上述的测试用例不能发现把第二个判断语句中的X>1错写成X<1的错误。所以，判断覆盖还不能保证一定能查出判断条件中的错误。因此，需要更强的逻辑覆盖来检测内部条件的错误。

               （3）条件覆盖。

               条件覆盖（Condition Coverage）就是设计若干个测试用例，使得被测程序中每个判断的每个条件的所有可能情况都至少被执行一次。

               上述被测程序，共有4个条件：

                

               为此，需要设计测试用例，使得a点出现测试结果：

                

               并使b点出现测试结果：

                

               可以设计两组测试输入数据：

                

               条件覆盖通常比判断覆盖强，因为条件覆盖可以使判断语句中的每个条件都能取两个不同的结果。但有可能出现虽然每个条件都取了不同的结果，但判断表达式却始终是一个值的情况，请看下面两组输入数据：

                

               它们满足条件覆盖，但不满足语句覆盖和判断覆盖的标准（未经历路径c，那么就发现不了X=X/A错写成X=X/B的错误）。因此，需要对条件及判断产生的分支兼顾，这就是下面要介绍的判断／条件覆盖。

               （4）判断／条件覆盖。

               判断／条件覆盖（Decision/Condition Coverage）是既要满足判断覆盖的要求，又要满足条件覆盖的要求。也就是设计若干个测试用例，使得程序中的每个判断的取真分支和取假分支至少执行一次，而且每个条件的所有可能情况都至少被执行一次。对于上图而言，下面两组输入数据可以满足判断／条件覆盖的要求：

                

               但这两组数据也是条件覆盖中所举的示例。因此，有时判断／条件覆盖并不比条件覆盖更强，逻辑表达式的错误也不一定能被检查出来。

               （5）多重覆盖。

               多重覆盖（Multi-job Coverage）就是设计多个测试用例，使得各判断表达式中条件的各种组合至少被执行一次。就上图所示的例子而言，要符合多重覆盖的标准，所设计的测试用例必须满足下面的8种条件组合：

                

               要测试到这8种情况，可以选择下列4组输入数据：

                

               很显然，多重覆盖包含了条件覆盖、判断覆盖和判断／条件覆盖，是前面几种覆盖标准中最强的。但就上面的4组输入数据，也没有将程序中的每条路径都覆盖了，如：没有通过acd这条路径，所以测试仍不完全。

               （6）路径覆盖。

               路径覆盖就是设计足够多的测试示例，使被测程序中的所有可能路径至少被执行一次。对上面的例子束说，可以选择这样的4组测试数据来覆盖程序中的所有路径：

                

               路径覆盖保证了程序中的所有路径都至少被执行一次，是一种比较全的逻辑覆盖标准。但它没有检查判断表达式中条件的各种组合情况，通常把路径覆盖和多重覆盖结合起来就可以得到查错能力很强的测试用例。如上面的例子，把多重覆盖的4组输入数据和路径覆盖中的第3组数据组合成起来，形成5组输入数据，就可以得到既满足路径覆盖的标准，又满足多重覆盖的标准。

               （7）循环覆盖。

               上面介绍的只是语句、分支、条件以及它们的组合情况，而循环也是大多数算法的基础：对循环的测试主要检查循环构造的有效性。循环分为简单循环（Simple Loops）、串联循环（Concatenated Loops）、嵌套循环（Nested Loops）和非结构循环（Unstructured Loops）4种类型，如下图所示。

                

               循环的4种类型

               对于循环次数为n的简单循环。可以采用下列措施进行测试。

               .跳过整个循环。

               .循环次数为1，2，n-1，n，n+1。

               .任取循环次数为m，其中m

               对于嵌套循环，如果采用简单循环的测试方法，则测试次数将会成几何级数增长。可以采用以下方法进行测试。

               .从最内层循环开始测试，对所有外层循环都取最小值，内层循环按简单循环的测试方法进行。

               .由里向外，一层层进行测试，凡是外层的循环都取最小值，该层循环嵌套的那些循环取一些典型的值。

               .直至所有循环测试完毕。

               对于串联循环的测试可分成两种情况：如果两个循环是独立的，则采用简单循环的测试方法；反之，如果两个循环不是独立的，则需要用嵌套循环的测试方法来测试，对于非结构循环，一般先把程序结构化之后再进行测试。

               黑盒测试的测试用例设计

               黑盒测试是在测试时把软件看成一个黑盒子，完全不考虑程序的内部结构及其逻辑，重点考察程序功能是否与需求说明书的要求一致。适合于黑盒测试的设计技术主要有：等价类划分、边界值分析、错误推测法、因果图、功能图等。下面重点介绍等价类划分、边界值分析这两种测试技术。

               （1）等价类划分。

               等价类划分是比较典型的黑盒测试技术。如前所述，输入量的穷举测试是不现实的，那么如何才能既可大大减少测试的次数、又不丢失发现错误的机会是问题的关键所在。等价类划分技术的主要思想就是程序的输入数据都可以按照程序说明划分为若下个等价类，每一个等价类对于输入条件可划分为有效的输入和无效的输入，然后再对每一个有效的等价类和无效的等价类设计测试用例。如果用某个等价类的一组测试数据进行测试时没有发现错误，则说明在同一等价类中的其他输入数据也一样查不出问题；反之，如用某个等价类的测试数据进行测试，并检查出错误，则说明用该等价类的其他输入数据进行测试也一样会检测出错误。所以在测试时，只需从每个等价类中取一组输入数据进行测试即可。

               使用等价类划分技术设计测试方案时，首先需要根据程序的功能说明划分出输入数据的有效等价类和无效等价类，然后为每个等价类设计测试用倒。在确定输入数据的等价类时常常还需要分析输出数据的等价类，以便根据输出数据的等价类来推导出对应的测试用例。

               在划分等价类时，可以按以下原则进行。

               .如果规定了输入数据的范围，则可划分为一个有效等价类和两个无效等价类。如学生年龄输入的范围为0～100,则有效等价类为“0≤年龄≤100”，两个无效等价类为“年龄>100”或“年龄<0”。

               .如果规定了输入数据的个数，则可划分为一个有效等价类和两个无效等价类。如一个老师在指导毕业设计时必须指导1～5个学生，则有效等价类为“学生人数是1～5个”，两个无效等价类为“一个都不指导”或“指导人数超过5个”。

               .如果规定了输入数据为一组可能的值，而且程序对每个输入值分别进行处理，这时需要为每个输入数据确定一个有效等价类，把除此之外的所有值确定为一个无效等价类。如在教师涨工资的方案中根据职称（教授、副教授、讲师和助教）的不同其增长幅度也不相同，这时需要对每个职称确定一个有效的等价类（共4个），还有一个无效的等价类，它包含不满足以上身份的所有输入数据。但是，如果在程序对这些可能值的处理都一样时，只需要确定一个有效等价类（所有合理值）和一个无效等价类（除合理值之外的其他任何值）。

               .如果规定了输入数据必须遵守的规则，则可以划分出一个有效等价类（遵守规则的输入数据）和若干个无效等价类（从不同角度设计得到违反规则的情况）。

               .如果在划分的某等价类中各值在程序中的处理方式不同，则需要将该等价类进一步划分成更小的等价类。

               以上列出的原则只是实际情况中很小的一部分。为了正确划分等价类，需要正确分析被测程序的功能。划分等价类的方法是根据每个输入条件（通常是规范说明中的一句话或一个短语）列出两个或更多的等价类，将其填入下表中，建立等价类表。

                

               等价类表

               根据等价类表设计测试用例，完成下面两个步骤。

               .设计新的测试用例，使其尽可能多地覆盖未被覆盖的有效等价类，重复这一步骤直至所有有效等价类都被覆盖。

               .设计新的测试用例，使其覆盖一个而且仅此一个未被覆盖的无效等价类，重复这一步骤直至所有无效等价类都被覆盖。

               之所以这么做，是因为程序在遇到错误之后就不会再检查是否还有其他错误。所以一个测试用例只能覆盖一个无效等价类。

               例如，判断是否为三角形的条件是其中任意两个数之和应大于第三个数。假入输入的三个数表示三角形的三个边，可以建立如下表所示的等价类表。

                

               三角形判断的等价类表

               根据等价类表可设计如下测试用例：

                

               （2）边界值分析。

               边界值分析也是黑盒测试技术，是等价类划分的一种补充。通常，程序在处理边界时容易发生错误。而等价类划分技术是在等价类中随便选择一组数据作为代表，并没有考虑边界情况。边界值分析是指将每个等价类的各边界作为测试目标，使得测试数据等于、刚刚小于、或刚大于等价类的边界值。

               边界值分析技术在设计测试用例的原则与等价类划分技术的许多方面类似。需要注意的是，边界值分析技术不仅应注意输入条件的边值，还应根据输出条件的边值设计测试用例（下面的④、⑤原则就是针对输出条件的边值问题）。选择测试用例有以下原则：

               ①如果规定了输入数据的范围，则应取等于该范围的边界值，以及刚刚超过这个范围的边界值的测试数据。如某数输入的范围是从0～1.0，则可选“-0.01”、“0”、“1.0”和“1.01”作为测试数据。

               ②如果规定了输入数据的个数，则应取最大个数、最小个数、比最大个数多1和比最小个数少1的数作为测试数据。如一个老师在指导毕业设计时必须指导1～5个学生，则可选指导人数分别为0个、1个、5个和6个作为测试数据。

               ③如果程序中使用了内部数据结构，则需要选择该数据结构的边界值作为测试用例。如在程序中使用了一个数组，其下标值的范围为0～20，这就需要选择达到该数组的下标边界值（即0与20）作为测试数据。

               ④根据规格说明的每个输出条件可以使用第①条原则。如某个被测程序的输出值在0～1之间，则需要设计测试用例使得其输出值分别为0和1。

               ⑤根据规格说明的每个输出条件也可以使用第②条原则。如某个被测程序在显示时要求显示的记录数最多为5条，则需要设计测试用例使得其输出的记录数分别为0条、1条和5条。

               例如，前面的三角形判断示例中，如果把a+b>c错误写成a+b≥c，等价类划分方法通常无法发现这个错误。使用边界值分析技术，则会选择这样的测试用例：

                

               这组数据就能发现上述错误。

               从这里可以看出，边界值分折与等价类划分技术最大的区别是边界值分析技术在设计测试用例时，将重点检测等价类边界和边界附近的情况，而等价类划分技术只是在每个等价类中随便选择一组测试数据。

               在设计测试方案中，通常会把逻辑覆盖、等价类划分和边界值分析等方法结合起来，这样既可以检测设计的内部要求，又可以检测设计的接口要求。

               在对非常庞大、复杂的信息系统进行测试时，如果严格按照上面所介绍的测试技术进行，所花费的人力、时间无疑是非常大的。考虑到测试中存在着群集现象以及软件的可重用性，在实际的测试过程中，可以采用抽样测试或重点测试。也就是有针对性地选择具有代表性的测试用例进行测试，或把测试的重点放在容易出错的地方及重要模块上。这样可以以较少资源发现错误，也就提高了测试效率。

 

 

 

 

因果图

       因果图又称为Ishikawa图、因果分析图、石川图、鱼骨图或鱼刺图，用于说明各种直接原因和间接原因与所产生的潜在问题和影响之间的关系，如下图所示。

       

       因果图的基本形式

       因果图法是全球广泛采用的一项技术。该技术首先确定结果（质量问题），然后分析造成这种结果的原因。每个分支都代表着可能的差错原因，用于查明质量问题的可能所在和设立相应检验点。它可以帮助项目班子事先估计可能会发生哪些质量问题，然后帮助提供解决这些问题的途径和方法。

       一般来说，造成质量问题的原因主要有人、机器、原材料、方法和环境5个方面，即4M1E因素，所以可以预先将这5个因素列入原因虚线的方框中，然后把各种原因从大到小，从粗到细分解，直到能够采取措施消除这些原因为止。

       绘制因果图的6个步骤如下。

       （1）确定问题。通常用其他统计过程控制工具完成，例如帕累托分析、直方图、控制图和头脑风暴法等，其结果可以对问题进行简洁、清晰的描述。

       （2）选择各学科的头脑风暴班子。按照确定问题所需要的技术、分析和管理知识来选择不同学科的专家组成的头脑风暴班子。

       （3）画问题框和主箭头。包括用于因果评价的问题说明，主箭头作为主要类别的分类基础。

       （4）具体化主要分类。确定问题框中所说问题的主要类别。问题主要原因的几个基本类别是4M1E，其他类别可以具体说明，根据情况而定。

       （5）识别问题原因。当已经识别问题的主要原因时，可以确定与每一类主要因素相关的原因。这里可以用到随机方法、系统方法和过程分析方法。

       （6）确定纠正措施。根据识别的原因，找到纠正问题的措施。

判定表

        判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件组合的取值及其相应要执行的操作构成规则，条目中的每一列是一条规则。

        条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试用例。

        建立并优化判定表，把判定表中每一列表示的情况写成测试用例。

        该方法的使用有以下要求：

        （1）需求规格说明以判定表形式给出，或是很容易转换成判定表。

        （2）条件的排列顺序不会影响执行哪些操作。

        （3）规则的排列顺序不会影响执行哪些操作。

        （4）每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

        （5）如果某一规则的条件的满足，将执行多个操作，这些操作的执行与顺序无关。

 

 软件测试过程模型

        在软件开发几十年的实践过程中，人们总结了很多的开发模型，比如瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发（RAD）以及最近比较流行的Rational统一过程（RUP）等，这些模型对于软件开发过程具有很好的指导作用，但是，非常遗憾的是，在这些过程方法中，并没有充分强调测试的价值，也没有给测试以足够的重视，利用这些模型无法更好地指导测试实践。软件测试是与软件开发紧密相关的一系列有计划的系统性的活动，显然软件测试也需要测试模型去指导实践，非常可喜的是软件测试专家通过测试实践总结出了很多很好的测试模型。当然由于测试与开发的结合非常紧密，在这些测试模型中也都把开发过程进行了很好的总结，体现了测试与开发的融合，下面对主要的模型做一简单的介绍。

               V模型

               V模型是最具有代表意义的测试模型，如下图所示。V模型最早是由Paul Rook在20世纪80年代后期提出的，V模型在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果。

               在传统的开发模型中，比如瀑布模型，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时测试工作会占用整个项目周期一半的时间，但是有人仍然认为测试只是一个收尾工作，而不是主要的过程。V模型的推出就是对此种认识的改进。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如模型图（下图）中所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

               

               软件测试V模型

               V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。

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

               V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。

               W模型

                      W模型建立

                      V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是与此相并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE std 1012-1998《软件验证和确认（V&V）》的原则。

                      一个基于V&V原理的W模型示意图如下图所示。

                      

                      软件测试W模型

                      W模型应用

                      W模型由Evolutif公司提出，相对于V模型，W模型更科学。W模型可以说是V模型自然而然的发展。它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。这样，只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。

                      如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地面对规格说明书的挑战。这意味着测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。

                      根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例，这些工作对测试的各级别都有意义。当需求被提交后，就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后，就需要确定测试条件来查找该阶段的设计缺陷。

                      W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充，或者根本没有文档的做法下（这已成为一种开发的文化），开发人员和测试人员都面临同样的困惑。

               H模型

                      H模型建立

                      V模型和W模型均存在一些不妥之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在互相牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以，相应的测试之间也不存在严格的次序关系。同时，各层次之间的测试也存在反复触发、迭代和增量关系。其次，V模型和W模型都没有很好地体现测试流程的完整性。

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

                      H模型应用

                      H模型的简单示意图如下图所示。

                      

                      软件测试H模型

                      这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程自身。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。

                      概括地说，H模型揭示了：

                      . 软件测试不仅仅指测试的执行，还包括很多其他的活动。

                      . 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

                      . 软件测试要尽早准备，尽早执行。

                      . 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

                      在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

               其他模型

                      X模型

                      由于V模型受到了很多人的质疑，因此，也有人提出了一些不同的观点和意见。在此，我们向大家介绍另外一种测试模型，即X模型，其目标是弥补V模型的一些缺陷。

                      X模型的基本思想是由Marick提出的，但首先Marick不建议建立一个替代模型，同时，他也认为他的观点并不足以支撑一个模型的完整描述。不过，Robin F. Goldsmith先生在自己的文章里将其思想定义为X模型，理由是，在Marick的观点中已经具备一个模型所需要的一些主要内容，其中也包括了像探索性测试这样的亮点。软件测试X模型如下图所示。

                      

                      软件测试X模型

                      Marick对V模型最主要的批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接、频繁重复的集成以及需求文档的缺乏等。Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。

                      X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后，将进行频繁的交接，通过集成最终合成为可执行的程序。这一点在图的右上方得以体现，而且这些可执行程序还需要进行测试，已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。

                      同时，X模型还定位了探索性测试，即如上图中右下方所示。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下，结果会怎么样”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

                      Marick对V模型提出质疑，也是因为V模型是基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。因为在实践过程中，很多项目是缺乏足够的需求的，而V模型还是从需求处理开始。

                      Marick也质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。Marick担心人们盲目地跟随“学院派的V模型”，按照模型所指导的步骤进行工作，而实际上某些做法并不切合实用。

                      前置测试模型

                      前置测试模型是由Robin F. Goldsmith等人提出的，它是一个将测试和开发紧密结合的模型，该模型提供了轻松的方式，可以使你的项目加快速度。前置测试模型如下图所示。

                      

                      前置测试模型

                      前置测试模型体现了以下的要点。

                      . 开发和测试相结合：前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。并且标识了这些行为在项目周期中的价值所在。如果其中有些行为没有得到很好的执行，那么项目成功的可能性就会因此而有所降低。如果有业务需求，则系统开发过程将更有效率。我们认为在没有业务需求的情况下进行开发和测试是不可能的。而且，业务需求最好在设计和开发之前就被正确定义。

                      . 对每一个交付内容进行测试：每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是惟一需要测试的内容。图中的椭圆框表示了其他一些要测试的对象，包括可行性报告、业务需求说明，以及系统设计文档等。这同V模型中开发和测试的对应关系是一致的，并且在其基础上有所扩展，变得更为明确。

                      . 在设计阶段进行测试计划和测试设计：设计阶段是作测试计划和测试设计的最好时机。很多组织要么根本不作测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和测试设计。在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。

                      . 测试和开发结合在一起：前置测试将测试执行和开发结合在一起，并在开发阶段以编码—测试—编码—测试的方式来体现。也就是说，程序片段一旦编写完成，就会立即进行测试。一般情况下，先进行的测试是单元测试，因为开发人员认为通过测试来发现错误是最经济的方式。但也可参考X模型，即一个程序片段也需要相关的集成测试，甚至有时还需要一些特殊测试。对于一个特定的程序片段，其测试的顺序可以按照V模型的规定，但其中还会交织一些程序片段的开发，而不是按阶段完全地隔离。

                      . 让验收测试和技术测试保持相互独立：验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。验收测试既可以在实施阶段的第一步来执行，也可以在开发阶段的最后一步执行。前置测试模型提倡验收测试和技术测试沿循两条不同的路线来进行，每条路线分别地验证系统是否能够如预期设想的那样进行正常工作。这样，当单独设计好的验收测试完成了系统的验证时，我们即可确信这是一个正确的系统。

               测试模型的使用

               前面我们介绍了几种典型的测试模型，应该说这些模型对指导测试工作的进行具有重要的意义，但任何模型都不是完美的。我们应该尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没有实际意义。

               在这些模型中，V模型强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地指出应该对软件的需求、设计进行测试，而这一点在W模型中得到了补充。W模型强调了测试计划等工作的先行和对系统需求和系统设计的测试，但W模型和V模型一样也没有专门针对软件测试的流程予以说明，因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发部的组织，就每一个软件测试的细节而言，它都有一个独立的操作流程。比如，现在的第三方测试，就包含了从测试计划和测试案例编写，到测试实施以及测试报告编写的全过程，这个过程在H模型中得到了相应的体现，表现为测试是独立的。也就是说，只要测试前提具备了，就可以开始进行测试了。当然，X模型和前置测试模型又在此基础上增加了许多不确定因素的处理情况，因为在真实项目中，经常会有变更的发生，例如需要重新访问前一阶段的内容，或者跟踪并纠正以前提交的内容，修复错误，排除多余的成分，以及增加新发现的功能等。

               因此，在实际的工作中，我们要灵活地运用各种模型的优点，在W模型的框架下，运用H模型的思想进行独立地测试，并同时将测试和开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。

 

 

过程模型

        产品开发生命周期通常使用过程模型进行表示。过程模型习惯上也称为开发模型，它是系统开发全部过程、活动和任务的结构框架。典型的开发过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。

               瀑布模型（Waterfall Model）

               瀑布模型是将系统生存周期各个活动规定为依线性顺序连接的若干阶段的模型，也称为线性模型。它包括需求分析、设计、实现、测试、运行和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落，如下图所示。

                

               瀑布模型

               瀑布模型为系统的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于系统需求很明确的软件项目的模型。

               瀑布模型假设一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现产生。瀑布模型的优点是，容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或三个阶段中，很难评估真正的进度状态；当接近项目结束时，出现了大量的集成和测试工作；直到项目结束之前，都不能演示系统的能力。在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。

               瀑布模型的一个变体是V模型，如下图所示。V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。随着团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其实际上是执行了一系列测试（质量保证活动），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。

                

               V模型

               增量模型（Incremental Model）

               增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”，如下图所示。当使用增量模型时，第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

                

               增量模型

               增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：第一个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布了第一个版本，因此可以减少用户需求的变更；运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。

               增量模型有以下不足之处：如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力。

               原型模型（Prototype Model）

               并非所有的需求都能够预先定义，大量的实践表明，在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于客户往往不能准确地表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型（rapid prototype）这种新的开发方法。原型方法比较适合于用户需求不清、需求经常变化的情况，是一种演化模型（Evolutionary Model）。当系统规模不是很大也不太复杂时，采用该方法比较好。

               原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。当然，能够采用原型方法是因为开发工具的快速发展，使得能够迅速地开发出一个让用户看得见、摸得着的系统框架。这样，对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求，开发初始原型，然后征求用户对初始原型的改进意见，并根据意见修改原型。原型模型如下图所示。

                

               原型模型

               原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制定原型开发的计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。被开发的原型应交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。

               根据使用原型的目的不同，原型可以分为探索型原型、实验型原型和演化型原型3种。探索型原型的目的是要弄清目标的要求，确定所希望的特性，并探讨多种方案的可行性。实验型原型的目的是验证方案或算法的合理性，是在大规模开发和实现前，用于考查方案是否合适、规格说明是否可靠等。演化型原型的目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。

               螺旋模型（Spiral Model）

               对于复杂的大型系统，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。螺旋模型是一种演化模型。

               螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，如下图所示。在每个螺旋周期分为如下4个工作步骤。

                

               螺旋模型

               （1）制订计划。确定系统的目标，选定实施方案，明确项目开发的限制条件。

               （2）风险分析。分析所选的方案，识别风险，消除风险。

               （3）实施工程。实施系统开发，验证阶段性产品。

               （4）用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。

               螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。因此特别适用于庞大、复杂并且具有高风险的系统。

               与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高产品的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了系统开发的风险。在使用螺旋模型进行系统开发时，需要开发人员具有相当丰富的风险评估经验和专门知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。

               喷泉模型（water fountain model）

               喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性，如下图所示。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它不像瀑布模型那样，需求分析活动结束后才开始设计活动，设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。

                

               喷泉模型

               喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行。其优点是可以提高项目开发效率，节省开发时间。由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大。

               形式化方法模型（Formal Methods Model）

               形式化方法是用于将复杂系统建模为数据实体的技术，是建立在严格数学基础上的一种开发方法，其主要活动是生成计算机软件形式化的数学规格说明。

               形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。

               统一过程（UP）模型

               统一过程的特色是“用例和风险驱动，以架构为中心，迭代的增量开发过程”。迭代的意思是将整个产品开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。

               统一过程定义了5个阶段及其制品。

               （1）起始阶段（inception phase）。起始阶段专注于项目的初创活动，产生的主要工作产品有构想文档（vision document）、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划（阶段及迭代）、业务模型以及一个或多个原型（需要时）。本阶段的里程碑是生命周期目标。

               （2）精化阶段（elaboration phase）。精化阶段在理解了最初的领域范围之后进行需求分析和架构演进，产生的主要工作产品有用例模型、补充需求（包括非功能需求）、分析模型、体系结构描述、可执行的体系结构原型、初步的设计模型、修订的风险列表、项目计划（包括迭代计划、调整的工作流、里程碑和技术工作产品）以及初始用户手册。本阶段的里程碑是生命周期架构。

               （3）构建阶段（construction phase）。构建阶段关注系统的构建，产生实现模型，产生的主要工作产品有设计模型、系统构件、集成的增量、测试计划及步骤、测试用例以及支持文档（用户手册、安装手册和对于并发增量的描述）。初始运作功能。

               （4）移交阶段（transition phase）。移交阶段关注于系统提交方面的工作，产生系统增量，产生的主要工作产品有提交的系统增量、β测试报告和综合用户反馈。本阶段的里程碑是产品发布版本。

               （5）生产阶段（production phase）。生产阶段对持续使用的软件进行监控，提供运行环境（基础设施）的支持，提交并评估缺陷报告和变更请求。

               在每个迭代中，有5个核心工作流：捕获系统应该做什么的需求工作流，精化和结构化需求的分析工作流，用系统构架实现需求的设计工作流，构造系统的实现工作流，验证实现是否如期望那样工作的测试工作流。

               统一过程的典型代表是RUP（Rational Unified Process），主要针对前4个技术阶段。RUP是UP的商业扩展，完全兼容UP，但比UP更完整、更详细。

               敏捷方法（Agile Development）

               敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在产品开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。

               敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念（敏捷宣言）。

               （1）极限编程（XP）。XP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。

               .4大价值观：沟通、简单性、反馈和勇气。

               .5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。

               .12个最佳实践：计划游戏（快速制订计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后再编写程序）、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本）、每周工作40个小时、现场客户和编码标准。

               （2）水晶法（Crystal）。水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论。

               （3）并列争球法（Scrum）。并列争球法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。。

               （4）自适应软件开发（ASD）。ASD有6个基本的原则：有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的，因此“重做”与“做”同样关键；变化不被视为改正，而是被视为对软件开发实际情况的调整；确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险也包含其中。

 

能力成熟度模型

        能力成熟度模型（简称CMM）是对一个组织机构的能力进行成熟度评估的模型。成熟度级别一般分成五级：1级-非正式执行、2级-计划跟踪、3级-充分定义、4级-量化控制、5级-持续优化。其中，级别越大，表示能力成熟度越高，各级别定义如下：

        . 1级-非正式执行：具备随机、无序、被动的过程；

        . 2级-计划跟踪：具备主动、非体系化的过程；

        . 3级-充分定义：具备正式的、规范的过程；

        . 4级-量化控制：具备可量化的过程；

        . 5级-持续优化：具备可持续优化的过程。

        目前，网络安全方面的成熟度模型主要有SSE-CMM、数据安全能力成熟度模型、软件安全能力成熟度模型等。

               SSE-CMM

               SSE-CMM（Systems Security Engineering Capability Maturity Model）是系统安全工程能力成熟度模型。SSE-CMM包括工程过程类（Engineering）、组织过程类（Organization）、项目过程类（Project）。各过程类包括的过程内容如下表所示。

                

               SSE-CMM系统安全工程能力成熟度模型过程清单

               SSE-CMM的工程过程、风险过程、保证过程的相互关系如下图所示。

                

               SSE-CMM的工程过程、风险过程、保证过程关联图

               SSE-CMM的工程过程关系如下图所示。

                

               SSE-CMM的工程过程关联图

               SSE-CMM的工程质量来自保证过程，如下图所示。

                

               SSE-CMM的保证过程图

               数据安全能力成熟度模型

               根据《信息安全技术数据安全能力成熟度模型》，数据安全能力成熟度模型架构如下图所示。

                

               数据安全能力成熟度模型架构

               数据安全能力从组织建设、制度流程、技术工具及人员能力四个维度评估：

               .组织建设——数据安全组织机构的架构建立、职责分配和沟通协作；

               .制度流程——组织机构关键数据安全领域的制度规范和流程落地建设；

               .技术工具——通过技术手段和产品工具固化安全要求或自动化实现安全工作；

               .人员能力——执行数据安全工作的人员的意识及专业能力。

               详细情况参考标准。

               软件安全能力成熟度模型

               软件安全能力成熟度模型分成五级，各级别的主要过程如下：

               . CMM1级——补丁修补；

               . CMM2级——渗透测试、安全代码评审；

               . CMM3级——漏洞评估、代码分析、安全编码标准；

               . CMM4级——软件安全风险识别、SDLC实施不同安全检查点；

               . CMM5级——改进软件安全风险覆盖率、评估安全差距。