敏捷软件测试.pptVIP

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