Duannian agile

636 views
579 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
636
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Duannian agile

  1. 1. 敏捷测试实践 段念 www.qconbeijing.com
  2. 2. 什么是我们谈论的敏捷测试?
  3. 3. <ul><li>Agile testing is a software testing practice that follows the principles of the agile manifesto , emphasizing testing from the perspective of customers who will utilize the system. </li></ul><ul><li>Agile testing does not emphasize rigidly defined testing procedures , but rather focuses on testing iteratively against newly developed code until quality is achieved from an end customer's perspective. </li></ul><ul><li>In other words, the emphasis is shifted from &quot;testers as quality police&quot; to something more like &quot;entire project team working toward demonstrable quality.&quot; </li></ul><ul><li>-- 来自 wikepedia </li></ul>
  4. 4. 敏捷测试 <ul><li>简而言之,敏捷测试是指在采用敏捷技术的项目中开展的测试 </li></ul><ul><li>同时,敏捷测试也意味着测试遵循敏捷的基本原则,接纳敏捷的核心价值观 (交流,简单,反馈,勇气) </li></ul><ul><ul><li>保持 简单 </li></ul></ul><ul><ul><li>以 任务 为导向,而不以过程或是角色为导向 </li></ul></ul><ul><ul><li>通过 沟通和反馈 保证测试能够建立合适的质量标准 </li></ul></ul><ul><ul><li>尽可能 减少测试周期的时间需求 </li></ul></ul><ul><li>敏捷测试要求“ 交付可用产品 ”而非单纯的“ 发现缺陷 ” </li></ul>
  5. 5. 敏捷测试 vs. 传统意义上的测试
  6. 6. 敏捷测试 带来的挑战(一) <ul><li>质量文化上的挑战 </li></ul><ul><ul><li>发现缺陷 vs. 在产品中内建质量 </li></ul></ul><ul><ul><li>敏捷带来的担心:测试工程师应该做什么? </li></ul></ul><ul><ul><li>敏捷带来的担心:测试工程师能够做什么? </li></ul></ul>
  7. 7. 敏捷测试 核心价值观 <ul><li>共享质量目标 </li></ul><ul><ul><li>开发和测试团队共享同样的质量目标,当然也共享同样的质量责任,每个工程师在测试方面都同样承担任务 </li></ul></ul><ul><li>在产品中内建可测试性 </li></ul><ul><ul><li>为产品建立更好的自动化测试不仅仅依赖于测试工程师的工作,更重要的是,产品本身内建的可测试性 </li></ul></ul><ul><li>关注产品质量的提升,测试周期的缩短,而不是仅专注于发现缺陷 </li></ul>
  8. 8. 敏捷测试 中的测试工程师可以做什么 <ul><li>获取和明确用户的质量期望 </li></ul><ul><li>建立合适的系统测试、用户验收测试质量标准 </li></ul><ul><li>建立可见的质量度量体系,让产品和代码质量反馈持续可见 </li></ul><ul><li>推进单元测试、开发测试,促进代码质量 </li></ul><ul><li>建立持续构建框架 </li></ul><ul><li>建立与维护合适的自动化测试以减少测试的时间投入 </li></ul>
  9. 9. 敏捷测试带来的挑战(二) <ul><li>测试工程师面临的挑战 </li></ul><ul><ul><li>必须通过与开发团队的密切合作获取产品信息,制定测试计划而不是依赖文档 </li></ul></ul><ul><ul><li>必须密切介入开发过程,参与设计,甚至是代码 </li></ul></ul><ul><ul><li>必须能够自我驱动 </li></ul></ul><ul><ul><li>必须具有足够的自动化测试技能与探索性测试技能 </li></ul></ul>
  10. 10. 拥抱变化,改变工作方式 <ul><li>与开发工程师密切合作 </li></ul><ul><li>转变角色,测试工程师不再是“裁判”,而应该是“支持者”和“帮助产品具有更好质量的角色” </li></ul><ul><li>将测试推动到上游 </li></ul><ul><li>自我驱动,积极参与敏捷过程,主动工作而非仅仅被动接受任务 </li></ul><ul><li>提升自己的技能,尤其是自动化测试方面的技能、探索性测试能力、快速学习能力 </li></ul>
  11. 11. 敏捷测试带来的挑战(三) <ul><li>测试团队面临的挑战 </li></ul><ul><ul><li>与传统测试不同的考核标准 </li></ul></ul><ul><ul><li>与传统测试不同的人员技能要求 </li></ul></ul><ul><ul><li>与传统测试不同的测试过程管理 </li></ul></ul><ul><ul><li>与传统测试不同的团队管理方式 </li></ul></ul>
  12. 12. 建立适合敏捷测试的团队 <ul><li>建立以“质量和生产率”为核心的激励机制 </li></ul><ul><li>提升团队成员技能,招聘合适的测试工程师 </li></ul><ul><li>质量驱动,而非过程驱动 </li></ul><ul><li>在团队内形成对敏捷的认知和认可 </li></ul><ul><li>给团队成员更大的自主空间 </li></ul><ul><li>鼓励团队关于自动化测试技术 </li></ul>
  13. 13. 敏捷测试的 四个象限
  14. 14. 敏捷测试体现的与传统测试的不同 <ul><li>作用于产品( Critique product )的测试 </li></ul><ul><ul><li>探索性测试( Exploratory Testing ) </li></ul></ul><ul><ul><li>场景测试( Scenario Testing ) </li></ul></ul><ul><ul><li>用户验收测试( UAT ) </li></ul></ul><ul><ul><li>性能测试,安全性测试 </li></ul></ul><ul><ul><li>…… </li></ul></ul><ul><li>作用于支持团队( Supporting the team )的测试 </li></ul><ul><ul><li>单元测试 </li></ul></ul><ul><ul><li>模块 / 组件级别的测试 </li></ul></ul><ul><ul><li>功能测试 </li></ul></ul><ul><ul><li>用户故事( User Story )测试 </li></ul></ul><ul><ul><li>…… </li></ul></ul>
  15. 15. 敏捷测试的目标 作用于支持团队的测试 作用于产品的测试
  16. 16. 敏捷测试实践 <ul><li>There are good practices in context, but are no best practices. </li></ul><ul><li>-- 来自《 Agile T esting – A Practical Guide For Testers and Agile Teams 》 </li></ul>
  17. 17. 敏捷测试过程 <ul><li>针对一个迭代周期 </li></ul><ul><ul><li>计划一个迭代周期内的测试 </li></ul></ul><ul><ul><li>了解细节,确定测试范围 </li></ul></ul><ul><ul><li>创建并执行测试 </li></ul></ul><ul><ul><li>发布 </li></ul></ul><ul><li>敏捷测试中的持续任务 </li></ul><ul><ul><li>提高代码质量与产品质量 </li></ul></ul><ul><ul><li>从更多层面建立测试 (单元测试、模块测试、系统测试等) </li></ul></ul><ul><ul><li>建立产品的质量度量 </li></ul></ul><ul><ul><li>改进自动化测试 (更稳定,更高的覆盖率) </li></ul></ul>
  18. 18. 计划一个迭代周期内的测试 <ul><li>计划的内容 </li></ul><ul><ul><li>产品发布标准(验收测试准则) </li></ul></ul><ul><ul><li>需要在本迭代周期内测试的内容 </li></ul></ul><ul><ul><li>需要安排的测试类型 </li></ul></ul><ul><ul><li>需要使用的测试环境(包括数据) </li></ul></ul><ul><li>管理计划管理 </li></ul><ul><ul><li>一页纸测试计划( One Page Test Plan ) </li></ul></ul><ul><ul><li>可以使用各种形式表达测试计划:在线文档,测试点列表,自动测试列表,白板或是电子表格 </li></ul></ul>
  19. 20. 了解细节,确定测试范围 <ul><li>了解本次迭代的产品细节 </li></ul><ul><ul><li>有哪些新增加的功能? </li></ul></ul><ul><ul><li>开发工程师为相应的功能建立了哪些测试? </li></ul></ul><ul><ul><li>需要增加哪些验收测试? </li></ul></ul><ul><ul><li>应用的哪些部分可以通过自动化测试覆盖? </li></ul></ul><ul><ul><li>应用的哪些部分需要通过手工测试覆盖? </li></ul></ul><ul><li>确定测试范围 </li></ul><ul><ul><li>哪些部分应该被纳入回归测试内? </li></ul></ul><ul><ul><li>哪些部分需要新增加自动化测试? </li></ul></ul><ul><ul><li>哪些部分需要新增加手工测试? </li></ul></ul>
  20. 21. 用自动化手段帮助确定测试范围 <ul><li>Diff 技术 </li></ul>后端(数据) 发送请求 比较输出
  21. 22. Diff 工具 <ul><li>Diff 的作用 </li></ul><ul><ul><li>识别应用中 发生变化 的部分 </li></ul></ul><ul><ul><li>包括对接口, UI 等各层面的检查 </li></ul></ul><ul><ul><li>发生变化的部分是需要重点测试和覆盖的部分 </li></ul></ul><ul><li>不同的 Diff 方法 </li></ul><ul><ul><li>HTML diff </li></ul></ul><ul><ul><li>DOM tree diff </li></ul></ul><ul><ul><li>Image Diff </li></ul></ul><ul><ul><li>接口数据 Diff </li></ul></ul><ul><ul><li>…… </li></ul></ul>
  22. 23. 创建测试并执行 <ul><li>建立测试执行的基础架构( Test Infrastructure ) </li></ul><ul><ul><li>持续集成框架 </li></ul></ul><ul><ul><li>建立自动运行的 Sanity Check Test Suite </li></ul></ul><ul><ul><li>维护验收测试集( Accept Test Suite ) </li></ul></ul><ul><li>在一个迭代周期中创建与执行测试 </li></ul><ul><ul><li>创建各个层次的测试 </li></ul></ul><ul><ul><li>使用自动化测试框架运行测试 </li></ul></ul><ul><ul><li>使用基于脚本的手工测试与探索性测试完成对新功能,以及部分原有功能的回归测试 </li></ul></ul>
  23. 24. 敏捷测试中的测试方法 <ul><li>探索性测试:主要用于探索和测试新功能,或是基于对应用的了解发现可能的缺陷 </li></ul><ul><li>基于脚本的手工测试:在某些无法自动化测试的部分,使用手工测试或是半自动测试执行某些回归测试用例 </li></ul><ul><li>自动化测试 </li></ul><ul><ul><li>从不同层次 / 级别验证应用 </li></ul></ul><ul><ul><li>性能测试,安全性测试,模糊测试( Fuzz Testing )等 </li></ul></ul><ul><ul><li>通过重构等方式建立更加稳定的自动化测试 </li></ul></ul>
  24. 25. 敏捷测试中的自动化测试工具 <ul><li>单元测试与模块测试 </li></ul><ul><ul><li>xUnit 工具 </li></ul></ul><ul><ul><li>Mock 工具 </li></ul></ul><ul><li>HTTP/HTML 层面测试工具 </li></ul><ul><ul><li>HttpUnit </li></ul></ul><ul><ul><li>WebDriver(HtmlUnit) </li></ul></ul><ul><li>UI 层面的测试工具 </li></ul><ul><ul><li>Selenium/Webdriver </li></ul></ul><ul><ul><li>Watir/WatiN </li></ul></ul>
  25. 26. <ul><li>性能测试工具 </li></ul><ul><ul><li>JMeter </li></ul></ul><ul><li>持续集成工具 </li></ul><ul><li>安全性测试工具 </li></ul><ul><li>其他测试工具 </li></ul><ul><ul><li>Link Checker </li></ul></ul><ul><ul><li>Crawler </li></ul></ul><ul><ul><li>Fuzz 测试工具 </li></ul></ul>
  26. 27. 发布 <ul><li>为达到质量标准的产品进行 Sign off </li></ul><ul><li>面向用户发布本迭代周期得到的 Release </li></ul><ul><li>在产品环境中验证本 Release </li></ul><ul><li>数据迁移(可能) </li></ul><ul><li>为可能的回滚做准备 </li></ul><ul><li>总结本迭代周期内的测试,持续改进 </li></ul><ul><ul><li>缺陷分析 </li></ul></ul><ul><ul><li>发现可测试性的问题,持续提高可测试性 </li></ul></ul><ul><ul><li>在团队中分享测试知识 </li></ul></ul>
  27. 28. 敏捷测试中的自动化测试工具 <ul><li>单元测试与模块测试 </li></ul><ul><ul><li>xUnit 工具 </li></ul></ul><ul><ul><li>Mock 工具 </li></ul></ul><ul><li>HTTP/HTML 层面测试工具 </li></ul><ul><ul><li>HttpUnit </li></ul></ul><ul><ul><li>WebDriver(HtmlUnit) </li></ul></ul><ul><li>UI 层面的测试工具 </li></ul><ul><ul><li>Selenium/Webdriver </li></ul></ul>
  28. 29. 软件可测试性 <ul><li>Testability is the degree to which it can be established that a system performs according to the requirements . </li></ul>
  29. 30. 软件可测试性 <ul><li>可操作性:易于测试执行,允许同时开发和测试 </li></ul><ul><li>可观察性:应用有明确的可观察的输出 </li></ul><ul><li>可控制性:可以通过灵活的方式控制应用 </li></ul><ul><li>可分解性:系统模块之间的独立性强 </li></ul><ul><li>简单性:功能简单,代码简单,结构简单 </li></ul><ul><li>稳定性:软件的变化是可控的 </li></ul><ul><li>易理解性:软件是自明的,具有良好的技术文档 </li></ul>
  30. 31. 可测试性示例——验证码 <ul><li>提高可控制性的方法 </li></ul><ul><ul><li>在测试版本中取消验证码 </li></ul></ul><ul><ul><li>万能验证码 </li></ul></ul><ul><ul><li>向应用注入钩子 </li></ul></ul>
  31. 32. 代码可测试性 <ul><li>class Hello { </li></ul><ul><li>… </li></ul><ul><li>String sayHello() { </li></ul><ul><li>Calendar cal = new Gregorian Calendar(); </li></ul><ul><li>int hour = cal.get (Calendar.HOUR) ; </li></ul><ul><li>if(t < 12 ) </li></ul><ul><li>return “Morning”; </li></ul><ul><li>else if(t < 18) </li></ul><ul><li>return “Afternoon”; </li></ul><ul><li>else </li></ul><ul><li>… </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>
  32. 33. 使代码 可测试 <ul><li>class Hello { </li></ul><ul><li>… </li></ul><ul><li>String sayHello( Calendar cal ) { </li></ul><ul><li>// Calendar cal = new Gregorian Calendar(); </li></ul><ul><li>int hour = cal.get (Calendar.HOUR) ; </li></ul><ul><li>if(t < 12 ) </li></ul><ul><li>return “Morning”; </li></ul><ul><li>else if(t < 18) </li></ul><ul><li>return “Afternoon”; </li></ul><ul><li>else </li></ul><ul><li>… </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>Hello hellotest = new Hello(); mockCal = EasyM ock.create Mock (Calendar.class); expect( mockCal. get(Calendar.HOUR)) . adnRe turn( 10 ); replay(mockCal); String result = hellotest.sayHello(mockCal); Assert.assertEqual(result, “Morning”);
  33. 34. 提高产品可测试性 <ul><li>强调可测试性设计 </li></ul><ul><ul><li>松耦合 </li></ul></ul><ul><ul><li>足够的“内部 API” (测试接口) </li></ul></ul><ul><ul><li>使用合理的设计模式 </li></ul></ul><ul><ul><li>…… </li></ul></ul><ul><li>使用单元测试 / 开发测试提高代码可测试性 </li></ul><ul><ul><li>Think Test First </li></ul></ul><ul><ul><li>代码可测试性是高单元测试覆盖率的必要条件 </li></ul></ul><ul><li>编码规范 </li></ul><ul><li>设计评审 </li></ul><ul><li>…… </li></ul>
  34. 35. Q&A

×