導讀：随着無人機技術的不斷發展，相關産品的軟硬體和算法的經過了一系列的快速疊代，來自大疆的張曉明為我們分享大疆是如何做快速疊代與測試，在快速疊代之中，大疆的研發測試做了什麼，遇到了什麼樣的困境和挑戰，又是如何做到突破。
一、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的定位。整個的思想還是把一些偏實作端的邏輯進行相關抽象，讓測試用力的編寫盡可能簡單化，可以讓更多的人能夠參與進來，去利用這個平台參與測試用力的開發，進而減少手工測試在可靠性、一緻性上的投入。
這張圖是具體的内部互動邏輯，大約是分為四個環節，包括飛行控制、測試任務排程、測試執行的狀态機、模拟人的第三方監控，在這裡面會基于飛機内部的一些傳感器資料、飛機自身的姿态資料，以及飛機外部類似于第三視角或者人的視角的一些狀态監控，或者未知姿态的外部定位。
這張圖是我們在某個項目上的實際運作效果圖，可以看到我們在一個外部空曠的環境下擺放了一百架左右的飛機，批量地分為幾個區域安排相關執行的任務，包括相關的計劃，飛起來以後會自動在天上散開，然後執行相關的測試邏輯。
這是我們内部統計的今年釋出的項目上通過自動飛行的一個飛行數量，以及飛機問題的變化曲線。大家可以看到，随着産品的不斷穩定，測試量有相關的上升，但是測試量的上升也促進了産品的相關問題，同時問題是以指數級的衰減。
四、接下來的挑戰
未來會發生什麼，其實不僅對研發，對測試也有非常大的挑戰，我相信大家都在各自的公司、各自的領域也面臨了很大的挑戰。最後，謝謝組委會給了我們機會，讓我們各個同仁聚在一起讨論測試前沿的知識，更重要的是一些測試活動或者測試想法背後的一些思路，也為我們接下來的挑戰提供了一些思路或創新的源泉。謝謝大家！
文章來源：張曉明 阿裡巴巴技術品質