《敏捷测试实践》PPT课件.ppt

敏捷测试实践,蒋晓东,敏捷测试,简而言之，敏捷测试是指在采用敏捷技术的项目中开展的测试同时，敏捷测试也意味着测试遵循敏捷的基本原则，接纳敏捷的核心价值观（交流，简单，反馈，勇气）保持简单以任务为导向，而不以过程或是角色为导向通过沟通和反馈保证测试能够建立合适的质量标准尽可能减少测试周期的时间需求敏捷测试要求“交付可用产品”而非单纯的“发现缺陷”,敏捷测试 vs.传统意义上的测试,敏捷测试带来的挑战（一）,质量文化上的挑战发现缺陷 vs.在产品中内建质量敏捷带来的担心：测试工程师应该做什么？敏捷带来的担心：测试工程师能够做什么？,敏捷测试核心价值观,共享质量目标开发和测试团队共享同样的质量目标，当然也共享同样的质量责任，每个工程师在测试方面都同样承担任务在产品中内建可测试性为产品建立更好的自动化测试不仅仅依赖于测试工程师的工作，更重要的是，产品本身内建的可测试性关注产品质量的提升，测试周期的缩短，而不是仅专注于发现缺陷,敏捷测试中的测试工程师可以做什么,获取和明确用户的质量期望建立合适的系统测试、用户验收测试质量标准建立可见的质量度量体系，让产品和代码质量反馈持续可见推进单元测试、开发测试，促进代码质量建立持续构建框架建立与维护合适的自动化测试以减少测试的时间投入,敏捷测试带来的挑战（二）,测试工程师面临的挑战必须通过与开发团队的密切合作获取产品信息，制定测试计划而不是依赖文档必须密切介入开发过程，参与设计，甚至是代码必须能够自我驱动必须具有足够的自动化测试技能与探索性测试技能,拥抱变化，改变工作方式,与开发工程师密切合作转变角色，测试工程师不再是“裁判”，而应该是“支持者”和“帮助产品具有更好质量的角色”将测试推动到上游自我驱动，积极参与敏捷过程，主动工作而非仅仅被动接受任务提升自己的技能，尤其是自动化测试方面的技能、探索性测试能力、快速学习能力,敏捷测试带来的挑战（三）,测试团队面临的挑战与传统测试不同的考核标准与传统测试不同的人员技能要求与传统测试不同的测试过程管理与传统测试不同的团队管理方式,建立适合敏捷测试的团队,建立以“质量和生产率”为核心的激励机制提升团队成员技能，招聘合适的测试工程师质量驱动，而非过程驱动在团队内形成对敏捷的认知和认可给团队成员更大的自主空间鼓励团队关于自动化测试技术,敏捷测试的四个象限,敏捷测试体现的与传统测试的不同,作用于产品（Critique product）的测试探索性测试（Exploratory Testing）场景测试（Scenario Testing）用户验收测试（UAT）性能测试，安全性测试作用于支持团队（Supporting the team）的测试单元测试模块/组件级别的测试功能测试用户故事（User Story）测试,敏捷测试的目标,作用于支持团队的测试,作用于产品的测试,敏捷测试实践,There are good practices in context,but are no best practices.-来自Agile Testing A Practical Guide For Testers and Agile Teams,敏捷测试过程,针对一个迭代周期计划一个迭代周期内的测试了解细节，确定测试范围创建并执行测试发布敏捷测试中的持续任务提高代码质量与产品质量从更多层面建立测试（单元测试、模块测试、系统测试等）建立产品的质量度量改进自动化测试（更稳定，更高的覆盖率）,计划一个迭代周期内的测试,计划的内容产品发布标准（验收测试准则）需要在本迭代周期内测试的内容需要安排的测试类型需要使用的测试环境（包括数据）管理计划管理一页纸测试计划（One Page Test Plan）可以使用各种形式表达测试计划：在线文档，测试点列表，自动测试列表，白板或是电子表格,了解细节，确定测试范围,了解本次迭代的产品细节有哪些新增加的功能？开发工程师为相应的功能建立了哪些测试？需要增加哪些验收测试？应用的哪些部分可以通过自动化测试覆盖？应用的哪些部分需要通过手工测试覆盖？确定测试范围哪些部分应该被纳入回归测试内？哪些部分需要新增加自动化测试？哪些部分需要新增加手工测试？,用自动化手段帮助确定测试范围,Diff技术,Diff工具,Diff的作用识别应用中发生变化的部分包括对接口，UI等各层面的检查发生变化的部分是需要重点测试和覆盖的部分不同的Diff方法HTML diffDOM tree diffImage Diff接口数据Diff,创建测试并执行,建立测试执行的基础架构（Test Infrastructure）持续集成框架建立自动运行的Sanity Check Test Suite维护验收测试集（Accept Test Suite）在一个迭代周期中创建与执行测试创建各个层次的测试使用自动化测试框架运行测试使用基于脚本的手工测试与探索性测试完成对新功能，以及部分原有功能的回归测试,敏捷测试中的测试方法,探索性测试：主要用于探索和测试新功能，或是基于对应用的了解发现可能的缺陷基于脚本的手工测试：在某些无法自动化测试的部分，使用手工测试或是半自动测试执行某些回归测试用例自动化测试从不同层次/级别验证应用性能测试，安全性测试，模糊测试（Fuzz Testing）等通过重构等方式建立更加稳定的自动化测试,敏捷测试中的自动化测试工具,单元测试与模块测试xUnit工具Mock工具HTTP/HTML层面测试工具HttpUnitWebDriver(HtmlUnit)UI层面的测试工具Selenium/WebdriverWatir/WatiN,性能测试工具JMeter持续集成工具安全性测试工具其他测试工具Link CheckerCrawlerFuzz测试工具,发布,为达到质量标准的产品进行Sign off面向用户发布本迭代周期得到的Release在产品环境中验证本Release数据迁移（可能）为可能的回滚做准备总结本迭代周期内的测试，持续改进缺陷分析发现可测试性的问题，持续提高可测试性在团队中分享测试知识,敏捷测试中的自动化测试工具,单元测试与模块测试xUnit工具Mock工具HTTP/HTML层面测试工具HttpUnitWebDriver(HtmlUnit)UI层面的测试工具Selenium/Webdriver,软件可测试性,Testability is the degree to which it can be established that a system performs according to the requirements.,软件可测试性,可操作性：易于测试执行，允许同时开发和测试可观察性：应用有明确的可观察的输出可控制性：可以通过灵活的方式控制应用可分解性：系统模块之间的独立性强简单性：功能简单，代码简单，结构简单稳定性：软件的变化是可控的易理解性：软件是自明的，具有良好的技术文档,可测试性示例验证码,提高可控制性的方法在测试版本中取消验证码万能验证码向应用注入钩子,代码可测试性,class Hello String sayHello()Calendar cal=new GregorianCalendar();int hour=cal.get(Calendar.HOUR);if(t 12)return“Morning”;else if(t 18)return“Afternoon”;else,使代码可测试,class Hello String sayHello(Calendar cal)/Calendar cal=new GregorianCalendar();int hour=cal.get(Calendar.HOUR);if(t 12)return“Morning”;else if(t 18)return“Afternoon”;else,Hello hellotest=new Hello();mockCal=EasyMock.createMock(Calendar.class);expect(mockCal.get(Calendar.HOUR).adnReturn(10);replay(mockCal);String result=hellotest.sayHello(mockCal);Assert.assertEqual(result,“Morning”);,提高产品可测试性,强调可测试性设计松耦合足够的“内部API”（测试接口）使用合理的设计模式使用单元测试/开发测试提高代码可测试性Think Test First代码可测试性是高单元测试覆盖率的必要条件编码规范设计评审,