1、1HM 项目计划书项目组长：王菁菁项目组成员：李应琴 张桦 李小兰 张力芳1 概述产品简介为加强中国光大银行零售业务基础性建设、提升客户群体规模，借助近年来房地产市场蓬勃发展的机遇，总行决定开展物业专项维修资金业务，为简化流程、减少手工操作，因此进行相应的技术开发和系统建设。物业专项资金业务系统（以下简称 HM）是针对大修基金进行管理的业务系统，由中国光大银行重庆分行科技部牵头建设，是独立于核心业务的管理系统并采用异步方式与核心系统进行数据同步。1.1 范围本计划是针对开发需求规定的内容拟定的测试计划，包括：1.1.1 业务处理：（1）开户、缴费、支出、退款、调整、销户（2）冲正（3）换卡(4
2、) 结息(5) 理财(6) 短信1.1.2 流程处理、变更处理：（1）业务申请2（2）业务审核（3）业务办理1.1.3：查询统计：（1）分户查询（2）流水查询（3）月收支统计（4）账户统计（5）收支统计（6）专户未缴纳情况统计（7）专户情况统计（8）收支明细统计（9）未缴纳物业明细查询1.2 限制条件本测试计划受限于产品开发人员提交测试的内容和时间的事实。根据开发人员提交模块的实际情况，本计划会做出相应修改。1.3 参考文档 序号 名称 作者 备注1. 会员中心需求设计2. 后台需求设计3. 前台设计需求设计4. 搜索需求设计5. 其他策划设计文档2 约定2.1 测试目标通过测试，达到以下目标
3、： 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。 产品规定的操作和运行稳定。 Bug 数和缺陷率控制在可接收的范围之内。32.2 接受标准本节所述的接收标准是指可测试的标准，这个标准以测试组接收测试为限。单元测试接收标准应该是准确、快速地保证程序基本模块的正确性。其余各阶段接收标准，以经过审核后的上一阶段测试报告为准，每一阶段停止标准以阶段情况而定。2.3 资源和工具2.3.1 资源 测试服务器（稳定的测试服务器） 人员（测试审核人 1 名，测试实施人员 4 名）2.3.2 工具 测试中使用的 Bug 管理工具：由于项目的测试时间短可以用 excel。 自
4、动化测试工具待定。24 送测要求开发人员提交的测试按以下要求进行：步骤 动作 负责人 相关文档或记录 要求1 打包、编译 开发人员 无 确认可测试2 审核并提交测试 Xx 经审核的上一级测试 报告 测试报告 xx 审核并签字3 接收测试 测试人员 经 xx 审核并签字的上一级测试报告4 开始测试 测试人员 Bug 单、小结 测试小结个人编写个人的内容2.5 编号规则与本测试计划相关的编号规则如下： 测试用例中的编号，功能名+界面名( 每个字第一个汉语拼音大写)+编号例如：注册会员第一个用例ZC HY 0001 测试用例文件命命名规则，模块名+测试用例例如：注册会员模块注册会员测试用例3. 测试
5、种类及测试标准3.1 测试种类计划完成以下类型测试4 功能测试：按照需求对系统的各个功能进行测试 业务测试：主要看各个模块之间的联接关系 压力测试：根据实际情况进行性能测试 验收测试：对系统进行全面的检验3.2 测试方法及标准3.2.1 功能测试3.2.1.1 功能系统能按照设计要求实现模块的各个功能，数据应完整、界面美观、操作方便。具体可参照本文档测试重点及顺序部分。3.2.1.2 界面测试a. 文本框、按钮的测试，如输入非法数据、默认值、特殊字符集、使缓冲区溢出的数据、相同的文件名等。b. 命令按钮控件的测试，如单击按钮正常响应操作、对非法的的输入或者操作给出足够的提示说明、对可能造成数据
6、无法恢复的操作给出必要的提示等。c. 单选按钮控件的测试，如一组按钮不能同时选中，只能选择一个、逐一执行每个单选按钮、一组执行同一功能的单选按钮在初始状态下必须有一个被默认选中，不能同时为空等。d. up-down 文本控件文本框的测试，如直接输入数字或用上下箭头控制、用上下箭头控制数字的自动循环、直接输入超出边界值的数据等。e. 组合列表框的测试，如条目内容正确，其详细内容根据需求确定、逐一执行列表框的每个条目功能等。f. 复选框的测试，如多个复选框可以被同时选中、多个复选框可以部分选中、多个复选框可以不被选中、逐一执行每个复选框的不同功能。g. 列表框控件的测试，如条目内容正确、列表框中的
7、内容较多时需要用滚动条、列表中内容允许多选时，要分别检查 shift 选择条目，按 Ctrl 选中条目与用鼠标直接选择条目的情况。h. 滚动条控件的测试，如滚动条的长度要根据显示信息的长度或宽度及时变换、拖动滚动条的时候，要检查屏幕的刷新情况等。i. 各种控件中混合使用时的测试，如控件中的相互使用、热键的使用、密码框的测试需要检查字母大小写情况。3.2.1.3 数据项测试 字母数字数据项要能够正确回显，并输入到系统中 图形模式的数据项（如滑动条）能正常工作 能够识别非法数据5 数据输入消息可理解 数据提示信息正确3.2.1.4 帮助文档测试 文档精确描述了如何使用本系统 例子要精确 术语、菜单
8、描述和系统响应要与实际程序一致 能够很方便地在文档中定位指南 能够很方便地使用文档排除错误 文档的内容和索引精确完整 文档的设计（布局、缩进和图形）便于信息的理解 显示给用户的错误信息有更详细的文档解释3.2.2 业务测试功能测试完成后进行业务测试，业务测试关注的要点是业务流程，及数据流从软件中的一个模块流到另一个模块的过程中的正确性。3.2.3 压力测试3.2.3.1 压力测试说明本次压力测试根据实际情况包含性能测试，重点模拟客户进行多用户测试。压力测试有一条8：2原则。及百分之八十的业务量在百分之二十的时间内输入。例如:正常每天有100条新数据，测试时在两小时内输入80条数据。我们无法知道
9、用户的业务量，所以只有利用公司现有资源进行大量的数据量的测试。3.2.3.2 压力测试工具待定3.2.4 验收测试3.2.4.1 验收测试说明软件产品测试部对经过内部单元测试、集成测试和系统测试后的软件所进行的测试，测试用例采用业务流程测试用例。4. 测试重点及顺序4.1 预测风险6本次测试过程中，可能出现的风险如下： bug 的修复情况 模块功能的实现情况 系统整体功能的实现情况 代码的编写质量 人员经验以及对软件的熟悉度 开发人员、测试人员关于项目约定的执行情况 人员调整导致研发周期延迟 新增需求导致某些测试计划无法执行4.2 测试重点4.2.1 功能测试这里仅为测试重点的描述，具体测试方
10、法以及内容请参见测试用例。4.2.1.1 业务处理（李小兰 张力芳）（1）开户、缴费、支出、退款、调整、销户 办理方式选择单笔办理或批量办理 准备业务信息，选择录入信息或上传文件 验证业务合法 生成上传核心的命令文件 上传业务命令文件 生成业务回单 完成业务处理（2）冲正 在核心系统执行之前进行 是单个业务或多个业务 功能对象选择的正确性（3）换卡 确认卡升级或密码忘记或丢失 确认卡为本人持有 确认信息正确 换卡成功7(4) 结息 确认卡中的余额信息 银行给顾客的利息信息 结息信息(5) 理财 当前卡中的金额 当前卡中的金额收支情况(6) 短信 已成功为你办理！4.2.1.2 流程处理和变更处
11、理（李应琴 张桦）a.业委会开发商提出业务申请（开户、续缴、支出、调整、退款、销户、理财、短信） 。b.房管局审核提交的业务申请。c.柜员办理通过审核的业务申请。e.转入柜员业务处理流程完成业务处理。4.2.1.2.1 功能测试（1）业务申请 验证录入信息的正确性 申请的信息通过房管局的审核 柜员办理通过审核的业务申请 转入柜员业务处理流程完成业务处理（2）业务审核 业委会开发商提交的业务申请通过房管局的审核（3）业务办理 办理成功用哪种方式反馈给用户4.2.1.2.2 业务测试：（1）业务申请 用户申请业务，审核通过与不通过两个流程8 申请通过审核后才能办理业务、完成此业务（2）业务审核 业
12、务通过审核就能办理此业务（3）业务办理 与用户申请有关联 反馈给客户，与后台有关联4.2.1.3 查询统计（王菁菁）4.2.1.3.1 分户查询 户主姓名查询成功 户主身份证号码查询成功 户主的住房门牌号查询成功4.2.1.3.2 流水查询 流水查询户主姓名成功 流水查询身份证号码成功显示数据 流水查询门牌号成功显示数据 流水查询收支情况成功显示数据 流水查询账户信息查询成功 流水查询专户情况统计查询成功 流水查询未缴纳物业统计情况查询成功4.2.1.3.3 月收支统计 月收支的数据正确统计 月收支的统计是当月的数据统计 月收支统计是账户本人的月收支统计4.2.1.3.4 账户统计 账户统计的
13、数据是正确的统计 账户统计的是本人的账户 账户统计的是单个账户统计或多个账户统计 账户统计的账户名正确 账户统计的账户号码正确 账户统计的账户数据量正确94.2.1.3.5 收支统计 收支的数据正确统计 收支统计的用户数量统计成功4.2.1.3.6 专户未缴纳情况统计 专户未缴纳的姓名统计 专户未缴纳的身份证号码统计 专户未缴纳的费用统计 专户未缴纳的数量统计4.2.1.3.7 专户情况统计 专户的姓名统计 专户的身份证号码统计 专户支出的费用统计 专户的人数统计 专户的收支情况统计成功 专户已缴纳情况统计 专户未缴纳情况统计4.2.1.3.8 收支明细统计 收支统计的数据正确 统计的每月收支
14、都统计成功 收支统计是账户本人的收支明细统计4.2.1.3.9 未缴纳物业统计查询 未缴纳物业查询的信息显示 未缴纳物业查询的信息出现数据错误 未缴纳物业查询的信息是要查询的信息 未缴纳物业查询的信息量 未缴纳物业账户的姓名统计能查询成功 未缴纳物业账户的身份证号统计能查询成功10 未缴纳物业的物业类型统计查询成功5. 测试任务和进度测试阶段 测试任务 工作量估计 人员分配 起止时间测试环境的搭建及测试案例的编写7 天/人 张力芳、李小兰待定业务办理、业务流程处理测试15 天/人 李应琴、张桦待定第一阶段单元测试单元测试 bug 审核 2 天/人 王菁菁 待定第二阶段集成测试业务办理、业务流程
15、处理测试12 天/人 李应琴、张桦待定第三阶段系统测试1. 业务流程测试2. 前台与后台的关联性6 天/人 李小兰、张力芳待定第四阶段性能测试性能测试 2 天/人 王菁菁 待定第五阶段验收测试1. 帮助测试2. 用户手册测试2 天/人 王菁菁 待定第六阶段审核 bug审核单元测试以外的 bug 3 天/人 李应琴、张桦待定测试总结 测试总结和分析、问题反馈1 天/人 测试人员全部待定6. 测试策略本项目最终交付期为 2012 年 4 月 18 日，其中 2012 年某月某日需要交付挂号、收费、库存管理等优先级高的功能，整个项目的递交计划见下：递交版本 递交功能 递交时间V1 系统设置 2010
16、.6.222010.6.28V2 病人档案，挂号，预约 2010.7.12010.7.9V3 收费，预交款，发票 2010.7.132010.7.20V4 就诊登记，回访，扎账 2010.7.222010.7.30V5 物品管理 2010.8.32010.8.20V6 数据同步 2010.7.192010.8.20V7 病历，外加工 2010.8.242010.9.10V8 分析报表 2010.9.132010.9.2011鉴于以上情况, 因此对整个测试作如下计划:测试目标: 保证在交付日期前客户可以得到较为稳定的系统, 增加客户的试用满意度; 在最终交付日期时应得到满足需求规格书的系统, 达
17、到客户的预期目标.总体策略: 主要是进行手工测试, 若有条件, 可利用晚上的时间进行一部分自动化测试; 其中将优先对先递交的,高优先级的功能进行用例设计和测试; 在存在有未测试过的功能时,应优先测试新功能, 同时兼顾旧功能; 需要保证每个功能点测试至少三个版本以上; 在功能较稳定的情况下可以利用测试工具(商用的如LoadRunner 或者自己开发)作性能, 负载方面的测试；在每次递交版本开始测试时，应先进行 30 分钟的随机测试，保证本次递交的主要功能是基本可用的，避免出现在本轮测试末期才发现版本递交失败的现象。环境要求: 在前期的测试中测试人员可以自己部署测试服务器进行测试; 在 V8 完成
18、后至最终交付日期前应进行系统测试, 此时测试方应该部署统一的测试服务器进行测试。另外，在 4.18 日交付高优先级功能前应至少做一次小范围的系统测试。版本要求：测试方测试的版本文件应该通过测试接口人向开发方接口人获取；其他任何人员不能通过任何其他方式获取版本文件。人员要求：各测试人员应该准时完成测试任务，提交测试报告，由测试方负责人合并，整理测试报告，并向相关项目人员报告；测试人员在发现缺陷时应及时报告，在不确定是缺陷时应及时和相关开发人员沟通，避免浪费时间，拖延项目工期；在某一版本测试完成到下一版本之间的空闲期，需要修订，整理相关测试用例。风 险：项目开发过程中可能存在如下风险，将会影响项目工期及其产品质量：1. 交付日期提前2. 开发过程中出现需求变更3. 测试发现严重的 bug，导致开发人员未解决该问题花费太多时间4. 工作量估计不足，导致工期跟不上计划5. 其他风险
