敏捷软件测试ppt课件.ppt

1、敏捷测试（敏捷测试（Agile Testing） 敏捷宣言 个体和交互胜过流程和工具 可用的软件胜过完备的文档 客户协作胜过合同谈判 响应变化胜过遵循计划敏捷方法 Scrum Crystal 极限编程（XP） 动态系统开发方法（DSDM） 特征驱动开发（FDD） 测试驱动开发（TDD）XP(极限编程)FDD (特征驱动开发)Scrum特点 敏捷的流程，可用于管控研发工作 现有设计流程的总结 以团队为基础，是一种在需求迅速变化情况下迭代的、增量的开发系统和产品的方法 控制由利益和需求冲突导致混乱的流程 改善交流、协调合作的最优方式 检测产品开发和生产过程中障碍并将其去除的方式 最大化生产率的一种

2、方法 适用于单一的项目到整个组织。Scrum可以控制并组织多件具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。 让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。 Sprint（迭代）Scrum的项目过程由一系列的Sprint组成Sprint的长度一般控制在24周通过固定的周期保持良好的节奏产品的设计、开发、测试都在Sprint期间完成Sprint结束时交付可以工作的软件在Sprint过程中不允许发生变更DSDM(动态系统开发方法) 九大原则 用户必须持续参与 必须授予DSDM团队制定决策的权利 注重产品的经常交付 满足业务用户用途是接受交付品

3、的主要依据 迭代和增量式开发对得到正确的业务解决方案是必不可少的 开发过程的所有变化可逆 在高层次上制定需求的基线 测试自始至终贯穿于开发周期之中 所有项目涉众间的通力合作是不可获缺的适合DSDM的应用 交互式、功能通过用户界面体现 有清晰的用户群 没有复杂计算 如果是大型应用，可以分解成小的功能部件 有时间限制 需求不清楚或不确定TDD(测试驱动开发) TDD得原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。 TDD得基本思路就是通过测试来推动整个开发得进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。 优点：在任意一个

4、开发节点都可以拿出一个可以使用，含少量bug并具一定功能的产品。 缺点：增加代码量。测试代码是系统代码的两倍或更多。TDD的名言名句 以动手实践为荣，以只看不练为耻。 以打印日志为荣，以单步跟踪为耻。 以空格缩进为荣，以制表缩进为耻。 以单元测试为荣，以人工测试为耻。 以模块复用为荣，以复制粘贴为耻。 以多态应用为荣，以分支判断为耻。 以pythonic为荣，以冗余拖沓为耻。 以总结分享为荣，以跪求其解为耻敏捷测试敏捷测试是指在采用敏捷技术的项目中开展的测试以任务为导向，而不以过程或是角色为导向通过沟通和反馈保证测试能够建立合适的质量标准 尽可能减少测试周期的时间需求敏捷团队与敏捷测试人员 客

5、户团队：由业务专家、产品经理、业务人员的产品负责人、测试人员等组成。 开发团队：有程序员、测试人员、架构师、系统管理员、数据库管理员、技术文档编写人员、安全专家等组成； 测试人员既属于客户团队又属于开发团队，既要了解客户的观点又要了解技术实现的复杂性。敏捷测试人员法则 提供持续反馈 为客户创造价值 进行面对面的沟通 勇气 简单化 持续改进 响应变化 自我组织 关注人 享受乐趣传统测试 vs. 敏捷测试传统到敏捷的挑战 质量哲学 整体团队负责质量 技能和适应能力 合适的节奏 客户关系 组织规模 沟通挑战 组织内的文化冲突 提前计划 授权团队敏捷团队结构 独立的质量保证团队 把测试人员整合到敏捷项

6、目 敏捷项目团队敏捷测试的四个象限敏捷测试的目的 管理技术债务（Ward Cunningham，1992） 象限担任了保持技术债务在一个可管理的水平的角色 上下文环境中的测试 任何实践的价值依赖于其上下文环境 存在上下文环境中的优秀的实践，但是没有最好的实践 人们共同工作是任何项目的上下文环境的最重要部分 项目随着时间以通常不能预测的方式发展 产品是一个解决方案，如果没有解决问题，那么产品是不能运转的 出色的软件测试是一个有挑战性的智力过程 只有通过判断和技巧，在整个项目中合作实践，才可以在正确的时间做正确的事情，有效地测试我们的产品使用TDD的原因 效率更高 让测试人员的工作更容易 设计时谨

7、记测试 即时反馈 工具箱 源代码控制 IDE（集成开发环境） 构建自动化工具（持续集成是敏捷团队的核心实践） 单元测试工具（Java的Junit）自动化测试 功能测试结构（Ruby with Watir） Web服务(IRB) 嵌入式测试(FXRuby)自动化测试原因 手动测试需要太长的时间 手动过程容易出错 自动化让人们有时间做更有价值的工作 自动化的回归测试提供了安全网 自动化测试能较早且频繁地提供反馈 驱动编码的测试和实例可以做更多的事情 测试提供文档 自动化的投资回报率高妨碍自动化的因素 程序员的态度 “痛苦的积累” 初期投入 总在变化的代码 遗留系统 恐惧 旧的习惯哪些测试可以自动化

8、 持续集成、构建和部署 单元与组件测试 API或WEB Services测试 GUI底层的测试 测试GUI 负载测试 比较 重复的任务 创建数据GUI测试验收测试（API层面）单元测试/组件测试测试人员在发布或主题计划阶段的工作 制定发布计划的目的 评估工作量如何评估故事测试人员在其中的角色一个示例（产品负责人与测试人员的沟通） 设定优先级为何要设定优先级需要考虑的测试情况 测试范围最后期限和时间表关注产品价值系统范围的影响第三方的介入 制定测试计划从何处开始为何要制定测试计划测试的种类测试基础设施测试环境测试数据测试结果 可选的测试计划形式轻量级测试计划测试矩阵电子表格白板自动化测试列表 注意可见性测试任务追踪测试结果交流发布矩阵总结：关键成功因素使用团队整体参与的方法采用敏捷测试思维自动化回归测试提供并获取反馈与客户合作保持大局观构建核心实践的基础持续集成测试环境管理技术债务增量工作编码和测试是同一个过程的组成部分实践之间的协作