測試架構師修煉之道：從測試工程師到測試架構師（第2版）

本書從測試工程師的行業現狀出發、解答了測試工程師遇到的職業瓶頸，同時在做好測試工程師的基礎上，向測試架構師邁進，掌握測試架構師的核心技能。 比較深刻的幾個總結： 1、敏捷開發模式下測試的可行範圍更廣：迄今的開發模式有三種：瀑布、敏捷、DevOps, 在當前比較流行的敏捷模式下，測試可以直接參與產品規劃；與用戶交流，收集需求；可以像開發人員一樣去編碼；可以使用工具做自動化；可以使用流程做質量改進；產品的職責發生變化，從質量守護到產品賦能：場景測試、性能測試、探索式測試、更有效的測試策略等使 測試具有系統和全局視角。 2、職業規劃上分爲管理上和技術上：管理上--基層測試組長（負責安排小組工作、承擔小組中最重要種負責的測試工作）、測試經理（對測試的全流程負責，需要和不同角色進行溝通協作完成產品目標，解決團隊測試中遇到的困難、難題，不斷提升團隊測試能力）、測試總監（負責一條或多條產品線、不在需要從事測試工作，但要關注測試新技術）；技術上--測試架構師（對不同組織、產品、研發模式做出適合當前狀況的選擇）、測試技術專家（測試分析設計專家、測試流程專家等）、測試開發人員（自動化測試架構的測試開發工程師、效能工具鏈測試開發）。 3、測試架構師必備的6個關鍵能力：明確測試目標、測試重點的能力；明確測試目標、測試重點的能力；測試分析、設計和執行能力（包括工具和自動化）；有效溝通的能力；持續學習和探索的能力。 4、軟件產品質量模型：8個屬性（功能性、兼容性、安全性、可靠性、易用性、效率、可維護性和可移植性），如何運用8個屬性進行具體的測試工作 5、如何制定測試策略：明確產品質量目標（完全商用、受限商用、受限試用、不能使用）、產品特性價值分類（無人問津的特性、核心特性、輔助特性、噱頭特性、潛力特性）、風險分析（確定測試重點和優先級）、適配產品開發流程（開發過程中關鍵節點和運作方式）、測試分層（將有共同測試目標的測試活動放在一起）。常見分析模型--產品覆蓋度分析、測試過程分析、缺陷分析等：需求覆蓋度評估、代碼覆蓋度評估；質量評估分析、測試用例執行情況分析、測試方法分析；缺陷密度分析、缺陷修復情況分析、缺陷趨勢分析、缺陷年齡分析、缺陷觸發因素分析。 本書雖然是在說測試工程師，但是對我這個開發工程師，是一樣適用的，在開發的路上遇到的迷茫都得到了解答，同時也對日常工作中對測試工程師的做法不認同的點有憑證能夠反駁，後面幾章更多的是理論上的介紹，要是能夠有更多案例之城，我可能會理解的更透徹一些。總而言之，很慶幸能夠看了這本書，雖然短斷斷續續的閱讀，但是也終於是讀完了，前進之步伐雖小，但只要走總能走到盡頭，值得我反覆去閱讀、去理解。

本書理論很強，體系健全，邏輯自洽，覆蓋廣泛，長期從事測試工作的人才能深切體會書中描述的情形。不謀全局者，不足以謀一域。不謀萬世者，不足以謀一時。測試工作不是爲了找缺陷而找缺陷，是爲了商業目的和產品價值，從全局角度系統層面進行統籌安排，按照特定時期的目標進行最大限度的軟件質量保障。 從產品立項，明確需求，特性分析，風險評估，測試策略，測試設計，溝通協調，再到資源分配，人工和自動化組合測試方法，按時交付，均有詳細闡述。 沒有任何一位測試人員能窮盡所有的情況，掌握測試技術，拓展測試視野，做出最適當的測試選擇，纔是測試人員的核心能力所在。認清現實，不斷探索，在有限的條件下追求效益最大化。測試架構師必備的6個關鍵能力： 1.明確測試目標、測試重點的能力； 2.敏銳的風險識別和有效的風險應對能力； 3.測試分析、設計和執行能力（包括工具和自動化）； 4.質量分析和評估能力； 5.有效溝通的能力； 6.持續學習和探索的能力。

推薦作爲測試手冊參考，結合《Google軟件測試之道》閱讀。書中不僅講測試的職業規劃，也提到了國外測試專家、軟件開發專家的測試理念和觀點，包括自動化測試的觀點，非常值得進一步閱讀、體會和實踐。可以從這幾個方面閱讀，重點推薦2和3：1. 測試的職業規劃，測試架構師的關鍵能力和知識體系。*2. 測試理念、觀點和方法*3. 自動化測試理念、觀點和實踐4. 產品質量的8個屬性和測試方法5. 做產品的啓發 書中要點，零散筆記：1. 測試的職業規劃（1）測試可以在管理方向和技術方向相互轉換 “測試架構師是測試技術方面的一個發展方向，是產品測試技術專家，其主要職責是對不同的組織、產品、研發模式做出最適合當前狀況的選擇，進行剛剛好的測試，爲產品成功保駕護航，提供支撐。”（圖2-8） “測試架構師的工作是保證測試的正確性，而測試管理者的工作是保證落地和交付。” （2）測試架構師的關鍵能力和知識體系。6個關鍵能力（圖4-1）、測試策略的全局視角（圖4-2）和測試技術知識體系（圖5-1 ）。 2. 測試理念、觀點和方法（1）"Test is Dead!" 真實的含義（by Savoia） “真正死去的，是那些傳統模式下重複的、低效的、堆人的測試，取而代之的是那些更加專業的測試，這些測試不僅不會死，還會成爲搶手資源。” 測試可以通過自動化固化產品的基本能力，測試人員是最貴的資源，他們應該聚集更有效的測試策略，實現場景測試、性能測試、更高效的探索式測試。 （2）探索式測試(Explortary Testing) 不是“發散測試找缺陷”，而是一種測試風格，強調並行、交互地開展學習、測試設計和執行。ET的定義可以查看Wikipedia介紹。 ET思維模型是CPIE（Collation，Prioritization，Investigation，Experimentation），包含整理、排序、調查和實驗的4個階段，並持續迭代。ET需要針對特性的價值，進行分區，並根據不同的分區，選擇不同的ET方法。 “和探索式測試對應的是腳本式測試（ScriptTesting，ST），腳本式測試要求測試人員編寫測試腳本去記錄所有的測試用例（包括測試操作和預期），然後通過腳本來實施測試。” James Bach總結的探索式測試和腳本式測試的差別：“在腳本式測試中，測試人員先設計測試用例，再在一段時間後執行這些測試用例，或者測試用例被其他測試人員執行。而在探索式測試中，測試用例是在測試執行時被設計的，而且大部分測試用例不需要詳細的記錄。” 探索性測試在整個測試中，理想的佔比是多少，參考圖4-14。 （3）開展基於產品特性價值、以及高價值特性的風險的測試，是一種驗收策略。 （4）價值流：價值流是精益模式中的一個基本概念。Karen Martin和Mike Osterling在Value Stream mapping中，把價值流定義爲“一個組織基於用戶需求所執行的一系列有序的交付活動”，包含了拿到用戶需求後，爲用戶進行設計、生產和提供產品服務所需的所有活動。測試活動在VSM中，需要體現高價值。 （5） 啓發式測試策略模型：測試專家James Bach提出的啓發式測試策略模型（Heuristic Test Strategy Model，HTSM），由項目環境、產品元素、測試技術和質量標準4個維度組成，如圖9-9所示。 （6）可測性：系統對輸入，以某種方式提供反饋，以便評估系統行爲（用戶）或者實現（技術）是否正確的可能性即可測性；質量的8個屬性，都要分析可測性； （7）測試設計：“好的測試設計得到的是整潔的測試用例”，參考《代碼整潔之道》。實例化需求是強大的測試思想，在自動化方面的應用也是，參考《實例化需求-團隊如何交付正確的軟件》by Gojko Adzic。 3. 自動化測試理念、觀點和實踐 （1）“自動化測試其實是一種誤稱，因爲無論如何嘗試自動化測試，都需要引入大量測試人員。自動化測試可以理解爲“工具支持的測試”，使用任何工具來幫助測試都屬於自動化測試的一種類型。“（James Bach自動化敏捷測試，2003） （2）“自動化測試的意義首先在於固化能力，其次纔是提升效率”，而不是反過來，強調效率，但不能做到有效的能力固化；不能固化能力的自動化用例，也可能成爲類似nonDeterminism的用例，也無法達到爲產品重構提供信心的好處； （3）“自動化測試最基本的要求其實就是兩點：測試者能夠充分信任自動化的結果；自動化腳本可穩定連續運行，可維護，可移植。”即自動化用例：a）不能是nonDeterminism的用例，否則它們無法被信任；（參考Martin Fowler關於nonDeterminism博文:https://martinfowler.com/articles/nonDeterminism.html）b）自動化腳本應該具有原子性，維護不應隨着用例的增長而快速增長，甚至變得無法維護。c）自動化腳本應該能反覆運行，即不依賴產品環境的數據，用例應該不關心繫統初始狀態，或者創造系統的初始狀態，在自動化測試結束後，清除自動化測試過程創建的數據和痕跡； （4）自動化測試推薦金字塔模型，Martin Fowler 認爲， 基於用戶接口（如UI）的自動化測試運行慢、效率低、維護開銷大。因此自動化測試應該投入更多的精力在單元（Unit）和接口（Service）層，這樣不僅自動化測試效率更高，還可以更早發現質量問題，提升系統質量。（參考 https://martinfowler.com/bliki/TestPyramid.html） 自動化測試的其它模型，比如Trophy和Honeycomb的討論：https://martinfowler.com/articles/2021-test-shapes.html 許多產品的測試是釘子模型，UI的手動測試佔比非常高，接口和單元測試的比例低。規範的接口定義，合適的自動化理念、流程和框架，以及自動化測試的分層，是達到測試金字塔模型的前提。 舉個簡單的場景，如果產品開發涉及前後端的數據交互，後端接口返回的數據，不符合規範，比如數據的類型、結構以及資源等的描述或操作不符合規範，前端需要進一步封裝或者業務邏輯處理，那麼，接口(service)層的自動化可能無法做得很充分。因爲，即使接口層的自動化用例全部通過，但數據可能不是前端直接就能用的，整體的自動化效果會打折。後續接口逐步規範的演進，也帶來更多的維護工作。 （5）自動化測試工具需要考慮其提供的工程能力見“圖4-113　自動化測試工具評估項”，而且自動化不僅僅是迴歸測試，而是需要發揮創造性思維，明確測試理念和思想，選擇合適的測試框架、框架，做適合自己產品特點的自動化。（參見《自動化測試最佳實踐》Dorothy Graham） （6）自動化成熟度可以評估參見圖4-115，4-116的自動化成熟度模型和成熟度評估指標。 （7）DevOps/CICD的自動化CICD、DevOps流水線上的各層測試全部自動化，參考“圖4-110　DevOps自動化效能平臺架構”。可以通過《持續集成軟件質量改進和風險降低之道》、《持續交付發佈可靠軟件的系統方法》進一步拓展理解。 4. 產品質量的8個屬性主要可以作爲手冊參考的內容：（1）車輪圖（2）各個屬性詳細測試內容（3）屬性的評估 5. 產品啓發（1）如何理解產品的商業目標和價值呢？可以參考商務知識和軟件架構的交錯關係的氣泡圖（by Dave Hendricksen），見圖3-1。 （2）產品特性價值分類銷售/核心、噱頭、繼承、輔助特性等，不同特性質量要求、測試方法都是不同的。"一個確定核心特性的取巧方法，即對那些比較成熟或正在持續演進的產品來說，用戶反饋缺陷最聚焦的那幾個特性，往往就是核心特性。" （3）"軟件中約有2/3的特性很少或從未被使用過"，因此需要謹慎規劃產品特性，以及售賣的商業模式。Standish Group的調研結果顯示：“真正被用戶使用的特性大概只有20%（7%一直使用，13%經常使用，16%有時使用，45%幾乎不用）”。文章“A Quick Look At The 7 Wastes of Software Development”指出：很多權威統計數據都顯示，現有軟件中約有2/3的特性很少或從未被使用過。 （4）產品存在“痛點”“爽點”和“癢點”參見《產品思維30講》（梁寧）

我覺得這裏面的測試設計思路真的蠻好的，蠻好的打測試功底的書，前提得靜下心來看

什麼是剛剛好的測試？如何做到剛剛好的測試，達成共贏的局面？作者從需求分析，測試分析，風險分析，風險分析和質量評估等維度進行端到端的分析，一環扣一環，缺一環可能都不容易完成。

在軟件測試領域，我推薦新手可以閱讀《軟件測試的藝術》和《測試架構師的修煉之道》作爲入門。 Myers《軟件測試的藝術》這本書的部分觀點雖然有點陳舊了，例如缺乏適應21世紀當代敏捷開發的內容。但作爲測試領域的“聖經”，該書依然非常適合初學者瞭解測試——作爲一個工程實踐領域的發展史，以及深入領悟測試領域的科學哲學。更多關於敏捷開發的內容，可以通過劉老師《測試架構師的修煉之道》這本書補充。 找工作前通過該書補充領域知識，背面試“八股文”。工作幾個月後重新閱讀，確實也基於實踐獲得了更多深入的領悟。在有工作經驗後，這本書也是常看常新的。 這本書的新版本時間早於AIGC時代，而在AIAgent輔助編程大行其道的2026年。測試以及軟件開發行業也產生了新變化。例如彙編語言和高級語言的執行結果幾乎沒有不確定性，所以軟件開發行業不需要考慮“容差”，但“容差”在其他工程學領域就非常重要。 而自然語言編程，每次輸出的結果都具有不確定性，這將“容差”重新引入了軟件行業。新一代工程師（例如我）很多已經不會“古法編程”了，如何把這些菜雞組織起來協作（笑）？ 另一方面，對各類黑箱模型（例如LLM）的評測工作，也成了測試領域的新重點。例如各類Bench marking（基準測試）非常火爆。而對於發展程度落後於LLM的，物理模型/世界模型/VLA（視覺-語言-動作）模型，如何建立一個好的，以及能促進模型質量改進的Benchmaking，依然是一個重大的挑戰。

我前15年做測試，屬於國內第一批做這個的，後5年做了開發。說實話，我感覺，測試是一個缺少自我的職業，他的能力很少一部分體現在測試本身的技能，因爲它本身也不需要啥技能，更大的技能需求體現在開發知識和業務理解。不懂業務，你不知道測試的標準，不知道啥是對的，啥是錯的。不懂技術，你很難有足夠的手段去測試底層功能。所以，當我做了開發，數據工程師，雲工程師，基本上啥都幹過了，才發現測試需要的是全才，而非專才

半個月讀完了這本書，從測試角度來看講的很有價值，很詳細，但對於書中的一些方法也要根據自身工作環境去優化使用。 很多事情需要大量時間，需要良好團隊，更需要跨部門合作和理解。測試不僅要做好自身也要讓不懂測試的人理解你支持你，不然測試本身很難有超出讓別人認可

本書體系全面，偏理論，輕實踐，需要有一定測試經驗的人去看。本人做爲開發者，從此書全面瞭解了測試工程師這個職業，其中很多關於需求分析和測試策略與用例的設計，做爲開發一樣受益良多

以前很想把自己的工作經驗總結成一本書，看了這本書之後，覺得真沒必要了！ 測試策略方面，很多我想到的沒想到的，本書都有介紹了 但是，請注意，所有事情都要理論聯繫實際，理論並不一定100%匹配你現在遇到的問題，但是絕對值得借鑑。