導讀：要做好系統分析類工程師的面試筆試，本身有專業的技術是基礎，但也要保持一個超高的學習熱情!以下是由本站小編J.L為您整理推薦的基礎(系統：CPU，程序)分析師之路，歡迎參考閱讀。
今年，確定了自己的職業走向：系統工程師。所以從工作和學習積累中開始放棄一些知識點和業務點，在測試行業的大知識圈中選中自己需要的幾個要點進行深入研究。
要做好系統分析類的工程師，需要注重3個部分：資料庫，作業系統，網路。此部分以作業系統為主，結合工作經驗，開始把系統以自己的測試角度來描述一下自己的系統見解。(此次學習和工作中效能測試的書為：《作業系統精髓與設計原理》)
雖然對於評測師考核中，硬體也是測試人員的知識點之一，由於我的職業走向基本很少和純硬體打交道，我就從cpu開始學習和總結。
計算機在單核的情況下，程式對其而言是一排需要執行的指令，在高速執行的過程中，單核的計算機執行的每個時刻都是隻能處理一件事情.所以單核的 CPU處理的速度取決與它的主頻。
想在每個程序之間插入一些操作，一般來說需要靠中斷，中斷一般來自與時鐘，程式和io干預.此時就可以在cpu中執行多個程序的程式.程序一般有新建，就緒，執行，掛機，退出的狀態，通過程式和cpu自動的分配可以使得程序。
多核的計算機就好比有多個獨立的執行緒，然後有1 個主控制器來分配任務，比起單核，可以同一時間做多個任務。在這裡我有個疑問，這些多核的系統應該也會像分散式系統一樣有個控制器來主導它的執行資料，所以我覺得他也有類似一個這樣的映像瓶頸的`因素在(這點書上我沒找到相關的資料)。
對於CPU，作為效能測試人員來說，即需要分析多執行緒的客戶端程式碼編寫，也需要分析被測伺服器的執行緒相關指標。一半作為自動化的指令碼來說，執行緒可能只有10個，出現到需要‘分析’執行緒的時機不是太多，但是作為壓力測試，尤其是不依賴工具來寫，是個重要的一環。
一臺普通pc可能在執行程式可以開到幾百甚至上千個執行緒。但是你作為測試的客戶端，就會受到了CPU主頻的限制。一個CPU處理速度是有上限的，就是計算機能夠開超過上千的執行緒，它輸出的壓力其實不比幾百個執行緒高。
因為此時你的CPU到了極限，多於的執行緒其實效果就跟列表的速度差不多。所以第一點測試的時候假如要求注重併發性，你首先要算好和測試你的每臺機器最佳開啟執行緒數(測試穩定性可以不用)。
其二我一直把一個“核”當作一個測試機對待，即使在現在最流行的雲，我也是堅持物理機做壓力，因為你再怎麼虛擬，機器的效率是有限的，你用盡了機器的’潛力‘不代表你高併發。其三，算好每個測試機網路io的最大流量，即使你用強大的伺服器機來做客戶端，你的io限制了，還有作業系統的限制，使得它併發的效果不是你所想的效果。
所以，我們在有條件的情況下，做多執行緒壓力就需要用到分散式，我也經常把多核伺服器當作“小分散式”對待。
但是分析被測系統的效能的時候，除了關注上面三點外，我們其實不是關注它的併發能力，而是它的交易成功率，還有就是排隊的快取，和負載均衡的效果。
說到執行緒，應該不會忽略掉訊號量的使用，也是每年軟體評測師的典型題目：PV操作。因為互斥，死鎖等問題，在我學習科學計算的文章時，用C++ 的程式碼會用到訊號量。
但是用指令碼語言python的時候，發現很多時候，它封裝的threading竟然也做到了訊號量的操作(我在同段程式碼加入訊號量的控制，效果一樣)這點我需要後期專案機會來研究(畢竟指令碼語言使用類似ReentrantReadWriteLock的時候不多)
為什麼我會提到互斥，還有我分析作業系統期間，會關注編寫記憶體這塊呢。因為很多時候，python和java寫的指令碼測試的確沒用到這些做壓力測試。
但是你碰到操作資料庫，重現產品異常測試BUG問題，還有提高壓力時，無疑嵌入C++語言是個好選擇(這和開發相反，不知道別人是否這麼做，我現在就是這樣做，喜歡把開發速度快的語言作為主語言)。
因為很多測試程式碼“自動”的功能幫倒忙，在做效能測試的異常測試時，往往會因為語言“自動處理”導致很多問題給忽略了，這時候你也不得不用到有“手動”功能的語言來進行測試。
結語：我的測試之路就是一直在打系統知識基礎的過程，每次分析專案問題的突破都和CPU，程序，執行緒有關。同時為後面的學習筆記：分散式，雲打下知識基礎。