信息系统项目测试方案

系统测试方案

2015年7月

太原新汇科计算机有限公司

Taiyuan New Quick Computer Co.,LTD

本文档及其所含信息为机密材料

并且由晋中市及所辖各县（市、区）信访局和太原新汇科计算机有限公司共同拥有。

文档中任何部分未经晋中市及所辖各县（市、区）信访局和太原新汇科计算机有限公司书面授权，

不得泄露给第三方，也不得以任何手段、任何形式进行复制与传播

1概述

《山西省网上信访信息系统测试方案》（以下简称《测试方案》）是山西省网上信访信息系统编码、单元测试完成后，在进行系统测试之前，针对优化版的业务功能进行功能和集成测试的计划安排。

《测试方案》主要明确系统功能和集成测试的有关规定和原则，其目的是提供系统功能和集成测试所依据和遵循的原则、方法和组织结构。

1.1目标

用户测试阶段应达到并完成以下的主要目的与任务：

目的在于检查优化需求版系统功能能否满足实际业务要求，流程是否符合各级信访机构日常业务程序。

对系统的业务功能进行测试，以验证是否达到了用户设计的业务要求，保证产品能够满足客户的业务需求。（这里的业务需求指的是《山西省网上信访信息系统需求规格说明书》、《山西省网上信访信息系统需求变更》、《山西省网上信访信息系统需求深化》、《山西省网上信访信息系统需求补充》）

对系统存在的业务及功能错误进行纠错，保证系统运行的正确性。

1.2假设

假设有足够容量的服务器资源。

假设有足够的测试工作站设备。

假设人员可以分班轮流，一个实际工作日能够测试多于一个的测试营业日。

假设测试中发现的问题能够得到及时的解决。

假设测试的过程能够进行有效的监控。

1.3测试范围

本计划的测试仅包括目前开发完成的功能。

1.4测试方法

本次测试主要采用黑盒测试方法，即测试软件产品的功能，不需测试软件产品的内部结构和处理过程。

黑盒测试的目的是试图尽可能地发现以下类型的错误：

●功能错误或遗漏；

●业务流程错误；

●界面错误；

●数据结构或外部数据库访问错误；

●初始化和终止错误。

采用黑盒技术设计测试用例的方法主要有：

●等价类划分；

●边界值分析；

●错误推测；

●因果图分析；

●综合策略。

1.5测试步骤

测试执行前的准备：

1.编写测试计划：由测试领导小组编写，明确测试组织的结构和职责，确定系统测试的流程以及系统测试所应完成的业务过程的周期；

2.准备测试数据：由新汇科测试组的人员准备系统基础测试数据，由信访局业务功能测试人员准备业务所需要的数据；

3.准备测试用例：由新汇科测试组的人员依据系统用例和业务功能编写测试用例，由信访局业务功能测试人员补充完善测试用例；

4.准备测试环境并初始化数据库；

用户测试执行过程：

1.按计划将任务分配给各个测试人员；

2.各测试人员按照计划，根据测试用例进行测试；

3.依据测试用例和业务过程的测试周期进行系统功能和流程的测试，对测试的结果进行验证，对测试的错误进行判别并确定修改准则；

4.若测试人员发现BUG，登录到问题单中；

在测试列表清单中登记测试情况（通过或未通过、未通过的填上BUG编号），如果是二次测试并且测试通过，到问题平台上关闭相应的BUG。

1.6测试进入准则

1.测试所需的设备及测试环境可用。

2.所有支持人员到位。

3.所有源码及环境的监控步骤已经明确并同意。

4.所有有关人员对其工作范围和职责明确无误。

5.所有的测试用例已经完成并获得审查通过。

1.7测试结束准则

1.所有测试用例及其相关用例均已测试完成，测试有关的文档齐全，测试结果均已接受。

2.所有发现的致命和严重问题已经解决。

2测试地点、人员与环境

2.1测试的地点和人员

测试地点： 吕梁云计算中心

测试人员：山西省信访局建设办测试人员及新汇科公司需求、测试、支持人员。

2.2测试环境

网上投诉系统：http://59.48.248.88:7096/wsts/

门户网站：http://59.48.248.88:7096/

旧业务数据迁移系统：http://59.48.248.88:7096/wsts/

自助信访终端系统：http://59.49.32.213:28080/touch/touch2.jsp

3组织结构

3.1组织结构

主要人员由山西省信访局和新汇科计算机有限公司的人员组成。

3.2职责范围

●总负责人：

⏹监控所有的测试活动及任务的执行情况

⏹对测试过程中有关的问题及事项进行决策

⏹对测试的总体进行跟踪、控制和报告

●总协调人：

⏹落实测试所需的有关问题，协调解决需用户落实的问题

⏹协调与安排用户的参与

●测试组：主要由新汇科专业测试人员组成，其职责为：

⏹提供所需的技术支持，如环境、硬件、软件、网络

⏹支持测试小组顺利开展测试工作

⏹落实解决测试过程中的问题

⏹协调测试与开发之间的一致性

⏹辅导各功能测试小组进行测试

⏹测试缺陷管理

⏹在测试阶段的终结提交《测试报告》

⏹测试文档管理

●支持组：主要由新汇科开发小组的负责人组成，其职责为：

⏹支持测试小组的测试工作

⏹对测试时所产生的问题提供技术及系统解决方案

⏹解决测试中遇到的问题

⏹（安排）修改测试发现的缺陷

⏹系统环境的优化

●各业务功能测试小组：

⏹准备测试数据、测试材料，并协同测试组一起完善测试用例

⏹执行测试

⏹提交测试发现的缺陷

4计划任务与时间

4.1计划任务

●环境准备：

⏹测试场地

⏹硬件网络环境

⏹系统软件

⏹应用软件

⏹应用软件的设计（参数及数据库初始化等）

●辅助设备准备：（负责人：业务功能测试人员）

●用例准备与审查：（负责人：新汇科测试人员、业务功能测试人员）

⏹准备各业务之测试用例

⏹审查用例

●计划准备：（负责人：业务功能测试人员）

⏹组织结构及人员安排

⏹测试与问题处理的流程

⏹确定测试时间表

●执行测试：（负责人：测试小组人员）

⏹执行计划的用例测试

⏹对测试的问题进行处理

⏹进行测试的例会

⏹对测试结果进行抽检

⏹进行测试有关的文档控制与管理

●测试结束：（负责人：新汇科测试人员、业务功能测试人员）

⏹对测试的结果进行评测

⏹准备并提交《总体测试报告》

4.2时间表

在测试时，将按照测试任务定义来进行测试。每个测试任务都有唯一的编号，并对应一个或多个测试用例。具体一个测试任务由那几个测试用例组成，请参看《测试用例》。

测试时间表如下，详细的测试任务分配表由各业务功能测试小组制订。

模块测试安排

每日问题反馈：

1.每天下午6点：将用户测试问题按照各系统分类进行整理，并进行问题分析后发给需求组。

2.每天晚上7点半：完成对当天用户提出问题的分析。

3.每天晚上10点前：与开发组各组长制定当天反馈问题的修改计划和每个问题的反馈意见，并发给现场参与测试人员。

每日版本升级：

1.每天下午5点前：将修改后的问题部署到集成测试环境。

2.每天下午6点：开发人员和测试人员完成在集成测试环境下的测试。

3.每天下午6点半：将测试通过后的更新包打包并发给实施组。

4.每天晚上9点前：完成山西信访局测试环境的更新部署。

5.每天晚上10点前：完成山西信访局测试环境更新部署的测试。

5人员的岗位职责

●测试员的工作：

●执行测试

－    执行测试案例

－    检查测试结果

－    填写测试结果

－    填写测试问题单后提交开发人员

●重新测试

－    重新执行测试

－    重新检查测试结果

－    重新填写测试结果

－    更新问题单并通知开发人员重测结果

●问题负责人的工作：

－    确定问题的范围

－    统筹问题的解决及修改并进行必须的测试及负责问题跟踪汇报

－    更新问题单

－    把问题单及所有测试记录送回测试人员

－    登记问题(记录收到问题的日期及时间，并分派问题编号，置问题状态为“OPEN”)

－    评估问题的严重性(非常严重、严重、一般，轻微)

－    分派问题到问题负责人

●收到从问题负责人送回的问题单    

－    记录收到问题单回应的日期时间

－    判定问题是否得到解决

－    如果问题得到解决，置问题状态为 “PENDING RE-TEST”， 并把所有测试记录送交测试员进行重测

－    如果问题没有得到解决而需要重新分派问题到别的负责人，更新问题记录中负责人的姓名、转发日期时间，并把问题单及所有测试记录转交新的负责人

●收到从测试员在重测后送回的问题单

－    记录有关重测的日期时间及结果

－    如果重新测试成功，则置问题状态为 “CLOSED”，把问题单及所有测试记录存档

－    如果重新测试失败，置问题状态为 “OPEN”，把问题单及所有测试记录送交最后的问题负责人

●日常的工作

－    准备有关问题的报告

问题总表

问题延误解决分析表(在预定时间内没有得到解决的问题)

－    跟踪有关问题单，保证得到问题负责人的高度重视

－    保存所有问题及测试记录，以备审查之用

6缺陷管理

6.1缺陷管理流程

本项目的测试将利用问题报告单进行程序缺陷的管理，问题报告单能如实地记录着每个问题的处理过程。

下面是缺陷管理的基本流程：

1.登记BUG，将该BUG分配给对应业务开发组组长；

2.开发组组长查看BUG的相应信息，判断是否属于BUG，如果不是BUG，通知测试组组长，组织相关人员进行讨论，经确定不是BUG后，测试组组长关闭该BUG；如果是BUG，开发组组长将该BUG分配给合适的开发人员进行修正，同时通知测试组组长，测试组组长安排人根据BUG的现象和对应的Use Case书写二次测试用例；

3.该BUG分配的开发人员着手进行修正，Bug经过修改和内部测试确定没有问题，开发组提交架构组进行新版本的集成，提交信息必须包含：新增加的用例、修改的用例号和对应的BUG ID；

4.开发人员修改BUG后，请在问题报告单上添加说明一栏中注明修改的信息。     

5.架构组统一修改新发布版本中所修订的BUG的状态为Resolved。

6.当BUG状态为Resolved和该BUG的二次测试用例准备完成后，测试组组长安排测试人员进行二次测试。

注：如果对Bug描述的现象需要进一步说明，请直接和相关的测试人员或辅导员进行沟通。

BUG管理流程如下图所示：

6.2缺陷的严重度和修改的优先级（此问题请见测试报告）

山西省网上信访信息系统

测试业务问题报告单

1.问题编号规则：模块名_报告日期（YYMMDD）_报告人_流水号，如：LX_070821_李四_01

2.文件命名规则：问题编号.doc

3.问题级别

●缺陷的严重程度级别：

7测试报告总结和分析

根据需要可以从问题平台中生成各种测试报告，并对测试报告统计数据进行分析以指导后期工作和资源的分布。