eshop测试计划实例.docx
《eshop测试计划实例.docx》由会员分享，可在线阅读，更多相关《eshop测试计划实例.docx（9页珍藏版）》请在冰点文库上搜索。
EShop网上购物系统测试计划
1产品简介
Eshop致力于为企业提供网上销售解决方案，包含Eshop企业网店软件和顾问式服务体系。
Eshop从企业开展电子商务的核心诉求出发，通过软件加服务的模式，帮助企业搭建平台、掌握运营。
Eshop是为具有法人资质的企业或个人在互联网上独立注册网站、开设网上虚拟商店，出售实物或提供服务给消费者的电子商务平台。
面向品牌商户或代理商提供多产品类目、可扩展的品牌库管理、订单管理技术解决方案。
品牌商家可根据企业特点，定制符合企业风格的网上商店模板，快速构建可信任的、安全的网上销售平台，实现线下渠道与在线电子商务销售的完美结合。
2测试范围
本测试计划包括：
Ø前台会员用户登录
Ø首页商品展示
Ø会员用户资料修改
Ø会员用户浏览商品
Ø多种商品分类形式
Ø商品排行榜功能
Ø便捷的商品检索功能
Ø会员中心功能
Ø购物车功能
Ø在线订单生成
Ø商品评论功能
Ø顾客留言功能
Ø相关商品
Ø账号和密码找回功能
Ø订单管理功能
3、测试方法
黑盒测试方法：
等价类方法、边界值方法、决策表方法、因果图方法、错误推测法
白盒测试方法：
逻辑覆盖法、基本路径测试法、循环测试方法
4、测试阶段
主要分为4个阶段：
测试计划
测试准备测试执行测试总结
5、测试交付品
本次测试完成后的提交物：
Ø测试计划
Ø测试用例
Ø测试Bug单
Ø测试小结
Ø测试分析报告
6、测试任务
计划完成以下测试：
l功能测试
l界面测试
l性能测试
l链接测试
模块名称
子模块
功能点
测试类型
前台登录
页面切换
功能测试、链接测试
登录信息的输入内容验证
功能测试、界面测试
必填项校验
功能测试
回车验证
功能测试
检测每个按钮的有效性
功能测试、界面测试
登录次数校验
安全性测试
Tab验证
功能测试
登录半个小时后查看过期
验证，自动保存密码
功能测试、安全测试
l安全性测试测试项：
模块名称
子模块
功能点
测试类型
注册
页面切换
功能测试、链接测试
会员级别校验
功能测试
必填项校验
功能测试
系统对域最大字符长度校
验
功能测试
系统对超出域最大字符长
度校验
功能测试
特殊字符校验
功能测试
重名校验
功能测试
密码校验
功能测试
电话号码验证
功能测试
邮箱地址验证
功能测试
邮政编码验证
功能测试
Tab验证
功能测试
回车验证
功能测试
按钮的有效性
功能测试、链接测试
添加注册信息半小时后再
提交对其进行过期验证
安全测试
购买商品
添加商品到购物车是否成
功
功能测试、界面测试
不输入购买数量
功能测试
在购买数量中输入字母
功能测试
购物车管理：
添加购物车
查看购物车，能否查看添
购买的商品
功能测试
翻页
功能测试、链接测试
生成购物单
功能测试、界面测试
清空购物车
功能测试
删除购物车中商品
功能测试
查看会员价
功能测试
继续购物按钮页面切换
功能测试、链接测试
进入下一步按钮页面切换
功能测试、链接测试
购物车管理：
生成订单
查看订单是否正确
翻页
模块名称
子模块
功能点
测试类型
必填项验证
Tab验证
电话号码格式验证
邮编验证
返回上一步页面切换
提交订单按钮切换
购物车管理：
订单提交
查看订单详情
订单管理
查看订单详情是否正确
订单详情返回按钮有效性
删除订单
特价区
图片链接验证
界面测试、功能测试
查看详情按钮验证
功能测试
购买按钮验证
界面测试、功能测试
会员价验证
功能测试
更多按钮验证
特价商品页面：
特价商品
浏览信息是否正确
特价商品页面：
上一页按
钮有效性
链接测试
特价商品页面：
下一页按
钮有效性
链接测试
特价商品页面：
首页按钮
有效性
链接测试
特价商品页面：
末页按钮
有效性
链接测试
特价商品页面：
去第几页
按钮有效性
链接测试
新品上市
同特价区一样，只是进入
页面的URL不同
顾客留言
查看留言是否正确
界面测试、功能测试
必填项验证
功能测试
模块名称
子模块
功能点
测试类型
输入字符长度等于最大字
符长度
界面测试、功能测试
输入字符长度大于最大字
符长度
界面测试、功能测试
提交留言按钮有效性
界面测试、功能测试
上一页按钮有效性
下一页按钮有效性
首页按钮有效性
末页按钮有效性
去第几页按钮有效性
修改注册资料
页面切换
功能测试、界面测试
会员级别校验
功能测试、界面测试
必填项校验
功能测试、界面测试
系统对域最大字符长度校
验
功能测试
系统对超出域最大字符长
度校验
功能测试
特殊字符校验
重名校验
密码校验
功能测试
电话号码验证
功能测试
邮箱地址验证
功能测试
邮政编码验证
功能测试
Tab验证
功能测试
回车验证
功能测试
按钮的有效性
功能测试、界面测试
不修改直接保存
安全测试
搜索
不输入查询
功能测试
选择特定查询
功能测试
模糊查询
功能测试
在查询条件中输入特殊字
符
功能测试
7、资源需求
资源：
工具：
Ø测试服务器
稳定的测试服务器，IP地址为:
10.180.2.127
Ø人员
测试审核人一名，测试实施人员2名。
Ø测试中使用的Bug管理工具为经过改进的Bug管理工具QuailtyCenter。
Ø自动化测试工具LoaderRunner。
8、职责
角色
职责对应
测试经理
1.制定测试计划
2.需求，测试用例评审
3.指导测试任务分配，（每天早上跟测试主管沟通）
4.跟踪bug的验证情况。
5.阅览测试主管的日报，周报
6.项目组进度和质量控制，
7. 项目报告整理（测试用例执行结果，主要遗留问题反馈；测试用例结果每周反馈；主要遗留问题每次发布版本之前2小时，同时汇报版本新增加问题，解决问题情况。
）
8.听取客户反馈问题的处理情况，
9.了解项目的进度报告
10.了解性能测试自动化测试的计划，进展，
11.测试流程改进
12.组织召开测试组例会
13.测试组人员招聘
14.测试组人员考核
15.部门之间协调
16.组织版本发布评审会议，准备质量报告
17.最后版本正式发布建议。
18.项目团队建设
19.人员培训，
20.项目总结
21.项目结束之后处理遗留bug。
测试主管
1.测试执行（管理40%：
测试执行60%）
2.需求，测试用例评审
3.测试任务分配
4.控制项目组进度和质量控制，（每天组内讨论，提供项目日报）
5.阅览测试人员周报（周一）
6.项目测试用例执行结果报告（每周一次。
周五）
7.跟踪bug的验证情况。
8. 准备每次版本发布的checklist，并严格按照list去检查工作完成情况。
9.版本正式发布提供测试意见。
10.项目团队建设
11.组间协调
12.测试流程改进
13.组织召开测试小组例会
14.协助测试人员招聘
15.协助测试人员考核
16.组内人员培训，
17.项目总结（管理流程，技术文档）
测试工程师
1.参与需求评审
2.测试用例开发、维护
3.参与测试用例评审
4. 执行测试用例，（至少每周完成一遍自己负责的区域的测试用例，其他根据测试主管的具体要求。
）
5.发现bug，报告bug，验证bug，足够回归测试
6.周一提交工作周报
7.产品，研发，测试三方沟通，积极促进问题解决。
8.发现重大bug，或者是工作进度被阻断及时向测试主管汇报。
9 需要测试主管支持的事项，及时跟主管沟通。
10.项目总结
研发经理
1. 每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：
需求、开发、产品共同确定）。
2、问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。
3、有可能是需求的问题，分配给需求人员。
4、定期对Bug库分析，找出常出错的模块，进行代码审查。
研发工程师
1.审核测试计划、测试报告
2.参与测试Bug讨论。
3.组织对测试人员的培训。
4.提供需求规范说明书；
5.需求变更文档
6.更新组件说明文档
9、人员配置和培训需求
测试经理
同学A
测试主管
同学B
测试工程师
同学C
研发经理
同学D
研发工程师
同学E
10进度
测试阶段
子阶段
计划时间
测试计划
制定测试计划
4h
测试计划评审
2h
测试计划修改
2h
需求管理
需求来源分析
2h
需求评审
2h
测试分析
测试项分析
2h
测试项评审
2h
测试设计
测试用例设计
16h
测试用例实现
2h
测试用例评审
2h
测试执行
测试执行
24h
11风险和不测事件
在测试工作中，主要的风险表现有以下几点：
（1）需求风险。
对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，同步时存在误差。
（2）测试用例风险。
测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求；测试用例没有得到全部执行，有些用例被有意或者无意的遗漏；
（3）缺陷风险。
某些缺陷偶发，难以重现，容易被遗漏；
（4）代码质量风险。
软件代码质量差，导致缺陷较多，容易出现测试的遗漏；
（5）测试环境风险。
有些情况下测试环境与生产环境不能完全一致，导致测试结果存在误差；
（6）测试技术风险。
某些项目存在技术难度，测试能力和水平导致测试进展缓慢，项目延期；
（7）回归测试风险。
回归测试一般不运行全部测试用例，可能存在测试不完全；
（8）沟通协调风险。
测试过程中涉及的角色较多，存在不同人员、角色之间的沟通、协作，难免存在误解、沟通不畅的情况，导致项目延期；
（9）其它不可预计风险。
一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。
以上是测试过程中可能发生的风险，其中有的风险是难以避免的，如缺陷风险等。
有的风险从理论上可以避免，但实际操作过程中出于时间和成本的考虑，也难以完全回避，如回归测试风险等。
对于难以避免的风险，我们的目标是将风险降到最低水平。
12批准
通过测试，达到以下目标：
Ø测试系统是否达到设计的要求，包括：
各个功能点是否以实现，业务操作流
程是否正确。
Ø产品规定的操作和运行稳定。
ØBug数和缺陷率控制在可接收的范围之内。
接收标准
本节所述的接收标准是指可测试的标准，这个标准以测试组接收测试为限。
单元测试接收标准的详细规定参见文档测试接收标准.doc。
其余各阶段接收标准，以经过审核后的上一阶段测试报告为准，每一阶段停止标准的详细规定参见文档软件测试停止标准.doc。
升级会员 