敏捷开发测试要求规范v0.1

《敏捷开发测试要求规范v0.1》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、实用标准敏捷开发测试规范（试行）2012年9月版本记录版本号日期修改人描述V0.12012/9周本文V0.1文档实用标准目录1概述31.1编写目的31.2读者对象31.3术语定义32敏捷测试流程32.1需求验证32.2用例设计32.3用例审核与维护32.4测试计划32.5测试实施运行42.6版本控制42.7需求变更52.8迭代末期“bug大扫除”53敏捷测试方法与策略53.1持续测试、持续反馈53.2单元测试方法策略53.3功能测试方法策略53.4性能测试方法63.5系统测试策略63.6测试驱动研发73.7持续集成

2、测试74终端移动互联网测试74.1用户体验测试74.2平台兼容性测试74.3不同网络环境下测试84.4多事务并发测试84.5安装、卸载测试85测试工具和环境85.1单元测试工具85.2功能回归测试工具85.3性能测试工具95.4持续集成测试环境96测试人员要求96.1人力需求96.2测试人员能力要求97附录11文档实用标准1概述1.1编写目的ICT自主开发产品拟采用敏捷开发模式，为规范ICT支撑中心项目敏捷测试流程，明确敏捷开发模式下的术语定义，明确敏捷测试方法与策略，明确移动互联网测试特有的测试内容，确定敏捷开发

3、模式下用到的测试工具以及测试环境，以及初步确定敏捷测试人力需求计算方式与对人员能力要求，特制定本规范。本规范适用于采用敏捷开发模式下的所有自主开发移动互联网产品。1.2读者对象本规范读者对象为软件开发项目管理者、项目经理、测试经理、开发经理、开发组、测试组所有人员。1.3术语定义敏捷开发模式下的几种重要角色、产品文档及过程会议术语如表1-1：术语中文说明ProductOwner（PO）产品所有者相当于项目经理、产品经理、产品负责人。产品用户故事编写负责人。ScrumMaster（SM）敏捷开发组织者组织项目敏捷开发

4、，负责协调、沟通、协助解决团队内部非技术问题。ProductBacklog产品需求产品待开发的功能项（用户需求）SprintBacklog迭代需求每个迭代需实现的功能项（产品需求细化）Userstory用户故事从用户角度提出的需求Burndownchart燃尽图产品需求、迭代需求完成的进度显示图PlanMeeting计划会迭代计划会，组织讨论下个迭代开发内容，PO需参加讲解产品需求。StandupMeeting每日立会每日立会，早上时间，主要讨论每人当天工作内容。ReviewMeeting迭代评审会每个迭代结束时召

5、开，展示迭代成果，听取PO意见、建议。表1-12敏捷测试流程文档实用标准2.1验证需求和设计敏捷测试强调问题暴露越早越好。需求和设计具体来说一般包括：（1）由项目经理根据需求文本而编写的产品用户故事或者是产品软件需求规格说明书；（2）由开发人员根据产品用户故事而编写的迭代用户故事，或者是详细设计、数据库设计、系统方案设计、概要设计（可裁剪，根据开发系统规模决定是否裁剪。）。作为测试人员，审核重点是检查产品用户故事、迭代用户故事对用户需求定义的完整性、严密性和功能设计的可测性。在测试初期，测试人员要学会做静态测试，做

6、好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。更多的参与DBDesign（数据库设计），框架的评审中来。积极地参与前期工作，尽早的开始测试，并迅速反馈给设计和开发其静态测试结果。需求和设计验证产出物:测试需要提交评审结果。2.2用例设计与审核开发人员根据产品用户故事、迭代用户故事，设计测试用例，测试人员负责测试用例审核。为保证测试用例的质量和可行性，确保测试工作的顺利进行，让开发人员、测试人员迅速地了解测试的重点并给出相应的意见和建

7、议，用例设计人员在出输出测试用例的同时，应出一份用户故事与用例跟踪表（见附件：产品故事-燃尽图跟踪表），其中注明测试用例已覆盖了哪些用户故事，具体每个用户故事对应的测试用例编号，这样其他项目组成员对测试用例进行查看的时候，能够对测试用例的覆盖率一目了然，对覆盖率不足（如某个重点用户故事的测试用例覆盖不够）的地方能够及时给出意见。测试人员负责用例审核。2.3测试计划敏捷测试的测试计划不需要复杂的计划文档，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来即可，模板见附件。2.4测试实施运行文档实

8、用标准敏捷开发模式中，测试与研发紧密结合在一起。测试主要有两种：单元测试和验证/接收测试。单元测试一般是由开发人员来完成的，接收测试是由客户代表来完成。　　由于客户通常无法在现场，一般由测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下后面的迭代中