1、信息系统项目测试方案设计说明信访局网上信访信息系统项目系统测试方案2015年7月新汇科计算机Taiyuan New Quick Computer Co.,LTD本文档及其所含信息为材料并且由晋中市及所辖各县(市、区)信访局和新汇科计算机共同拥有。文档中任何部分未经晋中市及所辖各县(市、区)信访局和新汇科计算机书面授权,不得泄露给第三方,也不得以任何手段、任何形式进行复制与传播1 概述省网上信访信息系统测试方案(以下简称测试方案)是省网上信访信息系统编码、单元测试完成后,在进行系统测试之前,针对优化版的业务功能进行功能和集成测试的计划安排。测试方案主要明确系统功能和集成测试的有关规定和原则,其目
2、的是提供系统功能和集成测试所依据和遵循的原则、方法和组织结构。1.1 目标用户测试阶段应达到并完成以下的主要目的与任务:目的在于检查优化需求版系统功能能否满足实际业务要求,流程是否符合各级信访机构日常业务程序。对系统的业务功能进行测试,以验证是否达到了用户设计的业务要求,保证产品能够满足客户的业务需求。(这里的业务需求指的是省网上信访信息系统需求规格说明书、省网上信访信息系统需求变更、省网上信访信息系统需求深化、省网上信访信息系统需求补充)对系统存在的业务及功能错误进行纠错,保证系统运行的正确性。1.2 假设假设有足够容量的服务器资源。假设有足够的测试工作站设备。假设人员可以分班轮流,一个实际
3、工作日能够测试多于一个的测试营业日。假设测试中发现的问题能够得到及时的解决。假设测试的过程能够进行有效的监控。1.3 测试围本计划的测试仅包括目前开发完成的功能。1.4 测试方法本次测试主要采用黑盒测试方法,即测试软件产品的功能,不需测试软件产品的部结构和处理过程。黑盒测试的目的是试图尽可能地发现以下类型的错误: 功能错误或遗漏; 业务流程错误; 界面错误; 数据结构或外部数据库访问错误; 初始化和终止错误。采用黑盒技术设计测试用例的方法主要有: 等价类划分; 边界值分析; 错误推测; 因果图分析; 综合策略。1.5 测试步骤测试执行前的准备:1. 编写测试计划:由测试领导小组编写,明确测试组
4、织的结构和职责,确定系统测试的流程以及系统测试所应完成的业务过程的周期;2. 准备测试数据:由新汇科测试组的人员准备系统基础测试数据,由信访局业务功能测试人员准备业务所需要的数据;3. 准备测试用例:由新汇科测试组的人员依据系统用例和业务功能编写测试用例,由信访局业务功能测试人员补充完善测试用例;4. 准备测试环境并初始化数据库;用户测试执行过程:1. 按计划将任务分配给各个测试人员;2. 各测试人员按照计划,根据测试用例进行测试;3. 依据测试用例和业务过程的测试周期进行系统功能和流程的测试,对测试的结果进行验证,对测试的错误进行判别并确定修改准则;4. 若测试人员发现BUG,登录到问题单中
5、;在测试列表清单中登记测试情况(通过或未通过、未通过的填上BUG编号),如果是二次测试并且测试通过,到问题平台上关闭相应的BUG。1.6 测试进入准则1. 测试所需的设备及测试环境可用。2. 所有支持人员到位。3. 所有源码及环境的监控步骤已经明确并同意。4. 所有有关人员对其工作围和职责明确无误。5. 所有的测试用例已经完成并获得审查通过。1.7 测试结束准则1. 所有测试用例及其相关用例均已测试完成,测试有关的文档齐全,测试结果均已接受。2. 所有发现的致命和严重问题已经解决。2 测试地点、人员与环境2.1 测试的地点和人员测试地点: 吕梁云计算中心测试人员:省信访局建设办测试人员及新汇科
6、公司需求、测试、支持人员。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 职责围 总负责人: 监控所有的测试活动及任务的执行情况 对测试过程中有关的问题及事项进行决策 对测试的总体进行跟踪、控制和报告 总协调人: 落实测试所需的有关问题,协调解决需用户落实的问题 协调与安排用户的参与 测试组:主
7、要由新汇科专业测试人员组成,其职责为: 提供所需的技术支持,如环境、硬件、软件、网络 支持测试小组顺利开展测试工作 落实解决测试过程中的问题 协调测试与开发之间的一致性 辅导各功能测试小组进行测试 测试缺陷管理 在测试阶段的终结提交测试报告 测试文档管理 支持组:主要由新汇科开发小组的负责人组成,其职责为: 支持测试小组的测试工作 对测试时所产生的问题提供技术及系统解决方案 解决测试中遇到的问题 (安排)修改测试发现的缺陷 系统环境的优化 各业务功能测试小组: 准备测试数据、测试材料,并协同测试组一起完善测试用例 执行测试 提交测试发现的缺陷4 计划任务与时间4.1 计划任务 环境准备: 测试
8、场地 硬件网络环境 系统软件 应用软件 应用软件的设计(参数及数据库初始化等) 辅助设备准备:(负责人:业务功能测试人员) 用例准备与审查:(负责人:新汇科测试人员、业务功能测试人员) 准备各业务之测试用例 审查用例 计划准备:(负责人:业务功能测试人员) 组织结构及人员安排 测试与问题处理的流程 确定测试时间表 执行测试:(负责人:测试小组人员) 执行计划的用例测试 对测试的问题进行处理 进行测试的例会 对测试结果进行抽检 进行测试有关的文档控制与管理 测试结束:(负责人:新汇科测试人员、业务功能测试人员) 对测试的结果进行评测 准备并提交总体测试报告4.2 时间表在测试时,将按照测试任务定
9、义来进行测试。每个测试任务都有唯一的编号,并对应一个或多个测试用例。具体一个测试任务由那几个测试用例组成,请参看测试用例。测试时间表如下,详细的测试任务分配表由各业务功能测试小组制订。序号任务名称工期(工作日)开始时间完成时间1用户资料准备及整理22测试环境搭建13初始化参数及数据准备24制订小组测试任务分配表15编写(完善)测试用例和准备测试数据56领导对优化版进行总结0.56测试培训18执行测试和回归测试139回归测试与测试总结34.3 安排模块测试安排序号系统名称模块名称工期时间(工作日)1门户系统容编审42栏目管理与授权模块23增加栏目14删除栏目0.55复制栏目0.56移动栏目27排
10、序栏目28访问权限29委托管理110热点词汇管理与自动维护模块111热点词汇定义212热点词汇查找213热点词汇自动214容编辑工具与容管理模块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基于模
11、板生成静态页面138系统管理139工作流程管理模块440用户、角色及权限管理模块141新增角色342删除角色143更新角色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工作动态
12、170图片新闻171重要新闻272网上信访大厅多媒体设计2.573网上信访大厅接口开发374网上投诉平台系统信访人管理子系统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与专网生成的查询码做是
13、否相同的校验496申请复查登记模块197输入查询码校验有效性198选择信访类别399录入复查事项理由2100申请复核登记模块0.5101输入查询码校验有效性2102列出复查结果1103录入复核项及理由2104办理事项网上查询子系统2105投诉请求办理情况查询模块0.5106验证查询码2107短消息提示2108多个投诉请求查询1109申请复查办理情况查询模块2110验证查询码4111短消息提示2112多个申请复查查询3113申请复核办理情况查询模块1114验证查询码1115短消息提示2116多个申请复核查询1117信访人满意度评价系统2118满意度评价1119旧业务数据迁移数据整理2120建立数
14、据字典2121表字段映射1122代码映射2123数据质量分析0.5124数据规性检查3125数据合法性检查2126数据完整一致性检查1127数据质量分析过程2128数据差异分析2.5129数据调整与迁移2130数据迁移整体测试0.5131转换处理流程可行性的测试1132转换工具或转换程序的测试1133单位数据量各个子系统、各个转换步骤,转换所需时间的测试2134校验程序的测试1135应急措施的测试1136数据迁移围2137数据交换系统1138数据采集2139数据交换2140数据接收校验入库2.5141上行交换容2142交换频度2143交换数据的来源3144数据交换系统技术环境2145数据质量管
15、理2146系统性能1.5147扩展实施2148数据抽取2149数据接收1150数据管理2151日志管理2152信访接待大厅自助终端系统用户真伪验证1153用户手机号格式及是否合法验证3154用户手机号是否可用验证2155用户注册信息验证2156用户扫描二代进行注册2157用户扫描二代进行登录0.5158扫描打印一体机扫描纸质材料生成图片2159上传扫描成图片材料2160上传材料验证2161上传材料成功信息反馈4162删除上传材料2163投诉写信容验证1164投诉写信提交2165投诉写信是否允许提交验证2166每日已投诉不允许再次投诉提示2167投诉写信成功提示1168查看已投诉信访件0.516
16、9查看信访件详情2170查看信访件的办理情况3171已处理信访件满意度评价2172已处理信访件满意度评价提交2173扫描二代查询来信来访件2174验证来信来访码的有效性0.5175查看来信来访详情2176查看来信来访满意度评价2177来信来访满意度评价提交2178自助查询一体机公告显示1179自助终端投诉与网上投诉系统用户通用2180自助终端投诉与网上投诉系统数据互通1181自助终端投诉与业务办理系统数据互通2182二代读卡器扫描二代信息1183系统还原工具保护系统安全及不被更改0.5184触摸屏浏览器提供专门的页面效果24.4测试更新安排每日问题反馈:1. 每天下午6点:将用户测试问题按照各
17、系统分类进行整理,并进行问题分析后发给需求组。2. 每天晚上7点半:完成对当天用户提出问题的分析。3. 每天晚上10点前:与开发组各组长制定当天反馈问题的修改计划和每个问题的反馈意见,并发给现场参与测试人员。每日版本升级:1. 每天下午5点前:将修改后的问题部署到集成测试环境。2. 每天下午6点:开发人员和测试人员完成在集成测试环境下的测试。3. 每天下午6点半:将测试通过后的更新包打包并发给实施组。4. 每天晚上9点前:完成信访局测试环境的更新部署。5. 每天晚上10点前:完成信访局测试环境更新部署的测试。5 人员的岗位职责 测试员的工作: 执行测试 执行测试案例 检查测试结果 填写测试结果
18、 填写测试问题单后提交开发人员 重新测试 重新执行测试 重新检查测试结果 重新填写测试结果 更新问题单并通知开发人员重测结果 问题负责人的工作: 确定问题的围 统筹问题的解决及修改并进行必须的测试及负责问题跟踪汇报 更新问题单 把问题单及所有测试记录送回测试人员 登记问题(记录收到问题的日期及时间,并分派问题编号,置问题状态为“OPEN”) 评估问题的严重性(非常严重、严重、一般,轻微) 分派问题到问题负责人 收到从问题负责人送回的问题单 记录收到问题单回应的日期时间 判定问题是否得到解决 如果问题得到解决,置问题状态为 “PENDING RE-TEST”, 并把所有测试记录送交测试员进行重测
19、 如果问题没有得到解决而需要重新分派问题到别的负责人,更新问题记录中负责人的、转发日期时间,并把问题单及所有测试记录转交新的负责人 收到从测试员在重测后送回的问题单 记录有关重测的日期时间及结果 如果重新测试成功,则置问题状态为 “CLOSED”,把问题单及所有测试记录存档 如果重新测试失败,置问题状态为 “OPEN”,把问题单及所有测试记录送交最后的问题负责人 日常的工作 准备有关问题的报告问题总表问题延误解决分析表(在预定时间没有得到解决的问题) 跟踪有关问题单,保证得到问题负责人的高度重视 保存所有问题及测试记录,以备审查之用6 缺陷管理6.1 缺陷管理流程本项目的测试将利用问题报告单进
20、行程序缺陷的管理,问题报告单能如实地记录着每个问题的处理过程。下面是缺陷管理的基本流程:1. 登记BUG,将该BUG分配给对应业务开发组组长;2. 开发组组长查看BUG的相应信息,判断是否属于BUG,如果不是BUG,通知测试组组长,组织相关人员进行讨论,经确定不是BUG后,测试组组长关闭该BUG;如果是BUG,开发组组长将该BUG分配给合适的开发人员进行修正,同时通知测试组组长,测试组组长安排人根据BUG的现象和对应的Use Case书写二次测试用例;3. 该BUG分配的开发人员着手进行修正,Bug经过修改和部测试确定没有问题,开发组提交架构组进行新版本的集成,提交信息必须包含:新增加的用例、
21、修改的用例号和对应的BUG ID;4. 开发人员修改BUG后,请在问题报告单上添加说明一栏中注明修改的信息。 5. 架构组统一修改新发布版本中所修订的BUG的状态为Resolved。6. 当BUG状态为Resolved和该BUG的二次测试用例准备完成后,测试组组长安排测试人员进行二次测试。注:如果对Bug描述的现象需要进一步说明,请直接和相关的测试人员或辅导员进行沟通。BUG管理流程如下图所示:6.2 缺陷的严重度和修改的优先级(此问题请见测试报告)省网上信访信息系统测试业务问题报告单问题编号:提问日期:提问人:问题级别:问题修改优先级:问题所在模块:问题描述答复日期:答复人:答复描述填写说明
22、:1. 问题编号规则:模块名_报告日期(YYMMDD)_报告人_流水号,如:LX_070821_四_012. 文件命名规则:问题编号.doc3. 问题级别 缺陷的严重程度级别:级别定义描述示例1致命系统测试无法进行下去,必须重新测试。测试时出现Server死机2严重系统测试仍可继续进行,但存在的问题对系统功能有重大影响,必须重新测试未完成指定的功能:比如无法保存录入的信息等等3一般问题对系统功能造成影响,必须进行修正,但可根据情况决定是否需要重新测试操作界面不友好,错误信息含糊、不明确4轻微问题对系统功能影响不大,必须进行修正,但无需重新测试。界面有错别字等等 修改优先级:优先级对应缺陷严重程度修改期限P1致命在发现该缺陷1天之P2严重在发现该缺陷3天之P3一般、轻微在发现该缺陷2星期之4. 问题描述:请重点、详细地描述问题出现的过程和问题容。7 测试报告总结和分析根据需要可以从问题平台中生成各种测试报告,并对测试报告统计数据进行分析以指导后期工作和资源的分布。
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1