敏捷测试

        敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈。敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。

一、敏捷测试定义

        首先敏捷测试(Agile testing)是测试的一种，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。
        敏捷测试是遵循敏捷宣言的一种测试实践：
        1、强调从客户的角度，即从使用系统的用户角度，来测试系统。
        2、重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
        3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

二、敏捷测试实质

        测试不仅仅是测试软件本身，还包含了软件测试的过程和模式。产品多数在发布后才发现很多问题，多数可能是软件开发过程出的问题，因此测试除了针对于软件的质量，即软件做了正确的事情，以及软件做了应该做的事情以外，敏捷的测试团队还要保证整个软件开发过程是正确的是符合用户需求的。
        敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈。敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。敏捷测试人员因而需要在活动中关注产品需求，产品设计，解读源代码；在独立完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论，团队决策。作为一名优秀的敏捷测试人员，需要在有限的时间内完成更多的测试的准备和执行，并富有极强的责任心和领导力。更重要的是，优秀的测试人员需要能够扩展开来做更多的与测试或许无关，但与团队共同目标直接相关的工作。帮助团队其他成员解决困难、帮助实现其预期目标，发扬高度协作精神以帮助团队的最终获取成功。需要指出的是，团队的高度协作既需要团队成员的勇敢，更需要团队成员的主动配合和帮助。对于测试人员如此，对于开发、设计人员，其他成员也是如此。

三、对比区别

敏捷测试与普通测试的区别：

1、项目相当于开发与测试并行，项目整体时间较快。
2、模块提交较快，测试时较有压迫感。
3、工作任务划分清晰，工作效率较高。
4、项目规划要合理，不然测试时会出现复测的现象，加大工作量。
5、发现问题需跟紧，项目中人员都比较忙，问题很容易被遗忘。
6、耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段解决。
7、发现BUG能够很快的解决，对相关的模块的测试影响比较小。
8、版本更换比较勤，影响到测试的速度。
9、要多与开发沟通。
10、要注意版本的更新情况。
11、测试人员几乎要参加整个项目组的所有会议。

四、敏捷项目测试人员应该具备的意识

1、心态

        以积极的心态拥抱变化:敏捷，即快速变化。敏捷项目原本充满变化和不确定性，因而需求变化比较快，产品开发周期短，给软件测试带来很大的挑战。但每一次的需求调整都是为了使产品开发朝着更正确的方向开展，测试人员应给予理解，减少无用的抱怨，积极主动去接受变化、理解变化，采取探索性测试尽早发现可能存在的问题，给予及时反馈。

2、文档

        接受精简的文档:如果要求需求频繁变化的敏捷项目像传统项目一样有详尽的文档，那么，每次变化将需要花费大量的时间来更新需求。特别是变化后不进行同步更新，将比精简的文档还糟糕。在敏捷项目中，直接沟通交流的效率远大于文档，而且直接沟通更能在理解上达成一致。测试人员可以通过主动沟通了解需求，自己整理出一份详细的需求，并不一定要像需求规格一样标准，易于理解即可。通过整理，可以更深入理解需求、发现问题、暴露问题。当然，也不能走极端，认为敏捷可以不要文档，核心业务逻辑应有文档或会议纪要体现。
        测试简单化：测试应关注于产生价值，不断尝试最简单的方法满足测试需要。比如，迭代初期，测试用例可以简单到只是包括所有测试点的清单，不仅可以节省评审时间，也可以避免需求的频繁变动加大测试用例维护的工作量。当然，每个迭代仍然需要明确且易于修改的测试计划、测试目标、测试范围、测试类型，选择合适的测试策略。在版本稳定后，再进行标准的用例库建设。

3、主动意识

        尽可能多的参与需求讨论：测试人员可以利用自己在用户体验、业务逻辑方面的经验，和项目组成员充分交流和讨论，提出有建设性的建议。也可以通过需求讨论，更加深入理解需求。
         作为勇敢的发言者：敏捷团队是民主的，团队成员能够平等参与讨论。思想的碰撞，更易突发灵感产生创造性的思维，有想法和建设性的建议应该勇敢提出来。测试人员和开发人员所站角度不同，测试人员的视角更接近客户，不要害怕所提的问题过于简单。要敢于提出问题、发表自己的意见、提出建议，尽早揭示风险、暴露问题，以免在后期造成更大的影响。
        主动沟通和协作意识：进入敏捷的协作环境，测试人员不应该局限在自己的职责领域，应关注于项目组共同的目标，尽可能产生更大的价值。优秀的测试人员应该知道如何与他人更好的沟通、合作，且随时准备协作。良好的团队沟通和协作意识也是项目成功的关键因素之一。
        乐于分享与反馈信息：一个测试人员所负责的功能一般不仅限于一个模块，因而比一个开发人员能掌握更多的需求信息。测试人员可以向项目组成员积极分享需求、反馈各功能模块的测试进展，让所有人更了解整体需求和项目动态。及时提供全面的质量反馈，每个周期对缺陷分类汇总，分析相似缺陷的发生频率和易发缺陷的功能模块，用清晰的图形化展示，提醒开发人员避免再次产生同样的缺陷。
        主动参与代码复审：测试人员不写代码，但可以主动参与代码复审，有助于提升代码阅读能力，也可能以测试人员的视角发现隐蔽的缺陷。
        不断改进工作和学习新技能：创新无论在哪里都非常重要。敏捷开发鼓励团队采纳新技术，使产品和团队自身都有很强的适应力和生命力。测试人员应该不断的学习和自我提升才能更好的适应和应对变化，努力培养自己的工作技术，关注、读好的文章以获得新想法和技能，试验新的工具和技术，改进测试工作。

4、测试方法

（1）测试驱动开发：

        敏捷项目测试人员参与了整个软件生命周期，测试人员
应该在不同阶段确认和验证、预防缺陷，而不是等到软件开发完成后才去发现缺陷。单元测试驱动开发(UTDD)和验收测试驱动开发(ATDD)，前者大多由开发负责，后者由测试操作。测试人员可以关注和推动单元测试，并利用专业测试、需求理解能力，以测试需求驱动、指导开发。当编码由测试指导，开发的产品可能更符合客户的期望，也有助于确保版本发布后重要功能正确、迭代功能无缺失。

（2）测试自动化：

        众所周知，由于敏捷项目快速迭代的特点，用自动化做回归测试是敏捷项目成功的要素之一。敏捷测试中回归测试是必须的，没时间实现测试自动化是一个不断积累债务的过程。测试自动化开始时会比较艰难，应尽早克服困难，选定或准备合适的工具。一旦某些核心功能稳定，每个迭代开始小规模的自动化工作，逐步把稳定的功能用自动化测试实现，减少回归时间和成本，将原本可发挥更大价值的人力从重复的手工测试中解放出来，将更多的时间用于重要的探索性测试。经验统计显示，80%的缺陷是在探索测试过程中发现的。

5、敏捷观

        树立正确的敏捷测试观念：敏捷项目是以结果为导向的，因此敏捷测试同样是结果导向。要有全局观，不只是关注于发现缺陷，也不以发现缺陷多少为目标，应关注于是否实现当前的功能。测试人员和开发人员都有相同的质量目标，应尽量协助开发人员不断提高软件的质量。不要“等待”，尽可能的早工作，做能够做的工作。