51Testing软件测试论坛

标题: 我对微软SDET的亲身感受 [打印本页]

作者: ffonline 时间: 2010-5-23 10:40
标题: 我对微软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 编辑 ]

作者: 8596991 时间: 2010-5-23 19:18
怎么感觉非常的乱？按照楼主所说，个人感觉SDET比SDE要厉害的不止一点点啊

作者: zhangting85 时间: 2010-5-23 20:15
原来sdet也要设计测试用例哇？不是纯编写工具吗。

作者: shanxi 时间: 2010-5-23 20:17

原帖由 8596991 于 2010-5-23 19:18 发表
怎么感觉非常的乱？按照楼主所说，个人感觉SDET比SDE要厉害的不止一点点啊

LZ所说的意思是SDET比SDE干的活要逊色不少，至少在开发代码这块。

微软中国不少SDET干的活是Design Test Case而不在写代码吧。

作者: ffonline 时间: 2010-5-24 05:42

原帖由 8596991 于 2010-5-23 19:18 发表
怎么感觉非常的乱？按照楼主所说，个人感觉SDET比SDE要厉害的不止一点点啊

参看我后面列出来三点关于SDET的劣势，尤其是第三点。

从广义来说，如果你想去的职位是要求“熟悉C++/C#/.NET/etc.多种技能”的位置，SDET也许有稍微广一些的技能，SDE不是说就不会C#了，只是工作中未必会用得上，在“广泛面”的条件下，也许SDET可以打90分,SDE可以打70分（注意，这都是指工作1-2年的前提下，对于工作多年的Senior，这很不好说，不过对于工作多年的，我个人感觉从“广泛”的角度看，SDE和SDET差不多，这我个人就没资格评价了）。

但是对于某个具体部分，如我文中所说，比如DirectX的实现、TCP/IP实现、File system的实现和保护等等，SDE就比SDET强很多，毕竟SDE是具体实现者，SDET是辅助。

从Design（架构设计开发）来看，如果都是双方开始，SDET可以更快接触到工具的设计和开发，因为测试工具相对于具体产品毕竟要小一些，考虑的要少一些，SDET可以从设计一个小的工具很快开始独立设计开发。而SDE，我有一些朋友一开始就是SDE，刚开始就会做比较无聊的工作，修改一些bug，过了很久才开始参与到整体的设计（但是都只限于局部），至于完整的重新设计一个单独产品，对刚开始的SDE来说是不可能的。所以也有人说刚开始两年的SDET和SDE各有优劣，不好说谁好谁坏。

但是，again，如我文中所说，以上谈到的“设计、开发”，不是SDET所“必须”做得工作，你的老板不会关心你自己设计开发的工具如何（除非非常非常优秀解决了很多很多问题），他只关心你找到什么bug.而对于SDE，这就使他的全职工作。所以怎么选，就看你自己到底想走哪条路了，正如有人说的：有些人喜欢查找产品的问题，而对如何修正问题兴趣不大，那么就适合SDET；而喜欢改正问题并实现新功能的，对查找问题兴趣缺乏的，就适合SDE。

作者: ffonline 时间: 2010-5-24 05:44

原帖由 zhangting85 于 2010-5-23 20:15 发表
原来sdet也要设计测试用例哇？不是纯编写工具吗。

其实SDET开发工具和测试用例理论上各占50%，但实际上写测试用例的时间更多，开发工具也就是开发那段时间多一些，开发完了就是全力写测试用例了。

作者: ffonline 时间: 2010-5-24 05:45
标题: 回复 3# 的帖子
其实SDET开发工具和测试用例理论上各占50%，但实际上写测试用例的时间更多，开发工具也就是开发那段时间多一些，开发完了就是全力写测试用例了。

作者: havards 时间: 2010-5-24 09:43
建议看看微软的测试之道这本书，你就会明白vaile

作者: hueslife 时间: 2010-5-24 11:09
vaile是什么

作者: 兰猫 时间: 2010-5-24 14:44
标题: 回复 1# 的帖子
呵呵，楼主好厉害，我是微软Vendor，职称也是SDET，但是做的事情远远比你说的那位SDET种类多的去了。
我的MSN：laurashi@live.cn，希望楼主能不吝赐教！

作者: ffonline 时间: 2010-5-24 14:47

原帖由 shanxi 于 2010-5-23 20:17 发表

LZ所说的意思是SDET比SDE干的活要逊色不少，至少在开发代码这块。

微软中国不少SDET干的活是Design Test Case而不在写代码吧。

“逊色不少”也许不是我要表达的意思，解决的问题和手段、目的不同，难以说是否逊色，一个好的SDE并不能马上设计出好的测试framework，反之一个好的SDET也不可能马上能接手SDE的工作。

但是如果光说“开发代码”这个部分，well,如果以此为生的SDE还比不过同样工龄的SDET，我看这个SDE可以被lay off了。

微软中国SDET主要做什么我不清楚，可能有少部分测试工具开发,我也只是在内部文档看看北京那边做什么东西，不好评价。

[ 本帖最后由 ffonline 于 2010-5-24 14:52 编辑 ]

作者: ffonline 时间: 2010-5-24 14:53

原帖由兰猫于 2010-5-24 14:44 发表
呵呵，楼主好厉害，我是微软Vendor，职称也是SDET，但是做的事情远远比你说的那位SDET种类多的去了。
我的MSN：laurashi@live.cn，希望楼主能不吝赐教！

无妨，我对vendor的工作的确不太清楚，大家讨论讨论，只要不涉及公司产品具体细节，我觉得都是没关系的。

作者: havards 时间: 2010-5-24 14:55

原帖由 hueslife 于 2010-5-24 11:09 发表
vaile是什么

笔误：
了的意思

作者: xavier_007 时间: 2010-5-24 17:28
呵呵，上次sdet面试通过了，问得是3个算法题目，在维亚，不知道和楼主说的是不是一个？
最终没有选择，因为是外派，不喜欢。面试的那位说内部的自动化至少95%？是否

作者: liangshi 时间: 2010-5-24 20:30
> 关于微软SDET职位，是一个很有争议的话题。
请问有何争议？

作者: ffonline 时间: 2010-5-25 12:33

原帖由 xavier_007 于 2010-5-24 17:28 发表
呵呵，上次sdet面试通过了，问得是3个算法题目，在维亚，不知道和楼主说的是不是一个？
最终没有选择，因为是外派，不喜欢。面试的那位说内部的自动化至少95%？是否

差不多，内部SDET目的就是开发测试工具，但是同时也要开发配套测试案例(test case)。开发出来了，当然就自动化了。

作者: pity 时间: 2010-7-20 16:30
知名企业招聘出，中，高级测试工程师， lead， pm
知名外企邀SDET（开发测试）

群：
职位： SDET，工作地：深圳
联系方式：[email=Mail to: hrwelcome@live.cn [/email] MSN:hrwelcome@live.cn
1. Must have solid foundation of software developing with C#/c++/Java for 3+ years;
2. Best to have 1+ years of experience in functional testing;
3. Best to be familiar with various testing phases and methodologies;
4. Best to have experience in writing automated test scripts;
5. Knowledge of Internet related technologies and web-services is a must;
6. Best to be able to understand and translate functional requirements/specifications into test cases;
7. Best to be able to develop own test cases from functional specifications;
8. Excellent problem solving skills;
9. Strong communication skills;
10. Good English skills.
1. Help to impove the whole team automation skill level.
2. Drive testing activities (manual&automated) for projects and pre-defined areas of ownership;
3. Writing test plans and holds review (also other recurrent test meetings) with client;
4. Daily summarize and report the project status.
1. Big Picture: USA online travel system.
2. Our Team: Web based (UI&Functional) test.

软件测试工程师(初，中，高级测试工程师， lead， PM):
工作地点：深圳    联系方式：MSN/Email:hrwelcome@live.cn

1. 熟悉测试的基本理论，测试用例，测试计划，Bug系统等。

2. 执行过相应的黑盒测试。

3. 有耐心，能够深入研究相关的业务知识。

4. 具有较好的coding能力，能够独立完成和开发出自己的测试用例。

5. 善于思考并且提出相对应的方案和问题。

6. 态度积极向上，能承受一定的工作压力。

7. 有一定测试工具使用经验。

8.  英文良好。

作者: 愚人 时间: 2010-10-27 22:23
谢谢分享……

作者: yangxiang655 时间: 2012-2-28 22:23

作者: yangxiang655 时间: 2012-2-28 22:26

作者: lujunda 时间: 2014-2-27 16:17
楼主炫耀了半天又怎么样呢。测试的目的是发现bug而不是开发测试工具。一个bug别人用眼一扫看出来了，你用180的智商花12分的心思牛X轰轰地开发n种工具运用各种算法，到最后可能忘了自己的目的是什么，人的精力毕竟是有限的。软件开发阶段你参与的越多越不利于你之后进行测试工作。
所以要独立测试。

作者: linlin212 时间: 2014-3-4 16:37
学习了楼主

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)