网上购物测试计划文档格式.doc
《网上购物测试计划文档格式.doc》由会员分享，可在线阅读，更多相关《网上购物测试计划文档格式.doc（16页珍藏版）》请在冰豆网上搜索。
3.2.1需求变更：
9
3.2.2进度风险：
3.2.3质量风险 10
四、测试策略 10
4.1测试完成标准 10
4.2测试类型 10
4.2.1功能测试 10
4.2.2、性能测试 11
4.2.3用户界面测试 11
4.2.4、安全性测试 12
4.2.5兼容性测试 12
4.2.6回归测试 13
4.3风险分析 13
4.3.1测试人员对系统熟悉程度的风险：
13
4.3.2系统资料方面的风险：
14
4.3.3时间方面的风险：
五、测试资源 14
5.1人员安排 14
5.2系统资源 14
5.3培训需求 15
六、测试进度和里程碑 15
6.2、里程碑技术 15
七、可交付工具 16
一、概述
1.1目的
测试网上购物系统中的各个功能模块是否满足用户需求，并测试是否存在bug。
预期达到能够使系统进行快速的改进和系统的提高。
为了在软件投入生产性运行之前，尽可能多地发现软件的错误，从而提高软件运行的稳定性和提高用户体验。
1.2背景
a.项目测试的背景：
网上购物系统是一个营业单位不可缺少的部分，他的内容对于购物者和管理者来说都至关重要。
所以网上购物系统应该能够为用户提供充足的信息和快捷的购买手段。
随着商品经济的发展及人们消费水平的提高，还有信息时代的飞跃，越来越多的人爱上了网购，从而催生了网上购物系统的诞生。
它为人们购物带来了方便快捷，节约了没时间出去而省下了空间。
b.该开发项目的历史，列出用户和执行此项目测试的机构或人群，该项目目前后经历三个阶段，前期设计阶段，然后是开发阶段，最后是软件的测试阶段。
项目的用户针对的是网上购物的广大群众和管理员，系统的功能测试主要由专业的软件测试人员进行测试。
1.3范围
网上购物系统测试采用的是黑盒测试的方式对系统进行测试，主要测试软件的功能是否满足用户的需求，性能是否优越以及系统所存在的问题。
对系统的各个模块进行详细的测试，并记录测试的结果，对测试的结果进行细致的分析处理。
测试时对系统的各个功能模块进行拆分测试，并以每一个模块都要测试到。
对所有可能的结果尽最大可能都测试到，以及测试过程中存在的问题进行分析，然后提交测试的记录并督促开发人员进行修复，最后，对软件存在的问题以及性能的测试进行全面分析，给予记录并解决。
在测试的过程中需要提出各个问题的假设，以及根据需求报告文档中存在的项目给你模块和用户的需求来改善系统。
列出可能会影响测试设计、开发或实施的所有风险、意外事件或所有约束。
测试计划和设计：
根据需求规格说明书和最终的系统设计，制定测试计划、测试方案，包括收集测试方法、测试用例、可能用到的测试工具等；
单元测试：
对各个模块的源代码进行测试，保证各模块基本功能能够正确的实现；
集成测试：
将各个模块进行组合测试，保证所有的功能都能够正确的实现；
系统测试：
根据《需求规格说明书》对软件进行功能测试，对重点的模块进行性能测试，并结合可能的用户测试；
验收测试：
根据用户手册对功能进行检查，复查报告库中的所有Bug，对Release版本进行安装测试。
1.4参考文档
表1列出的是制定测试计划所用的文档：
文档
作者或来源
备注
程序测试计划
网上购物系统
二、测试需求
功能性需求
功能模块
需求标识
测试需求/测试要点
用
户
注
册
用户名
填写事例：
fushaoxiong
fushao1234
123456789
用户名的范围：
1、字母或数字
2、字母+数字
3、用户名不能为空
4、长度：
[1,12]
密码
密码范围：
1、不能为空
2、两次输入要一致
3、字母+数字，字母或数字
[1,20]
邮箱
Fushao1234@
邮箱范围：
2、必须要+@
3、长度：
[1,16]
电
话
12345678900
范围：
1、不能为空
2、必须是11位的数字
非功能性需求
测试项目
功
能
性
互操作性
1、系统与外部设备接口、其他系统接口之间的协调、能够协调正常工作
2、系统从接口正确接受和发送数据
安全保密性
1、对不同的用户有不同的权限限制
所有的密码不明码显示、存储与传输
2、有密码设置策略，包括有效期、最小长度、复杂度、非空设置、大小写敏感度
依从性
遵循系统各功能的标准、约定、风格指南或法规
三、测试风险
软件测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足用户的需求。
本次测试所面临的风险（如人力资源风险、测试技术风险、测试资源风险、质量保证风险等）及相应的建议解决办法。
风险如下：
3.1人力资源风险
人员无法到位
规避措施：
a.在产品的预算中体现这部分需求
b.定期催促人力资源部门进行资源协调
c.从可能空闲的产品部门中物色人员
应急计划：
a.推迟进度计划b.进行招聘c.考虑外包
人员技能不符合要求
a.在人力预算中给出人员技能要求
b.对提供的人员进行技能面试
c.从其他产品部门协调有能力的人员
应急计划：
a.提高培训的强度b.加强培训效果监控c.对工作输出加强检视
3.1.1质量保证风险
需求、设计变更频繁导致测试依据失效
a.充分了解用户需求，确保主要需求不变更
b.开展有效的需求评审，及时与客户确认评审结果
先实现主要的需求，和客户确认无误后，再进一部完善系统，避免再次反覆
补丁频繁发布影响测试工作的执行
a.提高测试质量，避免功能性缺陷而导致的补丁
b.制定补丁发放计划，合理规划新增功能性补丁的发放工作
应急计划：
测试人员多和前端客户、维护人员沟通，针对补丁的必要性划分优先级，按序发布补丁
Bug的生命周期过长
a.及时分配修复任务，并检查监督
b.对于非问题、拒绝的等缺陷，请相关责任人验证后，尽快关闭
c.对于暂缓处理的缺陷，测试人员要记录并跟踪
对缺陷优先级进行排序，先修复优先级高的缺陷。
3.2风险管理
需求变更是软件项目经常发生的事情。
一个看似很有“钱途”的软件项目，往往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损（实际上项目建设方也面临巨大的风险）。
预防这种风险的办法是项目建设之初就和用户书面约定好需求变更控制流程、记录并归档用户的需求变更申请。
有些项目对进度要求非常苛刻（进度要求不高的项目，我们同样要考虑该风险），项目进度的延迟意味着违约或市场机会的错失。
预防这种风险的办法一般是分阶段交付产品、增加项目监控的频度和力度、多运用可行的办法保证工作质量避免返工。
3.2.3质量风险
有些项目，用户对软件质量有很高的要求，如果项目组成员同类型项目的开发经验不足，则需要密切关注项目的质量风险。
预防这种风险的办法一般是经常和用户交流工作成果、采用符合要求的开发流程、认真组织对产出物的检查和评审、计划和组织严格的独立测试等。
四、测试策略
4.1测试完成标准
最终通过系统测试，系统无业务逻辑错误和二级的bug。
经确定的所有缺陷都已得到了商定的解决结果，所设计的测试用例已全部重新执行，已知的所有缺陷都已按照商定的方法进行了处理，而且没有发现新的缺陷。
4.2测试类型
4.2.1功能测试
测试范围
验证数据精确度、数据类型、业务功能等相关方面的正确性
测试目标
核实所有功能均已正常实现。
1、业务流程检验：
各个业务流程符合常规逻辑，用户使用时不会产生疑问。
2、数据精确：
各数据类型的输入时统计精确。
技术
采用黑盒测试，使用边界值测试，等价类划分，数据驱动的测试方法
工具与方法
手工测试
开始标准
测试用例设计完毕并且通过同行评审且项目移交系统测试
完成标准
95%测试用例通过并且最高级缺陷全部解决
测试重点与优先级
需考虑的特殊事项
4.2.2、性能测试
大流量的数据与多用户操作时性能方面的测试
核实系统在大流量的数据与多用户操作时软件性能的稳定性，不在造成系统崩溃或相关的异常现象
自动化测试
VisualStudio2008
自动化测试脚本设计并评审通过且项目组移交系统测试
系统满足用户需求中所要求的性能要求
4.2.3用户界面测试
1、导航、链接、Cookie、页面结构的一致性等2、友好性，可操作性
核实各个窗口风格都与基准版本保持一致，或符合课接受标准，能够保证用户界面的友好性，易操作性，而且符合用户操作习惯。
WEB测试通用方法
项目移交系统测试
UI符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯
4.2.4、安全性测试
1、密码：
登录，超级管理员、用户或会员等2、权限3、非法攻击4、登录超市限制等
1、应用程序级别的安全性：
核实用户只能操作其拥有权限能操作的功能
2、系统级别的安全性：
核实只有具备系统访问权限的用户才能访问系统
代码包或者非法攻击工具
执行各种非法操作无安全漏洞且系统使用正常
4.2.5兼容性测试
1、使用不同版本的不同浏览器、分辨率、操作系统分别进行测试。
2、不同操作系统、浏览器、分辨率和各种运行软件等各种条件组合测试
核实系统在不同的软件和硬件配置中运行稳定
黑盒测试
在各种不同版本不同类项浏览器、操作系统或其组合下均能正常实现功能
4.2.6回归测试
所有功能、性能，用户界面，安全性等测试类型
核实执行所有测试类型后功能、性能等均达到用户所要求的标准
手工测试和自动化测试
每当被测试软件或其环境
升级会员 