淺談測試生涯如何轉型升級

導讀：

    全部的測試從業人員都想從業務測試轉型成長爲測試開發工程師，由於這是一個門檻，一種層級，一個上升自我，提升我的價值的重要驅動力。

    測試開發工程師是一個交又工做的角色。與開發工程師相比，測試開發工程師除了要具有寫代碼的能力，還須要掌握操做系統、數據庫、網絡、軟件測試等相關領域的知識。與業務測試工程師相比，測試開發工程師擁有編寫測試腳本、設計測試框架、搭建測試平臺、維護測試環境等技能，可是可能沒有業務測試工程師那種專業的業務知識背景。測試開發工做，本質就是爲了保證測試可以正確且順利進行而作的工做。測試開發要服務於業務測試，測試開發不是脫離業務而單獨存在的。在軟件系統生命週期過程當中，業務測試工程師和測試開發工程師是並存的，並不會彼此替代。

那麼，你爲轉型作好準備了嗎？

1．2業務測試的挑戰

1．2．1測試人員的挑戰及新要求

在固定時間內快速迭代，進行高併發任務測試一直都是測試人員和測試團隊所面臨的挑戰。除此以外，他們還要應對不斷變化的用戶需求，同時整個行業內開發人員和測試人員人數比例不平衡，傳統測試以外的任務缺少明確的方向和職業發展路徑等，這些都是測試人員面臨的問題。業務的多元化，以及公司戰略調整和整個行業的不斷髮展，要求測試人員具有愈來愈多的技能，其承擔的責任也就愈來愈大傳統測試的角色已經沒法知足工做的須要，同時測試人員也但願變得比以往更具技術性。現在的工做也要求測試人員具有比以往更高的執行力，可以提供快速反饋，有時不只要是測試人員，還須要成爲開發人員。

從流程上來看，測試介於產品和開發之間，須要和產品人員溝通，也須要和開發人員溝通，工做的特色也決定了測試人員要面臨的挑戰。如今大量的公司在招鴨測試工程師時，愈來愈須要綜合性的測試人才，要求應聘人員掌握必定的開發技能，這樣其能夠更好地理解系統，發現更深層次的缺陷，與開發人員的交流也會更高效，在和產品人員溝通時也能提出更有建設性的意見。未來徹底不懂技術或者代碼的測試人員可能會被行業淘汰。

應對挑戰的惟一方法就是不斷適應和進步。測試人員必須瞭解他們的角色在如何變化，以及如何在不一樣的環境中爲利益相關者提供最好的服務。測試人員須要具有很高的靈活性和適應性，不斷學習新的技能和方法，並願意承擔新的角色和活動，這纔是測試人員自身必須掌握的核心技能。

結合做者所在團隊的實際狀況，團隊的目標是可以快速反應，支持業務快速迭代，同時要把測試人員從繁重的重複工做中解放出來，爲內外「賦能」，提供好的測試平臺、好用的測試工具和高效的測試方法等。這就對測試人員提出了一些新的要求。

1．編寫代碼的能力

具有編寫代碼的能力可以提升測試效率，獨立或者輔助開發人員定位問題，而不是隻報告問題。這也有助於測試人員瞭解編程過程，完善思惟方式，提高測試形象。

2．工具思惟與工具開發能力

工具思惟有助於測試人員敏銳地發現能夠節省人力的工做點。具有工具開發能力能夠真正從繁重的重複工做中解放本身。

3．持續學習的能力，學會思考

持續學習不只是一種態度，更是一種能力。持續學習新的技術和新的思想，瞭解新的動態趨勢等，可以幫助測試人員更好地適應變化，在變化中進步。學會思考這個話題很寬泛，包括規避風險、項目推動、問題解決等測試人員須要的不少其餘的認知過程。可是，若是測試人員不能持續學習，那麼他的思考也會被限制。只有持續學習，不斷思考，才能知道在不可知的將來咱們可以提供什麼，價值該如何體現

4．強大的心裏

測試工做是一個不斷質疑與被質疑的過程。測試人員天天會面對不少繁重的工做，隨時隨地均可能被別人挑戰，還有可能在工做中遭遇質疑及誤解。想要將工做進行下去，強大的心裏對於測試人員來講極其重要。

5．測試思惟

測試思惟決定了測試人員能在測試這條路上走多遠。測試的核心技能不是測試理論、也不是測試工具，而是試分析試設計測試架構和試補主：思美去長、び少矩地」一直是做者所在團隊提侶的·學會分析任務，分清優先級，具有統一規劃能力，可以使工做達到事半功倍的效果。

轉型的基礎及必要性

轉型是爲了更好地知足業務需求，更好地保證系統質量，也是爲了可以更好地配合公司的戰略。每一個團隊是否轉型，以及轉型的動機及基礎，根據具體狀況而不盡相同。做者所在團隊主要負責業務的測試，年後新來了一位經驗豐富的測試經理，因此同時存在測試開發的崗位，這也是團隊轉型的一個優點。

相信和做者狀況相同的團隊數量很多，那麼這樣的團隊想要快速轉型須要先搞清楚哪些問題呢？

1．轉型的目的

更好地知足業務需求以配合公司的戰略，同時考慮到行業的發展趨勢，提高團隊總體的技術水平，實現團隊與我的的共同成長，實現良性循環

2．轉型的方向

單元測試是很是重要並且很是有必要實施的。在敏捷開發模型的工做實踐中，開發人員承擔了單元測試的工做。因爲公司戰略的調整，UI層的自動化測試再也不是團隊的重點，所以自動化接口測試配合測試工具開發，是做者所在團隊轉型的首選方向。完善的接口測試體系可以在很大程度上保證產品的質量，而這部分的投入也快速收到成效，並且測試工具的開發可以將測試人員從大量的手工重複性工做中解放出來，提升效率。

3．轉型的基礎

團隊轉型要根據轉型的目的以及須要解決的問題，選擇轉型的方案。大致上能夠從轉型意願、轉型所需時間、轉型規劃、轉型先後技能、應用等方面選行準備。

（1）轉型意願

團隊想要轉型成功，除了須要考慮業務需求、行業趨勢等外部環境因素外，還要考慮團隊成員的轉型意願。團隊成員主動轉型的意願是轉型成功的關鍵因素。被迫轉型與主動轉型的差異在這裏就不須要討論了，取得的轉型效果也是不一樣的。充分發揮團隊成員的主觀能動性可以讓轉型快速完成並取得使人驚喜的效果。

（2）轉型所需時間

團隊轉型必須經歷一個學習和練習的過程，這個過程須要時間。然而，測試工做的性質決定了其最缺乏的偏偏又是時間。那麼這部分時間從哪裏來？須要團隊成員達成共識，避免佔用成員的業餘時間而使他們產生抵觸情緒

（3）轉型規劃

團隊想要轉型成功，在轉型開始以前，要作好整個轉型期間的規劃，包括須要學習的技能、學習的進度、練習的時間、掌握程度的考覈、備份學習材料和備用方案等轉型期間要嚴格按照規劃進行，確保轉型有條不紊地進行。

（4）轉型先後技能

根據團隊轉型的目的，要求團隊掌握的技能也不盡相同，想要達到的效果也不一樣團隊應根據業務的特色及面臨問題的緊迫性來決定須要掌握的技能。轉型前須要具有的技能基本大同小異，包括測試的基本知識、業務背景知識、數據庫相關操做能力、主流編程語言開發能力（最好與公司開發語言一致）等。

（5）應用

團隊轉型想要取得好的成效，實戰是不得不考慮的問題。若是沒有實戰應用，那麼再多的理論支持也只能是紙上談兵。在轉型過程當中，能夠嘗試將培訓的技能應用到實際項目中。若是沒有項目，也可人爲地創造針對性的實戰。只有經過實際應用，才能發現問題和解決問題，讓轉型真正發揮做用，取得好的效果。

13團隊轉型的目標及計劃

1．3．1轉型路上的迷茫

自動化測試是軟件測試發展的一個必然結果。隨着軟件技術的不斷髮展，測試工具也獲得了長足的發展，人們開始利用測試工具來幫助本身作一些重複性工做。軟件測試的一個顯著特色是重複性。重複會讓人產生厭倦的心理，重複也使工做量倍增，所以人們想利用工具來解決重複的問題。

目前，自動化測試在行業中處於被熱捧的時期。一方面，不少專業人士對自動化測試大加讚揚：另外一方面，在移動互聯時代，企業的生存環境發生着深入的變化，各大互聯網公司都在尋求自身發展的道路，公司的轉型成了必然趨勢。公司要轉型，員工勢必也要跟隨發生變化。至今，做者都不能忘記團隊成員第一次據說組件化測試時滿臉的新奇。隨着一輪又一輪地探討如何作、怎麼作，團隊成員才慢慢意識到這將會是一條漫長的路，期間確定有迷茫和痛苦。然而，更痛苦和嚴峻的挑戰是團隊的轉型。轉型是否能夠達到應有的預期呢？

不少團隊基本上會不一樣程度上的面臨如下兩大問題。

（1）人員水平良莠不齊

團隊轉型不是一我的的轉型，一般涉及十幾人、二十幾人的同步轉型。其中每一個人的水平良莠不齊，學習能力也不盡相同。例如，以前大多數人從事的工做是功能測試，沒有開發過自動化工具或者框架，用的自動化工具很少，也沒有作過開發。那麼，這就要求咱們必須左右開弓，線上學習和線下培訓同步進行。

（2）作什麼及從何處作起Microsoft公司最初也設有隻進行手工測試而不編寫代碼的職位，稱爲STESoftware Testing Engineer）。而如今全部測試工程師的職位都稱爲SDET（ Software Development Engineer in Test）。從名字能夠看出來，後者是須要掌握編程能力的，而掌握編程能力是爲了更好地測試。

從STE轉到SDET的充分條件是測試人員對軟件及需求具備較強的理解能力，同時擅於站在用戶的角度去理解需求，以及重視質量使得程序的返工率大大下降而必要條件是達到開發人員所具有的設計能力和編碼能力。認清本身的不足，在如下方面不斷提升本身的能力。

（1）對程序架構思想的理解：經過參加需求評審、設計評審、代碼評審，學習設計方面的知識。

（2）編碼能力：經過單元測試、自動化測試、測試工具和測試框架的開發等環節提升本身在編碼方面的能力。

走出迷茫，有了奮鬥的目標，只要拼命追逐、堅持不懈，終會看到成功的方向。

1．3．2樹立目標

咱們作任何事情都應該有一個目的。有了目的，就會產生一個對應的目標。而後基於這個目標，進行相關活動的實施，以此來達到目的。相似地，咱們在進行自動化實施的時候，首先要明確自動化測試的目標，即實現了自動化測試到底能爲咱們帶來什麼好處，以及能夠解決什麼間題。咱們不能爲了自動化而自動化，必須在實施自動化測試以前明確自動化測試的目標。

1．提升測試人員的工做成就感和幸福感，減小手工測試中重複性的工做

目前。在大部分中小企業中，手工測試在平常測試工做佔據的比例很大。測試人員必須跟隨開發團隊不斷地進行選代式開發和測試。一個功能模塊可能在整個測試周期中重複測試超過10次。

如何改變這個現狀呢？進行自動化測試確定是一個很好的選擇。相應腳本寫好之後，能夠不斷地重複運行。測試人員只須要單擊某個按鈕就能夠開始測試工做了，而後看一下測試結果。就完成了以往手工測試須要花費很長時間才能完成的工做。此時，測試工做的成就感和幸福感油然而生，測試人員也會有意願去主動地推動自動化測試在不一樣項目中的深刻實施

2．提升測試用例的執行效率，實現快速的自動化迴歸測試，快速地給予開發團隊質量反饋

使用手工方式來執行測試用例，執行速度必然是很慢的。人是一種生物，而不是機器，工做時間長了必然會以爲勞累，測試執行的速度天然就慢了下來。在測試用例很是多的狀況下，測試一遍通全部測試用例的時間成本就會至關高。

若是使用自動化測試取代手工測試，那麼測試用例的執行者就變成了機器。機器能夠全天候不停地執行，能夠不知疲倦、快速地完成測試腳本指派給它的測試任務。此種方式勢必能夠大大提升測試執行的效率，縮短測試用例的執行時間，提升測試執行的準確性。

目前，敏捷開發模式在各種軟件企業中開始普及和應用。敏捷開發對被開發產品的質量反饋有着很高的要求，須要每週甚至天天開發出一個 Build版本，而且部署在測試環境上，同時但願測試人員可以給予快速的質量反饋。目前，只有經過自動化測試的方式，才能真正實現對於大型敏捷開發項目的質量反饋需求。缺乏自動化測試的敏捷開發項目會大大增長項目失敗的風險

爲了驗證是否達到了此目的，能夠和之前手工測試的執行時間進行對比，看看是否明顯縮短了測試用例的執行時間，詢問開發人員項目的質量反饋速度可否爲快速發佈產品帶來很大幫助。

3．減小測試人員的數量，提升開發和測試的比例，節省企業的人力成本在大部分IT企業的運營成本中，5006～706的成本是人工成本，如何更好地控制人工成本，對企業的發展有着重要意義。使用自動化測試方式，勢必會減小手工測試的工做量，從而達到減小測試人員的目的，進而下降企業的人工成本，提升企業的盈利能力

4．在線產品的運行狀態監控

在完成產品開發和測試工做後，產品會發布到生產環境中，正式爲用戶提供服務。可是，在生產環境的運營過程當中，產品老是會因爲各種緣由產生這樣或者那樣的問題或故障。如何快速發現這樣的問題呢？有人說：「出了問題必定會有用戶給客服打電話，這樣咱們就能夠發現生產環境中的問題了。」採用這樣的處理方式，勢必會下降用戶對產品的滿意度。另外，若是沒有熱心的用戶進行反饋，那麼生產環境中的問題被發現的時間會大大推遲。所以，僅僅依靠客戶反饋的方式是不可取的。

爲了保證快速、及時地發現生產環境中的問題，能夠編寫自動化測試腳本，以測試產品的主要功能邏輯。定時運行測試腳本，以檢查產品系統是否依舊能夠正常工做。若是運行測試腳本後沒有發現任何問題，則休眠等待一段時間後再運行測試腳本，以檢測產品系統的運行狀態。若是測試腳本發現了產品系統的運行問題，在重試幾回以後確認產品系統的問題依舊存在，則測試腳本會自動給系統運維的值班人員發出報警郵件和短信。相關人員收到報警信息後能夠人工處理系統出現的運行故障，這樣就達到了實時監控產品系統的目的，以便在第一時間發現和處

理系統的故障

5．插入大量測試數據

在系統級別的測試過程當中，常常要插入大量的測試數據來驗證系統的處理能力。例如，測試人員想要插入100個訂單，而且每一個訂單都要有業務要求，使用手工的方式來插入這些數據勢必會花費很長的時間和不少的精力。然而，若是咱們有「

6．常見的錯誤目標：使用自動化測試徹底替代手工測試

有人認爲，轉型後就是自動化測試了，不用手工測試了。對於任何項目，首選自動化測試，這是不可取的。在作出如何對待自動化測試的決定以前，首先要對自動化測試有一個清斷的認識。自動化測試是對手工測試的一種補充。不少數據的正確性、界面美觀程度和業務邏輯的知足程度等都離不開測試人員的人工判斷。而僅僅依賴手工測試會讓測試過於低效，尤爲是迴歸測試的重複工做量會對測試人員形成巨大的壓力。所以，人工測試與自動化測試都不可或缺，關鍵是在合適的地方使用合適的測試手段。

（未完待續）