导读：随着无人机技术的不断发展，相关产品的软硬件和算法的经过了一系列的快速迭代，来自大疆的张晓明为我们分享大疆是如何做快速迭代与测试，在快速迭代之中，大疆的研发测试做了什么，遇到了什么样的困境和挑战，又是如何做到突破。
我们是做无人机的，我周围的朋友一提到无人机，基本上都会问我这个东西能够飞多远、多高？无人机是不是完全就不需要人了？还有更过分的说无人机是不是冲着它一喊，无人机就可以跟着你走了？其实大家问的都没有错，今天我和同事一起带领大家走进真实的大疆研发和测试是怎么一回事。今天会给大家讲四部分的内容：第一部分，大疆研发测试做什么？第二部分，快速迭代和测试。第三部分，困境与突破。第四部分，接下来的挑战。
一、DJI 测试做什么
大疆给人的第一印象是什么呢？昨天也和业内的一些人士来聊，大家都说大疆无人机的市场占有率很高，在全世界的范围内占至少70%以上的份额，这是保守的数字。我在2015年加入大疆，那时候大疆给我的第一印象是有财，2015年汪峰通过大疆无人机给他的女朋友送了钻戒之后成功的上了头条，无人机能够让大家变得有财。第二印象，有钱。大疆的年终奖会发车（宝马、奔驰），这是当时给我的印象。第三个印象，有影响力。大疆现在在各种重要的场合、重要的事件都会参与进去，比如说去年的巴黎圣母院发生火灾，大疆派了大量的无人机去现场救灾、勘察火情、勘察测绘等。以上是当时给我的三个印象。
那么，实际真实的大疆是什么样子的呢？
大家可以看到，这是大疆一系列的产品，在大家的心目当中，大家知道的是第一排，有精灵系列等消费和影视的无人机，这些是大家最熟悉的产品。但是除了这些以外，还有手持无人机等等一系列的产品，另外，我们在消防、测绘、电力、巡检、农业等方面都有无人机产品，我们的农业无人机可以帮助农民节省三分之二以上的农药，可以帮助农民一天打农药打到800亩以上，如果一个人的话，正常大概也就是几亩。最下面的部分，因为我们老板的情怀，他一直用我们自己公司钱去支持办一个比赛，这个比赛现在是国内机器人比赛中最有名的一个赛事，大量的学校会参与进来。简单比喻一下，不知道现在有没有玩游戏的同学，它就是现实版的data，今年我们基于这块也生产出了大疆的第一款教育机器人，在今年的《开学第一课》上有专门的一个展示。以上大概是大疆的全系列的产品。
刚才说了大疆的产品，那么大疆的测试是什么样的？
大家可以看一下，像刚才菜鸟的同学说，它们的测试是分层的，我们的测试也是分层的。首先，第一类是最原始的，就是最基本的功能测试，我们内部会有大量专门的飞行人员，会在外面的实际场地像真正的用户一样去使用无人机。第二，我们在室内有专门的仿真测试仪器，会在室内进行自动化和仿真的测试。第三，大疆无人机的使用者很多都是在几线的环境，比如说冰山、高原这些地方，拍起来确实很美，所以在极限的高度或者低温、高压环境中，我们也会有这样的极限环境的测试，在我们内部会有各种各样的专业测试实验室。我们内部会有一些对产品非常懂的，叫内部的产品体验师，他们会对专业产品进行各种各样体验的测试，提出应该怎么设计，实际的用户会怎么样，我们叫他们KOL。
今天大家基本上的思路都是一致的，特别是刚才菜鸟的老师，大家发现会遇到各种各样测试的难点，尤其我们更是。请大家看一下，我不知道现场有没有人实际玩过无人机，玩过的就会知道，玩无人机的时候会有一个手机安装了APP，手机会连到遥控器，遥控器会连上天上的飞机，最终整个数据会回传到服务器上。我们整个的产品是跨了非常多的技术栈，比如说安卓、IOS、Linux、RTOS、后台、前台等，还有无人机可能会涉及到几十个芯片，这些芯片上都会有一些大大小小的操作系统，这会导致我们整个的技术栈是非常复杂的。另外，它会跨多个领域，飞行、飞控、计算机视觉、机器学习、通信系统、影像系统、APP、电池、系统安全等，我们有比较多这样跨专业的领域。而且，特别重要的是，对于无人机来说，大家可以想象无人机是在天上，是通过电池的动力去飞行的，它的结构和机械对我们的影响是非常大，而且它的可靠性和一致性的要求特别高。因为我的无人机在外面有成千上万，这些无人机之间的表现是否一致的，这台无人机好，但是那一台无人机可能是不好的，我们如何保证它，这都对我们提出了非常高的挑战。
这么多难点的话，我们在实际的测试过程中，是怎么样既保证它的质量，又快速迭代？大疆内部有一个说法，大疆是一家革命性的公司，它不负责革别人的命，只负责革自己的命，每出一代产品就会把自己的前一代产品打落，大疆基本上这样的产品，所以大疆的迭代非常快。在这样的情况下，我们如何保证质量同时又快速迭代，我们开发了一系列的测试平台。
二、快速迭代&测试
快速迭代是如何被保障的？其实这里面是由两个点：一是保障，二是快速，这是我对一句话的理解。谈到保障，很重要的一个点是全面性，从我们的角度来说，我们是想通过系统化去保障全面性。简单来说，我们会有一个类似于业界的Devops系统，从流程上来保障健全性，有一个系统化，再保证每个环节都能够被实施到。另外，在比较健全的流程上，我们也希望效率能够有一定的提升，这里面每个环节会尽可能地去配套一些提效工具，让流程尽可能高效，但是这个过程我们也在持续实施中。
第二个关键词是快速，所谓的快速就比较容易理解，就是整个测试的实施过程，我们是希望尽量敏捷，尽可能自动化。刚才前面几位同事都提到了测试上的传统思维，是分层测试，其实我们也是借鉴了业界比较成熟的一些思维，把测试分为大约四个环节：单元测试、Patch测试、每日构建测试、版本发布测试。
这是智能硬件的DevOps，我们正在进行相关工作的建设。这个图中的框框比较多，大致可以看一些，纵向的列可以理解为在研发和交互过程中的重大环节，可能大家也都比较熟悉了，会从最开始的需求设计开始，接下来是相关的开发。我们公司有一个很重要的特点，就是整个系统上也会有多个模块，接下来会有一个模块测试的环节，完成之后会向整机进行交互，接下来就是整机测试的环节，之后会以打包的形式导入到工厂或者直接导入到客户。当然，工厂和客户这边的有些问题会通过售后反馈到测试这边，中间是通过一些交互件（文档、固件、大包）等串联起来。在每个流程环节中，会有一些大家能够经常看到的系统、概念或者工具，比如说需求管理、持续集成、静态代码检查、缺陷管理、自动打包，最后在发布之前会进行相关的安全审计，因为我们的平台和业界类似，既有一部分是自营的，另外一部分是开源的平台。开源会涉及到相关的开源问题，比如说一些高危漏洞以及开源的合规。
这张照片是针对其中的持续集成的环节，有一个专门的门户，去加速持续集成这个过程的有效性和效率。我不知道大家在式过程中是否经常会和研发讨论一个问题，研发可能会随着我们的测试，权威性越来越重，那么我们的测试可能会设置一些节点，或者通过我们的通过率来检测研发的不合理处。在这时候的研发可能会提出一些问题，比如说你说我的代码是有问题的，那么你的测试系统是不是有效的，为什么代码提上来之后编不过，甚至编过了又测不过，这是一个很重要的矛盾。大家经常会问一个事情，随着整个系统的越来越庞大，我们每天都有上千次的提交，这就意味着上千次的编译和测试。在这个过程中，如果一个一个问题去纠结的话，会陷入低效，所以我们重点看两条曲线，一条曲线是会对整个持续集成的过程中，尤其是Patch测试中，对每个测试进行一个有效性的实时监控，谁有问题都来这上面看。上面这条线是代表过去100次最新的测试和编译过程中的有效性，比如说我们这里看到最上面的点就是代表这次测试是无效的，是我们自己会有一个内部监控的手段去监控测试是否有效，下面这条线是针对其中有效的这些部分测试状态的分析。最上面的是代表测试失败，针对每个测试失败研发可以点进来看，我们也会去分析到底什么原因造成失败，下面是编译失败，这是相当不可接受的一件事情，那么会做相关的一些统计。这样的话，整个过程大家通过一些可视化的手段，可以一起加速整个研发和测试过程中的效率。
Patch测试。在这里面的一些内容，大家都比较熟悉了，在Patch测试过程中，我们有一个特点，因为今天是在讲IoT和线下智能，所以说我们每次测试都会部署在实际设备上，保证每次测试尽可能是端到端的。当然，这也会带来一定的挑战，后面再讲。具体检查内容的话，主要有研发自测结果、代码风格、静态代码检查、编译检查、集成测试检查。通知方式，我们通过内部的即时通信软件，每次测试的结果会即时通信到相关的研发人员，他可以第一时间了解到情况。
这是Patch测试的拓扑图，我们可以把相关的编译和测试部署到相关的编译和测试机上，实际的测试是会通过串口、WIFI，根据不同的形态部署到无人机上。这里面还有一个特点，其实整个内部的研发平台化做的还是可以的，经常是一个提交会对多个产品有些公共的功能产生影响，每个提交可能会去自动评估它会影响到哪个产品，也可能会同时部署在多套测试上，同时把测试结果原路返回给研发。
Patch测试下一个阶段就是每日构建测试，这也是发生在实际设备上的，相关的内容就是基本功能冒烟，以及典型场景性能和功耗数据的采集。我们通过每天对一些关键场景下的关键性能指标、功耗指标进行采集，方便去做历史版本之间的对比和回溯，甚至比如说做一些二分法的拆解，看到哪些问题是害群之马。通知方式是通过邮件或者JRA的方式通知到研发。
这是每日构建测试可见化的截图。每日构建测试大约每天发生在凌晨，在这之前是先发生每日构建，每日构建完了之后会做每日构建的测试，相关的结果既可以通过测试中心点击查看，也可以通过邮件，就是每天测试完之后会在早上第一时间把测试结果发出来。比如说这里面有500多条，失败了100多条，测试工程师上班之后，第一件事就会对这些测试失败进行归类，哪些是新的问题，哪些是已有的问题，研发工程师看到以后会对当前的问题进行深入分析。这里面有500多条也不全是冒烟，我们尽可能是想暴露问题，一方面是保证基本的功能，另一方面是Patch测试里可能时间方面涉及不到的事情，我们尽量把它做一个深度的测试和探索，尽可能把问题往前暴露，这是测试的一个思想。
这是每日构建测试里的关键性能部分，刚才也提到了这和大家也大同小异，针对无人机上的一些特定场景，包括静态性能、图传、拍照和录像、最大负载。所谓的静态性能，就是没有起飞，APP通过遥控器连上飞机以后它的静态功耗。以及我们通过APP上去查看实时图传的相关功耗。最大负载，就是经过4KP60的录像，同时还能够再去做地图或做一些转角等模拟的场景去看系统的变化情况。因为一般情况下，我们会尽量尝试让用户买到的硬件性能发挥到极致，会在性能里塞上最新的算法和智能功能，把硬件的性能发挥到极致，所以最大负载的测试也是非常重要的。同时，基于以上这些场景会做一些相关的可视化，大致分为两类：一是变化趋势，就是版本间；二是问题分析。还有一个是版本内的，我知道这个地方有问题了，我希望你不只是告诉我问题，还希望你帮助我做一些辅助的分析，所以我们会有火焰图。
这就是刚才前面提到的版本间性能变化的采样。横轴是采样时间，每天的采样时间就是每日构建的时候会对各种各样的典型场景进行相关采样。纵轴是CPU，这是我们内部的一个设备，是我们已经发布的飞行眼镜，这是它的性能采样，这个性能采样里一个很关键的进程，它在不同版本间对CPU的占用情况。这个研发可以快速地通过Diff看到在几个版本上面，因为有些性能问题或者考虑到性能的一些点，会导致CPU占用提升，同时这个点很快就意识到这个情况了，把这些相关的东西做录入，发现它又拉回来了，大约是这样的思路。这里面还有一些其他的场景，我们就不一一看了。
这张图是前面提到的火焰图，可能有些同学比较熟悉。我知道某个点上可能发生了性能问题，那么我怎么去分析呢？我们会尝试在发布问题之后，会再往前走一步，在问题点上会做一些火焰图的相关采集。这是在某个场景下系统的调用顺序，我看到某个开销很大，就可以按图索骥看看调用栈，看看是在哪个地方发生了一个比较大的性能开销或者时间的开销，或者是IO的开销，它可以有这样一个初步的分析，然后去解决相关的性能问题。
我们还会进行版本发布的测试，这也是按需进行的。版本发布测试是按需触发，这里面有手工和自动测试，会包括各个模块和子系统集成打包、版本提测、冒烟测试、全面测试（手工测试和自动化）。手工测试主要是关注在算法性能的评估以及功能体验，自动化更多是关注在软件的稳定性以及硬件的可靠性和一致性。
这是几个版本发布测试的入口，版本的经理或人力负责人会负责集成大包，这是我们所看到的一个大包的版本号，可以在界面上发起版本发布测试的提测请求，发起之后，电子流会第一时间流转到测试负责人这里，测试负责人就可以按照前面测试的策略制定相关的测试技法。在测试技法里既包括手工测试，也包括自动测试，自动测试其实是通过引擎去分发到相关的测试节点，执行相关的一些自动化测试用力。自动化测试用力执行完成以后，会把测试结果回传到系统里。当然，这里面也会包括一些手工测试，手工测试的测试技法都会回到系统里来，最后会把整个测试的过程通过电子流的形式，以及相关人的一些反馈统计在一个系统里，方便后续的质量维护。
三、困境与突破
前面大致介绍了整个大疆产品测试以及研发交付的保障思路，基本的流程其实已经打通了。在这个基本流程打通的过程中，大疆不管是从老板开始，还是从公司价值观的追求上来说，是以创新为驱动的，追求快速迭代。说的直接一点，就是刚才提到的经常革自己的命，在这个过程中，对测试也提出了很多的需求，有一些比较大的挑战。
其中最大的一个挑战就是可靠性和一致性，关于可靠性和一致性，在座的同仁都有一些基本的概念，我相信其中一些同事也有深入的理解，大疆在这方面也有一些自己的切身痛点。大家知道，大疆是一家做无人机起家的公司，我们的无人机会飞在全世界各地，因为无人机和软件还是有一点区别，它是一个实际的物体，小到几百克，重到几百公斤，无论是有人还是空旷的地带，只要它掉下来了，影响还是非常大的。自从我加入了大疆之后，每次坐飞机的时候，都心惊胆战的，这对可靠性提出的要求是比较大的。二是一致性。大疆的无人机越来越多，每天可能有300万次的起落，用户买大疆的飞机花的钱还是比较多的，我们的产品相对来说还是比较贵的。花了钱之后，我对于品质也有一定的要求，起落的过程中在悬停的时候是否始终如一的稳定，走航线的时候是否走的那么直，是否都能如宣传片一样做的那么好，这是对产品的一致性提出了很高的要求。因为一致性不只是包括软件，还包括硬件，特别是我们的芯片。我相信今天做IoT和线下智能的也经常和芯片和传感器打交道，芯片和传感器在生产过程中，在某些特性上不是像一个线性函数那么完美，无论是电压特性还是参数特性都是呈正态分布的。
之前，我们是采用传统手段，说的直接一点就是我们是手工测试，通过手工飞行来做这样的测试，这样做的话会有一些痛点：一是人员技能不一。我们内部既有很专业的飞手，或者也有像半专业的飞手，技能确实不太一样。二是多机干扰。三是人力成本。假设我们一天要飞1000架次的需求，这个人力成本是非常高的。因此，我们开始逐步设计、同时逐步实施自动飞行的研究、实现和落地，自动飞机主要从以下三个思路去解决前面的问题：一是自动化。我们希望把飞行控制和状态监控变成自动化。二是批量化。我们希望测试能够批量化，在一台设备上进行测试以后，可以在上百台设备上进行批量化的同时运行，日飞行时间超500小时。三是标准化。包括最长无故障运行时间、最短失效时间以及平均无故障运行时间。
这张图是自行飞行的软件架构，它是运行在飞机端的一个现实应用，大约分为三层，最底层包括OS的抽象、消息分发存储和嵌入式开发的工具。上面是应用层，会对飞行逻辑、测试逻辑以及相关的基本测试设备、状态监控的逻辑、定位的逻辑进行了相关的应用封装。这上面是暴露给实际测试人员的，它可以基于上面的几个应用逻辑，可以去开发相关的测试用力，以及对这些测试用力进行相关的配置形成测试计划，以及外部的相关mark的定位。整个的思想还是把一些偏实现端的逻辑进行相关抽象，让测试用力的编写尽可能简单化，可以让更多的人能够参与进来，去利用这个平台参与测试用力的开发，进而减少手工测试在可靠性、一致性上的投入。
这张图是具体的内部交互逻辑，大约是分为四个环节，包括飞行控制、测试任务调度、测试执行的状态机、模拟人的第三方监控，在这里面会基于飞机内部的一些传感器数据、飞机自身的姿态数据，以及飞机外部类似于第三视角或者人的视角的一些状态监控，或者未知姿态的外部定位。
这张图是我们在某个项目上的实际运行效果图，可以看到我们在一个外部空旷的环境下摆放了一百架左右的飞机，批量地分为几个区域安排相关执行的任务，包括相关的计划，飞起来以后会自动在天上散开，然后执行相关的测试逻辑。
这是我们内部统计的今年发布的项目上通过自动飞行的一个飞行数量，以及飞机问题的变化曲线。大家可以看到，随着产品的不断稳定，测试量有相关的上升，但是测试量的上升也促进了产品的相关问题，同时问题是以指数级的衰减。
四、接下来的挑战
未来会发生什么，其实不仅对研发，对测试也有非常大的挑战，我相信大家都在各自的公司、各自的领域也面临了很大的挑战。最后，谢谢组委会给了我们机会，让我们各个同仁聚在一起讨论测试前沿的知识，更重要的是一些测试活动或者测试想法背后的一些思路，也为我们接下来的挑战提供了一些思路或创新的源泉。谢谢大家！
文章来源：张晓明 阿里巴巴技术质量
