Requirement Driven Testing需求驱动开发；包括doors工具.pptVIP

Requirement Driven Testing需求驱动测试 将ALM方案引入测试活动 涉及角色 角色如下 管理层(各位manager) Analyst-系统工程师/需求分析师(DOORS user) QA/Test - 测试人员 (some testing management tool’s user) Developer - 开发人员 (SYNERGY user) 角色: 系统工程师 系统工程师参与大量需求管理的工作 指明测试时必须被满足的达标标准(Qualification Criteria) 帮助测试人员,如review测试计划和测试用例 需要知道需求被测试的状况 碰到需求变更时,影响力评估分析须要包括需求工作和测试工作 角色: 测试人员 测试人员主要参与测试的管理和执行 帮助系统工程师写出更好的需求 使用测试达标标准(Qualification Criteria)作为测试的关键信息 确保测试的完备性: 建立测试用例到需求的追踪关系 测试失败调查 角色: 管理人员 高层的管理人员需要及时、准确、可靠的报告 测试经理 保证测试组是基于需求来进行有效的测试活动的 开发经理 根据测试的结果衡量开发活动的成绩 市场/发布/需求部经理 根据需求被满足的程度报告相关的发布版本会有怎样的市场后果(Business Impact) DOORS如何帮助测试活动？ 保证需求和测试的可追踪性 DOORS作为一个通用的存储平台 市场上有专用的测试管理平台 使用DOORS还是专用的工具? Test Support Options 客户在DOORS中建立自己的测试管理平台 Boeing/NASA Rolls Royce Japanese Aerospace eXploration Agency (JAXA) 本地客户(an outsourcing prospect, CMM level 4) The DOORS Test Tracking Toolkit (T3) A native DOORS toolkit (available # Mercury TestDirector LoadRunner Automation of Formal System Test Process 客户: NASA/Boeing 地点: Kennedy Space Center, Florida 时间: Telelogic Americas 2002 User Group Conference 特点： 客户自己收集需求，进行开发和测试 无外包 需求驱动的自动化测试 系统包含软件、硬件 原始测试流程 Word形式的文档，没有需求追踪 测试之前将文档打印出来(Hard Copy) 测试之后将测试结果标记在对应的测试条目后面(Hard Copy) 基于测试结果进行手工的质量分析 每次发布前需要总结40+份Software Requirement Specification和30+份System Test Procedure 15+System Test Engineers (STE), 12+ Quality Assurance Reps (QA) and 20+ System Engineers (SE) 原来流程的问题 系统工程师(SE)没有能有效参与测试工作 手工的进行测试后的质量分析，时间长3个月(up to 3 months)并容易出错 多轮的系统测试 STE,SE和QA之间的沟通很弱 没有公共平台进行管理权限 新的测试流程 追踪关系的建立：Software Requirement Specifications, System Test Procedures: Software Requirements Verification Matrix (SW-RVM) 测试的结果收集在DOORS里 测试数据的分析直接在DOORS里面完成 分析范围： 75+份Software Requirement Specification和35+份System Test Procedure 测试的报告导出成hard copy 新流程带来的好处 需求和测试之间建立简单而动态的关系 保证测试用例的完整性 QA人员在测试结束后几个小时内就可以完成自己的工作 整体评测报告的出炉只需几天，而不是几个月 实时的监控 准确的历史数据 DOORS中正式而完毕的文档配置管理 自动收集和分析metrics 可以重复的过程 The DOORS Test Tracking Toolkit 在DOORS中管理test case 建立测试到需求的关联关系 Generate test runs automatically Compare test runs 提供基本的测试结果的度量 检