文档敏捷开发测试规范（试行）6错误!未定义书文档版本记录版本曰期修改人描述V0.12012/9周本文V0.1目录1概述1.1编写目的41.2读者对象41.3术语定义52敏捷测试流程52.1需求验证2.2用例设计2.3用例审核与维护2.4测试计划72.5测试实施运行72012年9月文档2.6版本控制82.7需求变更92.8迭代末期“bug大扫除”93敏捷测试方法与策略103.1持续测试、持续反馈103.2单元测试方法策略103.3功能测试方法策略113.4性能测试方法123.5系统测试策略123.6测试驱动研发133.7持续集成测试144终端移动互联网测试154.1用户体验测试154.2平台兼容性测试164.3不同网络环境下测试164.4多事务并发测试174.5安装、卸载测试175测试工具和环境185.1单元测试工具185.2功能回归测试工具195.3性能测试工具195.4持续集成测试环境196测试人员要求196.1人力需求19文档6.2测试人员能力要求207附录211概述1.1编写目的ICT自主开发产品拟采用敏捷开发模式，为规范ICT支撑中心项目敏捷测试流程，明确敏捷开发模式下的术语定义，明确敏捷测试方法与策略，明确移动互联网测试特有的测试内容，确定敏捷开发模式下用到的测试工具以及测试环境，以及初步确定敏捷测试人力需求计算方式与对人员能力要求，特制定本规范。本规范适用于采用敏捷开发模式下的所有自主开发移动互联网产品。1.2读者对象本规范读者对象为软件开发项目管理者、项目经理、测试经理、开发经理、开发组、测文档试组所有人员。1.3术语定义敏捷开发模式下的几种重要角色、产品文档及过程会议术语如表1-1：术语中文说明ProductOwner(PO)产品所有者相当于项目经理、产品经理、产品负责人。产品用户古攵事编写负责人。ScrumMaster(SM)敏捷开发组织者组织项目敏捷开发，负责协调、沟通、协助解决团队内部非技术问题。ProductBacklog产品需求产品待开发的功能项（用户需求）SprintBacklog迭代需求每个迭代需实现的功能项（产品需求细化）Userstory用户故事从用户角度提出的需求Burndownchart燃尽图产品需求、迭代需求完成的进度显示图PlanMeeting计划会迭代计划会，组织讨论下个迭代开发内容，PO需参加讲解产品需求。StandupMeeting每日立会每日立会，早上时间，主要讨论每人当天工作内容。ReviewMeeting迭代评审会每个迭代结束时召开，展示迭代成果，听取PO意见、建议。表1-12敏捷测试流程2.1验证需求和设计敏捷测试强调问题暴露越早越好。文档需求和设计具体来说一般包括：（1）由项目经理根据需求文本而编写的产品用户故事或者是产品软件需求规格说明书；（2）由开发人员根据产品用户故事而编写的迭代用户故事，或者是详细设计、数据库设计、系统方案设计、概要设计（可裁剪，根据开发系统规模决定是否裁剪。）。作为测试人员，审核重点是检查产品用户故事、迭代用户故事对用户需求定义的完整性、严密性和功能设计的可测性。在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析,设计和开发。更多的参与DBDesign（数据库设计）,框架的评审中来。积极地参与前期工作，尽早的开始测试，并迅速反馈给设计和开发其静态测试结果。需求和设计验证产出物:测试需要提交评审结果。2.2用例设计与审核开发人员根据产品用户故事、迭代用户故事，设计测试用例，测试人员负责测试用例审核。为保证测试用例的质量和可行性，确保测试工作的顺利进行，让开发人员、测试人员迅速地了解测试的重点并给出相应的意见和建议，用例设计人员在出输出测试用例的同时，应出一份用户故事与用例跟踪表（见附件：产品故事-燃尽图跟踪表），其中注明测试用例已覆盖了哪些用户故事，具体每个用户故事对应的测试用例编号，这样其他项目组成员对测试用例进行查看的时候，能够对测试用例的覆盖率一目了然，对覆盖率不足（如某个重点用户故事的测试用例覆盖不够）的地方能够及时给出意见。测试人员负责用例审核。2.3测试计划敏捷测试的测试计划不需要复杂的计划文档，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来即可，模板见附件。文档2.4测试实施运行敏捷...
