本文根據2018雲栖大會深圳峰會·EMAS專場—移動互聯的進化論，阿裡巴巴技術專家字白《泛品質管了解決方案》的演講整理而成，文中就EMAS泛品質管了解決方案如何一體化建構高效、專業、立體的品質管理體系進行了分享。
今天的演講主題叫“泛品質管了解決方案”，為什麼叫泛品質呢？這也是根據之前的思考，包括我們集團内手機淘寶的成長路線，慢慢有些不一樣的了解。之前我們做測試，我們就是發現Bug，去解決Bug，現在看起來隻是這個點還是不夠的，比如說我們可以在研發階段做一些事情，我們線上上監控做一些事情，這樣我們才能更好地去做整個全流程的品質保證，不單單是找Bug這一點，我們在前、中、後要做很多事情，保證APP到使用者手上是一個很好的狀态，這就是這個泛的由來。
移動測試的現狀和問題
今天分這樣幾個階段給大家講講，我對整個泛品質管了解決方案的了解，然後看看大家有沒有一些共鳴。
先講一下移動測試的現狀和問題。我們現在做移動端的測試，因為移動端測試本身機器也比較多，碎片化也比較嚴重，另外APP的業務邏輯不像PC端那麼簡單，可能我們寫了很多腳本，花了很大力氣，但是發現下一個版本來的時候，大部分都用不了，要麼就重新寫一遍，要麼就人工去點，這實際上是很痛苦的過程。
主要的問題有四個，第一是我們做移動端的測試，在發版前做回歸測試。正常我們是三周做開發，一周做測試，測試完之後修改Bug，然後就釋出，基本上是這樣的流程。我們隻關注了上線前這一個點，實際上在研發階段，這個點是空白的，要麼就是要人工去點點，這個還是不夠，一會兒我會講講我們的解決方案怎麼幫助大家提升效率，解決問題。
第二點就是整個過程還是比較被動的。現在我們有一些bug提出來，開發同學可能覺得這個問題沒什麼價值，也不去改，但是客戶給我們客服打電話說這個問題很嚴重，我用不了了，尤其客戶是一個VIP的時候，我們就很上心，很努力地把這個事情解決掉。這反應一個問題，我們的APP上線之後，使用者這邊有些比較嚴重投訴的時候，能反推我們去做很多的改進。那我們是不是應該有一套更好的監控體系，在使用者發現問題之時，我們就立馬也能知道有多少人有問題，這個問題有多嚴重，我是不是立馬要解決掉，這個背後是要有一套度量标準支撐的
我們要做線上監控，做線下測試，很重要的一點就是能夠發現程式問題。這裡面有一個點，就是說問題是需要被界定的。我們知道崩潰是一個問題，這個大家都好了解，但是性能是一個問題，這個就不好了解，比如說我的啟動時間是一秒鐘，他的啟動時間是三秒鐘，哪個是問題，這是不确定的，這是要根據我們業務來的，真正使用者感受有問題的時候，那個就是有問題，是以這時候我們需要有一套标準，這個APP到2.5秒的時候就不合格了，因為使用者已經受不了了。這是另外一點，沒有一個資料化的支撐幫助你感覺到線上的問題。
最後一點是我們做很多的測試活動，有一個很不好的地方，我們做測試的時候雇一些外包同學做測試項，但是業務的經驗是跟人走的，這是很不好的，一旦這個人走了，我們要再找一個人，再積累一段時間讓他熟悉這個業務，這是一個很不好的事情，但是是不是有一種方式，有一個人做得很好，他能夠不斷地把他的測試方法、測試技術沉澱到這個平台上來，後面的人就可以很好地利用前面這些人積累的經驗，做很好的品質保障，這也是一個問題。
泛品質管了解決方案
第二部分講講泛品質管了解決方案。核心就是一句話，以資料為驅動力的智能DevOps。
什麼意思？以資料為驅動力，這裡面涉及到幾個點，線上我們的整個使用者資料沒有很好地被利用起來，比如說我們真正去解決線上問題的時候，大家可以想一想，有一個人說這個有問題，你幫我去看一下是什麼問題，趕緊給我解決掉。
一般情況下研發團隊就是打個電話或者通過其它的管道聯系上他，問他是什麼樣的手機，是什麼樣的環境，是怎麼操作的。然後按照使用者的回報，再一點點去摸索，找這個問題在哪兒，這個過程很痛苦，整個問題的發現到分析到解決，大部分時間都集中在分析這個階段，最後解決那一下可能一行代碼或者幾行代碼就搞定了。這裡面就暴露一個問題，我們對于使用者的整個行為，對當時的現場，其實資料是不全的，這就導緻我們解決問題就很困難。
實際上我們就提供這樣一套資料的采集方式，讓大家能夠在問題發生的時候不單單是把你的崩潰棧拿出來，還要把你的記憶體資訊拿出來，甚至把全量的日志拿出來。怎麼拿呢？定向的撈取當時哪些同學、哪些人、哪些手機上出現了這個問題，非常有針對性的定向擷取這些更詳細的資訊。隻要這個問題出現了，我一定幫你把全量的資訊找回來，這樣我們解決問題就不用去猜了。這是一個線上的場景。
再舉一個線下的場景。我們去做線下測試的時候，我是做APP的開發，或者我做APP的測試，我對業務很了解。但是實際上我們發現，到線上整個品質的情況并不是像我們想的那麼好，崩潰率有可能是百分之幾，有可能是千分之幾，當然千分之幾已經不錯了，但是品質情況并沒有百分之百。這就有一個問題，使用者怎麼用APP跟我們了解的其實不一定是一樣的，可能90%使用者跟我們想象的是一樣的，但是10%不一樣，這個10%的人群就造成了90%的Bug。這是對線上的使用者怎麼了解我們的APP沒有感覺，沒有資料支撐。這也是一個點，我們能夠幫助大家去把使用者怎麼用APP這樣一個畫像給畫出來，其實就是一個機率的統計，我們可以告訴你，有50%的使用者他是怎麼用這個APP的，他這個流程裡面是不是有些問題擋到他，然後影響他使用了，這些問題是不是崩潰問題，是不是性能問題，這樣就可以讓大家解決掉。
那這個“智能”什麼意思呢？是指我們通過資料可以驅動大家做一些決策。
舉一個釋出的例子，我們把APP灰階到線上之後，可以看到資料，現在的崩潰率可能是10%、20%，但是這個資料背後我們應該做什麼？這是需要我們去思考的。可能20%的時候，我們這個标準的模型裡面就應該是打回到線下再去做整個的複現、驗證、改Bug，然後再去做灰階，1%的時候，我們就擴大整個的灰階量，這個流程都是完全智能化、自動化的，當然還有其它的點，剛才我講的線上怎麼用，這些資料都可以線上下的智能引擎裡展現，他在做自動化的時候就看你的使用者是怎麼用，這樣幫你做測試，這樣的效果就更全面、更準确。
面對剛才說的那幾個問題，我們的泛品質解決方案是不一樣的。首先是整個品質管理過程橫跨全研發流程。從寫代碼開始，我們就可以通過專有雲去做持續內建，不斷地做疊代、做UI自動化測試。因為這些腳本都是在平台上的，我們可以通過自動化，持續觸發這個測試活動。測試階段我們有全量的機型，幫助大家做專家測試服務，在上線之後，我們有線上的監控，不管是崩潰也好，還是性能問題也好，還是其它的一些問題也好，我們都會有各種監控。大家在嘗試修複線上問題的時候，不可能有一個嚴重Bug等着下個月發大版本的時候再解決，是以我們提供熱修複能力，可以快速把這個問題解決掉，這是從發現問題到分析問題到解決問題，這樣一個全面的鍊路，不單單是一個點。
另外一點就是資料驅動，剛才講了，我們這裡面有大量的資料場景，能夠把線上的資料通過一定的訓練模型，能夠告訴大家，當時是發生了什麼事情。比如說線上的崩潰問題，崩潰問題怎麼解決，可能單單看某一個崩潰問題，它是一個孤零零的個例，如果你把它做資料統計方面的分析，你會發現它有些内在的關聯性。比如說我會發現可能我這個Bug大部分問題發生在深圳，或者說那個Bug大部分都是在使用者切到背景5秒鐘之後崩潰的，這些實際上都是需要我們把這些資料挖掘出來，然後給我們開發者一些具像化的了解。
第三個就是主動感覺。這就是剛才講的兩個點，一是我們要有一套比較好的估量标準，告訴大家什麼是問題，尤其是那些我們不好界定是不是問題的，這個要用使用者的感覺來界定，我們有這樣一套标準。這個感覺之後，出現問題之後，我們要告訴大家，發一條短信或者發一條告警給大家，現在你的使用者線上上有多少的比例，已經遇到什麼問題了，已經影響到業務的活躍度了等等。
最後一個就是整個泛品質管了解決方案的功能或者子產品，其實很大的一點是有很高的開放性，不管是open API，還是這個平台在基座上支援的很多插件，客戶的技術同學、開發同學都可以基于這個基座做橫向的擴充，這樣每做一個子產品進去，我們這個子產品就沉澱到這個系統裡面來，後面再來的同學可以直接享用前人的成果，不需要再去一點點研究，這樣的話，實際上加快我們整個團隊的技術建設，包括我們對業務的快速了解，其實都會有很好的幫助。當然這個點一旦提升起來，我覺得可能對我們整個測試團隊的技術使命感會有很大的幫助。我知道有一些APP開發者沒有專門的測試同學，有的可能雇一兩個外包，這樣整個技術氛圍會有點差，這個平台會把很多你沒有遇到的問題擺到你的面前。而阿裡雲會站在客戶背後給予最大的支援，幫助大家解決問題。
這是我們整個泛品質管了解決方案的大圖，功能全部在這裡，覆寫了研發、測試、運維、營運，今天我會主要講研發、測試、運維這三個階段，營運階段最後大概介紹一下。
這裡說的是我們通過資料怎麼去驅動我們做一些品質方面的決策。
首先是一定要有統一的度量标準，這個度量标準不單單是我們畫一條線，這條線要根據使用者的感覺來定。
第二，這個線要線上上跟線下完全統一起來，是一條平的，不能說線下沒有發現問題，但是線上問題爆發了，這就是兩邊不平等，線上線下一定要完全統一。
另外一點是資料驅動，剛才講過了，我們通過資料的方式可以告訴大家，背後的因子是哪些，你的品質問題、性能問題、崩潰問題跟哪些因子是有關系的。這樣我知道這是一個地域性的問題，還是一個弱網場景下會出現的問題。我們第一感官就有一個非常清晰的判斷，不至于一個Bug一個Bug的去看，人工去找這個相關性。
還有一個是我們通過自動化的方式，幫助大家去做決策：目前這個階段，面對現在的品質問題，你應該做什麼。
研發階段 品質管理
介紹一下我們在研發階段的産品，我們叫移動測試的專有雲，其實就是把我們現在公有雲的硬體和軟體平台一體化的給客戶服務，這樣在内部就實作了一個小的測試雲，我們可以通過它不斷地做每天的自動化測試，可以不斷地通過複制的方式把我們的腳本生成到這個平台上來。客戶可以通過生成的腳本，每天做APP自動化回歸，這樣就能很清晰地知道前一天開發同學送出的代碼有哪些Bug。
這是我們的專有雲架構圖，最下面就是我們的硬體層，也就是我們的無線機架、機房、手機等等裝置，包括電量測試的解決方案也在裡面，它也是通過硬體的方式解決。
上面就是我們的中間件，這個中間件裡面就提供一些基礎的服務，像一些OSS檔案存儲、MySql等等中間件服務。再上面就是我們開發的測試技術，像弱網怎麼做測試，智能探索怎麼測試，一會兒我會介紹一下智能探索的案例，這一層我們也會把我們的一些二次開發的接口或能力開放出來讓大家接入。最上面是我們現在封裝出來的主要測試能力，這個測試能力也同樣可以讓客戶自己去橫向的擴充，這樣就可以很好地實作客戶自己測試技術的積累。
然後講講這幾個主要的功能。其實在研發階段，很重要的一個事情就是做UI自動化回歸，是以第一個我就講功能自動化。我們現在已經支援3種架構：appium、robotium、robot framework。這裡面我們支援了很多複雜的業務場景，比如說金融場景下有随機密碼鍵盤，在做自動化的時候這個腳本很難寫，要麼你去點這個坐标，但是點坐标，這個位置是變化的，是以這種場景是比較困難的案例，那我們就通過圖象識别的方式，可以把整個鍵盤解析到，每個按鍵在什麼位置很好地分析，然後去做這個自動化測試。還有一些短信驗證碼，遊戲相關的一些自動化，最後這個測試報告裡面，我們會把我們的測試視訊截圖，性能情況等等都給大家分析出來。
這裡主要講一下我們的思路，為什麼會把視訊也放出來？因為我們之前發展，我們把這個Bug找出來之後，這個地方這個用例失敗了，或者說這個地方應用崩潰了，使用者在解決的時候，根據截圖做判斷發現很多關鍵資訊會丢失，我們發現這種視訊是一個很好的保留上下文的方式。現在在Android、iOS上都标配了這樣的視訊，隻要它的機型有問題，這個用例失敗了，我們就會把整個視訊放出來，發生問題之後我們可以看一下整個的測試流程。你可以看到我們做自動化測試的每一個點選是什麼樣的情況，以此來解決這些問題。但是功能自動化有一個比較大的瓶頸，需要我們去寫腳本，這是一個比較麻煩的事情，尤其是在移動端的APP都是疊代比較快的情況下，我寫一套完整的腳本可能要花一個月，但是一個月以後，這個APP很多應用都已經變了，我再用原先的腳本去跑的時候基本上跑不了了，是以效率上存在很大的瓶頸。
我們解決這種問題是通過線上的錄制方式幫助大家生成這個腳本，這個線上錄制，我們隻需要把我們的手機統一管理在這個平台上，其他的所有人都可以通過遠端的方式去打開這個界面，操作這個手機，你每一步動作它都會給你記錄下來，最後生成一個用例。通過線上錄制可以生成腳本，然後通過手動或者是自動化的觸發做測試。
第三個是用例管理，我們發現大家的業務複雜度上升之後，一個簡單的用例管理的功能很難覆寫到我們的需求，比如說我們有不同的測試環境，或者我們有幾套環境，有測試環境、線上環境，這些環境都對應了不同的參數或者不同的空間，我們如果用一套簡單的模型覆寫這樣的流程，實際上是比較困難的，在專有雲裡面我們提供了更加複雜的用例庫的管理，每個用例之間有關聯關系，可以組成更強大的用例集，最後可以看到每個執行的用例是不是有問題，它的問題是什麼，每個用例都有一段小的視訊，可以看到當時的場景是什麼樣的。
還有一個是智能探索測試，盡量降低大家錄腳本的成本。錄腳本的成本雖然比較低，但是還是要維護的，業務往前走了，頁面是需要改的，錄制的用例還是需要維護。我們想通過這種方式來解決這個問題。我們通過大盤可以看到線上的使用者是怎麼使用APP的，是怎麼用APP的。這些資料都可以放到這個引擎裡面，作為這個引擎的訓練樣本，它就會自動化的幫我們做APP的探索，這個探索就是使用者怎麼用，我就去怎麼自動化的模仿，這樣就可以很大程度地提高我們做這個測試的效果。
當然像一些特殊場景，比如說輸入使用者名、密碼，現在我們也是标配了各種場景的支援，它能夠自動地識别到我們有些登入的場景，有些可能看一些特征，比如說有兩個框、一個按鈕，有一些登入的文本，可以判斷這是不是一個登入界面，是登入界面的機率有多高。其它一些場景也會支援。現在我們的智能探索引擎，用100台手機測試，可以發現30台手機是有問題的。
另外一個是二次開發能力。這個專有雲不是說想把一台iphone給大家，你用它就可以了，我們更想給你一個樹莓派，你可以自己DIY，可以自己搞很多事情。我們提供了大量的開放API的接口，提供了很多插件化的機制，讓客戶基于自己的業務邏輯，更面向自己業務需求的方式編寫新的插件，這些插件就可以很好地被平台去排程，去執行我們想要的測試任務。客戶可以增加很多自己想要的測試項，這樣平台會随着我們的業務不斷地豐富，增加很多獨特的能力，這是與衆不同的，是非常貼近業務的。
還有一個是深度性能測試。也是基于我們的觀察和思考，如果說我們隻是把性能資料采集出來，沒辦法判斷這個問題的根因在哪裡，解決起來就沒有目的性。基于這個問題，我們就做了這個深度性能測試，我們把很多專項的測試項放進去，比如說做記憶體洩露的檢測，做啟動時間的分析，最後我也告訴你，你這個APP是不是有問題，是不是發生了記憶體洩露，記憶體洩露發生之後，我要告訴你整個洩露的原因是什麼，這樣一套完整的定向、定性、定量的資料就拿出來了，這樣我們可以很好地推動這個東西的改進，因為你很清楚這個東西發生問題的原因是什麼。現在的深度性能測試裡面加了8到10項專項的測試，例如卡頓、嚴苛模式等等都會在裡面，帶會有精确的代碼行告訴你哪裡有問題。
這是剛才講的智能探索引擎的測試效果，這是我們做智能探索的一個動作的豐富程度，它現在大概內建了8到10種操作類型，正常我們做APP測試可能就是點選、滑動占了99%，其它的隻占一點點，實際上我們是把整個模型重新更新了一下，有單擊、連擊、長案、多點觸控、按鍵、輸入指令，都會放到裡面。另外，你也會發現你用智能探索引擎做這個測試的時候，它會做一些這種邊界場景探索，比如說輸入框我寫的是輸入一個手機号，但是我會輸入一段中文進去，去看它會不會崩潰，這些都是積累的場景。
另外一個資料就是我們的引擎覆寫控件程度，一個是5分鐘，一個是跑了10分鐘。我們寫了大概有二三十個界面的APP，每個界面的複雜度還是蠻高的，有很多按鈕，然後去看每個按鈕的覆寫程度有多高。5分鐘我們就做到了92%，我們現在的智能引擎基本上可以做到每秒鐘做兩次點選，當然它不是漫無目的的，實際上是要做一個分析，把目前的場景分析到，然後去做一個判斷，我要去對哪個按鈕做什麼動作，然後做這樣一套判斷，用0.5秒鐘。是以說你會看到我們機房裡這些手機會飛快地做這個測試，實際上也不是瞎點。
這是動作數，5分鐘做了540個，另外一個是10分鐘做了1050個。
這是我們給客戶部署的一個專有雲的實施場景，這是客戶幫我們拍的圖檔。這其實就是我們的機架，每個機架裡面放10台手機，Android、iOS都可以，後面是我們的雲管控平台，當然這個雲是客戶的專有雲，基于這個專有雲可以實作對所有這些手機的遠端調試、線上錄制、智能探索，手機在哪怕在異地接入，所有人仍然可以遠端通路這些手機。
測試階段 品質管理
研發階段講完了再講一下測試階段。我說的這個測試階段更多的是釋出之前做的一個全量回歸的測試。現在大家知道移動端，尤其是Android端機型碎片化特别嚴重，我的APP對品質要求很高，我不想把它發上去之後，我的很多使用者用不了，很多機型都不适配，就可以通過這種方式做一個測試。我們是把專有雲裡面講的功能項打包在一起，由測試專家提供這樣一個測試服務，包括他會幫你去回歸測試用例。你隻需要提需求，然後稽核設計的這個測試用例是不是合适的。之後就由測試專家執行這個測試，測試完之後， 會幫你做一個完整的測試報告，報告裡會表明複現路徑，每個Bug的複現率有多高，影響面有多大，都會做一個評估。
專家測試服務的幾個點，第一是測試效率，我們現在是48小時提供測試報告，基本上就是兩天時間，從您這邊送出測試物料之後，48小時會回報這個報告。另外是我們覆寫600款Android機型，70款iOS機型，基本上市面上主流的機型都有。另外一個是我們的專家分析，我們發現Bug之後會幫助大家看看這個Bug是什麼問題，甚至對一些複雜的問題，我們都可以提供定向、一對一的解決方案，當然我們不會幫大家寫代碼，但是會形成解決方案出來。
線上品質管理
然後再講一下線上這部分。這部分我們叫APM或者是線上監控，這個圖剛才大家已經看到了，為什麼會選取這些點呢？大家可以看看，像啟動時間、頁面響應時間、流暢度、崩潰、卡頓、功耗，這些都是使用者感覺非常強烈的點，比如說不流暢，一個遊戲如果不流暢，這個遊戲肯定做不好，如果說打開一個APP要超過5秒鐘，除了強需求的可以忍耐，其它的我都不會再打開，這些都是使用者感覺很強烈的點，這些點背後的問題都是需要我們解決的，這樣才能幫助使用者提升他的體驗。
我們可以通過整個線上的監控和度量體系去找到線上是不是有這種啟動時間比較慢的問題，是不是流暢度是有問題的，會把整個資訊收集過來。
SDK都是all in one的，我們把它加進去，幾行代碼就搞定了，可以通過無痕的方式把資訊采集上來。
我們看到這個啟動時間或者是流暢度有問題，接下來我們要找到這個問題的原因。第一是我們通過這個品質體系知道這個是有問題的，它是不達标的。第二步我們給大家一個多元的分析，把背後的因子、因素、關聯關系找出來。第三個是我們可以幫助大家把問題出現的頁面上下文采集到，我們通過這些資訊可以做線下的複現。到第三步很多問題都可以解決了，但是仍有一小部分疑難問題還是很難解決，可能使用者當時用的場景，就是一些很偶然的因素，你再怎麼複現都複現不了，我們可以通過移動日志或者日志分析，定向地去撈取相關的日志和資訊，可以看到它的上下文是怎麼出現這個問題的，這樣就有很多資料幫我們做分析，而且是定向的。
分析了問題之後，首先做動态部署，然後是做熱修複，還有一個是遠端配置，這是我們的修複方案。
這是我們整個線上高可用體系的一個架構圖，最下面這些是度量的元件，中間是我們的網絡接口，通過這些接口可以把這些資料抛到最上面去，最上面就是一個大型的計算平台，這個計算平台幫大家把内在的關聯因子、關聯關系找到，把這些資料做一些合并、去重分析等等。最後實際上就是我們的告警，出現問題之後，大家可以去設定我的崩潰，比如說某個地方崩潰超過多少的時候就很嚴重了，不用天天盯着它，如果有問題會告訴你。
這是一個高可用的功能界面，這是整個性能的監控大盤。大家可以看看，這是當天的性能資料，這裡有啟動時間，這是跟某個版本的性能對比，這是一個趨勢，這是聚合的日志。這些Bug因為很多、很亂、很雜，需要很多特征幫我們做分析，我們把一樣的Bug放在一起，哪個Bug出現的機率高，影響問題多，我們就把它往前排，客戶就優先把這個問題解決掉。
這邊是所有的錯誤類型。如果說出現了問題，我想拉取某個使用者的資訊，就可以通過使用者日志的方式撈取這樣一個特定裝置的資訊。當時這個機型出現了問題，我們可以看到全量的上下文，解決起問題來會非常有針對性。
這是一個線下測試、線上監控的最佳實踐流程大圖，前面是研發階段去做自動化的打包，然後去做自動化回歸，去做問題的修複。我們在解決問題的時候，如果說問題的原因是我們不知道的，我們就發一條調試的指令到APP上，APP就會把這些資料、當時的上下文、記憶體資訊等等通過這種方式拉取到這個平台上來。我們可以通過這些資訊線上下，在我們的專有雲裡面做回放的驗證，知道使用者當時是怎麼樣的操作流程，看看線下能不能複現，如果能複現的話，基本這個問題八九不離十就可以很好地被解決掉了。這個問題我們找到之後，就可以通過熱修複的方式，通過CDN發到APP上，APP在快速啟動的時候，就可以把原先的問題代碼替換掉，整個就是這樣一個大的流程。線下跟線上的資料流轉就完成了。
這是一個實際效果，從原先的釋出周期30天一個版本，到現在基本上每天都會有一個版本的狀态。我們現在的崩潰率是萬分之二，問題在10秒鐘之内就能發現，一個小時内就可以修複，把問題解決。
原文釋出時間為：2018-05-4
本文作者：字白
本文來自雲栖社群合作夥伴“
淘寶技術”，了解相關資訊可以關注“
”。