资源描述
.wd.文档编号:IECUSTOM-整体测试方案V1.0海关信息数据采集与数据应用平台测试工程整体测试方案二零一六年九月关于本文档工程名称海关信息数据采集与数据应用平台测试工程主 题整体测试方案标 识IECUSTOM-整体测试方案V1.0说 明系统测试前,需要制定方案,以便对测试工作进展指导。适用对象甲方工程负责人、有关人员中科软工程工程领导小组、工程经理、工程组全体成员以及相关人员修订历史版本章节类型日期作者说明V1.0C2016年9月5日罗晨说明:类型创立C、修改U、删除D、增加A;评审记录角色签名日期说明目录第 1 章概述11.1编写目的11.2读者对象11.3工程背景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风险分析及预防16第 1 章 概述1.1 编写目的编写本测试方案的目的是为客户、工程经理、开发人员、测试工程师、维护人员等工程相关人员提供海关信息数据采集与数据应用与平台测试工程整体系统测试指导。1.2 读者对象本测试方案可能的合法读者对象为客户、工程经理、开发人员、测试人员、维护人员。1.3 工程背景随着经济环境、执法环境的变化,海关大监管、关警融合、分类通关等各项业务的不断深入,加快通关速度和大通关对缉私工作提出了更高的要求,情报工作在海关各工作特别是缉私工作中的地位和作用日益凸显,所担负的职责更加繁重,任务更加艰巨,海关人力资源与监管要求直接的矛盾突出。为了提升海关大监管的综合执法能力及海关缉私办案能力,必须借助现代化情报工作机制及计算机情报信息系统支持,完善情报机制,表达情报信息服务,增强对全国海关情报业务的掌控能力。第 2 章 测试方案概述2.1 测试目标1系统界面操作无明显异常,符合业务需求规定;2根据需求规格说明书,总体设计、详细设计文档实现整体功能测试;3系统主要流程,无异常,符合需求;4根据需求进展性能测试、稳定性、健全性及安全测试;5所有测试用例100%执行;6所有缺陷处于Closed、Rejected、Pending状态;7缺陷修改要求:High级缺陷修复率应到达100%;Medium级缺陷修复率应到达95%以上;Low级缺陷修复率应到达60%以上。2.2 测试范围本次测试主要针对海关信息数据采集与数据应用平台工程的软件需求规格说明书中涉及的要求进展完整性测试,包括界面、功能和流程的全面测试,以及性能测试、稳定性、健全性及安全测试等。本次测试采用黑盒测试的方法为主,辅助进展代码审查。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(R) D CPU 3.00GHZ2.99GHZ,1.99GB内存Windows XP Professional SP2服务器端应用服务器待定待定数据库服务器企业端(172.16.1.108):IBM XDERIES_366 IntelRXeon(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 MBHard 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)分中心邮箱客户端同PC机1和PC机2同PC机1和PC机2浏览器IE6表4.1 测试环境第 4 章 测试方案4.1 测试依据在本工程实施过程中编写的需求、设计、方案、测试方案、测试报告等产出物,需要通过客户、工程经理、QA、测试经理等该工程相关人员审核。4.2 功能测试测试人员根据通过审核的需求、设计、测试方案等文档编写测试用例,要求测试用例的功能覆盖率要到达100%,测试过程中测试人员严格执行测试用例并记录测试结果,验证系统的功能实现是否到达需求、设计要求,是否满足客户目标。测试用例执行率到达100%。测试过程中所有问题提交BugFree。4.3 性能测试应用系统经过系统测试后形成相对稳定版本,测试组在稳定版本的根基上选择性能测试点进展性能测试,测试组负责编写性能测试方案,对系统进展压力测试、并发测试、稳定性测试。测试过程中使用性能测试工具LoadRunner。执行性能测试时,同时填写性能测试记录表、性能测试调优过程记录表。4.4 内部测试4.4.1 测试策略测试过程按三个步骤进展,即单元测试、集成测试、系统测试,根据不同阶段测试的测重点不同。4.4.1.1 单元测试首先按照系统、子系统和模块进展划分,但最终的单元必须是功能模块,或面向对象过程中的假设干个类。单元测试是对功能模块进展正确性检验的测试工作,也是后续测试的根基。目的是在于发现各模块内部可能存在的各种过失,因此需要从程序的内部构造出发设计测试用例,着重考虑以下五个方面:1) 模块接口:对所测模块的数据流进展测试。2) 局部数据构造:检查不正确或不一致的数据类型说明、使用尚未赋值或尚未初始化的变量、错误的初始值或缺省值。3) 路径:虽然不可能做到穷举测试,但要设计测试用例查找由于不正确的计算包括算法错、表达式的符号表示不正确、运算精度不够等、不正确的对比或不正常的控制流包括不同数据类型量的相互对比、不适当地修改了循环变量、错误的或不可能的循环终止条件等而导致的错误。4) 错误处理:检查模块有没有对预见错误的条件设计对比完善的错误处理功能,保证其逻辑上的正确性。5) 边界:注意设计数据流、控制流中刚好等于、大于或小于确定的对比值的用例。4.4.1.2 集成测试集成测试也叫组装测试或联合测试接口联调测试。通常,在单元测试的根基上需要将所有的模块按照设计要求组装成系统,这时需要考虑的问题:1) 在把各个模块连接起来的时候,穿越模块接口的数据是否会丧失。2) 一个模块的功能是否会对另一个模块的功能产生不利的影响。3) 各个子功能组合起来,能否到达预期要求的父功能。4) 全局数据构造是否有问题。5) 单元模块的误差累积起来,是否会放大,从而到达不能承受的程度。4.4.1.3 系统测试系统测试目的是在于验证软件的功能和性能及其他特性是否与用户的要求一致,主要是以下类型的测试:1) 用户界面测试:测试用户界面是否具有导航性、美观性、行业或公司的标准性、是否满足设计中要求的执行功能。2) 功能测试:验证功能实现是否满足客户需求。3) 性能测试:测试相应时间、事务处理效率和其他时间敏感的问题。4) 可靠性测试:测试系统对数据有效性检查能力和抵御误操作的能力。5) 容量测试:测试大量数据对系统的影响。6) 容错性测试:测试软件系统抑制软件、硬件故障的能力。7) 数据安全测试:测试系统在出现异常情况下,是否可以保护数据不丧失;测试系统能否可以进展数据库的备份和恢复。8) 易用性测试:重点关注系统的易理解性、易操作性、易学性。9) 安装部署测试:确保软件系统在所有可能情况下的安装效果和一旦安装部署之后必须保证正确运行的质量。4.4.2 测试管理4.4.2.1 组织机构测试经理测试人员工程经理工程负责人开发人员4.4.2.2 角色职责角色职责测试经理- 负责与工程经理沟通,进展测试的整体筹划、制定测试方案、组织测试实施、分析测试结果,控制测试进度和Bug去除率。测试员- 负责检查测试环境、测试版本、编写并执行测试大纲、测试用例、报告缺陷、验证修改结果,进展测试数据统计,提交测试报告。工程经理- 负责与测试经理沟通,参与测试的整体筹划、提供测试依据等相关材料;介绍系统功能,负责测试组与开发组间协调。程序员- 按时部署测试环境、数据,提交可测试的软件版本,协助测试员编写用例,及时修改缺陷、填写修改记录。QA工程师- 对测试过程、测试结果进展标准性检查工程负责人- 评价测试结果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、 对整体业务流程中的分支流程进展测试,保证系统业务分支流程可以走通。3、 各业务系统流程测试4、 各子系统功能点测试。5、 覆盖性测试。6、 系统性能测试。回归测试贯穿每个测试阶段。系统整体流程如下说明:1、根基数据由数据采集系统从进出口相关执法部门采集,包括涉毒信息、旅客信息、航班信息等,形成根基数据。2、系统进展数据收集存储、数据加工处理、主题数据建设等处理,进展主数据转换加载与业务数据转换加载,产生中间过程数据,具有时间戳和更新标记。3、对集成数据进展分析,满足实时查询与统计需要,形成统计报表。4、动态数据仓库存放风险数据、预警数据。5、对预警数据进展评分、排名并设置消息推送。4.4.2.5 测试管理工具工具名称:Bugfree3.0来源:官方网站功能:测试用例、缺陷管理,自动统计测试结果4.4.2.6 缺陷处理流程Bugfree3.0规定缺陷有三种状态见表-1、七种解决方案见表-2。表-1缺陷有三种状态缺陷状态说明Active(激活)Bug的初始状态。任何新建的Bug状态都是Active。可以通过编辑功能修改Bug的内容,并指派给适宜的人员解决。Resolved(解决)解决中或解决完毕状态。Closed(关闭)已修复Bug、或解决方案见表-2被验证无误之后可以关闭。该Bug处理完毕。如果没有真正解决或者重新复现,可以重新激活,Bug状态重新变为Active。按照Bugfree3.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,修改完毕、提交验证。测试员验证,修改正确、可以关闭;否则,重新激活。External有效Bug外部因素比方浏览器、操作系统、其他第三方软件造成的问题。工程经理确认、必要时与客户和相关方协商解决,测试员验证后关闭;否则,重新激活。Postponed有效Bug目前不必修改的问题发现的太晚了,下一个版本讨论是否解决。工程经理确认、必要时与客户协商,如果同意下一个版本讨论或修改,保持“解决状态和当前解决方案不变;否则,重新激活,选择Fixed/External方案进展修改;WontFix有效Bug是个问题,但是不影响系统使用。工程经理确认,确实不值得修改、可让测试员关闭;否则,重新激活,选择适当的方案进展修改;ByDesign无效Bug就是这么设计的,不是Bug。工程经理确认,必要时与客户协商,如果确实不是Bug,需求和设计就是这样、或受限于开发环境和工具,可让测试员关闭;否则,重新激活,选择适当的方案进展修改;Duplicate无效Bug重复的Bug。测试员确认,确实是重报、测试员可以关闭;否则,重新激活,选择适当的方案进展修改;NotRepro无效Bug无法复现的问题。工程经理确认,确实无法复现,指定专人跟踪,如果一段时间内Bug不再重现,可让测试员关闭;否则,重新激活,选择适当的方案进展修改。*需工程经理确认的问题也可委托开发组长、技术骨干审查,关键问题由开发组长报工程经理确认。3、 Bug报告者和修改者参考程序员填写的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、 发现测试对象与用户需求完全不符合;4、 测试环境没有保障;5、 测试人员或缺陷修改人员缺席。4.4.2.9 风险分析及预防严格遵循软件测试标准,做到:组织标准、流程标准、文档标准依据评审通过的需求规格说明书、设计书编写测试用例;需求、设计变更时要有客户变更记录;要求测试大纲和用例:测试大纲和用例覆盖软件所有的功能要点和主要业务流程;每一条用例应给出测试数据需要输入数据时、执行步骤、方法、预期结果。测试大纲和用例应经过工程经理审查、客户负责人评审。4.4.2.10 提交成果物 整体测试方案 测试用例 BUG一览表 测试报告第 5 章 用户测试用户测试过程中重点关注需求文档中描述的功能是否都已经实现,主要对系统进展易用性测试、可靠性测试、容错性测试。其测试依据及测试环境同测试组一样。5.1 测试管理5.1.1 组织机构5.1.2 角色职责角色职责用户测试代表负责检查测试环境、测试版本、报告缺陷、验证修改结果,进展测试数据统计,提交用户测试报告。工程经理负责与甲方测试人员沟通,参与测试的整体筹划、提供测试依据等相关材料;介绍系统功能,负责甲方测试人员与开发组间协调。开发组按时部署测试环境、数据,提交可测试的软件版本,编写测试用例、测试大纲,及时修改缺陷、填写修改记录。QA工程师对测试过程、测试结果进展标准性检查甲方工程负责人评价测试结果5.1.3 测试安排测试时间: 2016年11月5日2016年11月20日,业主进展测试并完成问题修改。5.1.4 测试步骤第一步:测试开场前,由工程经理介绍已实现的功能、业务流程,保证用户方测试员深入理解系统功能和业务流程,执行测试用例。第二步:用户方测试人员逐条执行测试用例,发现的问题记录到用户测试问题跟踪表,并提交给中科软,再由中科软测试人员记录到BugFree中。对于有争议的BUG,外部问题、由工程经理与客户协商解决。5.1.5 测试管理工具工具名称:Bugfree3.0来源:官方网站功能:测试用例、缺陷管理,自动统计测试结果用户测试问题跟踪表5.1.6 用户问题处理、反响流程1、报告的方式、频度 在用户测试过程中,使用中科软提供的用户测试问题跟踪表.xls记录用户问题,再由中科软测试人员将问题记录到bugfree中,开发人员修改完毕后,由中科软测试人员验证通过后,再记录的到用户测试问题跟踪表中,由用户测试验证,问题的解决方案、修改记录、验证记录、统计测试结果可用bugfree进展统计; 用户测试进展的同时开发人员对于用户发现的问题进展分析、解决。用户测试问题跟踪表.xls由中科软进展统一收集。 测试版本的发布、测试轮次需要协商。2、问题处理和反响流程5.1.7 测试通过准则1、 方案测试的功能全部测试一遍;2、 测试结果及问题修改情况必须得到用户认可。5.1.8 测试异常中止准则1.系统的一二级错误太多、不能继续测试;2.发现明显设计错误、导致测试对象完全错误;3.发现测试对象与用户需求完全不符合;4.测试环境没有保障;5.测试人员或缺陷修改人员缺席。5.1.9 风险分析及预防1、 测试过程中需要严格按照测试用例操作步骤执行,防止因异常操作造成用例执行结果无效;2、 测试人员需要掌握系统流程,防止测试过程中因测试人员不熟悉业务流程会延长测试时间;3、 测试人员在测试过程中发现有影响测试进度的问题,需要及时和工程经理沟通,保障测试顺利进展。
展开阅读全文