SPASVO

1. 测试体系方案
1.1. 概述
本节旨在论述如何在XX用户建立测试体系以促进和加强测试管理和测试流程，提高测试质量，保证银行IT产品品质，终达到更好地为金融客户服务的目标。

测试体系是围绕测试活动开展制定的一系列规程、指南、标准、模板，用于管理和规范测试过程，通过引入测试体系可以引入更好地测试方法来优化测试细节；可以通过规定和规范加强流程化管理；可以通过定义指标、标准更准确地反映测试、评估测试。

1.2. 总体思路
详细描述以解决现有不足为目标并结合银行测试管理的现状而设计的测试管理总体解决方案的理念、思路、实现的方式方法。

根据上一节对XX商行测试工作的现状和现实环境的分析，我们了解到在行里建立符合现状和现需求的测试体系，并在该测试体系的指导下建立一批技术过硬的IT测试团队的必要性。本节将着重描述测试体系建设的整体规划和发展路线图。

1.2.1. 测试内容补充
为了进一步提高测试的覆盖度，保证系统质量，需要不断丰富测试的内容，使用“自底向上”的方式检验系统各个层面上的正确性和可靠性。在已有的UAT测试的基础上增加FT测试、SIT测试以及非功能性测试，非功能性测试包含的内容有：性能测试、兼容性测试等等。

1.2.2. 初步模型选型
建立测试体系的第一步是选择适应于目前情况的测试模型。与当前情况相符合主要是指研究目前开发项目和系统的特点，其中包括：项目需求的规模，对测试周期的要求，以及项目所选择的开发模型。

测试模型的选型目标主要是当前比较常用和成熟的测试模型：

瀑布模型

V模型

W模型

迭代模型

进化模型

RUP模型（增量迭代）

在选型过程中，需要选择多种不同的模型以满足现实中不同的开发需求，选型的方法可以参考选择一个主模型以适应IT项目、一个子模型以适应新特性开发、需求变更或紧急情况应急处理。

，选型完成后，可根据自身的需要对模型定义的测试阶段进行删减和补充。

1.2.3. 引进有效的测试方法
1.2.4. 建立规程与标准
在选择适合的测试模型后，测试活动被划分为多个测试阶段和多种针对不同测试目的的测试。例如：

单元测试

集成测试

功能测试（FT）

系统测试（SIT）

用户验收测试（UAT）

1.3. 体系建立
1.3.1. 建设目标
建立测试体系的目的是为测试工作制定周密的管理计划，为测试工作建立标准化流程和标准化文档，为测试单位提供运行的流程和规范。考虑到本项目的特点，我们知道该项目的测试工作需要横跨不同的业务系统，不同系统之间存在着网状的数据流。这种系统的复杂性为测试管理工作提出了严峻的挑战，据此我们需要通过建立测试体系的方法规范化测试流程，使得复杂的联调测试变得易于跟踪和控制，从而达到降低项目风险的目的。

建立测试体系的第一步是要确定一个生命周期模型从整体的角度描述整个项目。

1.3.2. 项目管理过程
将项目的测试管理分为五个阶段和一个日常事务检查表，对每个阶段的工作任务进行说明，包括时间点、任务、提交物等。提供该体系给项目管理人员作为测试项目管理手册，对整个项目的测试工作进行系统的管理、监督。

1.3.3. 流程与控制
该体系是针对项目具体实施过程的，对大运会项目的测试过程实施，在各个里程碑阶段，我们将使用以下体系进行项目测试过程的执行，包括：里程碑接口、里程碑输入信息、参与角色、工作过程、工作内容、输出信息等。

1) 初始阶段

初始阶段主要是给客户做测试过程和测试标准的介绍，加强客户对测试过程和测试标准的了解。

面向对象：对象为项目参与人员（包括管理人员和技术人员）。

介绍内容：

介绍测试过程

介绍测试策略

介绍测试方法和特点

介绍测试结果评估、分析方法

2) 需求分析阶段

前期接口：

初始阶段完成，项目组认可所使用的测试过程、方法等；

基本的测试范围（功能测试、性能测试、自动化测试等）和使用何种测试工具等基本达成一致。

输入：

被测系统的开发文档

被测系统的客户文档

参与角色：

在测试项目中，开发厂商，CSC专家，和测试组都有众多人员的参与，这里阐述了各方在项目中需要的角色和各自的职责。

阶段过程：

测试计划阶段的基本过程如下：

测试需求制定过程：

略

输出：

项目测试计划

项目相关标准

项目测试需求

3) 案例设计阶段

前期接口：

测试设计人员都参与了系统的详细培训

测试设计人员参与了测试工具的培训，掌握了测试工具的试用

输入：

项目测试计划

项目相关标准

项目测试需求

阶段过程：

略

定义测试策略：考察应用程序、系统环境和测试资源等以决定测试目标。

分解测试对象：将AUT（被测应用程序）分解成具体的测试单元（可被测试的模块和功能）。

定义测试案例：确定每个模块所需的测试类型，添加基本的定义描述。

建立需求覆盖：将具体的测试案例和需求建立覆盖关系。

设计测试步骤：为每个测试案例添加测试步骤。测试步骤描述测试的操作、检查点和预期输出。

分析测试案例：评审所有测试案例以确保符合测试目标。

输出：

测试案例

4) 执行阶段

前期接口：

测试案例设计并审核完毕

输入：

测试案例

阶段过程：

输出：

测试执行记录

缺陷记录单

缺陷跟踪汇总表

缺陷跟踪：

汇报缺陷记录

跟踪缺陷修改情况

回归测试直到缺陷得到恰当处理（是否进行缺陷跟踪要根据客户要求不同而定）

5) 总结分析阶段

前期接口：

测试执行工作完成

输入：

测试执行记录

缺陷记录

缺陷跟踪汇总表

阶段过程：

本阶段包含四个步骤：

整理数据：整理测试过程数据和缺陷数据，以备分析之需。

分析数据：根据收集整理的测试过程数据和缺陷数据对测试过程和系统情况进行分析。

编制总结分析报告：对项目进行总结，在整理数据和分析数据的同时即可进行该项工作，待数据分析完成后，将分析结果增加到报告中，并将总结分析报告提交给开发部，业务部，以便开展项目评估工作。

调查客户满意度：总结完成后，由开发部，业务部人填写满意度调查表，调查结果供测试过程改进和项目评估参考。

项目评估：由项目双方（开发部，业务部和测试组）相关人员一起，根据评估项及其统计数据对项目完成情况进行评估。

略

输出：

测试总结分析报告

项目评估报告

1.3.4. 项目测试标准
1) 缺陷相关标准

严重级别：

5 紧急

导致操作系统崩溃（如Win NT/2000 的篮屏、Win 98 的系统致命错误等）

导致操作系统不响应

程序退出没有释放资源

导致其它应用程序出现异常（如无法启动、不响应、异常退出）

卸载时不提示客户确认即删除公用程序（DLL 等）

其它导致操作系统或其它应用程序异常的情况

造成重大安全隐患情况（如机密性数据的泄密）

4 很高

程序挂起

程序异常退出

系统无法正常安装、卸载或升级

其它导致被测系统本身出现无法正常运行的错误

3 高

导致输出的数据错误（数据内容出错、格式错误、无法打开等）

导致其它功能模块无法正常执行，如：

功能不完整或功能实现不正确；

导致数据终操作结果错误

文件或数据传输不完整或不正确

对数据格式不进行检测

提示语句易误导用户，造成数据丢失等重大问题

其它导致被测应用系统其它模块无法正常运行或出现错误结果的情况

2 中等

影响当前操作结果

数据修改后没有保存提示

系统出错提示不正确或没有捕获系统出错信息

数据的重要操作（如删除、添加等）没有提示

其它影响被测模块/功能正常执行的情况

1 低

页面布局不合理

字体不一

错别字

语言不一致（如：中英文混合）

页面提示不明确

系统易用性不好

其它对被测模块功能实现没有影响的情况

缺陷导入阶段：

1. 需求阶段

未能真正了解客户需求，功能描述不正确

需求定义有二义性

需求中遗漏客户功能需求

2. 概要设计阶段

架构设计不正确

业务流程设计错误

3. 详细设计阶段

功能模块间数据格式定义不一致

开发规范

4. 编码阶段

5. 其它

缺陷优先级：

3 必须修改

2 将要修改

1 有时间则改

0 未分配

缺陷类型：

程序错误

环境设置

重复记录

需要完善

不可重现

并非问题

1.4. 测试体系涵盖的其它内容
1.4.1. 规范和强化测试子流程
略

1.4.2. 规范和强化测试流程
测试流程可分为两支：

自动化测试流程；

手工测试流程。

1.4.3. 标准化、规范化测试对象
在测试活动中通过标准化、规范化测试资源使测试资源可以被共享和重用。

如果测试对象缺乏必要的标准化、规范化，会导致测试案例等测试对象无法共享。例如，很多测试团队的测试案例编写缺乏规范，导致：

测试案例“个性化”、“个人化”，只有自己才能够“看懂”自己的测试案例来进行测试执行，其他的测试工程师无法使用其他人的测试案例来进行测试；

测试设计人员和测试执行人员无法分离，高成本的测试设计人员必须自己来执行测试案例，而不能使用低成本的测试执行人员来执行测试案例，导致无法达到很好的劳动组合，提高工作效率，也大大占用了经验丰富的测试设计人员的时间。

对于测试过程也需要进行控制，只有进行测试对象的标准化、规范化，才能够进行测试案例评审，进一步提升测试案例的质量。

1.4.4. 测试对象复用，降低测试成本
测试对象复用，主要指测试案例复用、测试脚本复用、测试计划复用。

1.4.5. 建基于模型驱动的自动化测试架构
一般情况下，如果一个测试需要执行3次以上，那么自动测试的成本能够和手工测试持平。随着执行测试的不断增加（特别是后期的回归测试），测试成本大大小于手工测试执行。

随着测试技术的发展，很多测试脚本能够通过灰盒测试方法，通过自动转换程序技术来自动生成，能够把测试工作大大提前，并且测试脚本的编写成本大幅度下降。

1.4.6. 定制流程管理缺陷，定制查询
实现缺陷流程定制化。根据项目特点，定制有针对性的缺陷管理流程。为每一个测试角色分配缺陷处理的权限。使得每个测试人员的分工更明确，人员配置更合理。

在缺陷跟踪之前定制查询。通过定制常用的查询规则，例如：当日提交给我待解决的缺陷、所有解决的缺陷等等，测试员和开发人员将有针对性地关注缺陷，测试经理也可以即时了解问题解决情况。

基于Test Center的测试体系可以划分为8个子模块，见下图。

缺陷管理模块：

支持缺陷管理流程，可以定制缺陷管理流程，支持缺陷流程的是一个工作流；

可定制的缺陷过滤器。用户根据自身的需要定义过滤器。通过输入查找条件，将查询规则定义为过滤器。通过这种方式，用户可以更快地找到自己所关心的缺陷，例如“剩余的没解决的缺陷”之类；

支持缺陷报告，缺陷报告以图表和图的方式展示处于各个状态的缺陷，以及各个紧急程度分类上的缺陷。缺陷报告还提供了缺陷关闭、打开曲线图，用以了解每日缺陷的关闭和打开趋势。

1.4.7. 生成测试报告
生成详尽的测试报告，包括执行情况、缺陷情况、需求达成情况使得项目重要干系人即使了解项目进程，了解问题的分布情况，即时分析和规避开发风险。

1.4.8. 测试环境管理
管理开发和测试资源，使用预约的方式将资源分配给人员和组，为资源分配提供管理和监控的解决方案。