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

自動化測試的誤區

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

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

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

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

分層與部署帶來的問題

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

應用軟件也越來越復雜，例如：

分層的變化：界面層，接口曾，業務邏輯曾，實體模型層

部署的變化：從單機運行到雙機熱備份再到負載均衡，最近進化到分布式系統。

存儲的變化：關系型數據庫，非關系型數據庫，緩存數據庫，搜索引擎數據庫

從下面的金字塔架構可以看出軟件展示給用戶的只有UI界面層

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

上面是軟件的分層，一個軟件經過部署后結構將會更復雜。

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

就WEB應用測試而言，涉及的內容就太廣泛了，從瀏覽器->WEB服務器->APP服務器->緩存->數據庫，中間會經過各種代理，負載均衡，分布式文件系統等等。

我們測試要涵蓋：

CDN測試，域名解析測試，

WEB UI測試，包括HTML,Ajax

API 服務器測試，api 是非人機交互界面，它是通過特定協議與API服務器交互通信。

代碼單元測試

配置測試，配置管理過程中配置變更后的測試，含系統與應用

安全測試，接口安全，認證，權限

注入測試，JS注入，SQL 注入，Shell 注入

緩存測試，命中率測試，包括CDN，WEB服務器，緩存服務器，搜索引擎

壓力測試，健壯性測試

擴展性測試，水平擴展測試，垂直擴展測試

高可用測試，集群測試

壓力測試存在的問題

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

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

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

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

壓力測試環境

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

首先準備測試環境，如單機測試要考慮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地址和數據包等等。

指導開發

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

持續集成形同虛設

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

為什么持續集成無法應用到生產環境？

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

測試的終極目標

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

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

2016-12-03 06:30 AM

原文發布于微信公眾號 -?Netkiller（netkiller-ebook）

原文發表時間：2016-12-05

轉載鏈接：https://cloud.tencent.com/developer/article/1051411

轉載于:https://www.cnblogs.com/finer/p/8526353.html

總結

以上是生活随笔為你收集整理的打破软件自动化测试的格局的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。