共计 6703 个字符，预计需要花费 17 分钟才能阅读完成。
2023 年 6 月 16 日，2023 上海国内嵌入式展（embedded world China 2023）圆满闭幕。龙智参加此次展会并展现了其针对嵌入式行业的 DevSecOps 解决方案，帮忙企业实现合规、可追溯、高效优质、繁多可信数据源的嵌入式开发。
展会期间，龙智资深 DevSecOps 参谋巫晓光带来了题为“更好、更快、更平安：嵌入式开发中的最佳实际和工具链构建”的主题演讲，受到参展观众关注。
以下是残缺文字实录（有删改润色）：
大家好，我是龙智的技术工程师巫晓光。明天十分荣幸跟大家分享嵌入式开发中的心得与领会。我分享的主题是“更好、更快、更平安：嵌入式开发中的最佳实际和工具链构建”，次要分为三个局部，首先是版本控制，其次是品质合规，最初是测试自动化。
版本控制
俗话说有人的中央就有江湖，有开发人员的中央就会用到版本控制工具，这曾经成为了业界共识，版本控制是团队合作的根底。
当企业规模较小时，个别应用一些开源的版本控制工具，比方 Git、SVN 等。因为这个时候客户规模较小，数据量不大，业务也比拟繁多，开源的版本控制工具可能根本满足需要。但随着企业规模的扩充，数据量和用户都随之增长，业务也更加简单，版本控制工具就会面临一系列的挑战。
版本控制系统面临的挑战
首先是分支治理的难度减少。通常来说，咱们应用的分支类型有主分支、开发分支以及公布分支等。如果有多个性能在并行开发，就会拉出很多性能分支，到我的项目开发的前期，一个我的项目就可能有几十个分支。保护这些分支间的关系会变得非常复杂，如果只用命名的形式进行区别，而没有一个图形化的界面去展现分支关系，可能会随着时间推移而遗记分支间的关系。
另外，分支合并也成为一个难题。目前市场上的一些版本控制工具，分支合并能力很弱。大家可能都有相似经验，在分支合并时，会引入一系列不必要的抵触，须要人工去解决。往往一个公布周期的前几天都是在解决这些抵触。
第二个挑战是数据量过大。龙智的一些客户前期数据量达到几十、上百 T。
数据量达到这个级别，面临的问题就是数据提交速度会十分慢，例如一些 10G 以上的大文件，提交速度十分迟缓，并且常常提交失败。
数据量过大还会导致存储问题。单个库是无奈接受如此之大的数据量的，只能将数据进行拆分，再放到各个系统中，这导致了前期保护的老本成倍增加。到了开发前期，可追溯性也成为一个问题，因为数据扩散在不同的零碎中。
面临的第三个挑战是跨地区合作。企业规模扩充后，我的项目组成员散布在全国甚至寰球各地的状况。在这种状况下，面临最显著的问题就是跨地区提交。因为带宽或网络稳定，可能会造成提交延时或失败。
第四个挑战来自于平安及审计需要。开源版本控制工具的权限控制能力较弱，比方 Git 的权限管制是到我的项目级别，SVN 是到文件夹级别。在我的项目中，不免有一些重要文件须要进行严格的拜访权限管制，这样就须要版本控制系统的权限管制力度细化到文件级别。并且，如果在审计方面没有齐备的日志，前期定位、追溯问题都会非常麻烦。
当企业面临的问题越来越多时，其实是在开释一个信号：目前所应用的版本控制工具曾经无奈满足企业的业务需要了。同时，也会发现工作效率在降落、治理成本增加。尽管在版本控制工具上节俭了开销，但无论是老本治理还是工作效益，都造成了很大的损失，这是隐性的老本。
所以，此时要扭转观点，把版本控制工具放在更重要的地位，须要为企业寻找一款更高效、更平安的版本控制工具。
强健的版本控制系统是研发流程的外围
强健的版本控制系统是研发流程的外围。为什么这样说？企业，特地是软件企业，大部分的劳动成果（比方设计材料、代码、配置项、生成物等）最终都会转换成数字资产，而这些都投入了大量工夫和资金，所以数字资产很重要。
其次，所有的研发工作都是围绕着数字资产开展的。作为治理这些资产的版本控制工具，更是处于研发流程外围地位。它为团队围绕数字资产开展的工作保驾护航。一款好的版本控制系统能够在繁多的平台上平安、高速地治理您的所有数字资产，无论资产的类型、地位、大小以及体量。
那么，如何评判一款版本控制工具是强健的？我认为能够从以下几个方面来思考。
首先是性能。简略列举一下，第一点，须要有很好的伸缩性。当企业规模只有几十名用户时，应用都很不便。但企业规模扩充，就须要版本控制系统可能撑持上万名用户。或是当数据量减少到几百 T 的时候，版本控制系统须要实现平滑的降级。第二点，对于寰球团队单干的状况，则要求版本控制系统是灵便的分布式部署，以满足团队间的高效合作需要。第三点，须要撑持每天数以千计的流水线构建。企业每天可能有成千盈百的流水线在构建，对于版本控制系统的性能来说也是一个挑战。第四点，当初的企业很多依赖于应用 Git 的开源我的项目，那么，版本控制系统须要提供一种可能性，既能兼容前端的开源工具，又能通过版本控制系统弱小的后盾为后端提供撑持。最初，是对立的企业级灾备打算。备份须要可能轻松保护，一旦发现问题事变，也能疾速复原，最大水平升高企业的损失。
而后是平安。版本控制系统须要有非常灵活、弱小的权限管制机制，可能在文件级别进行版本控制。并且须要非常灵活，可能通过组的形式将权限下放给真正理解我的项目的人。审计方面须要有齐备的记录，谁批改、谁拜访、何时批改、何时拜访等都须要记录在册，这是前期审计的根底。
最初是界面敌对。版本控制系统须要与 DevOps 生命周期中各个环节的工具进行良好地集成，例如 IDE 工具、代码评审工具、需要管理工具以及前期的流水线集成。集成后即可推动 DevOps 的各个环节，减速产品迭代。
我举荐 Perforce 的旗舰版本控制工具——Helix Core。这是一款高效、平安的版本控制工具，也深受客户的青睐。客户英伟达在评估 Perforce Helix Core 时提到，Perforce Helix Core 作为他们惟一的可信数据源，是十分重要的存在。
品质与合规
代码品质对企业来说十分重要，尤其对嵌入式行业的企业来说更为重要。因为嵌入式的企业软件波及到航空航天、医疗、汽车等行业，这些行业有着十分严苛的行业平安规范。家喻户晓，再好的软件工程师都无奈防止 Bug 的产生。既然无奈防止，那咱们能扭转什么？一是发现 Bug 的机会，二是发现 Bug 的办法。
代码品质与企业老本非亲非故
这张图展现了代码品质和企业老本的关系。横坐标代表了软件的各个生命周期，包含开发、单元测试、功能测试、零碎测试以及公布阶段。深蓝色的曲线表明，有 85% 的 Bug 都是在开发阶段产生的。再看一下橙色的曲线，它表明了 Bug 在测试阶段被发现，能够看到橙色曲线在开发阶段简直没有发现 Bug。再来红色曲线，它代表修复 Bug 的老本，能够看到在开发阶段，修复 Bug 的老本非常低，到测试阶段老本就成倍增加了。到前期，比方产品上线后，再发现 Bug，修复的老本将呈指数级回升。
这一点置信大家都深有体会。在开发阶段，Bug 是最容易被修复的，因为在开发环境中很容易重现 Bug。到了测试阶段，因为测试人员须要筹备大量的测试用例和测试数据，另外还波及到开发人员的公布老本，以及开发与测试的沟通老本，所以会成倍增加。产品上线后再发现问题，（修复老本）就会呈指数级增长，起因有几个方面。
一是产品曾经对客户造成损失，这时波及到经济抵偿的问题，比方汽车行业，一旦发现汽车品质问题，就须要大量召回。二是在客户现场发现问题，则须要技术支持人员驻场，驻场自身也有老本。最令人头疼的问题是，咱们达到客户现场后发现，Bug 很难复现。它往往出现一种随机性，很难捕获。受制于线上环境，咱们无奈模仿大量数据，这时须要就现场搭建模仿环境。现场搭建须要破费数天，在这期间 Bug 修复是没有停顿的。这时，您可能开始思考，有没有可能将发现或修复 Bug 的机会左移到开发阶段呢？
更早地发现问题
目前，一些企业采取的做法是人工代码审核，这可能在开发阶段发现一些问题，但有很大的局限性。首先，过多的依赖人工的教训。目前，龙智的一些客户采纳的做法是人工审核，这种办法在肯定水平上能够在开发阶段发现问题，但其实还是存在很大的局限性。大家也可能有相似教训，在审核时，没有强制性要求，咱们就会提出一些无关痛痒的问题，例如代码命名不标准、大小写不标准等。另外，因为代码少则几万行，多则上百万行，人工审核难以全面地笼罩所有代码。这时，咱们可能针对一些外围代码进行审核，而且审核成果也不显著。
行业合规规范
我的倡议是引入动态代码扫描工具，它能够无效地在代码阶段发现代码品质问题。先简略介绍一下动态代码扫描工具的原理。它的原理是利用一些权威的、常见的代码规范（例如 MISRA、AUTOSAR 等），以及成熟的算法来扫描代码，并发现品质问题。
罕用的代码规范
再来介绍一下代码规范。其实代码规范的作用更像是一个紧箍咒，将代码框定在一个平安的范畴内。它限度了一些开发行为，从而防止一些开发中常见的谬误，以及防止了安全隐患问题，包含常见的数据净化、内存透露等。如果说代码规范是紧箍咒，那么动态代码剖析工具就是会念紧箍咒的唐僧。
一款好的动态代码剖析工具应该合乎什么条件？又该如何抉择动态代码剖析工具呢？首先，它须要误报率、漏报率低，要害的谬误不能漏报。它也不能引入不必要的报警，烦扰开发人员。第二，这款工具的查看规定须要更全面，尽可能多地笼罩常见谬误。第三，扫描速度快。因为代码的规定和规范通常有成千盈百条，代码又有几百万行，对于动态代码剖析工具来说，工作量是两个数值的乘积。所以，它须要有成熟的算法来放慢扫描的速度。第四，须要对开发人员敌对，最好是开箱即用的。C、C++ 编译器有上百种，这就须要动态代码剖析工具能与编译器进行严密集成，并且不须要人工进行手动适配。最初一点，它应该可能轻松地与 CI 流水线工具进行集成。
动态代码剖析工具一方面可能进步代码品质，一方面也能够帮忙满足行业合规性要求。汽车、航天航空等行业通常面临着严苛的代码合规性要求，它们须要通过各种合规认证，常见的规范有：IEC 61508（通用工业，国防）、ISO 26262（汽车）、EN 50128（铁路）等。
我解释一下行业标准和代码规范之间的关系。因为很多刚开始应用动态代码剖析工具的用户可能会混同这两个概念。简略地来说，这两者之间是执行和被执行的关系。行业标准通常比拟形象、宽泛，它须要一个具体的执行者。而具体的执行者就是代码规范里的一些规定。
这里要提到一点，最上面一行（CERT、CWE 等）是平安规定。
行业标准认证
行业标准认证会让用户感到非常头疼，因为认证是件麻烦事，规定很形象、很宽泛。企业不晓得该如何执行，该匹配什么规定。这里来看个简略的示例。英文是 Enforcement of low complexity，中文意思是代码执行须要低复杂度。大家都晓得这句话的意思，但无从下手。什么叫低复杂度？如何掂量？以及须要匹配什么规定去执行低复杂度？这些都短少一个具体的阐明。
合规领导
动态代码剖析工具中的合规指导书能够提供帮忙，它对合规的规范进行了具体的阐明。
上图是 Perforce 动态代码扫描工具 Helix QAC 对于 ISO 26262（汽车）规范的具体阐明。右边是 ISO 26262 的一些条款，左边放大的图中则是具体阐明。针对低复杂度，能够应用圈复杂度和门路复杂度两个指标来掂量，也能够应用 MISRA 的规定，本书中都有具体阐明。
另外，在申请合规认证时，还须要筹备一系列资料。动态代码扫描工具的平安手册中已包含了这些资料，包含工具自身的认证证书、产品的认证报告、工具的覆盖率详情、如何适配认证规定的阐明，以及生成报告的插件。通过合规指导书，动态代码扫描工具可能帮忙咱们更不便、更疾速地通过行业的合规认证。
SAST 常见部署场景
动态代码扫描工具有三个常见的部署场景。首先是在 IDE 中即时剖析。利用动态代码扫描工具中的 IDE 插件进行即时剖析，让开发人员可能边写代码边扫描代码。第二，在代码提交时，代码仓库能够触发流水线，进行增量 / 全量查看。第三，每天对主分支进行查看。我举荐将第一、二点作为可选项，第三点我心愿作为企业的必选项。在每天对次要分支进行查看的同时，还能够设置一个品质门限。
另外，像 MISRA 这样的规定十分严苛，一开始就放开所有规定是不事实的，这样可能造成一行代码扫描出几十个谬误的状况，导致开发阶段解决 Bug 的阻力很大。所以我的倡议是，刚开始应用动态代码扫描工具时，先启用一些优先级较高的要害规定，从而升高阻力。当开发人员的品质意识进步后，再逐步把规定调到更加严格。
在这里，我举荐两款 Perforce 旗下的动态扫描工具，一款是 Helix QAC，另一个款 Klocwork。这两款工具各具特点，QAC 更能满足合规性要求，它的代码规范覆盖率更高。它对于 AUTOSAR 的微覆盖率已达 96%，这是十分高的。并且它领有 30 多年的历史，专一于 C /C++ 语言的代码剖析，在嵌入式开发中颇负盛名。
Klocwork 反对多种语言，并能很好地反对百万行甚至千万行代码的大型项目。除此之外，它的界面也非常敌对，易于应用。
大家能够看到客户对 QAC 的评估——咱们对 HelixQAC 印象粗浅，因为它发现了其余工具脱漏的问题。而 Klocwork 则是在大型项目上更具性能劣势。
测试自动化
测试对于代码品质来说十分重要。目前，很多企业次要采纳手动测试的办法，这也催生了很多挑战。
人工测试面临的挑战
首先是软件迭代速度放慢，无奈在短时间内实现大量测试用例。当初的软件迭代速度十分快，可能一周公布一个版本，这就须要进行大量的回归测试。如果全凭人工，无奈笼罩这么多测试。另一个常常会呈现的状况，就是在筹备上线的前几天，忽然发现了 Bug，须要紧急修复。这时，咱们只能对软件进行冒烟测试，或是针对次要性能进行测试，无奈笼罩大量的测试用例。重复性的测试通常比拟繁琐干燥，这会减少测试人员的累赘。人工的疲劳或忽略也会导致测试后果覆盖率低，不牢靠。并且，性能和平安测试都是人工测试单薄的中央。
既然人工测试面临这么多挑战，是否能够思考引入自动化测试工具来解决问题呢？一起来看下自动化测试的现状。
自动化测试
首先，自动化测试无奈齐全取代人工测试。自动化测试更多是针对一些重复性测试，例如回归测试等，效率优于人工测试。第二，自动化测试的占比在一直减少。很多企业其实也在开发自动化测试的框架，但这种框架的学习老本较高，对于测试人员的要求较高，脚本保护也很麻烦。所以很多企业会抉择无代码 / 低代码的自动化测试工具，通过录制、回放以及查看的性能实现测试，不须要编写脚本，升高测试人员的学习老本。
这里提到的自动化测试包含两个方面，一是 UI 自动化测试，也就是界面测试，另一个是 API（接口）测试。很多医疗软件有人工交互的界面，还有上位机也会简略的做一些界面，这些都是应用 UI 自动化测试的场景。
UI 自动化测试工具抉择
一款好的 UI 自动化测试工具应该具备哪些条件？首先须要可能反对多平台测试。当初的产品出现平台多样化的趋势，有桌面、Web 和挪动端等。甚至还有一些工业设施和穿戴式的设施，UI 自动化测试工具最好可能对所有平台进行撑持。第二点是须要可能反对多种技术框架。当初的技术框架层出不穷，须要自动化测试工具尽可能多的集成和兼容。第三点是对象辨认能力强，精确的定位控件。这也是很多自动化测试工具的弱点，许多工具的对象辨认能力较差。在对控件属性进行批改后，自动化测试工具可能无奈辨认，这时就须要应用脚本或从新录制，升高了工作效率。最初是须要不便地与 CI/CD、版本治理等工具集成。
合乎这些条件的 UI 自动化测试工具就是 SmartBear 的 TestComplete。“在回归测试方面，它为企业节约了大量工夫。平时须要三天的测试当初三小时就能实现。”这是客户对 TestComplete 的评估。
API 自动化测试工具抉择
另一个方面波及到 API 接口的自动化测试。API 接口是非常适合应用自动化测试的，因为 API 接口通常是纯数据结构，这种构造自身是须要机器读取的一种语言。
那么，一款好的 API 自动化测试工具须要具备哪些条件？首先是须要反对多种协定。通信协议多种多样，应用层的协定也是如此，这些都须要工具能反对。第二是可能疾速构建测试步骤，须要工具有一些图形化的界面帮忙疾速设置断言、检查点，以及疾速搭建测试步骤等。第三是反对内置数据字典，能够帮忙疾速主动生成平安测试。最初一点是可能模仿各种实在场景进行性能测试。
API 自动化测试工具我举荐 SmartBear 的 ReadyAPI。
客户对这款产品的评估中提到：“ReadyAPI 就是咱们技术的外围”。
我明天的演讲就到这里，谢谢大家。
