网上购物测试计划.docx
《网上购物测试计划.docx》由会员分享，可在线阅读，更多相关《网上购物测试计划.docx（14页珍藏版）》请在冰豆网上搜索。
网上购物测试计划
软件学院（专科）
《软件测试》
上机1提交成果
1.3《天天超市管理系统》测试计划
组号：
04
小组成员：
付少雄、何佩涛、赵东东、魏海峰、王浩浩、刘钊
项目组长：
付少雄
完成日期：
2015年03月20日
一、概述
1.1目的
测试网上购物系统中的各个功能模块是否满足用户需求，并测试是否存在bug。
预期达到能够使系统进行快速的改进和系统的提高。
为了在软件投入生产性运行之前，尽可能多地发现软件的错误，从而提高软件运行的稳定性和提高用户体验。
1.2背景
a.项目测试的背景：
网上购物系统是一个营业单位不可缺少的部分，他的内容对于购物者和管理者来说都至关重要。
所以网上购物系统应该能够为用户提供充足的信息和快捷的购买手段。
随着商品经济的发展及人们消费水平的提高，还有信息时代的飞跃，越来越多的人爱上了网购，从而催生了网上购物系统的诞生。
它为人们购物带来了方便快捷，节约了没时间出去而省下了空间。
b.该开发项目的历史，列出用户和执行此项目测试的机构或人群，该项目目前后经历三个阶段，前期设计阶段，然后是开发阶段，最后是软件的测试阶段。
项目的用户针对的是网上购物的广大群众和管理员，系统的功能测试主要由专业的软件测试人员进行测试。
1.3范围
网上购物系统测试采用的是黑盒测试的方式对系统进行测试，主要测试软件的功能是否满足用户的需求，性能是否优越以及系统所存在的问题。
对系统的各个模块进行详细的测试，并记录测试的结果，对测试的结果进行细致的分析处理。
测试时对系统的各个功能模块进行拆分测试，并以每一个模块都要测试到。
对所有可能的结果尽最大可能都测试到，以及测试过程中存在的问题进行分析，然后提交测试的记录并督促开发人员进行修复，最后，对软件存在的问题以及性能的测试进行全面分析，给予记录并解决。
在测试的过程中需要提出各个问题的假设，以及根据需求报告文档中存在的项目给你模块和用户的需求来改善系统。
列出可能会影响测试设计、开发或实施的所有风险、意外事件或所有约束。
测试计划和设计：
根据需求规格说明书和最终的系统设计，制定测试计划、测试方案，包括收集测试方法、测试用例、可能用到的测试工具等；
单元测试：
对各个模块的源代码进行测试，保证各模块基本功能能够正确的实现；
集成测试：
将各个模块进行组合测试，保证所有的功能都能够正确的实现；
系统测试：
根据《需求规格说明书》对软件进行功能测试，对重点的模块进行性能测试，并结合可能的用户测试；
验收测试：
根据用户手册对功能进行检查，复查报告库中的所有Bug，对Release版本进行安装测试。
1.4参考文档
表1列出的是制定测试计划所用的文档：
文档
作者或来源
备注
程序测试计划
网上购物系统
二、测试需求
功能性需求
功能模块
需求标识
测试需求/测试要点
用
户
注
册
用户名
填写事例：
fushaoxiong
fushao1234
123456789
用户名的范围：
1、字母或数字
2、字母+数字
3、用户名不能为空
4、长度：
[1,12]
密码
填写事例：
fushao1234
密码范围：
1、不能为空
2、两次输入要一致
3、字母+数字，字母或数字
4、长度：
[1,20]
邮箱
填写事例：
Fushao1234@
邮箱范围：
1、不能为空
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.1需求变更：
需求变更是软件项目经常发生的事情。
一个看似很有“钱途”的软件项目，往往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损（实际上项目建设方也面临巨大的风险）。
预防这种风险的办法是项目建设之初就和用户书面约定好需求变更控制流程、记录并归档用户的需求变更申请。
3.2.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回归测试
测试范围
所有功能、性能，用户界面，安全性等测试类型
测试目标
核实执行所有测试类型后功能、性能等均达到用户所要求的标准
技术
黑盒测试
工具与方法
手工测试和自动化测试
开始标准
每当被测试软件或其环境改变时在每个合适的测试阶段上进行回归测试
完成标准
95%测试用例执行通过并通过系统测试
测试重点与优先级
需考虑的特殊事项
4.3风险分析
4.3.1测试人员对系统熟悉程度的风险：
参与本项目的测试人员都是第一次接触该类型系统，在经过短期的系统培训后，仍然有可能没有完全掌握系统的业务细节，这将在后面的测试设计和测试执行工作造成一些测试逃逸现象（即一些要测试的方面没有测到）。
4.3.2系统资料方面的风险：
本项目被测试的系统没有完备的开发文档，测试人员做测试设计时能够参考的只是使用手册和训练手册，以及通过培训和初步使用后对系统的了解，可能导致测试人员在初期无法全面地对系统进行深入的测试。
4.3.3时间方面的风险：
本次项目时间只有一个月，却要完成测试规范的制定、整套测试用例的设计和执行一轮完整的测试，时间进度非常紧张，可能导致测试设计工作不够完善。
五、测试资源
5.1人员安排
人员安排表
角色
所分配的专职角色数量
任务安排或职责
测试经理
测试计划
测试设计员
测试方案与测试用例设计、测试总结
测试员
测试执行
5.2系统资源
系统资源
资源名称/类别
配置及数量
测试数据库服务器
PCServer:
512M内存、40GSCSI硬盘1台
PC台式机
P4,主频1.6G以上及其他电脑配置等4台
系统软件
SQLServer2008WindowsXP
应用软件
VS2008
5.3培训需求
由于参与本次测试的测试人员对考试管理系统都不了解，需要XX公司对这些测试人员进行系统的相关培训。
培训内容包括：
◆系统架构的培训
◆系统数据流程的培训
◆各子系统的功能培训
◆在实际使用过程中哪些部分问题比较多
◆哪些部分是本次的重点测试对象
六、测试进度和里程碑
6.1、测试进度
项目进度
测试工作任务的起止时间为：
测试工作任务
开始时间
结束时间
备注
制定测试计划
<项目的启动时间>
<四周完成>
项目的进程状况
实施测试
<设计测试完成时起>
<十二周完成>
项目的任务完成
评估测试
<实施测试完成后时起>
<两周完成>
项目的任务完成
6.2、里程碑技术
在本项目中，我们将整个测试过程分为几个里程碑，达到一个里程碑后才能转换到下一阶段，以控制整个过程。
我们将整个测试过程分为以下几个里程碑：
里程碑
完成标准
系统培训
1、对于本项目所有需要测试的系统的培训完成
2、测试人员以及对所有被测系统/模块进行了使用，了解了被测系统的具体功能
测试需求
1、所有具体测试范围已确定2、测试需求制定完成3、所有测试需求得到客户认可
测试设计
1、测试用例已覆盖所有测试需求2、测试用例设计已经完成
测试执行
1、所有测试用例被执行2发现的缺陷都有缺陷记录3、测试过程有测试记录
结果分析
1、完成测试分析报告
七、可交付工具
测试提交物
1）测试计划2）功能模块说明3）测试总结
升级会员 