信息系统项目测试方案设计说明

1、信访局网上信访信息系统项目系统测试方案2015年7月新汇科计算机Taiyuan New Qu ick Computer Co.,L TD本文档及其所含信息为材料并且由晋中市及所辖各县（市、区）信访局和新汇科计算机共同拥有。文档中任何部分未经晋中市及所辖各县（市、区）信访局和新汇科计算机书面授权，不得泄露给第三方，也不得以任何手段、任何形式进行复制与传播目录1 概述 11.1 目标 11.2 假设 11.3 测试围 21.4 测试方法 21.5 测试步骤 31.6 测试进入准则 41.7 测试结束准则 42 测试地点、人员与环境 . 42.1 测试的地点和人员 42.2 测试环境 53 组织结构

2、 53.1 组织结构 53.2 职责围 54 计划任务与时间 . 74.1 计划任务 74.2 时间表 84.3 安排 94.4 测试更新安排 175 人员的岗位职责 . 186 缺陷管理 206.1 缺陷管理流程 206.2 缺陷的严重度和修改的优先级（此问题请见测试报告） 237 测试报告总结和分析 . 261 概述省网上信访信息系统测试方案 （以下简称 测试方案）是省网上信访信 息系统编码、单元测试完成后， 在进行系统测试之前， 针对优化版的业务功能进 行功能和集成测试的计划安排。测试方案 主要明确系统功能和集成测试的有关规定和原则， 其目的是提供系统功能和集成测试所依据和遵循的原则、方

3、法和组织结构。1.1 目 标用户测试阶段应达到并完成以下的主要目的与任务：目的在于检查优化需求版系统功能能否满足实际业务要求， 流程是否符合各 级信访机构日常业务程序。对系统的业务功能进行测试， 以验证是否达到了用户设计的业务要求， 保证 产品能够满足客户的业务需求。 （这里的业务需求指的是省网上信访信息系统 需求规格说明书、省网上信访信息系统需求变更 、省网上信访信息系统需求 深化、省网上信访信息系统需求补充 ）对系统存在的业务及功能错误进行纠错，保证系统运行的正确性。1.2 假 设假设有足够容量的服务器资源。假设有足够的测试工作站设备。 假设人员可以分班轮流，一个实际工作日能够测试多于一个

4、的测试营业日。 假设测试中发现的问题能够得到及时的解决。假设测试的过程能够进行有效的监控。1.3 测试围本计划的测试仅包括目前开发完成的功能。1.4 测试方法 本次测试主要采用黑盒测试方法，即测试软件产品的功能，不需测试软 件产品的部结构和处理过程。黑盒测试的目的是试图尽可能地发现以下类型的错误： 功能错误或遗漏； 业务流程错误； 界面错误；数据结构或外部数据库访问错误； 初始化和终止错误。采用黑盒技术设计测试用例的方法主要有：等价类划分；边界值分析；错误推测；因果图分析；综合策略。1.5 测试步骤测试执行前的准备：1. 编写测试计划：由测试领导小组编写，明确测试组织的结构和职责，确 定系统测

5、试的流程以及系统测试所应完成的业务过程的周期；2. 准备测试数据：由新汇科测试组的人员准备系统基础测试数据，由信访 局业务功能测试人员准备业务所需要的数据；3. 准备测试用例：由新汇科测试组的人员依据系统用例和业务功能编写测试用例，由信访局业务功能测试人员补充完善测试用例；4. 准备测试环境并初始化数据库；用户测试执行过程：1. 按计划将任务分配给各个测试人员；2. 各测试人员按照计划，根据测试用例进行测试；3. 依据测试用例和业务过程的测试周期进行系统功能和流程的测试，对测 试的结果进行验证，对测试的错误进行判别并确定修改准则；4. 若测试人员发现 BUG，登录到问题单中；在测试列表清单中登

6、记测试情况（通过或未通过、未通过的填上BUG编号），如果是二次测试并且测试通过，到问题平台上关闭相应的 BUG。1.6 测试进入准则1. 测试所需的设备及测试环境可用。2. 所有支持人员到位。3. 所有源码及环境的监控步骤已经明确并同意。4. 所有有关人员对其工作围和职责明确无误。5. 所有的测试用例已经完成并获得审查通过。1.7 测试结束准则1. 所有测试用例及其相关用例均已测试完成，测试有关的文档齐全，测试 结果均已接受。2. 所有发现的致命和严重问题已经解决。2 测试地点、人员与环境2.1 测试的地点和人员测试地点： 吕梁云计算中心 测试人员：省信访局建设办测试人员及新汇科公司需求、测试

7、、支持人员。2.2 测试环境网上投诉系统： 59.48.248.88:7096/wsts/门户： 59.48.248.88:7096/旧业务数据迁移系统： 59.48.248.88:7096/wsts/自助信访终端系统： 59.49.32.213:28080/touch/touch2.jsp3 组织结构3.1 组 织结构主要人员由省信访局和新汇科计算机的人员组成。3.2 职责围总负责人：监控所有的测试活动及任务的执行情况对测试过程中有关的问题及事项进行决策对测试的总体进行跟踪、控制和报告总协调人：落实测试所需的有关问题，协调解决需用户落实的问题 协调与安排用户的参与测试组：主要由新汇科专业测试

8、人员组成，其职责为:提供所需的技术支持，如环境、硬件、软件、网络支持测试小组顺利开展测试工作落实解决测试过程中的问题协调测试与开发之间的一致性辅导各功能测试小组进行测试测试缺陷管理在测试阶段的终结提交测试报告测试文档管理支持组：主要由新汇科开发小组的负责人组成，其职责为:支持测试小组的测试工作对测试时所产生的问题提供技术及系统解决方案解决测试中遇到的问题（安排）修改测试发现的缺陷系统环境的优化各业务功能测试小组：准备测试数据、测试材料，并协同测试组一起完善测试用例执行测试 提交测试发现的缺陷4 计划任务与时间4.1 计 划任务环境准备：测试场地硬件网络环境系统软件应用软件应用软件的设计（参数及

9、数据库初始化等）辅助设备准备：（负责人：业务功能测试人员）用例准备与审查：（负责人：新汇科测试人员、业务功能测试人员）准备各业务之测试用例审查用例计划准备：（负责人：业务功能测试人员）组织结构及人员安排 测试与问题处理的流程确定测试时间表执行测试：（负责人：测试小组人员）执行计划的用例测试对测试的问题进行处理进行测试的例会对测试结果进行抽检进行测试有关的文档控制与管理测试结束：（负责人：新汇科测试人员、业务功能测试人员）对测试的结果进行评测准备并提交总体测试报告4.2 时 间表在测试时，将按照测试任务定义来进行测试。每个测试任务都有唯一的编号，并对应一个或多个测试用例。具体一个测试任务由那几个

10、测试用例组成，请参看测试用例 。测试时间表如下，详细的测试任务分配表由各业务功能测试小组制订。（工作日）1用户资料准备及整理22测试环境搭建13初始化参数及数据准备24制订小组测试任务分配表15编写（完善） 测试用例和准备测试数据56领导对优化版进行总结0.56测试培训18执行测试和回归测试139回归测试与测试总结34.3 安排模块测试安排序号系统名称模块名称工期时间（工作日）1门户系统容编审42栏目管理与授权模块23增加栏目14删除栏目0.55复制栏目0.56移动栏目27排序栏目28访问权限29委托管理110热点词汇管理与自动维护模块111热点词汇定义212热点词汇查找213热点词汇自动21

11、4容编辑工具与容管理模块215文件管理模块216容展现模块定义与管理模块217容关系管理模块218容审核模块419政治敏感信息审核220容正确性审核221容发布222容加工与生成模块123提取已审批通过文档224关联到网页模板225发布到网页0.526容发布模式定义与管理模块227主要容228程序触发发布模式229事件驱动发布模式2.530定时发布模式131实时发布模式232容发布模块233主要功能334重新发布栏目135重新发布文章0.536基于模板生成动态页面237基于模板生成静态页面138系统管理139工作流程管理模块440用户、角色及权限管理模块141新增角色342删除角色143更新角

12、色144角色权限对应关系245分配用户角色246新增用户1.547删除用户2.548更新用户149登录信息与认证管理模块150系统管理人员身份验证251系统管理人员的角色权限分配152多用户对系统的同时访问和操作253系统备份 / 恢复模块254自动备份155手工备份256资料恢复257栏目设计358UI 设计259首页设计0.560栏目页设计261容页设计1.562导航设计263领导介绍164信访局职责165机构设置166工作要闻1.567信访法规168信访指南0.569工作动态170图片新闻171重要新闻272网上信访大厅多媒体设计2.573网上信访大厅接口开发374网上投诉平台系统信访人

13、管理子系统275信访人注册模块0.576录入注册信息1.577注册信息校验178提交注册信息279信访人身份验证模块180登录系统时身份验证281判断住址的有效性1.582问题发生地的有效性283用户名校验284密码校验2.585个人信息维护模块386更新个人信息187信访人后台管理模块288信访事项登记子系统189登记投诉请求模块1.590录入投诉请求信息0.591校验投诉请求信息292提交投诉请求信息193生成并反馈查询码模块194生成反馈唯一查询码295与专网生成的查询码做是否相同的校验496申请复查登记模块197输入查询码校验有效性198选择信访类别399录入复查事项理由2100申请复

14、核登记模块0.5101输入查询码校验有效性2102列出复查结果1103录入复核项及理由2104办理事项网上查询子系统2105投诉请求办理情况查询模块0.5106验证查询码2107短消息提示2108多个投诉请求查询1109申请复查办理情况查询模块2110验证查询码4111短消息提示2112多个申请复查查询3113申请复核办理情况查询模块1114验证查询码1115短消息提示2116多个申请复核查询1117信访人满意度评价系统2118满意度评价1119数据整理2120建立数据字典2121旧业务数 据迁移表字段映射1122代码映射2123数据质量分析0.5124数据规性检查3125数据合法性检查212

15、6数据完整一致性检查1127数据质量分析过程2128数据差异分析2.5129数据调整与迁移2130数据迁移整体测试0.5131转换处理流程可行性的测试1132转换工具或转换程序的测试1133单位数据量各个子系统、各个转换步骤，转换所需时间的测试2134校验程序的测试1135应急措施的测试1136数据迁移围2137数据交换系统1138数据采集2139数据交换2140数据接收校验入库2.5141上行交换容2142交换频度2143交换数据的来源3144数据交换系统技术环境2145数据质量管理2146系统性能1.5147扩展实施2148数据抽取2149数据接收1150数据管理2151日志管理2152用

16、户真伪验证1153用户手机号格式及是否合法验证3154用户手机号是否可用验证2155用户注册信息验证2156用户扫描二代进行注册2157用户扫描二代进行登录0.5158扫描打印一体机扫描纸质材料生成图片2159上传扫描成图片材料2160上传材料验证2161信访接待上传材料成功信息反馈4162大厅自助终端系统删除上传材料2163投诉写信容验证1164投诉写信提交2165投诉写信是否允许提交验证2166每日已投诉不允许再次投诉提示2167投诉写信成功提示1168查看已投诉信访件0.5169查看信访件详情2170查看信访件的办理情况3171已处理信访件满意度评价2172已处理信访件满意度评价提交21

17、73扫描二代查询来信来访件2174验证来信来访码的有效性0.5175查看来信来访详情2176查看来信来访满意度评价2177来信来访满意度评价提交2178自助查询一体机公告显示1179自助终端投诉与网上投诉系统用户通用2180自助终端投诉与网上投诉系统数据互通1181自助终端投诉与业务办理系统数据互通2182二代读卡器扫描二代信息1183系统还原工具保护系统安全及不被更改0.5184触摸屏浏览器提供专门的页面效果24.4 测试更新安排每日问题反馈：1. 每天下午 6 点：将用户测试问题按照各系统分类进行整理，并进行问题 分析后发给需求组。2. 每天晚上 7 点半：完成对当天用户提出问题的分析。3

18、. 每天晚上 10 点前：与开发组各组长制定当天反馈问题的修改计划和每个 问题的反馈意见，并发给现场参与测试人员。每日版本升级：1. 每天下午 5 点前：将修改后的问题部署到集成测试环境。2. 每天下午 6 点：开发人员和测试人员完成在集成测试环境下的测试3. 每天下午 6 点半：将测试通过后的更新包打包并发给实施组4. 每天晚上 9 点前：完成信访局测试环境的更新部署。5. 每天晚上 10 点前：完成信访局测试环境更新部署的测试。5 人员的岗位职责测试员的工作：执行测试 执行测试案例 检查测试结果 填写测试结果 填写测试问题单后提交开发人员重新测试 重新执行测试 重新检查测试结果 重新填写测

19、试结果 更新问题单并通知开发人员重测结果问题负责人的工作： 确定问题的围 统筹问题的解决及修改并进行必须的测试及负责问题跟踪汇报 更新问题单 把问题单及所有测试记录送回测试人员 登记问题 （ 记录收到问题的日期及时间，并分派问题编号，置问题状态为“ OPEN”） 评估问题的严重性 （ 非常严重、严重、一般，轻微 ） 分派问题到问题负责人收到从问题负责人送回的问题单 记录收到问题单回应的日期时间 判定问题是否得到解决 如果问题得到解决，置问题状态为 “PENDING RE-TES”T， 并把所 有测试记录送交测试员进行重测 如果问题没有得到解决而需要重新分派问题到别的负责人，更新问 题记录中负责

20、人的、 转发日期时间， 并把问题单及所有测试记录转交新 的负责人收到从测试员在重测后送回的问题单 记录有关重测的日期时间及结果 如果重新测试成功，则置问题状态为 “ CLOSE”D，把问题单及所有 测试记录存档 如果重新测试失败，置问题状态为 “ OPEN”，把问题单及所有测试 记录送交最后的问题负责人日常的工作 准备有关问题的报告问题总表问题延误解决分析表 （ 在预定时间没有得到解决的问题 ） 跟踪有关问题单，保证得到问题负责人的高度重视 保存所有问题及测试记录，以备审查之用6 缺陷管理6.1 缺陷管理流程本项目的测试将利用问题报告单进行程序缺陷的管理，问题报告单能如 实地记录着每个问题的处

21、理过程。下面是缺陷管理的基本流程：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管理流程如下图所示：接受测试任务执行测试指派给对应应用开发小组组长N登记 Bu