软件测试测试计划.docx
《软件测试测试计划.docx》由会员分享，可在线阅读，更多相关《软件测试测试计划.docx（14页珍藏版）》请在冰豆网上搜索。
软件测试测试计划
测试计划
修订历史记录
版本
日期
AMD
修订者
说明
1.0
2016年5月31日
M
六组全部人员
修改全部内容
2.0
2016年6月3日
MD
六组全部人员
修改并删除内容
3.0
2016年6月7日
MD
六组全部人员
主要修改格式、删除冗余
（A-添加，M-修改，D-删除）
1.简介
1.1目的
<学生信息管理平台>这一测试计划文档有助于实现以下目标:
Ø对每个测试模块制定测试策略和方法
Ø制定测试测试进度和任务安排
Ø确定软件测试目标
Ø准备测试所需的环境
Ø预测测试风险
1.2背景
本系统软件名为SMS学生信息管理平台的B/S结构，由洛阳惠普基地老师进行设计开发。
本软件旨在为惠普基地的老师与学生提供一个信息的收集与交流的平台。
学生信息管理平台的好处是：
一是为老师发布作业与学生下载、提交作业提供好的交流平台；二是使老师对学生的作业信息和学生的基本信息有更加系统的查询与保存功能。
1.3测试目标
本次测试使用手动测试和自动化测试来完成测试，根据用户需求，找出本系统学生管理、就业管理、档案管理、就业统计、作业管理等五个主要功能模块的缺陷和不足，发现系统隐藏的问题。
功能测试可至少要进行三个轮次的测试，测试用例执行率要达到90%，缺陷修改率要达到95%。
性能测试目标满足用户的要求或者与用户的要求接近度达到99%。
1.4范围
需要测试的目标：
在学生信息管理平台系统功能测试中，需要测试学生管理、就业管理、档案管理、就业统计、作业管理等五个主要功能模块
系统性能指标要求如下：
1、系统支持的在线用户数不低于500
2、登录、学生管理、就业管理、档案管理、就业统计、作业管理等模块，相关操作的平均响应时间不超过3s
软硬件环境需求：
1、CRM系统可运行于Windows平台，支持Apache服务程序
2、系统采用B/S架构，支持IE11、谷歌浏览器对系统的访问
3、系统数据库使用MySQL5.5（或更高版本）
界面需求：
1、系统界面规范，颜色、风格搭配
2、页面布局合理，人性化
3、界面文字信息准确
4、系统界面中的窗体与各种控件可正常显示和使用，易用性好
5、Tab键、enter键、快捷键等可以正常使用
2.测试参考文档和测试提交文档
2.1测试参考文档
文档
（版本/日期）
已创建或可用
作者或来源
测试需求规格说明书
是
上级分配
软件跟踪矩阵
是
六组成员
软件测试用例
是
六组成员
软件测试需求
是
六组成员
测试时间表及人员安排
是
六组成员
2.2测试提交文档
测试阶段
阶段提交物
测试需求分析
测试需求文档
测试计划设计
测试计划文档
测试用例设计
测试用例文档
手工缺陷报告
手工缺陷报告文档
功能测试报告
功能测试报告文档
性能测试报告
性能测试报告文档
测试报告编写
测试报告文档
3.测试进度
测试活动
计划开始日期
计划结束日期
制定测试计划
2016-5-31
2016-5-31
测试要点提取
2016-6-1
2016-6-2
ALM项目管理
2016-6-2
2016-6-2
测试用例编写
2016-6-2
2016-6-3
ALM测试用例导入
2016-6-3
2016-6-3
手工执行测试用例
2016-6-6
2016-6-7
兼容性测试
2016-6-7
2016-6-7
功能自动化测试
2016-6-8
2016-6-13
功能测试报告
2016-6-14
2016-6-14
性能测试
2016-6-14
2016-6-20
项目总结
2016-6-21
2016-6-21
4.测试资源
4.1人力资源
角色
小组成员
具体职责
负责模块
测试组长
测试计划编写
作业管理
测试用例编写
作业管理
测试跟踪矩阵编写
作业管理
ALM测试用例导入
作业管理
用例执行
作业管理
功能自动化测试
作业管理
性能测试
作业管理
项目总结报告
作业管理
测试小组成员
测试计划编写
就业管理_添加档案
测试用例编写
就业管理_添加档案
测试跟踪矩阵编写
就业管理_添加档案
ALM测试用例导入
就业管理_添加档案
用例执行
就业管理_添加档案
功能自动化测试
就业管理_添加档案
性能测试
就业管理_添加档案
项目总结报告
就业管理_添加档案
测试小组成员
测试计划编写
就业管理_添加就业
测试用例编写
就业管理_添加就业
测试跟踪矩阵编写
就业管理_添加就业
ALM测试用例导入
就业管理_添加就业
用例执行
就业管理_添加就业
功能自动化测试
就业管理_添加就业
性能测试
就业管理_添加就业
项目总结报告
就业管理_添加就业
测试小组成员
测试计划编写
档案管理
测试用例编写
档案管理
测试跟踪矩阵编写
档案管理
ALM测试用例导入
档案管理
用例执行
档案管理
功能自动化测试
档案管理
性能测试
档案管理
项目总结报告
档案管理
测试小组成员
测试计划编写
学生管理,就业统计
测试用例编写
学生管理,就业统计
测试跟踪矩阵编写
学生管理,就业统计
ALM测试用例导入
学生管理,就业统计
用例执行
学生管理,就业统计
功能自动化测试
学生管理,就业统计
性能测试
学生管理,就业统计
项目总结报告
学生管理,就业统计
4.2测试环境
软件环境（相关软件、操作系统等）
IE11浏览器
SMS系统（学生信息管理平台）
中间件服务器Tomcat7.0
硬件环境（网络、设备等）
Windows7平台
208机房小组成员各自电脑
VMware虚拟机
4.3测试工具
用途
工具
生产厂商/自产
功能测试
UFT
HP
性能测试
LoadRunner
HP
测试流程管理
ALM
HP
选择UFT工具做功能测试的优势:
支持功能测试和回归测试自动化，可用于软件应用环境的测试UFT自动化的基本功能是创建测试、检验数据、增强测试、运行测试脚本、分析测试结果、维护测试。
选择LoadRunner做性能测试的优势:
一种预测系统行为和性能的负载测试工具，可以对整个架构进行测试，能最大限度的缩短测试时间，优化性能和加速应用系统的发布周期。
选择ALM做测试流程管理工具的优势:
利用计算机辅助软件工程的软件工具。
以标准的流程管理方式，协助降低软件开发过程中认为造成的开发瑕疵，特别适用于大型应用的开发。
5.系统风险、优先级
系统在测试阶段的风险主要有：
Ø对质量需求或产品的特性理解不准确，造成测试范围分析的误差。
Ø测试用例没有得到百分之百的执行。
Ø需求的临时变化，导致设计的修改和代码的重写，导致测试时间不够。
Ø测试用例设计不到位，忽视了一些边界条件，深层次的逻辑，用户场景等。
Ø测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差。
Ø有些缺陷的出现频率不是百分之百，不容易被发现。
Ø回归测试一般不运行全部测试用例，是有选择性的运行，必然带来风险。
优先级：
Ø低：
暂时不影响继续测试，可以在方便时解决。
Ø中：
部分功能无法继续测试，需要优先解决。
Ø高：
测试暂停，无法进行，必须立即解决。
6.测试策略
6.1功能测试
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。
此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。
以下为各种应用程序列出了推荐使用的测试概要：
测试目标
学生管理、新增作业模块测试用例执行率达到80%，档案管理、就业管理、就业统计测试用例执行率达到90%
就业管理、就业统计模块功能满足用户基本的需求；学生管理、档案管理、新增作业模块功能严格满足用户基本的需求
测试范围
学生管理、就业管理、档案管理、就业统计、新增作业模块和兼容性测试（IE11、360、谷歌浏览器）
技术
进行手工测试,分析需求,制定测试计划,然后编写测试用例,用例包括（编号,测试名称,前置条件,操作步骤,预期结果,优先级,状态等）编写完成后开始执行用例,在操作的过程中发现缺陷,发现的缺陷以缺陷报告的方式进行提交,最后提交总结报告
开始标准
到测试合同（或项目计划）约定的时间
软件测试所需的各种文档已经准备完毕
所提交的被测软件受控
软件源代码正确通过编译或汇编
完成标准
按要求完成了合同（或项目计划）所规定的软件测试任务
实际测试过程遵循了原定的软件测试计划和软件测试说明
客观、详细地记录了软件测试过程和软件测试中发现的所有问题
软件测试中的问题或异常有合理解释或正确有效的处理
测试重点和优先级
测试重点：
学生管理、就业管理、档案管理、就业统计、新增作业模块
优先级：
中
需考虑的特殊事项
模块与模块之间的关联
用户要求的特殊功能
6.2用户界面测试
用户界面（UI）测试用于核实用户与软件之间的交互。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。
另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。
测试目标
通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用
窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准
测试范围
学生管理、就业管理、档案管理、就业统计、新增作业模块和兼容性测试（IE7.0、360、谷歌浏览器）
技术
进行手工测试,分析需求,制定测试计划,然后编写测试用例,用例包括（编号,测试名称,前置条件,操作步骤,预期结果,优先级,状态等）编写完成后开始执行用例,在操作的过程中发现缺陷,发现的缺陷以缺陷报告的方式进行提交,最后提交总结报告
开始标准
测试小组配置好软硬件测试环境，并能正常访问以及测试用例的编写完成
完成标准
按要求完成了合同（或项目计划）所规定的软件测试任务
实际测试过程遵循了原定的软件测试计划和软件测试说明
客观、详细地记录了软件测试过程和软件测试中发现的所有问题
软件测试中的问题或异常有合理解释或正确有效的处理
测试重点和优先级
测试重点：
学生管理、就业管理、档案管理、就业统计、新增作业模块
优先级：
中
需考虑的特殊事项
模块与模块之间的关联
用户要求的特殊功能
6.3性能评测
性能评测是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。
性能评测的目标是核实性能需求是否都已满足。
实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。
测试目标
测试SMS系统处于压力情况下，应用的表现
测试SMS系统找到特性环境下系统处理能力的极限
测试SMS系统程序对异常情况的抵抗能力
压力测试：
通过对软件系统不断施加压力，识别系统性能拐点，来获得系统提供的最大服务级别的测试活动
负载测试：
通过在被测系统上不断施加压力，直到达到性能指标极限要求
强度测试:
检查程序对异常情况的抵抗能力
测试范围
大流量数据与多用户操作时系统响应时间,事务处理速率等
技术
负载测试
压力测试
强度测试
开始标准
到测试合同（或项目计划）约定的时间
软件测试所需的各种文档已经准备完毕
所提交的被测软件受控
软件源代码正确通过编译或汇编
完成标准
完成了合同规定的软件测试任务
发现了缺陷并得到了解决
测试工作通过了测试评审
客观详细记录了软件测试过程中发现的问题
达到并且满足的用户的需求
测试重点和优先级
测试重点:
对系统进行负载测试压力测试强度测试测试工作
优先级:
高
需考虑的特殊事项
负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测
应该暂时减少用于系统的DASD，以限制数据库可用空间的增长
使多个客户机对相同的记录或数据帐户同时进行的访问达到同步
7.测试标准
7.1测试接收标准
Ø到测试合同（或项目计划）约定的时间；
Ø软件测试所需的各种文档已经准备完毕；
Ø所提交的被测软件受控；
Ø软件源代码正确通过编译或汇编；
Ø最好从一开始就介入到被测软件的开发周期。
7.2测试停止标准
Ø按要求完成了合同（或项目计划）所规定的软件测试任务；
Ø实际测试过程遵循了原定的软件测试计划和软件测试说明；
Ø客观、详细地记录了软件测试过程和软件测试中发现的所有问题；
Ø软件测试的全过程自始至终在控制下进行；
Ø软件测试中的问题或异常有合理解释或正确有效的处理；
Ø软件测试工作通过了测试评审；
Ø全部测试软件、被测软件、测试支持软件和评审结果已纳入配置管理。
7.3非正常停止标准
Ø项目需要暂停进行调整，测试应暂停并备份暂停点的数据；
Ø软件在开发过程中出现重大偏差；
Ø本轮提交的缺陷未得到开发反馈；
Ø项目和需求中有2处不一致的情况出现；
Ø项目经理有特殊情况，需发文档说明并停止测试。
8.风险管理
8.1项目进度风险
Ø料：
需求变更、测试用例数据设计不充分、质量标准不统一；
Ø人：
疲态、同化效应、定位效应、业务不熟、测试人员变动；
Ø时：
测试时间不足、测试时间延长；
Ø环：
被测试软件版本不统一、被测试环境不一致、被测试硬件环境不一致、测试硬件未及时到位；
Ø法：
错误或缺失测试方法、场景缺失或部分缺失、测试用例实施不充分；
Ø其他：
沟通不良、开发提交测试时间比计划延时。
8.2需求变更风险
Ø针对需求变更过快问题，测试人员与开发人员应及时保持联系取得最新需求，并且测试人员必须和开发人员高度一致，保证测试人员所掌握需求是第一手资料。
一旦发生需求改动而测试人员不知情的情况，首先确认需求变动。
必要情况下可增加测试人员，同时，测试相关文档可以稍后修改，完成预定目标。
Ø针对需求不清晰问题，找相应的需求人员和开发人员进行需求评审，一定要和需求人员和开发人员意见达到一致。
8.3沟通不良风险
预防这种风险应该是项目建设之初测试人员就和此项目的相关人员进行交流和沟通，注意培养和锻炼自身的沟通技巧。
8.4功能和需求不一致风险
测试结束时，应用功能和需求不一致：
告知项目经理，并留下文档进行说明。
9.附录：
项目任务
以下是一些与测试有关的任务：
✧ 制定测试计划
⏹确定测试需求
⏹制定测试策略
⏹创建时间表
⏹生成测试计划
✧设计测试
⏹准备工作量分析文档
⏹确定并说明测试用例
✧执行测试
✧执行测试过程
✧评估测试的执行情况
✧核实结果
✧记录缺陷
✧对测试进行评估
✧评估测试用例覆盖
✧分析缺陷
✧确定是否达到了测试完成标准与成功标准
升级会员 