軟測自動化之矛與盾

2021-09-30 23:38:18 字數 1207 閱讀 7225

相比於之前的全手工測試,現在的測試無疑自動化的多,回首看頗有封建社會過渡到資本主義社會之感。已經「自動化」了好幾個月了,一直想總結總結這種由鳥槍更換成的大炮到底給我們測試帶來多少生產力的提高,它適用什麼場景,它對於測試的最終目的有多少幫助,又會帶來多大的影響?

其實說起來聽可笑的,我對於自動化測試起初還是挺牴觸的,總覺得自動化了之後會有一些很「隱藏」的缺陷會被放掉,而且針對小作坊式的軟體生產,不需要對每個軟體模組都進行全方位測試。往往將前後端一整合,發布乙個包,部署給環境,測試就好了,沒有那麼多的要求。可是當軟體進入批量和大規模之後,各個模組之間的介面通訊就變得異常重要,每個環節首先必須保證自己是沒有問題的才能整合進環境,還有軟體開發都是這樣,先後臺再前端,往往到了專案後期,才整合ui聯調,此時後端的功能和介面都必須已經測試過保證沒有大問題的情況下進行的;再者軟體後台的程式都屬於專案前期開發,更多的不確定和更多的缺陷等著測試人員去發掘。在這種情況下手工測試的缺點就暴露出來,一是不能及時提供有效的頁面給予手工測試,二是不停的**變更讓手工測試已經很難滿足復用的需要,這時候的自動化就猶顯重要。

囉嗦了一堆,其實就是想說自動化在軟體進入規模化生產之後測試人員的必經之路,可以大大的提公升測試效率和節省測試時間,讓這個軟體過程在最短的時間內完成。

前面提到了自動化測試適用的測試過程,現在結合幾個月測試過程簡單的談談自動化的優缺點,共享資源。

自動化適用的用例程度最好的就是引數值校驗的用例了,對於自動化指令碼來說,無論是指令碼語言還是高階語言都可以採用乙個模板,就是乙個套子,每次使用的時候只需要更換傳遞的引數即可。這種測試,同樣基於最基本的等價類邊界值的用例劃分,測試設計的基本思想,自動化同樣適用。

其實對於引數值用例校驗本身,其整合在功能模組測試之中,每個用例都最原始功能模組的一部分,軟體的程式就是這樣,我們測試每個功能模組是否有缺陷也就是靠傳遞引數檢視其返回是否達到期望結果。ps:不能向拆開汽車或者x光檢查身體那樣…………

自動化測試無法比手工測試發揮更好的地方就是執行使用者級用例的時候,具體到執行的時候就是介面測試和使用者場景測試,其實這兩種測試有交集的,都已直接和使用者打交道為主,因為是人,所以自動化即使執行通過不代表易用性等等方面達到要求,還是要具體使用情況。

自動化測試適用前期沒有頁面、需要驗證程式功能模組的情況,不但能夠盡早的發現問題,而且自動化本身的復用性也讓後期的回歸測試和冒煙測試變得效率十足。對於測試前端頁面和使用者體驗性測試,不建議使用,因為自動化指令碼編寫和除錯本身就很耗時,保證指令碼的正確性也需要費些周折,測試指令碼執行完成後還需要測易用性測試,時間上需要花費的更多。

robot framework 介面自動化測試

介面測試比ui測試更有價值,如果專案時間緊張,測試介面更好一些,但每次都頻繁的手工填寫介面進行測試也浪費時間,下面給大家介紹一下很好的自動化測試框架robot framework,並且做介面自動化測試事半功倍。其返回值驗證和與資料庫連線進行增刪改查很方便,邏輯也很嚴謹,如果公司沒有造輪子推薦這麼做。...

Robotframework 介面自動化測試

1.目的 1 以雲平台為例 實現註冊 登入 更新apikey 新增專案 新增裝置 新增感測器 新增執行器 感測器每隔3s上報一次資料 1分鐘後與雲平台主動斷開連線的介面自動化測試。2 斷言每條用例是否執行成功。3 程式不管執行多少次都不報錯。2.robotframework環境搭建 1 安裝pyth...

python requests介面自動化測試 一

python requests環境部署 1.安裝python,配置系統環境變數 4.安裝requests庫 pip install requests 在進行介面自動化測試時,常用到的幾個requests庫方法。如下 get 不帶引數的請求 n requests.get 帶引數的請求 引數是以字典的形...