测试计划模板.docx
《测试计划模板.docx》由会员分享，可在线阅读，更多相关《测试计划模板.docx（11页珍藏版）》请在冰豆网上搜索。
测试计划模板
XX测试计划
产品名称
项目承担部门
撰写人（签名）
完成日期
本文档使用部门
测试部
评审负责人（签名）
评审日期
版本
V1.0.0
日期
版本
说明
作者
目录
1.概述3
1.1.产品简介3
1.2.范围4
1.3.限制条件4
1.4.参考文档5
2.约定5
2.1.测试目标5
2.2.接收标准5
2.3.资源和工具6
2.3.1.资源6
2.3.2.工具6
2.4.送测要求6
2.5.编号规则7
3.测试种类及测试标准7
3.1.测试种类7
3.2.测试方法及标准8
3.2.1.功能测试8
3.2.2.业务测试8
3.2.3.压力测试8
3.2.4.安装测试9
3.2.5.冒烟测试9
3.2.6.敏捷性测试10
4.测试重点及顺序10
4.1.预测风险10
4.2.测试重点10
4.2.1.功能测试10
4.2.2.业务测试12
5.暂停标准和再启动要求12
6.测试任务和工作量13
7.测试提交物13
8.其他14
8.1.业务了解14
8.2.内部沟通14
1.概述
1.1.产品简介
本次开发是太仓薄片集成控制与SPC系统开发，SPC系统开发可以沿用津烟mes质量检测控制部分。
1.2.范围
本测试计划是针对<薄片厂自控_MIS-需求规格说明书>中规定内容的测试计划，包括：
Ø新增的产品定义模块
Ø新增的工序定义模块
Ø新增的生产排班模块
Ø新增的关键特性遴选模块
Ø新增的关键特性关联模块
Ø新增的判异规则确定模块
Ø新增的异常原因分析模块
Ø新增的反应措施制定模块
Ø新增的处理流程设计模块
Ø新增的方案制定模块
Ø新增的数采执行模块
Ø新增的工具选择模块
Ø新增的标准制定模块
Ø新增的监控执行模块
Ø新增的过程测量模块
Ø新增的过程历史查看模块
Ø新增的质量检验体系管理模块
Ø新增的质量检验规程管理模块
Ø新增的基片定量和基片水分的数采方案和监控标准（待定）
Ø新增的报表需求（待定）
1.3.限制条件
本测试计划受限于产品开发人员提交测试的内容和时间的事实。
根据开发人员提交模块的实际情况，本计划会做出相应修改。
1.4.参考文档
序号
名称
作者
备注
1.
2.
3.
4.
2.约定
2.1.测试目标
通过测试，达到以下目标：
Ø测试已实现的产品是否达到设计的要求，包括：
各个功能点是否以实现，业务流程是否正确。
Ø产品规定的操作和运行稳定。
ØBug数和缺陷率控制在可接收的范围之内。
2.2.接收标准
本节所述的接收标准是指可测试的标准，这个标准以测试组接收测试为限；测试过程中对于开发所提高的测试版本，实行打回机制，按测试规范文档执行。
2.3.资源和工具
2.3.1.资源
Ø测试服务器
稳定的测试服务器，具体以前后台环境部署为准。
Ø人员
主要测试项目负责人一名，测试实施人员4名（注：
后期可考虑让张小培参与需求报表测试）。
2.3.2.工具
Ø测试中使用的Bug管理工具为TD8.0管理工具。
Ø自动化测试工具（WEB页面可采用TestStudio2011.2;C/S系统工具待定）。
2.4.送测要求
太仓薄片开发人员提交的测试按以下要求进行：
步骤
动作
负责人
相关文档或记录
要求
1
打包、编译
开发人员
确认可测试
2
接收测试
测试人员
冒烟测试、执行打回机制
3
开始测试
测试人员
内部抽查机制、小结
测试小结由具体负责执行测试人编写
2.5.编号规则
与本测试计划相关的编号规则如下：
ØTestDirector中Subject命名，项目名：
例如：
太仓薄片
Ø数据准备文件命命名规则，项目名+模块名+数据准备
例如：
太仓薄片质量管理基础
太仓薄片质量管理基础数据准备
Ø答疑、理解文档、SQL积累命名规则，项目名+答疑文档
例如：
太仓薄片答疑文档
3.测试种类及测试标准
3.1.测试种类
计划完成以下类型测试：
Ø功能测试
Ø业务测试
Ø压力测试
Ø安装测试（注：
主要针对C/S系统）
Ø冒烟测试
Ø敏捷性测试（待定）
3.2.测试方法及标准
3.2.1.功能测试
3.2.1.1.功能
系统能按照设计要求实现模块的各个功能，数据应完整、界面美观、操作方便。
具体可参照功能手册文档。
3.2.1.2.界面测试
详细的界面测试可以参考软件测试中有关界面测试经验总结.doc。
3.2.1.3.数据项测试
详细介绍可以参照基础功能checklist.xlsx。
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.安装测试说明
除了嵌入式软件之外，安装是软件产品实现其功能的第一步，没有正确的安装根本就谈不上正确的执行，因此对于安装的测试就显得尤为重要。
3.2.4.2.安装测试方法及标准（供参考）
Ø自动安装还是手工配置安装，测试各种不同的安装组合，并验证各种不同组
合的正确性，最终目标是所有组合都能安装成功。
Ø安装退出之后，确认应用程序可以正确启动、运行。
卸载测试和安装测试同样重要，如果系统提供自动卸载工具，那么卸载之后需检验系统是否把所有的文件全部删除，注册表中有关的注册信息是否也被删除。
Ø至少要在一台笔记本上进行安装测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品。
（有条件的情况下）
Ø安装完成之后，可以在简单地使用之后再执行卸载操作，有的系统在使用之后会发生变化，变得不可卸载。
Ø安装时间是否合理；
Ø对于客户服务器模式的应用系统，可以先安装客户端，然后安装服务器端，测试是否会出现问题。
Ø考察安装该系统是否对其他的应用程序造成影响，特别是Windows操作系统，经常会出现此类的问题。
3.2.5.冒烟测试
3.2.5.1.冒烟测试说明
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。
该部分测试需辅助执行测试打回机制。
3.2.5.2.冒烟测试方法及标准
Ø根据软件的变更，包括新需求的实现、bug修复，设计出更改满足预期的功能级checklist。
Ø准备好测试环境。
如：
软件的运行环境是嵌入式产品，如手机，数码相机，医疗仪器等，需准备好用户使用的真实运行环境。
如果是windows平台运行环境，请准备干净的操作系统。
Ø执行checklist，确认基本功能有效，足以支持更进一步的详细、全面测试
3.2.6.敏捷性测试
待定
4.测试重点及顺序
4.1.预测风险
本次测试过程中，可能出现的风险如下：
Øbug的修复情况
Ø模块功能的实现情况
Ø系统整体功能的实现情况
Ø代码的编写质量
Ø人员经验以及对软件的熟悉度
Ø开发人员、测试人员关于项目约定的执行情况
Ø人员调整导致研发周期延迟
Ø开发完成时间的延期导致某些测试计划无法执行
Ø需求的不确定性，导致设计调整，测试暂停
ØC/S程序是否支持32、64位操作系统
Ø是否需要开发新技术支持
4.2.测试重点
4.2.1.功能测试
这里仅为测试重点的描述，具体测试方法以及内容请参见数据准备。
4.2.1.1.产品定义
Ø增、删、改功能是否实现
Ø再造烟叶是否可维护相应检测标准
4.2.1.2.工序定义
Ø查看工序等级和工序控制类别业务上是否联动
Ø增、删、改功能是否实现
4.2.1.3.生产排班
Ø新增数据是否维护了上下班时间
4.2.1.4.关键特性定义
Ø关键特性与三级工序、工序是否关联
4.2.1.5.异常判定与处理
Ø浏览窗口是否正确
Ø编辑功能是否实现
Ø是否根据指定条件搜索
Ø新增数据到知识库是否正确
4.2.1.6.在线数采
Ø浏览时列表显示是否正确
Ø增、删、改功能是否已经实现
4.2.1.7.在线监控
Ø各图形根据数采信息是否正常显示
Ø监控执行相应时间上是否接受
Ø采集数据点是否丢失
4.2.1.8.过程分析
Ø浏览窗口显示是否正确
Ø增、删、改功能是否已经实现
Ø能否按照指定条件查询报表
Ø导出附件是否正确
4.2.1.9.质量检验
Ø增、删、改功能是否已经实现
Ø浏览界面是否正确
Ø能否按照指定条件搜索
Ø新增数据到知识库是否正确
Ø选择界面是否可用
4.2.2.业务测试
这里只是描述了业务测试的大概情况，具体测试方法以及内容请参见数据准备文档。
（注：
根据设计文档描述，描述业务流程，参照流程维护业务数据测试）
5.暂停标准和再启动要求
Ø软件系统在进行冒烟测试时，发现bug等级较高，直接影响到测试的进行，暂停测试返回开发。
Ø软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。
Ø软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。
Ø如有新的项目需求，则在原测试计划下做相应的调整。
Ø若开发暂停，则相应测试也暂停，并备份暂停点数据。
。
Ø若项目中止，则对已完成的测试工作做测试活动总结。
Ø项目再启动时，测试进度重新安排或顺延。
6.测试任务和工作量
测试阶段
测试任务
工作量估计
人员分配
起止时间
第一阶段
单元测试
保证基本功能不报错，功能性bug不出现
参照现有项目执行情况（准备12天、测试36天、抽查12天）
测试人员
第二阶段
集成测试
待定
待定
第三阶段
业务测试
业务流程测试
关注数据的准确性,特别是导出数据
准备1天，测试3天，抽查1天
测试人员
第四阶段
性能测试
性能测试
2天（待定）
测试人员
测试总结
测试总结和分析、问题反馈
0.5天
测试项目负责人
注：
测试过程前期准备、测试执行、抽查进行工作量量化比1：
3：
1
7.测试提交物
本次测试完成后的提交物：
Ø测试计划
Ø测试数据准备、业务流程
Ø测试小结
8.其他
8.1.业务了解
整个项目进行下来，希望能在测试内部挖掘一些比较有潜质，对业务理解比较的人；在抽查过程抽查人员可针对业务理解上的困惑，通过问题管理系统分配个相应测试人员了解业务；也可在测试例会或测试与开发进行bugreview时解答开发人员对业务的模糊。
8.2.内部沟通
Ø在项目开动时，相应的测试项目负责人，参与设计与需求部门的review会议，整理会议记录；预估测试难点、风险。
Ø项目开发前期，在时间允许的情况下，可协商设计部门不定期根据开发人员、测试人员反映的业务理解部分进行专门的培训，尽量减少工作时间内不必要的沟通。
Ø测试进行时，可根据阶段测试出的bug问题，可以协商开发人员，每周召开小范围的会议；
Ø建议：
可以在SDC部门内部根据具体项目，建立一个小矩阵，参与成员：
主要项目设计负责人、测试负责人、开发负责人一个小的team；在年底或项目收尾时，让实施部门或者相关领导进行评估。
升级会员 