我對微軟SDET的親身感受
| 關於微軟SDET職位，是一個很有爭議的話題。 我不想說SDET多麼多麼好，也不想說它多麼糟，這裏我以一個微軟（總部）SDET的身份來講一下，給大家最真實第一手的資料。 國內的SDET，似乎大多是外包的vendor，比如中軟什麼的。就算美國這邊，vendor公司來的SDET也很多，做的工作的確比較枯燥無聊，我個人是在windows，以前team裏面除了我們這些正式sdet，還配了一個vendor的sdet，對方的職責就是每天把我們的測試工具（已經完全自動化了）跑那麼幾遍，比如在x86上跑一次，amd64機器上跑一次，windows client跑一次，windows server跑一次，然後如果有問題，就給我們正式的發郵件讓我們去看怎麼回事情-----呃，我有時候覺得他們能堅持這種工作也算是很有耐心了。 有些vendor sdet會稍微有挑戰性一點，比如在跑我們的自動測試工具時，發現了問題，有些sdet會自己去debug，把bug找到，然後再給我們很仔細的報告。嗯，從vendor的角度來說，最多就是做到這樣了。 vendor sdet開發測試工具？我反正從來沒見到過，有的話估計也就是他們自己team裏面用。 （說一下vendor sde，核心產品組很少有vendor sde，其它一些不太重要的，比如MSIT（對微軟內部服務的IT部門）有不少vendor sde，還有些偏business的也不少,windows/office/包括bing，都很少有vendor sde，xbox那邊好像也有一些） vendor說完了，來說微軟正式的SDET。 的確，微軟對SDET的說法沒錯：Software Developing Engineer in Test. 作爲一個SDET，你不可以避免開發測試工具，而全自動測試工具的開發更是極大的挑戰，要自動控制多臺機器？用socket呢還是用.NET remoting？測試底層驅動寫底層filter driver，多線程控制／同步，各種底層Win32的調用，包括一些SDE也不會用到的算法和framework的設計，這些都是一個SDET日常工作的一部分。微軟的SDET，的確可以說跟其它公司的QA/SDET有本質差別，我有幾個朋友跳槽去了加州硅谷那邊，他們就是說那邊的所謂ＱＡ／SDET都基本上是不寫代碼的，不想微軟這邊的SDET，寫代碼是重要工作之一。 我看到有篇文章說微軟的senior SDET很少，Principle SDET更少，呃．．．那篇帖子大概比較早了，現在微軟裏面的Senior SDET是很多了，Principle SDET．．．這個還是少，本來priciple的sdet也好／ＰＭ也好／ＳＤＥ也好，本來就不多。 上面說的主要是微軟SDET在開發方面的工作內容，和SDE不同的一點是SDET在很多時候需要更廣泛的技能，比SDE更廣的技能。最簡單的例子，一個做底層驅動的team，SDE就是純粹用C開發，而SDET除了需要用C來測試API之外，還要開發自己的自動化testing tool，這個就由SDET自己設計，用C\C++\COM\C#\...隨便你用什麼方式都可以。所以有種說法是：SDE是Depth first,SDET是Breath First. 此外，對SDET來說，很重要一點是對Scenario的設計和測試。對SDE來說，只要實現特定功能就行了，說穿了就是我這幾個function或者我這個component保證是正確的就可以，而對SDET來說，要測試的不單是某個具體function，一般來說要用程序模擬（自動模擬）用戶行爲，而這個模擬通常會涉及到很多不同的component，不單單是你自己team的部分。在這方面，往往是那些做過多年開發轉過來的sdet比較好，他們比較清楚通常用戶會有那些需求會容易在哪些環節出問題，也就能設計比較好的測試案例。 從設計開發上，對於每個新功能，微軟的SDET是有責任並必須跟SDE一開始就進行討論分析的，這個討論分析並不是簡單的討論如何測試，而是會討論如何實現這個功能，用什麼數據結構，API如何設計，算法是否合理。作爲SDET，這是份內的工作，SDE只有在跟SDET完全討論過之後，雙方達成共識，才能開始寫代碼（關於這個我後面還要說說），所以說在技能上，微軟的SDET跟SDE的要求是一樣的，不然根本無法一起開會討論分析。實際上，在這方面做得好的SDET，都是那些曾經有過多年開發經驗，對難點、解決方法、容易出現的問題都很熟悉的人才能輕鬆指出SDE設計中的問題所在，一般新手SDET還是比較難以在一開始就達到這一點，這個就是看經驗了。 另外軟件測試在學術研究中也有一席之地，近幾年有變熱的趨勢，如何優化測試數據，用儘可能少的測試數據來覆蓋儘可能大的範圍，這也是data mining和相關算法的研究方向之一。 上面說了SDET對開發和技能的要求，想來大家應該清楚了SDET的確在技能上的要求很高，從總體要求來說，並不低於SDE。 但是，我實話實說，從我自己角度來說，我想離開SDET這個職位的原因如下： 1. 雖然SDET也寫大量代碼，一般來說SDET的編程開發工作和測試案例設計(test case design)大概平均是50%:50%，如果你在開發上願意多花點時間，你的工作用70%時間都在開發也是可以的。問題在於，無論如何，開發不是你的工作重點，你的工作是測試別人的程序，你開發的工具再怎麼好，再怎麼複雜，再怎麼高效，其目的總是幫助你測試其它產品，你老闆不會關心你用了什麼算法來提高運行速度。當然，你也可以努力讓你的工具具有通用性，讓其他人或者其它組也能用（這種例子在微軟裏面很多），但是，again，你能做到這一點，是你的bonus，但是除非你真的非常有時間，或者願意耗出非工作時間熬更守夜去完善你的工具，一般來說很難做到這一點，因爲這不是你老闆要求你的工作重點，你老闆對你的要求是把那些測試案例設計完並能自動運行。 2. 作爲SDET，會跟很多部門打交道。有說法說微軟裏面SDE的“地位”高，這有點偏頗。更準確地說，微軟，至少是windows裏面，對某個具體功能，如果其它組遇到問題或者需要幫忙，比如說怎麼我的程序按照msdn的做法卻跑不起啊什麼的，第一選擇是找SDET，而SDE作爲“儘量不要去打擾”的對象，在迫不得已的時候纔去問。雖然我現在不是SDE，但是平時的瞭解就是SDE大部分時間只需要埋頭寫代碼，拿自己辦公室裏面的機器調試，然後check in 代碼就好了，其他基本不管。而SDET除了寫自己的代碼，還要很多其它組交涉（微軟分工很細），比如什麼自動化測試lab，什麼build lab,還有其它雜七雜八的組，因爲你的測試工具要交給其他組去自動化運行，而其它組的自動運行方式又各不一樣．．．總之麻煩事情很多。當然，這也不是什麼壞處，作爲一個SDET，如果你幫很多其它組解決了問題，這可以成爲升職的一個有利因素，對於那種比較積極，熱衷於跟多個部門打交道的，這其實很不錯。 3. 某些公司，或者某些SDET的工作，需要做大量的工具設計和開發，難度相當高。但是，如我前面所說，SDET儘管需要比較多樣化的技能，作爲SDET，你也許需要同時熟悉C\C++\C#\Powershell\SQL\etc.，而且這都是你在某個項目中需要大量使用的技術，但是，對於某個特定方面（比如你在測試的那個功能），畢竟你沒有實現代碼，這方面還是有差距。我前面說了，SDET會跟SDE一起分析功能的實現，但是那僅限於“紙上談兵”，你可以跟SDE討論整個架構實現的問題，可以去討論數據結構如何設計，但是SDET的職責僅限於“討論”，最終的實現仍然要SDE去做（分工如此），而很多實現中的細節和難題，不可能一開始就討論到，仍然需要SDE自己去解決。打個簡單的比方，假設某個功能需要用一個hash table，SDET知道會用hash table並也許會對其設計test case，但是這個hash table的實現，仍然是SDE去做。這就造成一個問題，雖然SDET可能開發了很好的工具來測試某個功能，但是對於這個功能本身（打個比方說DirectX或者TCP/IP協議）的實現，他並不如SDE瞭解得透徹，這是很容易發現的，因爲很多細節問題，只有親手去實現纔會碰到。這會有什麼問題呢？這個問題就是在你跳槽的時候，如果想轉developer會很不利，拿前面的例子，你去面試，你說我們什麼什麼東西里面用hash table怎麼怎麼樣，別人說好啊，那你來寫一下代碼實現這個hash table吧，如果是SDE，這是已經做過得工作（並反覆修改過各種bug），如果不是太久遠的project，馬上就可以輕車熟路寫出來，還可以大談我當時做得時候遇到過什麼什麼問題並怎麼怎麼解決了。而對SDET，你畢竟沒有親手去做過，所以能力強的也許能當場實現，弱一點的就歇菜了...好，假設你說我就是對測試工具開發感興趣，我不喜歡開發，我仍然去應聘SDET，問題是絕大部分公司並沒有微軟這樣重點開發自動測試工具的SDET職位，大部分就是簡單完全手工測試的QA，基本無須寫代碼。如果你仍然對programming感興趣，那些QA的職位你是不想要的。 當然，如果你就是喜歡純粹的QA,那麼微軟SDET的經驗會是很好的背景。 寫了這麼多，我有點擔心是不是泄露內幕太多了，在我停筆之前，我總結一下： SDE: fix bugs, design/develop new features in products SDET: find bugs, design/develop testing tools(if necessary) 還有種說法，我聽過有人說：在xx組裏面，其實SDET乾的活也跟SDE差不多了。 我對這種說法就不發表評論了，反正我從來沒聽過有SDE說：我們乾的活跟SDET差不多。 [ 本帖最後由 ffonline 於 2010-5-23 10:50 編輯 ] |