一步步實施 DevOps （二）

時間  2019-11-11
標籤 步步 實施 devops 简体版
原文   原文鏈接

Netkiller Management 手札

 

Mr. Neo Chan, 陳景峯(BG7NYT)



中國廣東省深圳市望海路半島城邦三期
518067
+86 13113668890

<netkiller@msn.com>nginx

Copyright © 2010-2018 netkillergit

 

版權聲明程序員

轉載請與做者聯繫，轉載時請務必標明文章原始出處和做者信息及本聲明。github
http://www.netkiller.cn
http://netkiller.github.io
http://netkiller.sourceforge.net
微信訂閱號 netkiller-ebook (微信掃描二維碼）
QQ：13721218 請註明「讀者」
QQ羣：128659835 請註明「讀者」

 

請首先閱讀：數據庫

一步步實施 DevOps （一）json

爲何自動化測試難以推廣

2005 第一次接觸自動化測試，十年已通過去了，着眼身邊的企業，真正實施自動化測試的企業很是少。 大部分企業，測試仍然處在，點鼠標階段。測試人員一般是驗收交付，而沒有參與整個軟件開發週期。api

爲何自動化測試難以實施

爲何自動化測試難以實施，我想有幾個問題，阻礙了自動測試普及。 其實懂得自動化測試工具的人仍是不少的，自動化測試難以實施，並非缺少技術人才。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 ：

worker_processes  8;            處理器數
    worker_rlimit_nofile 65530;     容許最多打開文件數
    worker_connections  4096;       最大鏈接數數爲
    keepalive_timeout  65;          開啓複用鏈接
    gzip  on;                       壓縮傳輸數據

怎麼測試呢？你要活得最大化性能嗎？仍是相對性能？咱們一般須要的是知足需求就好的相對性能，而不是最大化性能。爲何呢？由於要活得最大化性能是要作出不少配置犧牲的，例如關閉日誌，禁止訪問時間等等。

按照上面的配置你的測試用例應該是，每次併發4000 請求 8000~10000 次， 你不能併發8000 請求 4000 這樣測試。非常不少人經常犯的錯誤，因此測試者須要鏈接系統的配置參數，不能盲目使用數字實驗。

上面我說過線程的開啓時隨着請求，逐漸增長的，因此首次發起測試數據是不許確的，經過pstree命令能夠看到線程數量。等第三次之後線程逐漸增長到4096個，而且以前開啓的TCP能夠複用，這時測試的結果比較有說服力。

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

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程