SoapUI實踐:自動化測試、壓力測試、持續整合
因為專案的原因,前段時間研究並使用了 SoapUI 測試工具進行自測開發的 api。下面將研究的成果展示給大家,希望對需要的人有所幫助。
SoapUI 是什麼?
SoapUI 是一個開源測試工具,通過 soap/http 來檢查、呼叫、實現 Web Service 的功能/負載/符合性測試。該工具既可作為一個單獨的測試軟體使用,也可利用外掛整合到 Eclipse,maven2.X,Netbeans 和 intellij 中使用。
SoapUI 的安裝
下載地址,最好下載最新版本安裝包,因為 SoapUI 是基於 java 開發的測試工具,3.0 以前版本的安裝包沒有整合 JRE,這樣就得自己安裝和配置 java 執行環境了。
SoapUI 的使用
1. 在主介面 File 選單,點選“New REST Project”,填寫你想要測試的url,根據我們的專案 Teacher Site 中的 url 舉例:https://teacher-test.grapecitydev.com:
參照下圖需要在 Resource 輸入框輸入 /Login/Login 路由,並在 Params 中輸入登入時需要的查詢引數 accountName 和 password。
2. 點選綠色按鈕,SoapUI 傳送登入請求,可以在右側框中看到登入請求返回的結果。
根據 Teacher site 專案的業務需求,傳送 Login 請求完成後還得傳送 SchoolItemChange 介面才會返回使用者登入成功後認證的 Token,如下圖中 Set-Cookie 的值將會在下一個 GetOverview 介面的請求頭中 Cookie 屬性使用:
3. 接下來的第三個請求 GetOverview 如下圖,在 Header 框中新增 Cookie 屬性,值就是上一個請求 SchoolItemChange 返回的 Set-Cookie 值:
自動化測試
其實以上三個介面的呼叫,只是簡單的測試介面是否呼叫正常,如果想要對三個介面的呼叫進行自動化測試,請看下面的分解:
1. 右鍵每一個介面下的 Request 請求,如圖所示,選擇”Add TestCase”項,依次為以上三個介面設定 Test Case,在 TestSteps 下分別有 Login,SchoolItemChange,GetOverview 三個 TestCases。
2. 大家有沒有發現,在 Test Steps 下多了個 Set Cookie 項,這是幹什麼的呢?
這是通過 Groovy Script 語法,獲取上一個請求的返回值(此處是獲取 SchoolItemChange 介面的返回值”Set-Cookie”),並將”Set-Cookie”屬性值賦予下一個請求 GetOverview 的請求頭 Cookie 中,是不是和第2,3條很應景啊?!這樣就很好的解決了介面自動化測試,不用複製貼上請求之間依賴的返回值。
3. 接下來,就要為測試的介面新增 Assertion 斷言,點選左下角的,彈出 Add Assertion 對話方塊,根據斷言註解,選擇需要的測試點,例如 Response SLA 表示請求傳送後期望的響應時間:
Contains Assertion 則表示請求返回的字串中包含指定的字串。此斷言適用對比的內容不超過65535個字元,因為 Soapui 基於 java 語言編寫,這是 jvm 支援的最大字元個數:
4. 為解決上述不能超過65535個字元的問題,則需要為介面新增 Script Assertion,如下程式碼,表示將本地檔案 GetOverview 01.txt 中的內容與請求返回中 HtmlOfPartialView 屬性的值進行對比,判斷兩者內容是否相等:
5. 雙擊 Test Case,出現如下圖,點選按鈕,或者選中 Login 右鍵選擇”Run from here”,則依次執行 Test Steps 步驟,如圖所示,出現紅色背景 Failed 字樣,檢視右下角 TestCase Log 框,可以看出是由於 Step 4 GetOverview 介面請求的響應時間 1272ms 大於斷言中設定的時間 500ms:
傳送郵件功能
當你希望某個介面請求的結果以郵件方式通知給你時,如下圖所示,右鍵 Test Steps -> Add Step -> Groovy Script,新增 Send Email 指令碼,其中 Username 和 Password 分別是公司郵件伺服器的賬戶和密碼,Internet Address 即為接收的郵箱地址。
”${teacher-test#TestCase#Getoverview#Response}”的順序依次為
Test Suite name # Test Case name # Test Step name # Response:
壓力測試
以上是功能性測試,接下來是壓力測試,右鍵 Load Tests 建立測試用例,
Limit:60 即為壓力測試的時間 60s,Thread 表示多執行緒,可以同時執行5個執行緒,Test Delay * Radom,表示隨機延遲的時間數。
min 表示最小響應時間,max 表示最大響應時間,avg 為平均響應時間,last 表示上一次請求響應時間,cnt 表示請求數,tps 表示每秒處理請求數,bps 表示吞吐率,rat 表示錯誤率。
右鍵可以為請求新增斷言,Max Errors 設定最大的錯誤數,Step Average 設定期望的平均時間,其他的依次類推:
如下圖,可以選擇不同策略的負載和效能測試:
最常用的是簡單策略(Simple),如果你想執行功能測試,並想在10秒內延遲5個執行緒,則 Threads 設定為5,延遲 1000s,隨機延遲比率0.5(即將導致延誤5至10秒)。
方差策略(Variance),Threads 為方差的執行緒數量,Interval 為間隔設定所需的值。例如設定20個執行緒,間隔60和方差0.8,執行緒的數量將在第一個15秒從20增加到36,然後又減少到20,45秒後繼續減少到4個執行緒,最後等到60秒時返回到初始值20。在統計圖中我們很容易遵循這個方差:
線性策略(Thread),從一個執行緒到另一個執行緒的數量的執行。它的主要功能是確定某些統計資料變化或事件發生時的水平,例如設定開始和結束執行緒值(例如1 - 10),並設定持續時間(此例中每個執行緒至少30秒)獲得準確的測量資料:
持續整合
在UI介面進行持續整合:右鍵專案名稱 REST Project 1 -> 選擇 Launch TestRunner,出現如下圖,在 Basic Tab 頁選擇 TestRunner 安裝路徑:
在 Reports Tab 頁選擇報告輸出資料夾:
點選 Launch 按鈕,自動執行測試專案。
通過執行命令進行持續整合,以管理員身份開啟 Command Prompt 對話方塊,執行如下命令:
testrunner.bat -s'teacher-test' -cLogin -r -j -f'D:\Trivals\SoapUI\Logs' D:\Trivals\SoapUI\REST-Project-1-project.xml
該命令列的各個引數含義如下:
- s : The TestSuite to run, used to narrow down the tests to run
- c : The TestCase to run, used to narrow down the tests to run
- r : Turns on printing of a small summary report (see below)
- j : Turns on exporting of JUnit-compatible reports, see below
- f : Specifies the root folder to which test results should be exported
其他更多的引數設定,請參考 SoapUI 官網地址:
https://www.soapui.org/test-automation/running-functional-tests.html
本文概要介紹了 SoapUI 工具的基本使用方法,也歡迎感興趣的讀者留言補充 SoapUI 的更多功能使用方法,大家共同學習進步。
轉載請註明出自:葡萄城控制元件
葡萄城年末福利火熱放送中
凡在 2017 年 12 月 31 日之前,購買葡萄城控制元件團隊授權和企業授權的使用者,不僅可以享受到優惠的價格,還可獲贈葡萄城技術專家根據客戶專案需求提供的定製培訓服務。老客戶推薦新客戶成單,也將獲得“客戶推薦雙重感恩禮”。
瞭解更多:http://www.gcpowertools.com.cn/order/specialoffers.htm
關於葡萄城
葡萄城成立於1980年,是全球最大的控制元件提供商,世界領先的企業應用定製工具、企業報表和商業智慧解決方案提供商,為超過75%的全球財富500強企業提供服務。葡萄城於1988年在中國設立研發中心,在全球化產品的研發過程中,不斷適應中國市場的本地需求,併為軟體企業和各行業的資訊化提供優秀的軟體工具和諮詢服務。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28298702/viewspace-2147796/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 思考如何將自動化測試加入持續整合中
- Jenkins+Python自動化測試持續整合詳細教程JenkinsPython
- jenkins+ant+jmeter介面自動化的持續整合測試框架JenkinsJMeter框架
- 新夢想幹貨分享——持續整合的自動化測試
- 知物由學 | SDK API自動化測試與持續整合API
- Docker與自動化測試及其測試實踐Docker
- .net持續整合測試篇之Nunit引數化測試
- API自動化測試實踐API
- .netcore持續整合測試篇之測試方法改造NetCore
- 壓力測試redis redis-benchmark 優化實踐Redis優化
- 自動化測試的最佳實踐
- 前端自動化混沌測試實踐前端
- UI自動化測試工程實踐UI
- 自動化測試實踐總結
- Jenkins上實現Python + Jenkins + Allure Report 介面自動化測試持續整合,並生成allure-report測試報告JenkinsPython測試報告
- 持續測試跟自動化測試的這些區別你知道嗎?
- Linux 核心的持續整合測試Linux
- APP壓力測試6--monkeyrunner實踐APP
- 提升龍蜥核心測試能力!探究持續性模糊測試最佳化實踐
- 介面自動化測試工程實踐分享
- 使用 Xcode Server 持續整合 & 打包測試XCodeServer
- 壓力測試
- 自動化測試系列 —— UI自動化測試UI
- 自動化測試:Monkey工具實踐應用~
- 測試自動化中遵循的最佳實踐
- 在持續測試中使用哪種測試?談談DevOps在測試策略中的實踐!dev
- (一)效能測試(壓力測試、負載測試)負載
- 介面效能測試 —— Jmeter併發與持續性壓測JMeter
- 介面壓測實踐-壓力測試常見引數解釋說明
- 全鏈路壓測自動化實踐
- 聊聊持續測試
- ET-ci — 全自動軟體測試排程(持續整合)平臺
- sysbench 壓力測試
- MACOSXApacheab壓力測試MacApache
- ORACLE壓力測試Oracle
- laravel壓力測試Laravel
- 軟體測試:自動化測試
- 介面自動化測試世界裡的“身份證”—測試工具Jmeter實踐篇JMeter
- 【自動化測試入門】自動化測試思維