文档介绍：敏捷开发测试规范(试行) 3编写目的 3读者对象 3术语定义 32敏捷测试流程 3需求验证 3用例设计 3用例审核与维护 3测试计划 3测试实施运行 4版本控制 4需求变更 5迭代末期“bug大扫除” 53敏捷测试方法与策略 5持续测试、持续反馈 5单元测试方法策略 5功能测试方法策略 5性能测试方法 6系统测试策略 6测试驱动研发 7持续集成测试 74终端移动互联网测试 7用户体验测试 7平台兼容性测试 7不同网络环境下测试 8多事务并发测试 8安装、卸载测试 85测试工具和环境 8单元测试工具 8功能回归测试工具 8性能测试工具 9持续集成测试环境 96测试人员要求 9人力需求 9测试人员能力要求 97附录 111概述编写目的 ICT自主开发产品拟采用敏捷开发模式,为规范ICT支撑中心项目敏捷测试流程,明确敏捷开发模式下的术语定义,明确敏捷测试方法与策略,明确移动互联网测试特有的测试内容,确定敏捷开发模式下用到的测试工具以及测试环境,以及初步确定敏捷测试人力需求计算方式与对人员能力要求,特制定本规范。本规范适用于采用敏捷开发模式下的所有自主开发移动互联网产品。读者对象本规范读者对象为软件开发项目管理者、项目经理、测试经理、开发经理、开发组、测试组所有人员。术语定义敏捷开发模式下的几种重要角色、产品文档及过程会议术语如表1-1:术语中文说明ProductOwner(PO)产品所有者相当于项目经理、产品经理、产品负责人。产品用户故事编写负责人。ScrumMaster(SM)敏捷开发组织者组织项目敏捷开发,负责协调、沟通、协助解决团队内部非技术问题。ProductBacklog产品需求产品待开发的功能项(用户需求)SprintBacklog迭代需求每个迭代需实现的功能项(产品需求细化)Userstory用户故事从用户角度提出的需求Burndownchart燃尽图产品需求、迭代需求完成的进度显示图PlanMeeting计划会迭代计划会,组织讨论下个迭代开发内容,PO需参加讲解产品需求。StandupMeeting每日立会每日立会,早上时间,主要讨论每人当天工作内容。ReviewMeeting迭代评审会每个迭代结束时召开,展示迭代成果,听取PO意见、建议。表1-12敏捷测试流程验证需求和设计敏捷测试强调问题暴露越早越好。需求和设计具体来说一般包括:(1)由项目经理根据需求文本而编写的产品用户故事或者是产品软件需求规格说明书;(2)由开发人员根据产品用户故事而编写的迭代用户故事,或者是详细设计、数据库设计、系统方案设计、概要设计(可裁剪,根据开发系统规模决定是否裁剪。)。作为测试人员,审核重点是检查产品用户故事、迭代用户故事对用户需求定义的完整性、严密性和功能设计的可测性。在测试初期,测试人员要学会做静态测试,做好需求分析,做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性,将自身作为第一用户积极参与项目和系统的需求分析,设计和开发。更多的参与DBDesign(数据库设计),框架的评审中来。积极地参与前期工作,尽早的开始测试,并迅速反馈给设计和开发其静态测试结果。需求和设计验证产出物:测试需要提交评审结果。用例设计与审核开发人员根据产品用户故事、迭代用户故事,设计测试用例,测试人员负责测试用例审核。为保证测试用例的质量和可行性,确保测试工作的顺利进行,让开发人员、测试人员迅速地了解测试的重点并给出相应的意见和建议,用例设计人员在出输出测试用例的同时,应出一份用户故事与用例跟踪表(见附件:产品故事-燃尽图跟踪表),其中注明测试用例已覆盖了哪些用户故事,具体每个用户故事对应的测试用例编号,这样其它项目组成员对测试用例进行查看的时候,能够对测试用例的覆盖率一目了然,对覆盖率不足(如某个重点用户故事的测试用例覆盖不够)的地方能够及时给出意见。测试人员负责用例审核。测试计划敏捷测试的测试计划不需要复杂的计划文档,写出一页纸的测试计划,将测试要点(包括策略、特定方法、重点范围等)列出来即可,模板见附件。测试实施运行敏捷开发模式中,测试与研发紧密结合在一起。测试主要有两种:单元测试和验证/接收测试。单元测试一般是由开发人员来完成的,接收测试是由客户代表来完成。由于客户通常无法在现场,一般由测试人员做验证测试,最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试,发布版本之后由客户做接收测试,提出需要修改的地方。需要修改的地方将在下后面的迭代中完成。·单元测试在每日构件版本给测试前,开发首先要做单元测试,提前告知软件中的薄弱环节,帮助测试人员调整测试重点。做单元测试的好处是能够提高版本质量,减轻测试的工作量,减少浅层次的bug的发生率