1、信访局网上信访信息系统项目系统测试方案2015年7月新汇科计算机1 TaiyuanNew Qu ick Computer Co.丄 TD本文档及其所含信息为机密材料并且由晋中市及所辖各县（市、区）信访局和新汇科计算机共同拥有。文档中任何部分未经晋中市及所辖各县（市、区）信访局和新汇科计算机书面授权,不得泄露给第三方，也不得以任何手段、任何形式进行复制与传播目录1 概述 11.1 目标 11.2 假设 11.3 测试围 21.4 测试方法 21.5 测试步骤 31.6 测试进入准则 31.7 测试结束准则 42 测试地点、人员与环境 42.1 测试的地点和人员 42.2 测试环境 43 组织结构
2、 53.1 组织结构 53.2 职责围 54 计划任务与时间 64.1 计戈V任务 64.2 时间表 74.3 安排 84.4测试更新安排 135 人员的岗位职责 136 缺陷管理 166.1 缺陷管理流程 166.2 缺陷的严重度和修改的优先级（此问题请见测试报告） 187 测试报告总结和分析 201概述省网上信访信息系统测试方案（以下简称测试方案）是省网上信访信 息系统编码、单元测试完成后，在进行系统测试之前，针对优化版的业务功能进 行功能和集成测试的计划安排。测试方案主要明确系统功能和集成测试的有关规定和原则， 其目的是提 供系统功能和集成测试所依据和遵循的原则、方法和组织结构。1.1目
3、标用户测试阶段应达到并完成以下的主要目的与任务：目的在于检查优化需求版系统功能能否满足实际业务要求，流程是否符合各 级信访日常业务程序。对系统的业务功能进行测试，以验证是否达到了用户设计的业务要求， 保证 产品能够满足客户的业务需求。（这里的业务需求指的是省网上信访信息系统 需求规格说明书、省网上信访信息系统需求变更、省网上信访信息系统需求 深化、省网上信访信息系统需求补充）对系统存在的业务及功能错误进行纠错，保证系统运行的正确性。1.2假设假设有足够容量的服务器资源。假设有足够的测试工作站设备。假设人员可以分班轮流，一个实际工作日能够测试多于一个的测试营业日假设测试中发现的问题能够得到及时的
4、解决。假设测试的过程能够进行有效的监控。1.3测试围本计划的测试仅包括目前开发完成的功能。1.4测试方法本次测试主要采用黑盒测试方法，即测试软件产品的功能，不需测试软 件产品的部结构和处理过程。黑盒测试的目的是试图尽可能地发现以下类型的错误：功能错误或遗漏；业务流程错误；界面错误；数据结构或外部数据库访问错误； 初始化和终止错误。采用黑盒技术设计测试用例的方法主要有：等价类划分；边界值分析；错误推测；因果图分析； 综合策略1.5测试步骤测试执行前的准备：1. 编写测试计划：由测试领导小组编写，明确测试组织的结构和职责，确 定系统测试的流程以及系统测试所应完成的业务过程的周期；2. 准备测试数据
5、：由新汇科测试组的人员准备系统基础测试数据，由信访 局业务功能测试人员准备业务所需要的数据；3. 准备测试用例：由新汇科测试组的人员依据系统用例和业务功能编写测 试用例，由信访局业务功能测试人员补充完善测试用例；4. 准备测试环境并初始化数据库；用户测试执行过程：1. 按计划将任务分配给各个测试人员；2. 各测试人员按照计划，根据测试用例进行测试；3. 依据测试用例和业务过程的测试周期进行系统功能和流程的测试，对测试的结果进行验证，对测试的错误进行判别并确定修改准则；4. 若测试人员发现BUG登录到问题单中；在测试列表清单中登记测试情况（通过或未通过、未通过的填上BUG编号），如果是二次测试并
6、且测试通过，到问题平台上关闭相应的BUG1.6测试进入准则1. 测试所需的设备及测试环境可用。2. 所有支持人员到位。3. 所有源码及环境的监控步骤已经明确并同意4. 所有有关人员对其工作围和职责明确无误。5. 所有的测试用例已经完成并获得审查通过。1.7测试结束准则1. 所有测试用例及其相关用例均已测试完成，测试有关的文档齐全，测试 结果均已接受。2. 所有发现的致命和严重问题已经解决。2测试地点、人员与环境2.1测试的地点和人员测试地点：吕梁云计算中心测试人员：省信访局建设办测试人员及新汇科公司需求、测试、支持人 员。2.2测试环境网上投诉系统：http:/59.48.248.88:709
7、6/wsts/门户：http:/59.48.248.88:7096/旧业务数据迁移系统：http:/59.48.248.88:7096/wsts/ 自助信访终端系统：http:/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热点词汇定义212P热点词汇查找213热点词汇自动214容编辑工具与容管理
11、模块215P文件管理模块216容展现模块定义与管理模块217P容关系管理模块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更新角色1
12、44角色权限对应关系245分配用户角色246新增用户1.547:删除用户2.548更新用户149登录信息与认证管理模块150:系统管理人员身份验证251系统管理人员的角色权限分配152多用户对系统的同时访问和操作253系统备份/恢复模块254自动备份155手工备份256:资料恢复257栏目设计358UI设计259P首页设计0.560栏目页设计261容页设计1.562:导航设计263领导介绍164信访局职责165:设置166:工作要闻1.567信访法规168信访指南0.569工作动态170图片新闻171:重要新闻272:网上信访大厅多媒体设计2.573网上信访大厅接口开发374信访人管理子系统2
13、75信访人注册模块0.576录入注册信息1.577注册信息校验178提交注册信息279:信访人身份验证模块180r登录系统时身份验证281判断住址的有效性1.582网上投诉:问题发生地的有效性283用户名校验2平台系统84密码校验2.585:个人信息维护模块386:更新个人信息187信访人后台管理模块288信访事项登记子系统189r登记投诉请求模块1.590录入投诉请求信息0.591校验投诉请求信息292:提交投诉请求信息193生成并反馈查询码模块194生成反馈唯一查询码295与专网生成的查询码做是否相冋的校验496申请复查登记模块197输入查询码校验有效性198:选择信访类别399录入复查事
14、项理由2100申请复核登记模块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数据合法
15、性检查2126旧业务数数据完整一致性检查1127据迁移数据质量分析过程2128:数据差异分析2.5129数据调整与迁移2130数据迁移整体测试0.5131转换处理流程可行性的测试1132:转换工具或转换程序的测试1133单位数据量各个子系统、各个转换步骤， 转换所需时间的测试2134校验程序的测试1135应急措施的测试1136数据迁移围2137数据交换系统1数据采集2数据交换2140数据接收校验入库2.5141上行交换容2142交换频度2143交换数据的来源3144数据交换系统技术环境2145数据质量管理2146系统性能1.5147扩展实施2148数据抽取2149数据接收1150数据管理215
16、1日志管理2152用户身份证真伪验证1153用户手机号格式及是否合法验证3154用户手机号是否可用验证2155用户注册信息验证2156用户扫描二代身份证进行注册2157用户扫描二代身份证进行登录0.5158扫描打印一体机扫描纸质材料生成图片2159上传扫描成图片材料2160上传材料验证2161上传材料成功信息反馈4162删除上传材料2163信访接待 大厅自助 终端系统投诉写信容验证1164投诉写信提交2165投诉写信是否允许提交验证2166每日已投诉不允许再次投诉提示2167投诉写信成功提示1168查看已投诉信访件0.5169查看信访件详情2170查看信访件的办理情况3171已处理信访件满意度
17、评价2172已处理信访件满意度评价提交2173扫描二代身份证查询来信来访件2174验证来信来访码的有效性0.5175查看来信来访详情2176查看来信来访满意度评价2177来信来访满意度评价提交2178自助查询一体机公告显示1179自助终端投诉与网上投诉系统用户通用2180自助终端投诉与网上投诉系统数据互通1181:自助终端投诉与业务办理系统数据互通2182二代身份证读卡器扫描二代身份证信息1183:系统还原工具保护系统安全及不被更改0.5184触摸屏浏览器提供专门的页面效果24.4测试更新安排每日问题反馈：1. 每天下午6点：将用户测试问题按照各系统分类进行整理，并进行问题 分析后发给需求组。
18、2. 每天晚上7点半：完成对当天用户提出问题的分析。3. 每天晚上10点前：与开发组各组长制定当天反馈问题的修改计划和每个 问题的反馈意见，并发给现场参与测试人员。每日版本升级：1. 每天下午5点前：将修改后的问题部署到集成测试环境。2. 每天下午6点：开发人员和测试人员完成在集成测试环境下的测试。3. 每天下午6点半：将测试通过后的更新包打包并发给实施组。4. 每天晚上9点前：完成信访局测试环境的更新部署。5. 每天晚上10点前：完成信访局测试环境更新部署的测试。5人员的岗位职责测试员的工作:执行测试-执行测试案例-检查测试结果-填写测试结果-填写测试问题单后提交开发人员重新测试重新执行测试
19、-重新检查测试结果重新填写测试结果更新问题单并通知开发人员重测结果问题负责人的工作：确定问题的围统筹问题的解决及修改并进行必须的测试及负责问题跟踪汇报更新问题单把问题单及所有测试记录送回测试人员登记问题（记录收到问题的日期及时间，并分派问题编号，置问题状态为“ OPEN ）评估问题的严重性（非常严重、严重、一般，轻微）分派问题到问题负责人收到从问题负责人送回的问题单记录收到问题单回应的日期时间判定冋题是否得到解决如果问题得到解决，置问题状态为“PENDING RE-TEST 并把所有测试记录送交测试员进行重测如果问题没有得到解决而需要重新分派问题到别的负责人，更新问 题记录中负责人的、转发日期
20、时间，并把问题单及所有测试记录转交新 的负责人收到从测试员在重测后送回的问题单记录有关重测的日期时间及结果如果重新测试成功，则置问题状态为“CLOSE”把问题单及所有测试记录存档如果重新测试失败，置问题状态为“OPE”把问题单及所有测试记录送交最后的问题负责人日常的工作准备有关问题的报告 问题总表问题延误解决分析表（在预定时间没有得到解决的问题）跟踪有关问题单，保证得到问题负责人的高度重视 保存所有问题及测试记录，以备审查之用6缺陷管理6.1缺陷管理流程本项目的测试将利用问题报告单进行程序缺陷的管理，问题报告单能如实地记录着每个问题的处理过程。下面是缺陷管理的基本流程：1. 登记BUG将该BU
21、酚配给对应业务开发组组长；2. 开发组组长查看BUG的相应信息，判断是否属于BUG如果不是BUG通知测试组组长，组织相关人员进行讨论，经确定不是BUG后，测试组组长关闭该BUG如果是BUG开发组组长将该BUG分配给合适的开发人员 进行修正，同时通知测试组组长，测试组组长安排人根据BUG的现象和对应的Use Case书写二次测试用例；3. 该BUG分配的开发人员着手进行修正，Bug经过修改和部测试确定没有 问题，开发组提交架构组进行新版本的集成，提交信息必须包含：新增加的用例、修改的用例号和对应的 BUG ID;4. 开发人员修改BUG后，请在问题报告单上添加说明一栏中注明修改的信息。5. 架构
22、组统一修改新发布版本中所修订的 BUG的状态为Resolved。6. 当BUG犬态为Resolved和该BUG的二次测试用例准备完成后，测试组组 长安排测试人员进行二次测试。注：如果对Bug描述的现象需要进一步说明，请直接和相关的测试人员或辅导员进行沟通。BUG管理流程如下图所示:6.2缺陷的严重度和修改的优先级（此问题请见测试报告）省网上信访信息系统测试业务问题报告单问题编号：提问日期：提问人：问题级别：问题修改优先级：问题所在模块：问题描述答复日期：答复人：答复扌苗述填写说明:1. 问题编号规则：模块名 _报告日期（YYMMDD_报告人_流水号，如:LX_070821_3 _012. 文件
23、命名规则：问题编号.doc3. 问题级别缺陷的严重程度级别:级别定义描述示例1致命系统测试无法进行下去，必 须重新测试。测试时出现Server死机2严重系统测试仍可继续进行，但 存在的冋题对系统功能有重 大影响，必须重新测试未完成指定的功能：比如无法保存录入的信息等等3一般冋题对系统功能造成影响，必须进行修正，但可根据情况决定是否需要重新测试操作界面不友好，错误信息含糊、不明确4轻微问题对系统功能影响不大， 必须进行修正，但无需重新 测试。界面有错别字等等修改优先级:优先级对应缺陷严重程度修改期限P1致命在发现该缺陷1天之P2严重在发现该缺陷3天之P3一般、轻微在发现该缺陷2星期之4.问题描述：请重点、详细地描述问题出现的过程和问题容7测试报告总结和分析根据需要可以从问题平台中生成各种测试报告， 并对测试报告统计数据进行 分析以指导后期工作和资源的分布。
