Home | 簡體中文 | 繁體中文 | 雜文 | 打賞(Donations) | 雲棲社區 | OSChina 博客 | Facebook | Linkedin | 知乎專欄 | Github | Search | About

16.3. 打破軟件自動化測試的格局

16.3.1. 自動化測試的誤區

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

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

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

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

16.3.2. 分層與部署帶來的問題

隨着技術發展,軟件的多樣性,測試已經不侷限于基于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. 高可用測試,集群測試

16.3.3. 壓力測試存在的問題

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

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

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

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

16.3.3.1. 壓力測試環境

壓力測試無論是單機還是網絡,都需要一個好的壓力測試環境,例如網絡好比高速公路,如果公路成為瓶頸,你能測試出準確的數據嗎?

首先準備測試環境,如單機測試要考慮CPU速度,磁碟IO速度,RAID卡的速度,RAID卡緩存大小,內存速度,PCI—E匯流排速度,甚至會涉及多對稱CPU相關配置,內存與CPU通道的問題......等等

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

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

16.3.3.2. 測試順序

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

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

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

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

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

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

16.3.3.3. 瓶頸分析

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

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

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

外部監控是最容易實現的,有成熟的工具以及解決方案,CPU,內存,磁碟IO,網絡流量等等。

內部監控是指軟件運行加載到內存中之後的變化狀態,例如內存地址,變數,函數調用,動態連結庫載入,打開檔案句柄,Socket地址和數據包等等。

16.3.3.4. 指導開發

通過數據,圖表,快速定位軟件存在的問題點,指導開發完成軟件的改進

16.3.4. 持續整合形同虛設

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

為什麼持續整合無法應用到生產環境?

(待續,敬請關注作者微信公眾號,現在已經是早上6點中了,要去睡覺了)

16.3.5. 測試的終極目標

我認為測試不僅僅是完成按照測試用例完成軟件驗收,如果僅僅測試用戶可見的UI(人機介面)是不能滿足現代軟件的測試需求的。

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

2016-12-03 06:30 AM