前言
相比于我們常見的研發架構師，測試架構師是近幾年才出現的一個崗位，當然崗位title其實沒有特殊的含義，在我看來測試架構師其實更像對某一類人的抽象稱呼和對其復合能力的期待及認可。
在聊這篇文章的主題之前，先來看這樣一個問題：為什么軟件項目需要架構設計？
為什么軟件項目需要架構設計？
如果是一個簡單的軟件系統，沒有太多用戶使用，也沒有較為復雜的業務邏輯，那架構設計幾乎是不需要的。為什么呢？
一般來說用戶少意味著操作場景較少，沒有高并發場景，也沒有復雜的業務邏輯，只要功能正確實現可以正常使用即可。但在我們實際的工作場景中，我們面對的工作對象，常常具備這兩個特點：
- 需求不確定性較高；
- 系統使用的技術較為復雜；
需求的復雜和不確定性大家都很熟悉，特別是做互聯網To C業務的企業，需求的復雜和不確定性就更高。而技術的復雜性，主要來源于下面幾點因素：
- 需求讓技術變復雜：為了滿足需求的復雜和不確定性，軟件系統背后的技術應用就會很復雜；
- 人員讓技術變復雜：團隊里的同學來自不同背景不同企業，技術棧和工作經驗各不相同，因此技術也會變復雜；
- 技術本身就很復雜：不同的編程語言、框架、技術組件、數據庫、大數據、算法、ARVR等本身就是復雜的技術；
- 讓軟件穩定運行很復雜：線上服務要穩定運行會面臨各種不確定性，比如峰值流量沖擊、云服務不可用、網絡問題；
因為技術的復雜性，會導致軟件研發的過程變得很復雜，而軟件工程本身就是為了擺脫軟件質量危機，以軟件開發為核心，對開發過程組織+對方法的運用+對工具的使用，
來讓軟件系統達到穩定，而架構設計正好可以解決這些復雜性帶來的問題。架構設計的有點如下：
- 降低需求變更帶來的研發成本；
- 可以更好的組織人員高效協作；
- 架構設計本身就是對各種復雜技術的合理運用和組合；
- 架構設計可以保障線上服務更穩定的為業務目標達成提供支撐；
?
測試架構師需要解決什么問題？
看完了上面關于架構設計的優勢，其實可以快速推導出測試架構要做的事情。
研發角度的架構設計要做的是：用最小人力成本滿足需求開發和響應變更，用最合適的技術架構來保障軟件的平穩運行。
簡單來說就是：組織人力高效協作+合理設計技術框架+保障線上服務穩定運行。
從測試的角度出發，測試的本質是質量保障和推動研發效能提升。那么測試架構要做的事情是：
- 質量把控：從需求質量到研發過程質量以及線上質量的把控；
- 技術設計：針對不同項目，選擇合適的技術棧來快速解決問題；
- 組織協調：組織測試團隊的同學高效完成軟件產品的質量保障工作；
測試架構師需要具備哪些能力？
大多數企業的組織架構是橫向的，而測試團隊在其中的定位既可能是橫向的大團隊，也可以是縱向跟著項目走的小團隊。而測試架構師的角色，在我看來其實需要具備兩點特質：
- 縱向的業務了解和技術深耕；
- 橫向的拉通對齊和組織協調；
?
結合測試架構要做的事情以及在團隊中的角色定位，我認為測試架構應該具備如下幾點基礎能力：
測試工程師如何培養架構能力？
與其說測試架構師是一個崗位和title，不如說他是具備某些復合能力的可以解決問題的人。
當然并不是說所有測試同學都需要變成測試架構師，這種測試架構能力在日常工作和學習中是可以培養的。
對于普通的測試工程師，想要培養測試架構能力，我建議可以先從如下幾點入手：
- 分析需求：在日常工作中仔細分析需求，做好需求評審和風險評估；
- 技術選型：無論是自動化或者性能或者單元測試，盡可能選擇成熟的技術方案并對其深入了解；
- 逐步迭代：解決問題的過程中，避免追求完美的方案，而是先解決眼下問題，再逐步深入分析和優化；
- 不斷優化：解決問題后要不斷驗證其效果和效率，評估能否滿足未來的變化，能否持續保障軟件高質量運行；
?
你看，上面四點是不是和產品設計中提倡的mvp方案有類似的思路。
我在前面的文章中也提到過一個質量保障體系的總結，即：風險可識別+問題可追蹤+結果可驗證+數據可量化。
按照上面的幾點堅持去做，遲早我們都會具備架構能力。
?感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：
?
?
這些資料，對于【軟件測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴上萬個測試工程師們走過最艱難的路程，希望也能幫助到你!有需要的小伙伴可以點擊下方小卡片領取?
)
實現已選中的記憶功能。實現表格數據和已選數據（前端分頁）動態同步更新。)
)
