自动化测试用例.pptVIP

敏捷分享 敏捷背景 敏捷开发流程 敏捷实践案例 敏捷能解决那些问题 敏捷带来的挑战 敏捷实践误区 讨论 敏捷背景 回顾传统的CMMI流程 为什么我们要采用敏捷模式？ 在传统的CMMI流程项目中需求变更、人员技能提升、提高客户满意度都面临挑战，CMMI项目强调机械化流程、人员可替代、项目笨拙、周期长、需求变更影响大、无法快速响应客户业务要求，面对这些问题，敏捷模式提供了很好的解决方法。 敏捷开发流程 迭代前准备 迭代0 迭代1 SDV 迭代N SDV 下一迭代 团队组建 办公场地 敏捷培训 工具培训 持续集成 权限申请 开发环境 STORY输出 迭代计划 开工会 规格评审 STORY认领 及估计 . . . 单个STORY开发流程: STORY澄清 会议 ALL 开发 测试 资料 测试点AT 简单设计文档 资料编写 ST测试 细化用例 CODE Show Case 开始 执行测试用例 用例加入CI 结束 集成测试 需求评审 用例评审 串串烧 回顾会议 验收测试 跟下一个 迭代并行 验 收 测 试 敏捷实践案例 敏捷实践之一 每日晨会 敏捷实践之二 结对开发 敏捷实践之三 持续集成 敏捷实践之四 多次迭代 敏捷实践之五 User Story 敏捷实践之六 状态墙 敏捷实践之七 串串烧 敏捷实践之八 SHOW CASE 敏捷实践之九 迭代回顾会议 敏捷实践之十 一体化团队 敏捷实践之一 每日晨会 晨会又称站立会议，我们每天早上9点准时进行晨会。会议由项目成员轮流组织。 要求所有成员在会前做准备，围绕状态墙上的STORY反馈昨天做了哪些工作？ STORY的进度如何？质量如何？ 今天要做哪些工作？有什么困难？ 每个人发言控制在30秒左右。所有人发言完后，PM进行简单总结，敏捷教练也会提出指导意见。晨会完后PM将成员提出的困难汇总，并协调解决。 PM在发言时尽量不要用命令式的口吻，在项目组内营造平等、和谐氛围,强调大家的自我管理能力。 发言的顺序按STORY划分，先由STORY负责人介绍STORY的整体情况（质量进度困难），再由STORY的开发、测试、资料进行发言。这样大家可以对一个STORY情况完整的了解。 敏捷实践之二 结对开发 结对的对策： 要区分哪些STORY或模块需要结对，哪些不需要，原则是一些比较复杂的STORY我们采取结对。 由于我们新员工较多，所以我们采用以老带新的结对模式。 结对实施: 从STORY分析、方案设计、编码、测试连吃饭也在一起（引导一组人要一起去吃饭），通过这种频繁的交流让新员工能够充分吸收养氛，使他们能够快速成长，让我们团队的家底厚实一些。 结对结果： 通过这种结对方式我们的新员工能够快速成长起来，能独立胜任一些STORY的开发工作。强弱结对在培养新员工方面优势明显，但是在质量和效率方面不及强强结对有优势。 结对目标 通过三、四个迭代让团队所有人都成为团队骨干，有更多人可以进行强强结对，为我们项目质量保驾护航。 敏捷实践之三 持续集成 持续集成是敏捷项目的基础，首先需要一台独立PC服务器做持续集成服务器，然后根据项目情况制定持续集成管理。 我们的策略： 支持自动编译、自动部署、执行自动化测试用例、进行静态检查并及时向相关人反馈编译、静态检查、自动化测试用例的执行结果； 代码和自动化用例要测试OK才能提交到配置库； 建立纪律：设定了CI协调员，如果有问题负责协调相关人及时解决问题； 自动化用例覆盖率要达到90%； 关于历史欠债问题：用静态检查会发现大量FINDBUG、PCLINT、复杂度问题。由于交付压力，我们策略是保证新增代码不增加问题数和复杂度。做清理计划，优先解决问题级别高的问题。 持续集成的期望：持续集成能帮我们做ST，提交代码后就可以进行自动化测试，我们只用手工补测几个用例就可以完成测试工作。 敏捷实践之四 多次迭代 迭代的意义在迎接需求变化，将一个长周期的项目分成若干个迭代开发并进行发布，来满足经常性发布用户可用的版本。 迭代计划制定 由SE、PM、项目骨干参加，从需求列表中按有价值、风险、稳定、复杂、紧急进行排序，把排在前面的需求放在当前迭代来做。 认领STORY 确定STORY责任人，估计工作量（开发和测试），合理安排计划和人力。 迭代计划时间计划 一个迭代周期设定为5周，前4周进行STORY开发，后一周进行SDV测试。 在STORY开发阶段，可以将4周分为4个阶段，每周完成一些STORY尽可能减少进度风险。 根据估计的工作量和迭代周期，调整需求列表。 敏捷实践之五 User Story Story计划列表 显示Story优先级、 Story名称