敏捷交付中的自动化测试 _敏捷交付

提到敏捷交付，我们总会说到持续集成，持续交付，持续发布，即频繁地交付产品特性。而我们都知道要实现真正的持续交付，必然少不了两个关键要素：

持续集成工具
自动化测试，自动化的产品质量反馈机制

【敏捷交付中的自动化测试】只有测试不行，只有集成工具也不行，二者需合二为一，保持相同的步调，实现持续不断的质量反馈，方能实现保质地持续发布。
自动化测试不只自动化工具可以开门见山地说：Automation Test ≠ Automation Tools ≠ Continuous Test
根据我个人的项目经验，试着画了下面这个图来表达这三者的关系。

文章插图

在提及自动化测试的时候，很多人会把工具的使用等同于自动化测试。自动化测试应该是一个策略性的系统工程，不只有自动化工具。像我们的产品一样，不仅要有技术语言，还要有产品架构设计。自动化测试除了工具框架，还需要考虑：
项目的技术栈，产品架构，开发流程，基础设施，可靠的测试数据，稳定干净的测试环境，如何呈现测试报告，如何工程化测试配置，测试套件等等。
有了自动化测试还不够，我们的目的是在持续交付的过程中实现快速频繁的质量反馈，我们需要持续不断地测试（Continous Testing) 。实现持续测试，不仅需要团队从文化上去支持，真正做到全员对测试和质量负责，创建Devops文化氛围，打通开发-测试-运维的壁垒；还需团队从技术上去储备知识，比如云平台、虚拟化技术，容器及相应的编排技术，甚至网络知识等等。
维基百科对自动化的解释：