前段時間星球羣裏大家聊起了系統架構相關的話題。有同學說現在測試面試太難了，既要懂業務，又要寫代碼，更要懂系統架構，對常用的中間件也要有所瞭解，最好是有一定的使用經驗，學不完，根本學不完。
事實真的是這樣嗎？從我的觀察來說，上述的要求在一些知名互聯網企業確實有這些要求，如果你在面試時能表現出良好的技術能力和深厚的業務經驗，且對系統架構和常用中間件有所瞭解，對面試加分不少，通過的概率也會更大。
大部分測試崗位，在實際場景中主要的工作內容還是圍繞着需求和測試用例開展點點點工作。以前還有專職的自動化測試和性能測試崗位，近幾年隨着市場環境的變化，專項崗位越來越少，對測試的要求變化趨勢也逐漸向着全棧工程師演變。
從我的角度來理解，這是市場迴歸理性和現實的轉變。所謂的全棧工程師，並不是要求你對技術和業務都精通，而是你要對你所在崗位的工作內容負責，一站到底。
比如你是一位測試工程師，負責某一個業務模塊或者業務線的測試工作，那這部分和測試相關的工作涉及到的所有問題，到你這裏就要兜底，能全部解決。
畢竟，作爲測試工程師，對軟件質量負責，推動解決自己負責部分的質量問題，也是應有之義。
爲什麼這篇文章的標題我會建議測試工程師有必要了解系統架構，不妨從下面幾個角度來理解。
首先，我們的測試對象是什麼？是根據抽象業務需求通過技術實現的具象的軟件產品，即軟件系統是業務的實現載體。要做好軟件產品的質量保障工作，你勢必要對它有足夠的瞭解，否則無論是設計用例還是發現BUG，都是浮於表面，無法發現深層次的問題。
其次，我們常用的測試手段，比如接口測試、性能測試以及自動化測試，也是藉助各種測試工具或者框架通過技術手段來驗證軟件系統的功能實現是否和需求要求一致。
以接口自動化測試爲例，要想做好接口自動化測試，首先要了解接口的輸入輸出參數，其次要了解請求的上下游調用關係，再次要對數據的整個傳輸鏈路有所瞭解(如消息是否被消費，緩存是否命中，數據庫數據是否落庫)，否則落地過程中會遇到很多阻塞問題。
最後，自動化測試中，測試數據如何管理，出現問題如何查看日誌排查(監控)，服務如何部署(服務註冊配置)，諸如此類的問題，最後對應的都是系統架構。
下圖爲一個簡易的微服務系統架構圖：
我們在需求評審時，可能會遇到對某某業務進行流程優化，改動某某部分，然後進行需求分析並設計用例。
但是在實際的測試過程中，我們需要了解改動部分直接涉及了哪些服務，對上下游服務有什麼影響，原來的技術實現是否能支撐改動後的用戶訪問量，是否需要在線上針對性進行驗證和配置預案，諸如此類很多因素需要考量。
要解決這些問題，首先要把業務流程捋清楚，然後搞明白服務間的調用依賴關係，最後對系統架構有全面的瞭解，才能更好的解決這些問題，做好質量保障工作。
搞清楚這些，無論你做自動化測試還是性能測試，實施難度都可以降低很多，基於此做產出做彙報，也更有說服力。
這篇文章先聊到這兒，下篇文章，我會分享一些系統架構知識入門的經驗，敬請期待。