软件项目测试方案建议书

软件项目测试方案建议书

I

目录

1. 项目测试方案建议书 ........................................................................................................ 3

1.1.

测试方案 .................................................................................................................. 3 1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.1.5. 1.1.6. 1.1.7. 1.1.8. 1.1.9.

总体测试策略 .............................................................................................. 3 总体测试方案 .............................................................................................. 4 单元测试方案 ............................................................................................ 42 集成测试方案 ............................................................................................ 54 系统测试方案 ............................................................................................ 56 测试组织 ..................................................................................................... 73 测试工具 ..................................................................................................... 78 自动化测试 ................................................................................................ 83 软件测试知识库 ....................................................................................... 90

1.1.10. 实施测试 ..................................................................................................... 93

II 1. 项目测试方案建议书

1.1. 测试方案

1.1.1. 总体测试策略

软件测试是保证软件质量的重要手段，是软件质量的最后把关环节，制定一个好的策略，可以提高软件质量、提高软件测试效率、缩短工期。

本项目测试的总体策略是尽早测试、全面测试、全过程测试。

1. 尽早测试

“尽早测试”包含两方面的含义：第一，测试人员早期参与软件项目，及时开展测试的准备工作，包括编写测试计划、制定测试方案以及准备测试用例；第二，尽早的开展测试执行工作，一旦单元编码完成就应该及时开展单元测试，一旦模块被集成成为相对独立的子系统，便可以开展子系统集成测试，一旦有基线版本提交，便可以开展系统测试工作。

由于及早地开展测试准备工作，测试人员能够于早期了解测试的难度、预测测试的风险，从而有效提高测试效率，规避测试风险。由于及早地开展测试执行工作，测试人员尽早地发现软件缺陷，大大降低BUG修复成本。

2. 全面测试

软件是程序、数据和文档的集合，那么对软件进行测试，就不仅仅是对程序的测试，还应包括软件“副产品”的“全面测试”。需求文档、设计文档作为软件的阶段性产品，直接影响到软件的质量。阶段产品质量是软件质量的量的积累，不能把握这些阶段产品的质量，将导致最终软件质量的不可控。

“全面测试”包含两层含义：第一，对软件的所有产品进行全面的测试，包括需求、设计文档，代码，用户文档等等。第二，软件开发及测试人员（有时包括用户）全面地参与到测试工作中，例如对需求的验证和确认活动，就需要开发、测试及用户的全面参与，因为测试活动并不仅仅是保证软件运行正确，同时还要保证软件满足用户的需求。

3 “全面测试”有助于全方位把握软件质量，尽最大可能地排除造成软件质量问题的因素，从而保证软件满足质量需求。

3. 全过程测试

软件开发与软件测试是紧密结合的，软件开发和测试过程会彼此影响，这就要求测试人员对开发和测试的全过程进行充分的关注。

“全过程测试”包含两层含义：第一，测试人员要充分关注开发过程，对开发过程的各种变化及时做出响应。例如开发进度的调整可能会引起测试进度及测试策略的调整，需求的变更会影响到测试的执行等等。第二，测试人员要对测试的全过程进行全程的跟踪，例如建立完善的度量与分析机制，通过对自身过程的度量，及时了解过程信息，调整测试策略。

“全过程测试”有助于及时应对项目变化，降低测试风险。同时对测试过程的度量与分析也有助于把握测试过程，调整测试策略，便于测试过程的改进。

1.1.2. 总体测试方案

1.1.2.1. 测试蓝图

软件测试是一个三维空间，包括测试阶段、测试类型和测试方法。

测试阶段验收测试系统测试集成测试单元测试设计评审需求评审静态质量分析编程规则检查用户界面测试安装/卸载测试功能测试回归测试等等……白盒测试黑盒测试动态测试静态测试主动测试被动测试代码覆盖测试性能测试兼容性测试压力测试冒烟测试测试类型测试方法

4 1.1.2.2. 测试模型设计

软件生命周期（SDLC，Systems Development Life Cycle）是指软件从概念形成开始，经过开发、使用和维护，直到最终被废弃的整个过程。软件生命周期可分为制定计划、需求分析定义、软件设计、程序编码、软件测试、软件运行、软件维护和软件停用8个阶段。

生命周期方法从时间上对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务，前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的实现细节。各阶段分工协作，从而降低开发工作的难度，便于科学组织与管理，保证了产品的质量，提高了软件的可维护性。

软件开发模型（Software Development Model）是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

软件测试与软件开发有密不可分的关系。

用户需求需求分析说明书概要设计说明书详细设计说明书源程序代码单元测试集成测试系统测试用户测试 从软件测试与软件开发各阶段的关系来看，软件测试在软件开发阶段具有如下作用：项目规划阶段，负责从单元测试到系统测试的整个测试阶段的规划；需求分析阶段，确定需求测试分析、系统测试计划的制定，评审后成为管理测试的依据；详细设计和概要设计阶段，确保集成测试计划和单元测试计划的完成；编码阶段，由开发人员进行自己负责部分的测试代码，在项目较大时由专人进行编码阶段的测试任务；测试阶段（单元、集成、系统测试），依据测试代码进行测试，并提交相应的测试状态报告和测试结束报告。

5 可以看出，测试过程和开发过程贯穿软件过程的整个生命周期，它们相辅相成、相互依赖。对于不同的软件系统，可以采用不同的开发方法或模型，也可以采用不同的测试方法或模型。测试模型用于指导测试实践，主要包括V模型、W模型、H模型、X模型等。

针对本项目的开发特点（系统复杂、开发周期短），我们在版本迭代层面采用H测试模型，在版本内部开发层面采用W测试模型。测试模型设计如下图：

图：版本迭代测试

开发过程用户需求V&V用户需求用户测试计划、设计需求分析与系统设计V&V需求分析与系统设计系统测试计划、设计缺陷修正交付缺陷修正用户测试用户测试方案修订实施系统测试系统测试方案修订集成测试计划、设计详细设计V&V详细设计单元测试计划、设计集成缺陷修正集成测试测试过程下一迭代过程概要设计V&V概要设计集成测试方案修订编码缺陷修正代码审查单元测试

图：版本内开发测试模型

模型要点：

 测试人员参与需求、设计评审，同时编写相关测试计划及方案；  单元和单元集成测试，与编码同时进行；

6  采用迭代测试的方法，尽早启动测试工作，任一业务模块开发完成后，即进行模块功能性测试、模块集成测试、相关非功能性测试，如果子系统就绪（关键功能完成），即进行子系统的功能性测试、集成测试和相关非功能性测试，不断迭代，直到全系统集成完毕，进行全业务测试。

 用户验收测试提前进行工作准备，在系统版本提交给用户验收测试时， 用户端的准备工作需完成，用户验收测试即进入测试执行。

1.1.2.3. 测试过程的设计

测试过程，包括测试阶段的设计和测试过程的管理。

《用户需求》《项目工作说明书》《项目总体计划》《项目开发计划》《需求规格说明书》《概要设计说明书》《详细设计说明书》《系统测试计划、方案》《集成测试计划、方案》《单元测试计划、方案》《需求规格说明书》《用户测试计划、方案》《实验室环境测试报告》《用户环境测试报告》《试运行验收报告》输入测试启动测试计划方案设计测试实施缺陷管理验收测试被动测试缺陷管理测试评估测试结束“测试需求”“测试组织”“测试环境方案”输出“总体测试计划”“用户测试计划、方案”“系统测试计划、方案”“集成测试计划、方案”“单元测试计划、方案”“测试环境检查确认记录”“测试环境检查确认记录”“测试说明”“测试说明”“测试执行记录”“测试执行记录”“缺陷跟踪记录”“缺陷跟踪记录”“实验室环境各阶段测试报告”“用户环境测试报告”“用户测试反馈单”“缺陷跟踪记录”“软件系统验收申请（软件系统测试情况）”及相关资料“软件系统终验申请（软件系统测试情况）”及相关资料验收测试报告结论主要工作测试需求分析需求评审明确组织机构设计评审测试环境方案准备编写各阶段测试计划制定总体测试计划编写用户测试计划、方案设计各阶段测试方案(含用例)准备测试环境准备测试数据单元测试集成测试系统测试准备测试环境准备测试数据用户测试用户环境系统测试、压力测试… 被动测试缺陷管理测试结果分析测试结果评审资源管理、进度管理、风险管理如图所示，与软件开发生命周期相对应，我们将测试工作划分为六个阶段：

1. 项目启动阶段：测试工作同时启动

测试主要工作包括测试需求分析、明确组织机构、测试环境方案准备和制定总体测试计划。

 测试需求分析，指根据《业务需求》、《项目工作说明书》，分析测试需求；明确测试目标，制定工作策略；确认测试范围，将测试工作进行分类，如单元测试、集成测试、系统测试和用户测试等，并确定每类测试的对象，包括需要测试的特性及不需要测试的特性。  明确组织机构，指明确组织架构和职能分工，依据历史及经验数

7 据估计测试工作量，确定测试的人力需求。

 准备测试环境方案，指初步确定测试环境所需的软、硬件设备，主要考虑内容：主机环境、操作系统环境、数据库平台、网络环境、应用平台、其他支撑环境如测试数据等。

 制定总体测试计划，指根据《项目总体计划》、《项目开发计划》，确定测试的进度安排，明确各个阶段的主要工作和产出物。总体测试计划内容涵盖阶段划分、测试方法、工作流程、人员分工、进度安排等内容，制定完成须经招标人确认。

 编写用户测试方案，指根据《测试需求》、《总体测试计划》，编写用户测试计划，设计测试方案。

2. 需求分析和系统设计阶段：需求和设计评审、测试计划、方案设计 测试主要工作是参与需求和设计评审、制定测试计划和设计测试方案。

 需求评审，指依据需求评审规范，项目的分析设计和测试人员参与对《需求规格说明书》的审查工作，并协助招标人完成评审确认。  设计评审，指对现有的设计所做的正式的和独立的检查，用于找出和补救可能影响稳定性、可靠性、可维护性等对需求的理解程度和设计中的不足，并提出可能的改进。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示。

 制定测试计划，指根据《需求规格说明书》编写系统测试计划，根据《概要设计说明书》编写集成测试计划，根据《详细设计说明书》编写单元测试计划。测试计划内容涵盖测试范围、测试方法、测试完成准则、测试任务、测试问题跟踪策略、测试资源需求、测试风险分析和测试输出等。

 设计测试方案，指根据《测试计划》，编写各阶段测试方案，设计测试用例。测试方案内容涵盖测试范围与主要内容、测试环境、数据要求、测试方法与工具、完成准则和测试用例设计等，设计完成须经招标人确认。

3. 编码实现和实验室测试阶段：测试实施、缺陷管理 测试主要工作是执行测试和进行缺陷管理。

8  准备测试环境，指根据测试环境方案搭建、调试测试环境。  准备测试数据，别写测试用例，根据业务场景，分析业务需求，保证测试用例全面覆盖业务。

 执行测试，指根据《测试计划》、《测试方案》，严格按照各阶段测试流程进行测试。测试类型包括实验室环境完成的单元测试、集成测试、系统测试（含功能测试、性能测试、安全测试、压力测试、模拟灾备与恢复测试）。

 缺陷管理，跟踪测试人员发现的软件缺陷，当开发人员对相关的缺陷进行修改完善后，重新由测试人员进行测试。

 提交报告，指按照产出物模板，各阶段测试通过后，提交相应的测试报告。

4. 招标人测试环境阶段：用户测试

实验室环境所有测试类型的《软件测试报告》经招标人确认，进入招标人测试环境的测试。测试主要工作是进行用户测试、申请初验。

 准备测试环境，指测试环境所需设备由招标人提供，我们负责安装部署。

 准备测试数据，编写测试用例。

 执行测试，指根据《测试计划》、《测试方案》，严格按照测试流程进行测试。测试类型包括用户环境完成的用户测试（功能测试）、系统测试（性能测试）、压力测试、安全测试、灾备与恢复测试。  缺陷管理，指记录用户测试结果，对确认的测试问题跟踪调试。  申请初验，指提交软件系统验收申请。 5. 试运行、推广阶段：被动测试、缺陷管理

试运行是指完成软件测试后，移植到生产环境下的运行。主要目的是：检验软件的各种功能是否完善；检验软件的可推广性和可移植性；检验软件在用户生产网络环境下的性能指标。

试运行工作完成并通过质量评审后，软件各项功能基本完善，运行相对稳定，能够满足更大范围用户的应用需求，项目进入推广实施阶段。

试运行和推广实施阶段的主要工作是被动测试和缺陷管理，测试人员须参加。

9  试运行与推广测试：负责收集软件试运行过程中发现的问题和用户的二次需求，修改完善应用软件功能，优化系统性能。

 缺陷管理：承担发现问题、提交问题、修改问题的责任，按照总局统一的问题处理流程执行。

6. 项目验收阶段：测试结果评审、申请终验

 测试结果评审：对各阶段测试测试报告组织评审，并填写测试结论。

 申请终验：依据测试评审意见申请终验。 7. 贯穿项目始终：测试管理

主要工作是的是资源管理、进度管理和风险管理。

 资源管理，主要指测试人员和环境管理，负责测试人员的培训和及时到位，制定考勤制度、请销假制度，进行人员的日常考勤。负责测试所需工作场地、个人办公用设备的落实和日常管理。

 进度管理，指负责测试进度的控制，制定例会制度并组织实施，每日形成工作简报提交项目负责人审核。

 风险管理，通过在软件测试过程中进行风险识别、风险分析、风险计划、风险控制和风险跟踪，能够进一步提高软件质量。

1.1.2.3.1. 关键测试工作 1.1.2.3.1.1.

需求评审

由于软件系统的复杂性，在需求分析阶段可能存在着开发人员对业务需求理解不全面、不准确的情况。在这种情况下，如果不通过需求评审进行相关的质量控制，往往造成开发结果与用户需求不一致的情况。

需求评审针对《需求规格说明书》。主要评审其表述的清晰性、完整性、依从性、一致性、可行性、可管理性等。通常评审的结果都包括了一些修改意见，待修改完成后再经评审，才可进入设计阶段。

10 设计评审，指对现有的设计所做的正式和独立的检查，用于找出和补救可能影响稳定性、可靠性、可维护性等对需求的理解程度和设计中的不足，并提出可能的改进。软件设计一般可以分为系统设计和详细设计。

无论是需求评审还是设计评审，都需要测试人员参加。在需求分析和系统设计阶段，测试人员的关键工作是：各阶段测试计划、方案的编制，以及与《需求规格说明书》、《概要设计》和《详细设计》的相互验证与确认。

1.1.2.3.1.2. 单元测试

单元测试（单元集成测试），是在编码阶段针对每个程序单元而进行的测试。单元测试用于判断一小段代码在某个特定条件（或者场景）下某个特定函数的行为，主要测试软件设计的最小单元（模块）在语法、格式和逻辑等方面是否错误，是否符合功能、性能等需求。

1. 单元测试的目的

单元测试是对软件设计的最小单位—模块或组件等测试。单元测试的依据是详细设计描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。

（1）凡是进入基线库的代码都要经过单元测试

（2）经过单元测试的代码语句覆盖率要达到公司规定的要求 （3）通过单元测试及早发现缺陷，提高软件质量，控制项目进度 （4）力求代码达到：正确性、清晰性、规范性、一致性、高效性等 （5）正确性是指代码逻辑必须正确，能够实现预期的功能 （6）清晰性是指代码必须简明、易懂，注释准确没有歧义 （7）规范性是指代码必须符合本部或项目组制定的编码规范

（8）一致性是指代码必须在命名上（如：相同功能的变量尽量采用相同的标示符）、风格上都保持统一

（9）高效性是指代码不但要满足以上性质，而且需要尽可能降低代码的执行时间

2. 单元测试的原则

11 （1）单元测试遵循《软件单元测试计划》和《软件单元测试说明》文档，根据详细设计编写单元测试用例，而不能根据代码编写单元测试用例

（2）单元测试执行前先检查单元测试入口条件是否全部满足

（3）单元测试必须满足一定的覆盖率，重要的接口函数必须做单元测试 （4）在修改代码后修改测试用例，将单元测试用例进行回归测试 （5）单元测试必须满足预定的出口条件才能结束

（6）在单元测试完成后，记录《单元测试报告》，分析问题的种类和原因 （7）单元测试始终在配置管理控制下进行，问题修改须符合变动规程要求 （8）单元测试文档、测试用例、测试记录和被测程序等齐全，符合规范

3. 本项目单元测试的任务

本项目单元测试的任务：把已实现的单元进行测试，以发现代码单元本身的功能错误。

本项目单元测试的方法：“黑盒测试”或规格说明测试，验证单元外观上的可观察的行为；“白盒测试”或结构测试，验证单元的内部实现。

通常，单元测试在编码阶段，由开发人员进行。我们将对单元测试流程进行规范，制订一定的覆盖率指标和质量目标，来指导单元测试设计和执行。

1.1.2.3.1.3. 集成测试

集成测试，是在单元测试的基础上，将所有的软件单元按照《概要设计规格说明》的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。

1. 集成测试的目的

集成测试的目的是发现模块或子系统之间的接口问题，确保各部分组合在一起后能够按既定意图协作运行，并确保增量的行为正确。

2. 集成测试的原则

（1）所有公共接口都要被测试到 （2）关键模块必须进行充分的测试 （3）集成测试应当按一定的层次进行

（4）集成测试的策略选择应当综合考虑质量、成本和进度之间的关系

12 （5）集成测试应当尽早开始，并以总体设计为基础

（6）在模块与接口的划分上，测试人员应和开发人员进行充分的沟通 （7）当接口发生修改时，涉及的相关接口必须进行再测试 （8）测试执行结果应当如实记录

3. 本项目集成测试的任务

本项目集成测试的任务：确认集成体能够正确地满足所规定的要求，集成后的各软件单元之间能够正确地相互作用和传递数据。

本项目集成测试的方法：主要为“黑盒测试”，适当辅以“白盒测试”。

1.1.2.3.1.4. 系统测试

系统测试，是将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明为依据进行的测试。它是检验系统是否确实能提供系统方案中指定功能的有效方法。

1. 系统测试的目的

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

2. 系统测试的原则

（1）设计测试方案时。不仅要包括确定的输入数据，而且应包括从系统功能出发预期的测试结果

（2）测试用例不仅要包括合理、有效的输入数据，还要包括无效或不合理的数据

（3）不仅检验程序是否做了该做的事，还要检查程序是否做了不该做的事 （4）保留测试用例，作为软件文档的组成部分

3. 本项目系统测试的任务

尽可能彻底地检查出程序中的缺陷，提高软件系统的可靠性。系统测试的主要内容包括：

（1）功能测试：即对系统的各项功能进行验证，根据功能测试用例，逐项测试，检查本项目是否达到招标人要求的功能。由于正确性是软件最重要的质量因素，所以功能测试必不可少。

13 （2）性能测试：即通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，一是为了检验性能指标是否满足招标人需求，二是为了得到某些性能指标供相关人员参考。

（3）压力测试：即模拟工作负荷对软件进行破坏性测试和强度稳定性测试，如大数据量、大量并发用户连接等，测试软件在一定硬件环境下的性能指标。本项目压力测试内容包括：云支撑平台、大数据平台、动态展示等10类业务，以便有效发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等，确认系统是否具有良好的容错能力和可恢复能力，各类业务响应时间满足软件性能要求。

（4）安全测试：即采用静态和动态检测工具，对软件进行全面检测，检查软件安全防范能力，如系统权限设置有效性、防范非法入侵的能力、数据备份和恢复能力等，以发现软件在设计和编码中的错误、疏忽和其它缺陷。

（5）灾备与恢复测试：即进行模拟总局（北京和南海）部署模式下的灾备与恢复测试，并实施生产系统和灾备系统的实时切换，保证关键业务的业务连续性。

（6）用户界面测试：重点是测试软件系统的易用性和视觉效果等。 （7）安装/卸载测试：即确保软件在正常情况和异常情况下，使用各安装/卸载方法，验证安装/卸载过程中可能出现的各种各样的问题，完善保证安装/卸载后系统能够正确运行。

（8）兼容性测试：即保证系统在指定的硬件平台上、不同的操作系统或应用软件上，能正常的运行的测试，包括在同一软件平台的不同版本上正常运行；能与相关的其他软件或系统的“和平共处”。

（9）升级测试：确保版本升级可以在不同情况下成功完成以及软件运作正常的测试。

（10）文档测试：关注系统提供的安装部署文档，用户使用手册等的正确性和可操作性。

1.1.2.3.1.5. 验收测试

14 验收测试，在本项目中指用户环境测试，是以用户为主的测试，由用户参加设计测试用例，使用用户接口输入测试数据，并分析测试的输出结果，一般使用生产中的实际数据进行测试。

1. 验收测试的目的

验收测试是部署软件之前的最后一个测试操作，验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

2. 验收测试的任务

进行文档资料的审查验收、功能测试、性能测试、压力测试、安全测试和模拟灾备与恢复测试。

功能测试：即标书中的用户测试，对系统各项功能进行验证，根据功能测试用例，逐项测试，检查本项目是否达到招标人要求的功能。

性能测试：即标书中的系统测试，包括健壮性测试、性能测试等，通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

压力测试：即对本项目的各项性能指标进行大规模压力测试。

安全测试：即采用静态和动态检测工具，对软件进行全面检测，检查软件安全防范能力，以发现软件在设计和编码中的错误、疏忽和其它缺陷。

灾备与恢复测试：即进行模拟总局（北京和南海）部署模式下的灾备与恢复测试，并实施生产系统和灾备系统的实时切换，保证关键业务的业务连续性。

1.1.2.4. 关键管理工作

软件测试过程是一个从需求分析启动开始到系统上线贯穿项目整个生命周期的长期过程。在软件测试过程中，牵涉到项目管理的全部管理过程，这里重点说明质量保证、配置管理、进度管理、风险管理等过程。 过程管理领域 质量保证 1. 管理方法 评审各个阶段产出物，发现存在的质量缺陷，给出纠正措施，并跟踪缺陷修订状态，直至缺陷被纠正。 2. 审计测试各个过程，及时发现过程管理存在的问题，给出纠正措施，并跟踪直至问题被纠正。 15 3. 质量度量：度量软件缺陷，通过统计分析的手段，发现质量与预期的偏离度，及早发现问题并跟踪解决。 配置管理 1. 2. 3. 4. 批 进度管理 1. 每个测试活动都需要制定详细的计划，最细粒度的任所有测试相关的配置项必须纳入配置管理； 及时将配置项提交到配置库； 评审通过后的配置项应纳入基线管理； 对于已纳入基线的配置项不得随意变更，变更需要审务时间不得超过5个工作日，计划中应预留一定的缓冲时间。 2. 测试经理跟踪每个测试活动的进展情况，尤其是关键路径上的测试活动，及早发现进度的偏差。 3. 在发现进度偏差或预计产生偏差的情况下，及时采取措施进行赶工。 4. 如果发现关键里程碑点的进度滞后，应及时报告项目领导小组，必要时需要进行进度变更 风险管理 1. 在测试活动进行的早期，对可能发生的风险进行预估并制定规避措施； 2. 定期进行风险的跟踪和监控，发现风险的苗头，及早采取措施，把影响降低到最小； 3. 影响程度高的风险，应纳入项目级甚至项目领导小组级别的监控范围。 1.1.2.4.1. 缺陷管理

测试缺陷是指在本项目所有测试过程中发现的缺陷，我们保证对测试错误和缺陷进行及时修正、补充。

1. 缺陷分类 缺陷分类 16 描述 需求问题 设计问题 程序错误 接口错误 UI错误 性能 数据问题 系统错误 发生的BUG是因为需求的原因引起的 发生的BUG是因为设计的原因引起的 该BUG是由于编程错误发生的 属于系统内外接口的问题 属于用户界面操作接口的问题 属于系统整体性能方面的问题 由于数据的原因引起的问题 是由于系统本身、版本问题、集成问题等引起的测试BUG 2. 缺陷等级定义

缺陷的严重程度对以上所述的缺陷类型都是适合的，缺陷的严重程度反应的是对缺陷的发现对象可能造成的影响或后果来定义的。

下表中对测试缺陷的严重程度进行分级的定义： 严重程度级别 缺陷 性质 致命 缺陷 定义标准 表象与示例 导致对被描述的主要对象直接影响测试继续执行的一级(A) 的理解错误、不可行、不能错误。必须在测试前修复，运转、对业务和整个系统可否则测试无法继续进行。例能造成重大损失或损害。 如：启动失败，不能运行等。 对被描述的部分对象的理不影响其他测试案例的继解或实现错误，部分的系统续执行或与功能规格不符二级(B) 严重 缺陷 或模块不可行或不能运转的错误，有可能给客户造成或部分系统和模块缺失，对损失和风险的错误，必须在整个系统有重大影响或可测试完成前修复。如计算错能造成部分的损失和损害。 误等。 三级(C) 一般 缺陷 微小 缺陷 影响客户服务的错误。对系如报表格式不完全正确，提统功能影响比较小的错误。 示信息不对，画面布局文字有错误等。 基本不影响系统的运行和如提示信息不准确，画面布功能的实现。但是与标准、局位置不准确。 规范和定义不一致。 四级(D) 17 五级(E) 建议 缺陷 不在标准、规范、范围的定与规格符合，可以根据自己义和约束之内，但是从提出的时间来决定是否完成。 者来看是需要完善的建议。 3. 缺陷跟踪流程

<缺陷跟踪流程>输入配置管理员开始可测试的系统版本发放测试版本对系统进行测试修复缺陷是测试人员开发人员输出提交缺陷确认缺陷重新打开缺陷否是是否缺陷否拒绝缺陷关闭缺陷验证缺陷编写缺陷分析报告缺陷分析报告结束 如图所示，缺陷跟踪流程分为：

（1） 配置管理员将可测试的系统版本发放给测试人员，由测试人员进行测试。

（2） 测试人员发现系统缺陷，将缺陷提交给系统开发人员进行确认。 （3） 如果开发人员确认后，不是系统缺陷，则反馈给测试人员进行再次测试。测试人员测试后若确认不是缺陷，则直接关闭缺陷。如果仍确认为缺

18 陷，则再次提交给开发人员进行修改。

（4） 当开发人员确认为系统缺陷，则对其进行修复，并将修复后的缺陷提交测试人员进行重新测试。

（5） 测试人员测试经过修复的系统缺陷，如确认已经修复，则直接关闭缺陷；如果测试未通过，则需要开发人员再次修复。

（6） 缺陷关闭后，测试人员将编写系统缺陷分析报告，对系统缺陷进行全面的分析。 4. 缺陷度量

在软件开发和测试过程中实施缺陷的度量与分析，对于提高软件开发和测试效率，预防缺陷发生，保证软件产品质量有着十分重要的作用。缺陷分析是将软件开发各个阶段产生的缺陷信息进行分类和汇总统计，计算分析指标，编写分析报告的活动。通过软件缺陷分析可以发现各种类型缺陷发生的概率，掌握缺陷集中的区域、明确缺陷发展趋势、挖掘缺陷产生的根本原因，便于有针对性地提出遏制缺陷发生的措施、降低缺陷数量。

本项目的测试缺陷度量计划度量三个方面的信息：缺陷代码比率、缺陷分布、缺陷收敛度

 缺陷代码率

缺陷代码比率是指每千行源代码发现的缺陷数量。 度量公式：缺陷数/代码行数。

缺陷代码率需要度量不同子系统、不同模块的数据，通过比对分析，发现缺陷比较集中的模块，进行重点分析。一般来说，在前期测试（单元测试、模块集成测试）中，缺陷代码率高的模块，可能是开发人员经验欠缺的表现，而对于缺陷代码率低的模块，则可能是测试不充分的表现。都需要进行特别的关注。测试的后期（功能测试），缺陷代码率高，则可能是前期的测试不充分，缺陷没有在早期被发现。

 缺陷分布

缺陷分布度量是指缺陷在各个域的分布情况，域可以是模块、子系统、测试人员、开发人员、版本等。不同域的缺陷分布都需要进行度量。缺陷分布一般以饼图的方式来表现。如：

19 6%13%14%17%24%税务登记税种认定申报征收发票发售发票验旧26%

 缺陷收敛度

缺陷收敛度是指随着时间的推移，缺陷状态及数量的变化趋势。以周为单位，统计分析不同缺陷状态的收敛情况，随着时间的推移，被关闭的缺陷应该逐渐增加，未关闭的缺陷逐渐减少，新发现的缺陷逐渐减少。缺陷收敛度一般以曲线的方式来表现。如：

350300250200150100500第1周第2周第3周第4周第5周第6周第7周第8周第9周

1.1.2.4.2. 配置管理

软件测试过程将产出大量的配置项，包括但不限于过程文档（如测试计划、测试方案、测试用例、测试结果记录、测试报告等）、程序代码（测试代码、测试脚本等）、数据（测试数据、测试数据生成脚本等）、缺陷记录。这些配置项必须满足配置管理的要求。包括配置项的命名、配置项的获取/提交、配置项的版本跟踪等。

20 关键的配置项需要进行评审，评审通过后应纳入基线库。纳入基线库的配置项不得随意变更，如必须变更，应报项目经理，由项目经理决定采用何种变更流程。

1.1.2.4.3. 进度管理

每个测试活动都需要在活动早期进行详细计划的制定，测试活动的计划要与项目的总体计划向匹配。计划中任务详细粒度不得超过5个工作日，并留有一定的缓冲时间，计划要得到相关人员的认可。

测试人员应以计划为指导，制定自己更详细的工作计划。测试组长、测试经理、项目经理对计划进行层层跟踪，及早发现进度的偏差。

当发现进度偏差时，相关人员要进行分析，找出偏差的原因和解决办法。通过组内、组间的资源调配，有时可以解决进度偏差问题，或者采用缓冲时间进行赶工。

当关键里程碑点的进度可能发生偏差时，要作为风险及时上报项目领导小组。必要时采取进度变更。

1.1.2.4.4. 风险管理

在测试活动启动早期，尽早进行风险的预估并制定规避措施。风险的预估要考虑风险可能发生的频率和风险发生后的影响程度，依此确定风险的等级并进行排序，等级高的风险，在风险跟踪时要重点关注。

在测试活动进行过程中，定期进行风险的跟踪和监控，发现风险的苗头，及早采取措施，把影响降低到最小。如果发现有重大影响的风险，并且发生的概率较大，应及时上报项目领导小组。

测试过程中，影响较大且概率较高的主要风险及规避措施： 风险名称 风险描述 规避措施 测试进度测试进度无法保障，进度加强进度控制，每中类型的测试活动，风险 滞后，影响上线时间 都制定详细的测试计划 21 测试质量风险 软件系统的问题没有被发现，大量问题在后期暴露甚至到上线后发现 尽早测试，全面测试。分解详细的测试活动，在软件开发早期能够及时发现存在缺陷，避免大量的问题带入到后期测试中 1.1.2.5. 测试方法/技术的选择 1.1.2.5.1. 基本测试方法

软件测试从是否关心软件内部结构和具体实现的角度划分，可分为白盒法和黑盒法，从是否执行程序的角度分，可分为静态测试和动态测试。

1. 白盒法

软件的白盒测试是对软件的过程性细节作细致的检查。这一方法是把测试对象看作一个打开的盒子或透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

软件人员使用白盒测试方法，主要想对程序模块进行检查：对程序模块的所有独立的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性等等。

但是对一个具有多重选择和循环嵌套的程序，独立的路径数目可能是天文数字。而且即使精确地实现了白盒测试，也不能断言测试过的程序完全正确。在测试阶段由于穷举测试不可行，就必须精心设计测试用例，从数量极大的可测试用例中精心地挑选少量的测试数据，使得采用这此测试数据能够达到最佳的测试效果，或者说它们能够高效率地把隐藏的错误尽可能多地揭露出来。

2. 黑盒法

黑盒测试（黑盒法）又称为数据驱动测试、基于规格的测试、输入输出测试或者功能测试。黑盒测试基于产品功能规格说明书，从用户的角度针对产品特定的功能和特性进行验证活动，确认每个功能是否得到完整实现，用户能否正常使用这些功能。

22 黑盒测试在不知道系统或组件内部结构的情况下进行，不考虑内部逻辑结构，着眼于程序外部结构，在软件接口处进行测试。黑盒测试主要有如下功能：

 检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测是否满足性能等特性的要求。

 检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件等）的完整性。  检测程序初始化和终止方面的错误。

就软件测试来讲，软件的黑盒测试意味着测试要根据软件的外部特性进行。也就是说，这种方法是把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试方法主要是为了发现：是否有不正确或遗漏了的功能？输入能否正确地接受？能否输出正确的结果？是否有数据结构错误或外部信息（例如数据文件）访问错误？性能上是否能够满足要求？是否有初始化或终止性错误？所以，用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，检查程序是否者能产生正确的输出。

3. 静态与动态测试

根据程序是否运行，测试可以为分静态测试和动态测试，早期将测试局限于对程序进行动态测试，可以看作是狭义测试概念，而现在将需求和设计的评审也纳入测试的范畴，可以看作是广义测试概念或现代测试概念。

 静态测试

静态测试是不通过执行程序而进行的测试，用于检查软件的表现和需求规格说明书是否一致。静态测试技术是单元测试中最重要的手段之一。静态测试包括对软件产品的需求和设计规格说明书的评审，对程序代码的复审等。静态分析的查错和分析功能是其他方法所不能替代的，可以采用人工检测和计算机辅助静态分析手段进行检测，但越来越多地采用工具进行自动化分析。

 动态测试

动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统行为、变量实时结果、内存、堆栈、线程以及测试覆盖率等各方面的信息，来

23 判断系统是否存在问题，或者通过有效的测试用例，对应的输入输出关系来分析被测程序的运行情况，来发现缺陷。动态测试的原则是要覆盖所有的功能点。

1.1.2.5.2. 基本测试类型

1. 静态质量分析

静态质量分析是指在不运行及编译下直接分析代码。通过定制检查规则来捕获代码错误，从而提高代码质量。编程规则检查通常使用的策略有代码走查，桌面检查，代码审查。

静态质量分析审查的内容：代码和设计的一致性；代码对标准的遵循、可读性；代码的逻辑表达的正确性；代码结构的合理性等。

2. 代码覆盖测试

代码覆盖测试是指在二进制代码中注入一些监视代码并运行以获得实时覆盖数据。覆盖测试是衡量测试质量的一个重要指标。

3. 功能测试

功能测试的目标是核实软件能否正确地接受、处理和检索数据以及业务规则是否正确实施。功能测试也叫黑盒测试或数据驱动测试，只需考虑各个功能，不需要考虑整个软件的内部结构及代码。

功能测试主要是根据软件规格说明书，来检查被测试的系统是否满足各方面功能的使用要求。对于功能测试，针对不同的应用系统，其测试内容的差异很大，但都可以归为界面、数据、操作、逻辑、接口等方面。

功能测试的内容如：

（1）程序安装、启动正常，有相应的提示框、错误提示等。 （2）每项功能符合实际要求。 （3）系统的界面清晰，美观。

（4）菜单、按钮操作正常，灵活，能处理一些异常操作。

（5）能接受正确的数据输入，对异常输入可以进行提示、容错处理等。 （6）数据的输出结果准确，格式清晰，可以保存和读取。 （7）功能逻辑清楚，符合使用者习惯。

（8）系统的各种状态按照业务流程而变化，并保持稳定。

24 （9）支持各种应用的环境。 （10）能配合多种硬件周边设备。

（11）软件升级后，能继续支持旧版本的数据。 （12）与外部应用系统的接口有效。

4. 性能测试

性能测试的目标：验证软件系统或构件对于用户及时性要求的符合程度；基于软件的性能表现分析系统的稳定性、可扩展性和高可用性等性能指标。

性能测试通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

5. 压力测试

压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试。

压力测试的检测内容包括：当容量超出时，服务器是否停机，事务是否会丢失，数据的完整性如何；服务器软件是否会给出“服务器不可用”的信息；当系统达到80%或90%时，系统某些功能是否会被停止。

6. 回归测试

回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。

在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。

7. 冒烟测试

冒烟测试的术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。

25 在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。冒烟测试的对象是每一个新编译的需要正式测试的软件版本。冒烟测试的目的是确认软件基本功能正常，可以进行后续的正式测试工作。

8. 用户界面测试

简称UI测试，测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字、图片组合是否完美，操作是否友好等等。

针对系统，可以从如下方面着手来进行用户界面测试： （1）导航测试：

导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。

（2）图形测试

系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。 （3）内容测试

内容测试用来检验系统提供信息的正确性、准确性和相关性。 （4）表格测试

需要验证表单等是否设置正确。 （5）整体界面测试

整体界面是指整个系统的页面结构设计，是给用户的一个整体感。

9. 安装/卸载测试

安装/卸载测试是测试软件系统能否正确地安装到各种所需的软、硬件配置中以及软件在安装完成后能否正确地反安装。

10. 兼容性测试

兼容性测试是指系统在指定的硬件平台上、不同的操作系统或应用软件上，能正常的运行的测试，包括在同一软件平台的不同版本上正常运行；能与相关的其他软件或系统的“和平共处”。

11. 升级测试

升级测试是确保版本升级可以在不同情况下成功完成以及软件运作正常的测试。

26 12. 安全性测试

安全性测试是指在测试软件系统中对程序的危险防止和危险处理进行的测试，以验证其是否有效。

安全性测试的基本方法包括： （1）功能验证

采用软件测试当中的黑盒测试方法，对涉及安全的软件功能，如：用户管理模块，权限管理模块，加密系统，认证系统等进行测试。

（2）漏洞扫描

安全漏洞扫描通常都是借助于特定的漏洞扫描器完成，漏洞扫描器是一种自动检测远程或本地主机安全性弱点的程序。

（3）模拟攻击实验

对于安全测试来说，模拟攻击测试是一组特殊的黑盒测试，以模拟攻击来验证软件或信息系统的安全防护能力。

（4）侦听技术

主要用于对网络加密的验证，在数据通信或数据交互过程，对数据进行截取分析的过程。

13. 灾备与恢复测试

灾备与恢复测试，是指进行模拟总局（北京和南海）和省局两级部署模式下的灾备与恢复测试，并实施生产系统和灾备系统的实时切换，保证关键业务的业务连续性。

1.1.2.5.3. 基本测试技术

自动化测试（automated test）是相对于手工测试（manual test）而存在的一个概念，由手工逐个的运行测试用例的操作过程被测试工具或系统自动执行的过程所代替，包括输入数据自动生成、结果的验证、自动发送测试报告等。

手工测试在某些方面存在局限性，例如：通过手工测试无法做到覆盖所有代码路径，也难以测定测试的覆盖率；通过手工测试很难捕捉到与时序、死锁、资源冲突、多线程等有关的错误；在系统负载、性能测试中，用手工测试完成大量数据或大量并发用户非常困难；在系统可靠性测试中，需要模拟系统运行几年、

27 十几年，以验证系统能否稳定运行，也是手工测试无法模拟的；在多数回归测试中，时间很紧，希望一天能完成成千上万个测试用例的执行，手工测试是无能为力的；测试可以发现错误，并不能表明程序的正确性，因为无法实现穷举测试。对一些关键程序，则需要考虑利用数学归纳法或谓词演算等进行正确性验证。

由于手工测试的局限性，软件测试借助测试工具成为必要。自动化测试采用类似于编译系统的方法对程序代码进行检查。其原理包括对代码进行分析、对测试过程的捕捉及回放、测试脚本技术和虚拟用户技术。自动化测试由计算机系统自动完成，执行速度快、永不疲劳，而且会严格按照脚本、指令进行，不会出错。正是这些特点，软件测试自动化可以弥补手工测试的不足，给软件测试带来不少益处。

自动化测试的优势很明显：

 缩短软件开发测试周期。对同样上千个测试用例，软件测试自动化工具

可以在很短时间内完成，还可以不间断运行，能不厌其烦的运行同样的测试用例十遍、一百遍。

 更高质量的产品。因为通过测试工具运行测试脚本，能保证百分之百的

完成测试，而且测试结果准确、可靠。

 软件测试过程更规范。自动化测试鼓励测试团队规范化整个测试过程，

包括开发的代码管理和代码包构建、标准的测试流程以及一致性的文档记录和更完善的度量。

 测试效率高，充分利用硬件资源。可以同时进行几个测试进程，能够把

大量测试个案分配到各台机器同时运行等。

 节省人力资源，降低测试成本。在回归测试时，需要验证大量稳定的旧

功能，而通过测试脚本和测试工具，只要一个人就可以了。

 增强测试的稳定性和可靠性。通过测试工具运行测试脚本，能保证百分

之百进行，而手工测试时，个别测试人员可能会把并没有执行的测试用例标记为已验证。

 提高软件测试的准确度和精确度，提高测试质量。软件测试自动化的结

果都是客观的、量化的，并且和预期结果或规格说明书中规定的标准进行数字化比对，任何差异都能发现，而且任何差异也不会被忽视。

28  手工不能做的事情，软件测试工具可以完成，例如负载测试、性能测试

等，手工很难进行，只有通过工具来完成。

1.1.2.5.4. 方法与技术的选择

根据上述分析，本项目的不同测试阶段推荐的测试类型如下表：

测试阶段需求评审设计评审单元测试集成测试系统测试验收测试测试类型静态质量分析代码覆盖测试功能测试性能测试压力测试回归测试冒烟测试用户界面测试兼容性测试安装/卸载测试升级测试安全性测试灾备与恢复测试

不同测试类型推荐的测试方法见下表：

测试方法白盒测试黑盒测试静态测试动态测试手工测试自动化测试测试类型静态质量分析代码覆盖测试功能测试性能测试压力测试回归测试冒烟测试用户界面测试兼容性测试安装/卸载测试升级测试安全性测试灾备与恢复测试

29 1.1.2.6. 用例设计方法 1.1.2.6.1. 需求分析

在本项目测试工作的各阶段，都需要测试用例的设计。 测试用例的用途包括： （1）执行测试，发现缺陷； （2）重复执行测试，重现缺陷； （3）管理测试过程；

（4）回归测试，验证缺陷是否修复。 测试用例的目的：

（1）使测试更加方便的执行； （2）提高测试效率； （3）节省执行测试的时间； （4）使测试过程更方便管理。 测试用例的作用：

（1）有效性。测试用例是测试人员测试过程中的重要参考依据。我们已经知道，测试是不可能进行穷举测试的，因此，设计良好的测试用例将大大节约时间，提高测试效率。

（2）可复用性。良好的测试用例将会具有重复使用的功能，使得测试过程事半功倍。不同的测试人员根据相同的测试用例所得到的输出结果是一致的，对于准确的测试用例的计划、执行和跟踪是测试的可利用性的保证。

（3）易组织性。即使很小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用，正确的测试计划将会很好地组织这些测试用例并提供给测试人员或者其他项目作为参考和借鉴。

（4）可评估性。从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。测试人员经常说代码的质量不高或者代码的质量很好，量化的标准应该是测试用例的通过率以及软件缺陷的数目。

30 （5）可管理性。从测试的人员管理的角度来说，测试用例也可以作为检验测试进度的工具之一。工作量以及跟踪/管理测试人员的工作效率的因素，比较适用于对于新的测试人员的检验，从而更加合理做出测试安排和计划。

因此，我们将在测试过程中提供各类测试所需用例，并满足以下要求： 1. 测试用例的目标清楚，能满足软件质量管理各个方面的要求； 2. 测试用例的组织和分类设计思路正确、层次清晰、结构合理； 3. 测试用例应覆盖所有测试点、所有路径和所有已知的用户使用场景； 4. 有充分的负面测试用例，测试各种异常和例外情况。 5. 根据测试阶段和情况的变化，及时更新维护测试用例。

1.1.2.6.2. 用例设计

测试用例的设计方法很多，普遍会采用黑盒和白盒测试方法。

1. 黑盒用例测试方法： 设计方法 等价划分 说明 等价划分是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。 边界值分析 错误推测 因果图 正交数组测试 是对等价类划分方法的补充。针对各种边界情况设计测试用例，可以查出更多的错误。 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。 利用判定表，检查程序输入条件的各种组合情况。 通过正交试验理论来指导测试用例的选取，以便能够用较少的测试用例使测试充分。 2. 白盒用例测试方法： 设计方法 语句覆盖 行一次。 设计足够多的测试用例，使得判断中的每个条件获得各条件覆盖 种可能的结果，即每个条件至少有一次为真值，有一次为假值。 31 说明 设计足够多的测试用例，使得程序中每条语句至少被执 设计足够多的测试用例，使得程序中每个判定至少有一分支覆盖 次为真值，有一次为假值，即：程序中的每个分支至少执行一次。 设计足够多的测试用例，使得判定中每个条件的所有可判定/条件覆盖 能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。 组合覆盖 基本路径覆盖 设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。 设计足够的测试用例，覆盖程序中所有可能的路径。 下面介绍本项目采用的主要的测试用例设计方法—基于测试要素分析和测试矩阵的测试用例设计方法。

1. 等价类划分法

等价划分是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

2. 生成测试要素取值列表

测试要素是影响到执行结果的输入项，可以是输入条件，输入域，按钮等等。按照等价类划分法，将测试要素中的全部输入条件和输入域等进行精简，最终形成测试要素取值列表，如下所示。

序号 1 2 3 要素名 要素1 要素2 要素3 L1 值1 值1 值1 L2 值2 值2 值2 L3 值3 注意，每个取值对应一个等价类。

3. 生成测试要素矩阵

根据测试要素取值列表，进行一定的排列组合，形成测试要素矩阵。

序号 1 2 要素1 值1 值1 要素2 值1 值1 32 要素3 值1 值2 3 4 4. 生成测试用例

值2 值3 值1 值2 值1 值1 通过设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

最后添加上没有考虑进来的测试要素的取值后，测试要素矩阵中的每一行就自然地转换成了一个测试用例。

1.1.2.6.3. 用例组成

测试用例的组成元素包括测试用例编号、测试用例标题、预设数据、测试要素、操作描述和预期结果等。

系统的测试用例组成元素范例：

测试测试用例标题/目测试用例编号 的 用例级别 登记注册类型 增值测试要素 企业消操作预期所费描述 结果 税 得税 税 税种国有企业纳税人税种核定成功 国TC_DJ_SZDJ_001 国有企业纳税人税种核定 高 有企业 核核核定不增值核税、定 企业所得税 定 定 33 个体个TC_DJ_SZDJ_002 个体经营纳税人税种核定 高 体经营 核定 税种核定增值税 经营纳税人税种核定成功 不不核核定 定 1.1.2.6.4. 用例评审

测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面。

1. 需要评审的原因

测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。

2. 进行评审的时机

一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审；第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。

3. 参与评审人员

 部门评审，测试部门全体成员参与的评审。

 项目评审，包括了项目经理、开发经理、需求经理、测试经理、需求分

析人员、架构设计人员、开发人员和测试人员。  客户评审，包括了客户方的开发人员和测试人员。 4. 评审内容

 用例设计的结构安排是否清晰、合理，是否利于对需求进行高效覆盖。  优先级安排是否合理。

 是否覆盖测试需求上的所有功能点。

 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数

据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。

34  是否已经删除了冗余的用例。  是否包含充分的负面测试用例。

 是否从用户层面来设计用户使用场景和使用流程的测试用例。  是否简洁，复用性强。 5. 评审的方式

 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行

详细的评审记录。  通过邮件与相关人员沟通。

 无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对

方进行前期的学习和了解，以节省沟通成本。 6. 评审结束标准

在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。

1.1.2.6.5. 测试用例维护

测试用例不是一成不变的，当一个阶段测试过程结束后，或多或少会发现一些测试用例编写的不够合理，需要完善。而当同一个产品新版本测试中要尽量使用已有的测试用例，但某些原有功能已发生了变化，这时也需要去修改那些受功能变化影响的测试用例，使之具有良好的延续性。所以，测试用例的维护工作是不可缺少的。

测试用例的更新，可能出于不同的原因。由于原因不同，其优先级、修改时间也会有所不同，详见下表：

原因 先前的测试用例设计不全面或者不够准确，随着测试过程的深入和产品功能特性的更好理解，发现测试用例存在一些逻辑错误，需要纠正 所发现的、严重的软件缺陷没有被目前的测试用例所覆盖 35 更新时间 优先级 测试过程中 高， 需要及时更新 测试过程中 高， 需要及时更新 新的版本中添加新功能或者原有功能的增强，要求测试用例做相应改动 高， 测试过程前 要在测试执行前更新 测试过程中 中， 尽快修复，以免误解 中， 尽快修复，提高效率 测试用例不规范或者描述语句错误 旧的测试用例已经不再使用，需要删除 测试过程后 因此，测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面：

维护过程 维护内容 因为需求的改变等原因可能会使一个基线测试用例不再适合删除过时的测试用例 被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。 随着软件项目的进展，测试用例库中的用例会不断增加，其改进不受控制中会出现一些对输入或运行状态十分敏感的测试用例。这些的测试用例 测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。 如果存在两个或者更多个测试用例针对一组相同的输入和输删除冗余的测出进行测试，那么这些测试用例是冗余的。冗余测试用例的试用例 存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余用例删除掉。 增添新的测试用例 如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。 维护测试用例的过程是实时、长期的，测试用例的维护流程。 如图所示：

36 （1）任何人员（包括开发人员、需求人员和测试人员等）发现测试用例有错误或者不合理，向编写者提出测试用例修改建议，并提供足够理由。

（2）测试用例编写者（修改者）根据测试用例的关联性和修改意见，对特定的测试用例进行修改。

（3）向开发、项目经理递交修改后的测试用例。

（4）项目经理、开发人员及测试用例编写者进行复核后提出意见，通过后，由测试用例编写者进行最后的修改，并提供修改后的文档和修改日志。

1.1.2.7. 关键产出物的设计

云平台数据管理项目测试的关键产出物，可以分为三类：

 测试计划和方案：包括各阶段各种测试类型的测试计划和方案。  测试说明：包括测试标准和规范说明、测试设计说明、测试用例说明、测试规程说明。

 测试报告：包括各测试阶段和测试类型的测试报告。

交付成果物的要求是科学性、完整性和准确性，关键产出物列表如下： 序号 产出物分类 名称 《总体测试计划》 《用户测试计划》 测试计划 “系统测试计划”，含《功（包括功能测试计划》、《性能测试1 能和非功计划》、《压力测试计划》、与需求/设计评能测试计《安全测试计划》、《灾备审同步产生 划） 与恢复测试计划》等 《集成测试计划》 《单元测试计划》 “用户环境测试方案”，含与需求评审同描述测试需求、测试2 测试方案 《用户测试方案》、《系统步产生，用户环环境、测试类型和方测试方案》、《压力测试方境测试阶段完法、测试指标、目标案》、《安全测试方案》、《模善 37 产生时间 项目启动阶段 项目启动阶段 文档内容摘要 描述测试约束、测试范围、测试策略、测试风险、测试资源、测试进度和交付物等，是测试执行的依据。 测试阶段完善 等。 拟灾备与恢复测试测试方案》等 “实验室环境系统测试方案”，含《功能测试方案》、与《需求规格说《性能测试方案》、《安全明书》同步产测试方案》、《压力测试方生，系统测试前案》、《模拟灾备与恢复测完善 试方案》等（含用例） 《实验室环境集成测试方案》，含集成测试用例等 与《概要设计》同步产生，集成测试前完善 如压力测试方案，明确压力测试的测试环境、压力规模、加压时间等 《实验室环境单元和单元与《详细设计》集成测试方案》，含单元测同步产生，单元试用例等 《测试标准和规范说明》 测试说明《软件测试指南》 3 /规范 《测试用例模版》 《软件测试过程》 《缺陷跟踪流程》 《测试问题记录表》 启动阶段产生 测试过程中完善 描述测试用例说明。 描述测试规程说明。 描述测试过程中发现的缺陷。 描述缺陷跟踪的过测试过程中产程。 生 用于测试全过程管理。 用于测试评审管理。 用于用户测试管理。 38 测试前完善 描述测试所要遵循的标准和规范 描述测试设计说明。 《测试问题跟踪记录表》 4 测试过程 《测试过程检查单》 《测试评审检查表》 《用户测试反馈单》 《实验室环境单元和单元单元测试通过集成测试报告》 后 《实验室环境集成测试报集成测试通过告》 后 描述以下内容： 1. 测试概况：包括测试环境、测试类型、用例执行情况、实际进度和工作量《实验室环境功能测试报功能测试通过告》 后 《实验室环境性能测试报性能测试通过告》 后 5 《实验室环境安全测试报安全测试通过等； 后 告》 2. 测试数据分析：《实验室环境压力测试报压力测试结束包括测试用例执行后 告》 分析、测试需求覆盖测试报告 《实验室环境模拟灾备与模拟灾备与恢分析、测试用例有效复测试结束 恢复测试测试报告》 性分析、测试有效性《用户测试报告》 用户测试结束 分析、测试效率分《用户环境系统测试报系统测试通过析、缺陷收敛趋势分后 告》 析、缺陷分布分析、《用户环境压力测试报压力测试结束遗留缺陷、环境差异后 告》 分析等； 《用户环境安全测试报安全测试通过3. 测试结论及产品告》 后 质量分析 《用户环境模拟灾备与恢灾备与恢复测4. 缺陷清单 复测试测试报告》 试结束 所有测试类型《软件测试报告》（总体） 的测试均已通过 注：我公司提交的所有相关文档，须经招标人确认。

1.1.2.8. 测试质量的保证和验证

39 1.1.2.8.1. 质量保证

软件测试是保证软件系统质量的重要手段，而软件测试过程本身也需要质量保证的手段来保证测试过程及测试产出物的质量。在软件测试过程中，采用质量保证的管理规范方法监控整个过程，以保证软件测试的质量。

软件测试过程的质量保证，分为软件测试过程的质量监控和软件测试过程产出物的质量监控。过程的监控手段主要采用审计的方法进行，审计过程的实施是否满足预期的质量管理要求，过程产出物的监控方法主要采用评审的方法进行，评审每个阶段的产出物是否满足了预期的质量管理要求。同时采用质量度量的方法，度量软件测试质量，分析软件测试质量的符合度或者偏离度，并在发现质量问题后，采取响应的措施，及时纠正质量偏差，使得软件测试过程达到了质量管理的要求。

测试过程审计：在每个类型的测试活动中（单元测试、模块集成测试、子系统集成测试、系统功能测试、系统性能测试、跨系统集成集成、用户功能验收测试、用户性能验收测试），在每个阶段结束后，对本阶段的过程进行审计，发现存在的质量问题，包括不符合测试各阶段完成准则的问题，给出问题的纠正措施，并监督检查纠正措施的执行情况，直到发现的问题被解决。

例如，关于实验室的测试完成准则的示例如下： 一、单元和单元集成测试 1、单元测试结果审核完成 2、单元测试覆盖率达到招标人要求 3、测试报告通过评审 二、系统功能测试

1、功能测试用例全部被执行

2、测试过程中发现的缺陷，等级为A/B/C级的全部解决

3、测试过程中发现的缺陷，等级为D/E级的遗留数量每模块<5个 4、测试报告通过评审 三、系统性能测试

1、性能测试用例全部被执行

40 2、测试过程中发现的系统性能缺陷，全部被调优 3、测试报告通过评审 四、系统压力测试

1、压力测试用例全部被执行

2、测试过程中发现的系统压力缺陷，全部被调优 3、测试报告通过评审 五、安全测试

1、安全测试用例全部被执行

2、测试过程中发现的系统安全缺陷，全部被解决 3、测试报告通过评审 六、模拟灾备与恢复测试

1、模拟灾备与恢复测试用例全部被执行 2、测试过程中发现的系统缺陷，全部被解决 3、测试报告通过评审

测试产出物评审：在每个类型的测试活动中，每个阶段都有相应的产出物，在每个产出物提交后，组织相关人员对产出物进行评审，确认产出物是否达到的要求。对于评审发现的问题，给出纠正措施，并监督检查纠正措施的执行情况，直到发现的问题被解决。

1.1.2.8.2. 质量验证

据ISO9000质量管理体系要求，任何工作都要可测量，在测量过程中不仅要关注产品结果指标，还更应关注产品过程指标、关注产品成本与资源投入。验收和适应性测试综合度量在设计时需要把握4个维度：成本类指标、管理类指标、质量类指标、效率类指标。

在本项目中，我们需要保证和验证各种类型的测试质量，关键要把握质量类指标：即设计对测试工作的结果进行质量度量的指标，反映测试工作结果的质量水平。

41 质量度量：对软件测试发现的缺陷统计分析是评价软件测试质量及软件系统质量的重要手段。在测试过程中，及时地对软件缺陷进行度量并分析，可以较早的发现软件测试的质量问题以及软件系统的质量问题。

我们建议本项目质量类指标可以从缺陷密度、环境满足、案例覆盖等方面进行设计。例如：缺陷密度

该指标设计目的是通过测试所发现的缺陷，即每100个测试案例发现的缺陷总数量。使用缺陷密度可以总体衡量测试案例的编写质量、度量应用软件的质量、同时也找到发现一个缺陷的需要的案例数的平均值，避免无限制编写测试案例，监测是否出现“测试案例多，但质量不高”的情况是否出现。具体公式为：缺陷密度＝(发现的缺陷总数÷版本总案例数)×100%

缺陷密度是应用软件质量好坏的最重要指标。例如，某一软件版本共发现500个缺陷，使用了50000个测试案例，则缺陷密度是（1缺陷/100案例）。

度量指标管理应采用质量管理通用的PDCA(策划—实施—检查—行动)循环和过程方法。度量指标在实施前需要注意抓好两方面建设工作，以确保度量指标实施。

首先，需要事先策划并落实指标监控工作机制，同时应根据指标指向形成相应的工作改进机制。合理安排有一定的人力、资源投入到日常监控与测量之中，形成定式化工作模式。

其次，组建质量控制团队，利用质量指标开展软件测试的质量控制工作，其主要职责包括：一是针对指标结果进行分析；二是针对指标分析的结果提出测试方面的流程改进和质量控制建议；三是针对指标分析的结果，为测试经理及项目经理提供决策的依据和建议。

软件测试度量的核心思想是将软件测试工作进行合理的量化，涉及项目的成本、时间和质量三约束要素，并且采用量化的方法对测试活动进行审计。

1.1.3. 单元测试方案

1.1.3.1. 测试对象

单元测试（含单元集成）是对软件基本组成单元的测试。

42 单元测试的对象主要是软件设计的最小单位——模块。单元测试的依据是详细设计描述，单元测试应对模块内重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。单元测试一般采用静态代码检查和动态测试执行相结合的测试方法。

由于开发方式的不同，单元的划分存在一些差异，一般的单元划分方法是：结构化的软件开发，以模块（函数、过程）作为测试的最小单元；面向对象的软件开发，以Class(类)作为测试的最小单元，以方法的内部结构作为测试重点。

由于本项目都采用面向对象的编程语言JAVA等，因此这里的测试对象设定为程序单元，即指特定的一个具体的类或相关的多个类，单元测试主要是指对类和方法的测试。

1.1.3.2. 测试关键方法

综合各种测试方法的优劣，本项目采用静态检查和动态执行相结合的方法，具体的策略有：

 对于重要的源代码，如核心公共模块（如申报框架），采用人工静态分析

法。用代码走查、代码交叉检查的方式来做单元测试；或采用自动动态测试法，用JUNIT等工具编写测试代码，实现自动化的单元测试；  对于一般的源代码，采用自动静态分析法，利用工具扫描代码，检查错

误；或采用人工动态测试方法进行单元测试。

1.1.3.2.1. 动态单元测试框架

JUnit是对程序代码进行单元测试的一种Java框架。它提供了一组类，方便开发人员复用之以开发用于测试被测程序代码的测试代码，这样可以方便地将测试代码与产品代码分开。

使用JUnit编写测试代码的一般步骤是：

（1）定义测试类名称，一般是将要测试的类名前或后附加Test。 （2）引入JUnit框架包。import junit.framework.*。 （3）测试类继承JUnit的TestCase类。

43 （4）实现类的构造方法，可以在构造方法中简单的调用super(name)即可。 （5）实现类的main()方法，在main()方法中简单调用junit.textui.TestRunner.run(DateUtilTest.class)来指定执行测试类。

（6）重载setUp()和tearDown()方法，setUp()方法用于执行每个测试用例时进行环境的初始化工作（比如打开数据库连接），tearDown()方法用于执行每个测试用例后清除环境（比如关闭数据库连接）。

（7）编写每个测试用例，一般是要测试的方法前附加test。 自动批量执行单元测试用例：

1.1.3.2.2. 自动单元测试技术

持续集成，简单而言，就是不断的集成。通过这种不断的集成，将代码自身以及相互配合之中的问题，尽早暴露出来，便于将问题在萌芽阶段尽早消灭。

44

如图所示，持续集成流程通过五步代码检查法和持续集成结合，以实现自动化的单元测试，提高源代码的质量。

1. 对源代码的样式进行检查

采用开源工具CheckStyle，对代码的样式和风格进行检查，如JavaDoc不完整、变量名称命名不规范、方法长度过长等问题，用于剔除不符合编码规范的缺陷。该检查通过标准为所有发现缺陷全部修正。

2. 对源代码进行构建检查

对源代码进行每日构建，检查相关代码是否都已存在于配置管理库中，以及所有的代码都能相互配合进行编译。如引用第三方文件包是否存在、被调用的类接口是否发生变化等待。用于剔除可导致构建失败的缺陷。该检查通过标准为构建成功。

3. 检查代码中的逻辑缺陷

采用开源工具FindBugs，通过对编译后的代码进行静态分析，检查代码中的逻辑漏洞，如：无意义的控制流程语句，潜在的空指针引用，以及使用后未关闭的流等问题。用于剔除潜在逻辑缺陷。该检查通过标准为所有发现缺陷基本修正，未修正的必须由架构师给出书面合理性解释。

4. 对代码进行功能测试，同时进行覆盖率分析

45 使用JUnit测试框架，调用相应的测试用例，对被测代码进行功能测试，同时使用JProbe Coverage工具，对代码动态测试的覆盖率进行监视，核查每行代码是否都被测试到，剔除代码中的功能缺陷。该检查通过标准为所有测试用例通过，且要求行覆盖率达到100％。

5. 对核心代码进行内存使用情况分析

使用Jprobe Debugger工具，对关键代码的内存使用情况进行分析。通过对代码运行过程中的内存使用情况进行快照，通过对内存快照的分析检查是否存在内存泄漏等问题。该检查点通过标准为架构师对代码内存快照确定认可。

通过以上五步，对代码的各纬度都进行检测，保证了将要进入集成测试的代码的没有代码样式、构建、逻辑缺陷、以及功能和内存泄漏缺陷等质量问题。

1.1.3.3. 测试关键环节

本项目对平台各模块进行单元测试，单元测试的过程如下图所示：

46

下面阐述每个阶段执行的任务，以及一些产出物示例。

1.1.3.3.1. 计划阶段

47 项目经理制定项目的单元测试计划，明确测试范围，以及采用的测试方法。 本项目的各平台软件是分组开发的。由各开发组长依据详细设计说明书以及项目经理制定的项目单元测试计划，制定自己所负责小组的测试计划，明确每个被测功能模块的测试任务，代码覆盖率要求，测试要点，设计用例和执行负责人。

在计划阶段，将根据代码级别（从A到E）标准，确定不同类型的代码的不同的测试策略，如下表所示：

对应检查项 代码级别 A B C D E 系统公共类、函数、单元 核心业务类 核心算法类 模块级公共业务 模块级系统处理 DB级代码 Trigger、SP、Func 模块业务 前台View、JSP、Java Script 级别 A 单元测试方法 代码编写格式检查 通过标准 符合规范中的要求，CheckyStyle检查结果不符合项全部关闭 √ √ √ √ √ √ √ √ 48 符合规范中的要求，FindBugs检查B 代码编写质量检查 结果不符合项（除经过架构师确认的特殊用法外）全部关闭。 1）代码抽检率要达到要求 C 2）被抽检代码满足Code Review检代码走查 查表中检查项要求，不符合项全部关闭 D E JUNIT测试程序执行 内存泄漏检查 JUNIT测试程序执行通过 内在泄漏检查通过 1.1.3.3.2. 设计阶段

开发组根据《软件设计说明书》设计测试用例，开发人员负责单元测试用例的开发和测试脚本（JUNIT测试程序等）的编写。

设计好的单元测试用例，如下表所示： 计划编号 测试目的/数据输入、结果输预期要点描述 UTC-id正确等价输入：id=65535 PL-UT-MyCode-类：65535 MyCodeestimate-01 -UTC-id边界值：输入：id=0 estimate MyCode-0 estimate-02 输出：return 0 0 stEstimatet2() TestMyCode.te输出：return 1 1 stEstimatet1() TestMyCode.te出 结果 用例编号 测试代码 49 UTC-id边界值：输入：id=1 MyCode-1 estimate-03 UTC-id错误等价输入：id=\"a\" MyCode-类：a estimate-04 UTC-MyCode-estimate-05 UTC-MyCode-PL-UT-insertData-MyCode01 -UTC-insertDaMyCode-ta insertData-02 根据测试策略，开发组长还制订代码走查的计划和方案。

在设计阶段将搭建好持续集成平台，以便利用持续集成平台来自动化的构建代码和自动化地执行静态工具检查和JUNIT单元测试程序。

insert失败 输出：1 =1 stinsertData2() id为空，输入：\"\flagTestMyCode.te增加记录正常 输入：\"2\flag输出：0 =0 TestMyCode.testinsertData1() id错误等价输入：id=\"\" 类：空 输出：return 0 TestMyCode.te0 stEstimatet5() 输出：return 0 0 stEstimatet4() TestMyCode.te输出：return 1 1 stEstimatet3() TestMyCode.te1.1.3.3.3. 执行阶段

50 开发人员按测试计划和测试设计来执行单元测试。由于本项目系统规模庞大，开发组将针对不同级别的代码开展不同类型的单元测试执行： 1． 2． 3．

对于JUNIT单元测试程序，将执行JUNIT单元测试程序，以发现缺陷； 对于需要做代码走查的模块，在开发组长的组织下开展代码走查流程； 利用持续集成平台，自动调用相关的静态检查工具，对代码进行动态扫

描，以发现代码缺陷。 4．

开发组还开展不同形式的开发人员交互检查和测试对方代码的活动。 JUNIT单元测试程序的执行跟踪表如下表所示：

模块 目标类 级别 用例类 用例描述 执行结果 备注 【被测的代码类】 【代码级别】 【Junit测试类1】 【Junit测试类2】 【意图描述】 【P/F】 其中：P（Pass）：通过 F（fail）：失败 代码走查的检查表如下表所示：

缺分类 检查项 陷数 命名 has/can/is前缀的函数是否返回布 总数 百分比 a.java b.java 类 com.ctais.xxx(包路径) 尔型？ 注释 复杂的分支流程是否已经被注2 2 100.00% × × 释？ 方法的doc注释是否充分？（功1 2 50.00% √ × 能、输入、返回及其他） 51 0 0 0.00% 语句/功能分布/规模 单个变量是否只做单个用途？ 操作符++和--操作符的应用是否 0 0 0.00% 复合规范？ 可靠性（总则/变量和 语句） 是否已经消除了所有checkstyle0 0 0.00% 和findbugs警告？ 是否将公用常量和私有常量分0 0 0.00% 离？ 是否在if中有无效或无意义的分0 0 0.00% 支？ XML标记书写是否完整，字符串0 0 0.00% 的拼写是否正确? 对于流操作代码的异常捕获是否0 0 0.00% 有finally操作以关闭流对象?(数据库，通讯) 对浮点数值的相等判断是否是恰0 0 0.00% 当的？（严禁使用==直接判断） 可靠性（函数） 入口对象是否都被进行了判断不0 0 0.00% 为空？ 入口数据的合法范围是否都被进0 0 0.00% 行了判断？(尤其是数组)(junit) 是否对有异常抛出的方法都执行0 0 0.00% 了try...catch保护？(junit) 是否函数的所有分支都有返回0 0 0.00% 值？(junit) 0 0 0.00% 52 关键代码是否做了捕获异常处 理？ 是否对方法返回值对象做了null0 0 0.00% 检查，该返回值定义时是否被初始化? 是否确认在对Map对象使用迭代0 0 0.00% 遍历过程中没有做增减元素操作？ 0 0 0.00% 可维护性 实现代码中是否消除了直接常 量？（用于计数起点的简单常数例外） 是否消除了导致结构模糊的连续0 0 0.00% 赋值？（如a= (b=d+c )） 其它 代码实现与设计是否一致？ 代码是否使用规定实现框架？ … … … 0 0 0.00% 0 0 0 0 0 0 0 0 0 0 0.00% 0.00% 0.00% 0.00% 0.00% 项目补充 检查人 检查日期 修复日期

开发组还开展单元间的集成测试工作，测试CLASS之间的接口，将CLASS集成起来形成更大的单元。在单元集成测试的过程中，将开发一些驱动程序和桩模块来对被测单元进行测试，如下图所示：

53

1.1.3.3.4. 评估阶段

一轮单元测试结束后，项目经理召集各开发组长，对各开发组长的小组单元测试报告进行审核，若审核通过，则由项目经理汇总各开发组长的小组测试报告，编写《项目单元测试报告》。若审核未通过，则由开发组长组织新一轮单元测试。

1.1.4. 集成测试方案

1.1.4.1. 测试对象

集成测试主要用来对本项目中涉及的各类平台相互之间的兼容性进行测试，其中包括对大数据支撑平台、云计算支撑平台、数据资产平台、数据应用平台的集成性测试。

1.1.4.2. 测试关键方法

模块集成测试的基础是每个模块（单元）的自身测试已经通过，模块接口关系满足概要设计的要求。

集成测试方式一般有两种，一种是一次性集成测试，即将所有相关模块一次性集成在一起进行测试，一种是增量式集成测试，即将模块一个一个进行集成。当相关模块较少时，可以采用一次性集成测试，但模块数量较多时，这种方式容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错

54 的原因和位置。本项目开发的是大型复杂的软件，采用一次性集成测试方式，就会出现这种情况。因此，在本项目中将采用增量式集成方式，软件模块一个一个地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。

增量式集成常用的有自顶向下集成和自底向上集成两种方式。

自顶向下集成（广度优先）：从主控模块开始，按照软件的控制层次结构，以深度或广度优先的策略，逐步把各个模块集成在一起。

优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。

缺点：桩的开发量大；底层验证被推迟；底层组件测试不充分。

适用对象：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产品控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。

自底向上集成：从原子模块（即软件结构最低层的模块）开始组装测试，逐步增加之上的模块。

优点：对底层组件行为较早验证；[最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。

缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。

适用对象：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。

在本项目中，将根据被集成模块的特点，结合采用这两种集成方式。

1.1.4.3. 测试关键环节

制定集成测试计划→设计集成测试→实施集成测试→执行集成测试→评估集成测试： 

制定集成测试计划：根据项目组提供设计模型和集成构建计划，制定

出适合本项目的集成测试计划

55  测试过程 

设计集成测试：根据集成测试计划和设计模型设计集成测试用例及

实施集成测试：获取工作版本后，由测试设计员创建测试脚本（可

选）、更新测试过程，由设计员负责设计驱动程序和桩，实施员负责实施驱动和桩。 

执行集成测试：测试人员根据测试脚本（可选）和工作版本执行集成

测试，并记录测试结果。 

评估集成测试： 依照集成测试计划和测试结果，由测试设计员负责

会同集成员、编码员、设计人员评估此次测试，并生成测试评估摘要。

1.1.5. 系统测试方案

1.1.5.1. 功能测试

系统功能测试是将整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明和设计说明为依据，在模拟实际运行环境下进行的测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。

系统功能测试的目的是对最终软件系统进行全面的功能测试，确保最终软件系统满足产品需求并且遵循系统设计。

本测试采用手工黑盒测试的方法，依据功能测试用例，逐项进行操作，测试人员根据操作所获得的结果，流水记录，应用服务的日志等来进行功能验证。

56

如图所示，功能测试的总体流程分为六个步骤： 过程环节 57 工作 1 测试准备 制定测试方案或策略 准备功能测试环境和功能测试数据。 根据整个项目测试计划来安排功能测试的进度，并根据功能测试的需求明确测试小组人员的工作职责以及时间进度。 根据测试的需求，选择相应的测试方法设计相应的2 3 设计测试用例 测试用例。 由开发经理、测试经理、需求经理、开发人员和测4 测试用例评审 试人员共同参与的测试用例评审。 按照编制好的功能测试用例进行测试，形成《测试5 执行测试 日志》，并对测试过程中发现的缺陷形成《缺陷汇总表》。 6 在测试完成后总结测试的过程和结果，分析测试过产出测试报告 程中发现的软件缺陷，形成《功能测试报告》。 用例评审通过后，测试人员在测试过程中参考《测试用例设计》、《需求规格说明》、《详细设计》文档，对分配的测试内容逐一进行测试，对测试执行中发现的问题要提交到缺陷配置库中并记录测试日志。

1.1.5.2. 性能测试

在实验室环境的性能测试，由于环境设备无法完全满足生产系统的指标要求，因此，其主要目的是及早发现性能问题，进行性能调优和性能指标要求的初步验证。性能指标要求的完全验证在用户性能验收测试阶段进行。

目的： 

尽早发现软件架构的性能问题、软件程序设计的性能问题等，并进行性

能调优； 

通过测试分析，了解各个子系统的硬件资源（包括数据库服务器、应用

服务器、WEB服务器等）的配比，找出系统的参考配置方案； 

进行系统性能指标要求的初步验证，并为用户测试环境的系统性能验收

测试作准备。

58 实验室环境的性能测试分为两种类型： （1）性能指标测试(performance testing)：

性能指标测试是指在系统在正常负载（主要指完成的业务量）和高峰负载（如征期的高峰时间段）时，系统的各项性能指标是否满足要求。它的主要目的是验证系统要求的各项指标是否达到了要求。

这里是指的狭义范围内的性能测试。 （2）负载测试(load testing)：

负载测试是对系统不断的施加压力，或者增加压力为一定的持续时间，直到系统的性能指标达到忍受的极限，例如响应时间为10秒或某种资源饱和等。主要目的是验证系统处理能力的极限和容量。

性能测试脚本开发和执行按下面的步骤和方法进行。 1.

测试脚本录制和调试

性能测试借助于性能测试工具，使用性能测试工具模拟大量用户访问系统的情景。

针对被测系统，录制性能测试中使用的脚本，即将真实用户的操作步骤和使用数据全部记录下来。录制的脚本不能直接拿来使用，而是要经过参数化，将在录制过程中固定的业务数据采用参数化的技术，使之在测试期间不断变化，以便达到模拟不同用户不同业务数据进行业务操作的目的。如果从服务器端返回的某些参数是动态变化的，并且作为以后请求的提交，那么还需要使用关联技术，替换这些参数为实际的动态参数。需要真实模拟用户的请求，去掉一些脚本中不需要的冗余内容，最终就形成可以多次重复运行的测试脚本，由测试工具的控制台调度这些脚本。

脚本调试过程将采用以下循序渐进的方式：

59 录制单用户单循环单用户多循环多用户单循环多用户多循环    

单用户单循环验证：验证脚本编写准确，没有编译错误； 单用户多循环验证：参数化的数据能够正常运作； 多用户单循环验证：并发的功能；

多用户多循环验证：最终目的验证软件系统的压力。

针对集成平台来说，除了业务门户，通过web页面统一登陆以外，应用集成平台来说，测试脚本可能需要手动编写。模拟测试业务报文发起请求，针对开发使用的语言采用对应的协议脚本编写。例如采用tcp协议接入应用集成平台，开发语言使用java，模拟socket客户端发送请求报文。 2.

脚本执行

在测试环境中对被测系统执行测试，通过在线/并发的方式，形成对被测系统的压力，并监控和记录被测系统在各种压力状况下表现出来的各项特征，例如：交易响应时间变化趋势、业务处理量、网络流量变化趋势和系统资源利用率的变化趋势等。

对于性能指标测试来说，用户数根据正常和峰值的用户来对系统施加压力，执行过程中，在线用户数不需要超过峰值。

对于负载测试来说，需要继续施加压力，增加虚拟用户数，直到响应时间到达用户指标的临界点，然后继续增加用户数的情况下，如果系统的处理变慢，响应时间超过这个使用需求的时候，就可以不用增加压力。记录当这个临界点到达的时候，被测系统表现出来的特征。

60 3. 性能监控和记录

通过各种监控工具在性能测试过程中记录测试结果及其系统的运行状况，并

将这些数据记录在测试报告的附件中，需要记录的内容主要包括以下几项：

    

运行前的系统配置

运行前的参数或者软件调整情况 运行过程中的内存使用情况

运行过程中的故障现象及相应的log日志 对比测试中的对比配置信息

在性能测试过程中，将通过各种监控工具以监控主机、数据库、应用服务器、网络等的相关资源占用情况，主要包括如下几项：

监控级别 网络级别 内容 1. 网络流量：单位时间内网络传输数据量（网络包、字节，流入流程、流出流量）； 2. 冲突率：在以太网上监测到的冲突数 1. CPU总利用率：即CPU占用率（％） 2. 系统CPU利用率：系统的CPU占用率（％） 服务器系统级别 3. 用户CPU利用率：用户模式下的CPU占用率（％） 4. 内存占用率 存储 1. 存储写速率、读速率 2. 磁盘交换率：磁盘交换速率 1. 数据库的并发连接数、活动连接数 数据库级别 2. 数据库的SQL处理速率 3. 数据库锁资源的使用数量 4. 数据库内存使用情况 业务处理情况 1. 在线用户数 2. 并发用户数 61 3. 业务处理的响应时间 4. 业务处理量（单位时间完成的业务量） 5. 业务处理成功率 根据上述数据情况，针对被测系统的运行情况，进行性能分析和性能调优。 4.

网络流量测试方法

网络流量测试的目的是验证各服务器之间的网络流量是否满足系统的要求。这些网络流量包括总局服务器间的网络流量和省局到总局的服务器之间的网络流量。总局服务器间的网络流量包括数据库与应用服务器之间的流量，应用服务器之间的网络流量。省局到总局的网络流量，主要是省局集成平台到总局服务器间的网络流量。

总局服务器间的网络在前面的性能指标测试、性能压力测试期间进行采集。 省局到总局的网络流量的模拟测试可以采用两种方法，一种是在真实的部署情况下（即在前置，总局部署应该在总局部署的服务器），模拟终端从省局发起请求，监测网络流量，发起的请求数要达到一个省（可以取最大省的业务量）的业务量请求。一种是在总局的集中测试环境中，模拟一个省的业务量发起请求，监测服务器间的网络流量。我们计划采用第一种方式进行测试，这样可以更真实的模拟网络状况。

绝大部分情况下，针对测试场景的测试结果，一开始都不能符合性能标准，因此在性能测试执行过程中，将不断地进行性能分析和系统调优的过程。下面介绍性能分析和调优方法。

软件系统性能符合以下的性能模型：

62

如上图，软件系统性能的关键因素有四个：系统资源、并发用户数、响应时间、交易吞吐量（即单位时间内完成的交易数量，是系统处理能力的重要标志）。系统资源是限制，并发用户数是驱动力，响应时间和交易吞吐量是结果的表现。

对于性能指标测试，普通负载一般在轻压力区，高峰负载一般会到重压力区，可能高峰负载没有达到最大并发用户数。性能指标测试关注的不是系统负载达到最大，而是指标能够满足生产环境的需求。不需要通过不断增加压力来找性能瓶颈。

对于负载测试，需要关注吞吐量和响应时间什么时候达到用户需求临界点，此时能够说明被测系统能够支持多大的负载。需要先针对指标测试分析结果，当普通和峰值能够满足性能要求的时候，再分析负载测试的情况。这是个循序渐进的过程。

虽然说结果分析是一个灵活的过程，没有一个具体能够适应各种性能测试需要的统一的过程参考，但是还是有一些原则的内容可以参考。

对应用系统来说，包含硬件环境，系统设置，应用级别3个方面的调整，性能指标测试包含开发过程中的测试以及开发完业务功能的测试，对于开发中的测试，通常需要针对应用级别进行调整，对于开发完成的测试，有前面的工作作为基础，可以考虑重点调整系统设置，硬件环境。只有当前面两种方式都达不到要求的时候，需要分析应用级。

63 调优的原则需要确认基准的环境、负载、性能指标，每次执行测试的环境要严格保持一致，例如数据库在性能测试以后会积累不少新的记录，某些应用服务器在重新启动以后需要保持一段时间的预热等等。

最好保证每次调整的参数越少越好，这样才能确认哪些参数对实际的性能有较有利的影响。

根据经验，结果分析一般有如下方法： 

操作系统层面，主要关注各操作系统间测试结果的差异，jdk在不同

操作系统下的表现，各操作系统的系统参数设置 

数据库方面，可以通过Oracle11g自带的console监控，来定位问

题。有时性能问题表现为sql的缓慢，索引的不合理，数据库参数设置不合理，过度调度数据库等方面。 

中间件方面，主要是线程设置，集群算法的设置，可以通过中间件自

带的监控图分析是否需要调优中间件 

网络监控分析是否达到网络带宽的极限。有时可以通过优化网络实

现，有时是应用不合理造成的，例如图片/js/报文过大，优化程序解决。 

应用程序的分析，如果其他方面没发现瓶颈，而应用服务器的cpu并

不能线形增长到75%以上，可通过一些分析辅助工具，IBM的javacore分析工具/jprofiler等分析线程引起的阻塞。或者发现内存泄露，可以通过jconsole/jprofiler/jprobe来分析内存泄露。 

存储方面的调优。监控磁盘io的变化，有时是磁盘的瓶颈，有时是

应用或者数据库造成的频繁读写造成的。

在测试过程中，一般情况下，系统的性能瓶颈会有多个，当解决一个瓶颈后，会出现另一个瓶颈，如果调整中，已经达到性能指标的的目标了。可以认为性能指标测试完成。负载测试以满足实际需求为准，不需要系统崩溃。

1.1.5.3. 压力测试

64 用户环境压力测试是在接近生产环境的设备中，对系统的性能需求进行验证的测试。

通过压力验收测试，验证系统是否存在内存泄露等问题，能够承受高强度的访问频率，具备长期稳定运行的条件，系统是否达到了上线的要求。

测试重点和目标：

尽早发现软件架构可能存在的内存泄露问题，检验系统在这种情况下，响应时间有没有变化，确保系统的可扩展性能够满足真实的需要，并根据测试结果进行性能调优；

通过测试分析，确认系统能够承受较高强度的访问频率，便于评估出所需的系统的参考配置方案，包括软件和硬件方面；

实验室环境的压力测试将分为两种类型进行测试： （1）压力测试(stress testing)：

压力测试是在高于系统性能指标要求的情况下，对软件系统进行满负荷的高压力测试。通过压力测试，可以发现在性能测试时无法发现的问题。如：内存泄漏、队列过大或溢出、网络拥塞造成的问题等。

（2）稳定性测试(reliability testing)：

稳定性测试是指在系统较高压力（一般是资源使用率的70%-90%左右）的情况下，进行长时间的连续不间断的测试，以验证系统能否满足长时间运行的状况。主要测试系统在长时间不间断运行的情况下，是否存在一些通过长时间的累积才能被发现的问题。

压力测试脚本开发和执行按下面的步骤和方法进行。 1. 测试脚本录制和调试

压力测试借助于压力测试工具，使用测试工具模拟大量用户访问系统的情景。 性能稳定性测试的脚本录制/调试方法和压力测试一致。

针对被测系统，录制性能测试中使用的脚本，即将真实用户的操作步骤和使用数据全部记录下来。录制的脚本不能直接拿来使用，而是要经过参数化，将在录制过程中固定的业务数据采用参数化的技术，使之在测试期间不断变化，以便达到模拟不同用户不同业务数据进行业务操作的目的。如果从服务器端返回的某

65 些参数是动态变化的，并且作为以后请求的提交，那么还需要使用关联技术，替换这些参数为实际的动态参数。需要真实模拟用户的请求，去掉一些脚本中不需要的冗余内容，最终就形成可以多次重复运行的测试脚本，由测试工具的控制台调度这些脚本。

脚本录制调试过程将采用以下循序渐进的方式：

录制单用户单循环单用户多循环多用户单循环多用户多循环  单用户单循环验证：验证脚本编写准确，没有编译错误；  单用户多循环验证：参数化的数据能够正常运作；  多用户单循环验证：并发的功能；

 多用户多循环验证：最终目的验证软件系统的压力。 2. 脚本执行

在测试环境中对被测系统执行测试，通过增大负荷，形成对被测系统的极端加压，并监控和记录被测系统在这样的压力状况下表现出来的各项特征，例如：交易响应时间变化趋势、业务处理量、网络流量变化趋势和系统资源利用率的变化趋势等。

压力测试的用户数从峰值的用户数开始累计。

一般情况下，压力测试要求CPU达到80%以上，内存使用率达到70%以上，jvm的内存、数据库的连接等也能作为压力已经达到的依据。

稳定性测试一般脚本执行中会设置thinktime，用户选择指标测试时评测出来的系统最大处理能力所对应的用户量90%。

66

3. 性能监控和记录

压力测试通过各种监控工具在性能测试过程中记录测试结果及其系统的运行状况，并将这些数据记录在测试报告的附件中，需要记录的内容主要包括以下几项：

    

运行前的系统配置

运行前的参数或者软件调整情况 运行过程中的内存使用情况

运行过程中的故障现象及相应的log日志 对比测试中的对比配置信息

稳定性测试中需要记录的内容主要包括以下几项：     

运行前的系统配置

运行前的参数或者软件调整情况 运行过程中的内存使用情况

运行过程中的故障现象及相应的log日志

运行过程中的系统资源变化是否稳定，响应时间变化

两种类型的测试过程中，将通过各种监控工具以监控主机、数据库、应用服务器、网络等的相关资源占用情况，主要包括如下几项：

监控级别 内容 网络流量：单位时间内网络传输数据量（网络包、网络级别 字节，流入流程、流出流量）； 冲突率：在以太网上监测到的冲突数 CPU总利用率：即CPU占用率（％） 服务器系统级别 系统CPU利用率：系统的CPU占用率（％） 用户CPU利用率：用户模式下的CPU占用率（％） 内存占用率 存储 存储写速率、读速率 磁盘交换率：磁盘交换速率 67 数据库的并发连接数、活动连接数 数据库级别 数据库的SQL处理速率 数据库锁资源的使用数量 数据库内存使用情况 在线用户数 并发用户数 业务处理情况 业务处理的响应时间 业务处理量（单位时间完成的业务量） 业务处理成功率 稳定性测试中最好还加上应用服务器/数据库等连接的变化情况，操作系统底层涉及到的tcp连接等的变化情况，JVM的内存的变化情况，gc的频率幅度，检查长时间运行情况下，是否这些资源能够合理的释放回收。

根据上述数据情况，针对被测系统的运行情况，进行分析和性能调优。 软件系统性能符合以下的性能模型：

如上图，软件系统性能的关键因素有四个：系统资源、并发用户数、响应时间、交易吞吐量（即单位时间内完成的交易数量，是系统处理能力的重要标志）。系统资源是限制，并发用户数是驱动力，响应时间和交易吞吐量是结果的表现。

68 对于压力测试来说，需要考虑的就是重压力区以后的范围，吞吐量下降，用户无法忍受区，一般压力测试的时候用户数量至少是指标测试时评测出来的系统最大处理能力所对应的用户量的1.5倍以上。此时资源已经达到饱和，系统处于崩溃的边缘。压力测试要寻找这个临界点，并且持续运行一段时间。

稳定性测试来说，一般系统处于峰值压力的70%-90%，持续运行。 对于性能压力测试的结果分析，和性能测试类似，一般有如下方法： 

操作系统层面，主要关注各操作系统间测试结果的差异，jdk在不同

操作系统下的表现，各操作系统的系统参数设置 

数据库方面，可以通过Oracle11g自带的console监控，来定位问

题。有时性能问题表现为sql的缓慢，索引的不合理，数据库参数设置不合理，过度调度数据库等方面。 

中间件方面，主要是线程设置，集群算法的设置，可以通过中间件自

带的监控图分析是否需要调优中间件 

网络监控分析是否达到网络带宽的极限。有时可以通过优化网络实

现，有时是应用造成的，优化程序解决。 

应用程序的分析，如果其他方面没发现瓶颈，而应用服务器的cpu并

不能线形增长到75%以上，可通过一些分析辅助工具，IBM的javacore分析工具/jprofiler等分析线程引起的阻塞。或者发现内存泄露，可以通过jconsole/jprofiler/jprobe来分析内存泄露。 

存储方面的调优。监控磁盘io的变化，有时是磁盘的瓶颈，有时是

应用或者数据库造成的频繁读写造成的。

对于压力测试，在性能指标测试以后进行，可以主要关注数据库，中间件，网络和应用程序方面。

对于稳定性测试，压力一般70%-90%，重点分析内存和各种连接方面的问题，不用关注响应时间、吞吐量等这些指标。如果发现有内存问题，很可能要修改代码，这样的话，需要重复迭代执行性能指标测试、压力测试过程，直到达到目标。

69 压力测试和稳定性测试，更多地关注系统的稳定性，对于内存，数据库，和应用程序的分析尤其重要，特别是内存泄露，需要作为优先级高的问题分析解决。

压力测试和稳定性测试调优的目的和性能测试也不同，不关注于某些硬性的指标。

压力测试指标如下图所示： 指标项 并发用户数 指标值 用户数，可逐步增加 说明 大于性能测试的并发性能指标测试中最大并发用户数1.5倍以上，超过负载测试的用户数 系统资源使用系统的CPU至少达到可以调整实际范围，也可以加率 入jvm的可用内存，数据库cpu80%以上，内存使用超使用率等参数 过70% 交易失败率 低于千分 无内存泄露，失败事务数低于这个指标 稳定性测试的指标如下图所示：

指标项 并发用户数 指标值 说明 峰值并发用户数的70%-可以增加思考时间 90% 系统资源使用系统的CPU使用率 率 运行时间 交易失败率 至少3*24小时 低于千分之 可以实际调整 一般7*24小时 无内存泄露，失败事务数低于这个指标 1.1.5.4. 安全测试

开发工作中的每一个环节都可能出现问题，那些没发现或已“放大”的错误修复成本都是非常高的。所以，专门针对应用系统的安全性测试技术渐渐被人们重视，它已成为保证系统安全性的一项重要手段。

70 针对系统的安全性的测试方法就是采用各种方法来验证或发现系统安全方面的问题。对于需求说明书上既定的有关安全的功能需求，我们要一一进行验证测试。对于没有在软件需求书上标明的可能影响系统运行安全的隐性需求我们也要努力的发现。

安全测试的测试对象主要为： 1.

软件的安全功能测试 （1） 用户身份认证

用户身份安全主要是用户访问系统时，必须具备指定身份，不符合系统身份的用户无法访问系统。身份包括三类：一是从前端登录系统的用户身份；二是从接口访问系统的用户身份；三是访问数据库、中间件等系统的用户身份。

（2） 用户权限

用户权限安全是允许访问系统的用户，应该只允许访问系统指定的模块、功能，指定的模块、功能之外的，该用户应不允许访问。

（3） 数据传输安全

数据传输安全是指系统数据在网络传输过程的安全，主要是数据的加密、防串改、防窃取等。系统的数据比较多，为了保证系统的效率，不是所有的数据都必须通过严格的安全保护。但关键的数据必须得到安全保护，如用户密码、电子印章等。

（4） 数据存储安全

数据存储安全是指数据存储在介质上时，应保证其安全。数据包括敏感业务数据、用户密码、系统密码等。

（5） 安全审计功能

软件可以对用户和软件作用于系统的某些行为进行审计。应用程序可追踪用户录入数据到数据库的时刻、与所录入有关的信息或所录入数据在数据库所处的位置。审计主要是一种支持信息举证和入侵检测的事后行为。

（6） 软件容错

在软件的数据输入部分进行容错控制主要是通过增加对输入信息的检验，使之符合应用程序本身的要求，防止输入异常数据导致程序运行出错。例如对输

71 入的数据格式或长度等信息在用户输入是进行验证，符合规定的再提交给后台程序运行，反之则拒绝输入。

并且程序应当具备记录故障发生时的系统状态功能，例如系统状态的快照，便于时候分析故障原因。

（7） 资源控制

控制用户对系统资源的使用，使得高优先级任务的完成总是不受低优先级任务的干扰和影响，这些资源包括处理类资源和通信类资源等。控制用户和主体对资源的占用，使得不因不恰当占有资源而出现拒绝服务情况。 2.

软件开发脆弱性测试

对软件进行全面检测，以发现软件在设计和编码中的错误、疏忽和其它缺陷。 开发文档检测。对需求分析说明书、软件设计说明书、源程序作结构检查、流图分析等找出软件错误。

代码审计。通过人工或者工具检测软件编码工程中所造成的安全漏洞，主要检测内容为远程检测漏洞、SQL注入漏洞、跨占攻击漏洞、缓冲区溢出漏洞等。

安全测试最基本和最主要的是要采取静态分析技术和功能测试两种方式。

静态分析技术

其基本特征是不执行被测试软件，而对需求分析说明书、软件设计说明书、源程序作结构检查、流图分析等找出软件错误。

这里，需求和设计追溯和确认是验证测试的前提，我们可以利用一些自动化工具画出功能需求的相关关系图，以及一些系统结构的UML图，能够使测试人员与开发人员保持一致的设计思路。

源程序的结构检查和流图分析一般是测试人员代码审查时的重要工作，对于查出前期的软件错误非常有效，现在很多开发单位都采用自动化测试，取代了冗长的代码审查会议，提升了测试的效率和准确度。

功能测试

功能测试是动态测试的一种方式，验证的是软件的功能实现。因为在软件设计和开发过程中，会增加一些必要的安全防护措施，如用身份认证、权限管理模块、数据恢复功能等等，我们就会通过功能验证来检查我们是否达到了没有安全疏漏的要求。

72 安全测试过程如下：

过程环节 制定安全测试计划 编写测试用例 安全测试 修改安全问题 产生测试报告 划中 工作 制定安全测试的测试计划，可以包含在项目开发计安全人员首先撰写单元测试检查表（测试用例） 利用静态分析技术和功能测试进行安全测试 未通过测试需要修复安全问题，然后再测试 记录测试结果，分析测试结果，对Bug进行纠正并记录 1.1.6. 测试组织

软件测试组织是项目总体组织架构的组成部分，在总体组织架构中，牵涉到测试工作的组织有开发组和测试组。如下图中标红部分。

73

详细的测试组织架构如下图所示：乙方由开发组、集成与功能测试组、非功能测试组组成，甲方由集成与功能测试组、非功能测试组组成。

集成与功能测试组负责集成测试、功能测试、用户界面测试、安装/卸载测试、兼容性、升级测试等测试工作；非功能测试组负责性能测试、压力测试、安全测试、灾备与恢复测试等测试工作。

用户验收测试由甲方的测试组和乙方的测试组共同完成，以甲方的测试组为主，乙方的测试组配合。

各个组织的职责描述表： 组织 制定验收测试计划 甲方测试批准验收测试方案 负责人 管控测试过程，保证测试质量 测试报告评估 负责开发阶段的总体测试工作 乙方开发组长 制定总体计划 制订单元测试计划 组织单元测试，编写单元测试报告 管控测试过程，保证测试质量 74 职责 乙方： 编写单元测试用例 开发组 负责单元测试 修改测试缺陷 支持测试组的测试工作 协调测试组和项目内其它小组、测试组和外部各方的关系 乙方测试确定各阶段测试计划及测试方案 组长 管控测试过程，保证测试质量 开展测试分析，编制测试报告 乙方： 负责实验室集成与功能测试，支持用户环境测试 乙方集成负责模块、子系统、系统（产品）功能测试 与功能测负责模块、子系统、系统（产品）集成测试 试组 制定测试方案 编写测试案例，执行测试，编制测试报告 跟踪缺陷修订状态，执行回归测试 乙方： 负责实验室非功能测试，支持用户环境测试 负责性能、压力等测试 乙方非功能测试组 负责安全测试 负责灾备和恢复模拟测试 制定性能测试方案，设计测试场景 执行测试，编制测试报告 分析系统性能，找出系统性能原因，解决性能问题或给出解决建议 甲方集成与功能测试组 甲方： 负责用户环境集成与功能验收测试 根据总体进度安排 执行测试及回归 75 编制测试报告 甲方： 负责性能验收测试 甲方非功能测试组 负责安全验收测试 负责灾备和恢复模拟测试 根据测试规范要求，与乙方共同制定制定各种性能测试的方案，设计测试场景 执行测试，编制测试报告 1.1.6.1. 人员配备

我们将成立专门的测试组织，人员由高级测试经理和专业的、有经验的软件测试工程师组成：

岗位 职责 制定验收测试计划 甲方 测试组长 批准验收测试方案 管控测试过程，保证测试质量 测试报告评估 协调测试组和项目内其它小组、测试组和外部各方的关系 制定测试计划 乙方 测试组长 （高级测试管控测试过程，保证测试质量 经理） 开展测试分析，提交测试报告 测试设计分测试需求分析 析人员 编制各阶段测试计划及测试方案 76 分析测试结果，提出解决方案 编制测试报告 负责实验室功能性测试，支持用户环境测试 乙方 编制测试用例 集成与功能开发测试脚本 测试执行人进行测试准备 员 执行测试 跟踪缺陷修订状态，执行回归测试 负责实验室非功能测试，支持用户环境测试 编制测试用例 准备测试需要的基础数据 根据业务测试场景，设计和准备测试脚本中所需的各类业务数乙方 非功能测试执行人员 按照测试场景要求，录制、调试测试脚本 制定性能测试方案，设计测试场景 执行测试，编制测试报告 分析系统性能，找出系统性能原因，解决性能问题或给出解决建议 测试环境的搭建与维护 据 乙方 持人员 乙方 测试环境支测试版本的配置管理 测试产出物的配置管理 数据库管理对数据库系统进行安装、管理和调优。 员 甲方 负责用户环境集成与功能验收测试 77 集成与功能测试组 根据总体进度安排 执行测试及回归 编制测试报告 负责性能验收测试 负责安全验收测试 甲方 非功能测试组 负责灾备和恢复模拟测试 根据测试规范要求，与乙方共同制定制定各种性能测试的方案，设计测试场景 执行测试，编制测试报告

1.1.6.2. 第三方配合

如招标人委托第三方测试机构进行测试，我们承诺予以积极配合。

1.1.7. 测试工具

下面是本项目的测试工具列表：

类型 测试管理工具 缺陷跟踪工具 自动化测试工具 名称 QC（Mercury Quality Center） Bugzilla（开源） QTP Junit 单元测试工具 JProbe Findbugs 静态代码检查工具 CheckStyle 78 性能测试工具 LoadRunner 性能测试辅助工具 Nmon(开源) 持续集成工具 知识管理平台 CruiseControl 自有产品（含TRS） 1.1.7.1. 测试管理工具Quality Center

Quality Center (简称QC)是Mercury Interactive公司推出的基于WEB的测试管理工具。QualityCenter能够帮助你组织和管理软件测试过程的每个阶段，包括测试需求管理、测试计划、测试执行和缺陷跟踪。

QC的功能和TD类似，是TD的更高级版本，测试过程中可以根据需要选择二者中的一个即可。

1.1.7.2. 缺陷跟踪工具Bugzilla

软件配置管理系统（Software Configuration Management）作为一套规范、高效地软件开发基础结构，已不是一个新概念，早期的软件工程环境就已经开始考虑配置管理了。现在，人们通过实践越来越认识到软件配置管理对于提高软件质量和软件开发过程的可靠性有着极其重要的作用。SCM 代替了传统的问题修复方式，完整地记录了软件开发过程，包括软件中出现的问题，修复这个问题的过程以及是由谁进行的修改。更重要的是，记录的所有过程都是企业知识财富的积累，使软件项目不会因为开发人员的变更而受到影响。SCM 是通往ISO9001 和SEI CMM 标准的一块基石。

79 Bugzilla错误跟踪系统，能够有效的协调软件项目中各职能人员的工作，能够使软件项目在预定时间内高质量完成。通过使用 Bugzilla，可以使管理者和项目团队对开发过程中的编码阶段、测试阶段、版本更替阶段进行过程控制，从而成功地控制项目进度和产品质量，使软件开发的风险减少到最小。通过应用 Bugzilla，软件企业可以形成一个以软件产品为核心，以Bugzilla为纽带，高效开发的管理模式。

1.1.7.3. 自动化测试工具QTP

QuickTest Professional™是一款先进的自动化测试解决方案，用于创建功 能和回归测试。它自动捕获、验证和重放用户的交互行为。Mercury QuickTest Professional为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。

QTP适用于部分集成测试和系统功能测试中的自动化测试。

1.1.7.4. 单元测试工具JUNIT

JUnit就是对程序代码进行单元测试的一种Java框架。通过每次修改程序之后测试代码，程序员就可以保证代码的的少量变动不会破坏整个系统。

JUNIT框架适用于单元测试阶段编写单元测试用例和测试执行。

1.1.7.5. 单元测试工具JProbe

JProbe Suite 是Java最佳的性能调优组件工具包，提供了高级的、高灵活性的Java应用程序调优，而不管其在本地运行还是在远程运行。组件包中包括：JProbe Profiler(诊断Java代码中性能瓶颈)、JProbe Memory Debugger(发现Java代码中的内存泄漏)、JProbe Threadalyzer(多线程分析)、JProbe Coverage(代码覆盖分析)。

JProbe适用于单元测试阶段辅助JUnit进行代码内存分析，帮助发现性能的问题。

1.1.7.6. 静态代码检查工具findbugs

80 Findbugs是一个老牌的开放源代码的Java静态分析工具，它检查类或者 JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。

Findbugs适用于单元测试阶段在开始动态执行单元测试前，进行静态代码分析，发现代码中的逻辑错误。

1.1.7.7. 静态代码检查工具CheckStyle

CheckStyle提供了一个帮助JAVA开发人员遵守某些编码规范的工具。它能够自动化代码规范检查过程，从而使得开发人员从这项重要，但是枯燥的任务中解脱出来。它提供以下主要检查内容：Javadoc注释,命名约定,标题,Import语句,体积大小,空白,修饰符,块,代码问题,类设计,混合检查（包活一些有用的比如非必须的System.out和printstackTrace）。

CheckStyle适用于单元测试开始阶段，首先对代码进行编码规范的检查，从而保证不同程序员写的代码符合统一的编码规范。

1.1.7.8. 性能测试工具LoadRunner

LoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整 个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

LoadRunner适用于性能测试阶段，它帮助我们发现系统的性能问题以便进行性能优化，并能够验证系统是否达到了预期的性能指标值。

1.1.7.9. 性能测试辅助工具Nmon

Nmon是一个开源的监控linux系统资源的工具，可以监控cpu内存 Io网络等等，可以根据时间来监控并生成文件，最后利用excel形成结果分析图供测试人员使用。

1.1.7.10. 持续集成平台CruiseControl

81 持续集成关键是自动化，自动定时从指定的地方获取源代码、编译、连接、测试、发布。每个这样的过程称之为一次创建。支撑持续集成实践的是持续集成平台（系统或环境）。

CruiseControl 是一种开源的持续集成框架，它包括了ant 和各种源码控制工具的插件。并提供了 web 接口，用于查看当前和以前的创建的结果。

CruiseControl适用于从单元测试开始的整个测试过程，定期对代码进行自动持续集成，在单元测试阶段，CruiseControl集成代码检查工具和JUnit单元测试工具进行单元测试；在集成测试和系统功能测试阶段，CruiseControl集成QTP进行自动化功能测试。

我公司使用的持续集成平台：使用开源的CruiseControl 持续集成框架，通过集成代码编译工具，源代码静态分析工具，单元测试工具，单元测试工具覆盖率统计工具等，实现集编译、代码静态分析、单元测试等一体化的自动化持续集成过程。

持续集成平台中的相关软件如下表所示： 工具名称 CruiseControl Ant SubversionClearCase等 Selenium JUnit 自动化测试工具 基于页面的Web功能自动化测试工具 定位 持续集成服务器 版本创建者 、配置管理系统 作用说明 定时器，集成者 编译并链接程序，生成二进制文件 配置管理系统 Java的单元测试开放源代码的Java测试框架，用于编工具 写和运行可重复的测试程序。 另外，在持续集成平台中我们还将下表中的检查工具集成进来，以自动执行一些检查工作，如源代码样式检查、静态分析、内存泄露检查等。

工具名称 Checkstyle 定位 作用说明 Java代码样式检检查源代码是否符合编码规范和文件查工具 规范。 通过静态分析的方式，找出代码中的逻辑错误和代码中的可改良部分。 82 FindBugs 静态分析工具 JProbe Coverage JProbe Debugger 测试覆盖率计算 计算测试覆盖率，识别和量化没测试的代码行，等 内存分析、内存泄通过对代码在运行中的内存使用情况漏检查 的分析，指出潜在的内存泄漏，和有无产生过多的临时对象。 1.1.8. 自动化测试

1.1.8.1. 自动化测试原理 1.1.8.1.1. 自动化测试概念

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，通过计算机把人工的一步步的测试过程用计算机进行模拟，并将测试结果与预期结果进行比较，产出测试报告的过程。自动化测试能够实现测试数据的自动输入、测试过程的自动比较、测试结果的自动输出等功能。

1.1.8.1.2. 自动化测试原理

自动化测试原理如下图所示。

测试数据读取测试数据(2)测试数据写入被测系统(1)被测系统输入文本按钮按钮从被测系统获取测试结果(3)自动化测试工具(4)记录测试和比对结果测试结果 自动化测试的相关对象：

 自动化测试工具：执行自动化测试代码的工具和相关的辅助工具  被测系统：自动化测试运行的目标系统

83  测试数据：自动化测试运行时被测系统需要的数据

 测试结果：包括自动化测试的过程结果以及被测系统的反应与预期反应的结果

自动化测试原理和过程： (1) (2)

自动化测试工具读取被测系统需要的测试数据

自动化测试工具识别被测系统以及被测系统的界面元素对象，并

按照被测系统的操作步骤将测试数据赋值到被测系统的对应对象 (3) 进行比对 (4)

自动化测试工具将测试步骤以及比对结果输出到执行报告中 自动化测试工具记录被测系统的反应并与事先设计的预期反应

1.1.8.2. 自动化测试模型 1.1.8.2.1. 自动化测试框架

自动化测试框架是一组自动化测试的规范、测试脚本的基础代码、测试思想和测试用例的集合。应用自动化测试框架有以下好处：

 提高自动化测试开发速度，提升测试代码的执行效率；

 提高自动化测试代码质量，通过重构可以使代码更简洁和富有弹性；  降低自动化测试的维护成本；

 提高自动化测试的适应性和可扩展性。 自动化测试框架的发展经历了三个阶段：

(1) 简单的录制/回放

(2) 数据驱动（Data Driven）的自动化测试 (3) 关键字驱动（Keyword Driven）的自动化测试 相应地，软件测试自动化脚本的类型，从低到高的发展层次是：

(1) 线性脚本：通过录制直接产生的线性执行的脚本。

84 (2) 结构化的脚本：具有顺序、循环、分支等结构的脚本。 (3) 共享的脚本：可以被多个测试使用、被其它脚本调用的脚本。 (4) 数据驱动的脚本：数据和流程控制分离的脚本，通过读入测试数据来驱动流程进行的脚本。

(5) 关键字驱动的脚本：脚本、数据、业务分离，数据和关键字在不同的数据表中，通过关键字来驱动业务逻辑。

1.1.8.2.2. 自动化测试模型

由于关键字驱动技术目前还不够成熟，能够支持关键字驱动的工具比较少，因此选择数据驱动框架来创建自动化测试模型。

被测系统对象识别测试对象库自动化测试框架开始测试测试数据读取测试对象操作检查点结果生成测试数据执行结果 自动化测试模型应包括以下几个部分：

(1) 被测系统

自动化测试运行的目标系统，对于主流的C/S、B/S等系统，自动化测试都能很好地支持。

(2) 自动化测试框架

自动化测试框架是自动化测试的核心内容，主要由实现各种功能的脚本、辅助工具等组成。

 测试数据读取：由读取测试数据的脚本组成，用于在自动化测试运行

85 的过程中，根据被测系统的业务需要动态读取测试数据

 测试对象库：被测系统界面元素在自动化测试框架的映射对象的集合，通过自动化测试工具的对象识别技术进行映射，可以被自动化测试脚本直接使用。通常一个测试用例有一个对象库，对象库也可以共享给其它测试用例使用

 测试对象操作：根据被测系统的业务逻辑，通过自动化测试脚本操作对象库，达到对被测系统界面元素进行操作的目的

 检查点：自动化测试脚本中检验被测系统的反应是否符合预期结果的脚本。

 结果生成：将检查点的检查结果写入执行报告的脚本。 (3) 测试数据

被测系统运行过程中需要的数据，并能够根据测试的需要随时调整。数据的存储方式可以多样化，例如文本文件、Excel、关系数据库等。

(4) 执行结果

测试用例执行完成后产出的测试结果，通常记录每一个检查点的检查结果，用于在自动化测试结束后查看被测系统的运行情况。执行结果也有多种形式，例如文本、Excel、数据库等。

1.1.8.3. 自动化测试方法

自动化测试的实施离不开各种工具的支持，下面以QuickTest Professional（简称QTP）和Quality Center（简称QC）来介绍自动化测试的实现方法。

1.1.8.3.1. 自动化测试框架的要求

搭建符合以下要求的自动化测试框架，使得自动化测试实施能够有序、高效、快速地实施：高复用性、高可维护性、稳定性、快速编写脚本、自动执行、正确输出结果、能够不断提升自动化测试比例。

1.1.8.3.2. 自动化测试的实现思路

86 分层设计：业务流程、功能点、操作组件

在进行测试时，首先会验证各个页面、各个字段的正确性，然后验证功能点的正确性，再组合各个功能点进行进行业务逻辑、业务流程的验证，最终确保系统满足业务需求。

对于自动化脚本，采用分层的思想，先实现最底层的操作组件，通过调用操作组件、业务逻辑实现对功能点的验证，再通过调用业务逻辑组合功能点实现对业务流程的验证。不同的业务流程，对于底层的操作组件、中间层的功能点函数是完全可以复用的，知识调用的业务逻辑或测试数据存在差异。

尽可能做到各脚本之间具备独立性，不相互依赖，便于进行各种基本场景的组合运行。

脚本分离设计：对象、操作、测试数据、业务逻辑相互剥离、灵活调用 对某个功能进行自动化测试，实际上就是对这个功能涉及的对象进行操作，输入测试数据来验证其结果的正确性，复杂的检查点需要编写业务逻辑。如果全部采用脚本的方式编写，针对每一条测试数据就需要编写一份脚本，脚本数量将会非常巨大，同时被测系统的任何改动（程序、测试用例、GUI对象）都需要调整大量的脚本。

为了达到可维护性、可复用性的目标，将对象、操作、测试数据、业务逻辑剥离，分开管理，通过调用关系去组合实现不同的测试用例。

对象资源库 测试数据资源库 操作组件 脚本

封装基础函数、基础业务逻辑、检查点

通过对一些公用的、基础的函数封装以及业务逻辑和检查点的封装、调用，实现脚本的快速开发。

有效的执行体系

批量、定制执行、自动运行

自动化测试要真正达到提升测试效率的目标，需要实现无人值守情况下的批量自动执行，并且可以定制执行。

87 异常处理机制

在自动化测试运行过程中，因程序错误、环境问题、数据问题、脚本自身问题等经常会出现一些非预期的错误（如意料外的弹出窗口、发现错误数据、未找到对象、文件无法打开或无法读写等），有些情况下当前测试用例出错，并不影响后续用例的执行，需要支持异常处理机制，终止执行或终止当前用例的执行，继续后续用例的执行，抑或跳过当前操作步骤，继续后续的操作步骤，并输出当前的错误报告。

业务数据还原初始状态

自动化测试需要循环执行，执行完成后需要恢复初始状态，以使得程序重新提交版本后能够循环执行，不断地对新版本进行回归测试。

结果体系

针对每个检查点输出详细的检查点检查结果 针对每个用例输出用例的执行结果 针对每个流程输出流程的执行结果 结构化管理

对象、操作组件、基础函数、测试数据、功能点脚本、业务流程组合，如此多的层级和调用关系，必须进行结构化管理，采用高度组织化的目录结构，分级管理，方便进行正确和快速的调用，方便快速定位、查找问题。

版本管理

随着待验证版本的不一致，自动化测试脚本也会不断地更新、维护，同样需要版本管理。

1.1.8.3.3. 自动化测试的框架设计

自动化测试的框架设计，如下图所示。

88 业务流程A功能模块A3。。。功能模块B1A1业务流程功能模块B2B功能模块B3。。。……辅助工具业务流程管理工具业务层功能模块A1功能模块A2功能模块功能模块页面组件A11页面组件A12B1……功能层公共功能模块页面组件A11页面组件A12。。。。。。测试执行工具资源层页面组件操作对象业务逻辑(脚本)自动化测试数据管理工具公共测试数据特有测试数据基础函数执行体系数据访问执行管理组件数据驱动引擎关键字驱动引擎异常处理机制数据恢复机制脚本版本管理结果体系执行日志结果识别结果输出支撑层配置函数对象识别对象操作  业务层

调用功能层的功能模块，组成测试业务流程，并调度和执行测试业务流程，收集执行结果，形成测试报告。

 功能层

根据资源层的页面组件结合自动化测试脚本组合成功能模块，读取测试数据，将测试数据与执行步骤结合，组成功能模块的测试过程，并设置检查点，检验模块的执行正确性，执行完毕后返回执行结果。

 资源层

将各个功能模块中相同的操作对象、相同的业务逻辑等内容抽取出来，形成公用页面组件，包括操作对象、业务逻辑、公共数据、特有测试数据等，供功能层的功能模块脚本调用。

 支撑层

属于自动化测试平台的底层框架，包括封装的基础函数、执行体系和结果展示体系。

 辅助工具

包括自动化测试业务流程管理工具（Quality Center）、自动化测试脚本执行工具（QuickTest Professional）和其它相关辅助工具。

89 1.1.8.3.4. 自动化测试实施步骤

(1)

自动化测试脚本开发和测试数据模版设计

 自动化测试开发人员针对被测系统的每一个功能单元开发自动化测试脚本，将测试数据和脚本分离，并设计出符合此脚本运行的测试数据模版。

 自动化测试开发人员在进行脚本开发时，在脚本中增加每一个功能点的检查点。

(2)

测试流程组装

 自动化测试执行人员根据业务流程将各个功能单元的自动化测试脚本组装成不同的测试流程。

 按照流程之间的关系对流程进行优先级排序。

 根据自动化测试人员设计的测试数据模版生成自动化测试需要的测试数据。

(3)

测试流程执行

 自动化测试执行人员手工启动或通过辅助工具自动启动自动化测试流程。 (4)

测试报告生成

 自动化测试执行完成后生成测试的执行结果。

 自动化测试执行人员查看测试执行结果判断每个流程、模块、功能点是否执行通过，对于未通过的功能，进行手工验证后提报问题。

1.1.9. 软件测试知识库

根据软件测试过程中的典型性问题、常见性问题和重要性问题建立软件测试知识库。

1.1.9.1. 建立目的

通过对系统测试过程中有价值的资料、文档、成果、经验等知识进行有效收集和管理；不断积累软件测试的知识资产，避免知识的流失；促进测试人员对知识的共享、学习、再利用和创新；从而达到提高测试人员整体工作效率。

90 1.1.9.2. 整体功能

软件测试知识库分为两部分，第一部分包括知识的创建、审核、发布、浏览查询等功能，第二部分包括用户权限管理、知识分类管理、知识模板管理等系统管理功能。如下图所示：

软件测试知识库知识检索知识管理知识分类管理知识模板管理用户权限管理 其中：

知识检索：可以按照知识的分类、知识的专题等维度进行导航浏览。可以通过全文检索的方式查找符合要求的知识内容。搜索知识方式包括：

简单搜索。直接在搜索框中键入关键词搜索。

高级搜索。通过在高级搜索中选择，达到快速搜索的方式。 二次检索。在搜索结果中再进行搜索。 自然句搜索。在搜索框中键入自然句搜索。 在浏览知识的过程中可以对知识进行评价。

知识管理：是指知识创建、知识审核、知识发布、知识归档等内容。知识创建是指将有价值的测试知识按照知识模板录入到知识库的过程。知识创建后，由相关的人员对知识进行审核，审核是确保知识内容的准确性和实时性。审核完成后，进入到知识发布，知识发布完成后，可以供系统人员进行使用了。由于知识具有时效性，可以通过知识归档功能将已经失效的知识进行归档。

知识分类管理：是指建立一个主维度知识分类和多个扩展维度知识分类，并对知识分类进行显示、维护和修改。维度分类一般按照按照知识创建者所属组织划分和按照知识所对应的应用领域划分。

91 知识模板管理：是指用户可根据需求建立标准模板,可根据需求在标准模板的基础上建立特色知识模板。用户建立的模板可以应用在知识类型中。用户创建知识时，可选择知识分类所相应的模板创建知识。

用户权限管理：通过该模块可以为使用分配访问和操作权限。用户可分为管理员、匿名用户、普通用户。操作权限可以分为知识浏览、创建、审核、发布、归档等内容。另外，在知识浏览过程中，浏览密级又可分为普通、重要、内部等级别。

1.1.9.3. 知识内容

测试知识库的建立可以依据测试过程的特点，分为三个阶段建立知识内容。 准备阶段：知识包括软件测试理论、测试计划、测试方法、测试用例、需求分析规格说明书、概要设计说明书等内容

测试阶段：缺陷跟踪表 总结阶段：测试结果分析报告

由于测试过程是逐步迭代，精益求精的过程，知识库建立也可以按照这种方法逐步完善。

1.1.9.4. 知识分类及模板

根据软件测试知识库的特点，知识分类主维度可以按照典型性问题、常见性问题和重要性问题进行分类。

在扩展维度的分类中可分为界面测试问题、性能测试问题、业务功能测试问题等三类，每种分类可以进行细化。例如：性能测试问题可分为可靠性问题、安全性问题、健壮性问题、可移植性问题、易用性问题、开放性问题、可扩展性问题；业务功能测试问题可以按照业务功能模块进行细分。

标准的知识模板包括： 序号 1 2 3 知识属性 知识编号 创建时间 标题 是否必须 是 是 是 内容规则 唯一编号，数字型 日期型 100字以内，字符型 92 序号 4 5 6 知识属性 作者 关键字 知识分类 是否必须 是 是 是 人名，字符型 内容规则 一个或多个关键词组成，字符型 可以选择多个知识分类，其中有且只用一个为主分类 7 8 9 10 11 知识有效期 是 问题描述 解决方法 附件 知识密级 是 是 否 是 日期型 图文混排的内容 图文混排的内容 任意类型的附件 普通知识、重要知识、内部知识。 1.1.10. 实施测试

项目测试将按GB/T 15532-2008《计算机软件测试规范》和GB/T 9386-2008《计算机软件测试文档编制规范》进行软件检查、测试和文档的整理报送。

符合ISO9000的过程文件、模版、样例、指南等： 测试过程和规范内容列表 01过程文件 02模板 ST-P-01-软件测试过程.doc ST-T-01-软件测试-01测试计划模版.doc ST-T-02-软件测试-02测试分析报告模版.doc ST-T-03-软件测试-03测试用例模版.xls ST-T-04-软件测试-04测试问题记录表.doc ST-T-05-软件测试-05测试问题跟踪记录表.xls ST-T-06-软件测试-06对外版本发布签字说明模板.xls 03检查表 ST-C-01-软件测试过程检查单.xls ST-C-01-软件测试评审检查表.xls 04指南 ST-G-01-软件测试指南.doc ST-G-02-缺陷跟踪流程.doc 93 ST-G-03-TD缺陷跟踪流程.doc ST-G-04-BUTTERFLY缺陷跟踪流程.doc ST-G-05-QC缺陷跟踪流程.doc 测试管理平台使用指南.doc 05样例 样例1 CTAIS缺陷跟踪流程CQ.doc 软件测试-01功能测试计划.doc 软件测试-01性能测试计划.doc 软件测试-02功能测试分析报告.doc 软件测试-02性能测试分析报告.doc 软件测试-03测试用例.xls 软件测试-04测试问题记录表.doc 软件测试-05测试问题跟踪记录表.xls 样例2 软件测试—01影像系统功能测试计划.doc 软件测试—01影像系统性能测试计划.doc 软件测试—02影像系统功能测试分析报告.doc 软件测试—02影像系统性能测试分析报告.doc 软件测试—03影像系统功能测试用例.xls 软件测试—04影像系统测试问题记录表.doc 软件测试—05影像系统测试问题记录表.xls

94