整体测试方案

1、文档编号：IECUSTOM-整体测试方案V1.0海关信息数据采集与数据应用平台测试项目 整体测试方案二零一六年九月 整体测试方案关于本文档项目名称海关信息数据采集与数据应用平台测试项目主 题整体测试方案标 识IECUSTOM-整体测试方案V1.0说 明系统测试前，需要制定方案，以便对测试工作进行指导。适用对象甲方项目负责人、有关人员中科软项目工程领导小组、项目经理、项目组全体成员以及相关人员修订历史版本章节类型日期作者说明V1.0C2016年9月5日罗晨说明：类型创建（C）、修改（U）、删除（D）、增加（A）；评审记录角色签名日期说明目 录第 1 章概述11.1编写目的11.2读者对象11.3

2、项目背景1第 2 章测试方案概述22.1测试目标22.2测试范围22.3参考资料2第 3 章测试环境3第 4 章测试方案54.1测试依据54.2功能测试54.3性能测试54.4内部测试54.4.1测试策略54.4.2测试管理7第 5 章用户测试135.1测试管理135.1.1组织机构135.1.2角色职责135.1.3测试安排145.1.4测试步骤145.1.5测试管理工具145.1.6用户问题处理、反馈流程145.1.7测试通过准则155.1.8测试异常中止准则155.1.9风险分析及预防16III海关信息数据采集与数据应用平台测试项目 第 1 章 概述1.1 编写目的编写本测试方案的目的是

3、为客户、项目经理、开发人员、测试工程师、维护人员等项目相关人员提供海关信息数据采集与数据应用与平台测试项目整体系统测试指导。1.2 读者对象本测试方案可能的合法读者对象为客户、项目经理、开发人员、测试人员、维护人员。1.3 项目背景随着经济环境、执法环境的变化，海关大监管、关警融合、分类通关等各项业务的不断深入，加快通关速度和大通关对缉私工作提出了更高的要求，情报工作在海关各工作特别是缉私工作中的地位和作用日益凸显，所担负的职责更加繁重，任务更加艰巨，海关人力资源与监管要求直接的矛盾突出。为了提升海关大监管的综合执法能力及海关缉私办案能力，必须借助现代化情报工作机制及计算机情报信息系统支持，完

4、善情报机制，体现情报信息服务，增强对全国海关情报业务的掌控能力。第 2 章 测试方案概述2.1 测试目标（1）系统界面操作无明显异常，符合业务需求规定；（2）根据需求规格说明书，总体设计、详细设计文档实现整体功能测试；（3）系统主要流程，无异常，符合需求；（4）根据需求进行性能测试、稳定性、健全性及安全测试； （5）所有测试用例100%执行；（6）所有缺陷处于Closed、Rejected、Pending状态；（7）缺陷修改要求：High级缺陷修复率应达到100%；Medium级缺陷修复率应达到95%以上；Low级缺陷修复率应达到60%以上。2.2 测试范围本次测试主要针对海关信息数据采集与数

5、据应用平台项目的软件需求规格说明书中涉及的要求进行完整性测试，包括界面、功能和流程的全面测试，以及性能测试、稳定性、健全性及安全测试等。本次测试采用黑盒测试的方法为主，辅助进行代码审查。2.3 参考资料海关信息数据采集与数据应用平台测试项目需求规格说明书海关信息数据采集与数据应用平台测试项目合同公司软件测试规范。第 3 章 测试环境测试环境分类测试环境名称硬件环境软件环境客户端PC机1(172.17.9.106)Pentium(R) D CPU 3.00GHZ2.99GHZ,1.99GB内存Windows XP Professional SP2PC机2(172.17.9.123)Pentium

6、(R) D CPU 3.00GHZ2.99GHZ,1.99GB内存Windows XP Professional SP2服务器端应用服务器待定待定数据库服务器企业端(172.16.1.108)：IBM XDERIES_366 Intel（R）Xeon(7M) MP CUP 3.16GHz 3.17GHz 3.25GB内存中心端(172.17.16.22)：System Model: IBM,7040-671Number Of Processors: 16Processor Clock Speed: 1500 MHzCPU Type: 64-bitMemory Size: 16384 MBHar

7、d Disk: 109200MB企业端：Windows 2003 Server Enterprise Edition SP2中心端：AIX Version 5.3MQ服务器(企业端：172.17.16.14；中心端172.17.16.13)System Model: IBM,7026-6M1Number Of Processors: 8Processor Clock Speed: 752 MHzCPU Type: 64-bitMemory Size: 8192 MBHard Disk:36400MBAIX Version 5.3MQ6.0其 它加M机(172.17.8.250)分中心（邮箱客户

8、端）同PC机1和PC机2同PC机1和PC机2浏览器IE6表4.1 测试环境第 4 章 测试方案4.1 测试依据在本项目实施过程中编写的需求、设计、计划、测试方案、测试报告等产出物，需要通过客户、项目经理、QA、测试经理等该项目相关人员审核。4.2 功能测试测试人员根据通过审核的需求、设计、测试方案等文档编写测试用例，要求测试用例的功能覆盖率要达到100%，测试过程中测试人员严格执行测试用例并记录测试结果，验证系统的功能实现是否达到需求、设计要求，是否满足客户目标。测试用例执行率达到100%。测试过程中所有问题提交BugFree。4.3 性能测试应用系统经过系统测试后形成相对稳定版本，测试组在稳

9、定版本的基础上选择性能测试点进行性能测试，测试组负责编写性能测试方案，对系统进行压力测试、并发测试、稳定性测试。测试过程中使用性能测试工具LoadRunner。执行性能测试时，同时填写性能测试记录表、性能测试调优过程记录表。4.4 内部测试4.4.1 测试策略测试过程按三个步骤进行，即单元测试、集成测试、系统测试，根据不同阶段测试的测重点不同。4.4.1.1 单元测试首先按照系统、子系统和模块进行划分，但最终的单元必须是功能模块,或面向对象过程中的若干个类。单元测试是对功能模块进行正确性检验的测试工作，也是后续测试的基础。目的是在于发现各模块内部可能存在的各种差错，因此需要从程序的内部结构出发

10、设计测试用例，着重考虑以下五个方面：1) 模块接口：对所测模块的数据流进行测试。2) 局部数据结构：检查不正确或不一致的数据类型说明、使用尚未赋值或尚未初始化的变量、错误的初始值或缺省值。3) 路径：虽然不可能做到穷举测试，但要设计测试用例查找由于不正确的计算（包括算法错、表达式的符号表示不正确、运算精度不够等）、不正确的比较或不正常的控制流（包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等）而导致的错误。4) 错误处理：检查模块有没有对预见错误的条件设计比较完善的错误处理功能，保证其逻辑上的正确性。5) 边界：注意设计数据流、控制流中刚好等于、大于或小于确

11、定的比较值的用例。4.4.1.2 集成测试集成测试也叫组装测试或联合测试（接口联调测试）。通常，在单元测试的基础上需要将所有的模块按照设计要求组装成系统，这时需要考虑的问题：1) 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。2) 一个模块的功能是否会对另一个模块的功能产生不利的影响。3) 各个子功能组合起来，能否达到预期要求的父功能。4) 全局数据结构是否有问题。5) 单元模块的误差累积起来，是否会放大，从而达到不能接受的程度。4.4.1.3 系统测试系统测试目的是在于验证软件的功能和性能及其他特性是否与用户的要求一致，主要是下列类型的测试：1) 用户界面测试：测试用户界面是否具

12、有导航性、美观性、行业或公司的规范性、是否满足设计中要求的执行功能。2) 功能测试：验证功能实现是否满足客户需求。3) 性能测试：测试相应时间、事务处理效率和其他时间敏感的问题。4) 可靠性测试：测试系统对数据有效性检查能力和抵御误操作的能力。5) 容量测试：测试大量数据对系统的影响。6) 容错性测试：测试软件系统克服软件、硬件故障的能力。7) 数据安全测试：测试系统在出现异常情况下，是否可以保护数据不丢失；测试系统能否可以进行数据库的备份和恢复。8) 易用性测试：重点关注系统的易理解性、易操作性、易学性。9) 安装部署测试：确保软件系统在所有可能情况下的安装效果和一旦安装部署之后必须保证正确

13、运行的质量。4.4.2 测试管理4.4.2.1 组织机构测试经理测试人员项目经理项目负责人开发人员4.4.2.2 角色职责角色职责测试经理- 负责与项目经理沟通，进行测试的整体策划、制定测试计划、组织测试实施、分析测试结果，控制测试进度和Bug清除率。测试员- 负责检查测试环境、测试版本、编写并执行测试大纲、测试用例、报告缺陷、验证修改结果，进行测试数据统计，提交测试报告。项目经理- 负责与测试经理沟通，参与测试的整体策划、提供测试依据等相关材料；介绍系统功能，负责测试组与开发组间协调。程序员- 按时部署测试环境、数据，提交可测试的软件版本，协助测试员编写用例，及时修改缺陷、填写修改记录。QA

14、工程师- 对测试过程、测试结果进行规范性检查项目负责人- 评价测试结果4.4.2.3 测试安排总体测试时间：2016年9月1日2016年11月13日。第一阶段测试：2016年9月1日2016年10月9日，开发人员编写代码，完成系统功能开发，并对完成的功能模块进行单元测试、集成测试；第二阶段测试：2016年10月10日2016年10月25日，测试组对项目的软件系统进行功能测试，由开发人员完成所有问题的修改。第三阶段测试：2016年10月26日2016年11月4日，测试组进行性能测试并完成问题修改。4.4.2.4 测试步骤具体测试步骤：1、 对整体流程进行测试，保证系统整体业务流程可以走通。2、

15、对整体业务流程中的分支流程进行测试，保证系统业务分支流程可以走通。3、 各业务系统流程测试4、 各子系统功能点测试。5、 覆盖性测试。6、 系统性能测试。回归测试贯穿每个测试阶段。系统整体流程如下说明：1、基础数据由数据采集系统从进出口相关执法部门采集，包括涉毒信息、旅客信息、航班信息等，形成基础数据。2、系统进行数据收集存储、数据加工处理、主题数据建立等处理，进行主数据转换加载与业务数据转换加载，产生中间过程数据，具有时间戳和更新标记。3、对集成数据进行分析，满足实时查询与统计需要，形成统计报表。4、动态数据仓库存放风险数据、预警数据。5、对预警数据进行评分、排名并设置消息推送。4.4.2.

16、5 测试管理工具工具名称：Bugfree3.0来源：官方网站功能：测试用例、缺陷管理，自动统计测试结果4.4.2.6 缺陷处理流程Bugfree3.0规定缺陷有三种状态（见表-1）、七种解决方案（见表-2）。表-1缺陷有三种状态缺陷状态说明Active(激活)Bug的初始状态。任何新建的Bug状态都是Active。可以通过编辑功能修改Bug的内容，并指派给合适的人员解决。Resolved(解决)解决中或解决完毕状态。Closed(关闭)已修复Bug、或解决方案（见表-2）被验证无误之后可以关闭。该Bug处理完毕。如果没有真正解决或者重新复现，可以重新激活，Bug状态重新变为Active。按照B

17、ugfree3.0.4缺陷处理流程，测试者、Bug修改者都可以使用Bugfree报告Bug，测试者跟踪Bug状态，验证处理结果，直至关闭。具体过程：1、 报告者提交一个Bug，缺陷生命周期开始，Bugfree自动将状态置为Active（激活状态），报告者将Bug指派给修改Bug的程序员；2、 程序员接受Bug，点击解决按钮，进行Bug的修改，并指派Bug修改后的验证人（默认该Bug的报告者），Bug变为Resolved（解决状态），程序员选择Bug解决方案：表-2七种解决方案Bug解决方案方案说明处理规则Fixed（有效Bug）确认是Bug，修改完毕、提交验证。测试员验证，修改正确、可以关闭；

18、否则，重新激活。External（有效Bug）外部因素（比如浏览器、操作系统、其他第三方软件）造成的问题。项目经理确认、必要时与客户和相关方协商解决，测试员验证后关闭；否则，重新激活。Postponed（有效Bug）目前不必修改的问题（发现的太晚了，下一个版本讨论是否解决）。项目经理确认、必要时与客户协商，如果同意下一个版本讨论或修改，保持“解决”状态和当前解决方案不变；否则，重新激活，选择Fixed/External方案进行修改；WontFix（有效Bug）是个问题，但是不影响系统使用。项目经理确认，确实不值得修改、可让测试员关闭；否则，重新激活，选择适当的方案进行修改；ByDesign（无

19、效Bug）就是这么设计的，不是Bug。项目经理确认，必要时与客户协商，如果的确不是Bug，需求和设计就是这样、或受限于开发环境和工具，可让测试员关闭；否则，重新激活,选择适当的方案进行修改；Duplicate（无效Bug）重复的Bug。测试员确认，确实是重报、测试员可以关闭；否则，重新激活，选择适当的方案进行修改；NotRepro（无效Bug）无法复现的问题。项目经理确认，确实无法复现，指定专人跟踪，如果一段时间内Bug不再重现，可让测试员关闭；否则，重新激活，选择适当的方案进行修改。*需项目经理确认的问题也可委托开发组长、技术骨干审查，关键问题由开发组长报项目经理确认。3、 Bug报告者和修

20、改者参考程序员填写的Bug解决方案，按照上表定义的处理规则，需要时请项目经理确认，将可以关闭的Bug置为Closed（关闭状态）；否则，重新激活、置为Active（激活状态）。4.4.2.7 测试通过准则充分性：计划测试的功能至少全部测试了一遍；至少对缺陷高发点进行了回归测试；测试用例覆盖率100%；测试用例执行率100%；Bug清除率：有效Bug清除率95%以上；其中：1-2级Bug清除率100%3-4级Bug清除率95%以上；遗留Bug必须得到客户认可。4.4.2.8 测试异常中止准则1、 系统的一二级错误太多、不能继续测试；2、 发现明显设计错误、导致测试对象完全错误；3、 发现测试对象

21、与用户需求完全不符合；4、 测试环境没有保障；5、 测试人员或缺陷修改人员缺席。4.4.2.9 风险分析及预防严格遵循软件测试规范，做到：组织规范、流程规范、文档规范依据评审通过的需求规格说明书、设计书编写测试用例；需求、设计变更时要有客户变更记录；要求测试大纲和用例：测试大纲和用例覆盖软件所有的功能要点和主要业务流程；每一条用例应给出测试数据（需要输入数据时）、执行步骤、方法、预期结果。测试大纲和用例应经过项目经理审查、客户负责人评审。4.4.2.10 提交成果物Ø 整体测试方案Ø 测试用例Ø BUG一览表Ø 测试报告第 5 章 用户测试用户测试过程中

22、重点关注需求文档中描述的功能是否都已经实现，主要对系统进行易用性测试、可靠性测试、容错性测试。其测试依据及测试环境同测试组相同。5.1 测试管理5.1.1 组织机构5.1.2 角色职责角色职责用户测试代表负责检查测试环境、测试版本、报告缺陷、验证修改结果，进行测试数据统计，提交用户测试报告。项目经理负责与甲方测试人员沟通，参与测试的整体策划、提供测试依据等相关材料；介绍系统功能，负责甲方测试人员与开发组间协调。开发组按时部署测试环境、数据，提交可测试的软件版本，编写测试用例、测试大纲，及时修改缺陷、填写修改记录。QA工程师对测试过程、测试结果进行规范性检查甲方项目负责人评价测试结果5.1.3 测试安排测试时间： 2016年11月5日2016年11月20日，业主进行测试并完成问题修改。5.1.4 测试步骤第一步：测试开始前，由项目经理介绍已实现的功能、业务流程，保证用户方测试员深入理解系统功能和业务流程，执行测试用例。第二步：用户方测试人