大话敏捷测试-京东云开发者社区

前言

敏捷测试从广义上来讲，测试是整个敏捷团队的活动，而不仅仅是测试同学的活动，因为原则上我们期望的敏捷团队的产出是经过代码编写+代码集成+代码测试之后的增量，所以开发同学也需要在这个目标指引下，如果测试有积压，开发同学需要针对故事进行测试，以便完成整个敏捷团队的交付承诺，而不仅仅是编码，仅仅编码不是用户和公司期望的，而经过测试的代码才是期望的；

而从狭义上来讲，敏捷测试，首先从测试同学角度，在敏捷开发的环境和上下文下，如何进行测试，思维和方法有何转变。

什么是敏捷测试？

来源：老话题新解说：究竟什么是敏捷测试？https://mp.weixin.qq.com/s/OwDulBLziQVoLFD7JuOGAQ

在敏捷环境里，测试要想生存，需要转变认知，测试不再是传统意义上的测试阶段，而是变成了测试活动，从而才可以在敏捷上下文进行持续测试，因为测试活动无处不在。

来源：https://www.luxoft-training.com/news/the-agile-testing-manifesto/

敏捷测试人员

《敏捷测试》提到有关的敏捷测试人员：

敏捷测试人员：专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。

敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试。他们希望了解客户在做什么，以此更好地理解客户的软件需求。

敏捷测试人员成为敏捷团队中的一员，通常敏捷团队采用最流行的Scrum框架，那么团队包括负责产品方向和ROI的产品负责人，负责引领敏捷Scrum的团队真正的服务型教练式的领导Scrum Master，负责将产品愿景和需求实现的开发者（包含实施和交付所需各种技能的成员，例如开发前端技能，开发服务端技能，测试技能，测试自动化技能等等）。

敏捷测试思想

《敏捷测试》：以客户为中心，注重结果，勤于耕作、协作、富有创造力、乐于学习和适时地创造业务价值。

敏捷测试前提是敏捷开发，那么需要在认同和执行敏捷宣言的价值观和12原则前提下，从测试技能、测试活动角度，应该具备的思想，就是敏捷测试思想。

举一个例子，开发同学开发完成一个用户故事，如果测试同学说需要等一等，等几个用户故事积攒在一起再测试，因为只测试刚完成的用户故事，之后还要测，浪费，这个现象就不具备敏捷思想。

敏捷测试十大法则

来源：《敏捷测试》，强调态度和心态比特定技术能力更重要，有了Mindset心态和理念，自然在团队需要的时候就心甘情愿进行任何需要的活动。

1	提供持续反馈	反馈需求以便描述清楚每个用户故事；和团队共同将每个用户故事转化成可执行的测试；和同队共同执行测试，不断接收有价值的反馈
2	为客户创造价值	聚焦关键路径，确保最小核心功能首先完成，边边角角复杂完美功能逐渐迭代上线。敏捷测试人员不仅从利益相关者家督考虑软件系统，也会了解开发面对的技术限制和实施细节。尽早经常地向客户、产品负责人、开发提出问题，把他们的答案塑造成正确的测试。自动化黄金流程/常用路径的测试；稍后增加负面测试和边界测试。如果一个应用关注安全性，增加负面测试是必要的；在迭代计划会议上，需要评估测试时间，确保迭代按计划发布安全可靠的应用
3	进行面对面沟通	敏捷测试人员和开发，产品负责人，业务代表甚至用户，面对面沟通
4	勇气	有勇气避免等待所有功能代码完成再测试，有勇气推动敏捷转型，一个用户故事一个用户故事测试。有勇气践行测试先行，推进测试自动化和持续集成，无论是自动化单元测试，还是自动化其他各种类型测试，每个迭代持续积累自动化测试脚本。有勇气允许犯错，从而持续改进。有勇气说我们，而不是说我，说你。
5	简单化	从简单着手，开发进行简单设计编写简洁代码，测试人员采用轻量的工具和技术恰到好处地进行测试。对测试分层，采取必要的测试策略。
6	持续改进	持续改进是整个敏捷团队的核心，也是敏捷测试人员的核心，持续学习，持续改进，尝试更出色的工作，只要能可持续的高效的为用户、客户的创造价值、交付价值，并且提升测试的专业
7	响应变化	测试人员和开发人员一起适应和响应变化，在专注和变化之间找到平衡，自动化测试是一个关键。
8	自我组织	所有的产品实施交付活动都是团队的职责，敏捷团队贯彻敏捷测试理念，持续关注测试和自动化测试。最高优先级的问题需要整个团队解决。
9	关注人	敏捷团队成员互相尊重并认可个人成就，并有机会提高和发展各自领域的技能，也进行跨界扩展技能领域的广度，所有人是平等的，仅仅是具有不同技能的人而已，整个敏捷团队关注一个一个的用户故事的交付，任何人只有具备相应的技能，都可以贡献。只好测试工作得到执行，不一定要指定某些成员为测试人员。
10	享受乐趣	所有成员协作，整个团队负责质量和测试，从而激发和珍视敏捷测试人员对工作的激情，因为从测试角度，对团队和客户产生了真正的价值，而不是成为最后甩锅对象，出现问题，被各种人逼问，为啥测试没有把关好，把问题测试出来？

敏捷过程的测试策略

因为敏捷中落地实践最直接最广泛的是迭代，并且在迭代中是围绕一个故事一个故事（需求条目/产品待办事项）进行开发和测试，用户故事的生命周期，通常是：分析故事->设计故事->开发故事->测试故事->验收故事->演示故事等。

围绕用户故事组织工作，就可以避免在迭代内做成小瀑布，例如测试人员在迭代后期等待大批量故事累积在一起之后再进行测试。这样就很好的践行了测试左移、持续测试、测试先行的敏捷理念。

当然现在业界也提到测试右移，也就是在生产环境进行测试，个人观点不是特别推崇，这种测试需要良好的测试策略和测试计划才可以最大化的利用生产的数据和资源进行测试，但是不要因为测试右移的说法，将其作为借口，不但不进行测试右移，还不好好的正常测试，将质量放松到生产。笔者所在的500+规模产研团队，大部分都是在测试环境和预发环境做好测试活动的。

来源：敏捷测试的核心 https://mp.weixin.qq.com/s/ExDX8qgOfdu1n6jNWf5oTA

这里的test first，是说测试先行，或者说测试动作/活动先行，而不必等到迭代后期测试。而TDD, Test Driven Development测试驱动开发，是开发人员先写函数/单元的测试代码，导致测试失败，再写功能代码，让测试通过，再重构成简洁代码的过程。

从用户视角，ATDD（验收测试驱动开发，Acceptance Test Driven Development）/BDD（行为驱动开发，Behavior Driven Development），是整个敏捷团队一起进行的测试用例识别和测试用例自动化的方法。

那么什么叫做一个故事一个故事进行开发测试呢？如下图最下边的情况，跨职能特性团队进行迭代，针对每个故事进行DBT，定义产品方案、构建开发、测试。

迭代内的进一步描述如下：

来源：《敏捷测试》

来源：《深入敏捷测试》

可以明显看到，在例如2周的迭代周期内，第一周就有用户故事可以进行测试，所以从2周时间来看测试的活动是持续的。很多人都有误解，一周开发一周测试就是2周迭代了，这种做法导致的后果就是Bug集中在第二周爆发，并且在第二周没有更多的人力和时间把所有的用户故事测试完，这就带来了测试工作的积压，导致部分用户故事没有Done，延迟到下一个迭代，最终会影响整个迭代节奏的顺畅、稳定和高效率交付。

敏捷测试和传统测试的对比

来源：究竟什么是敏捷测试和探索式测试？https://mp.weixin.qq.com/s/uhb0qN_Hc2rLH6-tPTM5Zw

来源：爆肝全面分享什么是敏捷测试？https://mp.weixin.qq.com/s/w6RSvDVbOHtHZbCnUNqozg

传统测试最大的特点是测试活动发生在后期，将会有两个大爆发，一个是一大堆代码推过来，一个是一大堆Bug推回去，同时测试人员在进行排期计划的时候，考虑的是人员利用率最大化。

而敏捷测试最大的特点是测试活动发生在全生命周期，尽量提前，考虑的不是人员利用率最大化，而是用户故事/需求条目的价值最大化，那么什么时候最大化呢？就是针对一个故事测试完就是最大化的时候，当然说的准确一点的话，如果这个故事可以上线，那么一上线，就可以马上体现出最大化的价值，因为用户可以使用了。所以在这种场景下，就不会说人员有重复劳动啦，效率不高啦等等。

敏捷测试象限

测试活动发生在产品开发的全生命周期里，可以用四象限的方式进一步呈现。