软件测试项目计划书.docx
《软件测试项目计划书.docx》由会员分享，可在线阅读，更多相关《软件测试项目计划书.docx（12页珍藏版）》请在冰豆网上搜索。
软件测试项目计划书
HM项目计划书
项目组长：
王菁菁
项目组成员：
李应琴张桦李小兰张力芳
1概述
产品简介
为加强中国光大银行零售业务基础性建设、提升客户群体规模，借助近年来房地产市场蓬勃发展的机遇,总行决定开展物业专项维修资金业务，为简化流程、减少手工操作，因此进行相应的技术开发和系统建设。
物业专项资金业务系统（以下简称HM）是针对大修基金进行管理的业务系统，由中国光大银行重庆分行科技部牵头建设，是独立于核心业务的管理系统并采用异步方式与核心系统进行数据同步。
1.1范围
本计划是针对《开发需求》规定的内容拟定的测试计划，包括：
1。
1.1业务处理：
（1）开户、缴费、支出、退款、调整、销户
（2）冲正
（3）换卡
（4）结息
（5）理财
（6）短信
1。
1.2流程处理、变更处理：
（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.3资源和工具
2.3.1资源
Ø测试服务器（稳定的测试服务器）
Ø人员（测试审核人1名，测试实施人员4名）
2。
3。
2工具
Ø测试中使用的Bug管理工具：
由于项目的测试时间短可以用excel。
Ø自动化测试工具待定。
2。
.4送测要求
开发人员提交的测试按以下要求进行：
步骤
动作
负责人
相关文档或记录
要求
1
打包、编译
开发人员
无
确认可测试
2
审核并提交测试
Xx
经审核的上一级测试报告
测试报告xx审核并签字
3
接收测试
测试人员
经xx审核并签字的上一级测试报告
4
开始测试
测试人员
Bug单、小结
测试小结个人编写个人的内容
2.5编号规则
与本测试计划相关的编号规则如下：
Ø测试用例中的编号,功能名+界面名（每个字第一个汉语拼音大写）+编号
例如：
注册会员第一个用例
ZCHY0001
Ø测试用例文件命命名规则,模块名+测试用例
例如：
注册会员模块
注册会员测试用例
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数据项测试
Ø字母数字数据项要能够正确回显，并输入到系统中
Ø图形模式的数据项（如滑动条）能正常工作
Ø能够识别非法数据
Ø数据输入消息可理解
Ø数据提示信息正确
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验收测试说明
软件产品测试部对经过内部单元测试、集成测试和系统测试后的软件所进行的测试,测试用例采用业务流程测试用例。
4.测试重点及顺序
4.1预测风险
本次测试过程中，可能出现的风险如下：
Øbug的修复情况
Ø模块功能的实现情况
Ø系统整体功能的实现情况
Ø代码的编写质量
Ø人员经验以及对软件的熟悉度
Ø开发人员、测试人员关于项目约定的执行情况
Ø人员调整导致研发周期延迟
Ø新增需求导致某些测试计划无法执行
4.2测试重点
4.2.1功能测试
这里仅为测试重点的描述,具体测试方法以及内容请参见测试用例。
4。
2。
1.1业务处理（李小兰张力芳）
（1）开户、缴费、支出、退款、调整、销户
Ø办理方式选择单笔办理或批量办理
Ø准备业务信息,选择录入信息或上传文件
Ø验证业务合法
Ø生成上传核心的命令文件
Ø上传业务命令文件
Ø生成业务回单
Ø完成业务处理
（2）冲正
Ø在核心系统执行之前进行
Ø是单个业务或多个业务
Ø功能对象选择的正确性
（3）换卡
Ø确认卡升级或密码忘记或丢失
Ø确认卡为本人持有
Ø确认信息正确
Ø换卡成功
（4）结息
Ø确认卡中的余额信息
Ø银行给顾客的利息信息
Ø结息信息
（5）理财
Ø当前卡中的金额
Ø当前卡中的金额收支情况
（6）短信
Ø已成功为你办理!
4.2。
1。
2流程处理和变更处理（李应琴张桦）
a。
业委会／开发商提出业务申请（开户、续缴、支出、调整、退款、销户、理财、短信）。
b.房管局审核提交的业务申请.
c。
柜员办理通过审核的业务申请.
e。
转入柜员业务处理流程完成业务处理。
4.2。
1。
2.1功能测试
（1）业务申请
Ø验证录入信息的正确性
Ø申请的信息通过房管局的审核
Ø柜员办理通过审核的业务申请
Ø转入柜员业务处理流程完成业务处理
（2）业务审核
Ø业委会／开发商提交的业务申请通过房管局的审核
（3）业务办理
Ø办理成功用哪种方式反馈给用户
4.2。
1。
2。
2业务测试：
（1）业务申请
Ø用户申请业务，审核通过与不通过两个流程
Ø申请通过审核后才能办理业务、完成此业务
（2）业务审核
Ø业务通过审核就能办理此业务
（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账户统计
Ø账户统计的数据是正确的统计
Ø账户统计的是本人的账户
Ø账户统计的是单个账户统计或多个账户统计
Ø账户统计的账户名正确
Ø账户统计的账户号码正确
Ø账户统计的账户数据量正确
4.2.1。
3.5收支统计
Ø收支的数据正确统计
Ø收支统计的用户数量统计成功
4。
2。
1。
3.6专户未缴纳情况统计
Ø专户未缴纳的姓名统计
Ø专户未缴纳的身份证号码统计
Ø专户未缴纳的费用统计
Ø专户未缴纳的数量统计
4.2。
1。
3。
7专户情况统计
Ø专户的姓名统计
Ø专户的身份证号码统计
Ø专户支出的费用统计
Ø专户的人数统计
Ø专户的收支情况统计成功
Ø专户已缴纳情况统计
Ø专户未缴纳情况统计
4.2。
1.3.8收支明细统计
Ø收支统计的数据正确
Ø统计的每月收支都统计成功
Ø收支统计是账户本人的收支明细统计
4。
2.1。
3.9未缴纳物业统计查询
Ø未缴纳物业查询的信息显示
Ø未缴纳物业查询的信息出现数据错误
Ø未缴纳物业查询的信息是要查询的信息
Ø未缴纳物业查询的信息量
Ø未缴纳物业账户的姓名统计能查询成功
Ø未缴纳物业账户的身份证号统计能查询成功
Ø未缴纳物业的物业类型统计查询成功
5.测试任务和进度
测试阶段
测试任务
工作量估计
人员分配
起止时间
第一阶段
单元测试
测试环境的搭建及测试案例的编写
7天/人
张力芳、李小兰
待定
业务办理、业务流程处理测试
15天/人
李应琴、张桦
待定
单元测试bug审核
2天/人
王菁菁
待定
第二阶段
集成测试
业务办理、业务流程处理测试
12天/人
李应琴、张桦
待定
第三阶段
系统测试
1.业务流程测试
2.前台与后台的关联性
6天/人
李小兰、张力芳
待定
第四阶段
性能测试
性能测试
2天/人
王菁菁
待定
第五阶段
验收测试
1.帮助测试
2。
用户手册测试
2天/人
王菁菁
待定
第六阶段
审核bug
审核单元测试以外的bug
3天/人
李应琴、张桦
待定
测试总结
测试总结和分析、问题反馈
1天/人
测试人员全部
待定
6.测试策略
本项目最终交付期为2012年4月18日，其中2012年某月某日需要交付挂号、收费、库存管理等优先级高的功能，整个项目的递交计划见下：
递交版本
递交功能
递交时间
V1
系统设置
2010.6.22—2010.6。
28
V2
病人档案，挂号，预约
2010.7。
1—2010。
7.9
V3
收费，预交款,发票
2010.7.13—2010。
7。
20
V4
就诊登记，回访，扎账
2010.7.22—2010。
7.30
V5
物品管理
2010。
8.3—2010.8.20
V6
数据同步
2010。
7。
19—2010.8.20
V7
病历,外加工
2010。
8。
24—2010。
9.10
V8
分析报表
2010。
9.13-2010。
9.20
鉴于以上情况，因此对整个测试作如下计划:
测试目标：
保证在交付日期前客户可以得到较为稳定的系统,增加客户的试用满意度;在最终交付日期时应得到满足需求规格书的系统,达到客户的预期目标。
总体策略：
主要是进行手工测试,若有条件，可利用晚上的时间进行一部分自动化测试；其中将优先对先递交的，高优先级的功能进行用例设计和测试；在存在有未测试过的功能时,应优先测试新功能，同时兼顾旧功能;需要保证每个功能点测试至少三个版本以上；在功能较稳定的情况下可以利用测试工具（商用的如LoadRunner或者自己开发）作性能,负载方面的测试；在每次递交版本开始测试时，应先进行30分钟的随机测试,保证本次递交的主要功能是基本可用的,避免出现在本轮测试末期才发现版本递交失败的现象。
环境要求:
在前期的测试中测试人员可以自己部署测试服务器进行测试；在V8完成后至最终交付日期前应进行系统测试，此时测试方应该部署统一的测试服务器进行测试。
另外，在4。
18日交付高优先级功能前应至少做一次小范围的系统测试。
版本要求：
测试方测试的版本文件应该通过测试接口人向开发方接口人获取；其他任何人员不能通过任何其他方式获取版本文件。
人员要求：
各测试人员应该准时完成测试任务，提交测试报告,由测试方负责人合并,整理测试报告，并向相关项目人员报告；测试人员在发现缺陷时应及时报告，在不确定是缺陷时应及时和相关开发人员沟通，避免浪费时间，拖延项目工期；在某一版本测试完成到下一版本之间的空闲期，需要修订，整理相关测试用例。
风险：
项目开发过程中可能存在如下风险，将会影响项目工期及其产品质量：
1.交付日期提前
2。
开发过程中出现需求变更
3。
测试发现严重的bug，导致开发人员未解决该问题花费太多时间
4。
工作量估计不足,导致工期跟不上计划
5。
其他风险
升级会员 