欧宝体育娱乐平台:别再闭门造车自动化测试了！持续集成自动化大势所趋

　　2021中国互联网大会在北京召开，中国信通院依托云计算开源产业联盟与大数据研究所发布了《中国DevOps现状调查报告（2021年）》。

　　调查结果显示，敏捷已成为软件开发的主流研发模式，超过半数企业学习或实践过Scrum或Kanban；85.16%的企业选择了持续集成。

　　大家想一想，自己公司是不是已经有持续集成的流程？作为测试有没有参与进去？在公司中开展自动化测试，有没有结合到持续集成的流程中？

　　其实自动化测试的最佳实践，就是作为持续集成构建流程中守住底线的关键一环，在完成项目的构建和部署之后，以自动化测试作为最终的验证手段，保障版本质量。

　　所以，别再把自动化测试当做闭门造车的工作了，下面我们就看看怎么把自动化测试集成到持续集成流程中完成吧。

　　那么当真正在公司中开展起来，完成多个用例编写，就要写对应数量的类来完成整个流程的测试，是不是头脑已经开始发胀了？

　　在完成用这种方式实现的自动化测试脚本之后，运行自动化测试又变成了一个大问题，我们需要一个个类去执行这些自动化测试代码吗？这样岂不是跑个自动化还得自己一个个去运行，岂不是就快变成手动执行了？

　　为了解决这个问题，我们首先得从两个角度出发，完成自动化测试的优化和演进：

　　1、用例编写维护，简化自动化测试用例编写过程，让编写自动化测试门槛更低，更易理解。

　　2、用例运行调度，整合自动化测试多个用例的执行，让执行自动化测试更加优雅便捷。

　　上面我们提到了要解决自动化测试维护和运行问题的两个痛点，来看看如何解决吧

　　解决用例编写过于复杂的问题我们可以从关键字驱动理念入手，将常用的自动化测试操作进行封装，形成关键字，在编写新用例和维护的时候，复用关键字来进行调用。从而自动化测试脚本可以优化为如下形式：

　　显而易见，原本冗长的代码被简化成了关键字方法调用之后，测试数据和测试的动作进行了规整和分离，易读性和维护性都有大幅度的提升。

　　但是并不是所有的同事都能编写代码，并且这样管理测试所需要使用的操作数据，通用性并不是特别强，有没有办法进一步降低自动化测试用例的编辑门槛？并且让用例可读性再次提升？同时第二个痛点，多条用例进行执行如何调度？

　　针对上述问题，我们考虑再做优化，引入数据驱动的设计理念，用平时最常用的用例编辑模式——excel来记录编写的自动化测试用例。

　　引入数据驱动的核心，在于将代码操作和业务流程数据完全分离。如下是使用数据驱动理念通过excel来管理测试用例的例子，多条用例直接在excel中顺序添加，也可以用多个sheet页来进行交互管理。

　　当然用例通过excel写完之后，还得通过代码来进行调用让用例能够执行起来，因此运行中需要完成excel读写的实现以及将填写在excel中的用例步骤流程转变为自动化测试脚本执行：

　　通过数据驱动的优化，前面提到的两个痛点已经解决，用例的编写以更便捷易懂的excel来进行操作，而批量的用例运行则在excel中完成编写之后，直接可以在数据驱动框架中调用来完成批量运行。

　　至此我们对于自动化测试的优化已经完成，接下来，该看看如何把自动化测试引入持续集成的流程中了。

　　持续集成(CI Continuous integration/CD Continuous Deployment)的含义其实是在研发过程中团队开发成员持续性的将他们的工作集成到一个完整流程中，通常每个成员每天至少集成一次，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。持续集成的主要流程如下：

　　因此自动化测试作为其中最后一道关卡，用来验证每次持续集成流程所构建产生的项目是否能满足质量标准，并尽早发现项目中的问题。

　　因此持续集成的流程必然首先经过源码构建和项目部署两个流程，再完成自动化测试。

　　目前市场占有率最高的持续集成系统是Jenkins，因此接下来要做的，就是把完整的持续集成流程在Jenkins上搭建起来。

　　将自动化测试脚本打包为可执行jar，通过命令完成调用执行，或者结合testng等测试框架执行。

　　研发体系中的构建流程的操作到此完成，最后，在构建触发器中加上定时构建的设置，完整的持续集成流程也就搭建好了。