CI/CD --- 什么才是真正的自动化平台

近2年在软件开发中比较火的两个术语，一个是敏捷开发，另外一个就是CI/CD了；敏捷开发顾名思义就是“以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发”。那CI/CD（Continuous Integration、 Continuous Delivery、 Continuous Deployment）又是什么呢？

他是一种开发模式，通过自动化的手段来对已经开发的软件进行编译并对软件进行自动化测试，其目的是为了快速、保证质量、更加简单的完成软件的交付。那我们今天主要通过以下几个话题来说明下CD：

1. 为什么在软件测试中引入自动化测试？

2. 测试为何要进行平台化开发？

3. 什么样的自动化测试算是真正的平台化？

4. 什么样的自动化测试有希望实现智能化？

一、为什么要在测试过程中引入自动化测试？

人力成本

自动化测试最明显的一个闪光点就是节省人力，这点对于高度商业化的市场来说极具竞争力，而这也是无论大小公司都在积极的开展自动化测试的原因。

执行速度

第二点就是快速，同样的测试如果是人手工执行可能需要一周才能完成，但是自动化测试能够在一天甚至一个小时完成软件的验证，对于市场来说，早一天发布就有可能时赚的盆满钵满和破产的两种结果。

性能测试无可替代性

第三点自动化测试对于性能的测试更具备极强的竞争力，无论是性能测试中的压力测试还是时间参数测试，人的手工是无法在短时间完成这种功能性能的验证的，而对于车载行业，一点的软件问题都有可能是终端用户生命的代价，这是谁都无法承受的。当然自动化测试还有很多优点，但以上三点我个人认为是自动化测试极具竞争力和影响力的主要原因，也是所有人都想投入自动化测试的理由。

二、测试为何要进行平台化开发？

市场选择

实际上对于这个问题还是很好理解的，对于当前的市场环境来说，虽然每家公司都有专门的部门对用户的需求进行分析，然后选择最可能称为爆款的产品，但是最终结果也许并不能如愿以偿，那最好的办法就是多开发几种产品，快速占领市场，获取市场的喜好，然后实现盈利，公司得以生存。但人力有穷尽，那如何使用同样的人力同样的时间完成更多产品的开发呢？平台化自然而然的被提到了日程。

工作亮点、工作进化

而且对于中层领导来说，这也是可以作为年终述职的亮点；毕竟对于高层来说，他并没有时间去关注详细的开发过程，能看到的就是呈现到眼前的东西。有点扯远了，实际上平台化脚本开发和自动化脚本开发的引入理由并无太大区别，都是为了以最小的成本、最短的时间开发出最多的产品，也是一种市场软件开发的一种进化吧。

三、什么样的自动化测试算是真正的平台化？

这点也是我今天希望分享并且跟大家讨论的一个点，到底什么样的自动化测试脚本算是平台化脚本呢？以下是我的观点，大家如果有更好的见解，欢迎评论区留言一起讨论。

伪平台化

对于大部分公司来说，都是从手工测试、自动化测试最后才会考虑平台化测试；但由于这个过程经历了漫长的时间，并且在做自动化测试的过程中，并没有太多人的人考虑后续的平台化和继承（当然这点在使用Python语言开发的朋友身上出现的可能性少很多），因此最后在实现平台化的时候，很多人误以为在当前已有的自动化测试脚本的基础上套上一个马甲，就是平台化了；无可否认，在增加一层甚至两层、三层甚至更多层的封装，可在极短的时间内看到成效 --- 确实降低了一部分人力投入，但是后续的项目维护、持续开发、项目交接，将是接手人的噩梦，因此我叫它伪平台化。

平台化真容

我认为的平台化脚本，首先从源头上来说，测试点、测试模块、测试功能、平台化（以Autosar网络管理为例：测试点（例：验证上电唤醒后发出第一帧NM报文的时间）、测试模块（例：时间参数测试）、测试功能（Autosar网络管理测试）、测试平台（例：车载网络平台测试））。我说的伪平台化大部分都是通过测试平台的马甲实现调用测试功能，就连测试模块都无法调用，因此对于测试点更无从联系了。各自为政而已。

测试脚本的平台化

测试执行验证软件的脚本就像是万丈高楼的地基，如果地基崩塌，后面所谓的各类平台化、CI/CD都是空中楼阁，因此测试脚本需要满足以下几点：

1. 能够实现函数的公用，减少重复造轮子的概率

2. 测试模块、测试功能之间可以分开控制、互不影响

3. 每个需要维护的测试功能脚本执行互不影响，但是底层有相互联系

满足以上几点，我们在新增测试脚本、测试功能模块，就能实现快速的脚本开发，无需验证所有的底层函数（共用函数已成熟）。并且多个产品之间能够自由组合而无需通过复制粘贴、管理大量的测试功能的工程来实现维护，最大限度的提高脚本开发效率和脚本自由组合。

需求、用例、脚本一致性

如果需求无法和用例对上、用例无法和脚本一致，那可谓是一团乱麻，这个问题大家都知道，但是又有谁真正的想办法去做对应呢？很多做的所谓的需求和用例对得上仅仅是需求点可以在测试用例中找到、用例或者脚本的测试点可以在需求中查出，我想这是远远不够，他们应该是有一种特殊的对应关系，无论是看需求、用例、脚本中任意一个或一块的内容，都能够快速查找到其他两部分的相关的内容，而不仅仅是找得到而已！！！

平台化下调用的颗粒度

大家认为平台化调度的颗粒度到什么样的程度才算真正的平台化呢？个人认为平台化脚本只有能够操作到测试的也就是单条测试脚本的程度才算是真正的平台化；平台只有在能够控制到测试功能脚本、测试模块、测试点的时候，下一步才能实现在CI/CD中结合软件测试实现真正的CI/CD。也只有在做到这样的程度才能算是真正的平台化。

真正的平台至少需要实现以上几点内容才能叫做平台，而非一对乱七八糟的用例加上一堆乱七八糟的脚本然后套上一个所谓平台化的脚本就叫已经实现了自动化测试的平台化。

四、什么样的自动化测试有希望实现智能化？

这个问题我做了一部分，相对于第三部分，这部分算是做的最少的了，不过也已经实现了部分智能化，能够实现自动化测试结果的简单分析并给出分析结论，待测试人员进行进一步确认；实际上这部分如果有大量数据的支撑就是智能化分析的初版。

另外一个要实现的就是软件代码与规范的一致性，当软件代码开发完成后导入实现的需求规范，这样就能顾与第三节中的规范保持一致，这时候CI和CD就能够自动化联系上了。这就是智能化的第二个需要实现的点。

这时候就能够吧整个软件软件开发流程串起来了，软件拿到需求去实现代码开发，然后通过CI自动编译完成后有自动化测试平台接收，自动匹配需要测试的脚本然后自动完成测试，最后通过自动化分析给出初步结论是否能够发布（当然这部分如果通过大量数据对比分析，完成有可能真正的分析结果），实现智能化软件开发。

如果喜欢我的文章来波点赞、关注、评论吧！！！