敏捷软件测试ppt课件

DSDM(动态系统开发方法)
九大原则 • 用户必须持续参与 • 必须授予DSDM团队制定决策的权利 • 注重产品的经常交付 • 满足业务用户用途是接受交付品的主要依据 • 迭代和增量式开发对得到正确的业务解决方案是必不可少
的 • 开发过程的所有变化可逆 • 在高层次上制定需求的基线 • 测试自始至终贯穿于开发周期之中 • 所有项目涉众间的通力合作是不可获缺的
象限担任了保持技术债务在一个可管理的水平的角色
• 上下文环境中的测试
➢ 任何实践的价值依赖于其上下文环境 ➢ 存在上下文环境中的优秀的实践，但是没有最好的实践 ➢ 人们共同工作是任何项目的上下文环境的最重要部分 ➢ 项目随着时间以通常不能预测的方式发展 ➢ 产品是一个解决方案，如果没有解决问题，那么产品是不能运转的 ➢ 出色的软件测试是一个有挑战性的智力过程 ➢ 只有通过判断和技巧，在整个项目中合作实践，才可以在正确的时间
XP(极限编程)
FDD (特征驱动开发)
Scrum特点
• 敏捷的流程，可用于管控研发工作 • 现有设计流程的总结 • 以团队为基础，是一种在需求迅速变化情况下迭代的、增
量的开发系统和产品的方法 • 控制由利益和需求冲突导致混乱的流程 • 改善交流、协调合作的最优方式 • 检测产品开发和生产过程中障碍并将其去除的方式 • 最大化生产率的一种方法 • 适用于单一的项目到整个组织。Scrum可以控制并组织多
• 质量哲学 • 整体团队负责质量 • 技能和适应能力 • 合适的节奏 • 客户关系 • 组织规模 • 沟通挑战 • 组织内的文化冲突 • 提前计划 • 授权团队
敏捷团队结构
• 独立的质量保证团队 • 把测试人员整合到敏捷项目 • 敏捷项目团队
敏捷测试的四个象限
敏捷测试的目的
• 管理技术债务（Ward Cunningham，1992）
件具有相关性的产品开发以及拥有超过千名开发者和执行 者的项目实施过程。 • 让每个参与者都对自己所做的工作以及自己做出的贡献感 到骄傲，并让他们发挥到最佳水平。
Sprint（迭代） • Scrum的项目过程由一系列的Sprint组成 • Sprint的长度一般控制在2~4周 • 通过固定的周期保持良好的节奏 • 产品的设计、开发、测试都在Sprint期间完成 • Sprint结束时交付可以工作的软件 • 在Sprint过程中不允许发生变更
适合DSDM的应用
• 交互式、功能通过用户界面体现 • 有清晰的用户群 • 没有复杂计算 • 如果是大型应用，可以分解成小的功能部件 • 有时间限制 • 需求不清楚或不确定
TDD(测试驱动开发)
• TDD得原理是在开发功能代码之前，先编写单元测试用例 代码，测试代码确定需要编写什么产品代码。
• TDD得基本思路就是通过测试来推动整个开发得进行，但 测试驱动开发并不只是单纯的测试工作，而是把需求分析， 设计，质量控制量化的过程。
哪些测试可以自动化
• 持续集成、构建和部署 • 单元与组件测试 • API或WEB Services测试 • GUI底层的测试 • 测试GUI • 负载测试 • 比较 • 重复的任务 • 创建数据
GUI测试 验收测试（API层面）
单元测试/组件测试
测试人员在发布或主题计划阶段的工作
➢ 制定发布计划的目的 ➢ 评估工作量
• 测试人员既属于客户团队又属于开发团队，既要了解客户 的观点又要了解技术实现的复杂性。
敏捷测试人员法则
• 提供持续反馈 • 为客户创造价值 • 进行面对面的沟通 • 勇气 • 简单化 • 持续改进 • 响应变化 • 自我组织 • 关注人 • 享受乐趣
ห้องสมุดไป่ตู้
传统测试 vs. 敏捷测试
传统到敏捷的挑战
自动化测试原因
• 手动测试需要太长的时间 • 手动过程容易出错 • 自动化让人们有时间做更有价值的工作 • 自动化的回归测试提供了安全网 • 自动化测试能较早且频繁地提供反馈 • 驱动编码的测试和实例可以做更多的事情 • 测试提供文档 • 自动化的投资回报率高
妨碍自动化的因素
• 程序员的态度 • “痛苦的积累” • 初期投入 • 总在变化的代码 • 遗留系统 • 恐惧 • 旧的习惯
敏捷测试（Agile Testing）
敏捷宣言
• 个体和交互胜过流程和工具 • 可用的软件胜过完备的文档 • 客户协作胜过合同谈判 • 响应变化胜过遵循计划
敏捷方法
• Scrum • Crystal • 极限编程（XP） • 动态系统开发方法（DSDM） • 特征驱动开发（FDD） • 测试驱动开发（TDD）
做正确的事情，有效地测试我们的产品
使用TDD的原因
• 效率更高 • 让测试人员的工作更容易 • 设计时谨记测试 • 即时反馈
工具箱
• 源代码控制 • IDE（集成开发环境） • 构建自动化工具（持续集成是敏捷团队的核心实践） • 单元测试工具（Java的Junit）
自动化测试
• 功能测试结构（Ruby with Watir） • Web服务(IRB) • 嵌入式测试(FXRuby)
敏捷测试
• 敏捷测试是指在采用敏捷技术的项目中开展的测试 • 以任务为导向，而不以过程或是角色为导向 • 通过沟通和反馈保证测试能够建立合适的质量标准 • 尽可能减少测试周期的时间需求
敏捷团队与敏捷测试人员
• 客户团队：由业务专家、产品经理、业务人员的产品负责 人、测试人员等组成。
• 开发团队：有程序员、测试人员、架构师、系统管理员、 数据库管理员、技术文档编写人员、安全专家等组成；
• 优点：在任意一个开发节点都可以拿出一个可以使用，含 少量bug并具一定功能的产品。
• 缺点：增加代码量。测试代码是系统代码的两倍或更多。
TDD的名言名句
• 以动手实践为荣，以只看不练为耻。 • 以打印日志为荣，以单步跟踪为耻。 • 以空格缩进为荣，以制表缩进为耻。 • 以单元测试为荣，以人工测试为耻。 • 以模块复用为荣，以复制粘贴为耻。 • 以多态应用为荣，以分支判断为耻。 • 以pythonic为荣，以冗余拖沓为耻。 • 以总结分享为荣，以跪求其解为耻
• 如何评估故事 • 测试人员在其中的角色 • 一个示例（产品负责人与测试人员的沟通）