敏捷开发测试规范V0.1VIP免费

1敏捷开发测试规范（试行）2012年9月版本记录版日期修改描述2本号人■0.1V2012/9周本V0.1目录1概述31.1编写目的31.2读者对象31.3术语定义32敏捷测试流程42.1验证需求和设计42.2用例设计与审核42.3测试计划42.4测试实施运行52.6版本控制52.7需求变更62.8迭代末期“bug大扫除”73敏捷测试方法与策略73.1持续测试、持续反馈73.2单元测试方法策略73.3功能测试方法策略83.4性能测试方法83.5系统测试策略93.6测试驱动研发103.7持续集成测试104移动互联网终端测试114.1用户体验测试114.2平台兼容性测试124.3不同网络环境下测试124.4多事务并发测试124.5安装、卸载测试134.6安全性、接口测试135测试工具和环境135.1单元测试工具145.2功能回归测试工具145.3性能测试工具145.4持续集成测试环境146测试人员要求146.1人力需求146.2测试人员能力要求157附录1631概述1.1编写目的ICT自主开发产品拟采用敏捷开发模式，为规范ICT支撑中心项目敏捷测试流程，明确敏捷开发模式下的术语定义，明确敏捷测试方法与策略，明确移动互联网测试特有的测试内容，确定敏捷开发模式下用到的测试工具以及测试环境，以及初步确定敏捷测试人力需求计算方式与对人员能力要求，特制定本规范。本规范适用于采用敏捷开发模式下的所有自主开发移动互联网产品。1.2读者对象本规范读者对象为软件开发项目管理者、项目经理、测试经理、开发经理、开发组、测试组所有人员。1.3术语定义敏捷开发模式下的几种重要角色、产品文档及过程会议术语如表1-1：术语中文说明ProductOwne产品所相当于项目经理、产品经理、产品负责人。(PO)有者产品用户故事编写负责人。ScrumMaster敏捷开组织项目敏捷开发，负责协调、沟通、协(SM)发组织者助解决团队内部非技术问题。ProductBacklog产品需求产品待开发的功能项（用户需求）SprintBacklog迭代需求每个迭代需实现的功能项（产品需求细化）Userstory用户故事从用户角度提出的需求Burndownchart燃尽图产品需求、迭代需求完成的进度显示图PlanMeeting计划会迭代计划会，组织讨论下个迭代开发内容，PO需参加讲解产品需求。Standup每日立每日立会，早上时间，主要讨论每人当天Meeting会工作内容。Review迭代评每个迭代结束时召开，展示迭代成果，听Meeting审会取PO意见、建议。表1-142敏捷测试流程2.1验证需求和设计敏捷测试强调问题暴露越早越好。需求和设计具体来说一般包括：（1）由项目经理根据需求文本而编写的产品用户故事或者是产品软件需求规格说明书；（2）由开发人员根据产品用户故事而编写的迭代用户故事，或者是详细设计、数据库设计、系统方案设计、概要设计（可裁剪，根据开发系统规模决定是否裁剪。）。作为测试人员，审核重点是检查产品用户故事、迭代用户故事对用户需求定义的完整性、严密性和功能设计的可测性。在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。更多的参与DBDesign（数据库设计），框架的评审中来。积极地参与前期工作，尽早的开始测试，并迅速反馈给设计和开发其静态测试结果。需求和设计验证产出物:测试需要提交评审结果。2.2用例设计与审核开发人员根据产品用户故事、迭代用户故事，设计测试用例，测试人员负责测试用例审核。为保证测试用例的质量和可行性，确保测试工作的顺利进行，让开发人员、测试人员迅速地了解测试的重点并给出相应的意见和建议，用例设计人员在出输出测试用例的同时，应出一份用户故事与用例跟踪表（见附件：产品故事-燃尽图跟踪表，，其中注明测试用例已覆盖了哪些用户故事，具体每个用户故事对应的测试用例编号，这样其他项目组成员对测试用例进行查看的时候，能够对测试用例的覆盖率一目了然，对覆盖率不足（如某个重点用户故事的测试用例覆盖不够，的地方能够及时给出意见。测试人员负责用例审核。2.3测试计划敏捷测试的测试计划不需要复杂的计划文档，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来即可，模板见附件。52.4测试实施运行敏捷开发模式中，测试与研发...