产品测试策略V1.0.docxVIP

产品测试策略 产品测试策略 PAGE 产品测试策略 测试策略 总体测试策略 确定产品质量目标，进行项目整体的风险识别，从产品层面来确定测试重点和测试难点、测试深度和测试广度。 明确“产品质量目标” 产品质量评估 评估项目 产品基线 项目试用 测试覆盖度 需求覆盖度 100% 90% 测试过程 测试用例执行率 100% 90% 安全测试 通过 通过 性能测试 通过 通过 代码规范 % % 缺陷 缺陷修复率 ≥90% ≥85% 文档 按产品标准输出文档 达标 功能分类“测试策略” 分类 优先级 说明 测试策略 新功能开发 高 全新开发的功能 全面测试 旧功能修改 中 功能的修改完善 1）对改动功能的部分进行全面测试 2）进行稳定性测试 旧功能无改动 低 旧模块功能无代码改动 探索式测试 进行“风险分析” 1）提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整我们的测试策略，增加一些测试活动或者质量保证活动。 2）基于风险来加强和降低测试投入。 序号 预知风险 级别 解决措施 1 产品需求文档描述不够完整、清晰，不能有效指导开发和测试人员的工作。 高 前期多参加产品评审会议 加强和开发、产品经理的业务场景沟通、讨论、记录 2 在测试设计时，设计和需求文档未能及时更新，导致测试设计遗漏或不准确，无法达到测试设计的预期效果。 中 对已知的变更进行沟通 督促产品经理对需求变更形成记录 3 新版本修改的功能点，修改影响没有文档记录 高 和开发沟通，让其提供一份修改说明文档 4 产品功能设计的过于复杂，难以理解 高 和产品经理沟通，确认设计的优化可能性 让开发同事对设计实现进行讲解 5 产品中存在需要多人才能配合完成的功能，缺乏总体责任人推进 中 建议产品增加总责任人，负责确认接口、整体协调等 增加开发自测，将该功能作为冒烟测试点。 6 版本自测不充分 高 转给测试的版本，需要开发人员和产品经理进行自测，并出具测试报告 提供开发自测测试用例 7 在测试执行时，发现一些测试用例因为缺陷或者代码提交的原因阻塞了，不能按照计划进行测试执行。 高 1）及时和开发沟通解决 8 在测试执行时，发现缺陷迟迟不能修改，缺陷分析的结果不能达到预期。 中 和开发人员沟通协助修复 和产品负责人沟通，寻求开发资源 9 版本管理不明确，没有明显的发布计划 高 主动跟进产品的修改情况，确认发布计划 评估产品版本发布 总体测试安排 重要节点 开发完成时间 测试安排 测试计划时间 概念阶段 已完成 了解概念阶段的需求信息 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 第一个版本测试策略 测试范围 需要注意的是，这里的测试范围，是指开发能够真正提交，并且测试可测的功能。 安卓端： 编号 一级功能 二级功能 功能概述 优先级 用户 说明 1 登录 帐号密码登录 中 所有用户 升级改造 2 主页 功能入口 中 执法人员、领导 升级改造 3 执法管理 执法取证 做笔录及取证 高 执法人员、中层领导 升级改造 4 我的笔录 当前登录人做过的笔录（包括未提交笔录） 高 执法人员、中层领导 新增 5 待办任务 待处理的执法任务 高 执法人员、中层领导 升级改造 6 指派任务 上级指派执法任务给下级 高 中层领导 升级改造 7 预警雷达 预警监测超标或发现涉嫌环境问题 中 中层领导 升级改造 8 信息查询 一源一档 污染源信息查询 高 执法人员、中层领导 升级改造 9 一队一档 执法机构及人员信息查询 中 执法人员、中层领导 升级改造 10 执法台帐 执法及立案记录查询 高 执法人员、中层领导 升级改造 11 在线监测 在线监测企业监测数据查询及超标记录查询 中 执法人员、中层领导 升级改造 12 环保知库 嵌入知库 中 执法人员、中层领导 集成 13 决策分析 实时监控 GIS地图监控执法动态 高 中高层领导 集成 14 统计分析 从人、源、事进行统计分析辅助决策 高 中高层领导 集成 15 数据报送 方便领导监控执法数据报送情况 高 中高层领导 集成 16 我的 个人统计 个人执法情况统计 中 所有 升级改造 17 我的足迹 个人执法轨迹查询 中 执法人员及中层领导 升级改造 18 系统设置 系统更新等设置 低 所有 升级改造 后台： 编号 一级功能 二级功能 功能概述