【定义类】软件测试基础一

测试目的

       系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。

       测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。应根据开发各阶段的需求、设计等文档或程序的内部结构精心设计测试实例，并利用这些实例来运行程序，以便发现错误的过程。

软件测试的目的

        软件测试的目的是尽可能多地发现软件产品（主要是指程序）中的错误和缺陷。成功的测试是发现了至今未发现的错误的测试。

软件测试目的

       早期的软件定义指出软件测试的目的是寻找错误，并且尽最大的可能找出最多的错误。

       Grenford J. Myers就软件测试目的提出了以下观点。

       . 测试是程序的执行过程，目的在于发现错误；

       . 一个好的测试用例在于能发现至今未发现的错误；

       . 一个成功的测试是发现了至今未发现的错误的测试。

       Bill Hetzel提出了测试目的不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量。

       测试的目的，是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

       同时，测试是以评价一个程序或者系统属性为目标的活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求的程度，为用户选择与接受软件提供有力的依据。

       此外，通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。同时，通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。

       当然，通过最终的验收测试，也可以证明软件满足了用户的需求，树立人们使用软件的信心。

 

软件测试原则

       基于测试是为了寻找软件的错误与缺陷，评估与提高软件质量，我们提出这样的一组测试原则，如下所示。

       . 所有的软件测试都应追溯到用户需求。

       这是因为软件的目的是使用户完成预定的任务，并满足用户的需求，而软件测试所揭示的缺陷和错误使软件达不到用户的目标，满足不了用户需求。

       . 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。

       由于软件的复杂性和抽象性，在软件生命周期各个阶段都可能产生错误，所以不应把软件测试仅仅看作是软件开发的一个独立阶段的工作，而应当把它贯穿到软件开发的各个阶段中。在软件开发的需求分析和设计阶段就应开始测试工作，编写相应的测试文档。同时，坚持在软件开发的各个阶段进行技术评审与验证，这样才能在开发过程中尽早发现和预防错误，杜绝某些缺陷和隐患，提高软件质量。只要测试在生命周期中进行得足够早，就能够提高被测软件的质量，这就是预防性测试的基本原则。

       . 完全测试是不可能的，测试需要终止。

       想要进行完全的测试，在有限的时间和资源条件下，找出所有的软件缺陷和错误，使软件趋于完美，是不可能的。主要有三个原因：

       ①输入量太大；

        ②输出结果太多；

       ③路径组合太多。

       一个适度规模的程序，其路径组合近似天文数字，对于每一种可能的路径都执行一次的穷举测试是不可能的。此外，测试也是有成本的，越是测试后期，为发现错误所付出的代价就会越大，因此也要根据测试错误的概率以及软件可靠性要求，确定最佳停止测试时间，我们不能无限地测试下去。

       . 测试无法显示软件潜在的缺陷。

       进行测试是可以查找并报告发现的软件缺陷和错误，但不能保证软件的缺陷和错误全部找到，继续进一步测试可能还会找到一些，也就是说测试只能证明软件存在错误而不能证明软件没有错误。

       . 充分注意测试中的群集现象。

       经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。在所测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集性现象，已为许多程序的测试实践所证实。例如，在美国IBM公司的OS/370操作系统中，47%的错误仅与该系统的4%的程序模块有关。这种现象对测试很有用。如果发现某一程序模块似乎比其他程序模块有更多的错误倾向，则应当花费较多的时间和代价测试这个程序模块。

       . 程序员应避免检查自己的程序。

       基于心理因素，人们认为揭露自己程序中的问题总不是一件愉快的事，不愿否认自己的工作；由于思维定势，人们难于发现自己的错误。因此，为达到测试目的，应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试。

       . 尽量避免测试的随意性。

      应该从工程的角度去理解软件测试，它是有组织、有计划、有步骤的活动。

 

测试原则

       系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计和实施的最后复查。根据测试的概念和目的，在进行信息系统测试时应遵循以下基本原则。

       （1）应尽早并不断地进行测试。测试不是在应用系统开发完之后才进行的。由于原始问题的复杂性、开发各阶段的多样性以及参加人员之间的协调等因素，使得在开发的各个阶段都有可能出现错误。因此，测试应贯穿在开发的各个阶段，应尽早纠正错误，消除隐患。

       （2）测试工作应该避免由原开发软件的人或小组承担，一方面，开发人员往往不愿否认自己的工作，总认为自己开发的软件没有错误；另一方面，开发人员的错误很难由本人测试出来，很容易根据自己编程的思路来制定测试思路，具有局限性。测试工作应由专门人员来进行，这样会更客观、更有效。

       （3）在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果。将实际输出结果与预期结果相比较就能发现测试对象是否正确。

       （4）在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件。在测试的时候，人们往往习惯按照合理的、正常的情况进行测试，而忽略了对异常、不合理、意想不到的情况进行测试，而这可能就是隐患。

       （5）在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。多余的工作会带来副作用，影响程序的效率，有时会带来潜在的危害或错误。

       （6）严格按照测试计划来进行，避免测试的随意性。测试计划应包括测试内容、进度安排、人员安排、测试环境、测试工具和测试资料等。严格地按照测试计划可以保证进度，使各方面都得以协调进行。

       （7）妥善保存测试计划、测试用例，作为软件文档的组成部分，为维护提供方便。

       （8）测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便。当纠正错误、系统功能扩充后，都需要重新开始测试，而这些工作的重复性很高，可以利用以前的测试用例，或在其基础上修改，然后进行测试。

 

 

测试类型

        按照测试内容划分，测试类型一般有逻辑测试、功能测试、性能测试、接口测试、人机交互界面测试、强度测试、余量测试、安全性测试、恢复性测试、边界测试、数据处理测试、安装性测试、容量测试等。

        （1）逻辑测试。逻辑测试是测试程序逻辑结构的合理性、实现的正确性。逻辑测试由测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。逻辑测试根据不同的软件级别一般需进行语句覆盖、分支覆盖、条件覆盖、条件组合覆盖、路径覆盖、MC/DC覆盖等。

        （2）功能测试。功能测试是对软件需求规格说明或设计文档中的功能需求逐项进行的测试，以验证其功能是否满足要求。功能测试一般需进行：用正常值的等价类输入数据值测试；用非正常值的等价类输入数据值测试；进行每个功能的合法边界值和非法边界值输入的测试；用一系列真实的数据类型和数据值运行，测试超负荷、饱和及其他“最坏情况”的结果；在配置项测试时对配置项控制流程的正确性、合理性等进行验证。

        （3）性能测试。性能测试是对软件需求规格说明或设计文档中的性能需求逐项进行的测试，以验证其性能是否满足要求。性能测试一般需进行：测试在获得定量结果时程序计算的精确性（处理精度）；测试其时间特性和实际完成功能的时间（响应时间）；测试为完成功能所处理的数据量；测试程序运行所占用的空间；测试其负荷潜力；测试配置项各部分的协调性；在系统测试时测试软件性能和硬件性能的集成；在系统测试时测试系统对并发事物和并发用户访问的处理能力。

        （4）接口测试。接口测试是对软件需求规格说明或设计文档中的接口需求逐项进行的测试。接口测试一般需进行：测试所有外部接口，检查接口信息的格式及内容；对每一个外部输入／输出接口必须做正常和异常情况的测试；测试硬件提供的接口是否便于使用；测试系统特性（如数据特性、错误特性、速度特性）对软件功能、性能特性的影响；对所有的内部接口的功能、性能进行测试。

        （5）人机交互界面测试。人机交互界面测试是对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的要求。人机交互界面测试一般需进行：测试操作和显示界面及界面风格与软件需求规格说明中要求的一致性和符合性；以非常规操作、误操作、快速操作来检验人机界面的健壮性；测试对错误命令或非法数据输入的检测能力与提示情况；测试对错误操作流程的检测与提示；对照用户手册或操作手册逐条进行操作和观察。

        （6）强度测试。强度测试是强制软件运行在不正常到发生故障的情况下（设计的极限状态到超出极限），检验软件可以运行到何种程度的测试。强度测试一般需：提供最大处理的信息量；提供数据能力的饱和实验指标；提供最大存储范围（如常驻内存、缓冲、表格区、临时信息区）；在能力降级时进行测试；在人为错误（如寄存器数据跳变、错误的接口）状态下进行软件反应的测试；通过启动软件过载安全装置（如临界点警报、过载溢出功能、停止输入、取消低速设备等）生成必要条件，进行计算过载的饱和测试；需进行持续一段规定的时间，而且连续不能中断的测试。

        （7）余量测试。余量测试是对软件是否达到需求规格说明中要求的余量的测试。若无明确要求时，一般至少留有20%的余量。根据测试要求，余量测试一般需提供：全部存储量的余量；输入／输出及通道的吞吐能力余量；功能处理时间的余量。

        （8）安全性测试。安全性测试是检验软件中已存在的安全性、安全保密性措施是否有效的测试。测试应尽可能在符合实际使用的条件下进行。安全性测试一般需进行：对安全性关键的软件部件，必须单独测试安全性需求；在测试中全面检验防止危险状态措施的有效性和每个危险状态下的反应；对设计中用于提高安全性的结构、算法、容错、冗余及中断处理等方案，必须进行针对性测试；对软件处于标准配置下其处理和保护能力的测试；应进行对异常条件下系统／软件的处理和保护能力的测试（以表明不会因为可能的单个或多个输入错误而导致不安全状态）；对输入故障模式的测试；必须包含边界、界外及边界结合部的测试；对“0”、穿越“0”以及从两个方向趋近“0”的输入值的测试；必须包括在最坏情况配置下的最小输入和最大输入数据率的测试；对安全性关键的操作错误的测试；对具有防止非法进入软件并保护软件的数据完整性能力的测试；对双工切换、多机替换的正确性和连续性的测试；对重要数据的抗非法访问能力的测试。

        （9）恢复性测试。恢复性测试是对有恢复或重置功能的软件的每一类导致恢复或重置的情况逐一进行的测试，以验证其恢复或重置功能。恢复性测试是要证实在克服硬件故障后，系统能否正常地继续进行工作，且不对系统造成任何损害。恢复性测试一般需进行：探测错误功能的测试；能否切换或自动启动备用硬件的测试；在故障发生时能否保护正在运行的作业和系统状态的测试；在系统恢复后，能否从最后记录下来的无错误状态开始继续执行作业的测试。

        （10）边界测试。边界测试是对软件处在边界或端点情况下运行状态的测试。边界测试一般需进行：软件的输入域或输出域的边界或端点的测试；状态转换的边界或端点的测试；功能界限的边界或端点的测试；性能界限的边界或端点的测试；容量界限的边界或端点的测试。

        （11）数据处理测试。数据处理测试是对完成专门数据处理功能所进行的测试。数据处理测试一般需进行：数据采集功能的测试；数据融合功能的测试；数据转换功能的测试；剔除坏数据功能的测试；数据解释功能的测试。

        （12）安装性测试。安装性测试是对安装过程是否符合安装规程的测试，以发现安装过程中的错误。安装性测试一般需进行：不同配置下的安装和卸载测试；安装规程的正确性测试。

        （13）容量测试。容量测试是检验软件的能力最高能达到什么程度的测试。容量测试一般应测试到在正常情况下软件所具备的最高能力，如：响应时间或并发处理个数等能力。

        根据软件开发阶段和测试对象，一般可分为单元测试、部件测试（也称为集成测试或组装测试）、配置项测试和系统测试。

               单元测试

               单元测试的对象是软件单元。软件单元测试的目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求，发现单元内可能存在的各种错误。一般由软件的供方组织并实施软件单元测试，也可委托第三方进行软件单元测试。软件单元测试可根据软件单元的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。单元测试一般应符合以下的技术要求：

               （1）在对软件单元进行动态测试之前，应对软件单元的源代码进行静态测试。

               （2）应建立测试软件单元的环境，如桩模块和驱动模块，其测试环境应通过评审。

               （3）对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试。

               （4）软件单元的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖。

               （5）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。

               （6）语句覆盖率要达到100%。

               （7）分支覆盖率要达到100%。

               （8）对输出数据及其格式进行测试。

               软件单元测试一般应采用静态测试方法和动态测试方法。通常静态测试先于动态测试。软件单元测试完成后形成的文档有：软件单元测试计划；软件单元测试说明；软件单元测试报告；软件单元测试记录；软件单元测试问题报告。

               部件测试

               部件测试的对象包括软件部件的组装过程和组装得到的软件部件，软件部件由软件单元组成。软件部件测试的目的是检验软件单元和软件部件之间的接口关系，并验证软件部件是否符合设计要求。软件部件测试一般由软件供方组织并实施，测试人员与开发人员应相对独立；也可委托第三方进行软件部件测试。软件部件测试可根据软件部件的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。部件测试一般应符合以下技术要求：

               （1）应对构成软件部件的每个软件单元的单元测试情况进行检查。

               （2）若对软件部件进行必要的静态测试，应先于动态测试。

               （3）组装过程是动态进行的，因此应标明组装策略。

               （4）应建立部件测试环境，如桩模块和驱动模块，其测试环境应通过评审。

               （5）应逐项测试软件设计文档规定的软件部件的功能、性能等特性。

               （6）软件部件的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖。

               （7）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。

               （8）应测试软件单元和软件部件之间的所有调用，达到要求的测试覆盖率。

               （9）应测试软件部件的输出数据及其格式。

               （10）应测试软件部件之间、软件部件和硬件之间的所有接口。

               （11）应测试运行条件（如数据结构、输入／输出通道容量、内存空间、调用频度等）在边界状态下，进而在人为设定的状态下，软件部件的功能和性能。

               （12）应按设计文档要求，对软件部件的功能、性能进行强度测试。

               （13）对安全性关键的软件部件，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。

               （14）发现是否有多余的软件单元。

               软件部件测试一般应采用静态测试方法和动态测试方法。静态测试方法常采用静态分析、代码审查等方法，动态测试方法常采用白盒测试方法和黑盒测试方法。通常，静态测试先于动态测试。

               在由软件单元和软件部件组装成新的软件部件时，应根据软件单元和软件部件的特点选择便于测试的组装策略。按测试过程中，组合软件单元的方式，有两种不同的组装策略，即一次性组装策略和增值式组装策略。

               一次性组装策略是一种非增值集成方式，首先完成全部软件单元测试，然后再把所有的软件单元集成在一起进行测试，最终得到要求的软件系统。一次性组装策略的优点是工作量相对较小，缺点是定位错误比较困难。

               增值式组装策略也称为递增集成法，即依次将软件单元增加到已测试完成的软件部件中，将已测试的软件部件组装为更大的软件部件，在组装的过程中边增加边测试，以便发现组装过程中的问题。最后增值逐步组装为要求的软件系统。根据组装的过程又可分为自顶向下组装、自底向上组装、“三明治”组装、定向冒险组装、功能定向组装等策略。

               软件部件测试完成后形成的文档包括：软件部件测试计划；软件部件测试说明；软件部件测试报告；软件部件测试记录；软件部件测试问题报告。

               配置项测试

               配置项测试的对象是计算机软件配置项（CSCI，以下简称配置项），软件配置项是为独立的配置管理而设计的并且能满足最终用户功能的一组软件。软件配置项测试的目的是检验软件配置项与软件需求规格说明的致一性。配置项测试可根据软件配置项的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。配置项测试一般应符合以下技术要求：

               （1）必要时，在高层控制流图中作结构覆盖测试。

               （2）应逐项测试软件需求规格说明规定的配置项的功能、性能等特性。

               （3）配置项的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。

               （4）测试用例的输入应至少包括有效等价类值、无效等价值和边界数据值。

               （5）应测试配置项的输出及其格式。

               （6）应测试人机交互界面提供的操作和显示界面，包括用非常规操作、误操作、快速操作测试界面的可靠性。

               （7）应测试运行条件在边界状态和异常状态下，或在人为设定的状态下，配置项的功能和性能。

               （8）应按软件需求规格说明的要求，测试配置项的安全性和数据的安全保密性。

               （9）应测试配置项的所有外部输入、输出接口（包括和硬件之间的接口）。

               （10）应测试配置项的全部存储量、输入／输出通道的吞吐能力和处理时间的余量。

               （11）应按软件需求规格说明的要求，对配置项的功能、性能进行强度测试。

               （12）应测试设计中用于提高配置项的安全性和可靠性的方案，如结构、算法、容错、冗余、中断处理等。

               （13）对安全性关键的配置项，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。

               （14）对有恢复或重置功能需求的配置项，应测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试。

               （15）对不同的实际问题应外加相应的专门测试。

               应保证软件配置项测试工作的独立性。软件配置项测试一般由软件的供方组织，由独立于软件开发的组织实施。软件配置项测试一般应采用黑盒测试方法。

               软件配置项测试完成后形成的文档有：软件配置项测试计划；软件配置项测试说明；软件配置项测试报告；软件配置项测试记录；软件配置项测试问题报告。

               系统测试

               系统测试的对象是完整的、集成的计算机系统（CS），重点是新开发的配置项的集合。系统测试的目的是在真实系统工作环境下检验完整的软件配置项能否和系统正确连接，并满足系统／子系统设计文档和软件开发任务书规定的要求。可根据软件系统的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。系统测试一般应符合以下技术要求：

               （1）应按系统／子系统设计说明的规定，逐项测试系统的功能、性能等特性。

               （2）系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。

               （3）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。

               （4）应测试系统的输出及其格式。

               （5）应测试配置项之间及配置项与硬件之间的所有接口。

               （6）应在边界状态、异常状态或在人为设定的状态的运行条件下，测试系统的功能和性能。

               （7）应测试系统的安全性和数据访问的安全保密性。

               （8）应测试系统的全部存储量、输入／输出通道的吞吐能力和处理时间的余量。

               （9）应按系统或子系统设计文档的要求，对系统的功能、性能进行强度测试。

               （10）应测试人机交互界面提供的操作和显示界面，包括用非常规操作、误操作、快速操作测试界面的可靠性。

               （11）应测试设计中用于提高系统安全性和可靠性的方案，如结构、算法、容错、冗余、中断处理等。

               （12）对安全性关键的系统，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。

               （13）对有恢复或重置功能需求的系统，应测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试。

               （14）对软件系统的安装性进行测试。

               （15）对不同的实际问题应外加相应的专项测试。

               系统测试一般由软件的需方组织，由独立于软件开发的组织实施。系统测试一般应采用黑盒测试方法。

               系统测试完成后形成的文档包括：系统测试计划；系统测试说明；系统测试报告；系统测试记录；系统测试问题报告。

               可根据需要对上述文档及文档的内容进行裁剪。

 

 

软件测试过程

       开发过程的质量决定了软件的质量，同样地，测试过程的质量决定了软件测试的质量和有效性。软件测试过程的管理是保证测试过程质量、控制测试风险的重要活动。软件测试和软件开发一样，都遵循软件工程的原理，有它自己的生命周期。软件的测试过程一般分成测试计划、测试设计与开发、测试实施、测试评审与测试结论等阶段。对每个阶段的任务、输入和输出都有明确的规定，以便对整个测试过程进行质量控制和配置管理。

       软件测试过程是一种抽象的、遵循GB/T 18905（ISO 14598.5）《评价者用的过程（Process for Evaluator）》中定义软件评价过程的模型，是国际上共同遵守的软件评测过程标准，是软件测试过程管理的精髓。标准定义了分析各类软件产品的评测需求，规定、设计、实施、评审以及对评测做出结论所需的各种活动。本章介绍的主要内容，可作为软件测试过程工作内容与管理的基本原则。为符合GB/T 18905基本原理，仍保留“评价过程”的标准用语。

 

测试过程

        软件测试过程一般包括：测试需求分析、测试策划、测试设计和实现、测试执行、测试总结（包括评价过程和总结），如下图所示。

         

        软件测试过程

               测试需求分析

               根据被测软件的需求规格说明或设计文档，进行测试需求分析，包括：

               （1）确定需要的测试类型及其测试要求并进行标识（编号），标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试级别（单元测试、部件测试、配置项测试、系统测试）、测试类型相匹配。

               （2）确定每个测试项的优先级。

               （3）确定每个测试项的测试充分性要求。

               （4）根据被测软件的重要性、测试目标和约束条件，确定每个测试项应覆盖的范围及范围所要求的覆盖程度。

               （5）确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。

               （6）确定测试项与软件需求规格说明或设计文档的追踪关系。

               将测试需求分析结果按所确定的文档要求，形成测试需求规格说明或写入测试计划。

               应对测试需求规格说明或测试需求分析结果进行评审，评审内容如下：

               （1）测试级别和测试对象所确定的测试类型及其测试要求是否恰当。

               （2）每个测试项是否进行了标识，并逐条覆盖了测试需求和潜在需求。

               （3）测试类型和测试项是否充分。

               （4）测试项是否包括了终止要求。

               （5）文档是否符合规定的要求。

               测试策划

               根据软件需求规格说明或设计文档等进行测试策划，策划一般包括：

               （1）确定测试策略，如部件或配置项测试策略。

               （2）确定测试需要的技术或方法，如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术。

               （3）确定要受控制的测试工作产品，列出清单。

               （4）确定用于测试的资源要求，包括软硬件设备、环境条件、人员数量和技能等要求。

               （5）进行测试风险分析，如技术风险、人员风险、资源风险和进度风险等。

               （6）确定测试任务的结束条件。

               （7）确定被测软件的评价准则和方法。

               （8）确定测试活动的进度。应根据测试资源和测试项，确定进度。

               应将测试策划结果，按所确定的文档要求形成测试计划。

               测试设计和实现

               应根据测试需求规格说明和测试计划进行测试设计和实现，应完成如下工作：

               （1）按需要分解测试项。将需要测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有接口和要测试的接口。

               （2）说明最终分解后的测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等。

               （3）设计测试用例。

               （4）确定测试用例的执行顺序。

               （5）准备和验证所有的测试用数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等。

               （6）准备并获取测试资源，如测试环境所必须的软、硬件资源等。

               （7）必要时，编写测试执行需要的程序，如开发部件测试的驱动模块和桩模块以及测试支持软件等。

               （8）建立和校核测试环境，记录校核结果，说明测试环境的偏差。

               应将测试设计与实现的工作结果，按照所确定的文档要求编写测试说明，测试说明一般应包括：

               （1）测试名称和项目标识。

               （2）测试用例的追踪。说明测试所依据的内容来源，并跟踪到相应的测试项的标识（编号）。

               （3）测试用例说明。简要描述测试的对象、目的和所采用的测试方法。

               （4）测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置）等的初始化要求。

               （5）测试用例的输入。每个测试用例输入的描述中应包括的内容：

               ①每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）。

               ②测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）。

               ③测试输入是真实的还是模拟的。

               ④测试输入的时间顺序或事件顺序。

               （6）测试用例的期望测试结果。期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不确切的概念或笼统的描述。必要时，应提供中间的期望结果。

               （7）测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息，如：

               ①实际测试结果所需的精确度。

               ②允许的实际测试结果与期望结果之间差异的上、下限。

               ③时间的最大或最小间隔。

               ④事件数目的最大或最小值。

               ⑤实际测试结果不确定时，重新测试的条件。

               ⑥与产生测试结果有关的出错处理。

               ⑦其他有关准则。

               （8）实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括：

               ①每一步所需的测试操作动作、测试程序输入或设备操作等。

               ②每一步期望的测试结果。

               ③每一步的评估准则。

               ④导致被测程序执行终止伴随的动作或指示信息。

               ⑤需要时，获取和分析中间结果的方法。

               （9）测试用例的前提和约束。在测试用例中还应说明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响。

               （10）测试终止条件。说明测试用例的测试正常终止和异常终止的条件。

               （11）确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。

               （12）测试说明应经过评审，得到相关人员的认同，测试说明评审内容如下：

               ①测试说明是否完整、正确和规范。

               ②测试设计是否完整和合理。

               ③测试用例是否可行和充分。

               测试执行

               应按照测试计划和测试说明的内容和要求执行测试，主要完成下列工作：

               如实填写测试记录，当结果有量值要求时，应准确记录实际的量值。

               （1）测试记录应受到严格管理，并规范格式，至少包括测试用例标识、测试结果和发现的缺陷。

               （2）应根据每个测试用例的期望测试结果、实际测试结果和评估准则，判定测试用例是否通过。

               （3）当测试用例不通过时，应根据不同的缺陷类型，采取相应的措施：

               ①对测试工作中的缺陷，如测试说明的缺陷、测试数据的缺陷、执行测试步骤时的缺陷、测试环境中的缺陷等，记录到相应的表格中，并实施相应的变更。

               ②对被测软件的缺陷应记录到软件问题报告中。

               ③软件问题报告的格式应规范。

               （4）当所有的测试用例都执行完毕后，实验室应根据测试的充分性要求和有关记录，分析测试工作是否充分，是否需要进行补充测试：

               ①当测试过程正常终止时，如果发现测试工作不足，或测试未达到预期要求时，应进行补充测试。

               ②当测试过程异常终止时，应记录导致终止的条件、未完成的测试或未被修正的错误。

               测试总结

               应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录、测试问题及变更报告和软件问题报告等，对测试工作和被测软件进行分析和评价，主要完成下列工作：

               （1）对测试工作进行分析和评价，分析和评价内容应包括：

               ①总结测试需求规格说明、测试计划和测试说明的变化情况及其原因。

               ②在测试异常终止时，说明未能被测试活动充分覆盖的范围及其理由。

               ③确定无法解决的软件测试事件并说明不能解决的理由。

               （2）对被测软件进行分析和评价，分析和评价内容应包括：

               ①总结测试中所反映的被测软件与软件需求（或软件设计）之间的差异。

               ②可能时，根据差异评价被测软件的设计与实现，提出改进的建议。

               ③当进行配置项测试或系统测试时，当需要时，测试总结中应对配置项或系统的性能做出评估，指明偏差、缺陷和约束条件等对于配置项或系统运行的影响。

               （3）分析测评项目中的数据和文档，以供以后的测试使用。数据如：缺陷数据（包括缺陷描述、类型、严重性等）、用例数据、管理数据（如生产率、工作量、进度等）；文档如：好的用例设计、好的需求规格说明等。

               （4）应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录和软件问题报告等有关文档，对测试结果和问题进行分类和总结，按所确定的文档要求编写测试报告。测试报告除了应包括对测试结果的分析，还应包括对被测软件的评价和建议。

               测试总结评审应在测试报告编制工作完成后进行，以确定是否达到测试目的，给出评审结论。评审的具体内容和要求包括：

               （1）审查测试文档与记录内容的完整性、正确性和规范性。

               （2）审查测试活动的独立性和有效性。

               （3）审查测试环境是否符合测试要求。

               （4）审查软件测试报告与软件测试原始记录和问题报告的一致性。

               （5）审查实际测试过程与测试计划和测试说明的一致性。

               （6）审查测试说明评审的有效性，如是否评审了测试项选择的完整性和合理性、测试用例的可行性和充分性。

               （7）审查测试结果的真实性和正确性。

 

软件测试对象

        根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。软件测试应贯穿于整个软件生命周期中。在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，这就称为“确认测试”。将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。

        由于软件分析、设计与开发各阶段是互相衔接的，前一阶段工作中发生的问题如未及时解决，很自然要影响到下一阶段。从源程序的测试中找到的程序错误不一定都是在程序编写过程中产生的。如果简单地把程序中的错误全都归罪于程序员，未免冤枉了他们。据美国一家公司的统计表明，在查找出的软件错误中，属于需求分析和软件设计的错误约占64%，属于程序编写的错误仅占36%。这都说明，对程序编写而言，它的许多错误是“先天的”。事实上，到程序的测试为止，软件开发工作已经经历了许多环节，每个环节都可能发生问题。

        为了把握各个环节的正确性，人们需要进行各种验证和确认（verification&validation）工作。

        验证（verification）是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。

        确认（validation）是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。

        验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。

 

测试计划

        制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程，包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中，制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于：

        ①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序，并检测系统的性能、可靠性和容量等。

        ②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前，应了解哪些资源可用并确定如何有效地使用这些资源。

        ③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标（如检测重负载情况下的服务器响应时间）是不够的。明确的成功条件应类似于“50个客户能够同时查看他们的账户余额，并且服务器响应时间不超过1分钟”。

        下面详细论述负载压力测试计划过程的4个步骤。

               分析应用程序

               负载测试计划的第一步是分析应用程序。应该对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。应用程序分析可以确保使用的测试环境能够在测试中精确地反映应用程序的环境和配置。

                      确定系统组件

                      绘制一份应用程序结构示意图。如果可能，从现有文档中提取一份示意图。如果要测试的应用程序是一个较大的网络系统的一部分，应该确定要测试的系统组件。确保该示意图包括了所有的系统组件，例如客户机、网络、中间件和服务器等。

                      如下图所示说明了一个由许多Web用户访问的联机银行系统。各Web用户连接到同一数据库以转移现金和支票余额。客户使用不同的浏览器，通过Web方式连接到数据库服务器。

                      

                      联机银行系统应用布署

                      描述系统配置

                      增加更多详细信息以完善示意图。描述各系统组件的配置。应当掌握以下信息：

                      . 连接到系统的用户数；

                      . 应用程序客户端计算机的配置情况（硬件、内存、操作系统、软件、开发工具等）；

                      . 使用的数据库和Web服务器的类型（硬件、数据库类型、操作系统、文件服务器等）；

                      . 服务器与应用程序客户端之间的通信方式；

                      . 前端客户端与后端服务器之间的中间件配置和应用程序服务器；

                      . 可能影响响应时间的其他网络组件（调制解调器等）；

                      . 通信设备的吞吐量以及每个设备可以处理的并发用户数。

                      例如，在如上图所示的示意图中，多个应用程序客户端在访问系统。客户端的配置如下表所示。

                      

                      客户端配置内容

                      分析使用模型

                      定义系统的典型使用方式，并确定需要重点测试的功能。考虑哪些用户使用系统、每种类型用户的数量，以及每个用户的典型任务。此外，还应考虑任何可能影响系统响应时间的后台负载。

                      例如，假设每天上午有200名员工登录记账系统，并且该办公室网络有固定的后台负载：50名用户执行各种字处理和打印任务。可以创建一个200个虚拟用户登录访问记账数据库的方案，并检测服务器的响应时间。要了解后台负载对响应时间的影响，可以在运行方案的网络中再模拟员工执行字处理和打印活动的负载。

                      任务分布

                      除定义常规用户任务外，还应该查看这些任务的分布情况。例如，假设银行用户使用一个中央数据库为跨越多个州和时区的客户提供服务。250个应用程序客户端分布在两个不同的时区，全都连接到同一个Web服务器中。其中150个在芝加哥，另外100个在底特律。每个客户端从上午9点开始工作，但由于处于不同的时区，因此在任何特定时间内都不会有超过150个的用户同时登录。可以分析任务分布，以确定数据库活动峰值期的发生时间，以及负载峰值期间的典型活动。

               定义测试目标

               开始测试之前，应精确地定义想要实现的目标。

                      以可度量的指标制定目标

                      确定了负载测试的一般性目标后，应该以可度量指标制定更具针对性的目标。为了提供评估基准，应精确地确定、区分可接受和不可接受测试结果的标准。

                      例如：

                      . 一般性目标产品评估：选择Web服务器的硬件。

                      . 明确目标产品评估：在一台HP服务器和一台NEC服务器上运行同一个包含300个虚拟用户的组。当300个用户同时浏览Web应用程序页面时，确定哪一种硬件提供更短的响应时间。

                      . 测试目标

                      ①度量最终用户的响应时间，完成一个业务流程需要多长时间；

                      ②定义最优的硬件配置，哪一种硬件配置可以提供最佳性能；

                      ③检查可靠性，系统无错误或无故障运行的时间长度或难度；

                      ④查看硬件或软件升级对性能或可靠性有何影响；

                      ⑤评估新产品，应选择哪些服务器硬件或软件；

                      ⑥度量系统容量，在没有显著性能下降的前提下，系统能够处理多大的负载；

                      ⑦确定瓶颈，哪些因素会延长响应时间。

                      确定测试的时间

                      负载测试应贯穿于产品的整个生命周期。如下表说明了在产品生命周期的各个阶段有哪些类型的测试与之相关。

                       

                      产品生命周期与测试类型

               计划方案实施

               下一步是确定如何实现测试目标。

                      定义性能度量的范围

                      可以度量应用程序中不同点的响应时间。根据测试目标确定在哪里运行Vuser（虚拟用户）以及运行哪些Vuser。

                      . 度量端到端的响应时间。

                      可以在前端运行GUI Vuser（图形用户界面用户）或RTE Vuser（终端用户）来度量典型用户的响应时间。GUI Vuser可以将输入提交给客户端应用程序并从该应用程序接收输出，以模拟实际用户；RTE Vuser则向基于字符的应用程序提交输入，并从该应用程序接收输出，以模拟实际用户。

                      可以在前端运行GUI或RTE Vuser来度量跨越整个网络（包括终端仿真器或GUI前端、网络和服务器）的响应时间。如下图所示为端到端的响应时间。

                        

                      端到端的响应时间

                      . 度量网络和服务器响应时间。

                      可以通过在客户机运行Vuser（非GUI或RTE Vuser）来度量网络和服务器的响应时间（不包括GUI前端的响应时间）。Vuser模拟客户端对服务器的进程调用，但不包括用户界面部分。在客户机运行大量Vuser时，可以度量负载对网络和服务器响应时间的影响。如下图所示为网络和服务器的响应时间。

                        

                      网络和服务器的响应时间

                      . 度量GUI响应时间。

                      可以通过减去前两个度量值，来确定客户端应用程序界面对响应时间的影响。GUI响应时间=端到端响应时间-网络和服务器响应时间。如下图所示为GUI响应时间。

                        

                      GUI响应时间

                      . 度量服务器响应时间。

                      可以度量服务器响应请求（不跨越整个网络）所花费的时间。通过在与服务器直接相连的计算机上运行Vuser，可以度量服务器性能。如下图所示为服务器响应时间。

                        

                      服务器响应时间

                      . 度量中间件到服务器的响应时间。

                      如果可以访问中间件及其API，便可以度量服务器到中间件的响应时间。可以使用中间件API创建Vuser，来度量中间件到服务器的性能。如下图所示为中间件到服务器响应时间。

                      定义Vuser活动

                      根据对Vuser类型的分析以及它们的典型任务和测试目标来创建Vuser脚本。由于Vuser模拟典型最终用户的操作，因此Vuser脚本应包括典型的最终用户任务。例如，要模拟联机银行客户端，应该创建一个执行典型银行任务的Vuser脚本。需要浏览经常访问的页面，以转移现金或支票余额。

                       

                      中间件到服务器响应时间

                      根据测试目标确定要衡量的任务，并定义这些任务的事务。这些事务度量服务器响应Vuser提交的任务所花费的时间（端到端时间）。例如，要查看提供账户余额查询的银行Web服务器的响应时间，则应在Vuser脚本中为该任务定义一个事务。

                      此外，可以通过在脚本中使用集合点来模拟峰值期活动。集合点指示多个Vuser在同一时刻执行任务。例如，可以定义一个集合点，以模拟70个用户同时更新账户信息的情况。

                      选择Vuser

                      确定用于测试的硬件配置之前，应该先确定需要的Vuser的数量和类型。要确定运行多少个Vuser和哪些类型的Vuser，请综合考虑测试目标来查看典型的使用模型。以下是一些一般性规则：

                      . 使用一个或几个GUI用户来模拟每一种类型的典型用户连接；

                      . 使用RTE Vuser来模拟终端用户；

                      . 运行多个非GUI或非RTE Vuser来生成每个用户类型的其余负载。

                      例如，假设有五种类型的用户，每种用户执行一个不同的业务流程，如下表所示。

                       

                      Vuser的数量和类型

                      选择测试硬件和软件

                      硬件和软件应该具有强大的性能和足够快的运行速度，以模拟所需数量的虚拟用户。

                      在确定计算机的数量和正确的配置时，请考虑以下事项。

                      . 建议在一台单独的计算机上运行测试工具主控台。

                      . 在一台Windows计算机只能运行一个GUI Vuser；而在一台UNIX计算机上则可以运行几个GUI Vuser。

                      . GUI Vuser测试计算机的配置应该尽量与实际用户的计算机配置相同。

                      关于每个测试组件的硬件要求，请参考下表一和下表二。要获得最佳性能，应满足表中所列要求。

                       

                      测试机硬件与软件要求（Windows配置要求）

                      注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。

                      有关最新的安装要求，请访问

                      http://www.mercuryinteractive.com/products/loadrunner/technical/

                       

                      测试机硬件与软件要求（UNIX配置要求）

                      注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。

               检查测试目标

               测试计划应该基于明确定义的测试目标。下面概述了常规的测试目标。

               ①度量最终用户响应时间。

               ②定义最优的硬件配置。

               ③检查可靠性。

               ④查看硬件或软件升级。

               ⑤评估新产品。

               ⑥确定瓶颈。

               ⑦度量系统容量。

                      度量最终用户响应时间

                      查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。如下图显示了一个银行应用程序的负载和响应时间度量之间的关系。

                       

                      负载和响应时间度量关系

                      定义最优的硬件配置

                      检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。

                      例如，可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异。

                      . 配置1：200MHz、64MB RAM。

                      . 配置2：200MHz、128MB RAM。

                      . 配置3：266MHz、128MB RAM。

                      检查可靠性

                      确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载：强制系统在短时间内处理大量任务，来模拟系统在数周或数月的时间内通常会遇到的活动类型。

                      查看硬件或软件升级

                      执行回归测试，以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。

                      评估新产品

                      可以运行测试，以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如，可以根据评估测试来选择服务器的硬件或数据库套件。

                      确定瓶颈

                      可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。使用负载压力测试工具，以及网络和计算机监视工具以生成负载，并度量系统中不同点的性能。如下图所示为系统不同点的性能。

                       

                      系统不同点的性能

                      度量系统容量

                      度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量，可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后，便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。

                       

                      响应时间与负载关系

 

测试执行

               运行场景

               运行场景时，会为Vuser组分配负载生成器并执行它们的Vuser脚本。在场景执行期间，将要完成以下工作：

               . 记录在Vuser脚本中定义的事务的持续时间；

               . 执行包括在Vuser脚本中的集合；

               . 收集Vuser生成的错误、警告和通知消息。

               可以在无人干预的情况下运行整个场景，或者可以交互地选择要运行的Vuser组和Vuser。场景开始运行时，Controller会首先检查场景配置信息。接着，它将调用已选定与该场景一起运行的应用程序。然后，它会将每个Vuser脚本分配给其指定的负载生成器。Vuser组就绪后，它们将开始执行其脚本。

               在场景运行时，可以监视每个Vuser，查看由Vuser生成的错误、警告和通知消息以及停止Vuser组和各个Vuser。可以允许单个Vuser或组中的Vuser在停止前完成它们正在运行的迭代，在停止前完成它们正在运行的操作或者立即停止运行，还可以在场景运行时激活其他Vuser。在下面情况下，场景将结束：所有Vuser已完成其脚本、持续时间用完或者终止场景。以下过程概述如何运行场景。

               . 打开现有场景或新建一个场景；

               . 配置并计划场景；

               . 设置结果目录；

               . 运行并监视场景。

               在执行期间查看Vuser

               可以在场景执行期间查看Vuser的活动：

               . 在Controller负载生成器计算机中，可以查看输出窗口，联机监视Vuser性能以及查看执行场景的Vuser的状态；.在远程计算机中，可以查看包含活动Vuser的有关信息的代理摘要。

               监视场景

               工具一般提供下列联机监视器：

               . “运行时”监视器显示参与场景的Vuser的数目和状态，以及Vuser所生成的错误数量和类型。此外还提供用户定义的数据点图，其中显示Vuser脚本中的用户定义点的实时值。

               . “事务”监视器显示场景执行期间的事务速率和响应时间。

               . “Web资源”监视器用于度量场景运行期间Web服务器上的统计信息。它提供关于场景运行期间的Web连接、吞吐量、HTTP响应、服务器重试和下载页的数据。

               . “系统资源”监视器测量场景运行期间使用的Windows、UNIX、TUXEDO、SNMP和Antara FlameThrower资源。要激活系统资源监视器，必须在运行场景之前设置监视器选项。

               . “网络延迟”监视器显示关于系统上的网络延迟的信息。要激活网络延迟监视器，必须在运行场景之前设置要监视的网络路径。

               . “防火墙”监视器用于度量场景运行期间防火墙服务器上的统计信息。要激活防火墙监视器，必须在运行场景之前设置要监视的资源列表。

               . “Web服务器资源”监视器用于度量场景运行期间Apache、Microsoft IIS、iPlanet（SNMP）和iPlanet/Netscape Web服务器上的统计信息。要激活该监视器，必须在运行场景之前设置要监视的资源列表。

               . “Web应用程序服务器资源”监视器用于度量场景运行期间Web应用程序服务器上的统计信息。要激活该监视器，必须在运行场景之前设置要监视的资源列表。

               . “数据库服务器资源”监视器用于度量与SQL Server、Oracle、Sybase和DB2数据库有关的统计信息。要激活该监视器，必须在运行场景之前设置要监视的度量列表。

               . “流媒体”监视器用于度量Windows Media服务器、RealPlayer音频/视频服务器及RealPlayer客户端上的统计信息。要激活该监视器，必须在运行场景之前设置要监视的资源列表。

               . “ERP/CRM服务器资源”监视器用于度量场景运行期间SAP R/3系统服务器、SAP Portal、Siebel Web服务器和Siebel Server Manager服务器的统计信息。要激活该监视器，必须在运行场景之前设置要监视的资源列表。

               . “Java性能”监视器用于度量Java 2 Platform, Enterprise Edition（J2EE）对象及使用J2EE和EJB服务器计算机的Enterprise Java Bean（EJB）对象的统计信息。要激活该监视器，必须在运行场景之前设置要监视的资源列表。

               . “应用程序部署解决场景”监视器用于度量场景运行期间Citrix MetaFrame XP和1.8服务器的统计信息。要激活该监视器，必须在运行场景之前设置监视器选项。

               . “中间件性能”监视器用于度量场景运行期间TUXEDO和IBM WebSphere MQ服务器上的统计信息。要激活该监视器，必须在运行场景之前设置要监视的资源列表。

               . 所有的监视器所收集的数据都可以生成该监视器的图。

               有些工具也提供远程性能监控。

               在负载测试运行过程中，远程性能监视器可以查看特定的图，这些图显示Vuser在服务器上生成的负载的信息。用户在连接到Web服务器的Web浏览器上查看负载测试数据。如下图所示为利用远程性能监视器查看负载测试数据。

                

               利用远程性能监视器查看负载测试数据

               远程性能监视器服务器包含一个用ASP页实现的网站，以及一个包含负载测试图的文件服务器。它与Controller联机组件进行交互，并按相应的许可证处理同时查看负载测试的用户数。

 

CMM

        CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准。

        （1）初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行时没有政策、资源等方面的保证，那么它仍然被视为初始级。

        （2）可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

        （3）已定义级：用于管理方面和工程方面的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。它要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。

        （4）已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变成为一个工业生产活动。

        （5）优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。如果一个企业达到了这一级，表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

        在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域（Key Process Area，KPA），一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标。每个级别对应的关键过程域见下表。

         

        关键过程域的分类

 

 

初始级

        软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行时没有政策、资源等方面的保证，那么它仍然被视为初始级。

 

定义级

       在定义级，企业全面采用综合性管理及工程过程管理，对整个软件生命周期的管理与工程化过程都已标准化，并综合成软件开发企业标准的软件过程。企业标准软件过程通过证明是正确且实用的，所有开发的项目须根据标准过程，剪裁出与项目适宜的过程，并执行这些过程。

第三方测试

       这里所说的第三方测试是指独立于软件公司自身测试的测试。所谓的第三方是指在软件公司和软件用户之间的一方。第三方测试机构也是一个中介的服务机构，它通过自己专业化的测试手段为客户提供有价值的服务。但是第三方测试机构提供的服务不同于公司内部的测试。因为，第三方测试机构的测试除了发现软件问题之外，还有对软件进行科学、公正的评价的职能，这就要求第三方测试机构要保持公正、廉洁、客观、科学、独立的态度。

       第三方测试机构存在的价值主要是由软件公司、软件用户以及国家的公正诉求所决定的。对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观、科学的评价，有助于开发商认清自己产品的定位。对于行业主管部门以及软件使用者来说，第三方测试机构独立公正的地位有助于对被测软件进行客观公正的评价，帮助用户选择合适、优秀的软件产品。而对于一些信息工程项目来说，在验收之前，经过第三方机构的严格测试，可以最大程度地避免信息行业的“豆腐渣”工程。此外，经过国家认可的第三方测试机构，还为国家软件产品的质量监督抽查提供独立公正的测试支持。

       由此可见，第三方测试机构的测试工程师面对的是各种各样的系统，而且大多与具体的业务相关，这就要求他们不仅有宽广深厚的软件技术功底、测试技术功底，而且需要积累行业知识和经验，并且要融会贯通。目前，我国涌现了很多的第三方测试机构，虽然它们处于不同的发展阶段，但是它们的存在必将对我国整个软件产业的健康发展起到巨大的促进作用

 

测试内容

       测试内容一般包括并发性能测试、疲劳强度测试、大数据量测试和系统资源监控等。

  软件测试

       测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。

       软件测试是针对一个程序的行为，在有限测试用例集合上动态验证软件是否达到预期的行为。

       软件测试过程如下：

       （1）拟定测试计划。

       （2）编制测试大纲。

       （3）设计和生成测试用例。

       （4）实施测试。

       （5）生成测试报告。

       软件测试方法：

       .人工测试：采用人工方式进行测试，目的是通过对程序静态结构的检查，找出编译时不能发现的错误。人工测试包括个人复查、抽查和会审等。

       .机器测试：把设计好的测试用例作用于被测程序，比较测试结果和预期结果是否一致。机器测试包括黑盒测试（功能测试）和白盒测试（结构测试）。

       软件测试伴随软件开发和维护过程，通常可以在概念上划分为以下三个阶段：

       .单元测试：也称为模块测试，在模块编写完成且无编译错误后就可以进行

      .集成测试：也称为组装测试，就是把模块按系统设计说明书的要求组合起来进行测试。

       .系统测试：是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种组装和确认测试。其目的是通过与系统需求相比较，发现所开发的系统与用户需求不符合的地方。

 

测试方法

        根据是否执行软件，将软件测试方法分为静态测试和动态测试。动态测试是建立在程序的执行过程中，根据是否要求了解被测对象的内部，分为黑盒测试和白盒测试。

               静态测试和动态测试

                      静态测试

                      静态测试方法包括检查单和静态分析方法，对软件文档的静态测试方法主要是以检查单的形式进行文档审查，而对软件代码的静态测试方法一般采用代码审查、代码走查和静态分析的形式进行。

                      静态分析是一种对代码的机械性和程序化的特性分析方法。一般包括控制流分析、数据流分析、接口分析和表达式分析。

                      代码审查是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审。

                      代码走查是由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，按照程序的逻辑，逐步运行测试用例，查找被测软件缺陷。代码走查应由测试人员集体阅读讨论程序，是用“人脑”执行测试用例并检查程序。

                      对于规模较小、安全性要求很高的代码也可进行形式化证明。静态分析常需要使用软件工具进行。

                      静态测试的特点有：不必设计在计算机上执行的测试用例；可充分发挥人的逻辑思维优势；不需特别条件，容易开展；发现错误的同时也就定位了错误，不需作额外的错误定位工作。

                      动态测试

                      动态测试是建立在程序的执行过程中，根据是否对被测对象内部的了解，分为黑盒测试和白盒测试。

                      黑盒测试是一种按照软件功能说明设计测试数据的技术，不考虑程序内部结构和编码结构，也不需考虑程序的语句及路径，只需了解输入／输出之间的关系，依靠这一关系和软件功能说明确定测试数据，判定测试结果的正确性。黑盒测试又称功能测试、数据驱动测试或基于需求的测试。

                      白盒测试是一种按照程序内部逻辑结构和编码结构设计测试数据的技术，可以看到程序内部结构，并根据内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径的覆盖情况都在测试中受到检验。白盒测试又称结构测试、逻辑测试或基于程序的测试。

                      动态测试的特点有：实际运行被测程序；必须设计测试用例来运行；测试结果分析工作量大，测试工作费时、费力；投入人员多、设备多，处理数据多，要求有较好的管理和工作规程。

                      在软件动态测试过程中，应采用适当的测试方法，实现测试要求。配置项测试和系统测试一般采用黑盒测试方法；部件测试一般主要采用黑盒测试方法，辅助以白盒测试方法；单元测试一般采用白盒测试方法，辅助以黑盒测试方法。

               黑盒测试

               黑盒测试方法一般采用功能分解、等价类划分、边界值分析、判定表、因果图、随机测试、猜错法和正交试验法等。

                      功能分解

                      功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。

                      步骤如下：

                      （1）使用程序设计中的功能抽象方法把程序分解为功能单元。

                      （2）使用数据抽象方法产生测试每个功能单元的数据。

                      功能抽象中程序被看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能有由其下一层功能定义。按照功能层次进行分解，可以得到众多的最低层次的子功能，以这些子功能为对象，进行测试用例设计。

                      数据抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集。程序的每一个输入和输出量的取值集合用数据抽象来描述。

                      等价类划分

                      等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试用例。

                      步骤如下：

                      （1）划分有效等价类：对规格说明是有意义、合理的输入数据所构成的集合。

                      （2）划分无效等价类：对规格说明是无意义、不合理的输入数据所构成的集合。

                      （3）为每一个等价类定义一个唯一的编号。

                      （4）为每一个等价类设计一组测试用例，确保覆盖相应的等价类。

                      边界值分析

                      边界值分析是针对边界值进行测试的。使用等于、小于或大于边界值的数据对程序进行测试的方法就是边界值分析方法。

                      步骤如下：

                      （1）通过分析需求规格说明，找出所有可能的边界条件。

                      （2）对每一个边界条件，给出满足和不满足边界值的输入数据。

                      （3）设计相应的测试用例。

                      对满足边界值的输入可以发现计算错误，对不满足的输入可以发现域错误。该方法会为其他测试方法补充一些测试用例，绝大多数测试都会用到本方法。

                      判定表

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

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

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

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

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

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

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

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

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

                      因果图

                      因果图方法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试用例。

                      步骤如下：

                      （1）分析需求规格说明，引出原因（输入条件）和结果（输出结果），并给每个原因和结果赋予一个标识符。

                      （2）分析需求规格说明中语义的内容，并将其表示成连接各个原因和各个结果的“因果图”。

                      （3）在因果图上标明约束条件。

                      （4）通过跟踪因果图中的状态条件，把因果图转换成有限项的判定表。

                      （5）把判定表中每一列表示的情况生成测试用例。

                      如果需求规格说明中含有输入条件的组合，宜采用本方法。有些软件的因果图可能非常庞大，根据因果图得到的测试用例数目非常多，此时不宜使用本方法。

                      随机测试

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

                      猜错法

                      猜错法是有经验的测试人员，通过列出可能有的错误和易错情况表，写出测试用例的方法。

                      正交实验法

                      正交实验法是从大量的实验点挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种实验设计方法。

                      利用正交实验法来设计测试用例时，首先要根据被测软件的需求规格说明找出影响功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当作状态，生成二无的因素分析表。然后，利用正交表进行各因子的状态的组合，构造有效的测试输入数据集，并由此建立因果图。这样得出的测试用例的数目将大大减少。

               白盒测试

               白盒测试方法一般包括控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、修订的条件／判定覆盖MC/DC、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序变异、程序插桩、域测试和符号求值等。

                      控制流测试

                      控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结构。所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。以下介绍几种覆盖：

                      （1）语句覆盖。语句覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被遍历，语句覆盖在测试中主要发现错误语句。

                      （2）分支覆盖。分支覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖。

                      （3）条件覆盖。条件覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件的可能取值至少满足一次。

                      （4）修订的条件／判定覆盖（MC/DC——Modified Condition/Decision Coverage）。修订的条件／判定覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判定中的每个条件都曾独立的影响判定的结果至少一次（独立影响意思是在其他的条件不变的情况下，只改变一个条件，就可影响整个判定的值）。

                      对安全性要求比较高的软件，一般采用此覆盖要求。此覆盖要求在测试用例的效率和数量之间较为平衡。

                      （5）条件组合覆盖。条件组合覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组合至少出现一次，这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。

                      （6）路径覆盖。路径覆盖要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行，较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。

                      以上各种覆盖的控制流测试步骤如下：

                      （1）将程序流程图转换成控制流图。

                      （2）经过语法分析求得路径表达式。

                      （3）生成路径树。

                      （4）进行路径编码。

                      （5）经过译码得到执行的路径。

                      （6）通过路径枚举产生特定路径的测试用例。

                      控制流图是描述程序控制流的一种图示方式，它由结点和定向边构成。控制流图的结点代表一个基本块，定向边代表控制流的方向。其中要特别注意的是，如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符连接的逻辑表达式，则需要改变复合条件的判断为一系列单个条件的嵌套的判断。控制流图的基本结构如下图所示。

                       

                      控制流图基本结构

                      数据流测试

                      数据流测试是用控制流程图对变量的定义和引用进行分析，查找出未定义的变量或定义了而未使用的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。

                      数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除的情况。

                      数据流测试步骤：

                      （1）将程序流程图转换成控制流图。

                      （2）在每个链路上标注对有关变量的数据操作的操作符号或符号序列。

                      （3）选定数据流测试策略。

                      （4）根据测试策略得到测试路径。

                      （5）根据路径可以获得测试输入数据和测试用例。

                      动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。

                      程序变异

                      程序变异是一种错误驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小错误。本方法应用于测试工具。

                      程序插装

                      程序插装是向被测程序中插入操作以实现测试目的方法。程序插装不应该影响被测程序的运行过程和功能。

                      有很多的工具有程序插装功能。由于数据记录量大，手工进行将是一件很烦琐的事。

                      域测试

                      域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊要求的测试使用。

                      符号求值

                      符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好使用工具，在公式分支较少时手工推导也是可行的。

 

静态测试

        静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态分析中进行人工测试的主要方法有桌前检查（Desk Checking）、代码审查和代码走查。经验表明，使用这种方法能够有效地发现30%～70%的逻辑设计和编码错误。

               桌前检查

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

               .检查变量的交叉引用表。重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用、变量的使用序列，临时变量在某条路径上的重写情况，局部变量、全局变量与特权变量的使用等。

               .检查标号的交叉引用表。验证所有标号的正确性；检查所有标号的命名是否正确，以及转向指定位置的标号是否正确。

               .检查子程序、宏、函数。验证每次调用与被调用位置是否正确；确认每次被调用的子程序、宏和函数是否存在；检验调用序列中调用方式与参数顺序、个数和类型上的一致性。

               .等值性检查。检查全部等价变量的类型的一致性，解释所包含的类型差异。

               .常量检查。确认每个常量的取值和数制、数据类型；检查常量每次引用同它的取值、数制和类型的一致性。

               .标准检查。用标准检查程序或手工检查程序中违反标准的问题。

               .风格检查。检查在程序设计风格方面发现的问题。

               .比较控制流。比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档并校正错误。

               .选择、激活路径。在程序员设计的控制流图中选择路径，再到实际的控制流图中激活这条路径。如果选择的路径在实际控制流图中不能激活，则源程序可能有错。用这种方法激活的路径集合应保证源程序模块的每行代码都被检查，即桌前检查应至少是语句覆盖的。

               .对照程序的规格说明，详细阅读源代码。程序员对照程序的规格说明书、规定的算法和程序设计语言的语法规则，仔细地阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，并从它们的差异中发现程序的问题和错误。

               .补充文档。桌前检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。

               由于程序员熟悉自己的程序和自身的程序设计风格，这种桌前检查可以节省很多的检查时间，但应避免主观片面性。

               代码审查

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

               第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。

               第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。

               在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。这种检查表类似于本章单元测试中给出的检查表。

               代码走查

               代码走查与代码审查基本相同，其过程也分为两步。

               第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。

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

               值得说明的是，使用静态测试的方法也可以实现白盒测试。例如，使用人工检查代码的方法来检查代码的逻辑问题也属于白盒测试的范畴。

 

动态测试

        动态测试指通过运行程序发现错误，分为黑盒测试法、白盒测试法和灰盒测试法等。

        （1）黑盒法。把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。因此，黑盒测试又称为功能测试或数据驱动测试，使用这种方法，为了做到穷尽测试，至少必须对所有输入数据的各种可能值的排列组合都进行测试。黑盒测试使用所有有效和无效的输入数据来测试程序是不现实的，所以黑盒测试同样不能做到穷尽测试，只能选取少量最有代表性的输入数据，以期用较少的代价暴露出较多的程序错误。常用的黑盒测试用例的设计方法有等价类划分、边界值分析、错误推测和因果图等。

        等价类划分把程序的输入域划分成若干部分，然后从每个部分中选取少数有代表性的数据作为测试用例，每一类代表性数据在测试中的作用等价于这一类中的其他值。划分等价类时，首先要把数目极多的输入分成若干个等价类。所谓等价类就是某个输入域的集合，对于一个等价类中的输入值来说，它们揭示程序中错误的作用是等效的。

        边界值分析是一种补充等价类划分的测试用例设计技术，它不选择等价类的任意元素，而选择等价类边界的测试用例。实践证明，为检验边界附近的处理而专门设计测试用例，常常可以取得良好的测试效果。

        错误推测法基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。基本思想是列举出程序中所有可能的错误和容易发生错误的特殊情况，再根据它们选择测试用例。

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

        （2）白盒法。把测试对象看做一个打开的盒子，测试人员必须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。由于白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。常用的白盒测试用例设计方法有基本路径测试、循环覆盖测试及逻辑覆盖测试等。

        逻辑覆盖是以程序内部逻辑为基础的测试技术，常用的有语句覆盖、判定覆盖、条件覆盖、条件判定覆盖、修正的条件判断覆盖、条件组合覆盖、点覆盖、边覆盖和路径覆盖等。

        循环覆盖是指覆盖程序中所有的循环，包括单循环及嵌套循环。

        基本路径法在程序控制流程图的基础上，通过分析控制结构的环路复杂性导出基本路径集合，然后设计测试用例，保证这些路径都至少通过一次。

        （3）灰盒法。灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。

        灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。

 

边界条件

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

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

         

        这段代码的意图是创建包含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。诸如此类的问题很常见，在复杂的大型软件中，可能导致极其严重的软件缺陷。

 

 

      软件测试分类

       按照全生命周期的软件测试概念，测试对象应该包括软件设计开发的各个阶段的内容，对于需求和设计阶段的测试以及关于文档的测试将在面向对象与文档测试部分进行描述，这里重点讲述开发阶段的测试和程序测试。

 按照开发阶段划分

              按照开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试和验收测试。

              . 单元测试。

              单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

              . 集成测试。

              集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。

              软件集成的过程是一个持续的过程，会形成很多个临时版本，在不断的集成过程中，功能集成的稳定性是真正的挑战。在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。冒烟测试也叫版本验证测试、提交测试。

              . 确认测试。

              确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。

              . 系统测试。

              系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。

              . 验收测试。

              按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

              按照测试实施组织划分

              按照测试实施组织划分，软件测试可分为开发方测试、用户测试（β测试）、第三方测试。

              . 开发方测试。

              通常也叫“验证测试”或“α测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。

              . 用户测试。

              在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。

              β测试通常被看成是一种“用户测试”。β测试主要是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件。通过用户各种方式的大量使用，来发现软件存在的问题与错误，把信息反馈给开发者修改。β测试中厂商获取的信息，可以有助于软件产品的成功发布。

              . 第三方测试。

              介于软件开发方和用户方之间的测试组织的测试。第三方测试也称为独立测试。软件质量工程强调开展独立验证和确认（IV&V）活动。IV&V是由在技术、管理和财务上与开发组织具有规定程度独立的组织执行验证和确认过程。软件第三方测试也就是由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。一般情况下是在模拟用户真实应用环境下，进行软件确认测试。

              按照测试技术划分

              按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。静态测试是指不运行程序，通过人工对程序和文档进行分析与检查；静态测试技术又称为静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查，静态测试包括：走查、符号执行、需求确认等。动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。我们这里讨论的白盒测试、黑盒测试、灰盒测试，在实现测试方法上既包括了动态测试也包括了静态测试。

              . 白盒测试

              通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。

              . 黑盒测试

              通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查样序是否按照需求规格说明书的规定正常实现。

              . 灰盒测试

              介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。

              灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。

              软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件生命周期。走查、单元测试、集成测试、系统测试用于整个开发过程中的不同阶段。开发文档和源程序可以应用单元测试应用走查的方法；单元测试可应用白盒测试方法；集成测试应用近似灰盒测试方法；而系统测试和确认测试应用黑盒测试方法。

 

Bug记录信息

       主要包括以下几项内容。

       . 测试软件名称；

       . 测试版本号；

       . 测试人名称；

       . 测试事件；

       . 测试软件和硬件配置环境；

       . 发现软件错误的类型；

       . 错误的严重等级；

       . 详细步骤；

       . 必要的附图；

       . 测试注释。

 

管理流程

        信息系统软件交付之后就进入了运维阶段，该阶段短则4～5年，长则可达10年以上。运维的目的是保证信息系统软件能正常而可靠地运行，并能使系统不断得到改善和提高，以充分发挥作用。运维的过程也就是不断满足用户各种维护需求的过程。用户的维护需求是不断变化的，所以需要持续地对信息系统软件进行修改和维护。这一过程从本质上来说是一个P、D、C、A（P-Plan，策划；D-Do，实施；C-Check，检查；A-Act，处理）循环，不停顿地周而复始地运转。按照戴明质量控制理论，信息系统软件运维的管理流程如下图所示。

         

        信息系统软件运维管理流程

        信息系统软件运维服务的四个关键要素是：人员、资源、技术和过程，每个要素通过关键指标反映运维服务的能力。在运维服务提供过程中，通过应用PDCA的方法论，在运维的策划、实施、检查、改进等不同阶段，通过对人员、资源、技术和过程四个服务要素的统一管理，来实现运维服务能力的持续提升。

 

测试报告

        一般情况下，在测试的标志性阶段或者测试结束时需要出具测试报告，测试报告是整个测试的总结，其主要作用是描述测试结果。测试报告的格式可以不拘一格，但需要验证是否包括以下关键内容：

        . 测试案例说明；

        . 测试结果数据；

        . 测试结果分析；

        . 测试环境说明；

        . 报告术语解释。

        这些内容在前面都有过详细论述，这里不再赘述。

 

软件编码规范评测

        程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。下面分别论述评测内容以及相应的评测标准。

        . 源程序文档化。

        ①符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。

        名字不是越长越好，应当选择精炼的、意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。

        ②程序的注释。夹在程序中的注释是程序员日后与程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。注释分为序言性注释和功能性注释。

        序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其他有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。

        功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：描述一段程序，而不是每一个语句；用缩进和空行，使程序与注释容易区别；注释要正确。

        ③标准的书写格式。视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中的程序段语句向右作阶梯式移行。使程序的逻辑结构更加清晰。

        . 数据说明。

        在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。

        ①数据说明的次序应当规范化。数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。

        ②说明语句中变量安排有序化。当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。

        ③使用注释说明复杂数据结构。如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。

        . 语句结构。

        在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。

        比如：在一行内只写一条语句；程序编写首先应当考虑清晰性；程序要能直截了当地说明程序员的用意；除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；首先要保证程序正确，然后才要求提高速度，反过来说，在使程序高速运行时，首先要保证它是正确的；避免使用临时变量而使可读性下降；对编译程序做简单的优化；尽可能使用库函数；避免不必要的转移；尽量采用基本的控制结构来编写程序；避免采用过于复杂的条件测试；尽量减少使用“否定”条件的条件语句；尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；数据结构要有利于程序的简化；程序要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见；利用信息隐蔽，确保每一个模块的独立性；从数据出发去构造程序；不要修补不好的程序，要重新编写。

        . 输入和输出

        输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入/输出风格还受到许多其他因素的影响。如输入/输出设备（终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。

        ①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；

        ②检查输入项的各种重要组合的合理性，必要时报告输入状态信息；

        ③使输入的步骤和操作尽可能简单，并保持简单的输入格式；

        ④输入数据时，应允许使用自由格式输入；

        ⑤应允许缺省值；

        ⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；

        ⑦在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；

        ⑧当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性；

        ⑨给所有的输出加注解，并设计输出报表格式。

 

       编码规范

        编码规范是程序编写过程中必须遵循的规则，一般会详细规定代码的语法规则、语法格式等，如下表所示。

         

        编码规范

         

         

       编码

               编码过程

               在给定了软件设计规格说明书后，下一步的工作就是编写代码。一般来说，编码工作可以分为四个步骤：

               （1）确定源程序的标准格式，制订编程规范。

               （2）准备编程环境，包括软硬件平台的选择，包括操作系统、编程语言、集成开发环境等。

               （3）编写代码。

               （4）进行代码审查，以提高编码质量。为提高审查的效率，在代码审查前需要准备一份检查清单，并设定此次审查须找到的bug数量。在审查时，要检查软件规格说明书与编码内容是否一致；代码对硬件和操作系统资源的访问是否正确；中断控制模块是否正确等。

               编码准则

               在嵌入式系统中，由于资源有限，且实时性和可靠性要求较高，因此，在开发嵌入式软件时，要注意对执行时间、存储空间和开发／维护时间这三种资源的使用进行优化。也就是说，代码的执行速度要越快越好，系统占用的存储空间要越小越好，软件开发和维护的时间要越少越好。

               具体来说，在编写代码时，需要做到以下几点：

               .保持函数短小精悍。一个函数应该只实现一个功能，如果函数的代码过于复杂，将多个功能混杂在一起，就很难具备可靠性和可维护性。另外，要限制函数的长度，一般来说，一个函数的长度最好不要超过100行。

               .封装代码。将数据以及对其进行操作的代码封装在一个实体中，其他代码不能直接访问这些数据。例如，全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性，提高了对象的内聚性，使封装后的代码对其他行为的依赖性较小。

               .消除冗余代码。例如，将一个变量赋给它自己，初始化或设置一个变量后却从不使用它，等等。研究表明，即使是无害的冗余也往往和程序的缺陷高度关联。

               .减少实时代码。实时代码不但容易出错、编写成本较高，而且调试成本可能更高。如果可能，最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。

               .编写优雅流畅的代码。

               .遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜，而且能捕捉到通过传统测试检查不到的各种问题。

               编码技术

                      编程规范

                      在嵌入式软件开发过程中，遵守编程规范，养成良好的编程习惯，这是非常重要的，将直接影响到所编写代码的质量。

                      编程规范主要涉及的三方面内容：

                      .命名规则。从编译器的角度，一个合法的变量名由字母、数字和下画线三种字符组成，且第一个字符必须为字母或下画线。但是从程序员的角度，一个好的名字不仅要合法，还要载有足够的信息，做到“见名知意”，并且在语意清晰、不含歧义的前提下，尽可能地简短。

                      .编码格式。在程序布局时，要使用缩进规则，例如变量的定义和可执行语句要缩进一级，当函数的参数过长时，也要缩进。另外，括弧的使用要整齐配对，要善于使用空格和空行来美化代码。例如，在二元运算符与其运算对象之间，要留有空格；在变量定义和代码之间要留有空行；在不同功能的代码段之间也要用空行隔开。

                      .注释的书写。注释的典型内容包括：函数的功能描述；设计过程中的决策，如数据结构和算法的选择；错误的处理方式；复杂代码的设计思想等。在书写注释时要注意，注释的内容应该与相应的代码保持一致，同时要避免不必要的注释，过犹不及。

                      性能优化

                      由于嵌入式系统对实时性的要求较高，因此一般要求对代码的性能进行优化，使代码的执行速度越快越好。以算术运算为例，在编写代码时，需要仔细地选择和使用算术运算符。一般来说，整数的算术运算最快，其次是带有硬件支持的浮点运算，而用软件来实现的浮点运算是非常慢的。因此，在编码时要遵守以下准则：

                      .尽量使用整数（char、short、int和long）的加法和减法。

                      .如果没有硬件支持，尽量避免使用乘法。

                      .尽量避免使用除法。

                      .如果没有硬件支持，尽量避免使用浮点数。

                      下图是一个例子，其中两段代码的功能完全一样，都是对一个结构体数组的各个元素进行初始化，但采用两种不同的方法来实现。下图（a）采用数组下标的方法，在定位第i个数组元素时，需要将i乘以结构体元素的大小，再加上数组的起始地址。下图（b）采用的是指针访问的方法，先把指针fp初始化为数组的起始地址，然后每访问完一个数组元素，就把fp加1，指向下一个元素。在一个奔腾4的PC上，将这两段代码分别重复10 700次，右边这段代码需要1ms，而左边这段代码需要2.13ms。

                       

                      算术运算性能优化的例子

测试人员

               测试人员的选择

               测试人员的能力包括以下几项。

               ①一般能力：包括表达、交流、协调、管理、质量意识、过程方法、软件工程等；

               ②测试技能及方法：包括测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等；

               ③测试规划能力：包括风险分析及防范、软件放行/接收准则制定、测试目标及计划、测试计划和设计的评审方法等；

               ④测试执行能力：包括测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具；

               ⑤测试分析、报告和改进能力：包括测试度量、统计技术、测试报告、过程监测及持续改进。

               测试人员的激励

                      X理论＋Y理论

                      . X理论：胡萝卜＋大棒——迫使人们工作；

                      . Y理论：经理的职能不是督促人们工作，而是使人们有可能工作。

                      需要的层次（Maslow模型）

                      . 生存需要——工作职位、工资奖金、休息时间；

                      . 安全需要——公正待遇、应付工作的能力和信心；

                      . 社会需要——团队归属感，互相认同、理解和支持；

                      . 自尊需要——具有受人尊重/赏识的能力或/和业绩；

                      . 自我实现需要——成为自己期望的人物。

                      人员激励的关键点

                      . 管理者习惯用对自己有效的因素激励测试人员，很可能发现无效；

                      . 过多使用权力、资金或处罚手段很可能导致项目失败；

                      . 行业领先企业采取卓有成效的非货币形式的激励措施；

                      . 在项目进行过程中，而不仅是在项目结束时实施激励措施；

                      . 奖励应该在工作获得认同后尽快兑现；

                      . 对人员的工作表现出真诚的兴趣是对他们最好的奖励；

                      . 激励因素是因人而异、因时而异的。已经满足的需要很可能不再成为激励因素。

                      人员自我激励

                      测试工作的快乐哲学：选择积极的态度，把工作当作游戏，让别人快乐，全身心投入工作。

                      注意测试工作的7条效率原则：主动思考，积极行动；一开始就牢记目标，不迷失方向；重要的事情放在首位（但常常把紧急的事情放在首位）；先理解人，后被人理解；寻求双赢；互相合作，追求1＋1>2；终生学习，自我更新，不断进步。

               测试职业发展

               国际推荐的软件测试职业发展计划如下。

               . 1~2年，测试技能：熟悉整个测试过程及产品业务领域，学习和掌握自动测试工具，学习测试自动化编程技术；开发和执行测试脚本，承担系统测试实施任务；掌握编程语言、操作系统、网络与数据库方面的技能。

               . 3~4年，测试过程：深入了解测试过程，掌握测试过程设计及改进，参与软件工作产品的同行评审；进一步了解产品业务领域，改进测试自动化编程技术；能指导初级测试工程师；加强编程语言、操作系统、网络与数据库方面的技能。

               . 4~5年，测试组织工作：管理1~3名测试工程师，担任任务估算、管理及进度控制；进一步培养在软件项目管理及支持工具方面的技能。

               . 5~6年，技术管理：管理4~8名测试工程师，提高任务估算、管理及进度控制能力，完成测试规划并制定测试计划；研究测试的技术手段，保持使用项目管理及支持工具的技能；用大量时间为其他测试工程师提供技术及过程方面的指导；开始与客户打交道并做演示推介。

               . 6~12年，测试管理：管理8名以上测试工程师，负责一个或多个项目的测试工作；与客户打交道并做演示推介；保持使用项目管理及支持工具的技能。

               人员的培训

                      软件测试培训内容分类

                      . 测试基础知识和技能培训。

                      . 测试设计培训、测试工具培训。

                      . 测试对象——软件产品培训。

                      . 测试过程培训。

                      . 测试管理培训。

                      制定测试人员培训计划

                      . 是测试计划的一个重要组成部分。

                      . 需要管理层的重视，在时间和资源上予以保证。

                      . 认真调查和分析测试人员的培训需求。

                      . 将培训活动安排在测试任务开始前。

                      . “边干边学”模式很可能牺牲质量和效率。

                      . 软件测试实习活动在整个培训中占较大比例。

                      . 鼓励合作学习，团队演练。

                      . 对培训效果要及时评价，发现不足进行改进。

       设计阶段

        设计阶段监理进行质量控制的要点如下。

        （1）了解建设单位的建设需求和对信息系统安全性的要求，协助建设单位制定项目质量目标规划和安全目标规划。

        （2）对各种设计文件提出设计质量标准。

        （3）进行设计过程跟踪，及时发现质量问题，并及时与承建单位协调解决。审查阶段性成果，并提出监理意见。审查承建单位提交的总体设计方案，审查承建单位对关键部位的测试方案。

        （4）协助承建单位建立质量保障体系。

        （5）协助承建单位完善现场质量管理制度。

        （6）组织设计文件及设计方案交底会，制定质量要求标准。

 

  概要设计

        1）设计软件系统总体结构

        设计软件系统总体结构的基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。

        2）数据结构及数据库设计

        （1）数据结构的设计。在需求分析阶段，已经通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。

        （2）数据库的设计。数据库的设计是指数据存储文件的设计，主要指以下几个方面。

        ①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用ER模型来表述数据模型。

        ②逻辑设计。ER模型是独立于数据库管理系统（DBMS）的，要结合具体的DBMS特征来建立数据库的逻辑结构。

        ③物理设计。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。

        3）编写概要设计文档

        文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。

        4）评审

        对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性以及各部分之间的一致性等都一一进行评审。

 

详细设计

        总体设计只是为整个信息系统提供了一个设计思路和框架，框架内的血肉需要系统的设计人员在详细设计这个阶段充实。总体设计完成后，设计人员要向用户和有关部门提交一份详细的报告，说明设计方案的可行程度和更改情况，得到批准后转入系统详细设计。详细设计阶段主要是在总体设计的基础上，将设计方案进一步详细化、条理化和规范化，为各个具体任务选择适当的技术手段和处理方法。系统的详细设计一般包括如下。

        （1）代码设计。

        代码设计就是信息分类和编码的工作，是将系统中有某些共同属性或特征的信息归并在一起，并利用便于计算机和人识别和处理的符号来表示这些信息的设计工作。

        （2）数据库设计。

        数据库设计就是构建既能客观、准确地反映外部世界，又便于人类大脑认识的概念模型，并在此基础上对数据进行建模，转化为数据库管理系统所支持的数据模型；选择合适的存储结构和存储方法，最终完成数据库的设计工作。

        （3）输入／输出设计。

        输入／输出设计主要是对以记录为单位的各种输入输出报表格式的描述。另外，对人机对话格式的设计和输入输出装置的选择也在这一步完成。

        （4）用户界面设计。

        用户界面设计是指在用户与系统之间架起一座桥梁。主要内容包括：定义界面形式；定义基本的交互控制形式；定义图形和符号；定义通用的功能键和组合键的含义及其操作内容；定义帮助策略，等等。

        （5）处理过程设计。

        总体设计将系统分解为许多模块，并基本决定了每个模块的功能和界面。处理过程设计则定义每个模块的内部执行过程，包括数据的组织、控制流、每一步的具体加工要求和实施细节。通过处理过程设计，为编写程序制定一个周密的计划。一般来说，每一个功能模块都应设计一个处理流程。

 

 

 

 用户需求

        收集用户需求是要找出用户需要的重要服务和功能。收集用户需求的机制主要包括与用户群的交流、用户服务和需求归档3个方面。

        收集用户需求最常用的方式有观察和问卷调查、集中访谈、采访关键人物。在整个设计和实施阶段，应始终保持与关键人员之间的交流，以确保网络工程建设不偏离用户需求。

        用户服务表用于表示收集和归档的需求信息，也用来指导管理人员和网络用户进行讨论。

 

软件需求

        在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。

        （1）功能需求。

        （2）性能需求。

        （3）用户或人的因素。

        （4）环境需求。

        （5）界面需求。

        （6）文档需求。

        （7）数据需求。

        （8）资源使用需求。

        （9）安全保密要求。

        （10）可靠性要求。

        （11）软件成本消耗与开发进度需求。

        （12）其他非功能性要求。

               需求分析的任务

               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。

               （1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。

               （2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。

               （3）导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。

               （4）修正项目开发计划。

               （5）如有必要，可开发一个原型系统以验证用户的需求。

               软件需求的分类

               下面介绍软件需求的分类。

               （1）功能需求。所开发的软件必须具备什么样的功能。

               （2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。

               （3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。

               软件需求分析方法

               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。

 

 

       需求分析

        需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：

        （1）结构化分析方法。本节后续内容将详细讨论SA的内容。

        （2）面向对象分析方法。将在10.3节中进行详细介绍。

        （3）面向问题域的分析（Problem Domain Oriented Analysis, PDOA）方法。PDOA更多地强调描述，而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素，是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图，但不同的是上下文图的建模对象是针对解系统，而问题框架则是针对问题域。也就是说，问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段，并未广泛应用。

               业务流程分析

               业务流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系和每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流程变化提供依据。

               业务流程分析的步骤如下：

               （1）通过调查掌握基本情况。

               （2）描述现有业务流程（绘制业务流程图）。

               （3）确认现有业务流程。

               （4）对业务流程进行分析。

               （5）发现问题，提出解决方案。

               （6）提出优化后的业务流程。

               在业务流程图中使用的基本符号如下图所示。

               数据流图

               DFD是结构化分析中的重要方法和工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型，在信息系统开发中，一般将它作为需求说明书的组成部分。

                

               业务流程图符号

               DFD从数据传递和加工的角度，利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。具体来说，DFD的主要作用如下：

               （1）DFD是理解和表达用户需求的工具，是系统分析的手段。由于DFD简明易懂，理解它不需要任何计算机专业知识，因此通过它同客户交流很方便。

               （2）DFD概括地描述了系统的内部逻辑过程，是系统分析结果的表达工具，因而也是系统设计的重要参考资料，是系统设计的起点。

               （3）DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。

               在DFD中，通常会出现4种基本符号，分别是数据流、加工、数据存储和外部实体（数据源及数据终点）。数据流是具有名字和流向的数据，在DFD中用标有名字的箭头表示。加工是对数据流的变换，一般用圆圈表示。数据存储是可访问的存储信息，一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示。下图是一个典型的DFD示例。

                

               办理取款手续的DFD

               为了表达数据处理过程中的数据加工情况，用一个DFD是不够的。稍微复杂的实际问题，在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的DFD反映这种结构关系，能清楚地表达整个系统。

               下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1，第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，它的上层图称为父图，在它下一层的图则称为子图。

                

               分层数据流图

               概括地说，画DFD的基本步骤，就是“自顶向下，逐层分解”。检查和修改的原则如下：

               （1）DFD中的所有图形符号只限于前述4种基本图形元素。

               （2）顶层DFD必须包括前述4种基本元素，缺一不可。

               （3）顶层DFD中的数据流必须封闭在外部实体之间。

               （4）每个加工至少有一个输入数据流和一个输出数据流。

               （5）在DFD中，需按层给加工框编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。

               （6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。

               （7）可以在DFD中加入物质流，帮助用户理解DFD。

               （8）图上每个元素都必须有名字。

               （9）DFD中不可夹带控制流。

               数据字典

               数据字典是关于数据的信息的集合，也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD，数据字典难以发挥作用；没有数据字典，DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起，才能共同构成系统的规格说明。

               数据字典的设计包括：数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息：名称、别名或编号、分类、描述、何处使用。

               对加工的描述是数据字典的组成内容之一，常用的加工描述方法有结构化语言、判定树及判定表。

               （1）结构化语言：介于自然语言和形式语言之间的一种半形式语言，在自然语言基础之上加了一些限度，使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句，即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定，与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇：祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。

               （2）判定树：若一个动作的执行不只依赖一个条件，而与多个条件有关，那么这项策略的表达就比较复杂。如果用结构化语言的判断语句，就有多重嵌套，层次一多，可读性就会下降。用判定树来表示，可以更直观一些。

               （3）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。

 

 

  测试信息流

        测试信息流如下图所示。测试过程需要以下三类输入。

         

        测试信息流

        软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。

        测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程中，测试配置只是软件配置的一个子集。

        测试工具：为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。

        测试之后，要对所有测试结果进行分析，即将实测的结果与预期的结果进行比较。如果发现出错的数据，就意味着软件有错误，就需要开始排错（调试）。即对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。

        排错的过程是测试过程中最不可预知的部分，即使是一个与预期结果只相差0.01%的错误，也可能需要花上一个小时、一天、甚至一个月的时间去查找原因并改正错误。也正是因为排错中的这种固有的不确定性，使得我们很难确定可靠的测试进度。

        通过收集和分析测试结果数据，开始针对软件建立可靠性模型。如果经常出现需要修改设计的严重错误，那么软件质量和可靠性就值得怀疑，同时也表明需要进一步测试。如果与此相反，软件功能能够正确完成，出现的错误易于修改，那么就可以断定：或者是软件的质量和可靠性达到可以接受的程度，或者是所作的测试不足以发现严重的错误。如果测试发现不了错误，那么几乎可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用过程中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40~60倍

 

。

 

功能测试

        Web应用功能测试指Web应用系统的基本功能的测试，其案例的设计方法可参见有关《黑盒测试技术》章节的内容。

        考虑到Web应用本身的特点，其功能测试还要注意以下几个方面。

        . 客户端的选择。

        Web应用客户端软件环境主要包括操作系统和浏览器。除非有特殊要求，测试功能时，我们一般选择比较流行的配置，如选择WindowsXP+IE6.0的简体中文版本。需要注意的是，浏览器的种类和版本有可能影响功能的正确实现。

        . 客户端浏览器的配置。

        一般情况下，开发者不会过多地考虑客户端配置问题，只是将更多的时间用于实现服务端的程序，而用户也往往不会刻意地对所使用的浏览器进行适应性配置。如果测试人员完全按照浏览器的缺省配置测试一个Web应用的功能，有可能会出现较多的因浏览器配置而引起的问题。下面以IE6.0为例进行说明，IE6.0的主要配置界面如下图所示。

          

        IE6.0的主要配置界面

        例如Cookie设置就会影响含有Cookie的Web应用的功能能否成功地实现。其他如脚本设置、安全设置、显示设置等大多数设置都会影响到Web应用功能的实现。

        . 客户端的显示设置。

        大多数人都喜欢使用1024×768像素的显示设置，但并不是所有的Web应用都支持这种设置。不合适的显示设置不但会使Web应用系统的界面显示异常，还可能导致应用功能无法实现。

        . 内容测试。

        由于Web应用带有一定的开放性，尤其是发布于互联网上的网站，其内容是完全开放的，因此在Web系统的功能测试中还要重点测试一个方面，即内容测试。

        内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题，甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的“拼音与语法检查”功能；信息的相关性是指，是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中所谓的“相关文章列表”。

        下面介绍两种Web应用功能测试的自动化技术，一个是Web应用链接质量保证技术，另一个是Web应用功能测试技术，下面分别论述。

               Web应用链接质量保证技术

               链接是使用户从一个页面浏览到另一个页面的重要手段，链接的质量决定着功能是否能够成功实现。

               要保证每个链接的质量，需要做好三件事情：

               ①该链接将用户带到它所说明的地方；

               ②被链接页面是存在的；

               ③保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面。

               链接测试非常复杂。比如当网页的结构非常复杂且数量巨大时，链接检查的速度就迫切需要提高。当网络连接总是不稳定的时候，误判的频率增大导致工作量加大，就需要保证工作进度。还有，测试的结果能否清晰地报告出来等，这些需求都提高了测试的复杂度。

               要测试Web应用的链接，可以借助于自动化的Web应用链接测试工具，例如WebCheck、Linkbot、TestPartner等。这些测试工具在测试过程中自动扫描Web应用的所有链接，定位及报告问题。针对应用中存在的各种各样的链接，比如图片、框架（Frame）、插件（Plugin）、背景、样式表（Style Sheet）、脚本、Java Applet等以及支持的连接种类，比如HTTP、FTP、GOPHER、HTTPS等工具都能够支持。另外，对本地的链接和重定向的链接也能很好地支持。例如WebCheck能够定位约50个的问题类型，并且提供19个HTML格式的报告。

               利用自动化测试工具测试Web应用的链接，主要优势体现在以下几个方面。

               . 简单易用；

               . 在实现上采用多线程技术，因此检查速度特别快；

               . 对断开的连接可以再次检查，避免误判；

               . 没有检查连接的数量限制，只受系统资源的约束；

               . 可以分析Web应用的结构；

               . 检查结果可以分类查看，自动生成HTML格式的报告。

               Web应用链接主要测试点如下。

               . 测试内部和外部链接中成功和失败的链接点，以及应用中不被其他链接调用的页面；

               . 测试链接中新网页、老网页、慢网页以及丢失的图象标题标签和属性标签等；

               . 分析Web应用的结构是否合理，包括显示和某个URL相关的链接及按照标题、描述、作者、大小、最后修改时间、类型为URL链接分类等。

               Web应用功能测试技术

               如果开发人员刚创立一个新的Web应用系统。在发布应用系统之前，它必须经过测试以确保一切设定功能都能正常运行，这样的测试任务中，针对同一模块或者同一功能点的测试可能需要重复多次。另外，在一个公司中不同项目的测试可能并行展开，例如人事部门的HR系统、客服部门的CRM系统、物流部门的ERP系统等。这样的现状就会使测试人员面临这样一个问题，即“如何有效地测试不断修改着的一个或多个应用程序”。如果资源有限的话，这个问题就更加棘手。人工测试的工作量太大，况且很多公司负担不起额外的时间来培训新的测试人员。为了解决这个问题，就需要一个能简单操作的测试工具来自动完成功能性测试。

               Mercury Interactive的WinRunner就是一个功能性测试工具。它通过捕获和重放用户对Web应用程序的操作，WinRunner可自动执行功能性测试。下面我们来看一个标准的测试过程，主要步骤包括：创建测试脚本、插入检查点、运行测试以及分析结果。

               . 创建测试脚本。

               创建测试脚本只需记录下一个标准的业务流程，如下一张订单或建立一个新的商家账户。测试人员在GUI上点击鼠标，测试工具记录流程就可建立测试脚本，即使技术知识有限的用户也能生成完整的测试。脚本可以直接编辑来满足各种复杂测试的需求。例如，WinRunner可以将两种测试脚本创建方式结合在一个环境下，来适应测试需求。这两种测试脚本创建方式分别是模拟控件操作和模拟鼠标操作。

               . 插入检查点。

               在记录一个测试的过程的脚本中，测试工程师可插入检查点，测试工具会收集检查点的性能指标。脚本运行时，测试工具在查寻潜在错误的同时，会比较检查点所设定的结果和实际测试结果，对其一一验证。例如，WinRunner允许您使用几种不同类型的检查点，包括文本、GUI、位图和数据库。用一个位图检查点，可以确认一个位图图像，如公司的图标是否出现在指定位置。

               . 运行测试。

               建立起测试脚本，并插入检查点和做一些必要修改后，就可以开始运行测试。当测试工具执行测试时，它会自动操作应用程序，正如一个真实用户根据记录流程执行着每一步的操作。

               . 分析结果。

               一旦测试结束后，就需要分析测试结果。测试工具一般会提供详尽的、易读的报告，这些报告对在测试运行中发生的重要事件进行描述，如出错内容和检查点等。

               一次测试结束后，随着时间推移，开发人员会对应用程序做进一步的修改，并需要另加额外的测试。有了前面利用自动化测试工具进行测试的基础，不必改动测试脚本，就可以重新建一个新的测试，这样大大地节省了时间和资源，充分利用了测试投资。

               功能自动化测试工具还能验证数据库的数值，从而确保交易的准确性。例如，在创建测试脚本时，可以设定哪些数据库表格和记录资料需要检测。在重放时，测试程序就会核对数据库内的实际数值与脚本中设定的数值，在有更新/修改，删除或插入的记录上会使用突出标识以引起注意。

               有时为了彻底全面地测试一个应用程序，需要了解对于不同类型的数据，它是如何运行的。测试工具可以将一个记录下的业务流程转化为一个数据驱动的测试，来反映多个用户各自独特且真实的操作行为。以一个订单输入的流程为例，测试人员或许希望将一些锁定的项目栏，如定单号或客户名转化为可变栏，这样就可以用多套数值来检测应用程序了。数据来源可以采用自动生成表格，也可直接从其他的表格或数据库中导入。数据驱动性测试不仅节省了时间和资源，而且提高了应用程序的测试覆盖率。

               利用自动化测试工具在对脚本进行编辑的时候，可以从列表里选择一个功能函数加到脚本中，以提高测试能力。例如，点击“calendar”，然后从年历功能中的下属目录中选择，如“calendar_select_date()”，工具会提供函数的解释。选定了这个函数后，可以输入参数，再将这个函数插入到测试脚本中。

 

 

 

软件测试策略

        测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试和系统测试。如下图所示显示出软件测试经历的4个步骤。

         

    

    软件测试的过程

        开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。然后，把已测试过的模块组装起来，进行集成测试（组装测试），主要对与设计相关的软件体系结构的构造进行测试。为此，在将一个一个实施了单元测试并确保无误的程序模块组装成软件系统的过程中，对正确性和程序结构等方面进行检查。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。最后是系统测试，把已经经过确认的软件纳入实际运行环境中，与其他系统成分组合在一起进行测试。严格地说，系统测试已超出了软件工程的范围。

测试信息流

               测试信息流如下图所示。测试过程需要以下三类输入。

               

               测试信息流

               软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。

               测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程中，测试配置只是软件配置的一个子集。

               测试工具：为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。

               测试之后，要对所有测试结果进行分析，即将实测的结果与预期的结果进行比较。如果发现出错的数据，就意味着软件有错误，就需要开始排错（调试）。即对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。

               排错的过程是测试过程中最不可预知的部分，即使是一个与预期结果只相差0.01%的错误，也可能需要花上一个小时、一天、甚至一个月的时间去查找原因并改正错误。也正是因为排错中的这种固有的不确定性，使得我们很难确定可靠的测试进度。

               通过收集和分析测试结果数据，开始针对软件建立可靠性模型。如果经常出现需要修改设计的严重错误，那么软件质量和可靠性就值得怀疑，同时也表明需要进一步测试。如果与此相反，软件功能能够正确完成，出现的错误易于修改，那么就可以断定：或者是软件的质量和可靠性达到可以接受的程度，或者是所作的测试不足以发现严重的错误。如果测试发现不了错误，那么几乎可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用过程中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40~60倍。

               分析设计阶段

               分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。下述章节将详细论述。

                      需求说明书评测

                      由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。

                      因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。

                      什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。

                      . 编制良好的需求说明书8条原则。

                      1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。

                      原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。

                      原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。

                      原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。

                      原则4：规格说明必须包括系统运行的环境。

                      原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

                      原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。

                      原则7：规格说明必须容许不完备性并允许扩充。

                      原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。

                      尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其他各种形式的规格说明都适用。当然要结合实际来应用上述的原则。

                      . 需求说明书的框架。

                      需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。如下表中列出了需求说明书的框架。

                      

                      需求说明书的框架

                      . 需求说明书评测内容。

                      需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：

                      ①系统定义的目标是否与用户的要求一致；

                      ②系统需求分析阶段提供的文档资料是否齐全；

                      ③文档中的所有描述是否完整、清晰，准确地反映用户要求；

                      ④与所有其他系统成份的重要接口是否都已经描述；

                      ⑤被开发项目的数据流与数据结构是否足够、确定；

                      ⑥所有图表是否清楚，在不补充说明时能否理解；

                      ⑦主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

                      ⑧软件的行为和它必须处理的信息、必须完成的功能是否一致；

                      ⑨设计的约束条件或限制条件是否符合实际；

                      ⑩是否考虑了开发的技术风险；

                      ?是否考虑过软件需求的其他方案；

                      ?是否考虑过将来可能会提出的软件需求；

                      ?是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；

                      ?有没有遗漏、重复或不一致的地方；

                      ?用户是否审查了初步的用户手册或原型；

                      ?项目开发计划中的估算是否受到了影响。

                      为保证软件需求定义的质量，评测应由专门指定的人员负责，并按规程严格进行。评审结束，应有评审负责人的结论意见及签字。除承建单位分析员之外，业主单位人员和测试单位都应当参加评测工作。需求说明书要经过严格评测，一般，评测的结果都包括了一些修改意见，待修改完成后再经评测，才可进入设计阶段。根据上述讨论的评测内容，可以制定需求说明书评测规范，如下表所示。

                      填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

                      

                      需求说明书评测规范

                      

                      在需求说明书评测结束后，测试单位应将评测意见以专题报告的形式提交业主单位。

                      概要设计说明书评测

                      . 设计说明书的框架。如下表所示为软件设计规格说明的大纲。

                      

                      软件设计规格说明大纲

                      软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列设计质量的评测，以便及时发现和解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。

                      . 概要设计说明书评测的内容。

                      ①可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成份是否可追溯到某一项需求。

                      ②接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。

                      ③风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。

                      ④实用性：即确认该软件设计对于需求的解决方案是否实用。

                      ⑤技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。

                      ⑥可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。

                      ⑦质量：即确认该软件设计是否表现出良好的质量特征。

                      ⑧各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。

                      ⑨限制：评估对该软件的限制是否现实，是否与需求一致。

                      ⑩其他具体问题：对于文档、可测试性、设计过程等进行评估。

                      在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。

                      为评测设计是否达到目标，必须建立衡量设计的技术标准。如下：

                      ①设计出来的结构应是分层结构，从而建立软件成分之间的控制。

                      ②设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。

                      ③设计应当既包含数据抽象，也包含过程抽象。

                      ④设计应当建立具有独立功能特征的模块。

                      ⑤设计应当建立能够降低模块与外部环境之间复杂连接的接口。

                      ⑥设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。

                      根据上述讨论的评测内容以及评测标准，可以建立概要设计说明书评测规范，如下表所示。

                      填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

                      

                      概要设计说明书评测规范

                      

                      详细设计说明书评测

                      详细设计说明书的评测标准和评测内容与概要设计说明书基本相同，这里不再赘述。如下表所示为详细设计说明书评测规范。

                      填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

                      

                      详细设计说明书评测规范

                      

                      软件编码规范评测

                      程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。下面分别论述评测内容以及相应的评测标准。

                      . 源程序文档化。

                      ①符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。

                      名字不是越长越好，应当选择精炼的、意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。

                      ②程序的注释。夹在程序中的注释是程序员日后与程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。注释分为序言性注释和功能性注释。

                      序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其他有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。

                      功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：描述一段程序，而不是每一个语句；用缩进和空行，使程序与注释容易区别；注释要正确。

                      ③标准的书写格式。视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中的程序段语句向右作阶梯式移行。使程序的逻辑结构更加清晰。

                      . 数据说明。

                      在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。

                      ①数据说明的次序应当规范化。数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。

                      ②说明语句中变量安排有序化。当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。

                      ③使用注释说明复杂数据结构。如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。

                      . 语句结构。

                      在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。

                      比如：在一行内只写一条语句；程序编写首先应当考虑清晰性；程序要能直截了当地说明程序员的用意；除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；首先要保证程序正确，然后才要求提高速度，反过来说，在使程序高速运行时，首先要保证它是正确的；避免使用临时变量而使可读性下降；对编译程序做简单的优化；尽可能使用库函数；避免不必要的转移；尽量采用基本的控制结构来编写程序；避免采用过于复杂的条件测试；尽量减少使用“否定”条件的条件语句；尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；数据结构要有利于程序的简化；程序要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见；利用信息隐蔽，确保每一个模块的独立性；从数据出发去构造程序；不要修补不好的程序，要重新编写。

                      . 输入和输出

                      输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入/输出风格还受到许多其他因素的影响。如输入/输出设备（终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。

                      ①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；

                      ②检查输入项的各种重要组合的合理性，必要时报告输入状态信息；

                      ③使输入的步骤和操作尽可能简单，并保持简单的输入格式；

                      ④输入数据时，应允许使用自由格式输入；

                      ⑤应允许缺省值；

                      ⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；

                      ⑦在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；

                      ⑧当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性；

                      ⑨给所有的输出加注解，并设计输出报表格式。

               开发阶段

                      单元测试

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

                      . 单元测试的内容。

                      在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的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）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。

                      

                      一次性组装方式

                      

                      自底向上的增殖方式

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

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

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

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

                      . 满足某些软件需求；

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

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

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

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

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

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

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

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

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

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

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

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

                      . 集成测试完成的标志。

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

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

                      ②修正了所发现的错误。

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

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

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

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

                      确认测试

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

                      . 进行有效性测试。

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

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

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

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

                      . 软件配置复查。

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

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

                      系统测试

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

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

                      验收测试

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

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

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

               软件验证与确认（V&V）过程

               软件的验证与确认（V&V）是贯穿软件生命周期的重要的质量保证过程，国际标准化组织IEEE在1986年颁布了软件V&V标准，又于1998年修订颁布了IEEE/ANSI Std 1012-1998软件验证与确认计划。标准规定了软件验证和确认过程（简称V&V）和软件验证和确认计划（简称SVVP）编制要求。我国软件验证与确认（V&V）的国家标准也即将颁布实施，将在我国软件的质量保证和软件测试的工作中发挥重要作用。

               软件的V&V过程是确定按照规定的软件过程开发的产品是否符合活动的要求，软件是否满足它的预期用途和用户需要。软件的V&V过程包括软件产品和过程的分析、评价、评审、审核、评估和测试。

               软件测试活动是软件V&V过程的一个组成部分。软件测试过程的任务与管理也要符合软件V&V过程的有关规定。下面重点介绍软件V&V中的测试过程与管理。

                      V&V基本概念

                      . 验证（Verification）：通过检查和提供客观证据，证实规定的需求已满足。

                      . 确认（Validation）：通过检查和提供客观证据，证实预期用途的需求是否得到满足。

                      . 独立验证和确认（IV&V Independent Verification and Validation）：由在技术、管理和财务上与开发组织有规定程度独立性的组织执行的V&V过程。

                      V&V框架是由与软件开发过程同步的V&V过程、各阶段的V&V活动和任务组成的，如下图所示。

                      

                      V&V结构

                      对每个V&V活动都规定了它的输入、任务和输出，如下图所示。

                      

                      V&V活动过程

                      软件V&V过程

                      . 软件生存周期的V&V过程框架。

                      整个软件生存周期的V&V过程框架结构描述了各阶段的V&V过程、活动和任务的层次关系，如下图所示。

                      

                      V&V过程、活动和任务的层次关系

                      . 软件开发过程的V&V概述。

                      IEEE Std 1012-1998中开发过程的V&V，如下图所示。

                      

                      软件开发过程的V&V

                      软件V&V过程中的测试

                      . 测试过程。

                      GB/T 18905.5中规定的开发过程中的软件测试过程包括：测试计划过程、测试设计过程、测试执行过程和测试结束过程。如下图所示。

                       

                      软件测试过程

                      . 需求V&V活动中的测试。

                      需求V&V活动中有两项测试任务：系统V&V测试计划生成和验证、验收V&V测试计划生成和验证。两项V&V的任务、输入和输出如下表所示。

                      

                      需求V&V活动中的测试任务、输入和输出

                      

                      . 设计V&V活动中的测试。

                      设计V&V活动中有三项测试任务：单元V&V测试计划生成和验证、集成V&V测试计划生成和验证与V&V测试计划生成和验证。三项V&V的任务、输入和输出如下表一和如下表二所示。

                      

                      设计V&V活动中的测试任务、输入和输出

                      

                      

                      设计V&V活动中的测试任务、输入和输出（续）

                      

                      . 实现V&V活动中的测试。

                      实现V&V活动中有三项测试任务：V&V测试用例生成和验证、V&V测试规程生成和验证以及部件V&V测试计划执行和验证。三项V&V的任务、输入和输出如下表所示。

                      

                      实现V&V活动中的测试任务、输入和输出

                      

                      软件测试V&V活动

                      测试V&V活动覆盖了集成测试、系统测试和验收测试。测试V&V活动及它与软件生存期的关系如下图所示。V&V的目标是确保通过执行集成测试、系统测试和验收测试使软件需求和分配给软件的系统需求得到满足。

                      

                      V&V测试产品和测试执行任务的时段图

                      测试的V&V工作应生成自己的V&V测试件（包括计划、设计、用例和规程），执行并记录自己的测试，并对照软件需求验证测试计划、设计、用例、规程和结果；测试的V&V工作应验证测试活动和测试件（包括计划、设计、用例、规程和执行结果）。测试V&V活动的任务、输入与输出的关系如下表一和如下表二所示。

                      

                      测试V&V活动中的测试任务、输入和输出

                      

                      测试V&V活动中的测试任务、输入和输出（续）

 

测试策略

        由于标准符合性测试的不同分类，其相应的测试原理也不尽相同。

               数据内容类标准

               如《教育管理信息化标准》（第1部分《学校管理信息标准》），在测试工具设计上，其实现原理如下所示。

               . 将符合标准的信息集（表结构）与代码集（表内容）构建在测试工具数据库中，即建立标准模板；

               . 测试工具通过ODBC、JDBC等数据库连接方式连接被测软件的数据库；

               . 测试工具提供人工或自动方式建立模板库与被测库之间的关联，读取并验证相关数据表信息；

               . 生成信息集与代码集标准符合性检测结果报告。

               注意，在实际应用中，从易维护的角度出发，被测软件的代码集可能不是多个不同类别的小代码表集，而是一个包含各种类别的大代码表，但测试工具模板库往往是多个不同类别的小代码表集，这就要求测试工具能够实现一对多或多对多的关联设置。

               而对于检察机关网络应用软件的数据格式规范与代码符合性规范的测试工具，可采用网上已有的相关工具或自行开发。如数据格式规范测试可辅助采用已有的XML解析器进行，而代码符合性规范可采取自行开发测试工具方式执行，测试步骤包括工具中建立标准模板、连接被测软件、与标准模板比对测试和输出测试结果。

               通信协议类标准

               测试工具的实现原理与第一类标准基本相似，如中国远程教育CELTS-20教学管理标准中的，基于HTTP协议绑定规范的，测试工具可以这样实现：①建立标准模拟课件；②导入模拟课件到被测平台；③测试工具自动运行模拟课件，主动与被测平台进行数据通信；④将二者通信内容与工具中的标准模板内容进行比较，得出比较分析结果。

               开发接口类标准

                      SQL标准符合性测试

                      按照SQL92/97标准，全面测试一个SQL产品的功能特性。在详细研究美国标准技术研究所（NIST）的测试用例库（即在整个测试过程中，只需要执行全部的测试用例文件，最后统计通过的测试用例即可）的基础上，可自行开发一个集测试和结果的定量分析于一体的自动化测试工具，利用该测试工具可以直接选择被测文件，运行并统计运行的结果。

                      通过的入门级测试用例数占入门级测试用例总数的比例，即为入门级测试通过率。通过的过渡级测试用例数占过渡级测试用例总数的比例，即为过渡测试通过率。

                      为了保证测试结果的真实性，还可采用交互式测试用例验证测试结果，如果发现问题，则相应的嵌入式测试用例的结果视为不通过。

                      ODBC标准

                      可采用SWsoft Inc开发的ODBC2.5标准符合性测试工具进行测试。在此基础上，按照ODBC3.0标准对测试用例进行相当规模的修改和扩充，并且将微软的QUICK TEST测试工具的部分模块集成到该测试工具中，同时对测试结果进行了定量的分析。

                      其中，对API函数的测试，参照微软的测试工具（QuickTest）对每个函数选定一种最简单的参数组合来测试，仅用其作简单的支持性测试。此项测试根据通过测试的函数的百分比来计算。对于其他的更重要的应用功能，是通过其他更详细、更复杂的测试用例来验证的，其执行结果的成功与否直接记录为测试结果。

                      JDBC标准

                      可在SUN公司开发的JDBC标准符合性测试工具基础上，按照JDBC3.0标准对测试用例进行修改和扩充，同时加入对测试结果的定量分析功能。

                      JDBC标准符合性测试完成后，统计各个接口或类中API函数通过的测试用例点的数量，按用例通过的比例和每个类或接口所占的权值计算总体得分。

               信息编码类标准

               例如，对GB 18030中文符合性测试，包括字汇完整性和体系正确性两方面。

               对于字汇完整性可采用抽样测试的方法，其过程如下。

               . 生成标准测试文件。即依照GB 18030的字符集生成字符数据文件（如.TXT），包括GB 18030中定义的全部汉字区、符号区、保留区和用户自定义区。

               . 运行被测软件，打开已生成的标准文本文件，将屏幕显示内容与GB 18030中指定内容进行对比，记录屏幕显示对比结果。

               . 运行待测软件，打开已生成的文本文件并打印其内容，将打印结果与GB 18030中指定内容进行对比，记录打印对比结果。

               . 抽样对比。例如：抽样方法可定义为单字节抽样率达到100%，双字节1区抽样率达到约20%，双字节2区抽样率达到约15%，双字节3区抽样率达到约10%，双字节4区抽样率达到约5%，双字节5区抽样率达到约20%和四字节区抽样率达到约5%。抽样范围包括边界字符和中间随机字符，如有错误则抽样率加倍，直至抽样率达到100%。各区矩阵的抽样率均应达到100%。抽样对比测试办法如下：单字节区，逐字对比。双字节1～5区，以第一字节相同的所有字符构成一个矩阵为一个检查单位，每矩阵抽查第一个字符、最后一个字符，在其他字符中按前述抽样率随机抽查数个字符，如果被抽样字符中出现对比结果不符合现象，或发现明显的“？”、方框、连续空白，则按前述抽样方法进行。双字节用户区1～3，与用户文档中承诺的用户自定义字符列表或用户自定义界面的输入结果进行对比，抽样率为10%；如没有用户自定义字符，则应不显示字符。四字节区，每区抽查第一个字符、最后一个字符，在其他字符中随机抽查数个字符（区抽样率≥5%），如果被测字符中出现对比结果不符合现象，或发现明显的“？”、方框、空白，则对比整个矩阵。

               对于体系正确性测试，其测试过程包括：

               . 生成随机文件，即从GB 18030定义的全部字符中随机抽取，而形成的大于5000字符的文本。文本中包括单字节区、各双字节区、四字节区中的字符，所有字符随机组合。

               . 编辑处理，即在被测的软件平台上，将已生成的随机文件打开，并进行编辑处理，包括插入字符、删除字符、存储字符、复制粘贴、打印等操作，各类操作均包括单字节区、各双字节区、四字节区中的字符。

               . 记录结果，即记录编辑处理文本文件的结果。

               对于字汇完整性，符合以下所有条件的，字汇完整性成绩为通过，其他情况为不通过。

               . 单字节区显示和打印的符合率均等于100%。

               . 双字节各区显示和打印的符合率均大于98%。

               . 四字节区显示和打印的符合率均大于97%。

               对于体系正确性，插入字符、删除字符、存储字符、复制粘贴、打印等编辑操作处理正确为通过，出现乱字符、多字符、丢字符或其他影响编辑操作的处理结果为不通过。只有在字汇完整性与体系正确性的成绩均为通过时，总成绩为通过。其他情况为不通过。

               目前，由于GB 18030的测试主要依靠人工验证，所以测试过程相对繁琐一些。

 

 

测试实施

        标准符合性测试工具与一般功能和负载压力测试工具有着明显的不同，它是为明确的应用对象和测试目的服务的，具有更强的针对性，应用范围相对而言更具体、更狭隘一些。标准符合性测试的基本原理，就是将被测软件产品的功能与性能指标，和标准规定必须满足的功能和性能指标进行比较，从而确定软件产品对标准的符合程度。

        一般来说，标准符合性测试可以按以下步骤实施。

        ①阅读和理解标准：很多人可能不理解或者不认为应该将它归为标准符合性测试的第一步，但它确实是实施有效的标准化符合性测试的前提。因为，大多数情况下制定标准和进行标准符合性测试的不是同一组人，因此，在测试正式开始之前，首先就必须很好地阅读并理解标准的目的、意义、范围和具体的指标内容，否则测试结果就会产生偏差。

        ②确定测试工具：标准符合性自动化测试一般需要依靠特定的测试工具来完成，可以选择适当的商业化测试工具，也可以根据情况决定自主开发相应的测试工具。如前所述，由于标准具有特定性，所以大多数情况下，针对标准的符合性测试工具，需要测试组自行开发或者修改已有的测试工具。如果需要开发测试工具，则必须执行一个严格的开发流程，确保测试工具本身的正确性和有效性。

        ③确定用例文件：对于测试标准并不包含测试用例的，测试组需要根据标准规定的格式定义各种测试用例，当然应该包含正常的和异常的测试用例。

        ④执行用例文件：确定了相应的测试工具和测试用例后，就可以执行测试并记录测试执行的结果。

        ⑤分析测试结果：“标准符合性”顾名思义应该就有一个测试结果基准库，通常情况下，它规定了输入与输出的对应关系，标准符合性的测试过程就是将测试用例（被测产品）的输入输出与基准库定义的输入输出相比较，从而对与标准不一致的输入输出进行统计分析，确定测试结果以及被测产品对标准的符合程度。

        在测试结果的分析与评价上主要有两种形式：一种认为要全部符合标准才算通过，即Yes or No方式；一种则通过测试符合标准的程度来判定，如认为80%以上的符合率即为基本符合标准。

        正是信息技术的深入发展，及相关应用间方便快捷地进行通信和数据交换的迫切需要，使得信息技术标准化和标准符合性测试的重要性日益凸现。

        在实际应用中，根据不同的层面，对标准的分类有多种方式，这里仅从信息技术不同标准的内容划分为主要的四类，并就相应常用的测试原理进行了阐述。

        标准的价值在于应用。因此，如何准确高效地实施测试、衡量标准的应用是重要的环节。第三方测试机构代表国家对相关产品及相关设备进行评测的过程中，也是严格依据标准本身对产品进行标准符合性测试的，这必将进一步推动我国信息技术标准化建设更上新的台阶。

 

  测试工具

               物理线缆测试仪

               常见的测试项目主要有线缆长度、衰减、阻抗、串扰、反射和噪声等。某些线缆测试仪还可以定位线缆路由，即由线缆测试仪将一系列音频信号输入到线缆中，并用一个小的附属设备（充当音频放大器）在30～40cm处监听信号，这样即可探测到地板下或隔板下的线缆路由情况。此外，还可以使用附属信号发生器测试引起的分配情况并检测布线故障（如线缆折断、短路或线对反转等）。在使用线缆测试仪时，必须让其工作在要求的频率范围内，因为像串扰、衰减等参数都直接与信号频率有关。例如，对高速数据传输技术（如快速以太网或ATM）来说，线缆测试的频率范围是1～100MHz，在TSB67（电信系统公告牌67，1995年9月）规范中详细描述了线缆测试方法及相应的精度需求，还定义了两个频率精度等级（I级和II级），其中Ⅱ级测试仪的精度比I级测试仪高。任何价格昂贵的线缆测试仪都必须遵照《TSB67 Ⅱ级规范》，当然，在某些特殊场合下进行网络故障检测和修复，有TSB67 I级线缆测试仪就足够了。有很多优秀的物理线路测试工具，如美国Agilent公司的线缆认证测试工具WireScope 155和FLUKE公司的DSP-4100等。

               网络运行模拟工具

               模拟工具是指按照指定网络基准或网络负载模式，以指定速率向所连网络发送指定大小的数据包，从而模拟出所需的网络流量状况，进而再现运行网络真实的环境。

               协议分析仪

               协议分析仪是定位和排除故障的关键工具，可以捕获网络上的数据报或数据帧。一个数据包或数据帧主要包含三方面信息：源地址和目的地址、数据、控制位。捕获的数据包存放在磁盘缓冲区中，可以对各种协议进行进一步的解析。解析的程度可以不一样，可以进行简单的报文类型或报文地址解析，也可以进行复杂的解析，对数据部分进行分析，还原为指令代码，如文件打开、关闭等操作。协议分析仪可以监控网络的数据流量、连接数、处在网络连接中的目的端和源客户端的地址（MAC、IP、SPX）、数据包的大小分布、协议分布等，可以通过历史采样功能对网络参数进行采样，并通过直方图或饼图显示。网络维护人员用分析仪捕获数据包，查看数据包，解析数据包，由此获取信息，再分析这些信息，检查网络问题。网络协议分析仪还可以主动地产生大量的数据包施加到网络上，分析网络的响应或对网络系统进行负载测试。协议分析仪有许多不同的测试模块，最简单的测试系统就是安装在PC机（要配置相应的LAN和WAN接口）上的软件系统，而高性能的协议分析仪，一般都采用专用的硬件设备和基于专家系统的高性能分析软件。究竟选用何种协议分析仪，应取决于待测网络的规模、复杂性和拓扑结构等因素。使用得较多协议分析仪有NAI公司的Sniffer、FLUKE公司的OptiView、HP公司的Internet Advisor（网络专家系统）、WG公司的Domino系列、免费网络协议分析软件Ethereal等。

               专用网络测试设备

               专用的软硬件结合的测试设备，能够对网络设备、网络子网以及整个网络系统提供综合测试，具有典型的三大功能：数据捕获、负载产生和智能分析。常见的有Spirent公司的SmartBits 6000、IXIA公司的IXIA 1600等。下面简单介绍一下SmartBits，该产品是数据通信领域广泛认同的，能够对网络及设备进行性能测试和评估分析的标准测量仪表，为进行10/100/1000M以太网、ATM、POS、光纤通道、帧中继网络和网络设备的高端口密度测试提供了行业标准。SmartBits提供了测试xDSL、电缆调制解调器、IPQoS、VoIP、MPLS、IP多播、TCP/IP、IPv6、路由、SAN和VPN的测试应用，可以测试、仿真、分析、开发和验证网络基础设施并查找故障，从网络最初的设计到对最终网络的测试，SmartBits提供了产品生命周期各个阶段的分析解决方案。SmartBits 6000在一个机架中最多可支持96个10/100 Mbps以太网端口、24个千兆以太网端口、6个万兆以太网端口、24个光纤通道端口、24个POS端口或上述端口的任意组合，并可通过使用SmartBits多机扩展功能，将多达512台设备同步连接起来。

               网络协议的一致性测试工具

               对于网络协议的一致性测试，一般有专门的测试工具来支持，比如说对ISDN、ATM、ADSL、帧中继等的测试都有专门的测试仪。

               网络应用分析测试工具

               以应用性能分析为主要目的的网络性能测试软件，如Compuware公司的Application Vantage应用产品包，从服务器、网络到客户端。提供强大的故障定位和解决方案，以快速定位和解决问题。

  LoadRunner

        LoadRunner是软件测试工具，用于评估系统在不同压力下的性能状况，提供负载生成、虚拟用户创建、测试控制、测试分析等功能。

 

软件配置

        软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读和人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项。

 

 

生命周期

        IT服务生命周期由规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision）5个阶段组成，简称“PIOIS”。

        （1）规划设计：从客户业务战略出发，以需求为中心，参照ITSS对IT服务进行全面系统的战略规划和设计，为IT服务的部署实施做好准备，以确保提供满足客户需求的IT服务。

        （2）部署实施：在规划设计基础上，依据ITSS建立管理体系、部署专用工具及服务解决方案。

        （3）服务运营：根据IT服务部署情况，依据ITSS，采用过程方法，全面管理基础设施、服务流程、人员和业务连续性，实现业务运营与IT服务运营的全面融合。

        （4）持续改进：根据IT服务运营的实际情况，定期评审IT服务满足业务运营的情况，以及IT服务本身存在的缺陷，提出改进策略和方案，并对IT服务进行重新规划设计和部署实施，以提高IT服务质量。

        （5）监督管理：本阶段主要依据ITSS对IT服务质量进行评价，并对IT服务供方的服务过程、交付结果实施监督和绩效评估。

 

系统故障

        系统故障是指硬件故障、软件（如DBMS、OS或应用程序）漏洞的影响，导致丢失了内存中的信息，影响正在执行的事务，但未破坏存储在外存上的信息。这种情况称为故障-停止假设（fail-stop assumption）。

        系统故障中止了事务的执行过程，破坏了事务的原子性，由于缓冲区中的内容可能部分已写入数据库，系统重启后数据库可能处于不一致状态。

  软件系统

        网络系统软件包括网络操作系统和网络协议等。网络操作系统是指能够控制和管理网络资源的软件，是由多个系统软件组成，在基本系统上有多种配置和选项可供选择，使得用户可根据不同的需要和设备构成最佳组合的互联网络操作系统。网络协议是保证网络中两台设备之间正确传送数据的约定。

  检验

        检验（检查）包括测量、检查和测试等活动，目的是确定项目成果是否与要求相一致。检验可以在任何管理层次中开展，例如，一个单项活动的结果和整个项目的最后成果都可以检验。检验有各种名称，如复查、产品复查、审查及评审等。

        检查表（核对表）是常用的检验技术，检查表通常是由详细的条目组成的，用于检查和核对一系列必须采取的步骤是否已经实施的结构化工具，其具体内容因应用的不同而不同。检查表是一种有条理的工具，可简单可烦琐，语言表达形式可以是命令式，也可以是询问式。

        例如，下表是一个确认测试工具属性的检查表例子。

         

        一个确认测试工具属性的检查表例子