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

自動化測試的誤區(qū)

自動化測試僅僅被認(rèn)為是替代人工，所以我們看到很多企業(yè)實施自動化測試僅僅是將現(xiàn)有的 Test Case 轉(zhuǎn)換成自動化腳本。

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

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

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

分層與部署帶來的問題

隨著技術(shù)發(fā)展，軟件的多樣性，測試已經(jīng)不局限于基于CS結(jié)構(gòu)的GUI測試, 基于BS瀏覽器WEB UI測試。例如目前的安卓系統(tǒng)，蘋果IOS系統(tǒng)，微軟的 Windows Mobile 系統(tǒng)等等也加入到自動化測試領(lǐng)域。

應(yīng)用軟件也越來越復(fù)雜，例如：

分層的變化：界面層，接口曾，業(yè)務(wù)邏輯曾，實體模型層

部署的變化：從單機運行到雙機熱備份再到負(fù)載均衡，最近進(jìn)化到分布式系統(tǒng)。

存儲的變化：關(guān)系型數(shù)據(jù)庫，非關(guān)系型數(shù)據(jù)庫，緩存數(shù)據(jù)庫，搜索引擎數(shù)據(jù)庫

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

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

上面是軟件的分層，一個軟件經(jīng)過部署后結(jié)構(gòu)將會更復(fù)雜。

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

就WEB應(yīng)用測試而言，涉及的內(nèi)容就太廣泛了，從瀏覽器->WEB服務(wù)器->APP服務(wù)器->緩存->數(shù)據(jù)庫，中間會經(jīng)過各種代理，負(fù)載均衡，分布式文件系統(tǒng)等等。

我們測試要涵蓋：

CDN測試，域名解析測試，

WEB UI測試，包括HTML,Ajax

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

代碼單元測試

配置測試，配置管理過程中配置變更后的測試，含系統(tǒng)與應(yīng)用

安全測試，接口安全，認(rèn)證，權(quán)限

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

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

壓力測試，健壯性測試

擴(kuò)展性測試，水平擴(kuò)展測試，垂直擴(kuò)展測試

高可用測試，集群測試

壓力測試存在的問題

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

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

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

壓力測試有兩個重點，一是壓力測試環(huán)境的建設(shè)，二是壓力測試順序。

壓力測試環(huán)境

壓力測試無論是單機還是網(wǎng)絡(luò)，都需要一個好的壓力測試環(huán)境，例如網(wǎng)絡(luò)好比高速公路，如果公路成為瓶頸，你能測試出準(zhǔn)確的數(shù)據(jù)嗎？

首先準(zhǔn)備測試環(huán)境，如單機測試要考慮CPU速度，磁盤IO速度，RAID卡的速度，RAID卡緩存大小，內(nèi)存速度，PCI—E總線速度，甚至?xí)婕岸鄬ΨQCPU相關(guān)配置，內(nèi)存與CPU通道的問題......等等

如果是測試分布式系統(tǒng)，除了上述單節(jié)點的注意事項，還要考慮到路由器/防火墻的包轉(zhuǎn)發(fā)與連接數(shù)限制，交換機的背板帶寬以及吞吐能力，負(fù)載均衡器的轉(zhuǎn)發(fā)能力。

操作系統(tǒng)要考慮內(nèi)核參數(shù)優(yōu)化，TCP/IP棧優(yōu)化，各種服務(wù)器的配置。

測試順序

壓力測試順序的切入點非常重要，測試順序上多數(shù)人是從UI（人機界面）切入，即由UI驅(qū)動業(yè)務(wù)邏輯，這種測試順序是錯誤的，例如用戶->瀏覽器->WEB服務(wù)器->APP服務(wù)器->緩存->數(shù)據(jù)庫等等，這就帶來很多問題。

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

軟件的性能平靜通常是沙漏型的，最大的瓶頸莫過于數(shù)據(jù)庫，其他服務(wù)器的瓶頸我們都能從架構(gòu)的角度去解決性能問題。

所有我們應(yīng)該先從數(shù)據(jù)庫測試，首先確認(rèn)數(shù)據(jù)庫的配置優(yōu)化是否能達(dá)到我們預(yù)期值。然后是緩存，消息隊列，搜索引擎等等.....

至此我們已經(jīng)知道數(shù)據(jù)庫，緩存，消息隊列，搜索引擎不會成為我們壓力測試中的瓶頸。接下就可以測試應(yīng)用服務(wù)器和應(yīng)用軟件了。

如果你的測試格局能夠放大一點要考慮的遠(yuǎn)不止上述那些。 你還需考慮硬件，網(wǎng)絡(luò)，操作內(nèi)核參數(shù)優(yōu)化，TCP/IP棧優(yōu)化，驗證運維配置是否能滿足我們需求等等.....。

瓶頸分析

我們需要有一套監(jiān)控解決方案，能夠監(jiān)控到硬件的性能，軟件的性能。

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

監(jiān)控分為外部監(jiān)控與內(nèi)部監(jiān)控。

外部監(jiān)控是最容易實現(xiàn)的，有成熟的工具以及解決方案，CPU,內(nèi)存，磁盤IO，網(wǎng)絡(luò)流量等等。

內(nèi)部監(jiān)控是指軟件運行加載到內(nèi)存中之后的變化狀態(tài)，例如內(nèi)存地址，變量，函數(shù)調(diào)用，動態(tài)鏈接庫載入，打開文件句柄，Socket地址和數(shù)據(jù)包等等。

指導(dǎo)開發(fā)

通過數(shù)據(jù)，圖表，快速定位軟件存在的問題點，指導(dǎo)開發(fā)完成軟件的改進(jìn)

持續(xù)集成形同虛設(shè)

持續(xù)集成，自動化構(gòu)建幾乎么個測試團(tuán)隊都會實施，但實際境況并不理想，僅僅停留在工具配置的階段。幾乎沒有人在生產(chǎn)環(huán)境上使用自動化構(gòu)建。

為什么持續(xù)集成無法應(yīng)用到生產(chǎn)環(huán)境？

（待續(xù)，敬請關(guān)注作者微信公眾號，現(xiàn)在已經(jīng)是早上6點中了，要去睡覺了）

測試的終極目標(biāo)

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

測試者應(yīng)該站在更高的角度看問題，測試者是有能力指導(dǎo)開發(fā)人員，改善軟件的性能，健壯性，安全性，以及影響軟件架構(gòu)的設(shè)計。 測試者需要有廣泛的跨界知識支撐，要不斷學(xué)習(xí)提高，打破現(xiàn)有格局。

2016-12-03 06:30 AM

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

原文發(fā)表時間：2016-12-05

轉(zhuǎn)載鏈接：https://cloud.tencent.com/developer/article/1051411

轉(zhuǎn)載于:https://www.cnblogs.com/finer/p/8526353.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。