企业应用系统测试方案建议书.docx
《企业应用系统测试方案建议书.docx》由会员分享，可在线阅读，更多相关《企业应用系统测试方案建议书.docx（17页珍藏版）》请在冰豆网上搜索。
企业应用系统测试方案建议书
企业应用系统
测试方案建议书
第1章系统测试方案
1.1测试方法论
1.1.1完全生命周期测试模型
软件测试是应用系统开发的一个重要环节，它贯穿整个应用系统开发的生命周期。
本系统建设系统项目系统具有以下特点：
Ø系统复杂
Ø系统性能要求高、质量要求高
Ø采用多种新技术，技术要求高
根据本项目的这些具体特点和要求，建议在完全生命周期测试模型基础上，根据项目具体情况和成本效率进行裁剪，形成本项目的测试策略、总体测试计划和分项测试计划。
下图是“完全生命周期测试”方法论模型，它直观描述了整个项目生命周期内所有的测试流程、测试内容、测试阶段及应用系统开发各环节与测试的关系。
完全生命周期测试模型是经过实践证明的、结构化的测试方法。
完全生命周期测试模型为一个大型项目的所有测试和与测试相关的活动提供一个全面的视图。
在本项目中，将以此方法论为指导，结合本项目特点定义测试范围、制定测试计划、设计测试案例和管理测试任务。
1.1.2测试阶段
完全生命周期测试模型包括五个阶段，如下图所示：
1.1.2.1测试开始
开始阶段的重点在定义项目方法和工作范围、准备项目计划、建立质量管理机制，同时准备好项目人力资源，开始启动工作。
这一阶段的活动一般在开发生命周期的方案开始阶段进行。
1.1.2.2测试评估和计划
在测试评估和计划阶段，将评估、复审、整合和确认测试范围和目标，制定测试策略、测试总体计划，制定各个级别的详细测试计划，并且计划和执行静态测试。
在本项目中，测试评估主要源于双方制订的项目实施计划及需求分析报告。
测试范围和目标必须得到项目各方的一致认可。
测试管理小组必须了解应用系统业务和功能的需求及两者相互关系。
测试计划是项目测试成功最关键的环节，它应考虑到每一个测试任务的细节。
测试策略和测试总体计划给出项目总的测试方针和策略，详细测试计划是总体测试计划的补充。
这一阶段的活动一般在开发生命周期的分析设计阶段进行。
1.1.2.3测试计划
在这一阶段，将为每个级别的测试制定详细测试规格说明和测试执行计划，并且为每个级别的测试制定测试环境规格说明。
测试设计包括准备测试后勤、工具、技术、测试案例及各种层次的测试执行方法。
这一阶段的活动一般在开发生命周期的微观设计阶段进行。
1.1.2.4测试执行和报告
在这一阶段，将建立测试环境，执行每个级别的测试，复审和确认测试结果，在测试结果中记录所产生的差异。
在解决差异、完成调试工作、测试没有错误后，代码将转到下一级别的测试。
在每个级别的测试完成后，将提交测试报告。
测试报告有效地沟通了测试状态和测试结果，以便为项目管理组提供是否终止或继续测试的决策。
测试报告包括分析问题出现概率及测试中问题解决的状态，从而为项目管理组提供决策数据。
在本阶段，测试报告非常关键，它将决定最终项目上线的签收。
这一阶段的活动一般在开发生命周期的构建和部署阶段进行。
1.1.2.5方案实施和测试结束
在这一阶段，通过了测试的方案将被实施。
测试文档资产分类归档，供维护时使用。
测试小组更新测试计划，向项目管理组反馈测试改善意见，改善测试流程，测试结束。
测试管理流程贯穿整个项目开发周期，并保证项目的实施质量。
这一阶段的活动一般在开发生命周期的部署和方案结束阶段进行。
1.2测试策略
1.2.1制定测试策略的目的
制定测试策略的目的是：
Ø制定恰当的测试原则和准则，以减轻管理项目风险
Ø为涉及多个组织和业务单位的测试提供公共的方法和公共的术语
Ø为测试确定总体方向
Ø强调成本效益和团队测试方法的重要性
Ø描述完全生命周期测试的复杂性
Ø作为提前发现测试问题的沟通手段
制定测试总体计划的目的是：
Ø从高层面系统的角度对待测试
Ø提供测试的整体、宏观的视图
Ø确保系统的和完整的制定测试计划
Ø提醒相关组织在适当的时间分配适当的人力资源，为测试作好准备
1.2.2测试范围
测试范围定义了测试的边界，本项目软件系统测试范围包括：
Ø系统平台测试
Ø系统设计测试
Ø应用系统测试
1.2.3测试总体目标
软件系统测试的总体目标：
Ø满足客户的业务需求
Ø移植的数据通过一致和集成检测
Ø确保错误在早期测试中被发现，降低成本
Ø确保测试在预算和时程内执行
1.2.4测试重点
下面按优先级列出测试的重点：
高（按优先级排序）
Ø正确性（Correctness）：
根据规定的规则处理数据的能力。
控制交易和数据域编辑，确保数据的准确性和完整性。
Ø安全性（Security）：
确保系统和数据资源受到保护而不会意外或有意的修改或误用。
Ø处理的连续性（ContinuityofProcessing）：
发生错误时，能够具备继续处理的能力，包括发生故障后的备份和恢复能力。
Ø性能（Performance）：
系统在规定的时间内执行特定功能或特定数量交易处理的能力。
中（按优先级排序）
Ø可靠性（Reliability）：
系统提供计划中的功能不发生故障的程度。
低（按优先级排序）
Ø可审计性（Auditability）：
能够为跟踪数据处理提供依据。
Ø可维护性（Maintainability）：
发现并修正系统错误的能力，也包括系统环境动态变化时不改变系统的能力。
Ø可使用性（Usability）：
系统容易学习和使用。
Ø可操作性（Operability）：
系统易于学习和操作（手工或自动）。
Ø可移植性（Portability）：
系统在多个操作系统环境下运作的能力。
1.2.5测试级别
每个开发阶段都代表着一定程度的物理集成和质量达到的级别。
对应这些开发阶段可定义相应的测试级别。
这些测试级别可作为机构或项目组的测试标准和沟通的公共术语。
这些测试级别定义如下：
Ø单元测试
当建立或修改一个模块或程序的编码时就要进行最初的测试，即单元测试。
单元测试验证新的或修改的功能是否正确，它一般不需要与其他应用接口交互。
单元测试的目的是在模块或程序级消除编码中的错误。
Ø集成测试
集成测试验证应用组件的运行，以及模块与其他系统组件的运行。
Ø系统测试
系统集成测试验证所有应用的集成，包括与外部和内部接口的集成，同时验证应用与硬件、软件及基础设施组件在类似生产环境下的集成。
Ø用户验收测试
用户验收测试将全面和系统地测试应用或系统的各个方面，以验证是否能满足业务和非功能需求。
Ø模拟环境下测试
软件开发完成后，业主将组织业务、技术人员对软件在模拟环境下进行测试，检测系统能否满足业务需求及技术要求。
●按照完整的测试流程进行测试，并提供相应文档
测试流程包括制定测试计划、设计测试、实施测试、执行测试、应用系统集成测试等。
●针对不同的测试类型采用相对应的测试策略
测试内容包括数据和数据库完整性测试、功能测试、业务周期测试、性能测试、用户界面测试、安全性和访问控制测试、配置测试、安装测试等。
另外，还将考察软件支持跨操作系统、数据库平台的数据移植能力。
Ø实际环境下的测试（试运行）
根据软件在模拟环境下的测试结果，把通过模拟环境测试的软件，在选定的若干真实的软件运行环境中进行试运行。
这阶段主要检验软件的推广性。
主要指标要求：
●验证模拟环境下测试指标；
●支持不同网络带宽下多用户并发；
●对不同业务部门应用要求的适当能力；
●对试运行中发现的问题能否及时响应，给出解决方案。
Ø正式验收测试
在软件经过若干地区试点，验证产品具备推广性，同时将试运行阶段出现的若干问题解决后进行正式验收。
1.2.6测试类型
测试类型包括业务功能测试（功能类型测试）和结构功能测试（结构类型测试）。
测试级别和测试类型矩阵用来描述不同测试类型在测试级别中的使用。
Ø功能类型测试
功能类型测试确保应用系统满足业务需求。
Ø结构类型测试
结构类型测试验证应用系统在技术上的正确性，包括：
测试架构生存性（viability）和系统的可运行性。
1.3功能测试
1.3.1单元测试计划
1.3.1.1单元测试策略
根据实际情况，采用开发人员自己写测试代码、小组内同级审查和测试组抽查相结合的测试策略。
1.3.1.2单元测试方法
进行类的关键性分析，将类的优先级分为三类，1、2、3，一类为最高，三类最低。
Ø判定类的优先级的依据是：
类对应的用例的优先级，这是主要依据；
系统的目的，那些对系统可能产生严重后果的类必须适当提高优先级，如一些系统的关键类、基础类、公用类等等；
潜在的用户数量和使用的频度，使用频繁高的类的需要提高优先级；
信息的价值：
信息的价值含量高，对其他功能影响巨大的类需要提高优先级。
对不同优先级的类采用不同的测试方法：
对于优先级为1的类，采用以黑盒测试为主，对典型错误进行一定的白盒测试的方法。
对于这些类的每一步修改，都需要进行回归测试；优先级为1的类，都要有相应测试类；
对于优先级为2的类，根据实际情况决定是否需要测试类；对模块中核心类采用“运行测试”，其余的类通过“同级审查”；
对于优先级为3的类，采用静态测试，所有的类通过开发人员“自检”和“同级审查”。
类的优先级划分流程：
当一个类准备要开发的时候，需要确定它的优先级。
简要原则是：
小组成员向本组的组长提交类，描述本类的功能，组长确定类的优先级；
类的优先级划分流程
1.3.1.3单元测试的三级审核流程
第一级：
自查，开发人员自己测试审查自己的类，具体的方法见单元测试策略；
第二级：
互查，同级审查，开发人员内部（循环）审查，组长督促；
第三级：
抽查，由测试组的成员和其他相关小组组成；对已经经过同级审查的类进行抽查。
1.3.1.4单元测试时间计划
单元测试是伴随着编码工作开展的，因此单元测试的时间周期就是从编码开始到编码结束。
在本项目中，编码工作预计将分为两个阶段进行，因此单元测试工作也将分为两个阶段分别执行。
1.3.2系统测试
系统测试是在集成测试的基础上，在系统上线运行环境，或基本状态相似的模拟环境上进行全系统的功能和性能测试，其参与测试人员将由以开发组测试人员为主逐步转向以最终用户测试人员为主。
系统测试的准备、计划和执行与集成测试采取相同的策略和方法。
1.3.3软硬件交互测试
本系统主要进行数据的采集与查询，涉及到软件与硬件设备的交互，将软件与硬件进行集成后在模拟环境上进行测试。
软硬交互测试与集成测试采取相同的策略和方法。
1.3.4测试案例设计
为了保证项目实施的质量，项目开发的测试阶段显得尤为重要。
保证测试质量，测试案例是重点。
测试案例的设计是在系统设计阶段就开始，由于测试案例的建设非常复杂，一开始可以针对关键业务和关键流程进行设计，并考虑逐步完善，最终必须包括本系统建设系统项目所涉及的全部逻辑路径和节点。
根据业务功能的要求，收集案例业务类数据；根据设计的技术要求，完善案例代码属性类数据。
1.4性能测试
1.4.1性能测试流程
性能测试是对系统在长时间的高负荷下的稳定性、可用性、响应速度及并发性进行测试，性能测试是有别于其他的软件测试，性能测试主要测试那些经常使用的，并发性比较高的模块进行测试，性能测试要经过精心的分析和设计，并设定测试目标，然后设计测试案例，持续的让系统运行，并调整系统参数，同时监控并记录系统的运行状态，调整系统的性能以便达到上线目标。
在测试过程中，确保没有其他对系统的任何访问，因此基本上能够保证测试的真实性。
每一个测试用例的执行都是真实日常业务量的模拟。
测试是针对每一个用例单独测试或多个用例混合测试进行的。
对于测试的每一个场景，利用测试工具，模拟高峰期多个用户的并发访问（为了更好地模拟实际情况，我们将不同的场景设置不同的并发用户）。
同时，我们还在应用系统记录每一个部分的处理时间，包括开始时间和结束时间。
这里开始时间指的是进入某一模块的时间，结束时间指的是从某一模块返回的时间。
记录的目的在于，当性能不能满足需求的时候，根据已经记录的信息，很方便的发现在整个应用系统的哪一个部分的处理时间过长，结合中间件产品和操作系统的记录信息，对出现问题的部分做出判断，从而及时做出调整。
1.4.1.1性能测试的工作体系
测试工作由软件测试部门组织完成，在整个过程中需要项目组相关角色的支持。
性能测试的工作角色表
角色
职责
备注
设计人员
从业务的角度分析系统的各个模块被使用的频度和时间以及占整个系统的百分比，提出那些模块需要测试那些模块不需要测试。
准备测试数据和测试需求，设计测试案例以及测试套件。
指导测试案例编写
编码人员
编写各个测试案例的测试脚本，编写接口对核心应用服务器进行调用
测试实施人员
执行测试脚本，记录测试结果
配置管理
负责配置管理测试环境，并收集测试结果
1.4.1.2性能测试工作内容及流程
性能测试工作内容及其流程表
活动
输入
输出
参与角色
和职责
业务量估算
根据往年业务数据估算最多业务量的月份（具体到业务量集中的天数）
统计终端数量，根据终端数量估算并发数
在估算时还要考虑增量
每个模块的业务量分析报告
用户并发量分析报告
设计人员
性能测试计划
根据每个模块的业务量和项目计划
性能测试计划
设计人员
测试脚本开发
编写各个模块的测试脚本，模拟客户端访问核心应用服务器
各个模块的测试案例
编码人员
测试环境配置
根据测试要求配置测试环境，监控系统性能，调整系统参数，记录调整前后的性能参数值
系统监控报告
测试环境配置计划
系统参数调整记录
配置人员
测试执行
执行测试脚本，收集记录测试数据
测试报告
系统分析报告
测试实施人员
评估性能测试
性能测试计划、测试结果
性能测试评估报告
性能测试流程如下：
性能测试流程图
测试拓扑图如下：
测试拓扑图
1.4.1.3性能测试需求的获取
性能测试要先制定一个性能测试的目标，即先通过分析现实情况的数据来得到。
当前系统应该达到一个什么样的并发量和系统响应速度，通过前面的工作，可以获得用户量和每分钟系统需要处理的交易量，我们要以这个用户量和交易量来作为我们的新系统并发量和交易量的一个指标，如果说我们的系统达到了这个指标，我们即可得出我们的新系统可以满足当前的性能要求。
然后我们再在这个基础上调整并发量和交易量，得出当前系统能处理的最大交易量，并指出如果以后需要增加交易量，系统的瓶颈所在，可以指导用户有目的的增加相应设备。
1.4.1.4性能测试产生的工件清单
在整个性能测试过程中，我们将保存所有测试脚本及相应的测试结果，并根据测试情况编写测试报告，一并提交给用户。
性能测试产生的工件清单有：
Ø性能测试方案
Ø测试用例
Ø测试脚本
Ø测试报告
1.4.2性能测试方法
1.4.2.1黑盒测试
用facadel调用业务模块来模拟客户端对核心业务模块的访问，通过loadrunner并发设置来模拟大量并发用户。
1.4.2.2网络测试方法
10M光纤网络使用负载测试软件，主要测试网络的可用性和网络可支持的最大用户数以及对应的响应速度。
2MSDH网络根据实际可能的用户数来决定是否使用负载测试软件。
考虑到实际的网络带宽情况，我们将在不同的带宽条件下进行测试，以反映出不同带宽条件下的系统性能情况。
我们还将测试在网络传输不稳定的情况下，会不会出现数据传输错误，如果出现数据传输错误，将给出有效预防措施或者校验方法等。
1.4.3性能测试中的一些关键问题
1.4.3.1测试指标的设计
在测试工作开始前，要充分考虑目标用户的基础数据量，如操作的终端数、数据库中现有的数据量等内容；同时还要充分估算并发量，要求的响应时间等。
1.4.3.2测试场景的选取
在压力测试工作中，场景的选取非常重要，面对一个功能复杂，功能数量庞大的系统，必须要从中选取一些典型的案例作为测试的场景，一般情况下，选择平时使用最多的用例。
选定好用例后，就要设计测试的场景，准备好模拟数据，为了保证压力的效果，还要在数据库中预装和实际情况相当的数据量。
同时还要设计好单个场景和复合场景的测试，测试完单个场景后，还要设计几个复合场景，设计好各个组成的单个场景的比例，以模拟正式环境中的实际需求。
1.4.3.3测试的类型
在压力测试中，要对以下的一些内容进行测试：
实际网络环境终端响应时间测试、网络压力测试、主机压力测试等，全方位地提供数据给用户参考。
1.5集成测试
1.5.1集成测试方法
各测试周期分为下列几个步骤实施，以确认系统已经能够用于正式的运行：
按测试案例进行测试；
比较预期结果与实际测试结果；
记录实际测试结果与预期结果的差异以及问题的严重程度；
解决问题并重新进行测试。
1.5.2实施测试
测试者需按照测试案例实施测试周期，测试案例应定义需要测试的业务流程和情景。
测试小组负责人负责帮助完成系统测试并记录测试的情况。
如果在测试中有问题产生，测试小组负责人应在与测试组组长讨论后负责决定是终止测试周期，还是仍可以继续测试。
在每一个测试周期开始以前，应准备好测试所需的数据并对数据进行人工验证。
所有的测试说明应有电子化的记录并在每一个测试周期中获得落实。
比较预期结果和实际测试结果
在测试的实施过程中，测试小组负责人、项目经理和测试者应对实际测试结果和测试前预期的结果进行比较。
两者的差异应记录在“测试结果记录单”中。
记录实际测试结果与预期结果的偏差
在整个测试周期中，测试小组负责人应查询和回顾在“测试结果记录单”中记录的问题，并通知负责解决这些问题的人员。
项目团队的成员应每天回顾问题的解决情况并确定这些问题的优先次序。
1.5.3实施二次测试
测试团队的管理者应协调问题的解决情况并准备进行二次测试。
在测试周期中的所有问题被解决之后，应进行二次测试。
测试周期的实施、问题的解决和二次测试的情况应在测试过程中反复进行，直到整个测试周期完全获得通过。
在现有问题被解决之后，项目经理应决定是对整个测试周期进行二次测试，还是只测试系统中产生问题的部分。
1.6第三方测试
第三方测试是在软硬件联调测试的基础上，在系统上线运行环境上，进行的第三方测试，其参与人员主要是第三方测试机构，我方将在业主方的统一部署安排下，配合第三方测试。
第三方测试的准备、计划和执行与集成测试采取相同的策略和方法。
升级会员 