590
社区成员
发帖
与我相关
我的任务
分享微软SDET，最真实的介绍
关于微软SDET职位，是一个很有争议的话题。
我不想说SDET多么多么好，也不想说它多么糟，这里我以一个微软（总部）SDET的身份来讲一下，给大家最真实第一手的资料。
CSDN讨论的微软SDET，似乎都是外包居多。就算美国这边，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比较好，他们比较清楚通常用户会有那些需求会容易在哪些环节出问题，也就能设计比较好的测试案例。
另外软件测试在学术研究中也有一席之地，近几年有变热的趋势，如何优化测试数据，用尽可能少的测试数据来覆盖尽可能大的范围，这也是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，如果你帮很多其它组解决了问题，这可以成为升职的一个有利因素，对于那种比较积极，热衷于跟多个部门打交道的，这其实很不错。
写了这么多，我有点担心是不是泄露内幕太多了，在我停笔之前，我总结一下：
SDE: fix bugs, design/develop new features
SDET: find bugs, design/develop testing tools
我听过有人说：在xx组里面，其实SDET干的活也跟SDE差不多了。
well，it's OK to have positive thoughts about the job you are working on. 我对这种说法就不发表评论了，反正我从来没听过有SDE说：我们干的活跟SDET差不多。
我不想说SDET多么多么好，也不想说它多么糟，这里我以一个微软（总部）SDET的身份来讲一下，给大家最真实第一手的资料。
CSDN讨论的微软SDET，似乎都是外包居多。就算美国这边，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比较好，他们比较清楚通常用户会有那些需求会容易在哪些环节出问题，也就能设计比较好的测试案例。
另外软件测试在学术研究中也有一席之地，近几年有变热的趋势，如何优化测试数据，用尽可能少的测试数据来覆盖尽可能大的范围，这也是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，如果你帮很多其它组解决了问题，这可以成为升职的一个有利因素，对于那种比较积极，热衷于跟多个部门打交道的，这其实很不错。
写了这么多，我有点担心是不是泄露内幕太多了，在我停笔之前，我总结一下：
SDE: fix bugs, design/develop new features
SDET: find bugs, design/develop testing tools
我听过有人说：在xx组里面，其实SDET干的活也跟SDE差不多了。
well，it's OK to have positive thoughts about the job you are working on. 我对这种说法就不发表评论了，反正我从来没听过有SDE说：我们干的活跟SDET差不多。
...全文
请发表友善的回复…
发表回复
feifeihen2 2011-07-05
- 打赏
- 举报
好帖子，顶楼主！
zexi0409 2010-07-12
- 打赏
- 举报
非常感谢~
至少知道了什么是SDET了~
其实vendor的工作的无聊还是可以的~
大家已经都习惯了...
至少知道了什么是SDET了~
其实vendor的工作的无聊还是可以的~
大家已经都习惯了...
tangchao5220 2010-05-23
- 打赏
- 举报
lijavasy 2010-05-23
- 打赏
- 举报
写得不错,学习ing!
哀 2010-05-22
- 打赏
- 举报
草哥你发的什么被删了？
哀 2010-05-22
- 打赏
- 举报
The_End_Of_The_World 2010-05-22
- 打赏
- 举报
