构建测试的体系化思维（进阶篇）
讀完需要
24
分鐘速讀僅需 8 分鐘
? ?
00 引言
1. 三個層次聊測試體系
測試人員缺乏體系化思維？新建產品團隊或者新啟項目，如何搭建質量保障體系？
大家都接觸過不計其數的測試、質量方面的文章或者培訓課程，內容不乏測試實踐、技術相關，但是卻很難構建自己的測試體系?；诤芏嗯笥杨愃频睦Щ?#xff0c;結合本人多年的團隊實踐和咨詢經驗，從基礎、進階和高級三個不同的層次來跟大家探討測試體系化思維的構建。
《構建測試的體系化思維（基礎篇）》
《構建測試的體系化思維（進階篇）》（本文）
《構建測試的體系化思維（高級篇）》（待發布）
2. 基礎篇內容回顧
2022 年 1 月份發布了《構建測試的體系化思維（基礎篇）》（后文簡稱《基礎篇》），從測試的五個基本職責出發，圍繞這五個基本職責介紹了相應的實踐活動和方法集。
理解和澄清業務需求
制定策略并設計測試
實現和執行測試
缺陷管理與分析
質量反饋與風險識別
3. 進階篇內容概要
本文為進階篇，將跳出測試，從軟件質量的角度來看體系化思維的構建。
1）從測試到質量：跳出測試，從質量維度來看測試的體系化建設。
2）質量保障與質量內建：質量是產品與生俱來的，質量內建才是保障質量的根本。
3）質量內建深入實踐：質量內建如何落地是大家最為關注的問題，深入質量內建實踐介紹，供大家落地實踐參考。
? ?
01 從測試到質量
1. 為什么要從測試轉變到質量
在《基礎篇》中提到的五個測試基本職責，那是測試人員開展測試工作務必了解的方方面面，是做好測試工作的基礎。
但是，要做好軟件產品的質量保障工作，光從做好測試的角度考慮是遠遠不夠的，原因主要有兩個方面：
軟件質量不能通過測試來提高。著名質量管理專家戴明提到：“質量沒法檢測出來，軟件產品開發出來后質量就已經在那了。”
軟件測試可以驗證軟件質量是否滿足需求，但是隨著軟件生態的復雜性和不確定性增加，沒有辦法預知軟件行為，也就沒法通過測試來驗證軟件質量的方方面面。
因此，測試是基本功，但只關注測試是不夠的。需要跳出測試，將視野調整到軟件開發全生命周期質量的角度，關注質量的各個維度，才能更好地建立體系化思維，才能更好地做好軟件產品的質量保障工作。
在閱讀后面內容之前，我希望讀者朋友們先花 10 秒鐘思考以下問題：
問題：跳出測試，從軟件質量的角度思考，我們需要關注哪些方面？
這是一個老生常談的問題，答案似乎大家也都很清楚，但現實中又是很容易被忽視、被誤解的問題。
2. 軟件質量的定義
在回答上面問題之前，我們先來看看維基百科對軟件質量的定義 ( https://en.wikipedia.org/wiki/Software_quality )。如下圖所示：
維基百科對軟件質量的定義包括兩個方面：
軟件功能質量：基于功能需求規范看軟件是否提供了相應的功能，這是用戶使用軟件的角度，是軟件外部的質量。
軟件結構質量：對支持功能需求交付的非功能需求的滿足情況，比如健壯性、可維護性等，這是從軟件內部結構來看，是軟件內部的質量。
維基百科的這個定義跟咱平常提到的軟件質量包含外部質量和內部質量是一致的。外部質量是從軟件外部可感知的，是從用戶角度對軟件感知到的使用質量；內部質量則涉及到軟件的內部形態，包括技術架構和代碼質量等，是從團隊開發人員的角度感知到的。
相信大家對于外部質量好理解，是用戶角度能夠感知到的質量。而內部質量往往很容易被忽視，其實這也是因為人們普遍容易追求短期利益，看不到內部質量給軟件產品帶來的長遠影響，這里想給大家看個非常熟悉的圖，以增強對內部質量的重視。
不加整理的富含技術債的代碼，就如同圖中雜亂無章纏繞在一起的電線，嚴重影響著產品缺陷定位修復、后期功能擴展等。
3. 容易忽視的質量影響因素
理解了質量的定義，在日常軟件開發工作中有哪些因素是會影響到軟件質量的呢？其實，影響的因素特別的多，可能包括但不限于以下這些：
1）需求分析過程倉促，或者參與人員角色比較單一，導致業務上下文了解不夠，關鍵場景缺乏考慮等；
2）忙于交付更多的特性，忽略了對代碼質量的關注，該重構的沒有重構，在原本不太健康的代碼基礎上繼續增加更多的代碼，導致混亂，筑起高高的技術債；
3）沒有足夠的測試覆蓋，導致新增代碼容易破壞已有功能；
4）開發人員提交代碼后，就投入新代碼的開發，對所提交代碼缺乏關注，持續集成流水線上測試掛了不能及時修復，可能影響后面的測試進度；
5）大面積的重構發生在發布前夕，無法全面回歸，帶來很大的風險；
6）項目初期只考慮少量用戶的場景，隨著業務的發展，系統功能難以擴展，導致嚴重性能瓶頸；
7）技術選型失誤，開發困難，沒有及時改進，一錯再錯，最后問題嚴重到無法彌補；
8）第三方組件評估不夠充分，導致線上環境無法承載等；
9）開發缺少對異常情況的處理，測試過程缺乏探索，只覆蓋到主干路徑，邊角用例可能引發問題；
10）開發或者測試都只考慮當前功能模塊，缺乏更廣范圍的考慮；
11）缺乏跨功能需求的關注，導致嚴重的安全或者性能問題；
12）對線上環境了解不夠，而且沒有足夠日志信息記錄，線上問題難以定位，導致宕機時間過長；
13）等更多……
? ?
02 質量保障與質量內建
1. 質量如何保障
從質量維度來看體系化思維的構建，而質量是產品與生俱來的，做好軟件產品的質量保障工作更為有效的方式就是要將質量構建到軟件產品本身，提高軟件產品與生俱來的質量。這也就是質量內建（Build Quality In）的概念。
這個還是太抽象，為了更清楚的解釋質量內建，先來看兩個概念：暴露缺陷與預防缺陷。
2. 暴露缺陷與預防缺陷
“暴露缺陷”的概念眾所周知，就是軟件所暴露出來的缺陷，通常在測試或使用過程中被發現。
如果能夠全面統計一個軟件產品的所有可能引起缺陷的地方，我們可以說該軟件存在缺陷的總量是一定的。當然，現實情況是我們不可能全面考慮到所有的因素，缺陷是很難窮盡的。
如果這一定數量的缺陷中有一部分可以通過某些措施來預防，那么軟件在測試或最終用戶使用過程中所暴露出來的缺陷數量就會減少，這就是缺陷預防——減少暴露給用戶的缺陷。
軟件開發過程是個持續遞增的過程，預防缺陷也不是一蹴而就的事情，需要在整個軟件開發過程持續的進行。當然，盡早預防缺陷會更好，這樣可以顯著減少缺陷修復的成本，提高投入產出比。下圖曲線非常清晰地展示了修復不同階段暴露出來的缺陷所需成本的差異，修復成本是隨著軟件開發周期顯著增加的。
3. 質量內建如何做
將缺陷概念擴展為軟件產品質量相關的所有問題，那么做好了缺陷預防也就是做到了質量內建。
前文提到過容易被忽視的質量影響因素，要做好質量內建這些因素都是需要重點關注的。
但是，由于軟件開發過程的復雜性，要一次性做對所有事情、預防所有的缺陷是不可能的。因此，質量內建并不是嚴格意義上的不能有任何缺陷暴露，而是需要在軟件開發生命周期中盡早地把事情做對，并且通過持續的獲取快速的反饋來糾偏。
我們都知道那個有名的 PDCA 環（也稱“戴明環”）：
將質量管理分為四個階段，即 Plan(計劃)、Do(執行)、Check(檢查) 和 Act(處理)。在質量管理活動中，要求把各項工作按照作出計劃、計劃實施、檢查實施效果，然后將成功的納入標準，不成功的留待下一循環去解決。
質量內建可以理解為在軟件開發全生命周期中，從需求到線上頻繁地執行 PDCA 環，小步前進，持續反饋驗證，及時調整改進。如下圖所示：
? ?
03 質量內建深入實踐
前面主要從概念和理念層面介紹了質量和質量內建，這些內容對構建體系化思維是至關重要的，有助于拓寬視野，形成全局觀。但光有這些內容不夠，還得了解具體的落地實施方法。接下來就從質量內建相關實踐來探討質量內建在軟件開發生命周期的落地實施方案。
1. 質量內建的核心
在介紹具體的質量內建實踐之前，還是需要從抽象層面來理解質量內建的核心，其內容可以分為四個方面：
測試左移
快速反饋
測試右移
全員參與
1.1 測試左移
傳統軟件開發會分成分析、設計、開發、測試、發布等幾個相對獨立的階段，而測試是其中發生在開發完成之后的一個階段。
測試左移是針對傳統這種獨立測試階段來說的，不再強調獨立的測試階段，而是要將測試活動左移到軟件開發生命周期的最早階段（最左邊）——需求階段，從需求階段開始做好缺陷預防的工作。
要特別提醒注意的是，測試左移不是測試人員左移，而是強調的測試活動左移：
左移到傳統獨立測試階段左側就叫左移，不一定是左移到需求階段。當然，根據前面對質量內建的闡述，理想情況下肯定是越左邊越好。如果做不到徹底左移，能移一步也是進步。
測試人員的確需要左移參與相應的活動。但是，如果測試人員參與需求階段，卻沒有起到澄清需求、驗證需求有效性的作用，那就不是有效的測試左移，關鍵要看成效。
不僅測試人員要左移，開發等其他角色也需要左移。因為需求有效性的驗證，需要不同角色的經驗，需要來自不同視角的輸入；不同角色都有責任參與到每個環節的測試活動中來。
只要能做到從需求階段開始就有相應的測試活動，不一定都是測試人員參與。這里強調的是測試活動要有，哪個角色來做不是最關鍵的，角色其實就是戴了一定帽子而已。我們知道，有的團隊是沒有測試人員的，但不代表這些團隊沒有測試活動。
1.2 快速反饋
快速反饋，也就是頻繁持續地反饋，可以理解為一個持續測試的過程。
通?？焖俜答佇枰凶詣踊闹?#xff0c;比如自動化測試、流水線上自動代碼掃描等；也可以是一些人工參與的實踐環節，比如手動測試、各類評審和驗收等。通過這樣的一些實踐活動盡快地獲取相應工作（可能是需求分析、開發等）的反饋，根據反饋結果進行及時的修復、調整、或者優化。
為了保障快速反饋/持續測試實踐活動的有效開展，通常需要增加質量門禁，并確保質量門禁的嚴格執行。
1.3 測試右移
測試右移是跟測試左移對應的，就是將測試活動從獨立測試階段右移到生產環境。
但因為生產環境的特殊性，測試右移又不是測試活動的簡單右移，而是通過一些實踐活動獲取生產環境下用戶行為、日志等質量相關信息，利用這些信息來給前期的需求、開發和測試工作提供反饋，促進相應工作的優化改進，以更好的做好質量內建。
測試右移本身不能直接內建質量，但是可以幫助更好地質量內建，所以我認為測試右移也是質量內建不可或缺的核心內容之一。
這部分的內容比較多，之前有過詳細的介紹，此處不再贅述。歡迎參考文章《測試右移——生產環境下的 QA》閱讀更為詳細的內容。
1.4 全員參與
測試左移、快速反饋和測試右移都不是某個單一角色/人員可以做到的，需要不同角色的不同技能和不同視角的輸入，質量人人有責，需要全員參與并且能承擔起質量職責才行。
全員參與不僅是很多實踐活動需要大家一起參與，還有很重要的一點是團隊內部需要有足夠的溝通和信息共享。只有信息足夠透明，每個人都清楚質量目標、質量狀態和風險，才能真正發揮主人翁精神積極地參與，才能發揮團隊每個人最大的價值。一定要警惕團隊“蘑菇種植”。
這部分內容之前也有過非常多的分享，歡迎參考：《團隊對質量負責，“我”可以不負責？》、《敏捷測試的指導性原則》、《說好的團隊為質量負責呢？》等文章。
2. 質量內建典型實踐
綜合來看，質量內建的典型實踐通常有（但不限于）下圖這些：
不管是傳統開發模式還是敏捷迭代式開發模式，軟件開發生命周期都會有需求分析、開發實現和線上使用三個階段，只是敏捷模式下需求和開發是迭代式進行，在時間上不是界限清晰的階段。
這里為了描述方便，暫且將這些實踐分成三個階段來描述，事實上實踐活動跟階段也不是關聯非常緊密的，遵循測試左移、快速反饋、測試右移和全員參與這幾個核心思想才是關鍵所在。
2.1 需求分析
這里強調四個我認為跟需求分析密切相關的典型質量內建實踐，分別是需求澄清、行為驅動開發（BDD）、實例化需求（SbE）和需求評審。
需求澄清：需求的理解和澄清作為測試基本職責之一，在《基礎篇》中有較為詳細的介紹，請移步參考。不過，在這里需要補充的是不僅測試要參與需求澄清，還需要其他相應的角色協同參與，比如開發人員、技術負責人、技術架構師等。
行為驅動開發（BDD）：關于 BDD，很多人誤認為是一種測試方法，但其實 BDD 主要是為了三方更好地對需求達成一致認識，只不過通過 BDD 方式產生的需求能夠很好地指導自動化測試的開展。更多詳情，請參考我之前的文章《說起 BDD，你會想到什么？》。
實例化需求（SbE）：SbE 的核心思想跟 BDD 類似，但強調了一點要將需求描述通過實例來說明，以更好地發現漏掉的需求，讓需求更完整、更容易被多方理解和澄清。
需求評審：需要開發和測試跟業務分析人員一起討論確認需求，可能是正式的會議針對某個特性（大塊需求）的評審，也可以是針對單個需求條目或敏捷用戶故事進行線下評審。如果前期需求澄清過程中對需求的討論已經比較透徹，這里的評審就會比較輕量級，由測試人員（開發按需參與）自行安排時間評審即可。
這些實踐都是為了更好地在需求分析階段讓團隊對需求達成一致的理解，確保需求的質量，減少后期因需求問題帶來的返工和浪費。
2.2 開發實現
需求源頭的質量控制好了，接下來就是在開發實現階段持續地通過快速反饋的方式確保每一步工作的質量，下面的實踐都是為此服務的：
技術方案討論：不是要介紹這個實踐怎么做，而是要提醒在做技術方案討論的時候測試要盡量參與。一方面，測試清楚了解技術方案，才能更好地設計相應的測試策略，更完備的進行測試；另一方面，測試基于自己對系統的了解，可以給技術方案的討論提供輸入，比如系統重點需要考慮和關注的問題等?？赡苡腥藭X得測試技術水平跟不上，參與價值不大，但我想說的是不參與就不會有進步，只要參與了就一定會有收獲，從長期來看，不管是對個人還是對團隊整體都是非常有價值的。
需求條目啟動：也叫用戶故事啟動（Story kickoff）、開卡等。對于單個可開發需求，在開發人員要開始編碼前進行的再次澄清和確認，主要是確認其中的驗收標準是否不夠完備、是否大家都理解一致了。形式要求盡量輕量級，在開發人員電腦前完成即可，需要業務分析、開發和測試共同參與，時間一般不要超過 15 分鐘。
需求條目驗收：跟啟動是配對的，也叫用戶故事驗收（Desk check/Shoulder check/Story signoff）、結卡/驗卡等。同樣在開發機器前面完成，一般由開發將功能演示給業務分析和測試人員，大家確認需求中的正向路徑是否都已經開發實現了。更多詳情可參考文章《高效用戶故事驗收》。
測試用例設計：在《基礎篇》有對測試用例設計作詳細的介紹，從質量內建的角度來看主要是想說測試用例設計盡量早點做，而且對于用例設計的形式可以相對靈活些，列舉需要關注的測試點才是關鍵，從快速反饋的角度，不建議過于注重形式和流程。
測試驅動開發：TDD，常見的有單元測試驅動開發（UTDD）和驗收測試驅動開發（ATDD），通過先寫測試的方式驅動設計的完備性。Thoughtworks 同事劉冉老師有多篇關于 TDD 的文章，請移步他的網站「劉冉的思辨悟 ( http://liuranthinking.com )」查閱參考。
代碼評審：Code review，也叫代碼回顧。有團隊成員聚集在一起做回顧的，也有獨立線下評審的模式。Thoughtworks 同事伍斌道長的文章《Code Review: 超越“審、查、評”的代碼回顧》有關于 code review 非常詳細的講解，請移步參考。
自動化回歸測試：根據測試分層理論，自動化測試可能包括單元測試、接口集成測試和端到端測試。通常單元測試是開發人員編寫，而接口集成測試和端到端集成測試可以開發和測試協作完成。關于自動化測試相關文章比比皆是，這里推薦如下內容供參考：
《精益測試》
《微服務測試的思考與實踐》
《測試金字塔不是銀彈》
《一個遺留系統自動化測試的七年之癢》
Thoughtworks 洞見自動化測試文集 ( https://insights.thoughtworks.cn/?s=%25E8%2587%25AA%25E5%258A%25A8%25E5%258C%2596%25E6%25B5%258B%25E8%25AF%2595 )
劉冉老師網站的自動化測試文集 ( http://liuranthinking.com/automatedtesting/ )
單元測試評審：單元測試評審一般發生在需求條目驗收環節，詳情參考文章《QA 評審底層測試的價值》。
持續集成：持續集成（CI）概念大家并不陌生，但是有效實施卻不是那么容易。常見的反例有：
光有持續集成流水線，但是流水線上啥也沒有，沒有代碼掃描、沒有自動化測試、沒有質量門禁；
流水線有接入代碼掃描，但是掃描出問題沒有及時修復；
自動化測試沒有在流水線上頻繁執行，或者執行失敗不能及時修復；
代碼沒有頻繁提交；
……
更多內容，推薦參考 Thoughtworks 洞見文章《持續集成理論和實踐的新進展》和《對于持續集成實踐的常見問題的解答》。
自動化/持續部署：自動化部署在提高效率的同時還可以減少手工部署引入的問題，讓部署能夠更頻繁更持續地發生。這部分內容可以參考 Thoughtworks 洞見文章《持續集成和交付流水線的反模式》。
技術債管理：還記得前面那個布滿雜亂無章電線的圖嗎？軟件開發過程中引入的技術債如果沒有得到有效管理，軟件內部也會亂成那個樣子。關于技術債管理，推薦 Thoughtworks 同事麻廣廣的文章《軟件架構治理之技術債的前世今生》。
探索式測試：探索式測試有助于發現一些潛在的不易察覺的缺陷，是非常推薦的一個實踐。具體做法和建議在《基礎篇》中對探索式測試有詳細介紹。
客戶驗收：英文叫 Showcase，就是給客戶、業務方演示開發實現的特性。Showcase 也有很多常見誤區，請移步文章《敏捷實踐 Showcase 的七宗罪》。
缺陷分析：缺陷分析對質量內建的幫助主要是通過分析找出問題根因，在后續的開發工作中提前避免以預防更多的缺陷暴露。如何做好缺陷管理和分析？請參考下列文章：
《軟件缺陷的有效管理》
《缺陷分析如何幫助質量內建》
《都是臟數據惹的禍》
質量狀態報告和質量風險分析：請參考《基礎篇》中“測試職責之五：質量反饋與風險識別”部分的介紹。
回顧會議：回顧會議通過總結和分析過去一段時間團隊發生的事情，是關于團隊整體健康狀態的。我之所以將回顧會議列為質量內建的典型實踐，是因為咱們前面討論過了影響質量的因素涉及到方方面面，自然就跟團隊的健康有著很大的關系。利用好回顧會議這個實踐，及時發現問題并采取對應的改進舉措，將是非常有價值的。關于回顧會議的高效開展，可以參考 Thoughtworks 洞見文章《高效回顧會議的七步議程》。
2.3 線上使用
軟件產品發布到線上，質量內建相關實踐就都是跟測試右移有關的，這是一個很大的主題，之前有過系列文章的介紹，相關實踐可以參考下列文章：
《測試右移——生產環境下的 QA》
《測試右移之日志收集與監控》
《測試右移：QA 與 Ops 通力合作打造反脆弱的軟件系統》
? ?
04 寫在最后
測試基本職責是測試人員必備之基礎技能，但測試的體系化思維構建不能僅局限于測試工作本身，當我們跳出測試，從質量的角度來看，又是另一番景象。
希望本《進階篇》能夠幫助各位測試同仁從質量的角度拓寬視野，增加大局觀，讓質量保障工作做得更順暢。
總結
以上是生活随笔為你收集整理的构建测试的体系化思维（进阶篇）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【Jmeter篇】jmeter+Ant+
- 下一篇： python queue队列