产品测试管理

上传人:ji****n 文档编号:54757300 上传时间:2018-09-18 格式:PPT 页数:134 大小:4.75MB
返回 下载 相关 举报
产品测试管理_第1页
第1页 / 共134页
产品测试管理_第2页
第2页 / 共134页
产品测试管理_第3页
第3页 / 共134页
产品测试管理_第4页
第4页 / 共134页
产品测试管理_第5页
第5页 / 共134页
点击查看更多>>
资源描述

《产品测试管理》由会员分享,可在线阅读,更多相关《产品测试管理(134页珍藏版)》请在金锄头文库上搜索。

1、华成培训研发管理系列课程之RDM015,NPD-Testing,产品测试管理,课程目录,0、公司介绍 课程介绍,1、产品测试概述,2 、产品测试组织,3 、产品测试需求分析,5 、产品测试用例设计,4 、产品测试策略和计划,6、产品测试自动化,7、产品测试缺陷分析,华成对企业核心价值链的理解,课程清单(一),课程清单(二),课程清单(三),课程清单(四),产品开发管理的发展历程,Next Generation Product Development : How to Increase Productivity, Cut Costs, and Reduce Cycle Times (Hardco

2、ver) ,青铜器RDM全方位实现研发业务信息化,产品测试概述,系统质量管理体系,如:产品开发流程集成测试流程技术支持工作流程结构设计流程软件开发流程器件选型流程培训流程,如:ISO9000内审计划工程质量管理计划培训质量管理计划,如:组织机构角色与职位情景化知识管理体系PAL,如:业务改进体系优化能力提升根源分析,如:引导/培训审计/检查结果审计质量体系审计,如:度量评审评估测试,提示,华成咨询课程 RDM017 研发质量管理 详细讲解整个研发质量管理体系的构成和执行的方法,2.,管理级,1.,初始级,3.,定义级,4.,量化管理级,有纪律的过程,标准、一致的过程,可预测的过程,持续改进过程

3、,不可预测并且缺乏控制,可重复以前的主要经验,过程被描述,并得到良,好理解,过程被测量并受控,关注过程改进,5.,优化级,项目管理,集成工程过程,产品和过程质量,管理变更,测试在CMMI中的位置,Verification:验证 Validation:确认,CMMI : Capability Maturity Mode Integration 能力成熟度模型集成,测试贯穿产品开发始终,概念,方案,开发,验证,发布,启动 项目,制定产品测试策略,测试,制定产品测试计划,持续跟踪监控产品测试计划,TR,TR,TR,TR,TR,TR,DCP,DCP,DCP,优化产品测试计划,缺陷引入阶段分析,错误定位

4、费用分析,错误引入阶段分析,James Martin: 超过50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起,James Martin: 80%以上的用于定位软件错误的费用是基于软件系统需求定义的错误,为什么要尽早测试,测试两原则,Good-enough原则 Zero-bug & Good-enough 投入 & 产出 Pareto原则 研发测试:80% BUG 系统测试:80% BUG 用户使用:5% BUG,产品测试组织,研发测试部在公司的位置,硬件部,测试,部,产品测试组,产品测试组,产品测试组,测试物料部,项目团队的构成(NPD),注:来自PDMA Handbook,

5、项目团队模式,产品经理/项目经理,开发经理(代表),测试经理(代表),其他,配 置 管 理,风 险 管 理,度 量 管 理,测 试 协 调 员,业 务 测 试 组,性 能 测 试 组,验 收 测 试 组,特 性 测 试 组,TSE,SE,QA,测试组织的演进,混淆阶段 没有专职测试人员 缺少完善的测试流程 测试手段单一,严格区分阶段 测试部门独立 专职测试人员 不断完善的测试流程 测试工具技术开发,专业协作阶段 专职测试人员 完备的测试流程 人人具备测试意识 测试工具技术开发 运营测试,测试人员的双重晋升机制,测试人员资格等级划分,不同等级负责不同事务,初做者,专家,高级专家,资深专家,监督者

6、,管理者,领导者,有经验者,测试执行,例如系统测试操作,测试系统设计,可测试性设计,测试规划,测试评估,测试用例设计,例如系统测试用例编写,测试脚本编写,测试团队领导,测试工程领导,技术指导,测试体系构造,例如构造公司级别的测试平台,测试技术研究,测试过程改进,测试人员职业发展,Tester,客户需求分析专家,自动化测试专家,产品/项目经理,测试职能经理,资深测试专家,售前支持专家,产品技术支持专家,演练与讨论,结合公司实际测试工作,您认为一个优秀的测试人员需要具备哪些素质特征? 每个小组选派一名代表上台发表,产品测试需求分析,产品测试需求分析,测试需求分析,测试方案,DFT,产品需求评审 产

7、品测试规格 测试重点分析,测试环境 特性测试方案,客户化测试(面向需求的测试),IBM:客户遇到的57故障来自2的缺陷 站在客户角度测试有利于测试效率提升,系统缺陷,客户遇到缺陷,需求工程贯穿产品开发全过程,市场需求,产品包需求,内部需求,设计需求,系统规格,软件需求,客户要求,功能需求 非功能需求,标准约束,硬件需求,架构设计,质量属性 DFX,书面标准 事实标准,功能分解,将系统功能分解为更详细的子功能 将子功能需求按照逻辑顺序排列 详尽考虑所有可能的异常和反复,自上而下层层分解,Top Level1st Level2nd Level,6.0,5.0,3.0,4.0,2.0,1.0,1.1

8、,1.2,1.3,1.4,1.5,1.6,1.7,2.6,2.8,2.7,1.4.1,1.4.2,1.4.3,1.4.4,1.4.5,1.4.6,1.4.7,1.5.6,1.5.7,层次图,层次图:Hierarchy Diagram(Function Tree、Physical Tree),好需求的标准,以下需求有什么问题?,某照相机有2个需求: 在胶片到底后,可高速回绕。 胶片回绕过程中噪音要小。 某发动机有4个需求: 如果 70 温度 100,那么输出功率为3000W 如果100 温度 130,那么输出功率为2000W 如果120 温度 150,那么输出功率为1000W 如果150 温度,

9、那么输出功率为0W,产品生命周期成本冰山模型,什么是DFT?,可测性:系统和设备能及时准确地确定其工作状态(可工作、不可工作、工作性能下降)并隔离其内部故障的一种设计特性 -MIL-STD-2165,目的 方便测试 降低测试成本 发现、定位、隔离、解决问题,可见性 面向测试、维护人员 一般对客户不可见,客户也不关心,全流程性 贯穿项目全过程 涵盖所有测试阶段:验证测试、生产测试、维护诊断,DFT,可观可控可预测,DFT : Design For Test 可测试性设计,DFT的必要性,M公司DFT效益分析,产品测试分析与设计,产品包需求,设计需求,设计规格,产品测试 需求分析,测试规范 与理论

10、,制定产品 总体测试策略,BUILD计划,特性A 测试方案,特性B 测试方案,特性C 测试方案,特性A 测试用例,特性B 测试用例,特性C 测试用例,测试执行,测试 需求 分析,测试 方案 设计,测试 用例 设计,猴测试,需求双向跟踪机制,RTM : Requirements Tracing Matrix 需求跟踪矩阵,演练与讨论,总结历史项目后期测试中存在的效率低下、难以测试、测试问题难以定位等问题,提炼总结项目的可测试需求(DFT)? 每个小组选派一名代表上台发表,产品测试策略和计划,产品测试策略与计划,概念,方案,开发,验证,发布,启动 项目,制定产品测试策略,制定产品测试计划,持续跟踪

11、监控产品测试计划,TR,TR,TR,TR,TR,TR,DCP,DCP,DCP,优化产品测试计划,测试,测试策略需要重点考虑的内容,关键测试技术分析 需求的自动化测试分析 关键测试数据的获得 每个BUILD的测试重点分析 外部认证和标竿测试分析 测试仪器、环境的获得性分析,测试工具分析,软件打点方式 比较便宜 可在CACHE打开下工作对目标系统影响大(超过50%) 占用目标系统资源如,CPU 时间 内存,通讯通道等 缺乏很好的性能分析 缺乏覆盖率分析 缺乏内存分配分析 精确度偏低,对目标系统影响小(1-15%) 不占用目标系统资源 软件打点技术 强大的性能分析 强大的覆盖率分析 强大的内存分配分

12、析 价格较便宜 可在CACHE打开方式下工作 非常精确,不影响目标系统(0%) 不占用系统资源 不用打点有限或没有性能分析 有限的或没有覆盖率分析 没有内存分配分析 无法在CACHE打开方式下工作 精确性随情况变化 通过仿真存储器工作 价格昂贵,纯软件测试工具,纯硬件工具 仿真器,逻辑分析仪,CodeTEST 硬件辅助软件测试工具,常见的测试工具类型划分,静态测试工具 测试脚本工具(TCL、Python) 覆盖率检测工具 内存泄漏检测工具 性能压力测试工具,传统测试流程出现的问题,开发进度 (已实现比例),项目进度,100,开始集成,设计缺陷导致返工,计划发布日期,实际发布日期,项目进度难以控

13、制 项目风险控制能力弱 40精力发费在集成和测试上,渐增测试模型,模块设计,编码模块测试每日构建,系统联调 与集成,原型机测试,模块级 (MUTMITMST),系统级,V模型,传统开发测试模型,制定产品测试策略,定义产品可测试性需求,制定产品测试计划,产品测试需求分析,制定产品测试方案,测试用例设计,自动测试设计与开发,设计需求和规格定义,BUILD划分,模块设计、实现、验证、每日构建、持续集成,系统测试、BETA测试,入网、准入测试,MSF开发测试模型,TDD开发测试模式,TDD:Test-Driven Development,版本转测试流程,我负责提供转测试材料,我负责和测试接口,保证转测

14、试材料的完备性,我负责监督转测试流程的正确执行,我负责验收转测试所需要材料,如果不完备,对不起,我不接,设计文档 运行代码 测试建议 ,CMO,TM,R&D,测试在分级计划体系的位置,项目经理,市场,硬件,软件,测试,制造,服务,主控板项目组,背板项目组,电源板项目组,界面项目组,数据库项目组,协议项目组,一周,二周,三周,四周,一级计划 (产品级),二级计划 (职能领域级),三级计划 (项目模块级),周计划 (员工个人级),提示,青铜器RDM1000研发管理系统 全面实现分层计划管理体系,通过计划将研发、采购、制造、市场等各个职能领域的工作有效协同,测试通过和失败的标准,测试通过和失败的标准是测试活动结束的依据 系统测试通过/失败标准举例: 达到100%需求覆盖 没有遗留致命问题,严重问题有相应的规避手段 所有1、2级测试用例全部执行,3、4级执行70%以上 ,测试挂起和恢复的标准,系统测试挂起标准举例: 基本业务测试不通过 最小接受测试项目有10以上没有通过 出现致命问题导致30用例被堵塞,测试无法进行 系统测试恢复条件举例: 导致测试堵塞的问题被修复,并通过回归测试 ,

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 生活休闲 > 社会民生

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号