李红亮<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
时间过得真快，6个月的实习生涯眼看着马上就要结束了。带着许多的依依不舍，我回忆着这几个月，有经验，也有教训。1次onboard，2次outdoor，2次Internship review，3次demonstration，3次iteration dinner，数次tech talk，数次presentation，5次FTE conversion interview, 6次发津贴，6次all hands，N次mentor one-one，数不清的大大小小team meeting，一堆的Bug，一堆的code review，一堆的buddy test……这么多的回忆，想都想不完。而让我印象最深的，首先是那极具凝聚力的团队。
微软所有产品开发，差不多都有这四个team：Program manager team, Developer team, Tester team, Designer team. 在少数几个Senior manager及Leader的带领下，这四个团队之间的合作可以说是天衣无缝。PM管理着产品的feature，管理产品开发进度，是Developer 和Tester之间、Developer和Designer之间及Designer和Tester之间的粘合剂，使产品开发稳步前进。Developer是产品开发者，根据PM、Designer的想法，加上自己的创意，开发各种各样的prototype，然后根据PM确定的Feature Spec，着手开发产品。在产品开发之初，Developer通过开发prototype或凭经验在技术上确定Feature的可行性、成本和必要性，在开发过程中他们是Feature实现的主体，他们首先会写一些Design spec，然后再根据design来写Code。Code complete后，他们又是 Bug的主要Killer，可以说，Developer是团队中非常核心的人员。而Tester确是产品质量的主要保证。他们通过各种和样的方式来发现产品中的Bug。这些包括Feature test，buddy test，stress test，automation test，bug bash等等。所谓的 feature test就是针对Developer开发的某个Feature，根据PM的spec确定Feature的正确性、完整性，由他们把关Developer开发的Feature该不该Check-in。Buddy test主要是指回归测试。针对Developer对code的change，来回归测试它会不会影响原有的feature，以及测试这个改动是不是达到原有的目的，如是否修正了某个Bug或者是Issue。Stress与Automation Test一般用于发现一些极端条件下的Bug。Bug bash是在Developer code complete之后进行的一段全方位的Feature test。Designer team可以讲是最具创意的一个team，他们设计出来的东西，包括图片、动画、人机交互等等都是非常吸引人的，他们是人机交互的核心设计者，和PM一起保证着产品的通俗易用性。在这个大家庭中，往往能看到这样的交流场面：1、Designer team想到一个好点子，与PM协商确定必要性，然后找Developer做prototype看效果确定可行性；2、Developer完成了一个feature，找Tester测试，Tester发现了一些issue，让Developer改，Developer觉得这是PM Spec中定义较模糊的地方，于是一起与PM协商，最后确定Issue fix的必要性；3、Tester发现一个Bug，很兴奋地assign给Developer owner，Developer知道后几分钟内找到Bu*生的原因，又很兴奋地要Tester测……这样的场面在团队中屡见不鲜。Tester以发现Bug为荣，他们是产品的“破坏者”，想尽办法让产品不工作；Developer则相反，他们以少出Bug多Fix Bug为荣，是产品的忠实守护者，想尽办法Fix bug。团队之间有竞争，也有合作。正是因为这些团队之间的竞争与天衣无缝的合作才能保证微软的产品有着能满足用户需求、具有通俗易用性、技术含量高和产品质量好的特点。这些，也就是我实习过程中，对微软产品开发团队协作过程的认识。
丰富、灵活多样、成熟的管理工具及高效的开发流程是微软高效开发的又一原因。在产品开发过程中，无处不见的工具让产品开发流程变得非常高效清晰。在刚到这实习时，我最先花了得多时间熟悉团队开发过程，熟悉他们用的工具。因为他们的工具实在是太多了。从产品管理、代码管理、Build管理、测试管理、文档管理等等微软都有它独有的工具。这些工具已经经过长期的考验，证明了它们的高效性。独特的一套开发管理模式也正是微软引以为傲的地方之一。举个例，Tester发现一个bug，在BUG管理工具中开一个BUG，相应的Develop实时得知BUG，作改动后，在code review管理工具中提交code review，相应的reviewer Sign off后，通过buddy test工具提交test给tester，tester Sign off后，developer用check-in工具提交buddy build，无错build方可check-in。整个流程中，每个环节都有工具的帮助，保证了流程中各环节的紧密性与实时性。而这个流程却保证了code的质量，Build的稳定性等。
实习过程中，我做过的几个 Demo也是让我难忘的一方面。PM首先有了一个将某个Feature加入产品的想法，然后我们Developer leader要我做了一个很简单的原型，因为原型做得较好，先后给Developer leader、PM team、Group managers、Team core managers做了Demo，并取得了很好的反响。而这个Demo也是我实习生涯的第一个亮点，给Team留下了深刻的印象，包括ATC Team，Japan Team及Redmond Team。也成为Mentor推荐我参加FTE Conversion interview的直接原因，也是我通过这些面试成为FTE的一方面的因素。我觉得Demo成功首先得意于这个Feature本身吸引人，而其技术含量高开发难度大是获得好评的又一因素。而敢于面对挑战、勇于说服Leader、极积主动的工作态度和开发热情是Demo成功的根本原因。正是这些，Mentor在2次微软实习生review中给予了我Excellent的评价。
然而，几个月的实习也让我充分认识到了自己非常大的一个缺点：英语口语水平一定要提高起来。微软所有会议都是英语交流，所有Email都是英语写，所有文档都是英语。这些已经明确地说明了英语在微软的重要性。我的Mentor是美国人，跟他的一切交流都是英语。还好，Mentor的领悟水平极高，有时虽然我不知道表达，他总是知道我要讲什么。但要是碰到一个耐心不是很好的foreigner，该怎么办呢？答案只有一个：努力学好英语！在微软要成长，英语肯定是基础。
总之，6个月的实习，让我在这学到了很多很多的东西，也为我以后人生发展打下了基础。从6个月前的新奇与惊喜，到现在的收获与充实，无一不让我感到快乐。而这个充实与收获的结束，将意味着下一个新奇与惊喜的开始，把握好自己，把握好未来！人生就好像是微软产品开发一样，经过一个个的里程碑，一次一次的迭代，才会使得产品更完善，使得人生更完美！
李红亮 于2008月1月13日
肖于思
我很幸运地在微软亚洲工程院Milan项目组进行了为期四个月的实习，职位为软件测试开发工程师（SDET），工作项目为Surface Computing。我会介绍微软的产品开发流程，测试人员的日常工作以及我的一些额外的工作内容。
微软所有产品的源代码均放在美国的雷德蒙总部，而且微软本身有很多工具，如代码复查和回归测试的网站，BUG管理工具以及运行测试用例的工具等等。每个产品都会有几个重要的发布，像Pilot,Beta,RTM。在每个发布的期间，我们称这段期间为一个milestone。在每个milestone期间，我们会有几个iteration。在每一个iteration间，我们只开发几个功能（一般情况下是一个或两个）。我在微软实习期间经历了三个iteration。在每个iteration的开始阶段，项目经理会编写项目功能说明书以及主持项目功能说明书的讨论会议，与此同时，设计人员会完成设计文档并召开相应的讨论会议。开发人员则会研究如何实现此种功能并参与会议，测试人员则完成测试计划以及一些基本的测试用例并参与会议。在项目经理的功能说明书通过讨论后，项目经理会开始研究讨论下一个iteration的功能和更新功能说明书（如果我们发现了功能说明书的问题）。开发人员开始编写代码实现相应的功能，测试人员会利用这段时间自动化一些手工的测试用例并且为开发人员的代码签入做回归测试。在iteration的最后阶段，大约是两个星期的时候，测试人员会做一次bug bash，即所有的测试人员都来找bug，bug bash一般会做半天。在测试人员bug bash后，开发人员主要集中精力去修复这些bug，而测试人员则需为这些要签入的代码做回归测试以保证bug已经被修复。
这是微软亚洲工程院产品的一个基本流程，一个产品就由许多的iteration组成。下面我会介绍一下微软亚洲工程院测试人员的日常工作。
找bug：作为一个测试人员，最重要的事情就是尽可能地发现产品中的bug，这些bug包括代码中的bug和功能说明书中的bug。每天我们会至少花半个小时找bug，如果是在发布前期的一个iteration，这个时间会更多，大概会占到一个半小时左右。我们一般情况下利用手工和乱点来找bug。
测试计划：任何新功能的功能说明书出来后，测试人员需要针对功能说明书撰写测试计划，测试计划应该包括测试概要，测试目标，非测试目标，测试方法等。测试计划应该根据新功能的要点提出相应的测试方案，如最简单的主要是手工测试还是自动化测试。
手工测试用例：在测试计划完成后我们需要准备一些基本的手工测试用例，这些测试用例一般情况下会覆盖最基本的功能。在微软，最重要的就是BVT（build verification test）,BVT是由测试人员进行定义的，如一个登录的功能，正确的用户名和密码能够登录，错误的用户名或密码则不能够登录这些就是最基本的测试用例。任何签入的代码都会产生一个新的build版本，这个版本会自动运行BVT测试用例以保证代码不会产生最基本的bug。
自动化测试用例：由于手工测试用例的运行太消耗人工，在我们有空的时候，会尽可能最大限度地自动化手工测试用例，一般是在一个iteration的开始阶段。我们的自动化测试框架继承于雷德蒙总部的框架，根据自身产品的界面进行了一些泛化，主要是基于UI的自动化测试，同时，为了增加我们的测试覆盖率，我们还进行了基于API的自动化测试。
代码复查：每一个需要签入的代码都需要另外一个人做代码复查，无论是产品的代码或是测试的代码。这是为了保证代码的质量。每次要签入的代码均需要申请一个修改列表，并对这个修改列表进行打包。做代码复查的人则需要观看代码，在产品代码的部分则需要开发人员对产品代码的风格以及格式提出意见和建议，在通过后则需向测试人员提交回归测试，在测试代码的部分则需要测试人员不仅对风格和格式提出建议外还需要保证代码能够正常运行。
回归测试：这是另外一个很重要的工作。每一个修复了bug的代码或者是新功能的代码都需要由测试人员进行回归测试，也可以说是全部的产品代码都需要经过回归测试。测试人员需要确保这段代码已经修复了这个bug或者说实现了新功能，而且必须要保证没有引起以前的一些已修复的bug。因此，你必须要能够读懂开发人员的代码，所以要求你对开发人员的代码非常熟悉，能够发现其中的一些潜伏的bug。一般回归测试的要求是先保证签入的代码不会造成编译失败，编译失败是最不可容忍的错误，这样会阻止世界上其他任何与你合作组的工作，所以要保证签入的代码可以编译通过，其次还要保证签入的代码能够起到其应用的作用（修复bug或完成一个新功能），最后还要保证对代码的修改和更新尽量不能引入新的bug或产生原来已修复的bug重现。
代码覆盖率：测试人员需要在每一个iteration的结束进行代码覆盖率的审查，一般情况下是产生一个最新的编译版本，在此编译中运行所有的自动化测试用例，因为基本上所有的自动化测试用例能够覆盖到日常用户的操作行为，在所有的自动化测试用例运行结束后，则可确定产品代码的覆盖率。
全自动化测试用例通过：每天会有一个测试人员运行所有的自动化测试用例，因为微软有自己的运行自动化测试用例的工具，同时，所有的自动化测试用例会在美国雷德蒙的测试机器上运行，并不影响测试人员的日常工作。全自动化测试用例主要保证产品没有明显的bu*生，并产生相应的自动化测试用例报告，以此反应测试人员的测试用例覆盖情况。
微软的测试人员不负责进行单元测试的任务，单元测试一般情况下由该功能的开发人员进行。
下面我以一个例子说明以上的各个工作是如何融合一起的。项目经理和设计人员编写说明书的时候，开发人员会提出不可实现的地方，测试人员会提出不符合用户需求的地方。项目经理和设计人员会根据开发人员修改相应的功能，测试人员的问题则被记录到bug管理工具中成为说明书缺陷由主管会议进行决议。在功能说明书通过后，开发人员开始进行编码，并完成代码复查和回归测试，通过代码复查和回归测试后签入，测试人员会找产品中相应的bug,所有的bug都被记录到bug管理工具中并分派给相应的开发人员，开发人员解决 bug的代码同样经过代码复查和回归测试后签入。在iteration最后的阶段，测试人员进行bug bash,以后开发人员会进行bug resolve bash,尽全力去修复bug,同样，每个修复bug的代码仍然需要经过代码复查和回归测试。
以上是一些测试人员的日常工作内容，但如果你想成为一个优秀的测试人员，你还需要在以下几个方面进行提高。
交流：作为测试人员，你必须去推动项目经理和开发人员去完成新功能，包括有时候你发现的一些关于用户体验的bug，这时候，你都必须要与项目经理和开发人员去进行讨论。因此，测试人员的交流能力是非常重要的。
创新：作为测试人员，日常的工作内容都是一样的，无非功能的不同。因此，你必须要多想，想怎样才能改进我们的日常工作。下面是一些例子：新功能代码的签入必须经过回归测试，回归测试中发现bug必须重新做代码复查。总的来说，现有的可以改进，没有的可以创造，只要你认为我们可以从中受益。
在平常的日常工作中，我除了完成日常性的一些工作外，还做了如下的工作：
开发工具：我开发了三个工具，其中一个是根据选择的数据库运行应用程序，另一个是利用应用程序生成数据库，还有一个是批量运行自动化测试用例。并且我还更新了一个工具，这个工具是将数据库的数据以一种友好的方式展现给测试和开发人员。
压力测试：我与另外一位微软的员工合作进行了我们产品的压力测试。在我编写压力测试用例的过程中，发现了压力测试框架很多不合理且不好用的地方，我积极地与美国雷德蒙总部的测试人员沟通，一起讨论如何改进压力测试框架，最终使得我的压力测试用例能够在美国雷德蒙总部运行，并因此获得了美国测试人员颁发的stress appreciation award.
更新自动化测试用例框架：我更新了我们的自动化测试用例框架，对整个框架进行了重构，改进了框架中的异常信息的架构以及加入了日志功能，并且修复了美国自动化测试用例框架中的一个bug。
在微软实习的四个月中，我觉得软件测试的任务不仅包括通常认识中的找出软件中存在的缺陷和错误，在不同的操作平台下软件的兼容性以及是否存在安全漏洞等等。作为一个优秀的软件，还要在用户使用习惯和体验方面进行大量深入的考虑，所以要找出软件提供的功能和用户需求有出入的地方，检测软件的执行效率和对于破坏性操作的承受能力是否在用户容忍度范围内，同时，必须在交流和创新上下功夫，争取让小组的测试人员的工作越来越轻松，工作效率却越来越高。
肖于思 于2008月1月9日
陈超
工作总结
· 完成Visual diff 项目的开发并迁入到source depot
· 研究Product Studio
· 完成PSSP tool Framework的开发
· 研究Jabber Server并写出分析报告
· 研究Share Point
· 研究Share Point SLK
· 完成Content 自动转换工具的开发并迁入到Source depot
· 完成Server Stress Test 工具的开发
· 寻找GravaMobile Server的严重bug并分析原因
· 寻找JAME Server中影响稳定性的bug并修复
· 设计实现Verification System
感想
第一个月
在这里的第一个月因为机器，帐号密码等要通过Redmond总部办理的原因，所以企业导师分给我一个VisualDiff的项目，这个系统主要用于对J2ME自动化测试工具所生成的测试结果进行验证，并且为测试者上报bug和管理测试结果提供方便。因为很多细节方面要处理，所以大于花了一个月的时间来实现这个项目的主要功能。这个项目从设计到实现都是由自己一个人完成，所以几乎没有团队合作的机会。值得庆幸的是，导师本来认为要花4个月的任务，结果一个半月就搞定了。在这里要感谢我的导师给我很多很好的 建议，并且给我很充裕的时间。
第二个月
第二个月一边进行VisualDiff的代码评估，一边进行Share point和product studio两者的数据转换工作。花了半个星期研究SharePoint server的各种接口。然后又花了一个星期做了一个demo。我认为最棘手的工作莫过于在工作过程中研究某个领域。在进入这个领域前，组里没有人知道这个事情可不可以做，以及怎么做，而且又规定了研究时限。所以感觉自己的压力非常的大。如果方案可行，那就要做出一个demo。如果不可行，那么要利用现有的资料证明自己的观点。还有一个难点，相关资料也是要自己搜集。所以自己在这个月里练就“高深的”搜索本领。后来把这个Demo逐渐的改为了PSSP Framework。这个工作贯穿于以后的几个月中，并且断断续续的进行修改和测试。这个Framework的好处在于可以为以后的PSSP之间的转换提供便利。但是开发人员必须知道各个字段之间怎样转换。而后的半个星期PM分给我一个研究Jabber Server的任务，并要求做出各个server的性能和功能的分析报告，以利于他更好的做出决策。于是在剩下的时间里拼命的进行搜索，同时又联系了Jabber Server的开发组织。因为它是开源的组织，所以在技术，协议等方面都尽力为我解答。这对我写作分析报告提供了很大的帮助。另一个星期的任务是看看微软内部现有的server是否有和Jabber Server一样的功能。很可惜的是这个星期除了和Test lead，Dev lead，PM lead讨论相关事项，很少和组内的其他人员来往。当我联系share point开发组来询问技术细节的时候，他们认为实习生的权限不够，所以没有给我更多帮助。这里应该谢谢宇涛，当我share point 的service调用不成功的时候，远在Redmond的他给予我很大帮助。
第三个月
第三个月开始的日子和Test team一起找bug，找的不亦乐乎。后来手工测试结束，因为我对share point server的研究，我的导师决定让我和dev一起开发内容转换工具。剩下的日子很辛苦，同时也很快乐。很苦是因为产品要做pilot，所以这个工具要求在很短的时间内完成，并且可以正常运行。虽然我之前做过相关的工作，但是很多函数方法还是没有研究过。后来因为产品的server版本需要稳定下来，所以我*开发了一个过去server的精简改进版。这个server要在各个机器上运行，环境又不是很一致，所以花了很多时间进行远程调试。快乐是因为有团队合作，因为大家承认我是整个team中的一份子，因为自己开发的东西为整个项目组节约了很多精力和时间。
第四个月
第四个月开始的日子，应PM的要求做一个能够显示数据的网站。把任务推给我的理由是我有开发web系统的经验。无语……于是又熟悉了一下JavaScript。在开发网站的日子，发现这些数据量用来测试这个web系统远远不够。我询问测试组是否有这样的工作来测试产品的server对大数据量的承载能力。其结果是又将server stress test的工作分给了我。因为手工进行这样的压力测试很耗费测试者时间，而且很枯燥。于是开发了Server stress test的小工具来自动化的完成所有压力测试的工作，同时又学了点如何写dos script。就这样开始了管理组织server stress test的工作，发现了server的几个严重问题，后来发现这些问题是由于Session超时和带宽太低引起的。在做Stress Test的过程中慢慢发现写文档比写代码重要的多。
第五个月
这个月相对轻松了很多，因为产品在做pilot。为了解决困扰几个月的JAME Server的稳定问题，于是去研究JAME Server的连接部分。庆幸的是最后终于找到了几行有问题的代码段，解决了Server的不稳定性。Test team对我有很高的评价，也提升了自己在Test team中的“地位” J。对于另一个平台，现在刚刚开发出来自动化测试工具，还没有自动化验证工具。于是由我主持Verification System的设计和实现工作。因为我很快要离开ATC，所以过去的所有工作都要进行移交。我也希望通过和Test一起开发来移交我过去开发的visual diff。非常感谢ATC Education项目组的各位同事，让自己感到并不孤单；虽然不知道自己能不能留在ATC，或者自己以后会不会在ATC工作。（更加感谢饭团众人）
总结
在ATC的日子时而轻松，时而忙碌。前几个月很郁闷的一个人做事情，后几个月很快乐的一群人做事情。学到一些零散的知识和技能。手工做很痛苦的事情一定要让工具去做。项目需要什么学什么，学到够用就好。这里所有的人都是身怀绝技的人，所以每一个人都值得我去学习！
陈超 于2008月1月12日