[編者注：這篇文章很長（8998個字），但作者用心良苦，基於44個GBA Bug的分析，幾乎讓我們獲得了軟件測試工程師一生職業生涯中所需的經驗、找Bug所需的技能，值得慢慢閱讀和體會，然後記錄下對自己有用的要點。]
前言這個文章也是欠了大半年了，現在想要出來還賬了。熟悉我的測試同仁們，應該都記得我在12年前分析過淘寶GBA的近100個優秀提名bug，從中分析總結出互聯網測試模型（《探索式測試實踐之路》裏面有詳細的內容），指導測試工程師在某些特定場景下進行異常場景的測試設計，發現那些隱藏深處的bug。GBA活動在阿里和螞蟻運轉了10多年了，這個GBA獎項是測試工程師返璞歸真尋找測試價值的榮耀，背後代表的是測試工程師的在測試過程中體現的測試技術深度和廣度。如今10多年過去了，測試技術和測試平臺都有了非常大的發展，那麼從GBA的優秀bug也同樣看出來阿里螞蟻的測試技術發展以及當前的核心測試技術。GBA 概括
GBA 全稱是 Golden Bug Award，簡稱 “金 BUG” 獎。由淘寶測試團隊開創，後推廣至阿里和螞蟻。衆所周知，發現產品項目的缺陷是我們測試工程師所從事最頻繁的日常工作，如何發現定位缺陷也是我們測試工程師的基本技能，所謂技能自然就有高低優劣。如果你能夠發現別人發現不了的 BUG，或者在挖掘 BUG 的方法策略上更加有效，那就證明你的能力更勝一籌。設立 GBA 這一獎項的目的，正是爲了體現測試工程師的這一核心價值能力。我們一貫認爲，GBA 是測試人員的個人最高榮譽，重要的 BUG 價值堪比黃金，GBA 大獎也的的確確就是純金製作的獎品。2011 GBA回顧簡單回顧下從2011年GBA提名bug分享總結的一些關鍵點，發現優秀bug 聚焦在異常測試場景的設計和測試執行上（多併發場景、功能安全、數據庫異常等），絕大多數是靠手工測試發現的；5%的bug是靠某些工具平臺支撐發現的；整體上來看，這些優秀bug 是站在測試工程師優秀的異常場景設計和堅韌不拔的測試執行上（非必現但是測試執行過程複雜）。2022 GBA基本情況由於阿里螞蟻的BU特別多，各個業務線也特別多，所以2022 GBA 按照每個BU維度進行了GBA評選，阿里螞蟻44個BU，產出了44個GBA Bug，覆蓋了所有不同的業務和產品，這44個GBA bug代表的是阿里螞蟻是如何判斷優秀bug的，代表的是阿里螞蟻測試工程師是如何發現優秀bug的，代表的是阿里螞蟻測試技術的關鍵點和方向。由於這些bug背後的業務和產品都很複雜，筆者個人也並沒有做過多的深入瞭解和分析，期待能找到一些共同點以及啓發（雖然很難，盡力而爲）。2022 GBA 揭祕2022 GBA揭祕之一 - 流量錄製回放技術大放異彩44個BU級別GBA bug中，有14個Bug （其實比例是非常高的，筆者在分析過程中也有點驚訝）是利用流量錄製回放或數據對比的方法發現的，爲什麼是通過這個方法發現的呢，通過這個方法發現的bug基本上是在系統重構類或數據遷移類的項目類型中的。做過業務測試的同仁們應該知道這兩類項目的測試難點和重點在哪裏，很多時候靠經驗靠人肉去解決，現在有了流量錄製回放或數據對比的方法後，測試執行效率提升了很多，發現bug的效率和bug的深度也會提升很大。那麼，這裏面的測試技術的難點到底是什麼呢？測試工程師需要開發相應的流量對比或數據對比的工具（通用的接口流量對比能力除外），同時還需要在白盒角度來分析出可能隱藏的bug，還要不斷的重現這個bug，和開發討論這個bug情況和存在的原因等。那麼，如果是單純的利用工具發現bug的，那麼針對其他測試工程師來說啓發是什麼呢？這些bug往往是通過某一種測試方案來發現的，可以發現很多類似的隱藏bug的，這裏總結幾個要點，比如：發佈類、遷移類，不可窮盡的測試場景下提供了一種儘可能提升測試覆蓋率的方案；比如：新引擎上線後的迭代開發的灰度驗證中；新老接口的正確性最好的方案就是新老對比等。總結來說，基於對歷史線上問題、故障的review分析，可以發現：問題都是暴露在一些複雜組合甚至極端的場景中，也就是常規分析測試手段較難命中的；測試場景均爲場景量大不可窮舉或很難全部驗證覆蓋或數據構造難執行難的場景，場景case量大不可窮舉、難以完全執行驗證、難驗證難構造、且有歷史流量/數據、有比對基線，在這些背景下，都可以採用基於線上數據仿真造流回放來完善測試驗證。基於線上數據仿真造流回放，有以下幾點核心優勢：
- 效率高：藉助仿真基建，在測試階段成功回放完成X億流水數據，重現了線上用戶已有操作場景和鏈路。
- 可複用：仿真造流，可沉澱可複用爲常態化測試驗證能力，後續將沉澱爲數金仿真造流平臺的測試資產，來豐富並完善全流程全階段的測試驗證及迴歸能力。
- 通用性：在某些分佈式架構體系或多主體多架構部署體系下，通過造流、引流進行仿真回放可完善爲常態化質量驗證手段。
大家都知道流量錄製回放在阿里螞蟻是應用最廣的測試技術，也是傳統自動化測試的升級版，那麼是不是說傳統自動化測試就沒有任何價值和使用了呢，並不是。在44個GBA bug中，我們發現有3-4個自動化測試發現的優秀bug，這些bug從發現角度來看難度並不大，但是從問題復現和問題確認的角度來看難道比較大，涉及到很多開發技術的瞭解（引擎、Blink、灰度切流、多線程實例），同時也需要強調的是這些自動化測試場景並不是獨立的單接口的自動化測試case，而是全鏈路級別的自動化測試case。另外需要強調的是針對多線程併發角度總結出更多的經驗，研發同學在開發過程中，如果使用到ThreadLocal必須及時remove清理，最好能在框架層面afterExecute中執行remove，避免遺漏。但是更加建議的方案是，在每次使用ThreadLocal前，還是要再評估下，是否這纔是更好的實現方案，儘量不要把坑留給後面的人。所以測試工程師要把全鏈路自動化用例做全做厚，所謂做全，就是產品和場景的覆蓋度要做到核心100%覆蓋，所謂做厚，就是場景的校驗點要做到全分支覆蓋校驗，校驗點的細度要精確到每條落庫的數據。
2022 GBA揭祕之二 - 專業領域測試工具精準出擊阿里螞蟻的業務特別多，不同的業務會有自己業務特點的測試工具，這次44個GBA bug中，我們發現有11個bug是通過專業領域的測試工具發現的。這些bug涉及到的業務領域包括視頻直播、安全、算法、搜索、大數據等，涉及到的開發技術包括Dataworks、ODPS SQL、Hologres SQL以及PyODPS 3種數據開發形態；同步調用受理+異步回調通知；分佈式鎖組件，併發鎖、冪等、狀態鎖表、語音識別、HTTP2.0等。那麼，這裏面的測試技術的難點到底是什麼呢？和使用流量錄製回放工具類似的，測試工程師需要開發針對這些業務特點的測試提效工具，同時還需要在白盒角度來分析出可能隱藏的bug，還要不斷的重現這個bug，和開發討論這個bug情況和存在的原因等。那麼，如果是單純的利用專業測試工具發現bug的，那麼針對其他測試工程師來說啓發是什麼呢？同樣的，這些bug往往是通過某一種測試方案來發現的，可以發現很多類似的隱藏bug的，這裏總結幾個要點：1）在支付業務中，無論領域內模塊交互或與外部交互上，“同步調用受理+異步回調通知”是典型；更優的驗證方式是對上鎖事務做延時模擬或異常拋送，後續也考慮對該類驗證做常態化和工具化。2）直播專項測試設計和評測能力，開發測試工具模擬高碼率的推流場景，發現卡頓問題。3）一些大型項目中的一些可測性問題，提前思考測試思路，指定好測試方案，提前沉澱自動化工具，方便測試進行時及時發現問題，提高測試效率 。4）當業務存在表a數據狀態強依賴表b數據狀態推進時，單表加鎖處理邏輯複雜且影響性能時，可以採用下述普適解決方案，使業務併發異常邏輯處理更簡單高效。
普適解決方案：
|
2022 GBA揭祕之三 - 性能測試問題脫穎而出回顧下11年時的GBA bug沒有一個是性能測試bug，但是這次44個GBA bug中，我們發現有8個bug是通過性能測試發現的（包括專業領域的性能測試工具）。這裏也可以看出，這十幾年來，業務的變化和架構的變化，至於哪些變化，可以參考《互聯網測試轉型之樂與悲》，針對性能測試的要求以及穩定性要求也有很大的變化。那麼，這裏面的測試技術的難點到底是什麼呢？一方面是專業領域的性能測試工具開發，另外一個是關聯的開發技術更多，要了解的深度也更深，包括Service Mesh，Golang，time.Sleep；混合雲、飛騰2500芯片、底座元數據庫；網關接口協議；雲原生底座、Redis的mset刷緩存、Redis 配置；ArrayList，LinkedList等。那麼，如果是單純的做性能測試發現bug的，那麼針對其他測試工程師來說啓發是什麼呢？這些bug往往是通過建立業務特點需要的性能測試方案來發現的，這裏總結幾個要點：1）性能測試中，可以使用全鏈路排查能力對壓測流量接口服務鏈路數據的採集，最大程度的保留壓測期間的流量響應數據，快速定位到某個場景存在性能瓶頸；容量評估過程的建立一套可沉澱、可複製的資源計算方法，建立業務壓測容量模型。2）測試在壓測過程中需要進行核心鏈路和功能迴歸來驗證功能的穩定性；在特定場景且系統達到一定水位後才能爆發的問題，發現問題需要具備一定的探索性能力。3）性能測試常態化運行，日常自動地把鏡像交付、壓測場景執行、報告整理、問題追蹤等環節流水線化；代碼評審環節下，需要定期地分享典型案例，因爲專家也需要成長積累，不斷補充代碼掃描規則是沉澱專家經驗一種手段。4）壓測問題定位前建立“施壓端-服務端”的全鏈路可觀測機制，尤其是自研施壓平臺，分庫分表規則不可以有熱點不均衡數據（字段避免使用xx賬號），避免因流量不均衡誘發業務性能或者穩定性問題，關注網絡IO瓶頸，如帶寬佔用、TCP發送/接受緩衝區是否堆積等等。性能測試在阿里螞蟻是測試開發工程師的必備技能，特別是在系統重構類的項目測試過程中，在開發技術、業務場景、編碼能力的驅動下做好性能測試並不是一件很難的事情，筆者在分析這類型的GBA bug時，再次驚訝於阿里螞蟻的測試工程師的技術能力和分析能力、通過技術手段解決測試難點的能力。
2022 GBA揭祕之四 - 測試攻擊手段百花齊放筆者在分析44個GBA bug過程中，由於個人情感，一直想看到是因爲超高的測試設計技巧然後通過手工探索式測試發現的優秀bug，也想看到通過其他測試手段發現的優秀bug，也想看到需求階段或設計階段發現的優秀bug。幸運的是，我看到了這些bug，這些bug代表的是測試工程師另一個角度的軟能力，包括批判性思維能力和錯誤推測能力。由於這些bug 非常寶貴，接下來會花更多篇幅來詳細說說這些bug。通過探索式測試發現域名跳轉和跨站跟蹤bug這個bug是通過不同的瀏覽器來測試某個業務場景在域名跳轉和跨站跟蹤的鏈接是否正常時發現的，發現過程：使用safari 瀏覽器進行測試，pc和手機上的瀏覽器 都有問題（最新版的iphone系統默認開啓了safari的阻止跨店cookie），發現 safari、chrome瀏覽器具備可屏蔽跨站跟蹤能力，其中safari13.1版本之後默認開啓屏蔽，chrome目前非自動開啓。在瀏覽器兼容性測試時候，測試工程師需要熟悉瀏覽器安全特性的默認配置；跟瀏覽器安全隱私策略有關，可以手動打開和關閉；這個bug是在瀏覽器安全隱私機制升級導致的。從該bug發現和確認問題過程中，bug發現者通過多個瀏覽器版本和不同配置探索出隱藏的問題，同時總結一些測試執行過程中需要具備的品質：
- 發現問題時：對任何疑點絕不放過，要有懷疑精神。
- 定位問題時：不怕困難，對出現的問題追查到底，抱着解決問題的態度找外部合作的開發一起排查。
- 解決問題後：契而不捨，精益求精，推動合作的開發尋找最優解法，思考出可複用的測試能力。
通過代碼故障注入發現多線程併發bug這個bug是出現在系統重構類的項目中，bug發現者在項目上線前，梳理系統核心流程，評估內部實現隱藏風險；對代碼行進行故障注入，使得updateOnlineTouch方法超時，未執行方法邏輯，從而發現bug。
從這裏可以看出，bug發現人非常熟悉系統代碼實現，也善於從代碼角度來測試和驗證異常邏輯，給我們的啓發就是：對系統核心流程做風險評估和異常測試，必須是詳細設計，甚至是代碼都熟悉；利用故障注入來驗證自己的猜測；數據一致性問題值得關注，系統要有自恢復能力。
通過異常模擬發現多線程併發bug這裏有2個GBA bug都是這個類型的（多線程併發的問題是互聯網產品場景下常見的隱藏bug），也是徹徹底底的手工功能測試發現的bug，非常類似於12年前的GBA優秀bug，發現過程是bug發現人設計異常場景，類似於多賬號同時登錄或操作，多線程併發情況，發現功能安全問題或多線程超時異常問題。這個bug可以成爲GBA bug的原因是這個安全性的問題具有隱蔽性和比較難發現。給我們的啓發就是：測試工程師要敢於從不同的角度去嘗試，比如站在異常用戶的角度，怎麼讓賣票的時候出現同一張票超賣的情況，一張票能變成2張票，從而找到問題的突破點。安全場景監控和覆蓋，因此質量保障同學除了常規的功能測試，也需要從安全方面入手，用例設計階段需要考慮到安全場景。另外就是針對併發場景下子線程數據獨立存儲的技術方案，可以進行數據一致性的風險評估，包括如下幾個點：測試前進行正常場景和異常場景的分析，儘可能全的覆蓋業務；測試階段能夠藉助工具模擬各類異常場景的復現，達成測試預期；獨立分析業務上可能的資損場景，推進行開發建設線上資損覈對監控，以防測試遺漏。
通過bug fix code分析發現更多bug這個bug是在某個業務的常規迭代過程中，最初bug發現者的測試場景是新人首單下單後並取消訂單，這時發現用戶依然是老客，定位發現沒做取消訂單的人羣移除邏輯，於是提交bug，研發增加了取消訂單的老客人羣移除邏輯，並驗證通過。
接下來bug發現者通過了解開發fix bug的邏輯，和看代碼，瞭解可能存在的問題場景，然後測試執行，發現另外兩個問題。給我們的啓發就是：在修復了一個正向bug的時候，要考慮是否引入了其他方向的隱藏問題，使原本的小問題變成了更大的問題；除了發現功能問題外，也要發現性能穩定性的問題，例如下單場景的無效查詢，查庫改緩存查詢等。熟悉我的同仁們應該看過我很早就提過的測試經驗之一就是多看bug fix後的code change，看不懂也要看，看不懂你就問開發，總有一天你會看懂的，你會發現code背後隱藏的bug的，那個時候開發給你豎起大拇指的時候，就是你的測試價值體現更完美的時候，這個時候，你還擔心測試沒有未來嗎，你還擔心你不漲工資嗎，你還擔心你不能年薪百萬嗎：）。
通過技術方案設計異常場景發現一致性bug測試左移的重要性和實踐之一就是能從技術方案中找到可能存在的問題和風險，然後設計測試場景證實系統這樣實現是否存在問題。這個bug發現者必須熟悉重試、dubbo遠程調用、分佈式鎖、冪等 等技術原理，同時結合業務場景發現了這個隱藏bug，給我們的啓發就是：1）首先需要關注設計的合理性，其次是這種改造可能帶來的問題是什麼，以及對應的解決方案， 上游業務批量操作時，需要了解下游的分佈式瑣機制，更要避免由於分佈式瑣導致的數據不一致問題。2）從測試設計來看，需要從技術方案識別的問題去設計測試方案和用例，這個問題裏需要關注最終一致性和性能。面對數據不一致，需要加強資損對賬校驗；對於冪等問題，需要了解應用間的冪等處理結果，是返回成功，還是返回異常。3）在提測前，先評估是否會會存在併發場景，確定併發的技術實現方案是緩存系統分佈式鎖還是數據庫樂觀鎖，再根據不同鎖實現方式check可能存在的問題，最後通過併發測試執行來確定問題。如下是來自於bug發現者的總結思考：
通過技術方案評審發現設計bug大家都知道，不同的階段發現的bug帶來的修復成本是不一樣的；我們鼓勵在測試執行之前發現更多問題，測試工程師通過分析技術方案的實現邏輯發現設計上的問題是很讚的。這個bug發現者在參加常規迭代過程中某個需求的技術方案時，並沒有完全信任開發人員選擇的實現邏輯，而是主動去分析和技術調研，提出了另外一種更好的實現邏輯方式，且更適合當前業務的特點，最終開發採納和認可了這個方案，降低了開發實現成本、系統的複雜度和維護成本；做測試的成就感和幸福感滿滿的：）。這個bug發現者也思考了更多問題，比如：1. 需求分析過程能不能抽象出來？這樣就可以讓大家都可以複用這個模型發現這類問題？更進一步的話是不是需求調研階段就可以排除掉這類bug？2. 研發流程規範上有沒有什麼可以優化、改進或者借鑑的地方？優化後如何落地？落地後如何通過數字化的方式度量？3. 測試工具也好，研發流程也好，都是爲了迴歸到業務上，那麼我們應該如何去思考和看到我們的業務？這三個問題，本文就不給具體的答案，也期待大家自己的思考；針對測試左移的具體做法，不同業務會有不同的執行策略，該bug發現者也總結了電商業務下自己的評估模型，經bug發現者同意，本文分享這個模型給到大家做一個參考。
2022 GBA 總結阿里螞蟻的所有測試工程師每年至少發現數十萬個bug，這44個GBA bug只是其中的一些典型代表，TA能說明一些關鍵點，也不能說明一些結論；從以上的揭祕章節，再結合2011 GBA的bug特徵，相信大家能體會到阿里螞蟻的測試技術發展的幾個關鍵點，包括如下：1）利用工具發現的優秀bug更多了。2011 GBA的bug 基本上只有手工測試發現95%，工具發現5%的比例；而到2022 GBA，手工測試發現10%，工具發現90%的比例（當然2022 GBA的bug基數只有44個，充分性不足）；大家從這裏看出測試技術的發展和開發技術的發展的融合了吧。2）自動化測試一直是主旋律。互聯網敏捷研發和敏捷測試、雲原生作爲大的背景，都對自動化測試提出了更高的要求，自動化測試框架也經過了一代又一代的迭代和更新，當前主流互聯網產品業務是流量錄製回放爲主要手段、再輔助全鏈路接口測試，當然了，還包括各種端上的自動化測試。3）性能壓測和分析能力是標配。業務的發展、技術架構的演進都需要測試工程師具備性能壓測和性能分析的能力，特別是在複雜業務複雜架構下，利用性能壓測工具或專業領域開發性能壓測工具進行性能壓測和性能分析。能做到這些背後的支撐就是開發技術和系統架構的理解。4）bug分析能力大幅提升。大家都知道測試的核心職責是發現bug，確認bug；定位bug和分析bug原因、甚至給出bug解決方案都是開發的活。道理是這麼個道理，但是如果測試工程師想在技術上有更多積累，想發揮更大的價值，想多發現更多隱藏的bug，強烈建議多做定位bug和分析bug原因、給bug解決方案。筆者在看2022 GBA bug時候，發現很多bug發現者在定位bug和分析bug原因、給bug解決方案都做到了非常多，很多技術細節都清楚，甚是驚訝。5）測試左移效果會更加明顯。測試左移和測試右移都不是什麼新鮮的話題了，很多公司都在實踐這兩塊內容，但是在實踐過程中能踏踏實實的做的，做的效果好的，得到了產品和開發的認可的，真的不多。從2022 GBA 可以看出阿里螞蟻測試工程師在技術方案評審和分析中發現了很多風險和問題點，且通過自己的技術能力證明自己的猜測，做到這些真的是不容易的，也相信阿里螞蟻的很多測試工程師都具備這樣的能力和case。總體來說，測試技術發展是驅動質量保障體系發展的重要因素，這裏面還有質量門禁體系、全流程質量保障、各種服務化工具和智能化工具。後記最近幾年大環境不好，各個業務單元都在走經營責任制，測試部門相應的拆分到業務研發團隊，測試團隊相對於開發團隊來說就是徹徹底底的成本部門，是優化成本的第一優先級，所以測試工程師的前途和發展前景都堪憂，在這種大背景下，測試工程師在業務測試的打磨上，會更加聚焦業務價值本身、產品用戶體驗本身（業務競對分析、體驗優化、長尾問題挖掘）、產品質量本身、測試執行效率本身。而這些工作讓測試工程師找到自己的核心價值，找到自己的生存之本，找到自己的測試初心，找到自己的未來方向。熟悉我的人都知道我最近兩年離開了測試領域，在SRE領域學習和成長了較多，但是我還是不斷的關注測試業界的動態，阿里螞蟻的測試發展，測試同仁的困惑和發展，我很多時候都在想我是不是就不能離開測試領域（向國外一樣，做20/30年的軟件測試專家），我是真的太愛軟件測試了，對於任何軟件測試的理論和實踐我都熱衷於學習，我感覺我快回來了，回來繼續思考軟件測試如何更好的做，如何更好更快的建立自己的質量保障體系和質量策略，但道阻且長，請珍惜眼前。