在软件产品上线前，都要进行大量的测试。在软件开发方法日益成熟的今天，软件测试的方法也在不断完善。软件测试的探索，从简单的手工测试发展到单元测试、集成测试、契约测试、UI 测试、端到端测试等多维度协同协作方式为软件质量提供保证，还衍生出 TDD、BDD、自动化测试、混沌测试等侧重点不同的测试方法论。
那面对如此纷繁复杂的测试内容我们该如何制定和构建，如何针对自己的团队选择做出最适合选择呢？
本文将探讨一个自动化的、具备高响应力的、可靠并且可维护的测试组合应该如何构建，该测试组合无关具体架构，无论我们的服务架构是一个 micro service、移动应用程序或者 IoT 系统。
测试自动化的重要性
早期企业通过软件应用提高员工工作效率，但现在软件应用已经成为我们日常生活中的一个重要组成部分。作为用户，我们每天使用的软件越来越多。软件创新也正在不断的推动着软件开发团队前行。在大浪淘沙的数字化浪潮中，如果想跟上时代的步伐，我们去寻找如何在不牺牲软件质量的情况下更快的向用户交付功能成为了重中之重。
随着软件数量增多和软件功能的复杂化，手动进行构建、测试和部署，很快就会变得难以进行，除非你想把所有的时间都投入到手动重复的测试工作中，而不是用来开发功能完备的可工作的软件。把测试自动化，从构建到测试，从部署到基础架构，也许是唯一的选择。
传统的软件测试依赖测试人员手工进行：首先将应用程序部署到测试环境，然后执行一些黑盒测试，通过点击用户界面来检查软件工作是否正常。通常这些测试将由测试文档约定，以确保测试人员每次测试的内容是一致的。
显然，手工测试所有功能非常耗时、繁琐且重复。重复很无趣，无趣就容易犯错，所以保证整个软件质量需要耗费大量人力物力。
但值得一提的是，当前针对重复性的手工测试已经有了较为完善的解决方案：自动化测试。
自动化将测试工作从繁琐重复过程中解放出来。构建自动化测试后，测试人员工作的侧重点就可以从保证程序功能完整性转移到安全性、健壮性、可用性等方面。
同时对于软件开发人员，自动化这些测试意味着你可以充满自信地修改你的代码，在你对代码做了大规模改动后惬意地喝一杯咖啡，喝完咖啡后就能马上得知你的改动有没有破坏原有功能。这样的开发体验是不是听起来就让人舒服多了。
测试金字塔
对于如何构建合适企业的自动化测试流程，我们必须要知道一个关键的测试方法论：测试金字塔。
麦克科恩 (Mike Cohn) 的著作《Succeeding with Agile》一书中提出了测试金字塔这个概念。通过使用金字塔形状形象的比喻测试是需要分层的。它还描绘了每一层的测试类型。
从 Mike Cohn 的测试金字塔模型来看，整个金字塔由三层组成：
- 单元测试
- 服务测试
- UI 测试
整个金字塔模型代表着越上层的测试集成度越高，执行速度越慢，越下层的测试隔离性越好，执行越快越轻量。
图中分层粒度已经不能代表今天适用的测试结构了，有人认为 Mike Cohn 的测试金字塔里的命名或某些概念不是最理想的，从当今的角度来看，测试金字塔似乎过于简单了。
但是，我们仍能从测试金字塔中得到适合我们自己的经验法则：
- 构建不同粒度的测试
- 越高层次的测试应该越少，我们应该制定合理的测试策略
为了保持测试金字塔的形状，一个快速、可维护、覆盖范围合理的测试组合应该是这样的：
- 包含很多小而快的单元测试。
- 一部分粒度更粗的测试，如 API test，contract test。
- 较少的高层次的端到端测试。
同时，还有两点我们要注意的。一是千万不要让你的测试变成倒三角的形状，维护集成度更高的测试需要更多的上下文，同时执行起来也更慢，二是不用太拘泥于测试金字塔中各层次的名字，层次是根据测试粒度划分的，这一点也非常具有误导性，对于现代的前端单页应用，UI test 则可能不必位于最顶层，你完全有能力对 UI 进行单元测试，测试分层只需要和团队达成一致即可。
总结
对于现代软件测试架构来说，根据测试金字塔方法论制定一套合适的测试策略，将是快速迭代过程中质量保证的关键，同时分层结构的测试也更容易集成到 DevOps 体系中，将不同类型的测试分配在不同测试节点，以平衡研发效能、迭代周期、软件质量保障三者之间的关系。
