建站
咨詢
售后
建站咨詢
新聞中心
在歐洲中世紀的傳說中，有一種叫“人狼”的妖怪，就是人面狼身。它們會講人話，專在月圓之夜去襲擊人類。而且傳說中對“人狼”用一般的槍彈是不起作用的，普通子彈都傷不到也打不死它，只有一種用銀子作成的特殊子彈才能把它殺死。Brooks在他最著名的隨筆文章《No Silver Bullet》里引用了這個典故 ，說明在軟件開發(fā)過程里是沒有萬能的終殺性武器的，只有各種方法綜合運用，才是解決之道。
10年積累的成都網站制作、網站建設經驗，可以快速應對客戶對網站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網絡服務。我雖然不認識你，你也不認識我。但先網站制作后付款的網站建設流程，更有舒城免費網站建設讓你可以放心的選擇與我們合作。
那么在軟件研發(fā)過程中，哪怕沒有銀彈，如何用各種方法去解決這些“人狼”帶來的威脅呢?阿里巴巴在多年的研發(fā)過程中，又是如何對付這頭“人狼”?這一路走來，又有哪些方法和實踐沉淀?
1.阿里巴巴研發(fā)協(xié)同平臺介紹
阿里巴巴研發(fā)協(xié)同平臺(AONE)是阿里一站式智能研發(fā)協(xié)同平臺，目前為阿里巴巴集團，下屬子公司以及生態(tài)合作伙伴提供從“需求->編碼->測試->發(fā)布->反饋”端到端的持續(xù)交付服務，并解決研發(fā)過程中跨角色、跨組織、跨地區(qū)的協(xié)作問題，在此基礎上通過數(shù)據驅動度量分析為組織效能提升提供決策依據，目前這一平臺已經上云對外提供服務，稱為阿里云研發(fā)協(xié)同RDC。(以下簡稱為RDC)
??
??
上圖是整個RDC的業(yè)務框架，RDC采用微服務的架構，從規(guī)劃到運營提供了業(yè)務全生命周期的服務，眾多的服務造成了RDC的復雜度，另一方面作為一個面向用戶的平臺，RDC又涵蓋了阿里三個層次的技術服務棧。
第一層，基礎資源層，包括idc機房、網絡設施、OS、Docker、數(shù)據庫等。
第二層，平臺服務層，包括中間件、調度層、應用服務器等。
第三層，RDC研發(fā)協(xié)同平臺，包括 項目、代碼、應用、測試、交付、運營的管理。
三個層次加起來涉及的核心應用達50+，隨便一個風吹草動就會對系統(tǒng)的穩(wěn)定性造成影響，這些影響最終體現(xiàn)到面向用戶的RDC，因此好的質量保障才能為用戶提供一個穩(wěn)定，高可用性的研發(fā)協(xié)同平臺。
2.質量保障策略
總體采用 “事前預防”，“事中控制”，“事后總結改進”的思想，主要做的三件事情：
??
??
- 測試驅動持續(xù)交付
測試驅動持續(xù)交付，每一次的持續(xù)集成和發(fā)布都從單元測試，API測試，集成測試，UI測試進行自動化測試覆蓋;具體包括：單元測試，集成測試，WebUI測試，移動端UI測試，壓測，線上引流的API測試，線上冒煙測試。
- 線上質量監(jiān)控
對線上質量的保障，主要采用監(jiān)控的方式，希望一有問題就能及時發(fā)現(xiàn)解決，避免問題的大面積擴大。主要包括：
(1) 機器監(jiān)控報警，業(yè)務數(shù)據監(jiān)控。
(2) 對線上運行日志的聚合分析，發(fā)現(xiàn)存在的錯誤。
(3) SLA數(shù)據質量提升，將業(yè)務數(shù)據可視化，指導改進方向。
(4) 面向業(yè)務的監(jiān)控和故障演練，通過對線上7*24的監(jiān)控提前發(fā)現(xiàn)問題保障系統(tǒng)的穩(wěn)定運行。
- 研發(fā)質量提升
通過代碼審核，集團規(guī)約掃描，規(guī)范代碼和提升研發(fā)質量。
3. 持續(xù)交付流程
??
??
上圖是測試驅動的的持續(xù)交付流程，也是RDC各個應用在發(fā)布時的持續(xù)交付流程，通過RDC的發(fā)布功能實現(xiàn)。
(1) 開發(fā)在變更(Change Request)中提交代碼后，觸發(fā)單元測試，檢查代碼中基本的邏輯問題，實踐中單測的覆蓋率和維護由開發(fā)同學自己保證，目前RDC核心應用的單測行覆蓋率在50%左右。
(2) 部署測試環(huán)境，開發(fā)進行自測，主要對新的功能進行基本的驗證。測試環(huán)境與生產環(huán)境完全隔離，具有獨立的網絡環(huán)境，單獨的數(shù)據庫和中間件等依賴環(huán)境。
(3) 自測完成后發(fā)布預發(fā)環(huán)境，由測試同學進行集成測試，包括回歸測試和新功能的驗證，以及對核心接口的小壓測。預發(fā)環(huán)境與生產環(huán)境在同一個網絡中，共享同一個數(shù)據庫，數(shù)據隔離采用邏輯隔離，但是它具有一個獨立的依賴環(huán)境，如獨立的上下游和中間件。
(4) 接著進入Beta測試環(huán)節(jié)，通過截取一部分生產環(huán)境的流量到Beta環(huán)境回放來對核心接口做進一步的驗證。Beta環(huán)境與線上環(huán)境完全相同，不同的是Beta環(huán)境不對外提供服務。
(5) Beta測試完成后，正式發(fā)布生產環(huán)境并對生產環(huán)境執(zhí)行冒煙測試。
以上是一個變更的生命周期，也是一次完整的持續(xù)交付流程。得益于RDC發(fā)布系統(tǒng)和RDC實驗室的集成，我們可以在持續(xù)交付的流程中實現(xiàn)測試的卡點，測試不通過，無法進入下一個階段的發(fā)布。
4.測試技術和方法
以下內容重點討論測試方法和實現(xiàn)方案，以及如何通過RDC完成持續(xù)交付，不涉及代碼實現(xiàn)，部分服務也會在未來上云提供給外部用戶試用。
4.1 分層的自動化測試
傳統(tǒng)的自動化測試更關注的產品UI層的自動化測試，而分層的自動化測試倡導產品的不同階段(層次)都需要自動化測試。在《google 測試之道》一書，對于google產品，70%的投入為單元測試，20%為接口、集成測試，10% 為UI層的自動化測試。如下圖的金字塔形，越往上的投入越低，按照代碼統(tǒng)計的測試覆蓋率也越低。
??
??
4.2 測試框架
- 測試框架的選型
在開始RDC的自動化前團隊對其他測試工具有了一定的積累，各種流行工具，數(shù)據驅動，關鍵字驅動工具，如Fitness,RobotFramework等，也調研過一些特定的測試工具如對http測試的Jmeter, Postman, SoapUI等。
這些工具普遍存在的一個問題是不夠靈活，工具本身比較重，調試麻煩;另一些比較輕量的工具又功能單一，針對性強，無法作為一個測試框架使用，測試場景比較簡單時非常好用，一旦場景變復雜，就帶來了大量的維護工作。
其次也開發(fā)過一些看起來很高大上的框架，有前端有后端，目的是減少測試人員的coding工作，一鍵完成測試，看起來很高大上。 但實際的問題是測試人員的主要工作變成測試框架的維護，最后的結果是業(yè)務綁定太強，無法推廣，而自己的用例覆蓋率也沒有上去。
最后選擇了TestNG作為主測試框架，其他的功能全部交給RDC完成。選擇TestNG的理由：
(1)是靈活，作為程序員可以用代碼實現(xiàn)靈活的場景組織和功能，只要稍微二次開發(fā)一下。
(2)是跟很多框架一樣有Before，after，listener的概念，基于單元測試卻比junit強大，對場景的準備，還原，清理都能較好的處理。
(3)使用java，也許不是好的測試語言，但是團隊的技術儲備java是強項,擁有豐富的開源測試庫，能夠完成單測，API，集成測試，WebUI，移動UI的測試;另一個原因是RDC本身也采用Java開發(fā)。
(4)缺點是冗余，作為一個測試框架，要實現(xiàn)測試比其他的測試框架要多一些代碼。但是作為一個需要長期維護的測試工程，這些冗余也還可以接受。
- 基于TestNG的測試框架
采用分層的方式
??
??
如圖所示，整個測試框架分為四層，通過分層的方式，測試代碼更容易理解，維護起來較為方便。
第一層是基礎測試庫：包括selenium，macaca，ssh庫，httpclient，cli庫等。
第二層是服務層，相當于對測試對象的一個業(yè)務封裝，如http的測試，是對遠程方法的一個實現(xiàn)，對于頁面測試，是對頁面元素或操作的一個封裝。
第三層測試用例邏輯層，該層主要是將服務層封裝好的各個業(yè)務對象，組織成測試邏輯，進行校驗。
第四層測試場景，將測試用例組織成測試場景，實現(xiàn)各種級別cases的管理、冒煙，回歸等測試場景。
測試執(zhí)行
隨著測試用例的豐富和完善，測試時間會越來越長，我們的原則是盡量讓所有的cases在15分鐘內執(zhí)行完，讓整個發(fā)布流程能快速迭代起來，在實踐中采用了兩個方法：
測試調度：主要用于集成測試和UI測試，因為這兩個是對一個系統(tǒng)整體進行測試，RDC采用微服務的架構，整個RDC應用被拆分成十幾個微應用，如果一個應用發(fā)布后測試過程中，另一個關聯(lián)應用也發(fā)布了，那么這次測試結果的意義就不大。
因此在執(zhí)行中加入了調度機制，對關聯(lián)應用進行調度，比如A、B是兩個互相關聯(lián)的應用，A應用發(fā)布后正在進行測試，B應用發(fā)布，這時我們的調度程序會將測試中斷，然后B應用發(fā)布完成后，重新開始測試，最后將結果返回給A、B兩個應用，同時完成卡點。
分布歸并： 在測試集合中我們將用例進行組合，保證每個測試集合都在15分鐘內，一旦發(fā)現(xiàn)時間增加則將測試集進一步拆分，然后將這些測試集并行執(zhí)行，最后將整個結果歸并，既能壓縮時間，又能實現(xiàn)報告的統(tǒng)一。 所有用例在docker中執(zhí)行，動態(tài)的分配測試資源。
4.3 單元測試與依賴隔離
關于單元測試的投入產出不同的公司團隊有不同的認識，實踐中認為單元測試的主要意義在于最低成本的發(fā)現(xiàn)問題，尤其對于代碼的改動，相比集成測試階段的問題更容易定位，并且良好的單元測試習慣能夠使開發(fā)在編寫代碼時更全局的考慮問題。單測中主要需要解決的問題是外部依賴的隔離。
外部依賴的隔離：Mock和Stub
由于單測主要檢查自身代碼，因此需要處理對外部依賴的隔離，常用的外部隔離方式主要有Mock和stub兩種方式，這兩種方式的主要區(qū)別是Mock關注對代碼邏輯的驗證，Stub關注狀態(tài)的驗證。單元測試中采用Mock的方式，原因是Mock能快速的實現(xiàn)單測邏輯，執(zhí)行速度快，而Stub一般需要搭建復雜的模擬環(huán)境，維護成本較高。
隔離工具：Powermock+Mock
通過這兩個工具可以Mock出 1. 構造函數(shù)、2. 靜態(tài)函數(shù)、3.枚舉實現(xiàn)的單例、4.選擇參數(shù)值作為函數(shù)的返回值、5.在調用的mock方法中，改變方法參數(shù)的值。
使用中Mockito可以滿足大部分的需求，但是它的實現(xiàn)機制是使用cglib來動態(tài)創(chuàng)建接口的類的實例，這種實現(xiàn)方式不能用于構造函數(shù)和靜態(tài)函數(shù)，因為這兩個需要使用類的字節(jié)碼(比如使用javassist)，所以結合PowerMock一起。
單測用例
使用TestNG的注釋方式組織用例，通過Assert來校驗邏輯數(shù)據是否期望。
接入RDC和覆蓋率收集
在RDC的【變更】中配置【持續(xù)集成】實驗室，在實驗室中配置單元測試實驗室，RDC會監(jiān)控代碼提交事件，一旦提交則觸發(fā)單測的執(zhí)行。
關于測試評價，目前也沒有特別好的評價體系，所以最常用的還是代碼覆蓋率，在工程的pom.xml中引入cobertura，排除不需要計入的第三方class，RDC單測實驗室中的代碼覆蓋率工具會自動統(tǒng)計覆蓋率。目前RDC的行覆蓋率在50%，據了解行業(yè)內做的好的一般在68%左右。
4.4 大集成測試
集成測試是整個持續(xù)交付中最重要的階段，穩(wěn)定可靠的集成測試能夠減輕測試工程師的壓力，其次能促進開發(fā)和測試之間的相互信任，形成良好的互動。集成測試一般采用API的方式，在預發(fā)階段進行，選擇這一階段的原因是環(huán)境較為穩(wěn)定，測試發(fā)現(xiàn)的問題能真正反映系統(tǒng)的問題。
集成測試的方式
如上面分層測試的框架中，采用httpclient作為工具，將遠程的http服務封裝成本地服務，再進一步實現(xiàn)測試用例和測試場景。
集成測試規(guī)模
集成測試按照集成的規(guī)模，分為小集成測試和大集成測試，小集成測試一般是在某幾個系統(tǒng)之間進行集成，大集成測試在整個系統(tǒng)中進行，這兩個主要區(qū)別是測試覆蓋和測試時間，我們使用最在靠近用戶UI一層的API進行大集成測試，這一層更能體現(xiàn)真實的體驗，能用最少的投入產生最大的價值。測試時間通過測試調度控制，每一個子系統(tǒng)發(fā)布時檢測是否有測試進行，如果有則停止再重新觸發(fā)。
接入RDC
在RDC應用中有【測試驗證】，選擇【添加驗證點】，設置階段為預發(fā)集成測試(也可選擇其他階段)，同時在此處可以設置卡點的條件，如設置測試通過率99%，當你的測試通過率小于這個數(shù)字時在發(fā)布流程的預發(fā)測卡點中將會報失敗，防止將測試驗證不通過的代碼發(fā)布到線上。
4.5 云瀏覽器上的UI自動化測試
UI測試是一個很繁雜的事情，投入產出比不高，UI測試最大難點在穩(wěn)定性和維護性方面，因此我們在UI功能測試當中只覆蓋主流程和最基本的頁面檢查，主要對主流程進行覆蓋，如增、刪、改、查等這些出錯會造成系統(tǒng)不可用的功能進行覆蓋。
UI測試的實現(xiàn)
UI測試采用selenium，通過selenium時將頁面元素和功能進行抽象，稱為PageObject，如頁面的增加按鈕，查詢按鈕的封裝作為PageObject放在服務層，而測試邏輯層則用這些服務組裝成需要的測試邏輯。值得分享的是使用selenium做UI測試時盡量采用css，css定位較為準確，相比xpath定位速度較快，對比的結果是采用css比xpath速度最快能到20倍，尤其在IE上。
UI測試另一個比較麻煩的事情是兼容性，由于各類瀏覽器的快速迭代經常造成selenium連接瀏覽器、獲取元素失敗。因此我們對selenium-grid進行了二次開發(fā)，搭建瀏覽器云，根據指定的瀏覽器類型，版本、以及selenium的版本等在指定的瀏覽器上運行，滿足兼容性測試的同時，保證UI測試的穩(wěn)定運行。
接入RDC
跟集成測試一樣，通過將UI測試配入發(fā)布流程進行卡點;實踐中是通過RDC實驗室的多階段將集成測試和API測試同時配到了預發(fā)環(huán)境，完成測試卡點。
4.6 全站式UI頁面校驗
如上面提到的UI功能測試主要針對主流程功能性的邏輯測試，無法對頁面元素和展現(xiàn)進行校驗，因此我們對UI進行地毯式的校驗，采用的方法是 頁面元素+圖像比對。
基本步驟：
第一步：使用selenium對RDC的各個頁面進行爬蟲，深度為主域名以下三級Link，并遍歷出這些頁面的元素，主要對文字、Button、Link、Form元素進行收集，保存到數(shù)據庫中。
第二步根據前面錄制的Link，分別檢查頁面能否正確打開，并校驗這些頁面是否包含存在的元素。
第三步爬蟲腳本完善，由于個別頁面的變化和對頁面排版的要求，對導致測試失敗的腳本進行完善，去掉動態(tài)元素，由于動態(tài)元素不是很多在整個測試過程中影響不大;另一個是對展示要求較高的頁面加入圖像比對，提前對屏幕進行截取(分塊截取，動態(tài)內容不做截取，這部分在前面的功能測試中進行覆蓋)，在回放中會對相應頁面進行截取，使用工具sikuli將兩個截取的圖片進行比對。
4.7 核心接口壓測自動化
曾經有個故障，原因是開發(fā)的修改導致接口變慢。因此我們將壓測加入到常規(guī)的測試卡點中，在每次系統(tǒng)發(fā)布前都會進行一次壓測，將RT值進行對比。
(1).壓測腳本采用jmeter，在jmeter中維護系統(tǒng)的關鍵接口，將jmeter的壓測結果用csv保存，設置測試執(zhí)行的時間和并發(fā)線程數(shù)，一般設置為10個并發(fā)，時間為8分鐘。
(2).準備基準數(shù)據，基準數(shù)據為系統(tǒng)在穩(wěn)定情況下，將上面的腳本執(zhí)行10次，這10次執(zhí)行的rt值為基準的數(shù)據，并將每個接口的基準數(shù)據保存在一個文件中。
(3).測試結果對比，如此每次jmeter的運行后會產生一個csv的測試結果，將這些結果與之前的基準數(shù)據進行對比，如果結果落在的基準期間或者未超過最大基準數(shù)據10%(根據不同接口的響應時間這個百分比不一樣)，則認為這次測試通過，并將這次通過的結果也插入到基準數(shù)據中，如此不斷更新基準數(shù)據，最終保留30次的執(zhí)行數(shù)據。數(shù)據處理采用pyton的pandas。 如果測試不通過則發(fā)送對比圖片給相應的開發(fā)同學。 如下圖反映了一個接口的異常響應時間。
??
??
接入RDC
通過在預發(fā)階段新建【自定義實驗室】 可以將jmeter的運行腳本，結果處理以命令行的形式配置到實驗室完成測試卡點。
4.8 移動端真機測試
目前針對Android主要采用instrument的方式，對ios則采用自帶的的sdk的方式，隨之而來的問題是針對不同平臺需要兩套測試代碼。開源的macaca和appium解決了這個問題，這里選用macaca來進行測試，相比較Appium優(yōu)點是運行穩(wěn)定，去除了appium老版本Android的支持，而且macaca有專門的團隊進行支持。使用macaca能夠像selenium一樣對移動端的界面進行測試。
真機測試環(huán)境搭建
起初為了節(jié)省成本，采用了android和ios的模擬器，實踐中模擬器的可用性太差，各種啟動慢，異常退出，基本無法使用。最終采用了jenkins+服務器+真機的集群方式，服務器安裝jekins的slave,ios和android環(huán)境，手機接入服務器，并在服務器上安裝macaca服務。
測試執(zhí)行
如上采用jekins中央集群的方式，通過jenkins來配置要進行測試的機型，jenkins根據機型查找手機所在的服務器和手機的uid，并將測試代碼下載到該服務器，執(zhí)行測試腳本，并返回結果。
接入RDC
目前RDC尚未提供真機環(huán)境，因此我們使用Jenkins管理真機環(huán)境，然后通過調用Jenkins的Rest接口，觸發(fā)測試在真機環(huán)境上運行，執(zhí)行完成后解析Jenkins的報告為RDC格式的結果，即可在RDC的實驗室中展示測試結果，進而實現(xiàn)對發(fā)布流程的卡點。
4.9 AOP錄制回放進行API測試
傳統(tǒng)的API測試，一個接口一個接口的編寫代碼，準備測試數(shù)據，添加驗證點，工作量大，覆蓋不全，測試效果不明顯。這里我們引流生產環(huán)境的流量來進行API測試，原理是AOP的方法攔截。主要有三個步驟，線上流量復制，回放，寫操作的Mock。
錄制回放
錄制：使用ASM修改被測接口的字節(jié)碼，侵入生產環(huán)境(生產環(huán)境提供一臺機器)，在每個被測方法執(zhí)行前攔截得到需要的參數(shù)，方法結束時攔截得到返回的響應值。將錄制的返回值和方法序列化后保存到數(shù)據庫，需要注意的是對寫操作和外部系統(tǒng)的調用可能會對生產數(shù)據造成破壞，所以對接口內部的方法依次進行跟蹤，跟蹤到寫操作時，錄制寫操作返回的數(shù)據。
回放：同樣采用ASM在測試環(huán)境(Beta環(huán)境)修改被測接口的字節(jié)碼，觸發(fā)接口的調用，在被測接口中使用上面錄制的參數(shù)，接口執(zhí)行完成后將錄制的結果和這次執(zhí)行的結果進行對比，結果一致則測試通過。
Mock:對于寫操作，由于我們采用的Beta環(huán)境和生產環(huán)境采用同樣的數(shù)據庫和外部系統(tǒng)，因此到寫操作不能真實的寫入數(shù)據，需要在寫操作的方法中直接返回上面錄制的寫操作數(shù)據。
接入RDC
在上面的錄制環(huán)境和生產環(huán)境中，安裝agent開啟http服務，跟RDC實驗室進行通信并控制測試的執(zhí)行，最后的返回結果被RDC解析，從而實現(xiàn)發(fā)布卡點的功能。目前該系統(tǒng)正在改造，改造后將對云上用戶開放。
4.10 測試報告
測試報告同樣采用了分層的報告，分為：實時報告，單次執(zhí)行報告，統(tǒng)計分析報告。
實時報告
主要針對線上用例的冒煙測試，原因是測試用例全部跑完需要一定的時間，而對于線上我們希望能盡快的將錯誤反饋給開發(fā)并解決，所以一旦有錯誤就會實時將錯誤信息和的現(xiàn)場通過釘釘發(fā)到開發(fā)群。
單次執(zhí)行報告和后臺日志
單次的執(zhí)行主要是對這次運行的結果做展示，包括測試用例，測試步驟，截屏等。 在發(fā)送報告的同時我們會拉取測試時間段應用的后臺日志，這些日志包括了錯誤所在的機器，出現(xiàn)的時間點，stack以及，各個應用接口間的數(shù)據傳遞，通過這些日志能方便開發(fā)同學快速定位問題。
統(tǒng)計分析報告
在測試過程中同樣需要對測試代碼的改進和測試穩(wěn)定性的提高，每次測試完成后我們會將這次測試的結果解析發(fā)送到我們的一個測試報告系統(tǒng)中， 對通過率，失敗次數(shù)等進行統(tǒng)計分析，通過一個時期的分析來找出值得改進的測試用例或系統(tǒng)功能，從而提高測試穩(wěn)定性和系統(tǒng)穩(wěn)定性。
下圖是幾種測試報告的一個圖片合集：
??
??
5 線上質量監(jiān)控
5.1機器和業(yè)務監(jiān)控
對于機器監(jiān)控有很多開源的方案，在此不再詳訴，一般來說主要采集機器的CPU，內存，TPS，JVM等指標，一旦某個指標跨過紅線，及時做出報警。
對于業(yè)務數(shù)據比較復雜，根據RDC的業(yè)務有幾十種不同的監(jiān)控指標，這里我們主要采用的是日志打點的方式，RDC的各個子系統(tǒng)的都對輸出日志進行了改造，生產環(huán)境的每臺機器會有一個專門解析日志的agent，這些agent增量的實時監(jiān)控業(yè)務日志，并將日志解析得到跟業(yè)務相關的數(shù)據，發(fā)送給監(jiān)控系統(tǒng)，從而監(jiān)控系統(tǒng)能得到某個點或者某個時間段內的業(yè)務情況，根據劃定的業(yè)務指標紅線給出報警。 該系統(tǒng)目前正在進行改造，之后將提供給云上用戶使用。
5.2線上日志聚合分析
由于現(xiàn)在系統(tǒng)都采用微服務的方式，系統(tǒng)拆分較細，每個微服務又都采用集群的方式運行，因此系統(tǒng)只要正常運行，后臺發(fā)生了多少錯誤幾乎沒有人關心，而這些錯誤有可能是導致故障的潛在隱患。
我們采用了阿里云的sls日志收集功能，將RDC相關應用的日志接入到sls，每天晚上00：00按應用對RDC當天產生的日志進行聚合分析，目前通過一定的算法對錯誤信息進行聚合，發(fā)現(xiàn)問題和缺陷，自動提交bug，并發(fā)送當天的統(tǒng)計報告。 目前通過日志的聚合分析，RDC修復了大量穩(wěn)定性方面的錯誤，錯誤數(shù)由之前每天的十萬量級降低到現(xiàn)在的千級。
5.3 SLA服務數(shù)據驅動質量
將用戶體驗量化，如何為用戶提供極致體驗，一直是我們努力的目標，然后由于RDC上下游系統(tǒng)較多，如何評價現(xiàn)有系統(tǒng)，采用將服務體驗數(shù)字化，通過將每一層的服務數(shù)字化來找到問題的瓶頸。
數(shù)據的收集采用了兩種方式，一種是直接從數(shù)據庫中提取數(shù)據，另一種是通過打點的數(shù)據提取業(yè)務數(shù)據。將這兩種數(shù)據經過計算統(tǒng)計報表的形式展現(xiàn)，從而清晰的知道目前系統(tǒng)的情況。
如圖是某一周的業(yè)務數(shù)據：
??
??
通過這些數(shù)據能夠了解到整個系統(tǒng)的瓶頸，從全局了解系統(tǒng)和用戶感知的差距，并指定目標和改進計劃。 目前的問題是無法智能的拿到這些失敗或錯誤的原因，比如出版本失敗率0.14%，這0.14%是什么原因導致的需要花很大的精力排查，如何智能的找到問題，減少排查工作是下一步要做的工作。
5.4 面向業(yè)務的穩(wěn)定性監(jiān)控和故障演練平臺
功能監(jiān)控，將RDC相關系統(tǒng)的冒煙用例在線上7*24小時連續(xù)不斷運行，來及時發(fā)現(xiàn)線上的問題，盡量在先于用戶發(fā)現(xiàn)問題避免故障面的擴大。
頁面監(jiān)控，同樣對RDC的頁面7*24小時訪問，看這些頁面是否能夠正常訪問，鏈接是否被修改。
故障演練，根據RDC系統(tǒng)和業(yè)務邏輯制定專門的故障演練方案，將這些演練場景驗證點用自動化實現(xiàn)并接入到故障演練平臺。目的是能實現(xiàn)可靠地自動化故障演練，從而讓演練按需隨時進行，發(fā)現(xiàn)復雜場景下潛在的故障。
6 .研發(fā)質量規(guī)范和提升
研發(fā)質量的提升目前主要包括代碼審核、代碼質量檢查好研發(fā)效能數(shù)據的回溯。
代碼審核：在RDC上創(chuàng)建變更時會指定響應的代碼審核人員，發(fā)布時指定的開發(fā)同學會對發(fā)布的代碼進行審核，除了保障質量外，最重要的是通過審核提供開發(fā)人員的代碼質量和代碼規(guī)范，減少較低級的錯誤。
代碼掃描：我們Sonar掃描+阿里巴巴集團規(guī)約掃描的方式，要求對Blocker和Critical的問題必須修復后才能上線，其它級別的缺陷不能超過20%。
研發(fā)效能回溯：RDC提供的度量功能是一個團隊的研發(fā)情況看板，它能夠反映研發(fā)團隊在處理需求，缺陷、發(fā)布、回滾以及有效代碼量等方面的情況，從多維度的統(tǒng)計一個團隊的研發(fā)能力和研發(fā)效率。通過每周回溯這些數(shù)據，找出團隊存在的問題，促進研發(fā)效能的提高。
7. 總結和展望
對于自動化測試，希望能用更有效的發(fā)現(xiàn)問題，尤其在UI測試上，考慮如何用最低的成本獲得最大的回報，進一步完善爬蟲式測試回放的工具，增加測試的覆蓋率。
線上質量的監(jiān)控，希望能夠對故障進行預測，目前我們做到的還是對故障的處理，比如故障發(fā)生10s內發(fā)現(xiàn)，3分鐘能響應處理完成，但是如果能夠對故障進行預測將極大的降低系統(tǒng)風險，所以下一步工作是對海量錯誤日志，故障數(shù)據，用戶反饋數(shù)據，監(jiān)控數(shù)據進行數(shù)據挖掘分析，并結合實時監(jiān)控建立自學習的預警系統(tǒng)。
【本文為專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉載請聯(lián)系原作者】
??戳這里，看該作者更多好文??
名稱欄目：如何將bug殺死在搖籃里？
分享網址：http://m.fisionsoft.com.cn/article/cogdpci.html
