敏捷测试介绍
敏捷测试固然不能简单地理解为测得更快，绝对不是比之前用更少时间进行测试，也不是将测试的范围缩小了或将质量下降来减小测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面咱们将要讨论一下：
- 什么是敏捷测试？
- 敏捷测试有哪些流程改进？
- 测试人员如何面对敏捷测试的挑战？
- 在敏捷测试中如何制定相应的自动化测试策略？
什么是敏捷测试
假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工做可能会事倍功半，测试人员可能会每天加班，而不能发挥应有的做用。敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不一样的侧重，例如减小测试计划、测试用例设计等工做的比重，增长与产品设计人员、开发人员的交流和协做。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。因为敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是可以及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈
敏捷测试流程的优化
在敏捷方法中，需求变化比较快、产品开发周期很短，咱们目前采用四周时间，也就是每月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大的挑战，软件测试流程要作相应的调整。例如，咱们原有的测试规范明确规定，首先要创建项目的主测试计划书，而后再创建每一个功能任务的测试计划书，测试计划书有严格的模板，并且须要和产品经理、开发人员讨论，并和测试团队其余人员（包括测试经理）讨论，最终获得你们的承认和签字才能经过，仅测试计划通过“起草、评审和签发”一个完整的周期就须要一个月。在敏捷方法中，再也不要求写几十页的测试计划书，而是在每一个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就能够了。
在原有测试规范中，要求先用Excel写出测试用例，而后进行讨论、评审，评审经过之后再导入测试用例库（在线管理系统）中。在敏捷测试中，可能不须要测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如图2所示。
在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，并且某些关键方面也要获得咱们足够的关注，主要有：
- 测试人员不只要全程参与需求、产品功能设计等讨论，并且要面对面地、充分地讨论（包括带语言、视频的即时通信），仅仅经过邮件是不够的。
- 参与代码复审（Code Review），并适当辅助开发人员进行单元测试。
- 在流程中增长一个环节“产品走查（Product Walk-through）”DEMO——测试人员和产品经理、开发人员等在一块儿，从头至尾将新功能看一遍，可直观、快速地发现问题。
新功能的测试和回归测试策略
测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试创建相应的策略，以提升测试的效率，最大限度地下降质量风险。新功能测试的策略主要有：
- 不须要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即便要写测试用例，只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。
- 持续地进行验证，一旦某块新代码完成（Code Drop），就开始验证，而不是等到全部代码完成后才开始测试。这也包括参与到单元测试和集成测试中。
- 实施端到端（End-to-End）的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。
- 阅读代码来发现问题，能够和开发人员工做保持同步，消除测试周期的压力。
- 基于经验，能够实施更多的探索性测试、组合交互性（Interoperation）测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。
回归测试是敏捷测试中须要面对的难点。每次迭代都会增长新的功能，一个产品可能会通过十几回、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能仍是一个月。这样验收测试的时间很是有限，因此回归测试很大程度上依赖于自动化测试，由于很难将回归测试控制在很是有限的范围内。固然，仍是有些办法能够帮助咱们减小回归测试的范围，例如：
- 经过执行Code Diff 来了解代码变更的全部地方，再作代码关联分析，就能够明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小。
- 基于风险和操做面分析来减小回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。
- 持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到平常的试用和测试中来。
自动化测试策略
因为开发周期短，需求、设计等方面沟通也须要花费不少时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就须要正确的策略来提升自动化测试的效益，如图3所示，并说明以下。
- 构建一个灵活的、开放的自动化测试框架，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。
- 针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本,小部分主要功能自动化,而大部分新功能测试采用手工测试
- 集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工做。
- 在产品设计、编程时就很好地考虑了自动化测试的需求，使全面的、自动化的底层测试、接口测试成为可能，尽可能避免用户界面（UI）的自动化测试。
- 良好的IT基础设施，包括自动化构建软件包、自动化版本验证（BVT）、自动化部署、覆盖率自动产生等。
敏捷测试工具
自动化测试依赖于测试工具，所幸的是，目前已有不少敏捷测试工具。因为篇幅所限，这里只是简单地列出一些经常使用的敏捷测试工具，再也不深刻讨论了。
- 单元测试工具：TestNG、xUnit家族（如JUnit、NUnit）、JMock、BizMock等。
- 功能测试自动化：ThoughtWorks Twist。
- Web功能测试（frontend）：Selenium IDE/RC、WatiR、WatiN。
- Web service测试工具（backend）：soapUI。
- 性能测试：JMeter+BadBoy。
- 验收测试框架：Fitnesse、Tellurium。
- 敏捷测试过程管理工具：微软的Visual Studio 2010，包括TFS 2010、Scrum模板（MS VS Scrum 1.0）、Test Manager 2010、Coded UI Test等。
- 业务智能（BI）应用的测试框架：Oraylis BI.Quality （+ NUnit）。
- 其余一些协做工具等，如TestLink、BugZilla、BugFree、Wiki等。
测试人员在敏捷方法中的价值
在敏捷方法中，开发人员的主导做用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？
- 在需求和功能设计讨论上，测试人员能够站在客户角度来阐述本身的观点，扮演“用户表明”角色，强调用户体验，真正体现测试人员和开发人员的互补做用。
- 测试人员不只扮演“用户表明”角色，并且经过需求讨论、代码复审等各类活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程当中质量受到足够的关注，以提升质量改进的持续性和可视性。
- 测试人员应积极参与单元测试，即便不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具备良好可测试性的代码。
- 在敏捷方法中，每每将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（End-to-End）测试显得更为重要，测试人员在这些测试上能发挥更大的做用。
- 产品发布前，验收测试和回归测试依然不可缺乏，这更是测试人员的用武之地。
- 一个迭代周期结束后，对缺陷根本缘由进行分析、总结规律，帮助开发人员创建良好的习惯，预防缺陷，从根本上提升产品质量。
理想状况下，测试人员掌握设计模式、具备很好的编程能力，能够和开发人员进行角色互换，如在当前版本开发中担任测试人员角色，在下一个版本开发中则担任开发人员角色。这样双方对不一样角色的工做有着更深入的认识，消除沟通的障碍，开发的效率和质量会有进一步的提升。
总结
根据上面的讨论和咱们的实践，最后针对敏捷测试进行一个简单的总结，就是：
- 敏捷测试就是持续测试、持续反馈，扮演“用户表明”角色，确保产品知足客户的需求。
- 敏捷功能测试 = 新特性的手工测试（Use Case验证和探索性测试）+新功能的BVT测试(建议有) + 原有功能的自动化测试 （回归测试）。做为一个偷巧的办法，某些状况下，能够对代码进行diff 检查，比较代码改动的部分，让测试更有针对性。
- 合理的利用自动化。自动化并非越多越好。自动化能够保证已有功能的回归。对新增的功能，须要评估究竟是自动化效率高仍是手动测试效率高？我更倾向于对新增功能执行手动或者半自动化的测试，而在产品发布以后再补充完善自动化回归脚本。随着开发的进行，产品质量的提高，以及对产品了解程度的加深，对自动化测试进行持续改进，提供更大的覆盖，更好和更快速的验证。
- 敏捷开发追求持续的集成，持续的进行单元测试和回归测试。咱们计划与过程改进一块儿推动Check-In Test, BVT, daily regression test的自动化，让开发人员随时能够获得关于代码质量的反馈（例如，每一次的check-in是否break了build），帮助开发人员生产出具备良好可测试性的代码，进而提高测试的效率。帮助开发，就是帮助测试本身。
- 经过自动化和测试报告，创建可见的质量度量体系，让产品和代码质量反馈持续可
- 让测试用例更有效率，避免在测试用例上面浪费太多的时间。测试用例不是越多越详细就好。太详细的测试用例会下降测试效率，增长维护成本，而且会限制测试执行人员的思惟。若是你的Bug大部分是经过执行测试用例发现的，那说明有两个问题：你在测试用例上面浪费了太多的时间，或者你在测试经验上面比较欠缺。如何定义测试用例的粒度——从业务出发，测试用例只要覆盖全部的业务功能和逻辑就够了。而数据检查、边界条件的测试用例，就留给测试人员去执行探索性的测试吧，但愿每一个人都加强探索性测试的意识。
- 为各系统维护一套测试点的checklist，越精简越好。让负责测试的人员（尤为是新手）能在几分钟以内就知道有哪些测试点是被遗漏的、须要关注的。咱们已经把部分的checklist放在在wiki上了（例如引擎测试），但愿你们都能参与进来，不断补充完善。
- 前端应用的测试：UI变动频繁，测试很是容易失效？是否能够考虑把测试重心向相对稳定的接口测试倾斜？你们能够一块儿来思考。
- 开发和测试团队具备一样的质量目标和质量责任。开发人员有义务对产品的可测试性和可自动化负责。若是你有这方面的需求，必定要跟开发人员讲出来。
- 敏捷测试人员和开发人员的区别愈来愈小，理想状况下，敏捷方法中，测试人员和开发人员在不一样的迭代周期能够互换。
- 敏捷测试流程依据不一样的团队特色、不一样产品的特色而不一样，因地制宜，适合才是最好。
我的工做经历的一些经验，总结了如下几点：
一、测试人员尽量早的进入产品或项目的相关工做(这里指的产品或项目，指的都是从头开始的)，从产品的计划、需求调研、评审工做的开始测试人员就进行参与，这么作的目的有以下几点：
a.让测试人员尽量多的了解需求、了解业务，积极的提出问题
b.在下一步系统架构和接口设计以后，测试人员能够进行尽早设计系统的接口测试用例
c.还能够为下一步编码工做的单元测试作一个良好的铺垫，在后期设计单元测试用例的同时，懂代码的测试人员能够直接的检查开发人员的代码逻辑和业务逻辑是否符合要求，这也就实现了用最少成本“双人编程”。
二、综合一些实际状况考虑：根据一些实际调研，通常开发与测试的比例在1:6--1:10左右，能达到1:6的已经很不容易了，暂时不去讨论这个比例问题，由于这个须要根据项目的实际状况来看，我的看来：一些大型的互联网公司是不差钱的，因此他们会尽量的在测试方面多投入或者说投入较高的，还有一些公司是不肯意在测试方面多投入可是又想多作测试的，还有一些就是尽量少投入的，其实这些均可以调整，调整的依据是两个方面：一是确保公司对这个项目的重视和公司是真正的作测试，若是没有领导的支持，准确的说没有大领导的支持，测试工做是很难有效推动的，二是有效的安排测试人员，就是在项目的不一样阶段安排不一样测试人员，在测试不是不少是时候，可使用半我的或者更少的测试人员，实现这一点的方法就是让一个测试人员去服务多个项目便可，固然这个多个也是有数量限制的，由于一我的的精力也是有限。
三、从第前2条提出来的一个疑问：做者一直提倡让测试人员尽量早的接触产品和项目，这样能让测试人员充分了解项目，那么如何让一我的服务于多个测试项目？首先：明确一点，不是测试人员不从项目的开始就介入，测试人员就不能了解需求、不会测试。对于一个有经验的测试人员来讲，快速的熟悉项目的需求并非一件难事，若是说项目的各类逻辑真的是很复杂，项目经理也能够根据用户故事或者进行一些更为细致的安排来让这些协调过来的测试人员开展测试工做。一人服务于多个项目，这种事情在国内应该是家常便饭的。
四、如何安排人员也是一个如何花钱的问题：这种体会最深的就应该是外包公司，是先花钱仍是后花钱仍是超支仍是项目失败，想必外包公司对这方面算的是最细的了。早期发现问题早解决问题，后面的压力就会小，不能早期的发现的问题，后面的团队压力就会像滚雪球一下愈来愈大。早期的测试投入当作一份成本的话，用这一份成本，来提前的发现问题的下降风险，后期才开始投入测试的话，也算是用一份成本，可是若是发现问题，开发人员就追踪、修改的成本是要远远大于初期的，项目的庞大和不稳定是让开发人员准肯定位问题最大的困扰，还有测试人员作测试验证、回归测试、自动化脚本的修改这一切成本。
五、在项目的中后期如何作好自动化测试工做？在项目中期的时候，问题会逐渐积累，测试的东西也会愈来愈多，开发和维护的东西愈来愈多，维护是指测试人员测试出来的bug须要修复，可是又不能由于修复bug就中止项目开发工做。随着项目的推动，测试的效率保证是一个关键问题，这个时候自动化的推动和效率却成了一个矛盾的问题。缘由有三：1.自动化代码须要编写和调试 2.自动化代码测试结果须要和手动测试结果进行比对 (自动化测试结果和手动测试结果不一致会有发生)3.自动化测试代码须要维护，尤为是在需求变动和设计变动的时候，手动测试只须要肉眼对比，而自动化测试可能会将代码进行较大改动。这三个问题大大下降了测试效率，这是手动测试必须成为项目的主导。解决这一问题的办法就是在项目测试集中的阶段调整手动和自动测试人员的比例，自动化人员测试的范围须要有一个合理的规划，必须定时的提交自动化测试代码，在手动测试完成后必须尽快的补充自动化测试代码，在完成测试工做的同时也天然的与手动测试的结果进行了比较，至关于进行了1次回归测试。也就说仍是所有由手动测试人员进行第一轮全面覆盖的测试。
六、在“敏捷”开发过程当中，自动化工程师先对哪一部分功能进行优先的用例实现：能够从如下几个方面进行考虑：1.优先考虑数据对比类型的功能，这种功能人工操做比较费眼力和时间 2.优先考虑已经测试出问题的功能，这样能够有效的对bug的功能进行回归检查 3.用户使用比较频繁的功能 4.项目优先级比较高，比较核心的功能
7.强调一点：手动测试和自动化测试对于项目来讲同等重要，不存在自动化测试人员高级于手动测试人员。若是说必定要说哪一个最重要的话，只能是看项目的不一样阶段，在项目前中期的时候的时候，手动测试占据了核心地位，在后期的时候，自动化的全面覆盖保证了回归测试的有效进行。
8.总结：关于敏捷开发和敏捷测试的一点心得：敏捷如今已经被推向了一个高潮，何为敏捷？太多人有不一样的看法，说到最后与敏捷最分不开的一词就应该是“实践”，敏捷是实践出来的，不是效仿出来的，如今太多的公司和团队在盲目的追求敏捷，拿scrum来讲，有多少公司在作的只是scrum最最表象的一些东西，安排站会，制定sprint，总结会等等，可是这些真的给你的团队带来了改善了吗？想必答案只有他们本身清楚。我心中的敏捷：敏捷---敏-结，敏就是敏捷，简单的说就是要一个高效率，结：是指项目团队的协做和内部团结,这一点很是重要。看那些成功实施敏捷的团队和诸多的最佳实践团队他们都是团结一心的，整个项目团队都有一个共同的目标和追求，而不是天天项目经理在驱使着你们在前进，每一个人都积极上进学习，遇到不懂的问题去总结、去学习，去突破，再去分享，而不是说，“这个问题太难了，这个技术太难了，这个。。。我可作不了”，若是每一个成员都采用这种排斥的内心，那么这个团队就永远都敏捷不起来，还有就是在须要协做的时候，两个项目组不要互相“踢皮球”，而是要敢于承担责任，最广泛的现象就是项目出现了问题，而后你们在会上开始掐架。这时候有人会问，本身出来担责任不是傻吗？其实否则，一个明智的老板固然看的懂究竟是谁的责任，是否真正的须要人来承担责任。若是这都作不到，证实这个老板也就。。。再谈实践，笔者看来，很难有一个很细致的又能够公用的敏捷方法，即便如今最流行的scrum，也是一个很是抽象的概念，因此才有诸多屡实施又不见成效的团队，最好的推动敏捷的方法就是实践，只有实践才能发现问题，才能解决问题，最好找到一个适合本身的敏捷方法。
谈谈在敏捷的项目里如何实行测试的工做。
敏捷的项目对测试的影响
- 文档少，所以难以只是依赖文档来设计测试。
- 短迭代，须要更短的时间完成测试的工做。
- 频繁的变化，须要测试更具备探索性和适应性。
敏捷项目的正确测试观念
- 项目是以结果为导向的，因此测试一样是结果导向。
- 不以发现缺陷多少为目标。
- 以不断提升软件质量为目标。
- 测试人员的做用是帮助开发人员不断提升软件的质量，是协助性的。
- 测试人员不是批判性的。
- 测试人员可以尽量的作可以作的工做，尽量的早工做。
- “等待”在敏捷开发、敏捷测试范畴里已经是一种错误概念。
敏捷测试的管理
- 敏捷项目的测试没有严格的角色。人人都是测试。
- 以测试任务为导向。测试任务便可以是开发来作，也能够是测试人员来作。
- 相同的质量目标。开发和测试有着同一个质量目标，所以也承担着一样的责任。
- 关注质量的提高，测试周期与开发同步。
- 要有全局观，不仅是专一于发现缺陷。
- 为回滚作准备，本次迭代发布失败，可安全回滚至旧版本。
- 分享测试知识。
- 创建缺陷库，指导开发人员避免再次发生一样缺陷。
敏捷测试的执行
- 关注和推进单元测试。
- 持续改进自动化测试（由于软件的变化，已经对产品的深刻了解）
- 短文档（测试用例能够不写，测试计划列测试点，测试类型，质量标准便可）。
- 对新增的或者引发变化的地方（可询问开发人员协助）采起探索性测试。
- 对稳定的部分添加自动化测试。
咱们的项目以前的测试开发比例是1比5，质量基本达到客户的要求，为何1比5能够，由于我说过，开发人员是能够作测试的工做的。如今以为惟一有不足的地方是对稳定的地方进行自动化的回归测试。还有，我但愿在自动化的探索性测试上有所进步。
最后，我还说一点是，我看到不少项目靠加班，不会休息的团队是不健康的团队。其实，项目每每不是短时间行为，一般一个产品的至少须要半年努力和投入，长
时间的超负荷运转会使得工做效率低，身体透支等严重后果。项目中后期每每强度会比前期更大，这个时候，人员倒下和效率低不是一件好事情。因此，若是你的项目还要长期发展，应该帮助团队认识到轻松的团队氛围，张弛有度的工做安排是项目成功的最好方式。
固然，不加班，不表明上班时间很差好干。咱们要求就是8小时之内，每周40小时。
