2023QECON参会有感

前言

今日参加了在深圳举办的QECON全球质量&效能会议，为期两天的时间里听取了很多业内先进的软件工程实践案例以及理论知识，以下做出相关总结。

收获

关于AI

毫无疑问Chat-GPT成为了本次大会上最为火热的讨论话题，开局QECON朱少民老师就指出GPT-4将开启 “软件工程3.0” 新时代，今年是软件工程3.0元年。接下来茹炳晟老师关于AI的分享“LLM时代的软件研发机遇和进化”，基于自己的相关实践讲述了LLM（注：理解为类似于GPT的大语言模型即可）的现状以及在IT领域会产生什么样的影响，并指出IT行业在LLM加持下的各种可能性：

l 智能代码提示

l 代码片段智能生成

l SQL语句的智能生成与调优

l 更高效更精准的静态代码检查与自动修复

l 智能辅助的代码评审与代码重构

l 单元测试和接口测试代码的自动生成

l 更高级的重复代码检查

l 失败用例的自动分析与归因

l 更精准的技术问答

l 。。。

不禁引发思考，在LLM时代下，我们应该何去何从，但是以目前GPT的形式来看，还是离不开人为的干预，因为目前仍然是以上下文的形式进行交流，我们想要GPT给我们输出一些东西，那么我们必须精准描述，但是现实又是“想到的永远比说出来的多，说出来的永远比写出来的多”，因此如何使GPT以当前上下文继续回答后续的问题可能是接下来要做的事情，毕竟GPT接受的token是有限的，我们不可能每次都将所有上下文全部传输一遍，关于这个问题茹炳晟老师提到了lang-chain框架，可以做到类似的实现，值得我们去研究如何利用该框架让LLM给我们提供定制化服务；同时他还提出了“Prompt即代码，代码不再是代码；从 prompt to code 到 prompt as code”的新颖观点，或许我们马上只需要考虑如何写prompt而不再需要去学习编程语言了，prompt会成为未来的编程语言（注：prompt可以理解为我们与大语言模型的交互）。

主会场最后分享的嘉宾是华为的AI-LAB负责人，他分享了华为内部基于github自己训练的一个关于代码生成类的大模型AI，实现原理类似于copliot，看起来效果还不错，但是我认为这是在重复造轮子的工作，毕竟copliot已经可以使用，并且马上会推出copliotX，没有必要自己花费时间以及资源去做业界已经很成熟的工具，并且也不适用于中小公司。

总的来说，AI带来机遇，同时也带来了挑战，但是我不认为我们需要去担忧AI替代我们之类的事情，只要我们不断学习，那么AI只会成为辅助我们的工具而无法替代我们。

技术趋势

总体来说，大家分享的案例可以划分为AI化、自动化、精准化，下面从这三方面来进行总结。

AI化测试

大会中关于AI赋能测试也有着相当高的热度，但是在听之前我是没有报太大期望的，毕竟GPT刚刚火爆出线，想运用到实际中还是有着颇高难度的。

听了几个关于AI赋能测试的分享，大家在做的事请确实跟GPT没啥太大关系，多为低代码平台的建设，不过龙测的通过上传录制视频转自动化用例的还是有一点新颖的技术，南京银行关于PC自动化使用的是OCR文字识别技术进行操作也符合预期（网上关于PC自动化的方案分享还是比较少的），亮点是还做了ai控件框识别（下拉框、输入框等），不过大厂做的事情不太一样，比如华为云。

华为云的web相关测试运用到了模型训练，只不过是基于华为自己的代码数据，有接口和UI两方面，华为云接口测试（100W+组合测试）主要是分析服务中的所有api节点的入参出参，然后根据上传的接口文档自动分析各个接口可能存在的上下文关系然后自动拼接，然后进行测试，据他们自己统计可以覆盖80%的接口；ui自动化相关比较类似，分析页面中存在的不同控件，然后做不同组合进行测试。

虽然大厂用的技术看起来很高大上与高效，但是并不适合大多数公司，因为正常情况下我们并不会出现几十万甚至上百万的测试用例，他们使用AI建模是不得已而为之，并不能保证测试充分。

AI赋能相关我们能做的尝试还是有很多的，比如前文提到的用例自动生成与根据代码自动生成单元测试脚本等等，感觉这两年测试领域应该会发生一些比较大的技术变化。

自动化测试

自动化测试一直是QECON的重要话题之一，其实想想也是如此，时代的发展就如工业革命般会推动所有领域的自动化发展，只不过自动化测试领域已经非常成熟了，好久没有出现一些比较新颖的技术，大家近些年做的事情多是一些低代码平台的建设，现在的主要问题已经不再是如何进行自动化而是如何运用自动化了，这些案例分享中理想汽车引起我的注意，想看一看新势力行业他们在研究什么。

智能座舱，近些年热点话题之一，新势力造车领域常常提起智能座舱，即车内智能空间，相对于传统车内空间，多了很多智能交互以及娱乐设施，比如语音交互、看电影甚至是连接switch，这其实是给测试人员带来了很大挑战，因为首当其冲的是硬件问题，一套完整的硬件要数十万甚至上百万，因此从成本上注定不会有太多测试台架，这就可能会导致测试时间不够，因此如何去合理的运用自动化在空闲时间进行测试是比较关键的，理想汽车的测试团队就做了这样的事情，他们自建硬件台架，建立专属实验室，扩大团队测开规模，并且仅仅用了几年就做到了使用自动化技术为公司年节省2500W，成为目前业界内智能座舱测试的优秀实践者之一。

其实听完理想汽车的分享，还是比较震撼的，感叹于他人敢于尝试，且不断创新的勇气，他们真的一步一步完成了传统测试的转变，大家都在向前走，不断学习，我们也应如此。

精准化测试

精准测试的理念也提了好多年了，但是其实网上的资料并不多，目前网上并不能找到成熟的案例分享，我想大概是有几方面吧，首先是编程语言多样化，一个产品从前端到后端可能运用多种语言，对于代码的变化以及链路分析无法统一，其次是没有大厂或者开源的精准测试平台分享出来，大家大部分都在闭门造车，但是仔细思考下，每家公司的解决方案可能都是定制化的，基于自己独有的代码构建，可能对他人无用。

对于测试行业而言目前现状大部分是增量开发，全量测试，因此精准测试仍然是我们测试领域需要去探索的地方。

大会上主要有3个关于精准测试的分享，首先是阿里巴巴的案例，提到一个观点，精准测试其实是两个问题的集合，即这段代码我们要不要测试以及我们怎么去测试，我认为要不要测试是精准测试框架的底层分析能力，而如何测试则是我们在做精准测试时候基于底层推理能力做的测试解决方案。

案例中优酷通过线上流量进行代码调用分析，且通过流量建立起用例与业务的关联，同时根据改动的代码逆向推荐用例自动执行，完成精准测试，我觉得我们可以参考的地方就是他们使用流量来进行用例与业务的代码关联，因为在精准测试中，关联与推荐是比较重要的地方，而可能大部分解决方案都是手动进行关联的，我们或许也可以通过线上流量进行代码与业务的关联实现，同时他们还有一个根据接口热度评估是否需要代码review的评估系统，对于经常被调用的业务接口，如果监测到改动就推荐需要代码review，这点我觉得我们同样可以借鉴，降低线上风险。

第二个是小米的精准测试分享，他们主要是利用了模型训练进行影响范围分析，感觉有一些滞后性且并不适用于其他公司，因此不做赘述。

最后一个是跨越新科技的分享，总体上来说跟我们目前精准测试平台运用的技术栈基本一致，有一些新颖的点值得我们借鉴，他们会根据commit的msg进行代码与业务的关联，比如每次提交必须关联task_id或者bug_id，这样的话就可以与其他系统联动，知道本次提交的大致范围，而我们目前的提交还是比较随意的，没有固定格式，且没有任何代码review，跨越新科技目前做到的是检查commit格式与单元测试代码覆盖率，如果达不到门禁是无法入库的，整体的开发流程还是比较敏捷与现代化的。