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

2021-08-28 01:51:47 字數 2810 閱讀 6571

自動化測試僅僅被認為是替代人工,所以我們看到很多企業實施自動化測試僅僅是將現有的 test case 轉換成自動化指令碼。

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

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

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

隨著技術發展,軟體的多樣性,測試已經不侷限於基於cs結構的gui測試, 基於bs瀏覽器web ui測試。例如目前的安卓系統,蘋果ios系統,微軟的 windows mobile 系統等等也加入到自動化測試領域。

應用軟體也越來越複雜,例如:

分層的變化:介面層,介面層,業務邏輯層,實體模型層

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

儲存的變化:關係型資料庫,非關係型資料庫,快取資料庫,搜尋引擎資料庫

從下面的金字塔架構可以看出軟體展示給使用者的只有ui介面層

/\

/ \

/ ui \

/------\

/ api \

/----------\

/ service \

/--------------\

/ component \

/------------------\

/ database \

/______________________\

上面是軟體的分層,乙個軟體經過部署後結構將會更複雜。

/\

/ \

/cdn \

/------\

/ web ser\

/----------\

/--------------\

/ message queue \

/------------------\

/ cache|searchengine \

/ database| nosql \

/________________________\

我們測試要涵蓋:

cdn測試,網域名稱解析測試,

web ui測試,包括html,ajax

api 伺服器測試,api 是非人機互動介面,它是通過特定協議與api伺服器互動通訊。

**單元測試

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

安全測試,介面安全,認證,許可權

注入測試,js注入,sql 注入,shell 注入

快取測試,命中率測試,包括cdn,web伺服器,快取伺服器,搜尋引擎

壓力測試,健壯性測試

擴充套件性測試,水平擴充套件測試,垂直擴充套件測試

高可用測試,集群測試

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

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

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

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

首先準備測試環境,如單機測試要考慮cpu速度,磁碟io速度,raid卡的速度,raid卡快取大小,記憶體速度,pci—e匯流排速度,甚至會涉及多對稱cpu相關配置,記憶體與cpu通道的問題......等等

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

\------------------/

\ web server /

\ cache / mq /

\ database /

\ disk io/

\ /

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

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

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

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

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

測試目的不是為了得出乙個結果,告訴開發人員你的軟體能支撐***併發,而是在我們測試中監控每項操作,計算出每個功能所用的時間,分析出效能的瓶頸,指導開發人員改進軟體。

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

外部監控是最容易實現的,有成熟的工具以及解決方案,cpu,記憶體,磁碟io,網路流量等等。

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

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

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

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

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

2016-12-03 06:30 am

軟體測試自動化

只有當系統的介面元素不會頻繁的變化 系統功能基本穩定,已經通過一至兩輪的手工測試,確定系統不會存在重大缺陷時,才可以考慮自動化的實施。使用自動化測試工具代替手工完成一些測試任務,現在國內主流的測試工具是loadrunner 和qtp。lr 效能測試工具 和qtp 自動化測試工具 的區別 1 lr 基...

軟體測試之自動化測試

自動化測試的優勢 能夠極大地提公升測試的效率,測試人員可以迅速地在指定平台部署測試指令碼且對相應功能進行測試。弱化 了軟體測試人員個體差異對測試結果的影響。提高整個測試團隊的技能水平。自動化測試的缺陷 自動化測試的缺陷在於 總是按照既定的流程往下走,不能像人一樣隨機應變。一旦功能發生變動,就需要重新...

軟體自動化測試之我見

摘要 作者以自己多年在測試領域尤其是在自動化測試中的經驗,從管理層面講述了自動化測試相對於手動測試的優勢 並且從不同的方面論述了目前大家對於自動化測試的錯誤認識,同時讓大家充分意識到推行自動化過程中會面臨的困難。關健詞 自動化測試 手動測試 如今自動化測試以其執行速度快,結果反饋迅速的最大優點獲得了...