軟體測試開發人員（SDET）到底是什麼職位？

軟體測試開發人員（SDET）到底是什麼職位？

 SDET是微軟三大核心技術工種之一（其它兩個是PM和SDE），是任何一個產品Team Dev中必不可少的一份子。SDET是產品品質和使用者的代言人，主要的工作是從客觀的角度去分析產品的品質以及給出系統化的反饋和建議，從而使整個Team Dev能夠及時地做出對正確的抉擇。要做到這點，SDET需要積極的參與產品的計劃、設計、和代碼檢驗，找出並分析問題的根本原因，以及提高產品和流程品質的系統化的方案。

SDET 和SDE都有哪些區別？

SDET和SDE都需要有紮實的電腦科學基本功，包括編程能力。所不同的是，SDET的工作重點是用反向思維分析的方法找出對產品品質有負面影響的問題，帶領正個團隊解決這些問題，從而提高產品的品質。SDET需要掌握多種技術，用不同的方法去分析產品各個方面可能產生的種種問題。這裡所強調的是對問題的系統分析能力，以及預見到常人沒有想到的潛在問題。

什麼樣的人適合做SDET？

如果你對品質的要求很高，並且喜歡拆東西，弄明白它是怎麼工作的，而且喜歡去改善它的話，那麼SDET應當是你的首選。一個SDET的最基本要求就是對品質的熱情：一定要找到所有的瑕疵從而達到完美。其次，喜歡鑽研、分析、並改善事物是成功的SDET的又一潛質。另外，喜歡學習並掌握多種不同的技能和知識也是SDET所需的技能。

SDET都有哪些事業發展途徑？

在微軟，SDET有非常明確的事業發展階段。從入門SDET開始，到與總監同級的Partner SDET，每一個階段都有充足的挑戰和機會。喜歡做技術，可以一直順著IC的事業模型做到Partner SDET甚至Distinguished Engineer；如果你喜歡管理，可以從測試組長一直做到VP of Test。而最好的一點是，不管是做技術還是做管理，在同一層級的待遇是同等的，也就是做技術沒有“頂”，不做manager也能晉陞。

還可以看看內部人對這個職位的更詳細的解讀.

http://www.51testing.com/?action_viewnews_itemid_17398.html

        找到一篇不錯的關於微軟測試工作性質的文章，對工作角色的認識有一定的協助，我就是SDET，屬於開發與測試中間的那種，並不像自己想象的那種沒有什麼技術含量的黑箱測試，對SDET的要求還是挺高的，做好這種白盒測試，仍然要加緊自己在開發能力的培養，才能較快的發現代碼中的問題。
 
 1. 基本情況
       
測試在微軟公司是一項非常重要的工作，微軟公司在此方面的投入是非常巨大的。微軟對測試的重視表現在工程開發隊伍的人員構成上，微軟的專案經理、軟體開發
人員和測試人員的比例基本是1：3：3或1：4：4，可以看出開發人員與測試人員的比例是1：1。對於測試的重視還表現在最後產品要發布的時候，此產品的
所有相關部門都必須簽字，而測試人員則具有絕對的否決權。
        測試人員中分成兩種職位，Software Development Engineer in Test（測試組的軟體開發工程師）實際上還是屬於開發人員，他們具備編寫代碼的能力和開發工具軟體的經驗，側重於開發自動化測試工具和測試指令碼，實現測試的自動化。Software Test Engineer（軟體測試工程師）具體負責測試軟體產品，主要完成一些手工測試以及安裝配置測試。
2. 測試計劃
       
測試計劃是測試人員管理測試專案，在軟體中尋找Bug的一種有效工具。測試計劃主要有兩個作用，一是評判團隊的測試覆蓋率以及效率，讓測試工作很有條理
的逐步展開。二是有利於與專案經理、開發人員進行溝通。有了測試計劃之後，他們就能夠知道你是如何開展測試工作的，他們也會從中提出很多有益的意見，確保
測試工作順利進行。總之，有了測試計劃可以更好的完成測試工作，確保使用者的滿意度。
        測試人員在編寫測試計劃之前，應獲得以下文檔：
        1）程式經理編寫的產品功能說明書或產品開發計劃；
        2）程式經理或開發人員提供的開發進度表。
        根據產品的特性及開發進度安排，測試人員制定具體的測試計劃。測試計劃通常包括以下內容：
        1）測試目標和發布條件：
        a. 給出清晰的測試目標描述；
        b. 定義產品的發布條件，即在達到何種測試目標的前提下才發行就緒產品的某個特定版本。
        2）待測產品範圍：
        a. 軟體主要特性/功能說明，即待測軟體主要特性的列表；
        b. 特性/功能測試一覽，應涵蓋所有特性、對話方塊、菜單和錯誤資訊等待測內容，並列舉每個測試範圍內要重點考慮的關鍵功能。
        3）測試方法描述：
        a. 定義測試軟體產品時使用的測試方法；
        b. 描述每一種特定的測試方法可以覆蓋哪些測試範圍。
        4）測試進度表：
        a. 定義測試裡程碑；
        b. 定義當前裡程碑的詳細測試進度。
        5）測試資源和相關的程式經理/開發工程師：
        a. 定義參與測試的人員；
        b. 描述每位測試人員的職責範圍；
        c. 給出與測試有關的程式經理/開發工程師的相關資訊。
        6）配置範圍和測試載入器：
        a. 給出測試時使用的所有電腦平台列表；
        b. 描述測試覆蓋了哪些硬體裝置；
        c. 測試時使用的主要測試載入器。
        此外，還應列出測試中可能會面臨的風險及測試的依賴性，即測試是否依賴於某個產品或某個團隊。比如此項測試依賴性WindowsCE這個作業系統，而這個系統要明年2月份才能做好，那麼此項測試就可能只有在明年5月份才能完成，這樣就存在著依賴關係。如果那個團隊的開發計劃往後推，則此項測試也會被延遲。
3. 測試案例開發
        一個好的測試案例就是有一個合理的機率來找到Bug，不要冗餘，要有針對性，一個測試只針對一件事情。特別是功能測試的時候，如果一個測試是測了兩項功能，那麼如果測試結果失敗的話，就不知道到底是哪項功能出了問題。
        測試案例開發中主要使用的技術有等價類別劃分，邊界值的分析，Error Guessing Testing。
        等價類別劃分是根據輸入輸出條件，以及自身的一些特性分成兩個或更多個子集，來減少所需要測試的用例個數，並且能用很少的測試案例來覆蓋很多的情況，減少測試案例的冗餘度。在等價類別劃分中，最基本的劃分是一個為合法的類，一個為不合法的類。
       
邊界值的分析是利用了一個規律，即程式最容易發生錯誤的地方就是在邊界值的附近，它取決於變數的類型，以及變數的取值範圍。一般對於有n個變數時，會有
6n+1個測試案例，取值分別是min-1, min, min+1, normal, max-1,
max,max+1的組合。邊界值的分析的缺點，是對邏輯變數和布爾型變數不起作用，還有可能會忽略掉某些輸入的組合。
       
Error Guessing
Testing完全靠的是經驗，所設計的測試案例就是常說的猜測。感覺到軟體在某個地方可能出錯，就去設計相應的測試案例，這主要是靠實際工作中所積累的
經驗和知識。其優點是速度快，只要想得到，就能很快設計出測試案例。缺點就是沒有系統性，無法知道覆蓋率會有多少，很可能會遺漏一些測試領域。
實
際上在微軟是採用一些專門的軟體或工具負責測試案例的管理，有一些測試資訊可以被記錄下來，比如測試案例的簡單描述，在哪些平台執行，是手工測試還是自動
測試，啟動並執行頻率是每天運行一次，還是每周運行一次。此外還有清晰的測試通過或失敗的標準，以及詳細記錄測試的每個步驟。
4. Bug跟蹤過程
       
在軟體開發項目中，測試人員的一項最重要使命就是對所有已知Bug進行有效跟蹤和管理，保證產品中出現的所有問題都可以得到有效解決。一般地，項目組
發現、定位、處理和最終解決一個Bug的過程包括Bug報告、Bug評估和分配、Bug處理、Bug關閉等四個階段：
        1）測試工程師在測試過程中發現新的Bug後，應向項目組報告該Bug的位置、表現、目前狀態等資訊。項目組在Bug資料庫中添加該Bug的記錄。
        2）開發經理對已發現的Bug進行集中討論，根據Bug對軟體產品的影響來評估Bug的優先順序，制定Bug的修正策略。按照Bug的優先順序順序和開發人員的工作安排，開發經理將所有需要立即處理的Bug分配給相應的開發工程師。
        3）開發工程師根據安排對特定的Bug進行處理，找出代碼中的錯誤原因，修改代碼，重建產品版本。
        4）開發工程師處理了Bug之後，測試人員需要對處理後的結果進行驗證，經過驗證確認已正確處理的Bug被標記為關閉（Close）狀態。測試工程師既需要驗證Bug是否已經被修正，也需要確定開發人員有沒有在修改代碼的同時引入新的Bug。
5. Bug的不同處理方式
        在某些情況下，Bug已處理並不意味著Bug已經被修正。開發工程師可以延遲Bug的修正時間，也可以在分析之後告知測試工程師這實際上不是一個真正的Bug。也就是說，某特定的Bug經開發工程師處理之後，該Bug可能包括以下幾種狀態。
        已修正：開發工程師已經修正了相應的程式碼，該Bug不會出現了。
        可延遲：該Bug的重要程度較低，不會影響當前應提交版本的主要功能，可安排在下一版本中再行處理。
        設計問題：該Bug與程式實現無關，其所表現出來的行為完全符合設計要求，對此應提交給程式經理處理。
        無需修正：該Bug的重要程度非常低，根本不會影響程式的功能，項目組沒有必要在這些Bug上浪費時間。
五、成為優秀測試工程師的要求
       
要成為一名優秀的測試工程師，首先對電腦的基本知識要有很好的瞭解，精通一門或多門的程式設計語言，具備一定的程式調試技能，掌握測試載入器的開發和使用技
術。同時要比較細心，會按照任務的輕重緩急來安排自己的工作，要有很好的溝通能力。此外，還要善於用非常規的方式思考問題，儘可能多的參加軟體測試專案，
在實踐中學習技能，積累經驗，不斷分析和總結軟體開發過程中可能出錯的環節。這樣，一名優秀的測試工程師就從軟體測試的實踐中脫穎而出了。
       
結束語：微軟的軟體開發經驗積澱深厚，微軟工程師們的授課生動溢彩，其中有些內容是結合編程代碼所作的詳細講解，較難用介紹性文字加以概括提煉，加之筆者
受能力和精力所限，只能擷取部分精華內容整理成文以饗讀者，因此難免是掛一漏萬，甚至會有失誤之處，敬請對本系列文章的粉絲諒解及指正。最後對微軟老師
們的辛勤付出再表由衷謝意！