這篇文章是軟件工程系列知識總結的第五篇，同樣我會以自己的理解來闡述軟件工程中關於架構設計相關的知識。
相比於我們常見的研發架構師，測試架構師是近幾年纔出現的一個崗位，當然崗位title其實沒有特殊的含義，在我看來測試架構師其實更像對某一類人的抽象稱呼和對其複合能力的期待及認可。
在聊這篇文章的主題之前，先來看這樣一個問題：爲什麼軟件項目需要架構設計？
爲什麼軟件項目需要架構設計？
如果是一個簡單的軟件系統，沒有太多用戶使用，也沒有較爲複雜的業務邏輯，那架構設計幾乎是不需要的。爲什麼呢？
一般來說用戶少意味着操作場景較少，沒有高併發場景，也沒有複雜的業務邏輯，只要功能正確實現可以正常使用即可。但在我們實際的工作場景中，我們面對的工作對象，常常具備這兩個特點：
- 需求不確定性較高；
- 系統使用的技術較爲複雜；
需求的複雜和不確定性大家都很熟悉，特別是做互聯網To C業務的企業，需求的複雜和不確定性就更高。而技術的複雜性，主要來源於下面幾點因素：
- 需求讓技術變複雜：爲了滿足需求的複雜和不確定性，軟件系統背後的技術應用就會很複雜；
- 人員讓技術變複雜：團隊裏的同學來自不同背景不同企業，技術棧和工作經驗各不相同，因此技術也會變複雜；
- 技術本身就很複雜：不同的編程語言、框架、技術組件、數據庫、大數據、算法、ARVR等本身就是複雜的技術；
- 讓軟件穩定運行很複雜：線上服務要穩定運行會面臨各種不確定性，比如峯值流量衝擊、雲服務不可用、網絡問題；
因爲技術的複雜性，會導致軟件研發的過程變得很複雜，而軟件工程本身就是爲了擺脫軟件質量危機，以軟件開發爲核心，對開發過程組織+對方法的運用+對工具的使用，
來讓軟件系統達到穩定，而架構設計正好可以解決這些複雜性帶來的問題。架構設計的有點如下：
- 降低需求變更帶來的研發成本；
- 可以更好的組織人員高效協作；
- 架構設計本身就是對各種複雜技術的合理運用和組合；
- 架構設計可以保障線上服務更穩定的爲業務目標達成提供支撐；
測試架構師需要解決什麼問題？
看完了上面關於架構設計的優勢，其實可以快速推導出測試架構要做的事情。
研發角度的架構設計要做的是：用最小人力成本滿足需求開發和響應變更，用最合適的技術架構來保障軟件的平穩運行。
簡單來說就是：組織人力高效協作+合理設計技術框架+保障線上服務穩定運行。
從測試的角度出發，測試的本質是質量保障和推動研發效能提升。那麼測試架構要做的事情是：
- 質量把控：從需求質量到研發過程質量以及線上質量的把控；
- 技術設計：針對不同項目，選擇合適的技術棧來快速解決問題；
- 組織協調：組織測試團隊的同學高效完成軟件產品的質量保障工作；
測試架構師需要具備哪些能力？
大多數企業的組織架構是橫向的，而測試團隊在其中的定位既可能是橫向的大團隊，也可以是縱向跟着項目走的小團隊。而測試架構師的角色，在我看來其實需要具備兩點特質：
- 縱向的業務瞭解和技術深耕；
- 橫向的拉通對齊和組織協調；
結合測試架構要做的事情以及在團隊中的角色定位，我認爲測試架構應該具備如下幾點基礎能力：
測試工程師如何培養架構能力？
與其說測試架構師是一個崗位和title，不如說他是具備某些複合能力的可以解決問題的人。
當然並不是說所有測試同學都需要變成測試架構師，這種測試架構能力在日常工作和學習中是可以培養的。
對於普通的測試工程師，想要培養測試架構能力，我建議可以先從如下幾點入手：
- 分析需求：在日常工作中仔細分析需求，做好需求評審和風險評估；
- 技術選型：無論是自動化或者性能或者單元測試，儘可能選擇成熟的技術方案並對其深入瞭解；
- 逐步迭代：解決問題的過程中，避免追求完美的方案，而是先解決眼下問題，再逐步深入分析和優化；
- 不斷優化：解決問題後要不斷驗證其效果和效率，評估能否滿足未來的變化，能否持續保障軟件高質量運行；
你看，上面四點是不是和產品設計中提倡的mvp方案有類似的思路。
我在前面的文章中也提到過一個質量保障體系的總結，即：風險可識別+問題可追蹤+結果可驗證+數據可量化。
按照上面的幾點堅持去做，遲早我們都會具備架構能力。