新人报道，看微软如何做软件测试

该用户已存在007

新人报道，先转贴下微软tester的blog：
另外大家如果希望这个中国的微软测试团队介绍点什么，请跟贴说明哦~~
保证有问有答！



一位软件测试开发工程师的成长体验
[原文发表地址] 在微软当软件开发测试工程师的故事

[原文发表时间] Tuesday, February 24, 2009 3:45 PM


背景资料：李敏，2005年开始在微软实习，半年后研究生毕业成为正式员工，先后经历了System Center Configuration Manager 2007以及SP1、R2的发布，测试的领域涉及UI测试、AMT feature和安全测试等。这篇博客，是她想分享给大家的一些体会和故事，一来给不熟悉测试工作的读者描绘一下在微软当软件测试开发工程师是怎么回事情，二来“揭秘”一下微软的职业发展体制 ——


    2005年的秋天，李敏还在上海交通大学念研究生，还有半年就要毕业了。一天，同学发了个链接给她，是微软在上海招聘实习生的消息，职位的名称叫做软件测试开发工程师（Software Development Engineer in Test，简称SDET），这个职位对学生来说还是个新鲜玩意儿，没几个人清楚具体情况，在好奇心的驱动和微软的吸引力之下，她投出了简历。接着她经历了传说中的微软“五轮面试”，走出美罗大厦的时候已是下午一点，时至今日她对这个时刻的印象只有两个：饥肠辘辘，大脑高速运转。经过一周的焦急等待之后，她同时收到了SDET实习生和正式员工的offer，所在的组是System Management Server（也就是System Center Configuration Manager 2007的上一个版本）。

    就这样，李敏开始了在微软当软件测试开发工程师的旅程。

    几个月过去了，当同学好奇地问起在微软工作的感受和SDET的情况时，她说了自己的“微软测试初体验”：


测试初体验一、软件测试开发工程师，很“奢侈”很“酷”
    问起对软件测试开发工程师的第一印象是什么，她的回答是：挺“奢侈”挺“酷”的。

    说到“奢侈”，先看看一个软件测试开发工程师的典型“测试财产清单” —— 一到两台配置先进的工作机；两个21寸的液晶显示器，一个屏幕用来显示产品的界面，另一个屏幕用来发bug或者编程序；再加上实验室里面十几台测试机器或是一个16G内存的“巨无霸”。如果你需要测试Windows Mobile，那恭喜你了，各式各样的smart phone、pocket PC可以装满一抽屉。经过一段时间的了解后，她也知道了这样“奢侈”的配置一方面可以提高工作效率，更重要的是让测试工程师能够考虑到各种复杂的配置以及模拟客户环境。

    说到“酷”，印象中，软件测试开发工程师总是有机会走在尝试各种微软新技术、新产品的前端，也总是有机会通过动手能力来展示自己的“酷”。比如工程师会把十几台测试机器装成各种各样不同的Bench， 操作系统从Windows 2000、XP到最新的Vista、Longhorn甚至Windows 7，从x86到x64，从英文到德文、中文、日文等；微软最新的产品或者尚未发布的产品都可以拿来“研究”一把，比如Longhorn、Windows 7、Hyper-V等；虽然不一定考过MCSE，但是每个人都会配置DNS、DHCP、AD、network等。

该用户已存在007

测试初体验二、测试有时候就像是玩游戏，找问题的能力很重要
    测试就像是玩游戏？也许你会觉得不可思议。李敏拿了道面试题来打比方，给你一台笔记本电脑，你会怎么去测试它？这是一道典型的开放式问题，即使是没有测试知识的人也可以想出很多的“测试用例”。比如检查笔记本的型号、颜色、硬件配置、屏幕、电池、操作系统等，相信这是很多人拿到新买的笔记本之后做的第一件事情，这些多半都属于常规的正向功能测试；还有些人指出，外观要小巧方便携带，键盘手感如何布局如何，功能键是不是方便易用，这些人对可用性要求比较高；还有些会想到用它来玩3D游戏看看显卡的性能怎么样；有些人想到装上Vista、64位的操作系统，这就是兼容性方面的考虑；还有人思维“不走寻常路”，提出要把笔记本放在赤道的日照、南极的冰雪环境下试试能不能正常工作，当砧板切切菜，扔下楼看看碎不碎，这就是关于可靠性和压力方面的测试，有趣的答案还可以有许多许多，只要你去想…

    在李敏的描述中，软件测试开发工程师真实的日常工作跟答这道题一样的好玩，只不过笔记本电脑换成了软件程序。软件测试开发工程师拿到“笔记本电脑”之后，会像上面说到的一样开动脑筋仔细检查，检查之前需要列出想测试的各个方面、策略、工具、风险以及怎么开展等，这称为测试计划（test plan）；每项具体的测试叫做测试用例（test case），每个test case需要列出具体操作步骤（steps）；找出来软件的缺陷、问题等称为bug，bug中需要记录怎样去重现它，称为重现步骤（repro steps）；找bug的过程中你可以试图找出根本原因在哪里、甚至哪一行代码有问题，这就是debugging。优秀的软件测试开发工程师在这个“玩游戏”的过程中需要具备足够的好奇心，想出各种各样的主意把软件“搞坏”，尽可能地找出bug，还要多从客户的角度去想，其终极目标就是为发布到客户手中的软件把好质量关。其中，找bug是软件测试开发工程师应该具备的基本功。

    不久她就找到机会“测试”了一把自己的SDET指数，正好高性能计算组举办找bug比赛，优胜者可以获得一些小礼品，她拿到了一个印有Microsoft标志的水杯。

这时候，她的一个高中同学在MSN上面发了条消息：“你当了测试工程师，就不用编程了吧？”。看来需要澄清一下了：


测试初体验三、谁说软件测试开发工程师不用写代码了？
    微软早年也设有只做手工测试而不写代码的职位，称为STE(Software Testing Engineer)。现在所有的测试工程师的职位都叫做SDET(Software Development Engineer in Test)，从名字可以看出来，需要具备编程能力，这些编程工作是为了更好地做测试。

    举个例子，李敏负责的某个UI模块有1000多个测试用例，手工执行一遍想想都很累。为了偷懒，她写了些代码将其中80%的测试用例实现测试自动化，这样下班前只要让机器开始跑自动化，第二天就可以拿到结果，从而大大减少了验证这些测试用例所需要花的人工时间，又可以及时地捕捉到bug。此外，软件测试开发工程师经常会做一些实用的测试工具和研究测试技术，比如开发UI测试方面的工具，开发测试流程管理工具，和更好地运用基于模型的测试方法等。在坚持创新的公司文化引导下，大家都非常注重运用新技术新方法，不断地把测试工作推进到新的高度。

    转眼间，一年过去了,李敏从上海的服务器与开发工具事业部老大谢恩伟的手中接过了一周年的水晶纪念碑，按照惯例还请大家吃了一磅的M&M巧克力。2007年秋天，她所在的团队发布了System Center Configuration Manager 2007。在这段时间里，她亲身体验了微软给员工提供的多种多样的成长帮助：


职业发展体验一、员工成长路上的多种帮助
    从加入公司的第一天起，部门就分配了一个资深员工给李敏做“Mentor”，Mentor的意思是良师益友，也就是“师傅”。Mentor会手把手地教日常工作中碰到的各种问题，很多小问题都可以请教Mentor，比如打印机怎么用、测试用例怎么设计、甚至是开会的时候有个缩写名词没听懂等。第一个Mentor的作用就是“师傅领进门”。

    公司还提供了系统的专业知识培训。半年内，她先后参加了New SDET in Microsoft、Test Automation等培训，这些都是测试工作的基础知识。说起“修行在自身”，公司MyLearning网站上有不少测试专题，比如性能测试、代码覆盖率研究和安全测试等；这个网站有无数的在线课程录像，在这里可以学习其他员工的知识和经验，帮助自己更好地做测试工作；近期即将进行的技术讲座、培训、会议等也会在这里公布，热门专题一定要早点去注册“占座”，否则就没位子了。另外，她还发现了一个非常棒的资源MSLibrary，那里有无比丰富的技术书籍、新闻杂志和研究论文等。公司还投资了一系列的综合能力培训，为员工提供从各方面提升“软”技能的平台：有些培训是语言方面的，比如觉得英文不够好的可以去上课，老外来到中国也可以学中文；还有一些是教你“怎么说话”的，比如告诉你怎么精准提问、精准回答，怎样做演讲，怎样去沟通得到大家都想要的结果；还有一些教你“怎么思考”，比如创新思考，不同情况下的思考方式等。这些培训很实用，一般学完了就可以运用到实际工作和生活中。

    再后来，李敏对安全测试的兴趣日渐浓厚，她根据自己的发展需求和兴趣找了美国这方面的“大牛”来做Mentor，渐渐地在System Center Configuration Manager 2007 SP1中挑起了做安全测试的担子。她还在上海的服务器与开发工具事业部中组建了一个跨产品组的虚拟团队，一方面带领团队成员学习安全知识和安全开发流程，另一方面积极向各个产品组推广实施安全开发流程的最佳实践经验。虚拟团队的成员来自各个不同的产品组，能花在安全方面的时间都是“工作之余”，要带领这个团队凝聚力量朝一个目标努力是并不容易的事情。最初组建团队的时候，她会用自己对安全方面的热情感染其他有兴趣的人，接着用事例让大家认识到安全对于微软产品真的很重要，而且安全方面的知识对于长期的职业发展也很有帮助，就这样“招募”到了团队的最初几个核心成员。接下来就是确定这个组的远景、使命和活动计划，她先提出了一个草案然后组织大家一起讨论，经过一番“激烈”辩论、修正大家达成了共识。其实，最大的困难还是来自于按照计划一步一步地开展活动，在团队成员兴趣减退的时候，需要振作士气让大家重新记起“最初的梦想”；在一些成员特别忙的时候，需要灵活修改计划，让他们能两头兼顾；另外还要考虑怎样能够更好地把安全意识和最佳实践经验传递给所有员工，比如会选择技术讲座、安全知识简报和展示等多种宣传方式。在这个过程中，李敏学到了很多东西，尤其是“influence without authority”的领导方式，通过影响来带动别人，而不是通过上下级的权威去要求别人。

    此时，她对微软的职业发展也有了更加深刻的认识：


职业发展体验二、微软的职业发展道路为不断挑战自己的人而设计
    关于员工的职业发展，年中的时候会专门有一个关于职业发展的讨论（Mid-Year Career Discussion，在公司内部内部简称MYCD）。经理会和员工一对一坐在一起，评估员工现在所处的发展阶段、能力水平等，讨论员工的未来三到五年的职业发展规划，然后进一步制定实施计划。微软给员工的职业发展道路也比较灵活，总体上有个人贡献者（Individual Contributor，简称IC）和管理（Management）两条职业发展轨迹。

    软件测试开发工程师属于IC，也是李敏最初选择的轨迹。在微软，资深工程师很受尊敬也很有影响力。公司为工程师设计了具有挑战性的职业发展道路，所以，在这儿碰到一个为微软服务了十几年的工程师是稀松平常的事情。对于软件测试开发工程师来说，可以一路从Test（初级）做到Test II（中级），Senior Test（高级），甚至Principal Test（首席），随之而来的挑战是测试工作的范围、影响力不断扩大。比如一位Senior Test的挑战可能是对整个产品的测试工作做出很大的贡献，而一位Principal Test面临的挑战则是在整个Microsoft倡导新的测试技术，这都需要多年的积累，也很有挑战性。还有一个职位叫做Test Architect，这个职位负责测试Architect设计出来的architecture，光听听就知道很酷了。

    员工会选择一条职业发展轨迹前进，但也可以根据兴趣和能力进行调整。从2007年开始，李敏的小组需要将部分测试工作外包出去，李敏在经理的指导下开始参与组建和发展外包软件测试组的工作，这让她发掘了自己在管理方面的兴趣和潜力。组建外包测试组的第一步是招人，先确定职位所需要的能力，然后筛选简历，开始面试，多方面考察候选人，最终做出决定。然后是培训工作所需要的知识，老组员带新组员，要求新组员在一周之内学会并可以上手工作。接着是制订一些规范流程，让组员知道怎样去高效地独立工作，也让整个过程更便于管理。比如，为了保证自动化的代码质量，李敏搭建了一个回归测试平台和一个网站，所有的自动化必须在这个平台上通过3次，才能去网站上把它们标记为“自动化完成”。此时这个组能够较好地运作起来了，李敏会和组员定期会进行一对一的谈话，了解他们的状态和遇到的问题等，综合分析之后会想一些办法去优化流程和提高团队的效率。经过观察，她还确定了一些技术能力和综合能力不错的组员，适当授权给他们去担当更多的责任，发挥他们的聪明才智，也减少自己的管理成本。整个过程下来，她发现管理很有意思也很挑战，自己有兴趣也有潜力去做，于是她在一个MYCD里调整了职业发展轨迹。经理了解之后也给与了相应的支持和辅导，比如会建议如何去“打磨”管理方面的技巧，也会抛出问题让她自己去思考该怎么解决、怎样做得更好。

    选择不同的职业发展轨迹是一种挑战，而换个产品甚至迈进一个完全陌生的领域是另一种挑战。她身边就有一些同事选择加入其他的产品组。在这一点上，微软多元化的产品结构给员工提供了特别好的机会，从Windows到SQL Server、Visual Studio，从Office到XBox、MSN等，跨度很大，就像是一个“IT业界”。员工总能找到挑战自己的机会，做熟了这个产品还可以做另外一个产品。在微软，经常可以看到工作了多年依旧保持着高度激情的员工，这恐怕是和公司提供的多元化的职业发展道路是分不开的。

    时间如白驹过隙，2009年已经到来，她所在的组正在做下一个版本的Configuration Manager，她也在带领一个小组负责产品的UI测试工作。

    回顾这三年半的历程，激动人心的挑战、解决问题的成就感以及团队合作的乐趣始终伴随左右。而抬头向前看时，还有太多未知的探索之旅等待着。

    希望大家能喜欢这些心得与经验的分享。
李敏

mentgmery

你的用户很有意思,呵呵,支持

hueslife

好像在给微软打广告，哈哈::yiwen:::

mentgmery

呵呵,微软不用做广告,能让微软做广告的,只有google

该用户已存在007

这个不是做广告
是认真的。。。。

如果大家希望了解微软测试的方方面面， 都请留言。

主要是微软最近在打算做一个测试方面的论坛，分享经验和技术什么的。 现在需要了解国内测试领域大家比较关心什么，这样才好定优先级

luxiwen

以前看过了

helina168

原帖由 该用户已存在007 于 2009-9-15 18:33 发表
这个不是做广告
是认真的。。。。

如果大家希望了解微软测试的方方面面， 都请留言。

主要是微软最近在打算做一个测试方面的论坛，分享经验和技术什么的。 现在需要了解国内测试领域大家比较关心什么，这样才 ...

莫非你是策划人？

helina168

关心中国的测试什么时候能发展平衡点；
关心国内各个公司的测试流程什么时候能达到一个规范（像我现在所在的公司那样的该淘汰）；
关心公司啥时能把测试看在眼里；
关心测试这条路应该如何走下去，像我这种瞎灯摸路的不知道前方等待我的是什么，太有风险了；
关心测试的地位什么时候能跟开发平起平坐；

liujinkui

环境真好。你上面说到的两个学习论坛和学习库能共享链接吗？

bood

支持楼主，想法不错啊~

该用户已存在007

我不是策划人, 但是相信负责人能够了解到这些反馈

现在我只能根据我自己的感受针对上面几点发表下看法


关心中国的测试什么时候能发展平衡点；

首先什么叫做平衡. 我没有在不同的企业呆过,所以不确定这个命题本身的确切含义. 但是从上下文来看,我想您说到的, 应该是指偏开发,轻测试. 不知道是否是这个意思.

微软的开发和测试比例大概是1.2:1.一般来说 测试人员是不会直接对最后发布的产品有代码上的任何贡献的. 这个数据深层次的意思是, 微软发布的软件里面, 测试人员的工资等成本占用率大概是35%这样. 我想这个比例, 对于很多小企业来说, 是绝对不可以承受的. 那个老板会花这么多没有直接贡献的冤枉钱呢?

但是我们回头想,微软也不是傻瓜,为什么微软愿意花这么多钱来做test. 其实这是和产品本身的质量,还有市场非常相关的. 微软的产品发布后, 由于其用户规模巨大, 任何小的bug, 或者补丁的发布, 带来的额外成本都要乘上一个巨大无比的系数. 所以从市场还有利润的总体考虑出发, 花更多的钱,来保证产品的高质量,能够减少后继的维护开支. 所以产品和市场的不同, 导致了测试的比重不同.

除此以外, 微软的产品,一旦开始做, 就会一个版本一个版本做下去. 所以微软非常强调复用.  比如说windows, WinXP的case, 到了Vista肯定都要重新跑的, 而且只要windows不死, 会永远跑下去. 另外如果出补丁比如sp1, sp2, 都要跑. 这个总不能每次都人工跑吧.  所以,为了节省开销, 微软宁愿多花钱, 找高质量的测试人员来开发自动化测试. 这就是花小钱, 省大钱的道理.


所以呢, 中国的测试要找到所谓的平衡点, 是要把产品和市场结合起来看的. 什么时候中国需要发布高质量的, 大规模用户覆盖的产品, 什么时候测试的比重就会上来, 到时候自动化测试, 国际化测试, 用户体验测试等等问题才会真正地被考虑. 而鉴于现在国内软件的大环境, 我个人很难预料以后的发展状况.

不过, 这个情况其实一点也不悲观, 这个问题我在解释后面几点的时候就会提到, 不平衡只是一个现实, 不意味着没有机会或者没有发展. 当然, 如果你的目标就是找一个相对"平衡"的环境工作, 你可以考虑如何加入比较"平衡"的公司和产品团队.

bood

LZ好象是哪个技术论坛的管理吧，到这里好做007？

该用户已存在007

另外请大家也帮忙贡献下. 说说微软在软件测试的哪些方面,使您感兴趣的.

比如流程, 技术, 职业发展, 疑难问题, 还是趣味插曲什么的? 比让我一个人说阿,到时候搜集不到信息, 老大把这个项目取消了就....

mentgmery

你们是做外包的吗？

该用户已存在007

原帖由 mentgmery 于 2009-9-15 22:00 发表
你们是做外包的吗？

不是外包
虽然我们也招聘外包公司的员工

该用户已存在007

undefined

原帖由 helina168 于 2009-9-15 21:19 发表
关心国内各个公司的测试流程什么时候能达到一个规范（像我现在所在的公司那样的该淘汰）；

关心国内各个公司的测试流程什么时候能达到一个规范（像我现在所在的公司那样的该淘汰）；


关于这个问题, 我的看法是, 为什么要让不同的公司都遵循同一个规范呢?

在微软内部,不同项目,甚至不同小组的测试方法或者说规范都是不一样的. 其实我个人看到的测试水平也都参差不同. 但是, 这并不阻碍一个成功的产品诞生.

就我做过的项目里面, 还有测试人员在项目紧急关头全体冲上去帮忙修产品bug的, 这样是符合规范的做法吗?

其实针对类似的问题, 我问过我们这里的资深测试经理. 大致是这样问的

作为一个测试人员, 衡量工作的最终标准是什么? 是尽早地找到产品的bug吗? 工作过程中需要遵循的最终规范是什么？ 是bug bar吗？是进度吗？在必要的情况下可以对产品质量作妥协和让步吗？应该用怎么样的态度来面对一些进退两难的问题，比如在进度压力大的时候是否可以牺牲产品质量？

这个测试经理的回答原文节选：
“If feature team needed, test team should do whatever they are capable of doing to help feature team deliver the commitment including: doing a PM job in helping feature spec, doing a dev job helping dev unit test, or even fixing bugs, or UA job writing doc..etc.  When/how test team need to cross the discipline boundary is something feature team should decide and agree on based on their needs and priority”

换句话说，测试人员的终极标准只有一个：用尽一些办法帮助项目的成功。 这是最终的目的， 一切所谓的规范，规则等等，都是为了这个目标服务的。 从另外一个方面来说， 无论测试规范如何严禁， 无论测试人员找bug是多么的高效， 如果最后项目失败了， 那测试人员也是失败的。


所以， 所谓测试规范， 都是为了产品的成功而服务的。 而不同项目和不同产品的情况千差万别， 所以测试规范并没有统一的形式。 单纯追求规范是一个非常危险的信号。

我的建议是， 于其关心规范本身， 不如更深入地研究怎样的测试方法才能够帮助项目的最终成功。 对既有的黄金规范进行针对性地改革，使之适合国情，适合项目， 使其对项目做出最高效的贡献，才是正确的做法。

chenwei8822

夏竹

第一次看到李敏的文章，感触很深。虽然很早知道微软有“软件测试开发工程师”一说，但具体做什么通过读了这篇文章才知道的。努力吧！测试还是有前途的！

车棚居士

强人，经历很传奇。