一步步實施 DevOps （二）

請首先閱讀：

一步步實施 DevOps （一）

為什麼自動化測試難以推廣

2005 第一次接觸自動化測試，十年已經過去了，着眼身邊的企業，真正實施自動化測試的企業非常少。 大部分企業，測試仍然處在，點滑鼠階段。測試人員通常是驗收傳遞，而沒有參與整個軟體開發周期。

為什麼自動化測試難以實施

為什麼自動化測試難以實施，我想有幾個問題，阻礙了自動測試普及。 其實懂得自動化測試工具的人還是很多的，自動化測試難以實施，并不是缺乏技術人才。Load Runner, QTP 等等很多測試人員都會使用，為什麼他們放棄這些工具，改用手動測試呢？

1. 90%測試仍然處在功能測試
2. 很多測試人員沒有開發背景
3. 測試角色，沒有貫穿整個軟體開發周期
4. 各種問題阻礙了自動化腳本
5. 在中國測試人員人力成本太低

随着技術發展，軟體的多樣性，已經不局限于基于CS結構的GUI, 基于BS浏覽器WEB UI。例如目前的安卓系統，蘋果IOS系統，微軟的 Windows Mobile 系統等等。 還有一些非人機互動界面，各種協定/接口，例如json,bson,xml-rpc,soap,mq(message queue)我認為這些都應該納入自動化測試範疇。 這就需要測試人員具有一定的開發能力，且測試上述内容速要廣泛的技術知識支撐。

我認為進階測試工程師，需要具備以下能力

1. 嗅探器使用
2. gdb 使用
3. 了解各種協定族
4. 滲透于注入
5. HTML/CSS/Javascript
6. 資料庫 等等

就WEB測試而言，涉及的内容就太廣泛了，從浏覽器->WEB伺服器->APP伺服器->緩存->資料庫，中間會經過各種代理，負載均衡，分布式檔案系統等等。

配置這樣一個測試環境都已經非常不容易，幸好我們可以采用自動化運維幹這件事。

是什麼阻礙了自動化測試

1. 各種UI特效
2. 驗證碼
3. 浏覽器支援
4. 第三方插件(Flash,ActiveX...)
5. 技術封閉

網際網路的快速發展 Load Runner, QTP 等等軟體，我認為已經跟不網際網路的快速了，他們仍然按照傳統周期釋出軟體更新。 而網際網路需要的是快速變化，網際網路應用程式開發者，需要體驗更多的創新功能，軟體軟體釋出周期至少一年一個版本。真的太慢了。

網際網路不斷加入的新技術成為了自動化測試障礙，傳統軟體無法支援這些新技術，甚至向微軟這樣的企業技術跟進都顯得不給力。

Windows Automation 3.0 是非常高大上玩意，但是你在Microsoft官網能找到的資料，少之甚少，我不知道微軟的目的何在。

隻有 Load Runner, QTP 這些功能與微軟又合作，才能拿到Windows Automation API。

中國測試人員的人力成本

測試人員的薪水在開發團隊中應該是處于中下等的。與進階程式員，軟體架構師是有很大差距的。這也造成了自動化測試難以實施的原因。

我們需要從進階程式員，軟體架構師轉測試的進階測試人員。

我們需要黑客級的測試人員！！！

打破軟體自動化測試的格局

自動化測試的誤區

自動化測試僅僅被認為是替代人工，是以我們看到很多企業實施自動化測試僅僅是将現有的 Test Case 轉換成自動化腳本。

這樣做既沒有提高測試整體水準，也沒有改善測試結果。結果是通過手工能測試出來的問題自動化測試可以測試出來，手工測試不出來的問題自動化測試也沒有測試出來。

因為測試的觀念仍停留在已有 Test Case 階段，而 Test Case 停留在業務流程測試的階段。

最終自動化測試僅僅是按照測試用例走一邊業務流程，完成業務流程的檢驗。

分層與部署帶來的問題

随着技術發展，軟體的多樣性，測試已經不局限于基于CS結構的GUI測試, 基于BS浏覽器WEB UI測試。例如目前的安卓系統，蘋果IOS系統，微軟的 Windows Mobile 系統等等也加入到自動化測試領域。

應用軟體也越來越複雜，例如：

1. 分層的變化：界面層，接口曾，業務邏輯曾，實體模型層
2. 部署的變化：從單機運作到雙機熱備份再到負載均衡，最近進化到分布式系統。
3. 存儲的變化：關系型資料庫，非關系型資料庫，緩存資料庫，搜尋引擎資料庫

從下面的金字塔架構可以看出軟體展示給使用者的隻有UI界面層

/\
           /  \
          / UI \
         /------\
        /   API  \
       /----------\
      /   Service  \     
     /--------------\
    /    Component   \
   /------------------\  
  /      Database      \
 /______________________\      

上面是軟體的分層，一個軟體經過部署後結構将會更複雜。

/\
           /  \
          /CDN \
         /------\
        / WEB SER\
       /----------\
      / APP Server \     
     /--------------\
    / Message Queue  \
   /------------------\  
  / Cache|SearchEngine \
 /   Database| NoSQL    \ 
/________________________\      

就WEB應用測試而言，涉及的内容就太廣泛了，從浏覽器->WEB伺服器->APP伺服器->緩存->資料庫，中間會經過各種代理，負載均衡，分布式檔案系統等等。

我們測試要涵蓋：

1. CDN測試，域名解析測試，
2. WEB UI測試，包括HTML,Ajax
3. API 伺服器測試，api 是非人機互動界面，它是通過特定協定與API伺服器互動通信。
4. 代碼單元測試
5. 配置測試，配置管理過程中配置變更後的測試，含系統與應用
6. 安全測試，接口安全，認證，權限
7. 注入測試，JS注入，SQL 注入，Shell 注入
8. 緩存測試，命中率測試，包括CDN，WEB伺服器，緩存伺服器，搜尋引擎
9. 壓力測試，健壯性測試
10. 擴充性測試，水準擴充測試，垂直擴充測試
11. 高可用測試，叢集測試

 壓力測試存在的問題

請參考我的另一篇文章《壓力測試中存在的問題》

這裡我要再單獨強調壓力測試，很多人的測試方法是有問題的。

壓力測試不是準備一台機器安裝壓力測試軟體就可以開始測試的。 壓力測試的環境非常重要，很多工作多年的測試人員都沒有意識到這個問題。

壓力測試有兩個重點，一是壓力測試環境的建設，二是壓力測試順序。

 壓力測試環境

壓力測試無論是單機還是網絡，都需要一個好的壓力測試環境，例如網絡好比高速公路，如果公路成為瓶頸，你能測試出準确的資料嗎？

首先準備測試環境，如單機測試要考慮CPU速度，磁盤IO速度，RAID卡的速度，RAID卡緩存大小，記憶體速度，PCI—E總線速度，甚至會涉及多對稱CPU相關配置，記憶體與CPU通道的問題......等等

如果是測試分布式系統，除了上述單節點的注意事項，還要考慮到路由器/防火牆的包轉發與連接配接數限制，交換機的背闆帶寬以及吞吐能力，負載均衡器的轉發能力。

作業系統要考慮核心參數優化，TCP/IP棧優化，各種伺服器的配置。

 測試順序

壓力測試順序的切入點非常重要，測試順序上多數人是從UI（人機界面）切入，即由UI驅動業務邏輯，這種測試順序是錯誤的，例如使用者->浏覽器->WEB伺服器->APP伺服器->緩存->資料庫等等，這就帶來很多問題。

\------------------/
 \    Web server  /
  \   App Server /
   \ Cache / MQ /
    \ Database /
     \ Disk IO/
      \      /      

軟體的性能平靜通常是沙漏型的，最大的瓶頸莫過于資料庫，其他伺服器的瓶頸我們都能從架構的角度去解決性能問題。

所有我們應該先從資料庫測試，首先确認資料庫的配置優化是否能達到我們預期值。然後是緩存，消息隊列，搜尋引擎等等.....

至此我們已經知道資料庫，緩存，消息隊列，搜尋引擎不會成為我們壓力測試中的瓶頸。接下就可以測試應用伺服器和應用軟體了。

如果你的測試格局能夠放大一點要考慮的遠不止上述那些。 你還需考慮硬體，網絡，操作核心參數優化，TCP/IP棧優化，驗證運維配置是否能滿足我們需求等等.....。

瓶頸分析

我們需要有一套監控解決方案，能夠監控到硬體的性能，軟體的性能。

測試目的不是為了得出一個結果，告訴開發人員你的軟體能支撐XXX并發，而是在我們測試中監控每項操作，計算出每個功能所用的時間，分析出性能的平靜，指導開發人員改進軟體。

監控分為外部監控與内部監控。

外部監控是最容易實作的，有成熟的工具以及解決方案，CPU,記憶體，磁盤IO，網絡流量等等。

内部監控是指軟體運作加載到記憶體中之後的變化狀态，例如記憶體位址，變量，函數調用，動态連結庫載入，打開檔案句柄，Socket位址和資料包等等。

指導開發

通過資料，圖表，快速定位軟體存在的問題點，指導開發完成軟體的改進

持續內建形同虛設

持續內建，自動化建構幾乎麼個測試團隊都會實施，但實際境況并不理想，僅僅停留在工具配置的階段。幾乎沒有人在生産環境上使用自動化建構。

為什麼持續內建無法應用到生産環境？

測試的終極目标

我認為測試不僅僅是完成按照測試用例完成軟體驗收，如果僅僅測試使用者可見的UI(人機接口)是不能滿足現代軟體的測試需求的。

測試者應該站在更高的角度看問題，測試者是有能力指導開發人員，改善軟體的性能，健壯性，安全性，以及影響軟體架構的設計。 測試者需要有廣泛的跨界知識支撐，要不斷學習提高，打破現有格局。

壓力測試中存在的問題

 (What) 什麼是壓力測試

軟體壓力測試是一種基本的品質保證行為，它是每個重要軟體測試工作的一部分。軟體壓力測試的基本思路很簡單： 不是在正常條件下運作手動或自動測試，而是在計算機數量較少或系統資源匮乏的條件下運作測試。 通常要進行軟體壓力測試的資源包括内部記憶體、CPU 可用性、磁盤空間和網絡帶寬。

壓力測試涵蓋，性能測試，負載測試，并發測試等等，這些測試點常常交織耦合在一起。

30.2.1.1. 壓力測試存在那些問題

我歸納一下又幾點：

1. 作業系統預設安裝，在未做任何優化的情況下實施壓力測試
2. 未考慮磁盤IO對軟體的影響
3. 未考慮網絡帶寬對軟體的影響
4. 網絡軟體測試，沒有考慮到TCP特點
5. 各種逾時參數優化
6. 測試用戶端未優化
7. 并發了解有誤
8. WEB伺服器，資料庫，等等伺服器未優化

如果上面幾項沒有做優化，壓力測試資料基本沒有任何參考價值，任何一項沒有優化，都會導緻你的壓力測試資料出現偏差。 下面我來逐條說明：

1. 作業系統問題 作業系統是大衆化軟體，出廠優化都是面向大衆，不可能為某個領域做單獨優化。是以我們第一步需要優化作業系統。 Linux 系統優化核心參數，Windows 系統優化系統資料庫等等。
2. 磁盤IO 這是最容易出現瓶頸的地方，常常是CPU還沒有達到極限，磁盤已經不堪重負。
3. 網絡IO 與磁盤IO相同
4. TCP連接配接 幾乎所有 B/S, C/S 軟體都是采用多線程，或者多程序技術。這種技術有個特點，開發者将程式設計為線程可自動伸縮模式，開啟程序後會啟動少量線程，當連接配接不斷提高後，線程數逐漸增加，随着線程運作結束後，線程逐漸減少。 這樣的設計會更有效地利用硬體資源，在程式空閑時将硬體資源讓給其他程序。少有軟體設計為開啟服務獨占資源。 這樣測試軟體做壓力測試，不能一次并發很多請求，而是要采用逐漸增加的方式，否則第一次測試會有一部們并發不能及時響應，導緻測試資料偏差。另外也你可以多做幾次壓力請求（讓多線程工作起來），從第三次開始記錄測試資料，忽律前面兩次的測試資料。

提示：另一個問題是TCP連接配接複用，這也是一個重要配置項。如果這項沒有配置，我想測試出的資料也會有偏差

1. 逾時參數 逾時參數在壓力測試中是非常重要的參數，例如從WEB到資料庫連接配接逾時是60秒，如果有一個SQL查詢超過300秒，那麼後面的請求會持續排隊等待，當連接配接數達到資料庫的最大連接配接時，接下來的所有請求都是失敗的。 通常我們的WEB伺服器逾時不會超過30秒，有時我設定為10秒，一旦出現逾時，甯可讓該連接配接Timeout，不要讓他影響整體服務。
2. 用戶端 很多網絡軟體需要從用戶端發出壓力測試請求，是以用戶端的優化也是必須的，否則用戶端壓力出不去，服務端壓力進不來。
3. 并發 很多人認為并發，就是同一時間内的最大連接配接數，這是錯誤的。如果你寫過多線程程式，就會發現多線程運作時又規律的。是順序排隊運作的，根本不是同時運作的。 是以并發是指，相對時間内能完成的連接配接總和，例如，每秒并發，每分鐘并發等等，通常我們已秒為機關。 我們目前使用的作業系統叫分時作業系統，這種系統的特點就是可能實作多使用者，多任務。作業系統将程序排隊（優先級）輪詢運作，隻不過這個操作太快了，使你認為多個程序在同時運作。
4. 伺服器優化 主要B/S軟體壓力測試，WEB，緩存，資料庫等等伺服器，都需要逐一優化到最佳狀态

 (Why) 為什麼做壓力測試

如果在軟體設計階段都将這些問題元素都考慮進去，同時開發階段嚴格執行。那麼開發出些軟體幾乎不用做這個勞人傷神的壓力測試。

是以在軟體設計階段就要考慮，靈活性，擴充性，可靠性與性能，還要考慮高可用與負載均衡。

同時軟體優化伴随開發，持續內建，持續測試，持續部署。

 (Where) 在哪裡做壓力測試

有些軟體需要封閉的環境測試，不能在共享資源的環境中做測試。是以你有必要做Vlan隔離，甚至獨立的路由器與交換機在封閉網絡中測試。

(When) 什麼時間做壓力測試

任何時間都可能做壓力測試，為什麼我将“時間”重點提出呢？目前受地球自轉影響，經常閏秒，你不的不考慮這個問題。

(Who) 壓力測試過程參與人員

1. 運維部門
2. 開發部門
3. 測試部門

 (How) 如何做壓力測試

下面我們舉一些例子，講述壓力測試方法，限于篇幅不可能面面俱到，我僅僅是給你提供思路。

測試前你需要一些監控工具，事實監控伺服器的資源變化。

例如 Web 伺服器壓力測試，測試場景是 nginx ：

怎麼測試呢？你要活得最大化性能嗎？還是相對性能？我們通常需要的是滿足需求就好的相對性能，而不是最大化性能。為什麼呢？因為要活得最大化性能是要做出很多配置犧牲的，例如關閉日志，禁止通路時間等等。

按照上面的配置你的測試用例應該是，每次并發4000 請求 8000~10000 次， 你不能并發8000 請求 4000 這樣測試。很是很多人常常犯的錯誤，是以測試者需要連接配接系統的配置參數，不能盲目使用數字實驗。

上面我說過線程的開啟時随着請求，逐漸增加的，是以首次發起測試資料是不準确的，通過pstree指令可以看到線程數量。等第三次以後線程逐漸增加到4096個，并且之前開啟的TCP可以複用，這時測試的結果比較有說服力。

延伸閱讀《Netkiller Web 手劄》《Netkiller Testing 手劄》《Netkiller Linux 手劄》

版權聲明

轉載請與作者聯系，轉載時請務必标明文章原始出處和作者資訊及本聲明。