引言
內容已經有了，可是標題想了好久，最終仍是決定用這個。簡單清楚明瞭——總結一場失敗的自動化測試案例。前端
文筆欠佳，若有閱讀不適，請見諒！java
自動化測試
現在，軟件測試行業裏，人人都在講自動化測試，人人都在作自動化測試。若是誰說本身不會自動化測試，都很差意思去面試。如今各大公司招聘信息都是必須會自動化測試，一部分公司招人只招測試開發。甚至有些大頭公司都不分測試與開發兩個職位。python
因此，絕大部分公司都有人在搞自動化測試，甚至有一部分公司有一套成熟的自動化測試體系。你能夠把它當作標準化流水線，相似如今講的Devops。程序員
這裏，我講的固然是我在公司的一次自動化測試體會。因爲保密協議，這裏簡單介紹：web
背景
公司是一線大廠的子公司，也能夠稱爲合做夥伴。 相似華爲旗下的榮耀。公司去年年初，因爲業務愈來愈繁多，因此人員也是瘋狂擴展，因此迭代至關頻繁，標準是一週一個迭代，緊急小迭代，也有過兩三天的時候。有人會說怎麼作到的，拼人啊，加班啊。面試
測試團隊
先說咱們測試團隊吧，擴展後測試團隊人數大概是40左右，其中職位有自動化測試，測試開發，性能測試，安全測試。惟獨沒有測試工程師。由於公司不招單純的功能測試。sql
有人可能會質疑，那業務測試誰來作？數據庫
在這裏，咱們公司業務測試全職測是自動化測試，而測試開發是專職於測試體系建設中。性能和安全測試有時候會支援業務測試，可是他們也是專職於性能和安全方面的測試，面向全公司全部系統。編程
測試體系發展
起初測試團隊是沒有對測試技術體系思考，你們作自動化測試都是各自作各自負責的業務系統那一塊，用的工具與方面各色各樣，編程方面大體分兩派java和python。安全
這種分散的自動化測試帶來的弊端就是：
一、數據沒法可視化；
二、腳本維護難；
三、增長了學習成本；
四、易用性、移植性差；
這種分散的，小做坊形式的很快就不適應快速迭代的需求及市場變化。最核心的一點是，部門領導沒法向老闆展現數據。通俗的來說，就是沒法向領導展現咱們測試團隊存在的價值。
嘴巴說，誰都會。可是，領導想看數據，那麼平臺是惟一秀出測試團隊工做中沉澱下來的數據的途徑。這樣有了數據，團隊的KPI就出來了。
你說你每天在測試，每天在作自動化測試，作了多少，效果如何。領導不可能一個個找大家去統計，去查看。無論你腳本寫的多優秀，框架設計得多麼出神入化。終究沒有所謂的正規化平臺好。
而後，就這麼定了。幾位測試開發大神，在領導的安排下，通過多番討論的設計方案，寫了一套後臺是Java的自動化測試平臺。這裏說明一下，只因此是Java，由於公司是Java系統。
測試平臺
時至今日，平臺已經完善得差很少了，該有的都有，沒有的也有了。簡單說一下平臺的功能：
一、接口測試；
二、UI測試(app和web)；
三、性能測試；
四、流量監控；
五、接口覆蓋率統計；
六、安全測試；
七、代碼質量掃描；
八、生產發佈卡點；
....
主流的功能就是這些，其餘小功能我就不一一列舉了。這套平臺已經集成了軟件測試中絕大部分的測試技術在裏面；能夠算得上一套標準的流水線了。
之前會自動化測試會以爲高大上，如今平臺搭建起來了，而且已經維護了1萬左右的測試用例在上面了。是否是更加牛逼了？
答案我不知道平臺搭建後是否真正牛逼了，可是它的建設至少對測試團隊的影響有以下幾點：
一、增長了團隊的技術含量(至少領導不會認爲咱們只會點點點)；
二、提升了團隊的做戰能力；
三、提升了測試效率(因人而異)；
四、下降了成本(待查)；
五、提升了產品質量(待查)；
六、下降了學習自動化的難度；
...
上面只列了六點，對於咱們測試團隊的影響，也算人們口中常說的自動化測試的意義。其實還有不少，就不說了。
自動化測試現狀
平臺是完善好了，前面說了，平臺已經維護了1萬左右的接口測試用例，其餘數據我暫時沒看。顯然平臺健壯性是毋庸置疑的，易用性也很好，入門簡單。
那麼問題來了，對於迭代頻繁的項目，咱們在何時去編寫接口測試用例呢？
這種問題，絕大多數的人都知道，常規的回答不限於這些：
一、接口測試需求評審了(絕大多數是沒有)；
二、什麼開發接口開發好了，開發提供了接口文檔之類的，咱們就能夠去平臺維護接口測試用例了；
三、開發自測經過，代碼提交；
...
...
這些回答都很標準，很理想。可是，你有沒有想過，現實是很骨感的，就是會出現以下情形：
現狀一：
版本變化得讓你根本沒時間維護的時候，你只有加班抽時間來維護，並且這種狀況只有在領導發話了，你們纔會去維護上去。有些人因爲業務線確實忙，因此沒維護，有些是本身寫腳本，根本不想維護上去。固然也有人主動的去維護。
針對這個現狀，領導又出必殺技，將接口測試用例設計和覆蓋率的指標定下來，而且放到KPI考覈項裏去。
KPI大家都懂，這裏就不講述它的做用了。這個大招一放，你們都自覺的去平臺上維護了。
現狀二：
現狀二就是現狀一的延伸版，就是每次版本有新增的接口後，你們爲了KPI會主動上去維護。而後有一大部分人也僅僅上去維護此次，後面版本接口有變動，也不會花時間去更新已經維護上去的接口。
其中緣由，有些多是真正的忙，沒有時間。有些可能由於懶，不想去維護。總而言之，測試團隊中有一部分人是沒有去更新接口測試用例的。
現狀三：
談到自動化測試的用途時，你們都會記得其中一個是用於迴歸測試，減小人力投入到版本回歸測試中去，從而把節省出來的時間和人力，用於更多的業務測試或者其餘測試中去。
可是，現實倒是，在版本變動中，真正去執行之前維護的接口測試用例來回歸測試的人太少了。據我觀察和了解，在短時間迭代中，上個迭代維護的用例，這個迭代沒人會去跑，哪怕只用一分鐘的時間。
出現這種狀況，一方面因爲自信，太自信於以爲以前的接口沒有變更，不必去跑，另外一方面，時間過短，又要交付測試，功能測好，直接就進入產品&業務驗收環節。就把這一步省略掉。
固然，還有其餘不少緣由，這裏不細說。結果都是同樣，沒有去維護歷史數據。
現狀四：
自從公司招進外包測試後，如今部分項目測試工做分配以下：
測試工程師專門負責設計用例，而後交給外包團隊來將這些用例再翻譯成測試腳本，這樣的作法，效率不低下才怪。
首先外包同志不熟悉業務線，直接轉化，仍是得從瞭解業務開始。
其次功能測試用例直接翻譯成自動化測試腳本存在重複性勞動，同時也會出現場景遺漏，場景不可用的狀況。
總而言之，這種作法收益大大低於投入。
正確的姿式是：測試工程師本身就將測試腳本交付出來。對於那些全棧工程師而言，最正確的姿式是：開發人員本身就動手將測試腳本寫出來。根據我對微軟的瞭解，微軟的 Visual Studio 團隊，就是這麼作的，他們根本就不區分開發和測試。
現狀五：
談自動化測試的時候，咱們常常會講到它的優勢，其中一個就是下降錯誤率，發現人工沒法發現的缺陷。那麼，在這裏統計的結果，咱們作接口測試真正發現的缺陷是屈指可數，百裏挑一的。
有的甚至一個都沒有。固然接口測試自己也是有侷限性的，他不可能徹底代替手工去發現手工測試的缺陷。
這裏只講它的現狀...
現狀六：
...
...
綜上所述，還有不少現狀，我這裏不一一列舉，能夠看出來，出現這種想象，一方面是因爲我的緣由，測試的責任和態度。
一方面領導要求全部項目都要作接口自動化測試，歷來不評估哪些項目適合作接口自動化測試。
有點盲目跟風，作了自動化測試就閃光輝，而實際帶來的價值，倒是0。
還有一方面，也是關鍵的一點領導對自動化測試管理方面的欠佳，光靠KPI來觸發是不行的。
失敗的背景
上面已經講了，目前公司自動化測試存在的廣泛問題。
如今從我這個小團隊來說，項目要上阿里雲，就是系統上阿里雲，至於什麼緣由，就不說了，涉及保密協議。
系統上阿里雲，固然沒有那麼簡單，全部與系統相關的服務、數據庫、中間件、流量等等，相對於迭代版本，這是一次比較大的變動過程。
而後，咱們測試在裏面承擔了什麼角色呢？
自動化測試在此次遷移的價值會是怎樣呢？
失敗的經歷
項目上雲，固然咱們測試要保證項目上雲後，全部功能都能正常使用。可是切換的那一段時間，你有多少時間去驗證全部的功能都正常呢？
只有兩三個小時，一年積累下來的功能，兩三個小時如何驗證完呢？
這個時候就是自動化測試該上場了。
這個項目自動化測試交給外包維護了，是在咱們測試平臺上維護的，主要是維護WebUI功能測試用例。接口測試用例是咱們幾個在維護。
到了那一天凌晨，你們都準備好了，準備上雲。而後驗證。
最後發現，沒有維護一個WebUI測試用例(生產環境)。
臨近上雲的幾個小時前，我問他維護了多少用例，他說測試環境維護了，生產環境沒有。
我當時傻眼了，由於這個外包是專職安排弄UI自動化，用於上雲驗證。雲上UI前端框架和雲下前端框架是不同，也就是頁面元素不同，因此測試環境維護的用例，根本沒法在生產環境使用。
而後咱們這邊因爲時間太趕了，接口測試用例尚未更新到雲上環境的域名以及調試好。這個失職也是在於我。
致使，咱們此次上雲驗證，沒有跑過一個自動化相關的用例。
簡單來講，等於此次上雲，咱們用於迴歸測試的自動化測試相關的用例及腳本，沒有一個。
可是，咱們投入在自動化測試的時間，差很少跟咱們業務測試用例編寫的時間趨於一致。
投入與產出是1比0的，結果是慘不忍睹。
咱們4個測試，靠着經久不衰的手法，一路閃電帶火花的點點點，來驗證系統全部功能是否在雲上正常。
一直驗到次日上午人家來上班...
假設，咱們準備充分，接口和UI自動化測試用例都遍歷了全部功能，咱們也不至於熬了一個整整通宵，也不會這麼辛苦，這麼累。
失敗總結
通過此次項目上雲，發現了平時咱們打着自動化測試的口號：降本增效，提升質量。而到了實際要用時，卻發揮不出一點做用。固然，這裏有不少緣由，有我的，也有團隊管理方面的。
可是，拋開緣由不追究，其慘痛結果，反應一個問題，自動化測試是噱頭，沒價值？
答案是否認的，自動化測試是有意義的，也有價值。
可是，若是你運用和管理不當，它的價值沒有發揮出來，將成爲一堆廢鐵，終將百無一用。
試問有多少人，多少公司作的自動化測試(那些BAT、TMD一線大廠裏面的測試團隊除外，畢竟技術與管理體系已經很是完善)，真正發揮了它的價值呢？
大家有評估自動化測試(包括平臺)的收益嗎？
如何評估的呢？
真正達到產出高於投入的有多少呢？
學習自動化測試的人愈來愈多，自動化測試在軟件測試中已是人人蔘與的，可是，若是不真正發揮它的做用，大家作的自動化測試，包括測試平臺，可能就是：
一、爲了體現測試團隊的技術(面子)；
二、爲了團隊KPI；
三、自娛自樂；
四、爲了面試，拿高薪；
五、安慰本身；
六、爲了裝13；
七、盲目跟風，無論有沒有價值，先要有這個東西存在；
...
...
綜上，也有其餘動機和目的，可是，在這裏，我想說的是，作自動化測試，必定要在作以前思考不限於如下六個問題：
一、這個項目爲何要作自動化測試？
二、什麼項目適合作？
三、何時作？
四、作哪些核心業務模塊？
五、誰來作？
六、如何作？如何發揮它的核心價值？
其實搞清楚1,4,6三個問題就能夠了，最關鍵的是作好第六點，我想你作出來的自動化測試，確定在項目中獲得良好的收益。
最後：
歡迎關注公衆號：程序員一凡，領取一份Python自動化測試工程師核心知識點總結！
這些資料的內容都是面試時面試官必問的知識點，篇章包括了不少知識點，其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。