轉：google測試分享-SET和TE

​

      前端時間看了google測試之道，收獲了一些，在此總結下并打算寫一個系列blog，順便分享給各位，也希望大家多交流，多讨論。另外需要強調的是我說到的一些google測試理論和淘寶的相關測試實踐，并不代表所有淘寶測試團隊都會這樣去做，僅僅代表我的測試團隊會做的一些思路上的改變和實踐，肯定有不成熟的地方，歡迎讨論。最後需要強調的是，我這邊得到的一些google做法僅限于google測試之道那本書，其他的我真不知道，如果有沖突不一緻的地方，歡迎大家指出來。

為了讓這些blog分享更有邏輯性，我打算分幾個專題來分享google測試相關的測試理念。

google測試分享-SET和TE

google測試分享-分層測試

google測試分享-GTA

google測試分享-測試經理

google測試分享-問題和挑戰

google測試分享-未來測試 

      首先我們看下SET和TE的簡要說明，然後再看看他們的工作職責有何不同，在項目中發揮什麼樣的作用。SET就是測試開發工程師（software engineer in test），TE就是測試工程師（test engineer）。我們先不說國内是如何定義這兩個不同的職位，也不去關心國内是如何把測試人員/測試工程師/QA 叫成 測試開發工程師，這個話題太大了，而且因人（公司、團隊、文化）而異，在這裡不讨論了，這裡隻說明google或理想中的公司是如何來區分SET和TE的。

      首先我們看看自己團隊中的測試人員是做了哪些測試活動：功能測試（手工和自動化）、性能測試、安全測試等。這裡面我要強調的是功能測試的演變。

（1）測試人員從黑盒角度做系統測試，也從使用者角度來進行測試設計和測試執行，包括系統品質的全面評估

（2）自動化發展起來了，特别是頁面自動化測試，測試人員開始在項目測試上線後編寫測試腳本進行自動化回歸測試，同時之前的工作不變

（3）随着頁面自動化測試的ROI越來越低，接口自動化測試開始了，測試人員在項目過程中或項目上線後針對産品的重要接口進行接口測試腳本的編寫，同時之前的工作不變

（4）随着UT的重要性和開發自測的提倡，測試有時候還需要做UT和code review，還要做驗收測試，同時之前的工作不變

個人感覺國内隻要把測試工作裡面包括編寫自動化腳本的測試人員都叫測試開發工程師（偶爾也包括測試架構的二次開發等），這裡先不談專門的測試工具開發部門。

      我們先來談談測試開發工程師（SET）的工作職責吧，首先SET的重點是從開發角度去做測試工作，會把主要精力投入在系統設計和編碼階段。開發人員關注某個功能最優實作方案，SET要有整體産品的視野。SET在設計階段，幫助開發人員完成代碼複用和子產品互動方面的設計，SET在設計review的時候，保持目的性：完整性、正确性、一緻性、設計、接口與協定、測試（可測試性）。SET的自動化測試相關工作包括隔離容易出錯的接口，并針對它們建立mock和fake、建構一個自動化測試工程，控制mock系統的建立和運作，而開發人員使用這些mock接口做一個私有建構，針對這個建構進行自動化測試運作。

      另外，SET的第一要務是産品代碼的可測試性，同時作為整個項目的品質顧問提供給項目組其他人員關于品質保證的建議。他會主導UT和CT（元件測試）的測試執行工作，同時負責測試自動化體系的長期有效性。由于SET持續的關注自動化測試，他有可能會忽視人工跟蹤bug庫和每個釋出的測試的重要性。但是由于他在系統設計和編碼的深入，SET不僅可以看到樹木而且可以看到森林；是對測試有強烈興趣 和天資的開發人員。

      接下來我們談談測試工程師（TE）的工作範圍。首先TE的重點是從使用者角度去做測試工作，會把主要精力投入在系統測試階段，包括自動化回歸和手工的探索式測試。TE可以在多個産品之間流轉，了解不同的産品技術，為不同的産品進行系統測試和探索式測試。TE的重點在于評估對使用者的影響以及軟體産品整體目标上的風險，職責範圍最廣。TE可以從使用者産生的影響的角度來說明為什麼一個功能不能上線或整個釋出不能上線。

      從項目的角度來看，項目前期主要是SET的任務，項目後期是面向TE的任務。當然并非所有的産品都需要TE的介入。早期的産品測試計劃TE投入不多（特别是UT和CT占主導的産品），後期産品接近尾聲，TE引導做探索式測試。但是在需求階段，TE擅長發現需求中的模糊之處，分析溝通不明确的地方，而且TE角色需要敏銳的洞察力和上司力，很多進階測試經理來自于TE。所有說TE的工作經常需要去打破正常流程，可以在任何時間進入項目，必須迅速評估項目、代碼、設計和使用者的目前狀态，然後決定首要的關注點（這些東西在國内公司的測試團隊中從來不被重視，他們認為no code，talk is cheap）。

       這裡羅列下TE的主要職責：測試計劃和風險分析；需求評審、設計、代碼和測試；探索式測試、使用者場景、編寫TC、執行TC、衆包、使用統計、使用者回報。我們都知道項目的過程中，風險始終存在的，那麼TE是緩解風險活動的協調人，決定對風險較大的領域進行内部測試，要求開發人員和SET增加回歸測試。也可以借助dogfood使用者、beta使用者以及衆包進行測試。TE對風險最高的領域負有個人責任，必須編寫測試指導（類似于測試方案）。

      真正在項目過程中，TE是需要TE了解SET和開發人員的測試後，評估這些測試對風險的影響。高風險區域的每個bug都應該有一個回歸測試用例與之對應。TE還要仔細思索高風險的區域，咨詢可能的復原和恢複機制。對于風險較低的區域，可以降低要求，為這些區域編寫特定的測試用例是得不償失的，我們更多的是選擇探索式測試，或衆包測試。還需要強調的是，TE也會在項目過程中進行系統測試級别的自動化測試腳本編寫、CT和ST的自動化測試監控和腳本維護工作，但這不是他工作的核心。

     總體來說，TE是稀缺個體，是技術人，關注使用者，能在系統疾病和端到端的視角上了解産品。他們是無情的、偉大的談判專家，最重要的時，他們富有創造性、善于應對模糊性。

      如何招聘到好的TE呢，我們需要考察候選人計算機科學和技術技能，也要測試潛力。TE經常能擔當上司角色，因為和SET相比，他們站的更高、看的更遠，能給了解各自設計問題和風險。我們尋找的是對于事物結構、對于變量和配置的組合的各種可能性和意義的好奇心。是關于事物應該如何工作的強烈感覺以及清晰表達的能力，這裡的要點是，給出一個需要各種輸入和環境條件的測試問題，請候選人列舉出最有意義的可能。另外，就是要考察TE所需要的處理模糊性、反駁槽糕想法的能力。還要考慮比如給開源項目提bug、通用化自己的工作以提高複用性的人。

      TE經常在系統測試階段應用探索式測試的測試方法，而應用探索式測試，首先快速找到哪些測試模式适用于被測産品；多觀摩團隊其他人送出的bug、讨論發現政策，對每個人來說都是一種極好的學習體驗。

     SET可能會忽視人工跟蹤bug庫和每個釋出的測試的重要性。TE負責組織包括SET在内的整個測試團隊的測試戰略。當SET不清楚從何處開始實作測試霍工具時，TE會展示最需要測試的地方并以bug資料做支援。TE還能用真實資料說明他們的方案在預防bug方面的有效性如何。

     在google，自動化測試發現bug的比例很多，相比于手工測試。最後，一個令人贊歎的産品背後，總有一個構成多樣性的測試團隊，包括SET和TE。

----後記

      對于TE的描述，某些人可能覺得比較虛，還是SET經常寫code實在。國内的測試團隊，基本上把SET的工作和TE的工作合二為一，放在一個人的身上，大家其實也看到了SET和TE的技術和要求是不一樣的，我們測試團隊的測試開發工程師都能很好的具備SET和TE的能力嗎，我們真正的測試工作重心到底是什麼呢？我們的測試開發工程師都能在産品的測試過程中發揮這麼多的作用嗎？大家可以自己思考下。