什么是敏捷测试金字塔
什么是敏捷测试金字塔
敏捷测试金字塔模型能够帮助测试人员更好地理解如何实现自动化测试。称它为金字塔，是因为它的层次结构图就像一个金字塔形状：
这里需要明白的是，关于这个金字塔，有许多变种版本可以更形象地、更具体地展示它。它们可以加入一些图案、箭头、文字等内容。这张图只是展示了最抽象的结构，它不会告诉你关于敏捷测试的一切。但是，万变不离其宗，所有的相关金字塔图都是大致基于这样一个层次结构。
敏捷测试金字塔最初由敏捷工程专家Mike Cohn提出，在他的书《Succeeding With Agile》中提到：“测试金字塔最底层是单元测试，然后是业务逻辑测试，最后是端到端测试(End-to-end Testing)”。
敏捷测试和传统测试的区别
传统的软件测试，使用的是左下图的倒金字塔模式，也称作冰激凌模式，大量的测试工作都是通过在UI上手动测试完成。可能会有些自动化测试在中间层完成，也有一小部分的单元测试会由开发人员自己完成。我们可以把传统的软件测试方式的哲学视作“找 bugs”，它和传统的软件工程中的瀑布模型的哲学是相似的，整个软件开发的过程可以概括为“写代码”和“解决 bugs“，
而敏捷测试则使用右下图的模式，也就是我们说的金字塔模式。敏捷测试更多地依赖自动化，它需要开发人员大量的贡献。而它的哲学是“避免 bugs”。自动化测试要求我们清楚地了解什么是这个系统必须完成的功能，过去我们把它称为“功能规范”。为了减轻过重的文档和过于繁琐的过程，高效的敏捷团队往往会直接从用户故事(User Story)的验收标准(acceptance criteria)出发，去进行自动化测试。这意味着，大量的测试都是在单元和故事 (story) 层级通过自动化来完成。自动化测试给予我们信心，告诉我们这个产品是正确的、它的构建是正确的、它符合每一个验收标准，我们可以每天多次地运行自动化测试，用这种持续方式，来检验软件的正确性。
敏捷测试金字塔要求相关人员和组织掌握更多的技能。开发人员必须学会通过单元测试验收他们自己的工作，典型的工具是各类语言的单元测试库，如CPPUnit、JUnit等，经典的方法包括测试驱动开发 (Test Driven Development)；测试人员要求学习自动化测试工具，这些工具能够在故事层级工作，比较流行的工具包括：Fitnesse，Concordion，Cucumber，Behat以及Robot Framework等。
可以注意到，在敏捷测试金字塔的顶端，UI 测试非常少。原因很简单—— UI 的改动往往非常频繁。而一旦 UI 有改动了，它的相关的自动化测试也要改动。这样一来，测试的维护成本就超过了测试的带来的价值。所以我们鼓励对于 UI 测试，尽可能少地使用录制/回放测试(record and playback testing)，在一个成功的敏捷项目中，自动化测试并不意味着要使用 Selenium 之类的工具来运行录制脚本。
当进行迭代开发的时候，回归测试是必要的。软件系统每天都会变化，我们想知道原来能正常工作的东西现在也能正常工作，所以每个东西都需要持续地测试。这种持续测试，对于手动测试而言，是非常困难的，它是一个重复的、乏味的、易出错的任务，而且很有可能测试不完整。它让测试人员花很多时间重复地测试之前测过的功能，而测试新功能的时间却越来越少。下图展示了在迭代开发中，手动的回归测试的负载是如何呈几何增长的。
测试的投资回报率(ROI)
软件测试领域有这样一句话：“在一个软件已经发布之后去修复一个 bug，和在单元测试阶段去修复这个 bug，前者花费的代价是后者的足足五倍”。这其实说明了，测试的投资回报率，在软件的生命周期中，是逐渐递减的。在前面的金字塔模型中，底部的两类测试——单元测试和组件测试，代表了那些能够从自动化中获益的测试。当你沿着金字塔往上移动，投资带来的回报就会减少，并最终在手动测试和探索性测试那一层达到零点（这两类是非自动化测试）。这意味着，越早并越频繁进行测试，效果和回报往往越好。
为什么要尽早自动化测试呢？当你的测试流程变得成熟，你可能意识到这些机会：
- 用相同的成本可以到达更高的测试覆盖率
- 测试周期变得日益高效
- 测试开始规模化，并且可以跨项目使用
- 开发阶段解决一个 bug 花费的代价更少
- 越来越少的 bug 会被遗留到生产阶段
当你基于敏捷测试金字塔模型的时候，这些机会和好处会更加明显，它能帮助整个团队建立一个扎实的迭代开发基础，利用较早阶段的自动化测试带来的回报率，提升整体的效率。
当你沿着金字塔往上走时，一些问题就会出现：
- 测试的脆弱性开始凸显，比如常常会出现意料之外的错误，甚至人们都认为最新的改动不会导致这些错误
- 测试向开发的反馈时间变长
- 测试需要花费更多的时间
- 较高的成本去实现自动化
- 需要更专业的知识
举个例子，UI 的测试比起单元测试和集成测试更容易出错，通常是因为 UI 结构设计会一直改变。金字塔较低层次的测试会更快且更稳定，这也是为什么敏捷测试推荐把更多的精力放在低层次测试上面，而对于诸如端到端测试之类的高层次测试，写的测试要非常少。
参考
https://www.agilecoachjournal.com/2014-01-28/the-agile-testing-pyramid
「 您的赞赏是激励我创作和分享的最大动力! 」
- 原文链接：https://zhuyinjun.me/2020/agile_testing_pyramid/
- 版权声明：本创作采用 CC BY-NC 4.0 国际许可协议，非商业性使用可以转载，但请注明出处（作者、链接），商业性使用请联系作者获得授权。