自動化測試實踐總結

　　引言
　　內容已經有了，但是標題想了很久，最終還是決定用這個。簡單清楚明瞭——總結一場失敗的自動化測試案例。

　　文筆欠佳，如有閱讀不適，請見諒！

　　自動化測試
　　如今，軟體測試行業裡，人人都在講自動化測試，人人都在做自動化測試。如果誰說自己不會自動化測試，都不好意思去面試。現在各大公司招聘資訊都是必須會自動化測試，一部分公司招人只招測試開發。甚至有些大頭公司都不分測試與開發兩個職位。

　　所以，絕大部分公司都有人在搞自動化測試，甚至有一部分公司有一套成熟的自動化測試體系。你可以把它看成標準化流水線，類似現在講的 Devops。

　　這裡，我講的當然是我在公司的一次自動化測試體會。由於保密協議，這裡簡單介紹：

　　背景
　　公司是一線大廠的子公司，也可以稱為合作伙伴。 類似華為旗下的榮耀。公司去年年初，由於業務越來越繁多，所以人員也是瘋狂擴充套件，所以迭代相當頻繁，標準是一週一個迭代，緊急小迭代，也有過兩三天的時候。有人會說怎麼做到的?

　　拼人啊，加班啊。

　　測試團隊
　　先說我們測試團隊吧，擴充套件後測試團隊人數大概是 40 左右，其中職位有自動化測試，測試開發，效能測試，安全測試。唯獨沒有測試工程師。因為公司不招單純的功能測試。

　　有人可能會質疑，那業務測試誰來做？

　　在這裡，我們公司業務測試全職測是自動化測試工程師，他們兼任業務測試和所負責業務中的一部分自動化測試需求。

　　而測試開發是專職於測試體系建設中。效能和安全測試有時候會支援業務測試，但是他們也是專職於效能和安全方面的測試，面向全公司所有系統。

　　測試體系發展
　　起初測試團隊是沒有對測試技術體系思考，大家做自動化測試都是各自做各自負責的業務系統那一塊，用的工具與方法各有千秋，程式語言方面大致分兩派 java 和 python。

　　這種分散的自動化測試帶來的弊端不限於：

　　1、資料無法視覺化；

　　2、指令碼維護難；

　　3、增加了學習成本；

　　4、易用性、移植性差；

　　5、無法統一管理；

　　...

　　...

　　這種分散的，小作坊形式的很快就不適應快速迭代的需求和市場變化。最核心的一點是，部門領導無法向老闆展示資料。通俗的來講，就是無法向領導展示我們測試團隊存在的價值。

　　嘴巴說，誰都會。但是，領導想看資料，那麼平臺是唯一秀出測試團隊工作中沉澱下來的資料的途徑。這樣有了資料，團隊的 KPI 就出來了。

　　你說你天天在測試，天天在做自動化測試，做了多少，效果如何。領導不可能一個個找你們去統計，去檢視。不管你指令碼寫的多優秀，框架設計得多麼出神入化。終究沒有所謂的正規化平臺好。

　　然後，就這麼定了。幾位測試開發大神，在領導的安排下，經過多番討論的設計方案，寫了一套後臺是 Java 的自動化測試平臺。這裡說明一下，只所以是 Java，因為公司 99% 的系統是 Java 開發。

　　測試平臺
　　時至今日，平臺已經完善得差不多了，該有的都有，沒有的也有了。簡單說一下測試平臺的主要功能：

　　1、介面測試；

　　2、UI 測試 (app 和 web)；

　　3、效能測試；

　　4、流量監控；

　　5、介面覆蓋率統計；

　　6、安全測試；

　　7、程式碼質量掃描；

　　8、生產釋出卡點；

　　....

　　主流的功能就是這些，其他小功能我就不一一列舉了。這套平臺已經整合了軟體測試中絕大部分的測試技術在裡面；可以算得上一套標準的流水線了。

　　以前會自動化測試會覺得高大上，現在平臺搭建起來了，並且已經維護了 1 萬左右的測試用例在上面了。是不是更加牛逼了？

　　答案：我不知道平臺搭建後是否真正牛逼了，但是它的建設至少對測試團隊的影響不限於如下幾點：

　　1、增加了團隊的技術含量 (至少領導不會認為我們只會點點點)；

　　2、提高了團隊的作戰能力；

　　3、提高了測試效率（因人而異）；

　　4、降低了成本 (待查)；

　　5、提高了產品質量 (待查)；

　　6、降低了學習自動化的難度；

　　...

　　上面只列了六點，對於我們測試團隊的影響，也算人們口中常討論的自動化測試的意義。其實還有很多，這裡不一一複述了。

　　自動化測試現狀
　　平臺是完善好了，前面說了，平臺已經維護了 1 萬左右的介面測試用例，其他資料我暫時沒看。顯然平臺健壯性是毋庸置疑的，易用性也很好，入門簡單。

　　那麼問題來了，對於迭代頻繁的專案，我們在什麼時候去編寫介面測試用例呢？

　　這種問題，絕大多數的人都知道，常規的回答不限於這些：

　　1、介面測試需求評審了 (絕大多數是沒有)；

　　2、什麼開發介面開發好了，開發提供了介面文件之類的，我們就可以去平臺維護介面測試用例了；

　　3、開發自測透過，程式碼提交；

　　...

　　...

　　這些回答都很標準，很理想。但是，你有沒有想過，現實是很骨感的，就是會出現不限於如下情形：

　　現狀一：

　　版本變化得讓你根本沒時間維護的時候，你只有加班抽時間來維護，而且這種情況只有在領導發話了，大家才會去維護上去。有些人由於業務線確實忙，所以沒維護，有些是自己寫指令碼，根本不想維護上去。當然也有人主動的去維護。

　　針對這個現狀，領導又出必殺技，將介面測試用例設計和覆蓋率的指標定下來，並且放到 KPI 考核項裡去。

　　KPI 你們都懂，這裡就不講述它的作用了。這個大招一放，大家都自覺的去平臺上維護了。

　　現狀二：

　　現狀二就是現狀一的延伸版，就是每次版本有新增的介面後，大家為了 KPI 會主動上去維護。然後有一大部分人也僅僅上去維護這次，後面版本介面有變更，也不會花時間去更新已經維護上去的介面。

　　其中原因，有些可能是真正的忙，沒有時間。有些可能因為懶，不想去維護。總而言之，測試團隊中有一部分人是沒有去更新介面測試用例的。

　　現狀三：

　　談到自動化測試的用途時，大家都會記得其中一個是用於迴歸測試，減少人力投入到版本回歸測試中去，從而把節省出來的時間和人力，用於更多的業務測試或者其他測試中去。

　　但是，現實卻是，在版本變更中，真正去執行以前維護的介面測試用例來回歸測試的人太少了。據我觀察和了解，在短期迭代中，上個迭代維護的用例，這個迭代沒人會去跑，哪怕只用一分鐘的時間。

　　出現這種情況，一方面由於自信，太自信於覺得之前的介面沒有變動，沒必要去跑，另一方面，時間太短，又要交付測試，功能測好，直接就進入產品&業務驗收環節。就把這一步省略掉。

　　當然，還有其他很多原因，這裡不細說。結果都是一樣，沒有去維護歷史資料。

　　現狀四：

　　自從公司招進外包測試後，現在部分專案測試工作分配如下：

　　測試工程師專門負責設計用例，然後交給外包團隊來將這些用例再翻譯成測試指令碼，這樣的做法，效率不低下才怪。

　　首先外包同志不熟悉業務線，直接轉化，還是得從瞭解業務開始。

　　其次功能測試用例直接翻譯成自動化測試指令碼存在重複性勞動，同時也會出現場景遺漏，場景不可用的情況。

　　總而言之，這種做法收益大大低於投入。

　　正確的姿勢是：測試工程師自己就將測試指令碼交付出來。對於那些全棧工程師而言，最正確的姿勢是：開發人員自己就動手將測試指令碼寫出來。根據我對微軟的瞭解，微軟的 Visual Studio 團隊，就是這麼做的，他們根本就不區分開發和測試。

　　現狀五：

　　談自動化測試的時候，我們經常會講到它的優點，其中一個就是降低錯誤率，發現人工無法發現的缺陷。那麼，在這裡統計的結果，我們做介面測試真正發現的缺陷是屈指可數，鳳毛麟角的。

　　有的甚至一個都沒有。當然介面測試本身也是有侷限性的，他不可能完全代替手工去發現手工測試的缺陷。

　　這裡只講它的現狀...

　　現狀六：

　　...

　　...

　　綜上所述，還有很多現狀，我這裡不一一列舉，可以看出來，出現這種想象，一方面是由於個人原因，測試的責任和態度。

　　一方面領導要求所有專案都要做介面自動化測試，從來不評估哪些專案適合做介面自動化測試。

　　有點盲目跟風，做了自動化測試就閃光輝，而實際帶來的價值，卻是 0。

　　還有一方面，也是關鍵的一點領導對自動化測試管理方面的欠佳，光靠 KPI 來觸發是不行的。

　　失敗的背景
　　上面已經講了，目前公司自動化測試存在的普遍問題。

　　現在從我這個小團隊來講，專案要上阿里雲，就是系統上阿里雲，至於什麼原因，就不說了，涉及保密協議。

　　系統上阿里雲，當然沒有那麼簡單，所有與系統相關的服務、資料庫、中介軟體、流量等等，相對於迭代版本，這是一次比較大的變更過程。

　　然後，我們測試在裡面承擔了什麼角色呢？

　　自動化測試在這次遷移的價值會是怎樣呢？

　　失敗的經歷
　　專案上雲，當然我們測試要保證專案上雲後，所有功能都能正常使用。但是切換的那一段時間，你有多少時間去驗證所有的功能都正常呢？

　　只有兩三個小時，一年積累下來的功能，兩三個小時如何驗證完呢？

　　這個時候就是自動化測試該上場了。

　　這個專案自動化測試交給外包維護了，是在我們測試平臺上維護的，主要是維護 WebUI 功能測試用例。介面測試用例是我們幾個在維護。

　　到了那一天凌晨，大家都準備好了，準備上雲。然後驗證。

　　最後發現，沒有維護一個 WebUI 測試用例 (生產環境)。

　　臨近上雲的幾個小時前，我問他維護了多少用例，他說測試環境維護了，生產環境沒有。

　　我當時傻眼了，因為這個外包是專職安排弄 UI 自動化，用於上雲驗證。雲上 UI 前端框架和雲下前端框架是不一樣，也就是頁面元素不一樣，所以測試環境維護的用例，根本無法在生產環境使用。

　　然後我們這邊由於時間太趕了，介面測試用例還沒有更新到雲上環境的域名以及除錯好。這個失職也是在於我。

　　導致，我們這次上雲驗證，沒有跑過一個自動化相關的用例。

　　簡單來說，等於這次上雲，我們用於迴歸測試的自動化測試相關的用例及指令碼，沒有一個。

　　但是，我們投入在自動化測試的時間，差不多跟我們業務測試用例編寫的時間趨於一致。

　　投入與產出是 1 比 0 的，結果是慘不忍睹。

　　我們 4 個測試，靠著經久不衰的手法，一路閃電帶火花的點點點，來驗證系統所有功能是否在雲上正常。

　　一直驗到第二天上午人家來上班...

　　假設，我們準備充分，介面和 UI 自動化測試用例都遍歷了所有功能，我們也不至於熬了一個整整通宵，也不會這麼辛苦，這麼累。

　　失敗總結
　　經過這次專案上雲，發現了平時我們打著自動化測試的口號：降本增效，提高質量。而到了實際要用時，卻發揮不出一點作用。當然，這裡有很多原因，有個人，也有團隊管理方面的。

　　但是，拋開原因不追究，其慘痛結果，反應一個問題，自動化測試是有意義的，也有價值。

　　但是，如果你運用和管理不當，它的價值沒有發揮出來，將成為一堆廢鐵，終將百無一用。

　　試問有多少人，多少公司做的自動化測試 (那些 BAT、TMD 一線大廠裡面的測試團隊除外，畢竟技術與管理體系已經非常完善)，真正發揮了它的價值呢？

　　你們有評估自動化測試 (包括平臺) 的收益嗎？

　　如何評估的呢？

　　真正達到產出高於投入的有多少呢？

　　學習自動化測試的人越來越多，自動化測試在軟體測試中已經是人人參與的，但是，如果不真正發揮它的作用，你們做的自動化測試，包括測試平臺，可能就是：

　　1、為了體現測試團隊的技術 (面子)；

　　2、為了團隊 KPI；

　　3、自娛自樂；

　　4、為了面試，拿高薪；

　　5、安慰自己；

　　6、為了裝 13；

　　7、盲目跟風，不管有沒有價值，先要有這個東西存在；

　　...

　　...

　　綜上，也有其他動機和目的，但是，在這裡，我想說的是，做自動化測試，一定要在做之前思考不限於以下六個問題：

　　1、這個專案為什麼要做自動化測試？

　　2、什麼專案適合做？

　　3、什麼時候做？

　　4、做哪些核心業務模組？

　　5、誰來做？

　　6、如何做？如何發揮它的核心價值？

　　其實搞清楚 1,4,6 三個問題就可以了，最關鍵的是做好第六點，我想你做出來的自動化測試，肯定在專案中得到良好的收益。

歡迎大家來點評，來吐槽一下，也想知道各位做的自動化測試是怎樣的，到達什麼程度，獲得怎樣收益。

另外，此篇文章來自我部落格：https://blog.csdn.net/liudinglong1989/article/details/108899513