XXX银行软件测试规程(试用版).doc

详细向xxxx银行测试规程XXXX银行软件测试规程(试用版)XXXX银行信息科技部2007年3月目录第一章前言7一、背景7二、术语定义7第二章单元测试10一、概述10二、参与人员与职责10三、测试流程11四、单元测试评估与审计14五、测试评估数据15六、单元测试完成标准15七、培训15八、单元测试环境16九、单元测试工具16第三章集成测试17一、概述17二、参与人员与职责17三、测试流程18四、集成测试评估与审计21五、测试评估数据21六、集成测试完成标准21七、培训22八、集成测试环境22九、集成测试工具22第四章系统测试24一、概述24二、参与人员与职责24三、测试流程26四、系统测试的评估与审计30五、测试评估数据30六、系统测试完成标准30七、培训31八、系统测试环境31九、系统测试工具31十、系统测试报告31第五章压力测试33一、概述33二、参与人员与职责33三、测试流程35四、压力测试的评估与审计40五、测试评估数据40六、压力测试完成标准40七、培训41八、压力测试环境41九、集成测试工具41十、系统测试报告41附件43第一章 前言一、 背景随着xxxx银行业务规模和种类的迅速发展，银行IT系统的数量和种类不断增加，系统的复杂程度和规模也日益增加。因此，通过必要的技术和管理手段保证IT系统开发的质量，最终保证上线系统的稳定运行，成为IT系统软件开发的重要工作。软件测试是保证IT系统软件质量的重要手段。为了规范XXXX银行IT系统开发中软件测试管理工作，确保开发的IT系统充分满足业务需求，提高IT系统开发的质量，根据软件工程学关于测试管理的理论和方法论，结合我行实际，制定本测试规程。二、 术语定义l 软件测试：是指通过一定的制度、方法、技术、流程和工具对软件测试对象进行检查、验证和分析，根本目的是验证和确认软件测试对象与需求的一致性，最终保证软件系统的质量。一个IT系统的软件测试分为单元测试、集成测试、系统测试和压力测试四个阶段进行。每个阶段的测试依次完成四个子阶段的工作：计划、设计、实现和执行。l 软件测试对象：软件测试对象包括程序模块、功能模块和软件系统三个层面。IT系统软件的最小组成单元是程序模块，功能相关联的一组或多组程序模块通过有机的组合构成实现特定系统功能的功能模块，一个或多个功能模块构成最终完整的软件系统。l 软件测试管理：是指按照预定义的管理办法，通过一定的流程和工具，对软件测试工作进行有效管理，并对软件测试工作进行审计和状态报告的系统方法。l 单元测试：完成对程序模块的验证工作，以确认每个程序模块的功能与详细设计相符。单元测试重点是测试程序模块的功能，以及语句与分支的覆盖率，由此来检验程序模块在各种情况下运行结果都是设计这所预定的结果。l 集成测试：完成对功能模块的验证工作，以确认各功能模块功能以及功能模块之间的交互功能与概要设计相符，最终形成概要设计中描述的完整的IT系统。集成测试的重点在于各个功能模块之间的各种接口，测试每个接口在各种情况下都正确，并测试一些预定的非正常输入情况下，处理是否合理有效。l 系统测试(功能测试、综合测试)：是对整个系统的功能测试，以确认系统各种功能和系统的业务需求书一致。系统测试的重点是从系统的角度证明系统总体功能的正确性、与关联系统的协调性和时序的准确性。系统测试还应当确认系统其他的需求也都被满足，如：可恢复性，可移植性，错误恢复，可维护性等。l 压力测试(性能测试)：是对整个系统的性能测试，以确认系统符合业务需求部门在交易高峰期间对系统处理能力的要求。压力测试不同于功能测试，软件的正确性并不是它的测试重点。它所看重的是软件的执行效率，它以软件响应速度为测试目标，尤其是短时间内访问用户数爆炸性增长时软件的响应速度。l 回退测试：在以上任何阶段测试中发现问题后，要对有关程序进行相应的修改，修改后还要进行回退测试。回退测试是指对于一个被测对象(可以是程序模块、功能模块或整个软件系统)不仅要用原来发现其错误的测试案例进行测试，看其结果是否有了变化而且符合要求，还要设计新的测试案例来观察其修改后的功能是否完全正确，同时，还要用原有的其他测试案例来看原先没有修改的功能是否仍然正确。l 测试计划：是各阶段测试的基础，主要是确定测试的对象、范围；评估测试需要的时间和工作量；明确测试队伍的角色分工、工作任务划分和所需的培训；规划测试资源、工具和数据；定义测试完成标准。测试计划应该在测试工作执行前的较长时间就开始。最早的测试计划可以在需求规格说明书完成后开始。l 测试设计：设计测试方案，主要工作包括对测试对象进行深入分析，确定测试策略、测试方法、测试环境和测试工具，并进一步评估测试的工作量。l 测试实现：将测试设计的结果转化成可以操作和使用的程序、脚本和测试工具，主要工作包括设计测试案例、测试规则；编写测试代码、测试脚本；落实测试工具。l 测试执行：在测试环境按照测试案例完成测试是，主要工作包括执行测试案例；记录、分析、解决测试过程中发现的错误，并执行回退测试；评估测试结果，提交测试总结报告。l 软件测试环境：是指满足软件系统测试要求的硬件、网络和系统软件环境，包括主机、存储、网络、外围设备、操作系统软件、数据库、中间件、系统配置参数和测试用业务数据等。l 软件测试标准：是指判断各个测试阶段是否可以开始、结束和通过的衡量标准。软件测试标准包括测试阶段入口条件、测试阶段出口条件和测试阶段通过标准三部分。l 软件测试工具：是指用于软件系统测试的方法、数据和应用软件系统。第二章 单元测试一、 概述软件系统的单元测试是对系统基本组成单元进行的测试，以确认每个基本单元的功能与详细设计相符。这里的基本单元可以是一个具体的函数(function或procedure)(C语言)、一个类的方法(method)(C+)、一个菜单或显示界面(4GL)、一组完成基本功能的函数等。“单元”具有一些基本属性，如：明确的功能、规格定义、与其它单元明确的接口定义等，可以清晰地与同一程序的其它单元划分开来。单元测试除了要检测程序代码的错误外，它的重点在于测试基本单元的功能是否和详细设计的要求一致。单元测试的主要目的有：l 验证程序代码的功能与详细设计相符；l 跟踪系统需求与设计的实现方式；l 发现系统需求分析和设计中存在的错误；l 发现在编码过程中引入的错误。l 单元测试的工作由程序开发员在编码过程中实现。二、 参与人员与职责1 项目组：1) 项目经理密切监控项目的进度，及时配置相应的资源；确保单元测试按照单元测试计划有序进行；确认并为进行单元测试的程序开发人员提供必要的培训；定期向总经理室汇报项目进度；2) 程序开发员l 编写单元测试案例；l 编写单元测试代码(如果需要)；l 执行单元测试，记录测试结果；l 记录单元测试错误报告；l 撰写单元测试报告。3) 配置管理员l 对原代码和可执行代码打基线；l 对单元测试记录、错误报告和测试报告进行归档、打基线和变更审计工作。2 质量管理处：l 对单元测试的合规性(是否符合测试计划和测试规则的要求)进行指导和审计，并提交审计报告；l 根据单元测试报告(主要是测试发现的错误和缺陷情况)，对单元测试进行定量分析，并向总经理室提交单元测试是否通过的审核意见。3 总经理室：对单元测试结果进行审批。三、 测试流程1. 计划(1) 时间安排在概要设计完成评审后约一周后开始。(2) 输入项目开发计划项目需求规格说明书概要设计文档(3) 入口条件l 概要设计文档已经通过评审。(4) 活动步骤l 确定单元测试的总体策略，具体包括：n 决定采用何种测试方式，包括自顶向下、自底向上和孤立测试三种方式，可以根据被测试系统的具体特点选择其中一种，也可以组合多种方式；n 决定是否使用已有的输入、输出或数据源(例如其它项目单元测试使用的测试文档和测试数据发生器等)l 确定被测试对象和测试范围；l 确定单元测试的完整性需求，具体包括：n 单元的接口；n 单元内的局部数据结构；n 单元内部逻辑中的对立路径；n 单元的出错处理机制；n 单元逻辑中的边界条件；n 对单元代码测试覆盖率(包括功能特性、过程、状态、函数、数据特性、指令等)；n 系统的特殊需要，包括系统的性能、安全性、保密性等；l 评估单元测试的工作量，需要考虑测试对象的数量、难度，以及测试代码开发的工作量；l 确定测试角色分工，划分工作任务；l 标识出测试的时间进度、任务、约束等条件；l 考虑一定的风险分析及应急计划；l 考虑和准备单元测试需要的测试人员、工具、数据、环境等资源；l 考虑相关培训安排；l 定义测试完成标准。(5) 输出单元测试计划。(6) 出口条件单元测试计划通过概要设计阶段的基线评审。2. 设计(1) 时间安排在详细设计完成评审后约一周后开始。(2) 输入l 项目需求规格说明书l 系统详细设计文档l 单元测试计划l 以往项目的单元测试文档(如果有)(3) 入口条件l 概要设计阶段基线通过评审。(4) 活动步骤l 分析单元测试的策略，据此将被测试单元进行分组，确定测试顺序；l 分析单元测试的完整性需求和被测单元的特征，据此将被测试单元进行分组，制定设计可以复用的测试代码结构；l 分析被测对象的特征，设计测试案例的结构和内容；l 分析以往项目的单元测试文档，选择可以复用的单元测试设计方案、测试案例和测试数据发生器；l 分析单元测试需要的测试工具，并从以往的单元测试工具中选择可以复用的工具；l 分析单元测试的环境和约束条件；l 进一步评估单元测试的工作量，安排单元测试分工。(5) 输出l 单元测试设计方案。(6) 出口条件l 单元测试设计方案通过详细设计阶段的基线评审。3. 实现(1) 时间安排在编码阶段开始后进行。(2) 输入l 项目需求规格说明书l 系统详细设计文档l 单元测试计划l 单元测试设计方案l 以往项目的单元测试文档(如果有)(3) 入口条件 详细设计阶段基线通过评审。(4) 活动步骤l 将单元测试设计阶段选择出来的以往的单元测试案例与相应的被测单元关联起来；l 编写单元测试案例；l 编写单元测试规则；l 编写单元测试代码(如果需要)；l 编写单元测试脚本(如果需要)；l 选择和落实单元测试工具(如果需要)。(5) 输出l 单元测试案例；l 单元测试规则；l 单元测试代码(如果有)；l 单元测试脚本(如果有)；l 单元测试工具(如果有)。(6) 出口条件l 单元测试案例和测试规则通过编码阶段基线评审。4. 执行(1) 时间安排 单元测试执行子阶段的主要工作通常在系统程序编码工作完成进行，部分比较简单的单元测试工作可以伴随编码过程同时进行。(2) 输入l 项目需求规格说明书；l 系统详细设计文档；l 单元测试计划；l 单元测试设计方案；l 单元测试案例；l 单元测试规则；l 单元测试代码(如果有)；l 单元测试脚本(如果有)；l 单元测试工具(如果有)；l 系统程序代码。 (3) 入口条件l 单元测试设计与实现子阶段已经通过基线评审。 (4) 活动步骤l 执行单元测试案例；l 对测试过程中发现的错误进行记录、分析、解决，并执行回退测试；l 评估单元测试结果；l 更新所有相关的系统设计文档；l 撰写单元测试记录、测试事件报告和单元测试报告。(5) 输出l 单元测试报告；l 用于单元测试的测试程序源代码、文档和可执行代码；l 更新后的系统程序源代码和可执行代码；l 经过更新的所有相关的系统设计文档；l 经过更新的所有相关的系统计划文档。(6) 出口条件l 单元测试报告和测试文档通过单元测试阶段评审；l 单元测试中发现的问题已经得到解决并获得批准。四、 单元测试评估与审计1. 单元测试开始前举行测试准备情况审核会；2. 单元测试结束前举行测试结束审核会；3. 质量管理处根据通过标准验收清单进行逐项核验工作；4. 质量管理处对整个单元测试过程的合规性进行审计；5. 版本管理员对测试后的系统打基线，并向项目组，总经理室和质量管理处提交系统版本情况报告。五、 测试评估数据l 单元测试中发现的错误/缺陷；l 按照内容对错误/缺陷进行分类；l 按照严重程度对错误/缺陷进行分类；l 按照造成的原因(系统设计错误还是编码错误)对错误/缺陷进行分类；l 单元测试投入的时间和工作量。六、 单元测试完成标准1 完备性：l 所有的单元测试案例都是按照测试计划确定的完整性需求完成的设计和实现；l 所有的单元测试案例都按照测试计划完成测试； l 关键模块经过充分测试；l 测试中发现的错误得到修改后，都完成回退测试。2 正确性：l 所有的测试案例都被正常执行，被测试的单元符合详细设计规定的功能；l 被测试的单元符合测试计划确定的完整性需求；l 测试中发现的错误得到修改后，经过回退测试证明修改正确；3 文档的一致性：l 单元测试的测试计划、设计方案，以及所有测试案例、测试数据记录、测试错误分析、测试错误修改、测试总结报告都以文档的形式按照规定保存；l 单元测试中发现的问题被解决后，系统相关的概要设计、详细设计、代码和单元测试案例都得到相应的修改和归档，保证系统文档内容的一致性。4 经过正式审核：单元测试结果和测试报告需要经过项目经理、质量管理处和总经理室三级审批通过。七、 培训项目经理应当确认将要执行单元测试工作的程序开发人员的培训需求，并尽快协调有关方面落实培训。比如测试人员不熟悉单元测试工具，需要向他们提供这方面的非正式培训解决。八、 单元测试环境1) 硬件环境单元测试可以在开发环境或与开发环境隔离的模拟生产环境中进行。2) 操作系统环境要充分考虑不同机型使用的不同操作系统版本。对于实际环境可能使用的操作系统环境，尽可能都要测试到。3) 数据库和中间件环境数据库和中间件的选择要根据实际的需要，确保软件版本与生产版本一致。4) 网络环境单元测试在局域网内进行，个别需要与行外其它网络连接的测试案例，可以通过仿真程序完成。九、 单元测试工具1 测试记录表格、错误报告表格；2 编译器、debugger工具和编辑器；3 为本次单元测试专门编写的测试程序；4 以往单元测试使用的可以复用的测试程序；5 用于单元测试不同方面的商业测试工具软件，如代码静态分析工具、代码检查工具、代码功能测试工具、代码动态覆盖率测试工具、内存泄漏检测工具、回归测试工具等。第三章 集成测试一、 概述软件系统的集成就是将一系列的软件单元组装在一起，构建一个完整的软件系统。在构建软件系统的过程中，系统的集成工作存在于不同的层次程序单元集成为功能模块，功能模块集成为子系统，子系统集成为软件系统。所以集成测试也存在于这些层次功能模块，子系统，软件系统。集成测试，也叫组装测试、联合测试或部件测试，它是通过测试验证组装后不同的功能模块之间的是否能够正常协同工作，从而确认组装起来的软件系统符合总体设计的要求，可以在不导致系统瘫痪的情况下执行系统功能。集成测试的重点在于各个功能模块之间的各种接口，测试每个接口在各种情况下都正确，并测试一些预定的非正常输入情况下，处理是否合理有效。应当在不同层次的集成测试引入不同的测试策略和方法。集成测试的工作由各功能模块的程序开发员通过测试共同实现。二、 参与人员与职责l 项目组：1) 项目经理l 密切监控项目的进度，及时配置相应的资源；l 确保集成测试按照集成测试计划和方案有序进行；l 确认并为进行集成测试的程序开发人员提供必要的培训；l 定期向总经理室汇报项目进度；l 及时向业务部门通报集成测试的进展(如果需要)。2) 程序开发员l 编写集成测试案例；l 执行集成测试，记录测试结果；l 记录集成测试错误报告；l 撰写集成测试报告。3) 配置管理员l 对原代码和可执行代码打基线；l 对集成测试记录、错误报告和测试报告进行归档、打基线和变更审计工作。2. 质量管理处：l 对集成测试的合规性(是否符合测试计划和测试规则的要求)进行指导和审计，并提交审计报告；l 根据集成测试报告(主要是测试发现的错误和缺陷情况)，对集成测试进行定量分析，并向总经理室提交集成测试是否通过的审核意见。3. 总经理室：对集成测试结果进行审批。三、 测试流程l 计划1) 时间安排在概要设计完成评审后约一周后开始。2) 输入l 项目需求规格说明书l 概要设计3) 入口条件l 概要设计文档已经通过评审。4) 活动步骤l 确定被测试对象和测试范围；l 评估集成测试被测试对象的数量、难度，即工作量；l 确定测试角色分工和划分工作任务；l 标识出测试各阶段的时间、任务、约束等条件；l 考虑一定的风险分析及应急计划；l 考虑和准备集成测试需要的测试人员、工具、数据、环境等资源；l 考虑外部技术支援的力度和深度，以及相关培训安排；l 定义测试完成标准。5) 输出l 集成测试计划。6) 出口条件l 集成测试计划通过概要设计阶段的基线评审。l 设计u 时间安排详细设计阶段开始。u 输入l 项目需求规格说明书l 概要设计l 集成测试计划u 入口条件l 概要设计阶段基线通过评审。u 活动步骤l 分析被测对象的结构；l 分析集成测试的功能模块；l 分析集成测试的接口；l 分析集成测试的策略；l 分析集成测试需要的测试工具；l 分析集成测试的环境；l 进一步评估集成测试的工作量，安排集成测试分工。u 输出l 集成测试设计方案。u 出口条件l 集成测试设计方案通过详细设计阶段的基线评审。l 实现1) 时间安排在编码阶段开始后进行。2) 输入l 项目需求规格说明书l 概要设计l 集成测试计划l 集成测试设计3) 入口条件l 详细设计阶段基线通过评审。4) 活动步骤l 编写集成测试案例；l 编写集成测试规则；l 编写集成测试代码(如果需要)；l 编写集成测试脚本(如果需要)；l 落实集成测试工具(如果需要)。5) 输出l 集成测试案例；l 集成测试规则；l 集成测试代码(如果有)；l 集成测试脚本(如果有)；l 集成测试工具(如果有)。1) 出口条件l 集成测试案例和测试规则通过编码阶段基线评审。l 执行u 时间安排 单元测试完成后就可以开始执行集成测试了。u 输入l 项目需求规格说明书；l 概要设计；l 集成测试计划；l 集成测试设计；l 集成测试案例；l 集成测试规则；l 集成测试代码(如果有)；l 集成测试脚本(如果有)；l 集成测试工具(如果有)；l 系统详细设计；l 系统程序代码；l 单元测试报告。u 入口条件l 单元测试阶段已经通过基线评审。u 活动步骤l 执行单元测试案例；l 对测试过程中发现的错误进行记录、分析、解决，并执行回退测试；l 评估集成测试结果；l 撰写集成测试记录、测试事件报告和集成测试报告。u 输出l 集成测试报告；l 更新并打了基线的系统程序源代码和可执行代码；l 经过更新的所有相关的系统设计文档；l 经过更新的所有相关的系统计划文档；u 出口条件一、 集成测试报告通过集成测试阶段评审。四、 集成测试评估与审计n 集成测试开始前举行测试准备情况审核会；n 集成测试结束前举行测试测试结束审核会；n 质量管理处进行通过标准验收清单逐项核验工作；n 质量管理处对整个集成测试过程的合规性进行审计；n 版本管理员对测试后的系统打基线，并向项目组，总经理室和质量管理处提交系统版本情况报告。五、 测试评估数据1. 集成测试中发现的错误/缺陷；2. 按照内容对错误/缺陷进行分类；3. 按照严重程度对错误/缺陷进行分类；4. 按照造成的原因(系统设计错误还是编码错误)对错误/缺陷进行分类；5. 集成测试投入的时间和工作量。六、 集成测试完成标准1 完备性：l 集成测试按照一定的层次进行，所有三个层次的集成测试应当全部完成-功能模块，子系统，软件系统；l 所有公共的接口都被测试到，包括软件系统与系统外的其它系统间的接口；l 关键模块经过充分测试；l 所有的集成测试案例都按照测试计划完成测试； l 测试中发现的错误得到修改后，涉及的相关接口都完成回退测试，证明修改正确。2 正确性：l 在把各个软件单元连接起来时，通过单元接口的数据没有丢失或被更改；l 各个子功能组合起来能够达到概要设计要求的父功能；l 一个软件单元的功能不会对另一个软件单元的功能产生不利影响；l 全局数据结构没有问题，不会被异常修改；l 单个程序单元的误差积累起来，不会出现放大效应，以致达到不可接受的程度，导致整个系统工作异常。l 所有的测试案例实现正常完成，符合概要设计规定的功能，并且在测试过程中整个系统工作正常，不出现宕机、系统资源耗尽、系统效率异常等情况；3 文档的一致性：l 集成测试的所有测试案例、测试数据记录、测试错误分析、测试错误修改、测试总结报告都以文档的形式按照规定保存；l 集成测试中发现的问题被解决后，系统相关的概要设计、详细设计、代码和集成测试案例都得到相应的修改和归档，保证系统文档内容的一致性。4 经过正式审核：集成测试结果和测试报告需要经过项目经理、质量管理处和总经理室三级审批通过。七、 培训项目经理应当确认将要执行集成测试工作的程序开发人员的培训需求，并尽快协调有关方面落实培训。比如测试人员不熟悉系统其它部分的代码，需要向他们提供这方面的非正式培训解决。八、 集成测试环境1. 硬件环境集成测试可以在与开发环境隔离的模拟生产环境中进行。在搭建模拟生产环境时，需要分析模拟环境与实际环境之间可能存在的设备性能、网络连接、交易产生方式等方面的差异，并尽可能通过编写仿真程序减少这种差异。2. 操作系统环境要充分考虑不同机型使用的不同操作系统版本。对于实际环境可能使用的操作系统环境，尽可能都要测试到。3. 数据库和中间件环境数据库和中间件的选择要根据实际的需要，从性能、版本、容量、我行现有资源等多方面考虑。4. 网络环境集成测试原则上在局域网内进行，个别需要与行外其它网络连接的测试案例，可以通过仿真程序完成。九、 集成测试工具l 测试记录表格、错误报告表格；l 测试模拟环境；(如果需要)l 测试工具软件。由于集成测试关注的是模块之间接口的个性化特点，能够直接用于集成测试的商用测试工具并不多，因此，能够有效支持系统集成测试的工具主要以项目组自行开发为主；l 用于单元测试的一些测试工具可以用于集成测试；l 对于一些以界面为主的集成测试或者基于公共协议的集成测试，可以寻找一些商用的测试工具第四章 系统测试一、 概述系统测试指的是完成对整个系统的功能测试，以确认系统各种功能和系统的业务需求书一致。系统测试的重点是从系统的角度证明系统总体功能的正确性、与关联系统的协调性和时序的准确性。系统测试还应当确认系统其他的需求也都被满足，如：系统安装与恢复，数据备份，运行可维护性等。系统测试又成为“功能测试”或“综合测试”。系统测试的目标是：1. 确认软件系统在仿真实际生产环境中，能够无错误地和可重复地实现系统业务需求书要求的功能，以及系统设计的隐性功能。2. 系统没有不正确或遗漏的功能。3. 确定并记录软件系统的性能特征和指标。4. 为压力测试和即将到来的上线投产提供一个功能完整的，文档齐全，运行稳定的系统版本。在系统测试正式进入到执行测试子阶段前，必须召开一次正式的测试准备情况审核会，以便保证系统测试工作在充分准备并合乎测试要求的情况下进行，保证测试的效率和质量。审核工作可以通过审核集成测试结果、系统测试方案、以及任何为系统测试开发的支持程序代码等来完成。在项目组和测试队伍之间应当对系统测试应该完成的程度、测试流程的有效性以及测试结果的理解达成共识。该部分的工作由提出项目需求的业务部门人员、测试团队和项目组人员在集成测试后合作完成。二、 参与人员与职责1. 提出需求的业务部门l 负责系统测试的组织和实施工作；l 编制系统测试计划；l 协调业务人员、开发项目组和第三方测试人员完成系统测试；l 协调和组织系统测试过程中错误/缺陷的修改和回退测试，并及时修改测试计划以反映实际情况；2. 测试团队（包括项目组测试人员和第三方测试人员）：l 进行系统测试设计；l 编写系统测试案例和测试框架；l 开发测试脚本；l 审核第三方测试团队提交的测试案例；l 确定系统测试工具；l 执行系统测试，记录测试结果，形成系统测试事件报告；l 收集并提交测试评估数据；l 与业务测试员沟通确定测试中发现错误/缺陷的严重级别；l 执行错误/缺陷修改后的回退测试；l 向项目组开发人员通报和说明系统测试过程中发现的问题；l 撰写系统测试总结报告。3. 项目组：1) 项目经理密切监控系统测试的进度，及时修改项目计划以反映情况的变化；为配合系统测试安排必要的程序开发资源；及时向业务部门通报系统测试及项目的进展情况(如果需要)；跟踪系统测试过程中发现问题的解决；2) 程序开发员l 根据系统测试报告更新程序源代码和相关文档，并进行必要的单元测试和集成测试；l 与项目经理就测试中发现问题的解决方案进行沟通。3) 配置管理员l 对原代码、可执行代码和项目相关文档打基线；l 负责整理、保存和维护系统测试资产，包括测试方法、测试案例、测试报告测试数据等；l 对系统测试记录、错误报告和测试报告进行归档、打基线和变更情况审计工作。4. 质量管理处：l 根据测试计划协调全部门的测试资源，保证系统测试顺利进行；l 负责组织测试团队需要的系统测试相关知识和技能培训。l 配合业务部门确保系统测试按照系统测试计划和方案有序进行；l 对系统测试过程的合规性进行监督和审计；l 定期向总经理室汇报系统测试进度；l 根据系统测试团队提交的系统测试报告对系统测试结果进行定量分析，提交系统测试评估和审计报告。三、 测试流程1. 计划1) 时间安排在需求分析完成后开始。2) 输入l 项目需求规格说明书；l 项目需求分析说明书；3) 入口条件需求分析文档已经通过评审。4) 活动步骤l 确定系统测试的内容：根据以下清单确认系统测试的范围和内容：n 功能测试：对项目需求规格说明书说述功能的测试；n 文档测试：对开发团队提供的各类操作手册内容的测试；n 备份测试：对系统备份机制的测试；n 恢复性测试：对系统从硬件或软件失败中恢复的能力测试；n 安装测试：对系统安装流程有效性的测试。l 评估系统测试的工作量，确定需要的时间和人力资源；l 确定系统测试进度, 标识出测试各阶段的时间、任务、约束等条件；l 组织系统测试团队，确定测试角色分工和划分工作任务；l 确定系统测试环境；l 确定和准备系统测试需要的工具、数据、环境等资源；l 考虑一定的风险分析及应急计划；l 考虑外部技术支援的力度和深度，以及相关培训安排；l 定义测试完成标准。5) 输出l 系统测试计划。6) 出口条件l 系统测试计划通过需求分析阶段的基线评审。2. 设计1) 时间安排概要设计阶段开始。2) 输入l 项目需求规格说明书；l 项目需求分析说明书；l 系统测试计划。3) 入口条件l 需求分析阶段基线通过评审。4) 活动步骤l 分析被测系统的功能组成；l 分析被测系统与外围关联系统的关系；l 分析系统测试的策略、过程和标准；l 分析系统测试需要的测试工具；l 分析系统测试的环境；l 进一步评估系统测试的工作量，安排系统测试分工。5) 输出l 系统测试设计方案。6) 出口条件l 系统测试设计方案通过概要设计阶段的基线评审。3. 实现1) 时间安排在详细设计阶段开始后进行。2) 输入l 项目需求规格说明书；l 项目需求分析说明书；l 系统测试计划；l 系统测试设计方案；3) 入口条件l 概要设计阶段基线通过评审。4) 活动步骤l 设计系统测试案例；l 设计系统测试规则；l 设计系统测试代码(如果需要)；l 编写系统测试脚本(如果需要)；l 落实系统测试工具(如果需要)。5) 输出l 系统测试案例；l 系统测试规则；l 系统测试代码(如果有)；l 系统测试脚本(如果有)；l 系统测试工具(如果有)。6) 出口条件l 系统测试案例和测试规则通过详细设计阶段基线评审。4. 执行1) 时间安排 集成测试完成后就可以开始执行系统测试了。2) 输入l 项目需求规格说明书；l 项目需求分析说明书；l 系统程序源代码；l 集成测试报告；l 系统测试计划；l 系统测试设计方案；l 系统测试案例；l 系统测试规则(如测试顺序、进程等)；l 系统测试代码(如果有)；l 系统测试脚本(如果有)；l 系统测试工具(如果有)；l 测试记录表；l 测试事件报告表；l 测试准备报告；l 测试环境（设备、网络、系统软件等）l 测试通过标准验收清单；3) 入口条件l 系统源代码被没有任何问题地集成为一体；l 集成测试阶段已经通过基线评审，所有在集成测试阶段发现的问题已经解决；l 集成后的系统源代码已经打上基线，并且在交给测试团队进行系统测试后没有进行任何改动；l 系统测试计划已经获得批准；l 已经开过测试准备情况审核会；l 系统测试所需要的各种资源已经确认并可以得到；l 系统测试案例和测试规则已经获得审核和批准；l 总经理室已经批准进行系统测试。4) 活动步骤下面列出了测试过程需要进行的活动。根据被测试系统的特点，下列部分或全部活动将被执行。l 测试团队根据测试计划执行系统测试；l 将所有的系统测试工作记录到测试记录表中；l 系统测试过程中发现的问题被记录到测试事件报告表和错误记录工具中；l 将系统测试中发现的所有问题通报给开发项目组；l 开发项目组根据测试团队提供的错误事件报告对对错误的严重性进行分级；l 如果系统测试发现了重大错误导致继续进行测试没有意义，则应当暂停系统测试，待开发项目组将问题解决后再恢复系统测试；l 系统测试应当一直进行到确认软件系统满足了项目需求规格说明书上的需求后才能结束；l 测试团队提交系统测试总结报告；l 在系统测试阶段结束前，应当召开测试结束审核会，对整个系统测试工作进行审核，以便确认系统测试计划要求的所有工作已经完成，测试中发现的所有问题已经得到修改和回退测试；l 质量管理处应当按照测试通过标准验收清单逐项核验，在确认系统满足验收单所列的条件时，方可批准系统测试完成。5) 输出l 经过系统测试后的程序源代码；l 系统测试记录报告；l 更新后的项目文档；l 测试数据分析报告；l 系统测试总结报告；l 质量管理处核准的测试通过标准验收清单。6) 出口条件l 系统满足项目需求规格说明书对功能的要求；l 系统测试计划中定义的测试工作内容全部完成；l 系统测试中发现的所有问题(特别是严重程度高的)都得到解决或有了处理结论；l 测试记录和测试事件报告已经归档；l 项目的所有文档已经根据系统测试情况进行了更新和归档；l 系统测试总结报告通过评审。1) 系统测试的评估与审计1 系统测试开始前举行测试准备情况审核会；2 系统测试结束前举行测试测试结束审核会；3 质量管理处进行通过标准验收清单逐项核验工作；4 质量管理处对整个系统测试过程的合规性进行审计；5 版本管理员对测试后的系统打基线，并向项目组，总经理室和质量管理处提交系统版本情况报告。2) 测试评估数据1. 系统测试投入的时间和工作量；2. 压力测试中发现的错误/缺陷总数；3. 按照内容分类的各种错误/缺陷总数；4. 按照严重程度分类的各种错误/缺陷总数；5. 对即将上线系统功能的质量评级；6. 对系统测试资源(人员、日程、软硬件资源等)需求估算的准确度；7. 测试期间遇到的需要进行系统变更的次数；8. 实现系统变更投入的时间和工作量总和；9. 测试人员为了按时完成系统测试工作的加班时间总和。3) 系统测试完成标准u 完备性：l 系统测试计划要求的所有内容是否全部完成？l 所有的测试案例是否全部执行？l 测试中发现的错误是否得到有效的修改或有了处理结论？l 测试中发现的错误被修改后，是否完成了回退测试，证明修改正确？u 正确性：l 项目需求规格说明书上描述的功能是否都测试通过？l 项目需求规格说明书上没有明确描述但却是系统必要的功能(如系统安装、数据备份和恢复等)是否都测试通过？l 系统和系统外的关联系统之间的交互功能是否都测试通过？l 所有的测试案例是否实现正常完成-符合项目需求规格说明书上描述的功能，并且在测试过程中整个系统工作正常，不出现宕机、系统资源耗尽、系统效率异常等情况？l 单个功能单元的误差积累起来，是否会出现放大效应，以致达到不可接受的程度，导致整个系统工作异常？u 文档的一致性和完整性：l 系统测试的所有测试案例、测试记录、测试事件记录、测试错误分析和修改、测试总结报告、测试评估和审计报告都以文档的形式按照规定保存；l 系统测试中发现的问题被解决后，系统相关的概要设计、详细设计、代码和系统测试案例都得到相应的修改，保证系统文档内容的一致性。u 经过正式审核：系统测试结果和测试报告需要经过项目经理、质量管理处和总经理室三级审批通过。4) 培训对于系统测试团队为了执行系统测试所需要的特定培训，应当尽快确认并提供。5) 系统测试环境l 原则上系统测试环境应当与系统未来上线后的环境一致，这包括硬件环境、操作系统环境、数据库和中间件环境、网络环境以及各类环境的配置参数；l 对于系统测试环境中无法提供的一些环境，比如被测试系统以外的相关系统，应当提供模拟环境或仿真程序，同时需要分析模拟环境与实际环境之间可能存在的设备性能、网络连接、交易产生方式等方面的差异，并尽可能通过编写仿真程序减少这种差异；l 系统测试人员应当尽可能靠近程序开发人员，以便他们之间的有效交流；l 应当要求系统测试涉及的软硬件供应商提供必要的技术支持。6) 系统测试工具l 测试记录表格、测试事件报告表格；l 测试模拟环境(如果需要)；l 测试工具软件，如自动化测试工具、测试案例库、其它支持软件等。7) 系统测试报告1. 系统测试报告由三个文件组成：l 测试记录：记录测试期间做了哪些工作；l 测试事件报告：描述在测试期间发生的任何需要进一步检查分析的事件；l 测试总结报告：对测试活动的总结。2. 测试评估和审计报告。在系统测试期间，质量管理处人员要对系统测试流程是否符合项目要求和测试计划进行过程审计，审计结果应当反映在给总经理室提交的测试评估和审计报告中。第五章 压力测试一、 概述压力测试是指完成对系统的性能测试，以确认系统符合业务需求部门在正常交易压力和交易高峰期间对系统处理能力的要求。压力测试不同于功能测试，软件的正确性并不是它的测试重点。它所看重的是软件的执行效率，它以软件响应速度为测试目标，尤其是短时间内访问用户数爆炸性增长时软件的响应速度。影响软件系统响应速度的因素有很多，包括应用程序的编写质量、所使用算法的效率、用户并发数的多少、关联系统的运行效率、系统软硬件资源的配置、数据库参数的设定等。压力测试在系统测试完成后进行，是系统上线前的最后一道测试环节，和系统测试共同构成了系统上线前的总体测试工作。系统测试的目标是：l 确认系统处理能力的下限(Minimum)业务部门对系统抗压能力的显性需求，即在系统上线后一段时间内，在单位时间内至少能够正常处理的交易量，该交易量应当能够满足业务部门在业务需求说明书中对系统处理能力的要求。l 确认系统处理能力的上限(Maximum)业务部门对系统抗压能力的隐性需求，即在系统上线后一段时间内，在不崩溃的情况下单位时间内最多能够处理的交易量。l 确认系统上线后在需要时能够提高系统处理能力的系统参数组合。l 确定制约系统处理能力的关键环节和瓶颈。在压力测试正式进入到执行测试子阶段前，必须召开一次正式的测试准备情况审核会，以便保证压力测试工作在充分准备并合乎测试要求的情况下进行，保证测试的效率和质量。审核工作可以通过审核集成测试和系统测试结果、压力测试方案、以及任何为压力测试开发的支持程序代码等来完成。在项目组和测试队伍之间应当对压力测试应该完成的程度、测试流程的有效性以及测试结果的理解达成共识。该部分的工作由测试团队和项目组开发人员在系统测试结束合作完成。二、 参与人员与职责1. 测试团队（包括项目组测试人员和第三方测试人员）：l 负责压力测试的组织和实施；l 编写压力测试计划；l 完成压力测试设计；l 编写测试案例和测试框架l 开发压力测试脚本开发；l 确定系统测试工具；l 审核第三方测试团队提交的测试案例；l 编写压力测试案例；l 执行压力测试，记录测试结果，形成压力测试事件报告；l 协调和组织系统测试过程中错误/缺陷的修改和回归测试，并即使修改测试计划以反映实际情况；l 收集并提交测试评估数据；l 与业务测试员沟通确定测试中发现错误/缺陷的严重级别；l 执行错误/缺陷修改后的回归测试；l 向项目组开发人员通报和说明压力测试过程中发现的问题；l 撰写压力测试总结报告。2. 项目组：1) 项目经理l 密切监控压力测试的进度，及时修改项目计划以反映情况的变化；l 为配合压力测试安排必要的程序开发资源；l 及时向业务部门通报压力测试及项目的进展情况(如果需要)；l 跟踪压力测试过程中发现问题的解决；2) 程序开发员l 根据压力测试报告更新程序源代码和相关文档，并进行必要的单元测试和集成测试；l 与项目经理就测试中发现问题的解决方案进行沟通。3) 配置管理员l 对原代码、可执行代码和项目相关文档打基线；l 负责整理、保存和维护压力测试资产，包括测试方法、测试案例、测试报告测试数据等；l 对压力测试记录、错误报告和测试报告进行归档、打基线和变更情况审计工作。3. 质量管理处：l 根据测试计划协调全部门的测试资源，保证压力测试顺利进行；l 负责组织测试团队需要的系统测试相关知识和技能培训；l 配合测试团队确保压力测试按照压力测试计划和方案有序进行；l 定期向总经理室汇报系统测试进度；l 对压力测试过程的合规性进行监督和审计；l 根据系统测试团队提交的压力测试报告对压力测试结果进行定量分析，提交压力测试评估和审计报告。4. 总经理室：l 检查项目和测试的进展状态，为项目组的工作明确方向；l 参加压力测试开始前的测试准备情况审核会，批准压力测试开始；l 参加压力测试结束前的测试测试结束审核会，给出对压力测试结果的批准或拒绝意见。三、 测试流程1 计划十、 时间安排在需求分析完成后开始。十一、 输入l 项目需求规格说明书；l 项目需求分析说明书；十二、 入口条件l 需求分析文档已经通过评审。十三、 活动步骤l 确定压力测试的内容：根据以下清单确认压力测试的范围和内容：u 容量测试：在系统上线后的参数配置下，系统在正常运行状态下能够达到的最大日处理能力；u 抗压测试：在系统上线后的参数配置下，系统在不崩溃的情况下在短时间内，如小时内，能够达到的最大处理能力；u 配套参数测试：应当测试在不同系统参数组合情况下的抗压能力，确认与系统不同的处理能力对应的配套参数组合，做为系统上线后运行处系统维护和调优的依据；u 交易效率测试：包括在系统正常运行状态下， 不同交易类型交易的单笔处理速度 单位时间内可以处理的交易笔数 交易堵塞(超时)的比例 交易失败的比例u 重点交易测试：确认对重点交易的处理能力，重点交易包括交易最频繁的交易和对系统资源消耗最大的交易；u 瓶颈测试：通过测试确认制约系统处理能力的瓶颈环节，并提出解决瓶颈限制的可选方案，如扩容，调整瓶颈环节参数等。l 明确压力测试的完整性原则：压力测试的完整性至少包括以下方面的内容：u 保证每笔测试交易的完整性；u 保证测试交易种类的完整性-测试交易种类应当按对实际生产情况的预测比例组合；u 保证交易渠