软件测试项目计划书

HM项目计划书

项目组长：王菁菁

项目组成员：李应琴 张桦 李小兰 张力芳

1概述

产品简介

为加强中国光大银行零售业务基础性建设、提升客户群体规模，借助近年来房地产市场蓬勃发展的机遇，总行决定开展物业专项维修资金业务，为简化流程、减少手工操作，因此进行相应的技术开发和系统建设。

物业专项资金业务系统（以下简称HM）是针对大修基金进行管理的业务系统，由中国光大银行重庆分行科技部牵头建设，是独立于核心业务的管理系统并采用异步方式与核心系统进行数据同步。

1.1 范围

本计划是针对《开发需求》规定的内容拟定的测试计划，包括：

1.1.1 业务处理：

（1）开户、缴费、支出、退款、调整、销户 （2）冲正 （3）换卡 (4) 结息 (5) 理财 (6) 短信

1.1.2流程处理、变更处理：

（1）业务申请

1

（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 测试目标

通过测试，达到以下目标：

? 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流

程是否正确。

? 产品规定的操作和运行稳定。

? Bug数和缺陷率控制在可接收的范围之内。

2

2.2 接受标准

本节所述的接收标准是指可测试的标准，这个标准以测试组接收测试为限。单元测试接收标准应该是准确、快速地保证程序基本模块的正确性。其余各阶段接收标准，以经过审核后的上一阶段测试报告为准，每一阶段停止标准以阶段情况而定。

2.3 资源和工具 2.3.1 资源

? 测试服务器（稳定的测试服务器）

? 人员（测试审核人1名，测试实施人员4 名）

2.3.2 工具

? ?

测试中使用的Bug管理工具：由于项目的测试时间短可以用excel。 自动化测试工具待定。

2..4 送测要求

开发人员提交的测试按以下要求进行： 步骤 1 2 3 4 动作 打包、编译 审核并提交测试 接收测试 开始测试 负责人 开发人员 Xx 测试人员 测试人员 相关文档或记录 无 经审核的上一级测试报告 经xx审核并签字的上一级测试报告 Bug单、小结 确认可测试 测试报告xx审核并签字 测试小结个人编写个人的内容 要求

2.5 编号规则

与本测试计划相关的编号规则如下：

? 测试用例中的编号，功能名+界面名(每个字第一个汉语拼音大写)+编号

例如：注册会员第一个用例 ZC HY 0001

? 测试用例文件命命名规则，模块名+测试用例

例如：注册会员模块 注册会员测试用例

3. 测试种类及测试标准

3

3.1 测试种类

计划完成以下类型测试

? 功能测试：按照需求对系统的各个功能进行测试 ? 业务测试：主要看各个模块之间的联接关系 ? 压力测试：根据实际情况进行性能测试 ? 验收测试：对系统进行全面的检验

3.2 测试方法及标准

3.2.1 功能测试 3.2.1.1 功能

系统能按照设计要求实现模块的各个功能，数据应完整、界面美观、操作方便。 具体可参照本文档测试重点及顺序部分。

3.2.1.2 界面测试

a. 文本框、按钮的测试，如输入非法数据、默认值、特殊字符集、使缓冲区溢出

的数据、相同的文件名等。

b. 命令按钮控件的测试，如单击按钮正常响应操作、对非法的的输入或者操作给

出足够的提示说明、对可能造成数据无法恢复的操作给出必要的提示等。 c. 单选按钮控件的测试，如一组按钮不能同时选中，只能选择一个、逐一执行每

个单选按钮、一组执行同一功能的单选按钮在初始状态下必须有一个被默认选中，不能同时为空等。

d. up-down文本控件文本框的测试，如直接输入数字或用上下箭头控制、用上下

箭头控制数字的自动循环、直接输入超出边界值的数据等。

e. 组合列表框的测试，如条目内容正确，其详细内容根据需求确定、逐一执行列

表框的每个条目功能等。

f. 复选框的测试，如多个复选框可以被同时选中、多个复选框可以部分选中、多

个复选框可以不被选中、逐一执行每个复选框的不同功能。

g. 列表框控件的测试，如条目内容正确、列表框中的内容较多时需要用滚动条、

列表中内容允许多选时，要分别检查shift选择条目，按Ctrl选中条目与用鼠标直接选择条目的情况。

h. 滚动条控件的测试，如滚动条的长度要根据显示信息的长度或宽度及时变换、

拖动滚动条的时候，要检查屏幕的刷新情况等。

i. 各种控件中混合使用时的测试，如控件中的相互使用、热键的使用、密码框的

测试需要检查字母大小写情况。

3.2.1.3 数据项测试

? 字母数字数据项要能够正确回显，并输入到系统中

4

? 图形模式的数据项（如滑动条）能正常工作 ? 能够识别非法数据 ? 数据输入消息可理解 ? 数据提示信息正确

3.2.1.4 帮助文档测试

? 文档精确描述了如何使用本系统 ? 例子要精确

? 术语、菜单描述和系统响应要与实际程序一致 ? 能够很方便地在文档中定位指南 ? 能够很方便地使用文档排除错误 ? 文档的内容和索引精确完整

? 文档的设计（布局、缩进和图形）便于信息的理解 ? 显示给用户的错误信息有更详细的文档解释

3.2.2 业务测试

功能测试完成后进行业务测试，业务测试关注的要点是业务流程，及数据流从软件中的一个模块流到另一个模块的过程中的正确性。

3.2.3 压力测试 3.2.3.1 压力测试说明

本次压力测试根据实际情况包含性能测试，重点模拟客户进行多用户测试。压力测试有一条8：2原则。及百分之八十的业务量在百分之二十的时间内输入。例如:正常每天有100条新数据，测试时在两小时内输入80条数据。我们无法知道用户的业务量，所以只有利用公司现有资源进行大量的数据量的测试。

3.2.3.2 压力测试工具

待定

3.2.4 验收测试 3.2.4.1 验收测试说明

软件产品测试部对经过内部单元测试、集成测试和系统测试后的软件所进行的测试，测试用例采用业务流程测试用例。

5

4. 测试重点及顺序 4.1

预测风险

本次测试过程中，可能出现的风险如下： ? bug的修复情况 ? 模块功能的实现情况 ? 系统整体功能的实现情况 ? 代码的编写质量

? 人员经验以及对软件的熟悉度

? 开发人员、测试人员关于项目约定的执行情况 ? 人员调整导致研发周期延迟 ? 新增需求导致某些测试计划无法执行

4.2 测试重点

4.2.1 功能测试

这里仅为测试重点的描述，具体测试方法以及内容请参见测试用例。 4.2.1.1 业务处理（李小兰 张力芳）

（1）开户、缴费、支出、退款、调整、销户 ? 办理方式选择单笔办理或批量办理 ? 准备业务信息，选择录入信息或上传文件 ? 验证业务合法

? 生成上传核心的命令文件 ? 上传业务命令文件 ? 生成业务回单 ? 完成业务处理

（2）冲正

? 在核心系统执行之前进行 ? 是单个业务或多个业务 ? 功能对象选择的正确性

（3）换卡

6

? ? ? ?

确认卡升级或密码忘记或丢失 确认卡为本人持有 确认信息正确 换卡成功

(4) 结息

? 确认卡中的余额信息 ? 银行给顾客的利息信息 ? 结息信息

(5) 理财

? 当前卡中的金额

? 当前卡中的金额收支情况

(6) 短信

? 已成功为你办理！

4.2.1.2 流程处理和变更处理（李应琴 张桦）

a.业委会／开发商提出业务申请（开户、续缴、支出、调整、退款、销户、理财、短信）。 b.房管局审核提交的业务申请。 c.柜员办理通过审核的业务申请。 e.转入柜员业务处理流程完成业务处理。

4.2.1.2.1 功能测试

（1）业务申请

?

? ? ?

验证录入信息的正确性

申请的信息通过房管局的审核 柜员办理通过审核的业务申请

转入柜员业务处理流程完成业务处理

（2）业务审核

? 业委会／开发商提交的业务申请通过房管局的审核

（3）业务办理

? 办理成功用哪种方式反馈给用户

4.2.1.2.2 业务测试：

7

本文来源：https://www.bwwdw.com/article/0oso.html