产品测试策略Word格式文档下载.docx
《产品测试策略Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《产品测试策略Word格式文档下载.docx（16页珍藏版）》请在冰点文库上搜索。
全新开发的功能
全面测试
旧功能修改
中
功能的修改完善
1）对改动功能的部分进行全面测试
2）进行稳定性测试
旧功能无改动
低
旧模块功能无代码改动
探索式测试
1.3.进行“风险分析”
1）提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整我们的测试策略，增加一些测试活动或者质量保证活动。
2）基于风险来加强和降低测试投入。
序号
预知风险
级别
解决措施
1
产品需求文档描述不够完整、清晰，不能有效指导开发和测试人员的工作。
前期多参加产品评审会议
加强和开发、产品经理的业务场景沟通、讨论、记录
2
在测试设计时，设计和需求文档未能及时更新，导致测试设计遗漏或不准确，无法达到测试设计的预期效果。
对已知的变更进行沟通
督促产品经理对需求变更形成记录
3
新版本修改的功能点，修改影响没有文档记录
和开发沟通，让其提供一份修改说明文档
4
产品功能设计的过于复杂，难以理解
和产品经理沟通，确认设计的优化可能性
让开发同事对设计实现进行讲解
5
产品中存在需要多人才能配合完成的功能，缺乏总体责任人推进
建议产品增加总责任人，负责确认接口、整体协调等
增加开发自测，将该功能作为冒烟测试点。
6
版本自测不充分
转给测试的版本，需要开发人员和产品经理进行自测，并出具测试报告
提供开发自测测试用例
7
在测试执行时，发现一些测试用例因为缺陷或者代码提交的原因阻塞了，不能按照计划进行测试执行。
1）及时和开发沟通解决
8
在测试执行时，发现缺陷迟迟不能修改，缺陷分析的结果不能达到预期。
和开发人员沟通协助修复
和产品负责人沟通，寻求开发资源
9
版本管理不明确，没有明显的发布计划
主动跟进产品的修改情况，确认发布计划
评估产品版本发布
1.4.总体测试安排
重要节点
开发完成时间
测试安排
测试计划时间
概念阶段
已完成
了解概念阶段的需求信息
2018-09-06—2018-09-18
设计阶段
原型和需求说明书分析测试，编写测试用例
2018-09-17—2018-09-22
开发阶段
2018-09-01—2018-10-30
制定测试策略，安排测试计划，更新测试用例
2018-09-17—2018-10-28
测试阶段
完成功能，安全，文档测试
2018-11-12—2018-11-23
发布阶段
发布符合质量标准的版本
2018-12-24—2018-12-26
2.第一个版本测试策略
2.1.测试范围
需要注意的是，这里的测试范围，是指开发能够真正提交，并且测试可测的功能。
安卓端：
编号
一级功能
二级功能
功能概述
用户
登录
帐号密码登录
所有用户
升级改造
主页
功能入口
执法人员、领导
执法管理
执法取证
做笔录及取证
执法人员、中层领导
我的笔录
当前登录人做过的笔录（包括未提交笔录）
新增
待办任务
待处理的执法任务
指派任务
上级指派执法任务给下级
中层领导
预警雷达
预警监测超标或发现涉嫌环境问题
信息查询
一源一档
污染源信息查询
执法人员、中层领导
一队一档
执法机构及人员信息查询
10
执法台帐
执法及立案记录查询
11
在线监测
在线监测企业监测数据查询及超标记录查询
12
环保知库
嵌入知库
集成
13
决策分析
实时监控
GIS地图监控执法动态
中高层领导
14
统计分析
从人、源、事进行统计分析辅助决策
15
数据报送
方便领导监控执法数据报送情况
16
我的
个人统计
个人执法情况统计
所有
17
我的足迹
个人执法轨迹查询
执法人员及中层领导
18
系统设置
系统更新等设置
后台：
帐号密码登录系统
不升级
概览
摸清家底，掌握动态
领导
待办任务处理
执法人员，
指派执法任务
执法常用语
编辑执法常用语
系统管理员
执法表单管理
笔录配置
立案调查
立案、调查报告文书草拟审核及证据资料整理归档
执法人员、
信息管理
查询污染源信息
查询队伍人员信息
执法事件
查询执法事件
环保智库
查询法律法规等
辅助领导决策
高层领导
一张图
地图分布分析
案卷归档配置
编辑用户角色
笔记本端：
概述
登陆
账号密码登陆
升级
首页
全局搜索
用于搜索法律法规和企业
待办任务提示
待办任务快捷入口
新建笔录
搜索污染源，做笔录
查看“我”做的笔录，包括已提交和未提交的笔录
执法台账
查看全网的执法记录
模板管理
管理调查询问笔录模板，可以新增自定义模板
关于系统
系统及版本说明
意见反馈
反馈对本系统的意见及改进建议
2.2.测试目标
对象–测试方法–测试结果这样的方式来描述测试目标，强调这个版本测试的要求。
子系统
功能测试
兼容测试
移动执法后台
功能需求正确实现
谷歌、IE9及以上、360浏览器
详见需求文档
安卓终端
以上
通过测试平台测试，和开发核对问题修复
笔记本端
Win7、Win10、Windows
2.3.重点业务关注
重点内容说明
重点功能
1.指派任务流程的正常办理
2.执法事件的台账数据展示
3.执法笔录的正常打印
4.立案调查流程的正常办理
5.概览页面数据展示
6.决策分析统计数据
业务关注
1.任务执法场景，指定和不指定污染源
2.不同层级领导概览和决策分析数据查看权限
3.动态表单的配置
4.立案调查的一键生成案卷
安卓终端：
1.任务流程的正常办理
2.执法笔录的填写，打印，展示
3.我的笔录数据展示、再编辑
4.执法事件的台账数据展示
1.新增企业执法场景
2.现场直接填笔录执法场景
3.任务执法场景
4.离线执法
5.执法过程历史笔录的数据提取
6.在线监测数据对接
1.执法笔录的填写，打印，展示
2.我的笔录数据展示、再编辑
3.执法事件的台账数据展示
2.4.测试环境资源
测试资源分为人力和工具两部分。
人力资源主要说明参与测试的人员，工具主要是指可能用到其他软件，测试环境是指兼容的环境信息。
开发责任人
测试责任人
测试环境
测试工具
后台
胡小龙
康铭
陆思毅
康铭、刘睿
华为荣耀X6
曾益
Win7、Win10、Windows
2.5.用例设计选择
系统
测试用例选择策略
完成情况
1.基础功能选择testlink中通用测试用例的测试用例
2.重点功能和业务用例手动编写并审核通过
1.未开始
2.编写中
安卓端
笔记本
2.6.冒烟测试策略
开发人员将版本转给测试人员时，测试人员先对这个版本进行一次测试，确认版本没有阻塞测试的问题，能够按照测试策略完成测试。
如果存在影响测试的问题，及时找开发沟通解决。
1.任务办理正常；
2.笔录正常填写，打印，提交；
3.台账记录正常；
2.7.文档管理
对于一个完整的产品来说，文档是很重要的一环。
它需要经过完整的测试验证。
文档名称
测试情况
需求规格说明书
用户操作手册
系统部署实施说明
3.跟踪测试执行
确保测试团队是按照测试策略来执行测试的。
关注项目中的实时风险，基于风险来调整测试策略。
3.1.跟踪测试用例执行情况
用例总数
执行数量
未通过数量
通过数量
通过率
未执行数量
未执行原因
3.2.缺陷跟踪
跟踪版本需要解决但还处于待修复状态bug的解决情况：
Bug描述
是否解决
4.版本质量评估
4.1.需求和实现的偏差
需求描述
实现偏差
BugID
修复说明
4.2.测试过程评估
1.测试方法回顾：
总结比较有效的方式方法
2.测试投入回顾
3.测试用例分析
4.3.缺陷分析
1.功能特性的缺陷密度是否正常
2.缺陷阶段分析是否正常
原型阶段
需求阶段
Bug数
5.后面的版本测试策略
后面的版本会考虑到实际的产品研发情况和测试情况，而对测试策略进行调整，因此，后面版本的测试策略还需要增加回归测试策略和探索式测试策略的内容。
5.1.回归测试策略
5.1.1.缺陷回归
确认测试中发现的缺陷被开发人员正确修复了。
我们将缺陷分为三类：
功能类、非功能类、底层或中间层类。
底层或中间层类缺陷很多功能都可能会调用它们，修改它们往往会影响较多的功能。
对这类问题，可以使用如下策略：
1）控制这类缺陷在设计修改和编码上的质量。
例如，要求开发人员对修改代码进行自测。
2）测试责任人根据缺陷的修改方案来确定需要进行回归测试的内容。
5.1.2.功能回归
确认老功能不会因为新合入的功能而失效。
1）新开发功能在合入版本后的回归测试
2）老功能回归测试
5.2.探索式测试策略
5.2.1.基于场景的探索式测试
基于用户操作场景测试软件的重要功能模块，确保功能正常稳定。
快速访问软件的各种功能，确保基本功能正常。
5.2.2.基于反馈的探索式测试
利用反馈来指导今后的探索。
例如“覆盖”，上一次测试我用的ie，这一次我用谷歌
6.发布质量评估
6.1.确认总体测试策略中的质量目标是否完成
6.2.遗留缺陷分析
缺陷对用户的影响程度
缺陷风险评估和规避措施
不能遗留的缺陷：
“致命”缺陷不应该作为遗留缺陷。
没有“规避措施”的“严重缺陷”不应该遗留。
6.3.暂挂bug的处理
被暂挂的bug，也需要有合理的解决方案。
需要和开发人员、产品经理沟通确认修复方案。
那些一直被暂挂的bug，需要测试责任人定期将这些bug汇总，选择优先级高的缺陷，组织开发人员和产品经理评审，沟通解决方案。
升级会员 