Ⅰ 基於linux環境的自動化測試的研究應用
(一)各種技術應用的前提。對於在開源社區和一些開源項目中獲得的測試工具，首先需要了解工具適用於哪些類型應用的測試，以及工具發布後的發布說明和FAQ。開源的工具通常不像商業工具那樣成熟穩定，因此找出工具的適用范圍以及探索工具的實現程度是進行自動化測試應用的前提。
(二)各種技術應用的環境需求。對於各類工具，需要關注編譯和運行時對各種包和庫及其版本的依賴關系以及對預先安裝的應用的依賴關系。這些在用戶手冊中都有詳盡的說明。
(三)伺服器性能監視器。大部分測試工具沒有提供伺服器端的性能監控功能，測試工程師需要根據實際的需求編寫性能監控腳本來配合工具的使用。
下面結合曾經參與進行過的Linux平台下的自動化測試的研究，面向不同類別的測試用例自動化的需求，將主要從功能測試，如GUI測試、命令行客戶端的測試，以及性能測試等幾個方面對Linux平台下的測試工作的自動化進行分析和說明。
GZW自動化洲試
對於GUI測試的自動化，通常的測試工具所使用的捕捉／回放技術有兩種，一種是通過記錄界面的滑鼠事件(如點擊、移動)和鍵盤事件來完成錄制和回放，另外一種則是錄制和回放都是基於控制項的識別和操作進行的掘空，每個腳本的執行都是控制項對象的屬性改變或事件觸發。我們從開源社區可以獲得如上兩種類型的運行於Linux平台之上的典型測試工具，如Knee和LDTP等。
(一)Xnee工具
在Linux操作系統的xll環境下，Xnee能夠錄制、回放和分發用戶的動作。Xnee的捕捉／回放技術是記錄滑鼠事件和鍵盤事件。進入錄制模式時，Xnee記錄發送至和來自X server之間的協議數據拷貝，並生成Xneesession文件。在回放模式下，Xnee讀取Xnee Session中的事件，模仿整個錄制過程(即用戶操作過程)完成和x server之間的通訊，被錄制的應用軟體(Xclient)則接收來自xserver的消息，完成預設的動作。
(二)LDTP測試工具／框架
Linux Desktop Testing Project(LDTP)測試工具／框架能夠基於用戶在應用界面的選擇進行腳本的錄制。LDTPI具使用了Gnome環境下的Accessibility庫即輔助選項庫(at-spi)。使用輔助選項能夠獲得應用通過AT-SPI協議提供的關於用戶界面的信息和界面控制項的當前狀態或者屬性。LDTPI具／框架的體系結構如下：
AT-SPI的基礎思想就是為用戶界面的可視化元素提供對應的輔助對象，而錄制完成的每個腳本的執行都是基於這些輔助對象進行的。對於希望利用LDTPI具進行測試的應用，需要激活輔助選項。
(三)GUI自動化測試工具的應用
在實際的GUI自動化測試中，LDTPI具應用的場景會更廣泛一些。LDTPI具可以識別窗口中的對象(如按鈕)，測試腳本使用LDTP的API介面，每個API介面對UI對象進行操作判局瞎存在兩個最基本的入口，即窗口和對象臘早，窗口通過窗口的類型和名稱(即標題)識別，對象通過希望操作的控制項的類型和名稱(標簽或者關聯的標簽)識別。我們同樣可以通過at-pokel具展現激活了輔助選項的應用程序窗口的對象及對象屬性。在測試Linux桌面產品和伺服器產品的過程中，使用LDTPI具可以測試任何啟用輔助選項的Gnome應用，如Mozilla，OpenOffice.org、Evolution郵件客戶端，Nautilus文件瀏覽器等等，此外還可以測試UI界面基於Swing的Java應用，以及KDE4.O上基於QT4.0的應用等等。
而Xneel具所針對的應用程序類型就沒有特別的限制，對於一些簡單的窗口驗證測試和界面的穩定性測試等則比較有效。Xnee相對於基於控制項方式捕獲和回放的工具而言，不用擔心存在控制項不能被識別的問題。
從使用的情況來看，各個工具也都因為實現技術而存在一定的缺陷，如兩個工具均不能插入驗證點，從而不能實現用例級別的結果驗證；LDTP對於界面的個別元素捕獲不到以及不能對不支持輔助選項的應用進行測試等等；而Xneel具生成的腳本可編輯性差，同時由於錄制生成的腳本中的事件和屏幕坐標相關，因此當出現窗口彈出位置發生變化等問題時，就需要考慮回放時應該如何來處理這些變化。
Ⅱ 如何測試兩台linux伺服器之間的連接速度有什麼命令或軟體可以做到詳細些。
iperf,具體要纖細直接去看文檔，
簡單給你列條測試：（TCP和UDP知只是兩種傳輸數據的協議）
1）TCP測試
伺服器執行：./iperf -s -i 1 -w 1M '這裏是指定windows如果是 iperf -s則windwos默認大小為8kbyte/s
客戶端執行：./iperf -c host -i 1 -w 1M 其中-w表示TCP window size，host需替換成伺服器地址。
2）UDP測試
伺服器執行：./iperf -u -s
客戶端執行：./iperf -u -c 10.255.255.251 -b 900M -i 1 -w 1M -t 60 其中-b表示使用多少帶寬，1G的線路你可以使用900M進行測試。
不給分不給力
Ⅲ linux 性能優化-- cpu 切換以及cpu過高
本文先介紹了cpu上下文切換的基礎知識，以及上下文切換的類型（進程，線程等切換）。然後介紹了如何查看cpu切換次數的工具和指標的解釋。同時對日常分析種cpu過高的情況下如何分析和定位的方法做了一定的介紹，使用一個簡單的案例進行分析，先用top，pidstat等工具找出佔用過高的進程id，然後通過分析到底是用戶態cpu過高，還是內核態cpu過高，並用perf 定位到具體的調用函數。（來自極客時間課程學習筆記）
1、多任務競爭CPU，cpu變換任務的時候進行CPU上下文切換(context switch)。CPU執行任務有4種方式：進程、線程、或者硬體通過觸發信號導致中斷的調用。
2、當切換任務的時候，需要記錄任務當前的狀態和獲取下一任務的信息和地址(指針)，這就是上下文的內容。因此，上下文是指某一時間點CPU寄存器(CPU register)和程序計數器(PC)的內容, 廣義上還包括內存中進程的虛擬地址映射信息.
3、上下文切換的過程：
4、根據任務的執行形式，相應的下上文切換，有進程上下文切換、線程上下文切換、以及中斷上下文切換三類。
5、進程和線程的區別：
進程是資源分配和執行的基本單位；線程是任務調度和運行的基本單位。線程沒有資源，進程給指針提供虛擬內存、棧、變數等共享資源，而線程可以共享進程的資源。
6、進程上下文切換：是指從一個進程切換到另一個進程。
(1)進程運行態為內核運行態和進程運行態。內核空間態資源包括內核的堆棧、寄存器等；用戶空間態資源包括虛擬內存、棧、變數、正文、數據等
(2)系統調用(軟中斷)在內核態完成的，需要進行2次CPU上下文切換(用戶空間-->內核空間-->用戶空間)，不涉及用戶態資源，也不會切換進程。
(3)進程是由內核來管理和調度的，進程的切換只能發生在內核態。所以，進程的上下文不僅包括了用戶空間的資源，也包括內核空間資源。
(4)進程的上下文切換過程：
(5)、下列將會觸發進程上下文切換的場景：
7、線程上下文切換：
8、中斷上下文切換
快速響應硬體的事件，中斷處理會打斷進程的正常調度和執行。同一CPU內，硬體中斷優先順序高於進程。切換過程類似於系統調用的時候，不涉及到用戶運行態資源。但大量的中斷上下文切換同樣可能引發性能問題。
重點關注信息：
系統的就緒隊列過長，也就是正在運行和等待 CPU 的進程數過多，導致了大量的上下文切換，而上下文切換又導致了系統 CPU 的佔用率升高。
這個結果中有兩列內容是我們的重點關注對象。一個是 cswch ，表示每秒自願上下文切換（voluntary context switches）的次數，另一個則是 nvcswch ，表示每秒非自願上下文切換（non voluntary context switches）的次數。
linux的中斷使用情況可以從 /proc/interrupts 這個只讀文件中讀取。/proc 實際上是 Linux 的一個虛擬文件系統，用於內核空間與用戶空間之間的通信。/proc/interrupts 就是這種通信機制的一部分，提供了一個只讀的中斷使用情況。
重調度中斷（RES），這個中斷類型表示，喚醒空閑狀態的 CPU 來調度新的任務運行。這是多處理器系統（SMP）中，調度器用來分散任務到不同 CPU 的機制，通常也被稱為處理器間中斷（Inter-Processor Interrupts，IPI）。
這個數值其實取決於系統本身的 CPU 性能。如果系統的上下文切換次數比較穩定，那麼從數百到一萬以內，都應該算是正常的。但當上下文切換次數超過一萬次，或者切換次數出現數量級的增長時，就很可能已經出現了性能問題。這時，需要根據上下文切換的類型，再做具體分析。
比方說：
首先通過uptime查看系統負載，然後使用mpstat結合pidstat來初步判斷到底是cpu計算量大還是進程爭搶過大或者是io過多，接著使用vmstat分析切換次數，以及切換類型，來進一步判斷到底是io過多導致問題還是進程爭搶激烈導致問題。
CPU 使用率相關的重要指標：
性能分析工具給出的都是間隔一段時間的平均 CPU 使用率，所以要注意間隔時間的設置，特別是用多個工具對比分析時，你一定要保證它們用的是相同的間隔時間。比如，對比一下 top 和 ps 這兩個工具報告的 CPU 使用率，默認的結果很可能不一樣，因為 top 默認使用 3 秒時間間隔，而 ps 使用的卻是進程的整個生命周期。
top 和 ps 是最常用的性能分析工具：
這個輸出結果中，第三行 %Cpu 就是系統的 CPU 使用率，top 默認顯示的是所有 CPU 的平均值，這個時候你只需要按下數字 1 ，就可以切換到每個 CPU 的使用率了。繼續往下看，空白行之後是進程的實時信息，每個進程都有一個 %CPU 列，表示進程的 CPU 使用率。它是用戶態和內核態 CPU 使用率的總和，包括進程用戶空間使用的 CPU、通過系統調用執行的內核空間 CPU 、以及在就緒隊列等待運行的 CPU。在虛擬化環境中，它還包括了運行虛擬機佔用的 CPU。
預先安裝 stress 和 sysstat 包，如 apt install stress sysstat。
stress 是一個 Linux 系統壓力測試工具，這里我們用作異常進程模擬平均負載升高的場景。而 sysstat 包含了常用的 Linux 性能工具，用來監控和分析系統的性能。我們的案例會用到這個包的兩個命令 mpstat 和 pidstat。
下面的 pidstat 命令，就間隔 1 秒展示了進程的 5 組 CPU 使用率，
包括：
perf 是 Linux 2.6.31 以後內置的性能分析工具。它以性能事件采樣為基礎，不僅可以分析系統的各種事件和內核性能，還可以用來分析指定應用程序的性能問題。
第一種常見用法是 perf top，類似於 top，它能夠實時顯示佔用 CPU 時鍾最多的函數或者指令，因此可以用來查找熱點函數，使用界面如下所示：
輸出結果中，第一行包含三個數據，分別是采樣數（Samples）如2K、事件類型（event）如cpu-clock:pppH和事件總數量（Event count）如：371909314。
第二種常見用法，也就是 perf record 和 perf report。 perf top 雖然實時展示了系統的性能信息，但它的缺點是並不保存數據，也就無法用於離線或者後續的分析。而 perf record 則提供了保存數據的功能，保存後的數據，需要你用 perf report 解析展示。
1.啟動docker 運行進程：
2.ab工具測試伺服器性能
ab（apache bench）是一個常用的 HTTP 服務性能測試工具，這里用來模擬 Ngnix 的客戶端。
3.分析過程
CPU 使用率是最直觀和最常用的系統性能指標，在排查性能問題時，通常會關注的第一個指標。所以更要熟悉它的含義，尤其要弄清楚:
這幾種不同 CPU 的使用率。比如說：
碰到 CPU 使用率升高的問題，你可以藉助 top、pidstat 等工具，確認引發 CPU 性能問題的來源；再使用 perf 等工具，排查出引起性能問題的具體函數.
Ⅳ 如何檢查linux伺服器cpu，內存性能
1.查看系統負載
（1）uptime
這個命令可以快速查看機器的負載情況。
在Linux系統中，這些數據表示等待CPU資源的進程和阻塞在不可中斷IO進程（進程狀態為D）的數量。
命令的輸出，load average表示1分鍾、5分鍾、15分鍾的平均負載情況。
通過這三個數據，可以了解伺服器負載是在趨於緊張還是趨於緩解。
如果1分鍾平均負載很高，而15分鍾平均負載很低，說明伺服器正在命令高負載情況，需要進一步排查CPU資源都消耗在了哪裡。
反之，如果15分鍾平均負載很高，1分鍾平均負載較低，則有可能是CPU資源緊張時刻已經過去。
(2)W
Show who is logged on and what they are doing.
可查詢登錄當前系統的用戶信息，以及這些用戶目前正在做什麼操作
其中的load average後面的三個數字則顯示了系統最近1分鍾、5分鍾、15分鍾的系統平均負載情況
注意：
load average這個輸出值，這三個值的大小一般不能大於系統邏輯CPU的個數。
如果輸出中系統有4個邏輯CPU，如果load average的三個值長期大於4時，說明CPU很繁忙，負載很高，可能會影響系統性能，
但是偶爾大於4時，倒不用擔心，一般不會影響系統性能。相反，如果load average的輸出值小於CPU的個數，則表示CPU還有空閑
2.dmesg | tail
該命令會輸出系統日誌的最後10行。
這些日誌可以幫助排查性能問題.
3.vmstat
vmstat Virtual Meomory Statistics（虛擬內存統計），用來獲得有關進程、虛存、頁面交換空間及 CPU活動的信息。這些信息反映了系統的負載情況。
後面跟的參數1，表示每秒輸出一次統計信息，表頭提示了每一列的含義
（1）監控進程procs：
r：等待在CPU資源的進程數。
這個數據比平均負載更加能夠體現CPU負載情況，數據中不包含等待IO的進程。如果這個數值大於機器CPU核數，那麼機器的CPU資源已經飽和（出現了CPU瓶頸）。
b：在等待io的進程數 。
（2）監控內存memoy：
swpd：現時可用的交換內存（單位KB）
free：系統可用內存數（以千位元組為單位）
buff: 緩沖去中的內存數（單位：KB）。
cache：被用來做為高速緩存的內存數（單位：KB）。
（3）監控swap交換頁面
si: 從磁碟交換到內存的交換頁數量，單位：KB/秒。
so: 從內存交換到磁碟的交換頁數量，單位：KB/秒。
如果這個數據不為0，說明系統已經在使用交換區（swap），機器物理內存已經不足。
（4）監控 io塊設備
bi: 發送到塊設備的塊數，單位：塊/秒。
bo: 從塊設備接收到的塊數，單位：塊/秒。
（5）監控system系統
in: 每秒的中斷數，包括時鍾中斷。
cs: 每秒的環境（上下文）轉換次數。
（6）監控cpu中央處理器：
us：用戶進程使用的時間 。以百分比表示。
sy：系統進程使用的時間。 以百分比表示。
id：中央處理器的空閑時間 。以百分比表示。
us, sy, id, wa, st：這些都代表了CPU時間的消耗，它們分別表示用戶時間（user）、系統（內核）時間（sys）、空閑時間（idle）、IO等待時間（wait）和被偷走的時間（stolen，一般被其他虛擬機消耗）。
這些CPU時間，可以讓我們很快了解CPU是否出於繁忙狀態。
註：
如果IO等待時間很長，那麼系統的瓶頸可能在磁碟IO。
如果用戶時間和系統時間相加非常大，CPU出於忙於執行指令。
如果有大量CPU時間消耗在用戶態，也就是用戶應用程序消耗了CPU時間。這不一定是性能問題，需要結合r隊列，一起分析。
4.mpstat -P ALL 1
該命令可以顯示每個CPU的佔用情況，如果有一個CPU佔用率特別高，那麼有可能是一個單線程應用程序引起的。
MultiProcessor Statistics的縮寫，是實時系統監控工具
其報告與CPU的一些統計信息，這些信息存放在/proc/stat文件中。在多CPUs系統里，其不但能查看所有CPU的平均狀況信息，而且能夠查看特定CPU的信息。
格式：mpstat [-P {|ALL}] [internal [count]]
-P {|ALL} 表示監控哪個CPU， cpu在[0,cpu個數-1]中取值
internal 相鄰的兩次采樣的間隔時間
count 采樣的次數，count只能和delay一起使用
all ： 指所有CPU
%usr ： 顯示在用戶級別（例如應用程序）執行時CPU利用率的百分比
%nice ：顯示在擁有nice優先順序的用戶級別執行時CPU利用率的百分比
%sys ： 現實在系統級別（例如內核）執行時CPU利用率的百分比
%iowait ： 顯示在系統有未完成的磁碟I/O請求期間CPU空閑時間的百分比
%irq ： 顯示CPU服務硬體中斷所花費時間的百分比
%soft ： 顯示CPU服務軟體中斷所花費時間的百分比
%steal ： 顯示虛擬機管理器在服務另一個虛擬處理器時虛擬CPU處在非自願等待下花費時間的百分比
%guest ： 顯示運行虛擬處理器時CPU花費時間的百分比
%idle ： 顯示CPU空閑和系統沒有未完成的磁碟I/O請求情況下的時間百分比
系統有兩個CPU。如果使用參數 -P 然後緊跟CPU編號得到指定CPU的利用率。
（ Ubuntu安裝： apt-get install sysstat）
5.pidstat 1
pidstat命令輸出進程的CPU佔用率，該命令會持續輸出，並且不會覆蓋之前的數據，可以方便觀察系統動態
6.iostat -xz 1
iostat命令主要用於查看機器磁碟IO情況
r/s, w/s, rkB/s, wkB/s：分別表示每秒讀寫次數和每秒讀寫數據量（千位元組）。讀寫量過大，可能會引起性能問題。
await：IO操作的平均等待時間，單位是毫秒。這是應用程序在和磁碟交互時，需要消耗的時間，包括IO等待和實際操作的耗時。如果這個數值過大，可能是硬體設備遇到了瓶頸或者出現故障。
avgqu-sz：向設備發出的請求平均數量。如果這個數值大於1，可能是硬體設備已經飽和（部分前端硬體設備支持並行寫入）。
%util：設備利用率。這個數值表示設備的繁忙程度，經驗值是如果超過60，可能會影響IO性能（可以參照IO操作平均等待時間）。如果到達100%，說明硬體設備已經飽和。
註：如果顯示的是邏輯設備的數據，那麼設備利用率不代表後端實際的硬體設備已經飽和。值得注意的是，即使IO性能不理想，也不一定意味這應用程序性能會不好，可以利用諸如預讀取、寫緩存等策略提升應用性能
7.free -m
free命令可以查看系統內存的使用情況，-m參數表示按照兆位元組展示。
最後兩列分別表示用於IO緩存的內存數，和用於文件系統頁緩存的內存數。
註：
第二行-/+ buffers/cache，看上去緩存佔用了大量內存空間。這是Linux系統的內存使用策略，盡可能的利用內存，如果應用程序需要內存，這部分內存會立即被回收並分配給應用程序。
如果可用內存非常少，系統可能會動用交換區（如果配置了的話），這樣會增加IO開銷（可以在iostat命令中提現），降低系統性能。
8.sar -n DEV 1
sar命令在這里可以查看網路設備的吞吐率。
在排查性能問題時，可以通過網路設備的吞吐量，判斷網路設備是否已經飽和。
9.sar -n TCP,ETCP 1
sar命令在這里用於查看TCP連接狀態，其中包括：
active/s：每秒本地發起的TCP連接數，既通過connect調用創建的TCP連接；
passive/s：每秒遠程發起的TCP連接數，即通過accept調用創建的TCP連接；
retrans/s：每秒TCP重傳數量；
TCP連接數可以用來判斷性能問題是否由於建立了過多的連接，進一步可以判斷是主動發起的連接，還是被動接受的連接。TCP重傳可能是因為網路環境惡劣，或者伺服器壓力過大導致丟包。
10.top
top命令包含了前面好幾個命令的檢查的內容。比如系統負載情況（uptime）、系統內存使用情況（free）、系統CPU使用情況（vmstat）等。
因此通過這個命令，可以相對全面的查看系統負載的來源。同時，top命令支持排序，可以按照不同的列排序，方便查找出諸如內存佔用最多的進程、CPU佔用率最高的進程等。
但是，top命令相對於前面一些命令，輸出是一個瞬間值，如果不持續盯著，可能會錯過一些線索。這時可能需要暫停top命令刷新，來記錄和比對數據。
Ⅳ Linux 伺服器性能出問題，排查下這些參數指標
1.1 top
1.2 vmstat
r 表示可運行進程數目，數據大致相符；而b表示的是 uninterruptible 睡眠的進程數目；swpd 表示使用到的虛擬內存數量，跟 top-Swap-used 的數值是一個含義，而如手冊所說，通常情況下 buffers 數目要比 cached Mem 小的多，buffers 一般20M這么個數量級；io 域的 bi、bo 表明每秒鍾向磁碟接收和發送的塊數目(blocks/s)；system 域的 in 表明每秒鍾的系統中斷數(包括時鍾中斷)，cs表明因為進程切換導致上下文切換的數目。
說到這里，想到以前很多人糾結編譯 linux kernel 的時候 -j 參數究竟是 CPU Core 還是 CPU Core+1？通過上面修改 -j 參數值編譯 boost 和 linux kernel 的同時開啟 vmstat 監控，發現兩種情況下 context switch 基本沒有變化，且也只有顯著增加 -j 值後 context switch 才會有顯著的增加，看來不必過於糾結這個參數了，雖然具體編譯時間長度我還沒有測試。資料說如果不是在系統啟動或者 benchmark 的狀態，參數 context switch>100000 程序肯定有問題。
1.3 pidstat
如果想對某個進程進行全面具體的追蹤，沒有什麼比 pidstat 更合適的了——棧空間、缺頁情況、主被動切換等信息盡收眼底。這個命令最有用的參數是-t，可以將進程中各個線程的詳細信息羅列出來。
-r： 顯示缺頁錯誤和內存使用狀況，缺頁錯誤是程序需要訪問映射在虛擬內存空間中但是還尚未被載入到物理內存中的一個分頁，缺頁錯誤兩個主要類型是
-s：棧使用狀況，包括 StkSize 為線程保留的棧空間，以及 StkRef 實際使用的棧空間。使用ulimit -s發現CentOS 6.x上面默認棧空間是10240K，而 CentOS 7.x、Ubuntu系列默認棧空間大小為8196K
1.4 其他
while :; do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd' sleep 1; done
2.1 iostat
3.1 netstat
➜ ~ netstat -antp #列出所有TCP的連接
➜ ~ netstat -nltp #列出本地所有TCP偵聽套接字，不要加-a參數
3.2 sar
3.3 tcpmp