logo资料库

应用系统集成测试规范.doc

第1页 / 共13页
第2页 / 共13页
第3页 / 共13页
第4页 / 共13页
第5页 / 共13页
第6页 / 共13页
第7页 / 共13页
第8页 / 共13页
资料共13页,剩余部分请下载后查看
目 录
前 言
应用系统集成测试规范
1范围
2术语和定义
2.1金质办
2.2用户
2.3监理
2.4总集成商
2.5总标准商
2.6各级开发商
2.7PM&PSM
2.8评审
2.9审核
3应用系统集成测试规范
3.1集成测试的前提条件
a)参与集成测试的各应用软件系统经过了各级开发商的单元测试、集成测试,测试总结报告通过了监理、总集成商、
b)参与集成测试的各级开发商提出集成测试的书面申请,各级开发商并已经准备好了接口测试用例。
c)参与集成测试的各级开发商的应用系统已经集中,并已经搭建好了测试的环境。
d)测试环境准备完毕。包括场地安排、网络联调、硬件环境、参与集成测试的各级开发商的配合支持人员已经到位等
3.2集成测试的内容
a)在把各个应用系统连接起来的时候,穿越系统接口的数据是否会丢失,数据转换是否正确,数据权限是否准确;
b)一个系统的功能是否会对另一个系统的功能产生不利的影响;
c)各个子系统组合起来,能否达到“金质工程”一期系统预期的要求;
d)“金质工程”的整体数据结构是否有问题;
e)各子系统组合起来的性能是否符合多个用户的业务管理需求。
应用在客户端性能的测试
应用在网络上性能的测试
应用在服务器端性能的测试。
3.3集成测试过程
正常终止:所有测试过程(或脚本)按预期方式执行至结束。
致命错误 - 系统故障(网络故障、硬件崩溃等)。
测试脚本命令故障。
分析测试结果并提交变更请求,以保证测试已执行完全,并确保报告的测试结果没有受到非测试对象因素的影响;
评估基于需求的测试覆盖,来确定:需求的测试(测试用例)的数量与测试对象的总需求测试数量的比例。
分析缺陷,目的在于通过队缺陷密度、趋势等的分析,将本次迭代的评测方法与先前各次迭代的分析结果进行比较
3.4测试发现问题的处理流程
a)测试人员测试后填写《测试问题卡》并及时提交测试负责人。
b)测试负责人对《测试问题卡》进行审阅、汇总,并进行签字确认。
c)测试负责人将汇总确认后的《测试问题卡》交给各级开发商开发负责人,同时进行存档。
d)开发商开发负责人接到《测试问题卡》后,首先进行审阅,如有疑问的与总集成商测试负责人进行沟通,确认必须
e)各级开发商开发负责人对修改情况进行跟踪检查,组织各开发商专业测试人员对修改后的应用程序进行回归测试,
f)各级开发商开发负责人对修改情况进行跟踪检查,并将修改完成情况(《问题跟踪报告》)及时汇总并反馈给总集
g)所有开发商的问题修改完成,总集成商的测试人员进行问题的回归测试。
3.5测试沟通会议
附录A (资料性附录)
参考文献
ICS A JZB 金 质 工 程 标 准 JZB XXX—2007 应用系统集成测试规范 (征求意见稿) (成稿日期:2007 年 10 月) ××××-××-××发布 ××××-××-××实施 金质工程 建设领导小组 发 布
JZB XXX—2007 目 录 言 ............................................................................................................................................II 前 1 范围 ............................................................................................................................................ 1 2 术语和定义................................................................................................................................ 1 3 应用系统集成测试规范 ............................................................................................................ 2 3.1 集成测试的前提条件 ....................................................................................................2 3.2 集成测试的内容 ............................................................................................................ 2 3.3 集成测试过程 ................................................................................................................ 3 3.4 测试发现问题的处理流程 ............................................................................................4 3.5 测试沟通会议 ................................................................................................................ 5 附录 A (资料性附录) .................................................................................................................. 6 参考文献 ............................................................................................................................................ 9 I
JZB XXX—2007 前 言 本标准由国家质量监督检验检疫总局提出。 本标准由国家质量监督检验检疫总局归口。 本标准由国家质量监督检验检疫总局负责解释。 本标准起草单位:国家质量监督检验检疫总局、沈阳东软软件股份有限公司。 本标准主要起草人: II
JZB XXX—2007 应用系统集成测试规范 1 范围 本标准规定了测试各个二次开发商所开发的应用系统协同运行的方法和程序。 本标准适用于:“金质工程”项目办公室,总集成商、监理、测试者等。 2 术语和定义 2.1 金质办 “金质工程”项目建设办公室简称,是“金质工程”建设领导小组的具体办事机构,负 责工程建设的组织协调工作,由总局和领导小组授权代表总局开展与“金质工程”相关的对 外联系工作。负责整个“金质工程”项目的招投标、实施、管理、监督、汇报工作。 2.2 用户 国家质检总局所属的所有和“金质工程”项目有关的单位的统称,包括监督司、质量司、 计量司、特设局、食品司、执法司、动植司、食品局、检验司、通关司、标准委、认监委、 标法中心等各级相关部门。 2.3 监理 是指“金质工程”一期项目的监理服务提供商,负责整个“金质工程”一期项目的进展 情况、实施质量、投资监控、信息安全和知识产权保护、信息管理和组织协调,对项目实施 全程进行监理。 2.4 总集成商 负责“金质工程”一期项目的总集成工作,按照合同规定内容要求开展工作。 2.5 总标准商 是“金质工程”的标准规范建设单位,负责整个“金质工程”的标准编制。 2.6 各级开发商 参加“金质工程”一期项目的各应用软件系统或专项信息系统的开发商的统称。 2.7 PM&PSM PM-项目经理,是各级开发商每个业务应用软件系统的项目负责人。 PSM-软件项目经理,也可以是各级开发商的应用软件开发负责人。 2.8 评审 为评估工作成果而召开的会议,参加会议的人员是有关专家(分业务和技术)、“金质 工程”建设的各方人员,可以包括业主单位成员、监理单位成员、总集成单位成员、各级开 发商单位项目管理成员以及其他和“金质工程”有关的人员。 1
JZB XXX—2007 2.9 审核 对于工作成果进行的独立审查,检查工作成果是否符合规范、标准、合同或其他的准则。 审核可以由任何被赋予其职责的单位或成员执行。 3 应用系统集成测试规范 各级开发商要严格按照测试规范和总标准的测试标准要求进行测试活动,安排合理的人 员,进行应用软件系统的全面测试。 要求各级开发商针对各自负责的应用系统的测试工作执行如下策略:  组建最专业的测试队伍  坚持统一规划、审慎论证、精心设计、分步执行的测试原则  利用完整的测试方法,从不同的角度和维度,对软件系统的各个方面实施测试和 评价工作。 各级开发商要完善各自的测试组织体系,并在系统测试结束后提供《测试报告》给监理、 总集成商、总标准商、金质办。由监理组织对测试《测试报告》进行评审,被评审通过后方 可进入下一个应用系统集成测试软件过程。 3.1 集成测试的前提条件 进入应用系统集成测试软件过程,必须满足以下条件: a) 参与集成测试的各应用软件系统经过了各级开发商的单元测试、集成测试,测试 总结报告通过了监理、总集成商、总标准商、金质办的评审。 b) 参与集成测试的各级开发商提出集成测试的书面申请,各级开发商并已经准备好 了接口测试用例。 c) 参与集成测试的各级开发商的应用系统已经集中,并已经搭建好了测试的环境。 d) 测试环境准备完毕。包括场地安排、网络联调、硬件环境、参与集成测试的各级 开发商的配合支持人员已经到位等。 满足以上条件,由总集成商会同各级开发商给出《集成测试计划》安排,提交监理、金 质办、总标准商审核,审核通过后开始进行集成测试。 3.2 集成测试的内容 应用系统集成测试过程中关注以下几方面: a) 在把各个应用系统连接起来的时候,穿越系统接口的数据是否会丢失,数据转换 是否正确,数据权限是否准确; b) 一个系统的功能是否会对另一个系统的功能产生不利的影响; c) 各个子系统组合起来,能否达到“金质工程”一期系统预期的要求; d) “金质工程”的整体数据结构是否有问题; e) 各子系统组合起来的性能是否符合多个用户的业务管理需求。 应用系统集成测试的内容由总集成商提出,由金质办、监理、总标准商审核,具体内容 参见《集成测试计划》。包括但不限于以下内容: 1) 各级开发商的应用软件界面内容。 ——各级开发商的软件界面内容、界面风格是否符合“金质工程”的统一的规范、标 准要求; ——功能分布是否合理; ——界面是否可以方便的和其他应用软件系统界面进行集成。 2) 统一权限 2
JZB XXX—2007 ——权限的设定是否符合“金质工程”的要求和规划; ——多个系统之间的权限统一设定的测试; ——总局、司(局、中心)、省、市多级权限设定的测试。 3) 组织机构 ——组织机构的设定是否符合“金质工程”统一的规范要求; ——多个系统之间的组织机构的设定、一致性测试。 4) 共享数据访问机制、数据交换 ——内部系统之间的数据展现与应用:质量、计量、质检、食品、特设、执法等各业 务应用软件系统内部生成的、需要为其它业务提供共享的数据内容是否可以有效的在另一个 质检业务应用系统中展现和应用;包括质量数据、计量数据、特设数据、监督数据、食品数 据、执法数据、检验检疫数据、行政许可数据等。 ——内部系统与外部系统之间的数据展现与应用:质量、计量、质检、食品、特设、 执法等各业务应用软件系统对质检行业外的信息系统提供的数据是否有效;来自于质检行业 外部信息系统的数据是否有效的展现和应用。 ——数据交换:质量、计量、质检、食品、特设、执法等质检行业内部各业务应用软 件系统之间的数据交换是否符合“金质工程”设计规范标准。包括质量交换、计量交换、特 设交换、监督交换、食品交换、执法交换、检验检疫交换、行政许可交换等。 ——质检内部业务应用软件系统与质检外部应用系统的数据交换是否符合各业务的 需要和规范标准要求,数据走向是否正确。包括组织机构代码交换及其他。 5) 信息发布 质量、计量、质检、食品、特设、执法等各业务应用软件系统对内、对外信息发布是 否符合“金质工程”的规范和标准。包括质量数据、计量数据、特设数据、监督数据、食品 数据、执法数据、检验检疫数据、行政许可数据发布等。 6) 系统的安全性、稳定性等。 ——多个应用软件系统联动的安全性、稳定性等指标是否满足“金质工程”标准和规 范的要求。 ——开放性测试包括:数据内容类标准、通讯协议类标准、开发接口类标准、信息编 码类标准; ——可管理性测试:包括系统的维护、管理、变更、定制、授权等管理和维护功能进 行测试。 ——安全性测试:主要从程序体系结构和设计入手,对被测系统在部署与基础结构、 输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密、参数操作、异常管理、 审核和日志记录等几个方面入手。 ——稳定性测试:测试业务系统在日常负载下能够稳定运行的时间,通常对于 7*24 小时不间断系统,要求系统在稳定性测试阶段持续运行 72 小时以上,而对于 5*8 小时日常 业务系统,被测系统在稳定性测试阶段持续运行 10 小时以上即可。 ——性能测试:对系统的响应速度,数据处理能力等测试对象的能力要求和操作特征 等。将性能测试概括为三个方面:  应用在客户端性能的测试  应用在网络上性能的测试  应用在服务器端性能的测试。 3.3 集成测试过程 测试过程参考软件工程的过程,分五个阶段开展测试工作:测试准备、测试计划、测试 3
JZB XXX—2007 设计、测试执行、测试总结。 在测试工作开始前,制定详细的测试计划,围绕测试的目标,制定相应的测试策略及测 试计划,测试计划内容中要体现包括被评估被测系统之间的关系,系统间的架构关联、用户 的性能需求、用户的行为模式。测试计划的步骤分为确定测试需求、进行风险评估、确定资 源、确定测试日程表、生成测试计划。 测试设计的步骤分为:确定并描述测试用例、检查评估测试覆盖、创建和确认测试程序、 创建和维护测试外部数据集。 测试执行主要包括执行测试过程、评价测试执行情况、对比核实测试结果等内容。一般 来说,测试执行活动结束或终止时,以下两种情况之一会出现:  正常终止:所有测试过程(或脚本)按预期方式执行至结束。  异常或提前结束:测试过程(或脚本)没有按预期方式执行或没有完全执行。当 测试异常终止时,测试结果可能不可靠。在执行任何其他测试活动之前,应确定并 解决异常/提前终止的原因,然后重新执行测试。 测试过程中,可能会出现意外中断测试进程的错误,因此测试组会针对这种情况,确定 问题的实际原因,并纠正问题,重置测试环境,然后重新执行测试。 一般来说,这种情况可能由以下两种错误导致:  致命错误 - 系统故障(网络故障、硬件崩溃等)。  测试脚本命令故障。 测试总结 评价测试结果是指通过评价测试结果、确定并记录变更请求,以及计算主要测试评 测方法来完成的。评价步骤和内容主要包含:  分析测试结果并提交变更请求,以保证测试已执行完全,并确保报告的测试结果 没有受到非测试对象因素的影响;  评估基于需求的测试覆盖,来确定:需求的测试(测试用例)的数量与测试对象 的总需求测试数量的比例。  分析缺陷,目的在于通过队缺陷密度、趋势等的分析,将本次迭代的评测方法与 先前各次迭代的分析结果进行比较,判断缺陷的走势,为缺陷修正和下一次迭代 测试提供可资借鉴的依据。其中:  缺陷密度 – 单位代码量测试发现的缺陷数量  缺陷趋势 – 以图表形式表现的缺陷数目以随时间变化的函数曲线  生成测试评估摘要 测试过程中,对缺陷(bug)进行实时的统计、跟踪,并监控测试质量,评估整体系统 的质量,给出软件集成测试报告。 测试结束后,测试组将依据上述信息内容撰写《软件集成测试报告》,并将其分发给金 质办、监理、总标准商、用户等进行评审。若《软件集成测试报告》没有被评审通过,集成 测试要进行完善计划,并完善测试。 3.4 测试发现问题的处理流程 a) 测试人员测试后填写《测试问题卡》并及时提交测试负责人。 b) 测试负责人对《测试问题卡》进行审阅、汇总,并进行签字确认。 c) 测试负责人将汇总确认后的《测试问题卡》交给各级开发商开发负责人,同时进行 存档。 d) 开发商开发负责人接到《测试问题卡》后,首先进行审阅,如有疑问的与总集成商 测试负责人进行沟通,确认必须修改的马上派发给相关开发人员进行修改。 4
分享到:
收藏