标签: 敏捷开发

在上一篇文章中，我们对 DDS 协议测试的策略、方法和工具进行了详细的介绍。本文旨在进一步探讨如何利用这些方法和工具搭建实际的测试环境，并执行测试，进而揭示可能遇到的各类问题。 被测协议栈简介 在本次测试中，被测协议栈选择了一个在汽车行业内广泛使用的开源 DDS 产品。 近年来随着开源软件社区的不断发展和成熟，越来越多的整车厂在选择 DDS 协议栈实现时，开始青睐开源产品。相比商业化的 DDS 协议栈，开源产品具有显著的成本优势。此外，使用开源产品还可以让整车厂获得更大的自主可控性，以便根据自身需求对协议栈进行定制和优化。 然而天下没有免费的午餐，选择开源 DDS 协议栈也意味着使用者必须承担起产品质量的责任。与商业化产品不同，开源产品通常没有专门的团队负责质量保证。因此，开源 DDS 协议栈的使用者必须投入额外的精力和资源，甚至组建专门的软件团队，来全面评估、测试和维护所选择的开源产品，以确保其功能和性能满足汽车行业的严苛要求。 在本篇文章中我们试图准确地识别出可能存在的问题，希望为汽车行业用户在选择开源 DDS 协议栈时提供实用的参考。 测试环境搭建 被测的 DDS 协议栈部署在一台运行 Ubuntu 操作系统的 x 86 服务器上。这种部署方式能够为 DDS 协议栈提供一个简单、稳定，且一致的运行环境，避免资源或网络配置错误等原因导致的测试结果不可信。 同时，为了全面评估 DDS 协议栈的功能和性能，我们在 DDS 之上部署了两个专门设计的测试应用程序。这两个应用程序的主要目的是模拟真实场景下的应用程序对 DDS 接口的调用，以验证 DDS 能够正确地处理各种请求并返回预期的结果。通过这种方式, 可以全面检验 DDS 的接口是否符合 OMG DDS 标准，以及是否能够满足汽车行业的特定需求。 为了实现对测试过程的自动化控制和管理，我们在上位机中开发了一套专门的测试脚本。这些脚本负责向 DDS 测试应用程序发送各种测试指令，根据预定的逻辑对测试应用程序的行为进行编排和调度。测试过程全自动化，无需任何人工干预，能够确保测试过程的一致性和可重复性。 此外，为了方便工程师对测试用例进行管理和监控，上位机软件还提供了一个直观的图形化界面。通过这个界面，测试人员可以轻松地创建、编辑和组织测试用例，并实时监控测试的执行状态和结果。 图1: DDS测试环境搭建 需要强调的是，测试环境可以根据用户的具体需求进行灵活地配置。比如将 DDS 测试程序部署在一个或多个真实的 ECU 中，以帮助我们发现系统性的网络配置问题、兼容性问题或性能问题等，包括防火墙、IP 地址、端口号、TSN 约束、时间同步、网络拓扑结构问题，DDS 中间件与不同硬件和软件平台之间的兼容性问题，也包括吞吐量、延迟、资源占用等指标。从而全面评估 DDS 分布式系统在实际应用场景下的可靠性、兼容性和性能表现，为系统的开发和优化提供重要的依据。 测试用例介绍 测试用例覆盖了 OMG DDS 规范中定义的所有软件接口，共 406 条测试用例，内容如下： 接口行为测试，包括正常调用时的行为测试，以及错误调用的故障行为测试，共计 353 条用例 QoS 测试，即 OMG DDS 中定义的各项 QoS 的功能测试，共计 53 条用例 关于性能测试，由于 DDS 的性能很大程度上取决于硬件平台的性能和资源情况，以及操作系统的调度和管理机制，故在测试服务器中得到的性能测试结果与实际系统的性能表现可能相差很大，故本次测试不包含性能测试。 测试结果分析 概览 本次测试共计执行 406 个测试用例，通过194个，失败 212 个，通过率为 47.78%。如下为各模块的通过情况。 图2: 测试结果概览 问题示例 1. 功能缺失 如下表格列出了部分当前版本 DDS 缺失的接口。这些缺失的接口对于 DDS 分布式系统的功能和性能具有直接或间接的影响。重要的是，开发者文档可能并未明确指出这些接口功能的缺失，这种情况可能会对系统的稳定性和可靠性带来潜在风险。因此，用户在使用 DDS 时需要对这些潜在的缺陷保持警觉，并采取相应的预防措施。此外，用户应当积极参与开源社区讨论，关注产品的更新日志，以便及时了解和补充这些关键接口的功能，从而降低系统运行中的不确定性和风险。 表 1: 功能缺失问题示例 图3: 功能缺失问题的测试报告示例 2. 行为错误 当开发者根据官方文档调用特定 API 时，软件表现出的行为与文档描述不一致。这种不一致性可能表现为返回错误的结果、触发未预期的副作用或完全无响应。这种情况下，开发者不得不投入大量的时间去排查和定位问题。 表 2：API 行为错误示例 图4: 行为错误测试报告示例 3. 异常终止 此类问题指的是当应用程序在某些场景下调用特定接口时，DDS 中间件出现异常终止。这类问题的严重性在于其难以被发现、排查和修复。问题的隐蔽性在于异常通常只在特定的条件下触发，这些条件可能包括特定的数据模式、并发级别或资源使用情况，使得在常规测试中难以触发和识别。同时，即使问题被成功识别，修复工作也同样困难重重，这需要精确修改复杂的代码逻辑，还需要确保不会对 DDS 的其他功能造成负面影响。 由于 DDS 中间件作为系统的基础软件，其稳定性对整个系统的运行至关重要。同时，基础软件的不稳定性会对上层应用和最终用户产生连锁反应，极大地影响整个系统的质量和用户体验。因此，解决 DDS 中间件的异常终止问题，不仅是提升软件质量的技术挑战，也是确保系统整体稳定性和可靠性的重要一环。 表 3: DDS 软件异常终止问题示例 总结 经过本篇文章的介绍，相信读者已经对DDS的协议测试以及可能存在的问题有了大概的了解。 在敏捷开发模式下，软件需求不断增加，软件系统的规模和复杂度也在不断增长。然而，许多关键问题（尤其是性能问题）只有在软件达到一定规模和复杂度后才会暴露出来。一旦发现这些问题，修复的成本往往非常高昂，因为任何基础软件的改动可能会影响到整个系统，牵一发而动全身。 相比之下，如果在项目早期就能够模拟实际的应用场景，并对 DDS 进行全面的功能和性能测试，开发团队可以深入了解 DDS 的行为特点，甚至软件缺陷，识别性能瓶颈，从而及时调整设计，优化实现。这种“前置”的测试方法不仅能够显著降低后期的修复成本，能够提高整个系统的质量和可靠性，帮助系统应对未来的挑战。 本文介绍了南京臻融科技有限公司（以下简称“臻融科技”）开发的DDS协议测试工具。臻融科技在过去十年里，一直致力于DDS产品及其相关工具链的自主研发，并且在国内关键行业领域取得了最高的市场份额。这款DDS协议测试工具在DDS研发过程中已经历了近十年的不断迭代，证明了其产品的成熟性和可靠性。臻融科技与北汇信息的合作，旨在将这套工具引入汽车行业，以协助客户建立DDS测试能力，提供高品质的测试服务和相关培训，进而加快DDS在汽车行业的推广和应用。

D ocker 简介 Docker是一个开源的应用容器引擎，它可以实现让开发者打包他们的应用、依赖以及配置到一个可移植的镜像中，并且可以发布到任何可运行Docker的Linux或Windows操作系统的机器上，并可以无需再次进行配置便完美执行。Docker容器是使用的沙箱机制，任何容器之间的创建、运行和关闭不会相互影响，相互之间也不会有任何接口。容器和虚拟机虽然都使用虚拟化技术，但容器并不是模拟一个完整的操作系统，而是在宿主机操作系统上应用虚拟化技术，可实现软件应用的秒级启动和响应，相比而言，虚拟机冗余步骤多、启动太慢、占用内存硬盘资源，过于笨重。 在敏捷开发模式越发流行的现在，Docker技术的使用也越发普遍，开发过程中对迭代版本中的代码的测试成本也逐渐增长，如何方便快捷地对代码进行测试也随之成为了一个越来越值得关注的问题。 在众多种类的代码动态测试工具中，北汇信息所采用的是Vector旗下的代码动态测试工具—VectorCAST/C++。 VectorCAST/C++工具是德国Vector公司的一款白盒测试工具，主要用于实现代码的单元测试和集成测试。工具最大的特点以及优势就在于经受了多个大型量产项目的实践，证明了工具对C++高阶特性、Linux系统和CI平台的强力支持。 那下面为大家介绍VectorCAST这款强力的动态代码测试工具在Docker场景中的使用。 VectorCAST 使用 基于Docker技术进行开发，实际情景一般是代码与编译环境同时部署在镜像中，或是代码和编译环境分开部署在本地服务器和镜像内，那么这也导致在使用工具时可能会采用不同的方式。 一、挂载工具方式 在使用多个Docker镜像进行代码版本迭代或控制的开发场景下，不需要将VectorCAST工具先放置到镜像中，而是使用挂载的形式，将工具在启动容器时挂载到对应容器中，以实现在容器中对工具的使用，此方式大大减少了工具重复的安装过程，并且实现同一个工具对不同镜像的复用。下面简要说明使用的流程。 容器的启动 参数解析： 1、docker:Docker的二进制执行文件。 2、run:与前面的docker组合来运行一个容器。 3、-v:设定共享目录，为了将安装包保存到容器中，需要指定目录。D:\Docker\Data指本地目录，可以自定义；/dev/shm是指容器中的目录。将需要复制到容器中的文件放置到D:\Docker\Data中，在容器中就可以进入/dev/shm来访问这些文件。 4、-i: 以交互模式运行容器 5、-t: 为容器重新分配一个伪输入终端 6、-e:设置环境变量 在启动容器时将工具所在的目录通过-v选项挂载到容器内。 修改工具启动文件 工具在容器内打开后使用的是容器内部的文件树，所以需要将启动文件中对应的路径进行修改。 工具启动与使用 工具成功启动后可以在工具顶端会标识出正在运行工具的容器id号。 二、工具镜像方式 若是需要进行经常性的工具迁移使用，使用工具挂载方式会显得不便捷，那可以选择另一种方式在容器中使用工具，即将工具放置在镜像内，实现快捷的工具迁移。以下对此方式进行介绍。 编写 D ockerfile 使用dockerfile在制作镜像时将工具目录同时拷贝进去而形成一个新的镜像。 构建镜像 启动容器 使用指令启动刚刚新制作的镜像，而镜像里本身就已经包含着工具，不需额外对工具进行挂载。 修改工具启动文件 工具在容器内打开后使用的是容器内部的文件树，所以需要将启动文件中对应的路径进行修改。修改后可启动工具。 工具使用 工具成功启动后同样可以在工具顶端标识出正在运行工具的容器id号。 总结 在敏捷开发模式越发流行的现在，Docker技术的使用也随之越发普遍，使用Docker会给开发带来一些优势，如更高效的系统资源利用、更快速的应用启动、提供统一的运行环境、利于实现持续集成与部署、更易于移植以及更便捷的维护和拓展。但对开发过程中对迭代版本中的代码的测试成本也逐渐增长，方便快捷地对代码进行尽可能早的测试也成为了越来越多用户所追求的。 VectorCAST作为一款强力的C/C++代码测试工具，不仅可以与Docker技术进行结合，并且可以适配实际的交叉编译链，对代码基于最真实编译环境进行完备的测试检验，大大减少因代码测试中测试工具与环境分割或适配带来的花费，提高测试效率和降低测试难度。 如果您想了解更多有关信息请联系北汇信息，北汇信息作为Vector公司的中国合作伙伴，拥有专业的VectorCAST测试服务团队，可为您提供周全完整的研发、测试解决方案及优质的技术支持服务。

「Jeff Sutherland」Scrum之父，敏捷宣言（Agile Manifesto）起草人。萨瑟兰毕业于西点军校，越战期间是出色的战斗机飞行员，擅长低空飞越北越进行侦察任务。越战归来后，先在史丹佛大学取得统计硕士学位，后于科罗拉多大学医学院取得 生物统计学 博士学位，其 指导教授John Bailar是医学暨统计学最知名的研究学者之一。现在 为Scrum基金会总裁。他在空军训练中学到：观察（Observe）、导向（Orient）、决定（Decide）、行动（Act）的循环方法。 Scrum是目前全球最为广泛采用的敏捷工作法(1,500万人正在天天使用中)，Amazon有3,300个Scrum开发团队，Intel则有500个Scrum teams，Tesla、Apple、BOSCH、J.P. Morgan、及日本的TRI-AD/Toyota、Docomo、KDDI ...... 911事件发生后，事件调查 委员会试图找出事情发生的关键原因。该委员会指出，负责分析情报的人员未能取得一些原本应该要分析的情报。「FBI的资讯系统效能不彰，」报告中写道，「这意谓着情报分析人员多半得仰赖与工作部门或工作小组成员间的私交， 才能从存放情报的单位取得情报。」这是该委员会的结论:「FBI缺乏知道自己欠缺什么的能力:内部缺少一个能吸收或分享组织知识的有效机制。」 FBI「自动化案件支援」(Automated Case Support)系统架设于 1980年代曾经走在时代尖端的大型主机上。但是，很多干员根本不用这套系统，因为它实在太笨重又太迟缓。 「你得在文书处理软体中打好内容，然后列印出三份。第一份是 要请上级层层核可的;第二份是要存放起来，以防第一份遗失的;第三份你得拿一枝红笔──我没开玩笑，真的是红笔，圈出关键字，输入 资料库中，因为你得为自己的报告做索引。」 这样的情景在官僚化系统里最为常见。 这种管理方式实在太过时又松散，一度备受诟病:FBI明明早在九一一事件前几个星期就已得知，有多名 激进 组织的份子进入美国，却未能把种种迹象的关联性加以串连，有人认为部分的原因就出在档案系统上。当时FBI的某单位对某个目标起疑，另一个单位对于有这么多可疑的外国人在接受飞行训练感到事有蹊跷，还有一个单位则是把某盖达成员列入监视名单，却从未通知其他单位。在FBI 内部，没有人把这些事情全部拼凑在一起。 当参议员们开始质询FBI一些难堪的问题时，FBI基本上都会回 答:「别担心，我们已经有一个正在进行中的现代化计划了。」该计划要发展的是一套名为「虚拟案件档案」(Virtual Case File, VCF) 的系统，照理说这应该可以让一切改观。FBI的官员很懂得利用每一 次面临的危机，他们向参议院表示，该计划除了原本已拨款的1亿美元经费以外，只需要再追加7,000万美元经费就够了。假如你回头去找当时媒体对VCF系统的报导，你会发现内文大量使用诸如「革命性 的」与「转型」之类的字眼。 三年后，计划终止了，因为根本不管用，连一丝一毫的效果都没有。FBI已经花费纳税人1.7亿美元的辛苦钱，买到的却是一个永远不会有人使用的电脑系统──没有任何一行程式码、应用程式派得上用场，也不会有任何的滑鼠点击。整个计划根本是一场灾难。 2005年，FBI展开名为「哨兵」(Sentinel)的新计划。这次一定要管用，这次一定要用对预防措施，一定要跑对预算流程，一定要做好控管。毕竟FBI已经得到教训。哨兵计划造价多少?只要4.51亿美元，而且2009年就能全面上线。受雇建置哨兵系统的承包商Lockheed Martin已经用掉4.05亿美元的经费，却只完成一半的工作，而且这时候的进度还落后了一年。一项独立分析预估，这个专案可能还要六年到八年才能完成，而且纳税人为此至少必须再花3.5亿美元。FBI花费近十年的时间试图更新局里的电脑系统，但是专案看起来即将「再次」失败，成为史上最大的软体灾难。 原因不在于这些人不够聪明，也不在于FBI所托非人，甚至不是选错技术的问题。问题无关乎职业道德，或是缺乏外来的竞争刺激。原因在于大家工作的方式不对，大多数人都用错了工作方法。我们都以为工作应该要那样完成，只因为别人教我们的就是那一套。 Lockheed Martin的成员在投标前先开会检视系统需求（有1,100项需求，堆起来大概几吋厚），而后开始着手规划如何打造出一个满足所有需求的系统。他们会交由公司内部的大量人才处理，花费几个月的时间整理出必须完成的事项。接着，再花几个月的时间 规划如何完成。他们会划出许多美观的图表、解说每件必须完成的工 作，以及每件工作所需的时间。然后会小心挑选颜色，把计划的每一个部分以层层相接的形式呈现出来，看起来就像一道倾泻而下的瀑布。 大多数的软体开发专案都还是采用瀑布法，专案分成多个阶段完成，一个又一个阶段发展出准备释出 给顾客或软体使用者的终极版。流程很缓慢，也无法预知成果，而且往往会做出使用者并不想要或不愿付费购买的产品。进度延迟几个月或几年是家常便饭。这种事前先把每一步都规划好的计划， 会把所有细节都画成甘特图，也让管理高层相信开发的过程完全在掌控中，但结果往往是进度很快就开始落后，而且预算严重超支。 这类图表叫做甘特图(Gantt chart)，因为它是由亨利.甘特 (Henry Gantt)所发明的。1980年代，个人电脑的问世让大家能很容易就画出这种复杂的图表，但是也让图表变得极其复杂，甘特图于是成为一种艺术品。专案中的每一个阶段都巨细靡遗地设定好了，包括每一个里程碑、每一个交日期在内。这些图表看了真的会让人留 下深刻的印象，但唯一的问题却在于它们往往是错的。 甘特大约在1910年发明这种知名图表，最早使用甘特图的是第一次世界大战时担任陆军军械部部长的William Crozier将军。任何研究过第一次世界大战的人都知道，有效的组织能力在那次大战中实在称不上是什么突出的特质。我一直都很纳闷， 为什么甘特图这种一次世界大战时的玩意儿会变成21世纪专案管理中的既定标准工具。我们现在已经不再打壕沟战，但是当年用于规划壕沟战的思维到现在却依然流行。艾森豪威尔曾说过，为战争拟定计划固然重要，但是等到开了第一枪后，计划就化为乌有了。他很有见地的没有使用甘特图。 传统上，管理团队对于任何专案都会要求两个条件:控制和可预测性。这会带来为数众多的文件与图表，就像Lockheed Martin一样，会花好几个月的时间规划所有细节，以确保没有任何错误，没有任何成本超支，而每件事也都能按照时程完成。 问题在于，这样美好情节从未真正发生。所有用于规划的心力、用于限制变化与厘清未知事项的努力全部都是白费。每个专案一定都会出现许多的问题，冒出许多新想法。试图把任何规模的人类行为限制在全彩图表里，不但愚蠢，而且注定会一败涂地。人不是这样做事的，专案不是这样进展的，想法也不是这样落实的，美好的成果更不是这样创造的。 Scrum的固定仪式之一是询问大家很简单的三个问题:从我们上次交谈后到现在，你做了什么?在我们下次再讨论之前，你打算做什么?有什么事情干扰你吗?这可以促使 特派员们彼此讨论并分享资讯。在每次开会后，Scrum Master要负责确保任何干扰团队工作的因素在下一次开会前已经被排除，否则流程就无法“流动”。 大野耐一提出的关键概念「流程」，意思是生产流程应该流畅平顺;管理团队的重要任务之一在于找出流程中的阻碍，并且予以排除。任何挡在路中央的东西都会造成浪费。他的经典著作《丰田生产方式:追求超脱规模的经营》(The Toyota Production System)中，评定「浪费」的道德价值及商业价值:在低成长时期，这样的浪费不但是商业损失，更是社会犯罪。排除浪费必须是企业的首要目标。想要让Scrum真正发挥功能，高阶管理团队中必须有人发自内心地把阻碍视为近乎罪犯。 大野耐一谈到三种不同的浪费，他用的是日文字眼:Muri、 Mura、Muda。Muri指的是因为不合理、不恰当导致浪费;Mura指的 是因为缺乏一致性导致浪费;Muda指的是成果欠佳导致浪费。这些想法与PDCA循环高度契合，也就是规划、执 行、检核、行动。规划意谓着要避免Muri，执行意谓着要避免Mura， 检核意谓着要避免Muda，而行动意谓着我们要有意志、动机及决心把这些事做好。 节奏是Scrum的核心，运作得宜的Scrum团队可望实现我们所称的「超生产力」。 美国太空总署采用的「阶段-关卡」流程就是经典案例。美国太空总署在1960年代、1970年代及1980年代就是使用这套流程执行太空梭等计划。现在的流程已经大不相同了，这里讲述的是他们那套旧流程的运作方法。首先，从探索「阶段」着手，大家决定要设法完成的目标，比如说打造一艘登月火箭。一群策略人员坐在房里，想像着那幅场景。接着会有一个「关卡」，由一位或一群管理者签名，认可该专案有发展的价值。再来进入初步调查阶段，所有的「需求人员」 必须决定该做哪些事。接着会有另一个关卡，又要开好几次的会，产出的所有庞大文件要转交到下一个阶段──细步调查阶段，并拟定专案计划。再来，所有的计画又必须历经一连串的会议与核可，完毕之后再送到下一个阶段──开发阶段，到这时才会真的开始动手生产。接着又是一堆会议与文件，然后把产品交到另一群人手中，进入下一个阶 段──测试。测试人员先前从未看过产品，但他们还是照测不误，然后签名核可，再把产品放到另一个关卡前，也就是永无止尽的开会，这时会再产出一批根本没有人会阅读的文件。直到这里，产品总算要送到第六批人员的手中，由这些人实际推动上市。光是把这些过程写出来就累死人了，但这却是美国太空总署过去发展计划的过程。 物理学家Richard Feynman:「无论是出于内部或外部所需的任何理由，看来美国太空总署的管理当局夸大产品的可靠度已经到了幻想的地步。」 只要资料在不同团队间移交，就有发生灾难的可能。正如刊载在《美国联合部队季刊》(Joint Force Quarterly)上，一篇名为

        今天出差回深圳的路上，与司机聊天，聊着聊着，就谈到他儿子的学习情况。         司机说：“学习的事情还是要看人，我儿子就很懒，学习成绩中等偏上，问他有什么兴趣，什么爱好都没有，懒得很，书很难读得好。”           我问到：“您儿子今年多大了？”          司机回答：“读高二了，十六岁了。”          我说：“您对他的期望很高，对吧？”          他说：“那是当然，眼看不就要高三了嘛。”           我对他说：“我觉得在中国学习好坏只是一个方面，我感觉中国式教育最缺少的就是，解决问题能力与方法。我觉得目前对您来说期望您的孩子考一流的高校，不切实际，毕竟只有一年的时间了。将来孩子走向社会，各种拼爹，拼关系，拼背景，也无力相拼。那么您能做的就是，尽早让他学会生存之道，授之以鱼，不如授之以渔。”           他说：“暑假我有让他去外打工。。。”           我说：“我以前想着暑假也去外面打工什么的，我当时给自己的目标是赚一千元回来，然后我就试着想去当服务生。但我现在看来，我当时用的是80%的人都会用的方法去赚一千元，所以相对辛苦一些。我现在看来，其在赚一千元的方法有很多种，不一定都要当服务生。赚一千的方法，可以是自己当家教，也可以是批发一些热销的产品来卖等等。。。只要你够敏捷并且条件合适就可以有更多的方法来赚一千元。 我当想的更多的是自己要赚一千元，而忽略了如何更快，更高效地去赚一千元。就像我当时读大学的时候，希望自己毕业后出人投地，就只一味就想着努力学习，但没有更多的关注方法，如何出人投地，也很少去实践。我想我当时是不够敏捷的。。。”           噼里啪啦，我说完一堆，不明白司机有没有完全理解我的意思。但是他说了一句话：“哎呀，是呀我该应让他自己思考打什么工，而不是帮他找好地方让他去才对呀，这个方法好。。。”            下车后，我在路上思考了挺多。现在在软件行业流行的关键词：“敏捷开发”就是一种提高软件开发质量，效率，提升软件开发企业竞争力的一种方法论。这种方法论源于精益生产，更甚至在欧美一些国家衍生出“精益创业”的理论。其实我觉得这种思想对于人的职业发展，人生轨迹，工作，学习，生活中都是有一定的指导意义的。可以说适用的地方无处不在，一句话凡事都要讲究方法，在工程开发领域更是如此。           当然，我这里说得“敏捷”并非华而不实的空思，好的方法是由一定的知识、经验积累产生的。所以在今后的工作，生活中，一定要培养自己“敏捷”的思维，扎实专业知识，积累经验，多思考，找方法。