04 jenkins接口自動化測試(接口自動化測試環境搭建jmeter+ant+git+jenkins)

熟悉，還需要知道如何通過將某一測試工具生成的某種格式的測試報告集成在Jenkins上以方便一鍵獲取測試報告。

像cucumber的測試報告插件：

像Allure的測試報告插件：

有了這些插件的輔助，在流水線上就一鍵可得測試報告，為‘質量團隊負責’提供了很好的契機。

3） Pipeline as Code, 想要集成測試到流水線，不可避免是需要一些DevOps相關知識的

也許項目的需求是如何通過Jenkinsfile 并行運行各種測試，也許是通過Jenkinsfile傳遞測試相關參數以為云上運行測試所用，還也許你需要在Jenkinsfile里添加調試信息用以線上調試，等等。

云上運行，我們還要學會如何在一個slave 上優雅地管理運行測試的容器，不出現容器占用，slave內存不足，測試失敗之后報告不可得等等問題。

所以只會自動化工具不夠，只有自動化測試也不夠。如果你們團隊開發們沒有DevOps的經驗，或者他們忙于特性開發，上線沖刺，那么QA必須對Docker，Kuber買粉絲es 基本命令和用法有些了解。QA就是一個不分前后端，不挑技術棧，需要持續不斷學習的角色。

會自動化工具算是有了織網的道具，有自動化測試資產算是編出了能撈魚的網，而持續測試才能真正地實現持續交付，才算是把一張張過濾不同缺陷的網放置于了不斷提交變更的交付之流中。

只有網而無法至于河里，或者不知道于何處放置，那就只能站于岸邊時時撒網捕魚，不夠及時，也不算釋放了捕魚人 （QA和團隊) 。

我們期望的是，各種不同的網 （自動化測試資產） ，置于不同的河段（ 軟件產品不同層級：函數級別？組件級別？接口級別？系統級別？） ，過濾不同的魚 （缺陷） ，而不管是誰 （團隊的所有角色） 都可以去確認有沒有撈著魚 （測試掛了嗎？為什么掛？我們對目前的變更有足夠的信心嗎？） ，也需要所有人時時確認我們的漁網是不是破了？ （測試覆蓋率不夠？斷言不嚴謹？測試用例過時？） 。

軟件交付是一項團隊工作，即便自動化測試也一樣需要全員協作。

文/ThoughtWorks郭泰瑜

軟件測試難不難學?

必須明確一點軟件測試不是很難，但是也不是說誰都能夠學習，也不是說會使用測試工具，點點點就行的。根據企業現在軟件測試崗位要求，要求測試人員能熟練掌握功能測試、接口測試、性能測試、自動化測試、安全測試等技術。

功能測試就是檢驗產品的模塊是否有問題，這部分入門比較簡單，零基礎就能學會。主要學習計算機基礎、軟件生命周期；測試理論、測試方法、測試用例，缺陷生命周期；版本管理工具、測試管理工具、Office、流程圖。Windows Server、Linux、數據庫等。

接口測試的話就是測試接口的數據傳輸有沒有問題。需要掌握接口概念、計算機網絡、網絡協議、編程語言、Fiddler、HttpWatch、WireShark、Postman、JMeter、SoapUI、瀏覽器內置工具等。

性能測試就是檢測在一定負載情況下，產品會不會出現問題，穩定性如何等。需要掌握性能測試理論、分類、方法、性能測試工具（Loadrunner、Jmeter)、性能調優、數據庫調優、分析報告等。

自動化測試這塊兒是重點，要求能夠使用或編寫工具，實現對一個項目的web自動化或移動自動化測試任務。會學習Web前端基礎、編程語言、Web自動化測試框架Selenium、QTP、APP自動化測試框架工具Appium、Monkey等。

軟件測試相比開發類課程，涉及的代碼更少，所以不是很難學。因此越來越多的應屆畢業生，零基礎轉行的，非計算機專業的人想進入軟件測試這個行業。

「自動化測試」是否有必要做自動化測試？

目錄

一、前言

二、自動化目的

三、自動化分類

四、自動化實現

一、前言

在一些測試交流群經常會看到有小伙伴在問，"怎么做自動化測試？學習自動化測試有什么資料嗎？自動化測試是不是很牛逼？" ，甚至有些言論是"不會自動化的測試人員，真的要被淘汰了嗎？"

不得不說一堆流量號主抓住大眾心理，點進去的必然是賣課廣告，或者是關注買粉絲買粉絲領取測試資料大禮包。

實話實說，我之前也有同樣的疑問，甚至帶著擔憂。每次又不甘心得領著測試資料大禮包......

當然，隨著自己的認知不斷擴大，自己的一套測試體系建設不斷完善，于是這些擔憂逐漸的消失。每項技術引用都要看適用場景，是否適合自己的團隊，因地制宜才能發揮其最大的價值。

因此，我想通過這篇文章來分享下我對于自動化測試的理解。

二、自動化目的

自動化工作可以節省很多人工操作成本，減少人工重復性操作，提高整個團隊的研發效率。但是如果搭建自動化體系需要耗費很長時間，投入很多人力資源，但是用戶只要2-3分鐘的手動工作就能解決，而且這個操作并不頻繁，又或者需要自動化操作的平臺變更迭代非常快并且沒有規律，自動化工具在后面類似累活的跟著。那么自動化還是有必要嗎？

我之前在的團隊，造測試數據特別困難，嚴重影響了整個研發效率，但是當時也沒有一個好的解決辦法，后來基礎研發組做了一個造數平臺，這個平臺需要自己去配置各種字段，并且梳理出各個表字段的關聯，從頭到尾一個一個去構建場景，一不小心就配置錯誤，看著提示你也找不到原因的那種。這給造數過程中又添了一個攔路虎，給本不充裕的測試時間，又耗時一把。

如果能在做執行任務前評估任務的投入和收益，那么是不是就能更加合理的開展這項任務。那么自動化測試的投入和收益是怎樣的呢？

投入：通過測試人員借助腳本或者工具實現自動化，維護自動化平臺。

收益：提高測試效率，提升測試人員的成長。

自動化測試真的提高測試效率嗎？真的可以提升測試人員的成長嗎？針對后者，我認為是有的。接下來我們就來聊聊自動化測試是否提高測試效率。

三、自動化分類

自動化一般分為接口自動化和UI自動化，其中UI自動化又分為Web UI自動化和App UI自動化，按照我的理解還應加上部署自動化。

接下來我將針對這四種自動化的場景做一個介紹。因為我對于UI自動化不是很熟悉，我認為投入產出比不是很高，主要還是因為我沒咋接觸過，所以后面僅做簡單介紹，重點講解接口自動化和部署自動化。

四、自動化實現

4.1、接口自動化

接口

接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞過程，以及系統間的相互邏輯依賴關系等。

流程

填寫接口，入參，對出參進行斷言，每天定時構建，輸出測試報告。

入參覆蓋范圍：必選，可選，有/無/null，類型，數值大小/數值范圍，特殊字符；

出參：json，data；

接口關聯：接口之間的依賴，數據傳遞；

斷言：對響應做核驗，可以對狀態碼或者msg做校驗。

優點

接口測試可以更快的發現服務端問題；

接口測試相對容易實現自動化持續集成；

接口測試相對于比單元測試比較貼近業務場景；

技術選型

1、MeterSphere

MeterSphere 是一站式測試平臺，涵蓋測試跟蹤、接口測試、性能測試、 團隊協作等功能，全面兼容 JMeter、Postman、Swagger 等開源、主流標準。

MeterSphere是一個功能交全的平臺，并且是開源的，對于免費版就足夠小團隊使用了，使用門檻相對來說較低，對于技術能力要求不高，所以是一個不錯的選擇。MeterShpre使用的技術棧是SpringBoot+vue，以及一些中間件，也可以在此基礎上進行二次開發。

2、Python

通過Python來做接口自動化的話，常用組件有：執行庫Requests，斷言庫unittest，測試報告HTMLTestRunner，通過持續集成Jenkins做定時構建。

框架思想：封裝，數據驅動。

使用Python的話則需要掌握一定的代碼能力，當然這個對個人技能的提升是很有幫助的，但是如果在時間比較緊迫的并且沒有足夠的技術功底情況下，還是比較推薦MeterSphere的。

4.2、部署自動化

部署

部署就是將源代碼編譯成可運行軟件包，比如jar包或者war包，并且將軟件包放到目標環境，將軟件包運行起來，并且能夠被客戶端調用。

流程

通過遠程倉庫拉取代碼，前端編譯，后端編譯，下發軟件包到目標機器，重啟服務，啟動失敗

很赞哦!（461）