這是鼎叔的第九十一篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本專欄和微信公眾號《敏捷測試轉型》，星標收藏，大量原創思考文章陸續推出。本人新書《無測試組織 - 測試團隊的敏捷轉型》已出版（機械工業出版社）。
眾所周知，測試活動越早進行，在早期發現缺陷的數量就越多，而且單個缺陷的修復成本也會越低。如果缺陷在接近釋出前被發現，修復的總成本要提高一個數量級，如果缺陷上線後才被發現，帶來的損失價值可能再高一個數量級，達到令人吃驚的程度。
根據 Capers Jones 在《全球軟體生產力和質量度量分析報告》中給出的圖表資料，假設在編碼過程中修復一個缺陷的成本是 1，那麼在單元測試中修復一個缺陷成本是 4，而功能測試和系統測試的單個缺陷修復成本分別是 10 和 40。如果遺漏到線上，修復成本飆漲到 640！
通常在開發階段，開發人員做的事情是開發設計文件，編碼，CR（程式碼評審）和開發自測等工作。與此同時，測試人員的常規活動是準備測試策略，測試用例設計，用例評審和自動化測試相關準備，等等。
本文提到的測試左移，是指測試人員除了要學習開發人員提供的設計技術文件（用作測試設計的參考）以外，還可以積極參與開發相關的如下重要活動，更早地暴露問題，減輕而非加重開發人員的負擔。
1）參與開發設計評審。
2）推動測試驅動開發（Test Driven Design，TDD），落實單元測試門禁。
3）程式碼評審活動。
4）程式碼規範落實。
5）桌面評審（Showcase），即完成驗收測試。
6）共建每日持續測試，完善測試分層建設。
測試人員的目的從發現缺陷變成了預防缺陷，這會導致與開發人員協作關係的重大變化。
參與開發設計評審
在傳統研發團隊，軟體的開發設計包含概要設計和詳細設計，測試人員並不被鼓勵參加開發設計評審。實際上這個評審活動有利於測試人員獲得重要的業務架構、功能和非功能的實現資訊，對於測試策略和用例設計可能會大有啟發，也會為精準測試提供關鍵資訊。
測試人員參與開發設計評審，優先關注軟體的整體架構、分層模組、底層模組的檢視，鼓勵追問設計方案的選型原因、資源限制場景、可靠性保障機制、安全處理機制等背後的技術知識，藉此埋下 “如何基於設計風險做測試設計” 的種子，降低測試探測的盲目性。開發在設計討論中的爭論，也許提示了潛在的高風險資訊。
從參與設計評審開始，測試和開發也就能在對等資訊的基礎上進行質量問題的本質探討。
行業中有一種觀點，認為如何測試人員過於熟悉開發的實現思路，就會站在理解開發的角度來測試，不會想盡辦法找到破壞路徑。我不這麼認為，只要刻意訓練，測試人員可以充分利用白盒資訊和黑盒觀察的各自優勢，可以快速切換成不同的測試角色（開發者或普通使用者）來高效地挖掘問題。
TDD 與單元測試門禁
TDD 常見的型別有兩種，UTDD（Unit Test Driven Design，單元測試驅動開發) 和 ATDD（Acceptance Test Driven Design，驗收測試驅動開發），兩者的差異如下。
UTDD 是測試用例在先，編碼在後的開發實踐方式，屬於單元測試的層次。開發人員透過不斷讓單元測試透過，提升對程式碼的信心，再持續最佳化和重構程式碼，保持用例透過，這樣可以儘可能降低重構的風險，讓開發人員可以更放心的進行快速重構，提高迭代效率。UTDD 彌合了開發實現和單元測試的分界線，將傳統開發過程倒轉過來，藉助測試程式碼增量地驅動設計。
ATDD 則是在業務層面的實踐，基於前面介紹的驗收測試用例，驅動開發面向客戶需求進行場景設計和程式碼實現。
相關文章：聊聊測試驅動開發 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484254&idx=1&sn=f48dd00832d9fb7da108f4ceeb63942b&scene=21#wechat_redirect
專職的測試人員直接介入到 UTDD 活動是比較困難的，但這不意味著測試人員不能推動 UTDD 的優秀實踐。我們可以藉助持續整合流水線，以及團隊對於單元測試質量的重視，把單元測試門禁作為持續提升程式碼質量的基礎，透過門禁才能進入下一輪研發活動，從編碼源頭內建好質量。具體行動步驟推薦如下。
1）在團隊中普及 UTDD 知識和實踐方法，讓大家理解並遵守單元測試編寫的基本原則：
單元測試要求全自動化執行，速度要足夠快（毫秒級）。
單元測試要獨立。用例不依賴外部資源（如外部資料，介面和網路等），用例之間也不互相依賴。
單元測試可重複測試，穩定性極高。
單元測試集要保障較高的覆蓋率。及時更新用例以覆蓋最新程式碼。
2）基於團隊評估討論，可以設定單元測試透過的標準，如執行耗時上限，測試集透過率，程式碼覆蓋率等。
3）在研發測試流程平臺（或 DevOps 平臺）上，接入對應程式語言的單元測試框架，將單元測試關鍵指標顯示到實時質量看板上。
4）針對未達標的單元測試，檢視詳細報告並進行最佳化。常見的質量問題有：耗時太長，增量覆蓋率或全量覆蓋率太低，缺失正確完整的斷言檢查等。整改未達標的單元測試，不能進入下一步的提測環節。
切記，單元測試覆蓋的目標是所有重要的程式碼路徑被覆蓋，但不是和具體實現程式碼過於緊密的耦合，避免內部程式碼一旦改變，單元測試就失敗。
此外，不要為了提升被測程式碼覆蓋率而忽略了重要的斷言檢查，包括對返回值的斷言、對方法引數的檢查、對異常值的檢查等。高質量的斷言檢查才能讓單元測試成為出色的質量防護網，不懼程式碼的頻繁更新。
程式碼評審活動
程式碼評審（Code Review，以下簡稱 CR）通常是由開發人員互相進行的。測試人員參與 CR，也能獲得不小的收益，不僅能學習到開發人員實現軟體的具體邏輯，也能快速尋找程式碼質量風險，儘快攔截問題。
長期參與 CR，有利於工程師的快速成長，更有利於團隊工程能力的協同。擁有良好 CR 文化的技術團隊，就擁有儘早識別缺陷的能力，擁有自覺完善程式碼的主動心態。
為了保障 CR 的順利和高效進行，整個團隊也需要樹立評審原則，包括：
1）確保每次 CR 只做一件事，即單一職責原則。重點放在業務邏輯檢查，看實現方案是否充分。
2）儘早評審，多次評審。而不是快釋出才集中評審。
3）評審前先借助掃描工具查漏補缺，而不是單純依靠人工檢查基礎錯誤。
4）為評審者提供詳細資訊。
5）對評審人員的行為要求：及時響應，謙虛，不追求程式碼完美，指明必須解決項，多多鼓勵，等等。
測試人員參與開發者 CR，可以特別關注軟體的設計意圖，可測性，以及在效能、安全、穩定性等方面的設計缺失，並思考可以進行缺陷探索的場景。當然，測試人員如果是業務整體架構和業務設計邏輯的精通者，更能在 CR 中看到具體函式沒有考慮到的上下游整合風險。
為了提高找風險的效率，測試人員基於現有缺陷特徵分析，評審效率可能更高。我們既可以從當前主要缺陷的根因分類來提煉 CR 的觀察角度，也可以藉助靜態程式碼掃描工具的支援，批次化發現問題。舉例如下。
1）App 崩潰問題很多是因為空指標異常，那測試做 CR 就會特別關注物件的初始化，任何一個物件在使用前都要做判空處理。
2）不少缺陷的上報都是因為邊界問題，做 CR 時會重點評審陣列和列表的邊界，判斷是否有越界情況。同時，對於各種不正常的輸入，判斷程式碼是否做了完備性檢查，並給予合理的異常提示。
3）應用的記憶體洩漏作為測試重點項，我們會分析出常見的記憶體洩漏原因，及其程式碼實現中的錯誤表現。按這些反例提煉評審關注點，比如物件如果註冊了實踐回撥，是否在合理的地方進行了反註冊；快取物件、圖片資源、各種網路連線、檔案 IO 等，最終是否正確關閉，諸如此類。
4）專業的靜態程式碼掃描工具也可以提供典型程式碼問題的分類定義和推薦解決方法，結合起來學習效果更佳。
最後，為了讓程式碼評審流程規範化和更高效，也可以在研發管理平臺上即時發起線上評審，確保多人的評審結論滿足基本門檻後，平臺才允許把程式碼提交入主幹。
程式碼規範落實
不少大公司會制定程式碼規範（Coding Standard），包括質量層面、風格層面和安全層面。測試人員針對程式碼規範往往可以做一些較高收益的嘗試：協助制定適宜的程式碼規範，並積極推動激勵制度落地，形成開發習慣，等於用很低的成本把不少潛在風險攔截在初期開發階段，價效比高於強推開發單元測試。
圍繞程式碼規範的推動，質量人員可以做三類動作：
一，推動程式碼規範的文件化和宣導。大公司的程式碼規範文件往往很容易獲取，但是細則繁多，對開發的嚴謹習慣提出了較高的要求，測試可以根據團隊專業成熟度，以及常見缺陷風險，選取其中的子集作為本團隊的規範，在執行成本和風險攔截中取得平衡。
二，把規範檢查納入到流程管控或者工具審計中。與開發達成程式碼規範卡點的紀律，在日常程式碼自動掃描中要明確告警規則，確保開發負責人即時響應處理，不允許隨便取消告警規則。
同時，在引入靜態程式碼檢查工具階段，測試人員也會參與貨比三家，務必在價格、質量/安全風險檢出率、誤報率、修復提示水平，售後技術指導等多個要素上推薦出更佳的開源或商業工具。如圖是我們在 2017 年針對程式碼掃描工具選型的評測結果。
圖 SonarQube 和 Pinpoint（源傘）掃描工具效果評測
三 作為中立方輸出程式碼規範專項審查報告。程式碼規範的分類多樣，我的經驗是可以細分為排版規範、註釋規範、命名規範和編碼規範四類，規約強度可以是 “建議” 或者 “原則”。測試可以藉助掃描工具和人工核查，針對特定一類違規現象做審計，輸出分析改進專題，這種聚焦曝光和集中改進的效果往往讓人印象深刻。泛泛而談的審計報告則很容易失去可持續的抓手。
比如我曾帶團隊陸續輸出的幾期專題報告：APP 程式碼掃描專項，程式碼註釋規範專題，冗餘程式碼專題，圈複雜度分析專題等等，充分利用多種掃描工具，配合人工核實問題有效性，聚焦清理一類問題，因此開發解決的速度會很快，讓團隊也很有成就感。
桌面檢查（驗收 Showcase）
當開發完成編碼和除錯，如果馬上部署測試環境開始進行端到端的驗收，那麼就進入高成本的測試活動。當測試發現了可能的缺陷，尋找開發人員進行確認時，開發人員可能已經在開發另一個需求了，必然產生更多工切換和溝通的成本。
如果開發完成編碼除錯後，進入桌面評審（Deskcheck）活動，比要求開發人員承諾 “自測” 的方式更有利於提升開發質量。有些公司也稱之為 Showcase。只需要在開發的本地環境驗證（測試資料由開發自行準備），組織特性團隊和干係人的集體會議，由技術人員進行功能演示。通常在演示中會執行驗收測試用例。如果驗收測試用例不透過，則可以打回開發進行修復，未來再安排新的一輪 Showcase。如果驗收測試沒有發現嚴重問題，可以進入系統測試階段。
這個質量評審活動體現了敏捷宣言的核心實踐，個體的互動及合作，比固定流程更重要。
基於本人的實際感受，因為 Showcase 形式公開直接，開發人員會進行充分的測試準備和確認。參與 Showcase 的人員如果原本不太熟悉業務細節，透過參與驗收展示的全流程，會對於業務互動邏輯有非常深入的理解。
最後關於持續測試，將來再重點講解。