自動化測驗是每個軟體公司反復提及的，放眼望去，測驗崗位的招聘要求里十有八九都會有一條“掌握自動化測驗技巧”，甚至有的公司把用例自動化率（實作自動化的用例數/總用例數*100%）當作考核測驗人員作業質量的指標之一，
那么，對此，想必大多測驗人員會發出靈魂一問：難道手工測驗就必須消亡了嗎？自動化用例真的那么重要嗎？是不是所有用例都需要實作自動化呢？自動化測驗是不是就是所向披靡，無敵的呢？
在回答這幾個問題之前，我們先來簡單了解下自動化測驗的特點，談及自動化測驗，就不得不把手工測驗拉出來一較高下了，它們各自的定義就毋庸贅言了，
01 自動化測驗的特點…
相較手工測驗，自動化測驗最大的優勢就在于：
能夠快速測驗（快速檢測代碼變更引入的錯誤）；
可以重復測驗（反復執行成本低），
但是，自動化測驗也有自己的缺點：
如果軟體系統體量比較大，那么自動化測驗腳本也會比較復雜，自動化測驗腳本的復雜度與系統的復雜程度是成正相關的；
如果軟體系統迭代快、周期短、變動多，那么腳本維護將需要較大成本；
隨著軟體系統的不斷迭代，功能的不斷增加或細節的變更，會出現大量冗余的自動化測驗腳本，這類冗余的腳本會直接影響測驗腳本執行的效率；
自動化測驗腳本的質量直接影響測驗執行成功率（執行成功通過的次數/總的執行次數*100%），只要是代碼都會有故障，測驗代碼也不例外，低質量的自動化測驗腳本有可能導致測驗執行時的不穩定性（例如：反復失敗）；
對于測驗人員而言，自動化測驗，腳本準備時間（如自動化測驗工具選取、腳本撰寫等）大于測驗設計時間；
對于迭代較快的產品，需要測驗人員快速地完成測驗，在此種情況下，留給測驗人員實作用例自動化的時間不會很多，自動化測驗在新功能周期內往往很難快速實作；
對于業務量大、業務復雜的系統（如經濟類系統，銀行等），用例自動化率難以保證，且如前端GUI自動化測驗，100%用例自動化率本身就是一個幾乎難以實作的愿景，
說了那么多，到底是想證明個什么事兒呢？其實，上面的闡述無非是想問答幾個問題：
手工測驗會消亡嗎？
個人覺得，答案肯定是不會，為什么呢？自動化測驗有其優點，可以幫助測驗人員快速完成回歸測驗，但其缺點也依然存在：測驗代碼冗余、測驗代碼維護成本大、部分產品的復雜功能難以自動化等等，
是不是所有自動化用例都需要實作自動化呢？
答案當然是否定的，理想很豐滿，現實很骨感，且不說產品本身特點是否能滿足完全自動化測驗，從自動化成本（維護成本，時間成本，人力成本等）而言完全自動化就是值得思考的問題，再者，對于前端GUI自動化測驗而言，完全自動化本身就很難，
自動化測驗是不是所向披靡、無敵的？
答案當然也是否定的，畢竟自動化測驗的根本目的主要在于快速地回歸測驗，在回歸測驗的程序中對于環境的需求、場景的設定都是具有限定性的，且自動化測驗代碼也會存在故障，如果切換場景進行自動化測驗，不見得能百分百通過，
那么，再進一步想想，如果自動化測驗很重要，但又不是百分百完美的，如果想要借助自動化的便利提升測驗效率，那么應該針對怎樣的用例實作自動化呢？自動化用例應該用在什么樣的測驗活動中呢？
02 選擇需要實作自動化的用例…
其實在上述章節已經揭曉了如何選擇需要實作自動化用例的部分原則，
選擇執行結果穩定的用例實作自動化
試想如果一個用例執行結果不夠問題，那么將手工測驗步驟自動化有什么意義呢？這個時候需要的是去重新審視測驗步驟是否準確或者代碼是否有隱藏問題吧？！
選擇功能穩定的用例實作自動化
試想如果一個模塊或者一個功能頻繁變更，那么用例實作自動化有什么意義呢？如果將此類用例實作自動化，反而會加重測驗人員對自動化腳本的維護成本，
首先選擇介面用例自動化
那是因為介面自動化學習成本低，幾乎是每個測驗人員接觸自動化測驗的第一步，而且介面是每個模塊銜接之處，保障系統運行的重中之重，
如果要求前端GUI自動化
要慎重
前端GUI本身就是一個屬于頻繁變動的部分，如果實作自動化，對自動化腳本的維護就是一個不得不思考的問題，
也許你會說，我用錄屏啊，錄屏雖然學習成本低、操作簡單，但是對于測驗步驟的斷言、測驗結果的判定大多還需人工干預，
03 如何在自動化興起下發展手工測驗…
百分百自動化測驗是每個測驗人員的追求，每個公司的終極夢想，但這本身就意味著實作的困難和不可能，
自動化測驗很重要，但手工測驗仍然不可或缺，
測驗人員擔心自己會被各種不斷進步的自動化測驗工具替代的時候，可以想想如何在包圍圈中拼殺出一條血路：我想，測驗設計應該是一條可選之路，
好的測驗設計能夠節省測驗成本（如測驗資源的投入）、提高測驗效率、提升測驗結果穩定性，同樣，優秀的測驗設計能夠指引測驗人員挖掘一些深層故障，提高產品質量，
常有人說：測驗是一門簡單的作業，測驗崗位可以被取消，不需要專職測驗人員，但是如果不需要專職測驗人員，讓開發人員兼職測驗作業，豈不是開發人員既當選手又當裁判？如何能夠公正地評判，
再試想：如果開發人員能夠知道自己代碼中的故障，那為什么不在撰寫代碼的時候就避免了呢？
04 測驗員如何殺出一條血路…
說實話，我沒什么遠大的理想，無非就是想在測驗這條道路上做大做強，當然為了我穩定的作業，我發自內心也確實想做點什么，總結下來無非就是以下幾點:
1、提高核心競爭力
當然，無論你選擇自動化還是手作業為自己的核心競爭力，學習是一定不能落下的，學習力強的軟體測驗員敢大膽地體驗嘗試新技術，所以他們的技術堆疊始終在保持不斷地更新，
對于軟體測驗員而言，看檔案其實是最快的學習方法，對于自己作業中常用到的技術，抽時間把官方檔案都讀一遍，其實沒有你想象中的那么多，但你一定會有意想不到的識訓，所有的核心競爭的前提都是需要不斷學習來造就的，擁抱技術升級，才能使你一直不會被市場淘汰，
2、鍛煉一個強健的體魄，
做了程式員之后我就很少運動了，新的計劃就是一周至少要去健身房2-3次，不求練的跟泰森一樣壯，只求能有一個強健的體魄，程式員猝死的新聞比比皆是，在職場殺出血路的前提條件當然是身體健康，鍛煉身體是很必要的，為了預防猝死嘛，嘻嘻，開個玩笑，
3、學習更多的技術，
我的學習效率實在是太低了，說到底就是因為懶，這也是我覺得自己最該改變的一點，目前計劃是繼續多學多看多實踐，
最后：下方這份完整的軟體測驗視頻學習教程已經整理上傳完成，朋友們如果需要可以自行免費領取【保證100%免費】
軟體測驗面試檔案
我們學習必然是為了找到高薪的作業，下面這些面試題是來自阿里、騰訊、位元組等一線互聯網大廠最新的面試資料，并且有位元組大佬給出了權威的解答，刷完這一套面試資料相信大家都能找到滿意的作業，
這些資料，對于【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴上萬個測驗工程師們走過最艱難的路程，希望也能幫助到你！
這些都在我的軟體測驗學習交流群里：902061117
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/550024.html
標籤：其他