敏捷交付中的自动化测试

lsekfe

提到敏捷交付，我们总会说到持续集成，持续交付，持续发布，即频繁地交付产品特性。而我们都知道要实现真正的持续交付，必然少不了两个关键要素：
　　·持续集成工具
　　·自动化测试 ， 自动化的产品质量反馈机制
　　只有测试不行，只有集成工具也不行，二者需合二为一，保持相同的步调，实现持续不断的质量反馈，方能实现保质地持续发布。
　　自动化测试不只自动化工具
　　可以开门见山地说：Automation Test ≠ Automation Tools ≠ Continuous Test
　　根据我个人的项目经验，试着画了下面这个图来表达这三者的关系。

　　在提及自动化测试的时候，很多人会把工具的使用等同于自动化测试。自动化测试应该是一个策略性的系统工程，不只有自动化工具。像我们的产品一样，不仅要有技术语言，还要有产品架构设计。自动化测试除了工具框架，还需要考虑：
　　项目的技术栈，产品架构，开发流程，基础设施，可靠的测试数据，稳定干净的测试环境，如何呈现测试报告，如何工程化测试配置，测试套件等等。
　　有了自动化测试还不够，我们的目的是在持续交付的过程中实现快速频繁的质量反馈，我们需要持续不断地测试（Continous Testing)。实现持续测试，不仅需要团队从文化上去支持，真正做到全员对测试和质量负责，创建Devops文化氛围，打通开发-测试-运维的壁垒；还需团队从技术上去储备知识，比如云平台、虚拟化技术，容器及相应的编排技术，甚至网络知识等等。
　　总结出自动化测试的两个特点，就是：
　　·自动化测试本身也是软件
　　·自动化测试基于预期结果进行断言
　　测试，质量评估的重要手段之一，而自动化测试只是测试的一种具体实现方式而已。它能释放QA的双手和一部分大脑（这部分大脑，即know knowns），将对已知特性和既定逻辑流程的检测交由计算机来完成。而QA去做更多需要思辨能力，分析判断能力的事情。例如，通过向团队提问，来澄清需求的unknowns；通过探索产品去拓宽对产品的knowns；抑或运用经验帮助团队走出Unknown Unknowns 带来的迷局。
　　测试工具的选择需要考虑项目的技术栈，也需要考虑QA自身的技术能力。
　　不管多火的工具，如果不能兼容项目的技术栈和基础设施，那都无处发挥其优势，流行的不一定是适合项目的。
　　在写自动化之前，QA需要对项目的技术栈，开发流程，和基础设施有基本的认识和了解；另外也需要了解和掌握各个工具之间的优劣，这样才能为项目选择最匹配的自动化工具。是不是像老生常谈？但是别人告诉你的经验和自己经历的实战真的两种不同的收获。就跟蹲家看电视和去现场看演唱会的区别一样，别人的经验之谈总归是别人的，自己走过的路才是自己的。
　　选择合适的时候做自动化, 避免不必要的浪费。
　　在项目做第一个规范安全流程的产品时，MVP1(Minimum Viable Product) 一完成，该产品的接口自动化测试和端到端自动化测试便实现了，并集成到了产品CI/ CD 流水线上。后来由于客户方硬件集成的问题，该产品基于MVP1进行了一次演进，从产品直接融入并规范安全流程换成了‘曲线救国’地强化安全流程，页面和接口设计也有较大变动。由于产品流程设计上的变动导致之前的接口测试和端到端的自动化测试全部都失效，需要重新编写和维护。
　　这个经历挺真实的，自动化是有好处，但是也是有代价的： 在MVP1，特别是POC（Proof Of Concept)阶段的产品建议不要急于做自动化，项目的初期更别尝试做UI层面的自动化。当然对工具的spike是可以的，把框架搭建好，等待特性稳定了，就可以直接加测试用例了。

　　我们选择自动化一定是要考虑项目是否存在客观的现实需求，在动手实施具体的自动化测试之前，一定要对自动化测试的投入产出比做一次客观理性地评估。如上图所示，自动化测试的成本相对单次（或者少量的）手动测试来说是较高的，为了少量的测试活动而做自动化，投入产出比是很低的。需要QA根据项目进度，产品演进程度，测试策略，回归频率等等做一个综合评估，找到出图中交集的点，即何时何种情况团队和产品应该必须引入自动化测试了。因为自动化前期需要投入产品分析，工具框架选型，用例设计，数据环境准备等等，后期还需要持续不断地投入人力进行及时的维护和更新以保证自动化测试的严密性和足够的覆盖率。