導讀：要做好系統分析類工程師的面試筆試，本身有專業的技術是基礎，但也要保持一個超高的學習熱情!以下是由本站小編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，進程，線程有關。同時爲後面的學習筆記：分佈式，雲打下知識基礎。