比尔•盖茨曾经说过：“微软不是一家软件开发公司，而是一家软件测试公司。” 足见其对于软件测试的重视程度。 ATC( advanced Technology Center，微软亚洲工程院)测试组负责微软某些产品的测试工作。其测试工作的方法沿袭微软的工作习惯和软件测试的普遍方法，同时因其测试对象的特殊性，又具有其自身的特点。从本期开始，我们将陆续邀请ATC测试组的相关负责人来介绍他们所认识的测试工作，以及如何进行测试工作的。
你喜欢“找茬儿”么？ 或者你有着和别人不一样的思维方式，总能发现问题的存在？是不是从小就被称之为“破坏之王”呢？ 或者能够静下来，在纷繁复杂的事物里找到你想要的东西？如果你满足以上两条或者更多的条件，那么请关注一下你可能非常适合的行业――软件测试。
认识测试工作
由于种种原因，国内的软件测试并没有规范化，也没有真正地被重视起来，甚至没有被足够地了解。许多软件公司都没有自己独立负责测试的部门，也不会把测试工作外包出去，开发人员往往是自己开发自己测试，边开发边测试，这种很原始的测试方式，没有比较科学的方法指导，更没有文档可依。这样的局面让之前提到的软件测试天才们没有足够的用武之地。
然而，软件测试是在有限的时间内提供高质量软件的保证，是一个完整正规的软件开发过程中非常重要的一个部分。在大型的软件公司里，往往软件测试工作被高度重视，在微软也不例外。ATC测试组负责Exchange Server、MSN Search、IE、Office Communicator等产品的测试工作。在这些产品发布之前，都要经历无数次严格地测试，并且测试工作不是从开发人员开始编写代码的时候才开始，而是从该产品建立研发项目伊始，就一直作为项目进行的一项重要工作而伴随项目的进行贯穿始终的。
软件测试的任务不仅包括通常认识中的找出软件中存在的缺陷和错误，在不同的操作平台下软件的兼容性以及是否存在安全漏洞等等，作为一个优秀的软件，还要在用户使用习惯和体验方面进行大量深入的考虑，所以要找出软件提供的功能和用户需求有出入的地方，在检测软件 的执行效率和对于破坏性操作的承受能力是否在用户容忍度范围内等等，这些涉及到非软件功能上问题的测试工作同样很重要，但是通常容易在工期或者其他因素影响下被忽视。微软件的产品之所以能被广大用户接受，其良好的用户体验是一个非常重要的因素，其中就有测试人员在改善用户体验和使用习惯方面所做出的巨大贡献。
工作的角色和职业的发展
如同大家对测试工作知之甚少一样，对于测试人员的职业道路的发展也不被大多数人熟知。兴趣和个人的期望发展方向因人而异，测试工作人员也能够选择驾驭还是领导团队。
在ATC成为软件测试工程师）SET-Software Test Engineer)后，可以按照自己的喜好和特长继续发展。通过努力，可以成为在测试方面的软件设计工程师（SDET－Software Design Engineer In Test），之后，如果痴迷于具体技术的研究和应用，可以继续发展成为测试技术主管）Technical Lead)， 最后成为测试架构师（Test Architect）――测试技术方面的顶峰职位；若是有领导才能，钟情于在团队中扮演领导角色，可以尝试发展成为测试主管（Test Lead）和测试经理（Test Manger）， 最终成为测试总监（Test Director）。
不同阶段的测试工作
在微软，软件产品的研发项目一般都分为产品定义阶段、设计阶段、开发阶段、确认阶段和发行阶段，测试工作则覆盖到这里的每个阶段，在每个阶段的工作重点都有不同。
通常大家认为在产品定义阶段，测试工作的介入还为时尚早，事实上测试人员在这个时候也已经开始忙碌起来。他们会根据产品规格书的描述理解产品，然后对照需求文档，找到其中不符点，并综合考虑项目的要求和资源，对纳入需求和开发目标的功能进行取舍，然后向项目经理反馈变更，同时开始构建测试的基础架构。在产品的设计阶段，测试人员在开发人员忙于设计产品同时，审视开发设计的文档并给出反馈意见，同时准备制订测试计划和开发测试工具的工作。开发阶段可能是Bug最多的时期，ATC测试组的工作人员会将找到的Bug提交到开发组中一个共有的数据库中以供开发人员参考。为了防止针对某个Bug的修正引发更多的问题，他们在开发人员修正完Bug之后经过严格反复的测试，才能将修正后的代码重新发布到团队共有的代码库中。产品在确认阶段将不再有大的变动，这个时候测试工作仍然紧张地进行，不但针对功能进行测试，还会进行针对性能，压力和安全的测试。目的就是为了保证产品的稳定性和提高用户体验方面。测试人员的神经在发布阶段通常仍然非常紧张，担心在这个时候出现较大的问题而影响产品的发布。然而众所周知，没有完美的软件，所以在这个阶段查找出来的Bug就需要测试人员去全面权衡是否那么重要，一定要去修复，如果时间紧急并且不那么重要，就要对这样的Bug进行有效的取舍了。
在产品进行测试的过程中，有时候也会发现操作系统和其他产品的安全漏洞和Bug。与软件公司不同的是， ATC测试组将会把这些问题及时反馈给微软件负责相关产品研发的部门，或者累积到下一个版本集中解决，或者是发布补丁来进行修下。
另外，由于测试工作是个“得罪人”的职业，测试人员如何能和开发人员进行有效且友好的沟通需要他们在平时提升自己的沟通水平和人格魅力了。
人工测试和自动测试的选择
对于一些大型的软件来说，测试工作确实是非常复杂和繁重的。在繁重的测试工作中，善于平衡人工测试和自动测试来进行工作可以节省很多的人力和时间，也能将工作做得更好。例如很多时候，对于软件测试中存在要在一定时间内完成类似枚举的大量重复或者需要模拟大量用户访问的服务器压力承载能力的工作时，测试人员往往会借助测试工具或者自己编写测试代码进行软件的自动测试来代替人工测试以节省时间和人力。例如，在测试BizTalk Server的时候，由于该产品涉及到26种人类语言，需要在多种不同的操作平台和不同的编码语言的情况下对软件进行全面的测试，浩大工作只能交给测试工具和软件自动测试来进行。在这种繁重的工作下，利用自动测试来能够避免由于人工的疲倦和其他影响因素造成的误操作带来的无效或者不准确的测试结果，而这是测试工具和自动测试所不会有的问题。
在对于产品的性能、压力承载能力方面，自动测试能够模拟出例如大量的访问量这亲的场景来进行测试，这个优势是人工测试无法涉及的。对于像产品的功能以及本地化/全球化这样方面的测试，也同样是自动测试的优势所在。
编写代码也许也是从事软件行业的人最喜爱并最能获得成就感的工作。自己编写测试工具进行自动化测试也是让工作变得更加有趣，而不是机械性地进行重复性的实验。在这里，每个人都可以最大限度地迸发个人创造性和智慧，为了更好更快地检测出软件的Bug，编写优秀的测试工具是测试人员成就感的巨大来源。另外这些测试工具还能够在下一个类似的产品和工作中重用，节省更多的时间和人力。
然而，人工测试也有它不可替代的优势和独到之处。例如，对于软件的操作方式、外观、使用便易性等这些有关用户体验方面的测试，就不是自动测试所能代替的了。在对于测试工具和自动测试代码有时所不能触及的部分，例如软件的语法和文法错误，人工测试是唯一的选择。人工测试不需要参与此项工作的测试人员有深厚的编码基础，这能够降低项目的人员成本。另外，在软件的生命周期很短、软件本身相对比较简单的进修，使用人工测试就能降低成本，并显现出其不可替代的优势。
对需要测试的软件选择人工测试还是自动测试就要看工作对于时间、人力、技术以及对稳定性的要求来平衡两者的比例了。这种情况下，不仅是努力工作就能完成工作的唯一方法了。 “Work Smartly”就显得非常重要。在ATC的测试组，每个人都不断地被来自Work Smartly的成就感所激励，测试工作成为他们展示创造性和智慧的舞台。
Q&A
国内一般的测试人员,面对的测试对象大部分都是应用软件，对于平台软件的测试,接触得相对较少。ATC(Advanced Technology Center, 微软亚洲工程院)测试组负责微软某些产品的测试工作，在这里的测试人员经常会从事平台软件的测试工作.在测试组中的SDET( Software Design Engineer in Testing—测试方面的软件设计工程师)往往是整个测试组的主力军。为了解微软的SDET的工作情况及他们是如何进行平台测试工作，本刊专访了ATC的测试主管周振宇先生。
问： ATC承担对微软产品的测试中，有对应用软件的测试，也有对平台软件的测试。这两种不同软件的测试工作对测试人员的要求有什么不同？
答： 用户软件和平台软件测试的区别，最关键在于这两种软件面向的用户群体的不同。例如： Office，IE等应用软件,他的使用者大部分是终端用户，测试人员在对软件固有的功能进行测试之外，还需要在如何让软件更加易用、更好符合用户的使用习惯以及UI等这些用户体验方面进行很好的控制。用户体验的测试工作，对于测试人员的编程水平要求不高，往往由STE(Software Testing Engineer –软件测试工程师)来承担。
而平台软件大部分面对的则是开发者，它的职责在于如何使得开发人员可以花费最少的努力来开发出更具价值的应用程序。所以需要SDET对这些平台软件和系统底层之间的关系和联系非常了解。例如测试人员要测试一个GDI的软件，就必须能够自己编写GDI的程序，并且对其中的细节非常了解，才能知道如何对这样的软件进行测试，发现了Bug如何去探求产生Bug的原因，并辅助开发人员去修订这个Bug。 所以，平台软件的测试工作对于测试人员在编程水平方面的要求是非常高的。往往进行平台软件测试的测试人员，编程水平能够和一个资深的开发人员抗衡。这些工作会由SDET来进行。
问：说到SDET这个在测试组中这个非常重要的角色，除了刚才所说的需要有深厚的编程基础之外，要成为一个合格的SDET，还需要具备什么样的能力呢？
答：SDET必须是一个合格的软件开发工程师，熟知各种算法、软件架构和编程技巧和测试方法，还要非常关注细节，喜欢查找产生细节差异的原因，热衷于把系统拆开，弄明白。
例如有一次在对Windows上的文字处理系统进行测试的时候，发现在这个系统的2个不同的Build版本之间产生了一点点细小的差别：一个字母和下一个字母之间的间距有1个像素的差别。一般来说这点是非常不容易觉察到并引起重视的。而我们的SDET感觉这其中有些东西发生了变化，就一定要知道这些变化会带来更好还是更糟的后果，于是开始对这个问题进行了全面深入的探究，一方面开始追根到底找到产生差异的原因，最后发现是一个开发人员把文本渲染的算法中一个数字作了更改，另一方面在这个差异点上进行更全面的测试后发现：如果是英文，间距造成的影响甚微，但是对于阿拉伯文来说，由于它的字母都很紧凑，所以一点点的间距变化可能会造成很多句子中的字母会变形，字母错开或者重叠。所以SDET需要把所有微小改变所造成的影响想得十分全面和完备，并且找到其中的原因。
有一种比较普遍的看法，认为SDET不论是技术能力还是产品认识都不如开发人员。然而真实情况不是这样的。SDET在项目启动时就开始了解产品，开发用各种方式测试产品应该做的事情，按照产品规格说明书去测试产品每个要求是否达到了，察看产品在规定的步骤和要求下，是否获得了应该有响应…… 他们对于产品是全面的了解。并且由于要对产品的各个方面进行测试，并且还要动手编写测试工具，所以开发能力并不比开发人员逊色。我们在面试新人的时候，不管他要求做开发工作还是做SDET，我们都会考察他在测试方面的潜质。如果发现他乐于钻研测试用例，喜欢用各种方法找到系统薄弱的地方让它崩溃等等，我们就会极力建议他去向SDET发展。也有很多开发高手选择从事测试工作，这是因为他们认为自己有很好的测试方面的天赋，可以在这个领域做出更大的贡献。
问：有一种说法是“项目经理（PM）、开发人员和测试人员是工发团队中的‘三剑客’”。那么，在ATC测试组中，SDET和PM以及开发人员之间的关系是怎样的呢？
答：应该来说，SDET是在整个项目中是监控的作用。他们是最了解产品的，甚至比PM还是了解产品。PM很了解产品，但是测试人员不仅了解产品现在能够满足什么要求，还需要了解产品应该满足哪些要求。微软的产品周期模型（Product Cycle Model） 在初期会制定一个需求，SDET会从用户的角度审视这些需求是否合理，客户是否真正需要需求所描述的这些要求，并且将结果反馈给PM。在整个产品周期中反复比对产品的实际情况和这个需求，一般找出需求描述中存在的问题，一边按照需求的要求控制产品开发的方向。然而无论多详细和完备的产品规格书，里面都有可能有没有涉及到的地方，这些也正好是PM所没有想到并且需要的，然后再协同开发人员对代码进行相应的修正。
例如有一次测试一个服务器的组件，需要在MMC上面写些IP地址，然后让这个组件通过指向这个地址建立网络连接。然而PM没有想到的是，产品设计书和规格描述中都没有限定输入的IP地址的地址段中不能放置负数，显然这里出现负数是不合法。 SDET发现了这个问题，最后对所有的与此相关的描述都进行了完善，并且开发人员在相关的地方也增加了合法输入的验证。
问：如何才能评价一个SDET的工作情况呢？
答：关键还是在找Bug的情况上。评价SDET的工作不一定在于他找到的Bug数量，更重要的是还是找到质量更高的Bug。找到质量更高的Bug有时候需要一些运气，但是更多的是基于经验，是对产品深入了解的程度。
要找到质量好的Bug一定要花费很多的时间。在产品开始阶段，Bug最多，可能比较容易就找到Bug，随着这些Bug逐渐被修正，Bug的寻找机会越来越困难，能否找到更高质量的Bug需要看SDET对这些代码所付出的努力了。一般来说SDET会对于寻找Bug有经验积累和感觉。开发人员在编写和设计某些代码时可能会欠考虑，一般来说如果一个地方出现Bug，作相应的改动之后，会产生更多的Bug，另外一般有Bug的代码周围会有更多的Bug聚集。有经验的测试人员会根据这点，锁定Bug的特殊特征，然后根据这个特征就能够找到更多更好的Bug出来。
问：这么看起来SDET的工作还是地分繁重的。那么市面上的自动化测试的工具是否能够减轻他们的工作量呢？
答：首先要判断所要测试的对象适合不适合自动化测试，不是所有的问题都适合做自动化的测试。自动化有它不能或者不适合解决的问题。它善于解决的问题是， 一次编写出来，可以重用，每次软件版本更新，都可以用同一个自动化测试的工具进行测试。然而，自动化找Bug，并且要找到新的Bug的时候，还是离不开人工的操作。通过查看我们的Bug日志也可以发现，新Bug很多都是SDET自己动手找到的。SDET需要对于常规的地方，自己动手进行编写测试工具进行测试，然而也是思考哪些地方可能会出现新的Bug，这些要去手工地进行查找。因为工具毕竟还不能帮助人去思考。
现在第三方的测试工作和微软的平台软件并没有很好的介入。这个也是由于微软件平台软件的特殊性所决定。 但是对例如URL这些通用并且与平台无关的软件功能模块进行测试的时候，第三方软件会有一些帮助。但是，在API的测试方面做一个通用的工具对它进行测试是很非常困难的。有个工具叫做“Any Unit”，直接照调用API去做一些很基本的测试，例如检验这些API是否有正确的相应和返回正常。但是，如果要做一些索引测试（Index testing）的话，就非常困难。这是因为面对的对象，越是特殊，这些工具起到的帮助作用就越小。所为作为一个SDET， 就需要自己编写测试工具来开展工作。
TA
测试架构师（Test Architect）是在微软内测试技术人员技术发展方向的最高职位。其实在4、5年前，微软是没有软件测试架构师这个职位的。测试人员发展到最高级别就是测试主管，然而这是偏管理方向的发展道路。对于那些钟爱技术又十分优秀的测试人员来说缺少这方面的职位发展目标。后来在测试工作的长期发展过程中，需要有人去做整个产品在测试方面的推进工作。慢慢地，随着担任此项工作的人越来越多，软件测试架构师这个职位定位和概念渐渐清晰起来。
那么对于这要一个职位，都需要具备什么样的素质和特性呢？
坚持、有毅力、在逆境的时候要能坚持自己的想法和做法。以ATC软件测试经理何浪飞为例，在成为软件测试架构师（Test Architect）之前，他就是这样坚持，并且曾经为了一个大家都觉得并不那么重要的Bug，历经周折来为这个小Bug“正身”。
这个既不会返回错误又不会造成Down机的小小Bug只是在注册表中某个值的默认设置上可能会给一些初级用户带来不便，让他们不知道该如何正确地使用这个值相关的功能。何浪飞当时所在的测试小组中包括那些有20年以上经验的员工，几乎所有人都因为这个Bug造成不便的几率只是可能，所以认为它还到不了必须要去修订的程度，而加入这个测试小组不到2年的何浪飞却坚信改进它非常必要。既然问题出在可能会让用户感到不便，那么用户的反馈将是进行验证的最好证据。于是他找到负责相关产品支持的人员，查找该产品用户反馈问题的Top 10列表，发现自己坚持需要修订的Bug就在其中。在了解了解决问题所带来的人员支持等所花费的时间和各项费用之后，何浪飞的意见终于被大家欣然采纳，很快修正了那个Bug。
站在用户的角度上审视产品，相信自己，并且要用例证说话。这是要达到测试工作技术领域的最高级别――软件测试架构师所必需具备的。在微软，很多领域都有很强的竞争对手，大家需要付出很长时间的努力，然而也许需要5年才能超过他们，这个时候在市场上很长一段时间都不会有比较明显的表现，所以特别需要给自己信心，相信自己做的工作。在项目组里也是，也许观点大家都不同意，但是如果在分析了事实之后，觉得自己是正确的，就需要坚持，而不是简单屈从大多数和经验深厚的人或者是领导的决定。
然而，要成为软件测试架构师，仅凭这些还不够。因为他们的很多工作都需要和项目经理、开发人员以及项目外部相关人员互相协调和合作，在沟通和影响力传递的方面也需要有很高的造诣。
那么测试架构师在和项目经理、开发人员以及项目相关的其他外部人员之间如何协调进行工作呢？
在项目进行中，测试工程师、项目经理和开发人员的合作通常有两种形式。一种是相互交叉的，交叉的地方有大有小。在单元测试中，要提高产品质量的话，需要开发人员也参与测试工作，项目经理也提供相应的支持，进行各种资源的调配。这种情况更注重合作，是由三方共同进行参与的过程，大家彼此都是平等的地位。测试架构师需要关注项目经理、开发小组和项目相关外部人员之间合作和各自工作的各个过程，找出哪些需要继承，哪些需要优化和提高。
另外一种形式是由测试人员来驱动整个项目的过程，然后由项目经理、开发人员和外部相关人员进行各种合作，大家各司其责，整个工作是由测试人员来负责进行协调。测试人员编写代码验证的工具，希望开发人员和外部合作人员在Check in他们的代码之前，使用这个工具来确认他们的代码是符合要求的。项目经理在协调整个小组的各项资源的时候，受到测试人涡对代码要求的影响，从而影响到所有的成员。这种关系是驱动合作的关系，而不是管理的关系。测试架构师在其中不仅需要对所有的测试人员编写的工具进行监控，更要对这种驱动关系进行很好的推进，以测试角度的需要和要求控制项目的进行。
软件测试架构师有时候总是称自己为传道士，把他们做的工作称为在为相关的其他部门布福音。
以何浪飞所在的MSN部门为例，这个庞大的部门包含了50多个产品小组，并且都有自己成型的组织架构，并且每个产品组，每隔6个月都需要发布一个产品的版本，想要改变他们工程流程上的一些细节，都是非常困难的。在这样庞大的机构中要想推进某个优化流程的工具就更是难上加难。首先在每个部门中少有这样专门用于配合推行这项工具的人员，并且确实存在有怀疑这些工具是否能够改进他们现有工作状态的人存在。这个时候要MSN部门中50多个产品组，随时达到接受改进的最佳状态，非常不易。
这个时候就需要这些软件测试架构师去对这50多个产品组一一走访，去了解他们的状况。因为每个小组的现实情况和需要都不同，也许测试架构师推行的工具虽然很好，但是每个小组可能使用的方法不同，遇到的问题也不同，他们需要去倾听没有使用或者没在达到预想效果的这些原因，帮助这些人去适应这些工具实现顺利过渡，或者对工具做些相应的修改。
通常在推进策略上也采取一些渐进的方法，何浪飞他们称之为“农村包围城市”。他们通常最先去解决那些积极提供支持和合作的部门，然后去解决消极抵触的部门，最后去解决那些年头比较长、阴力比较大、现成和历史东西比较多的产品部门。这个时候大多数部门都已经接受，并且开始有成效，他们的工作逐渐被认可，那些之前最难接受的部门也就慢慢容易接纳所推行的工具了。这些软件测试架构师就这样去为整个工作搭建平台，让大家在一个公共环境中去做工作，节省成本和提升整个工作组的工作效率。
另外很多测试工作通常需要自动化，在其中需要有什么样的测试推进、测试需要有哪些步骤、需要哪些点进行测试等这些工作需要有技术过硬又对产品有整体把握的人来进行，这些都属于软件测试架构师的工作范围。他们不仅对于测试相关的工作需要深入把握，还在对于整个团队工作的本身流程优化和整合做出很大的贡献。同样用何浪飞所在的部门为例，其中的哪些测试架构师历经很长的时间，为相关的工作人员搭建了一个平台，方便大家的合作工作。现在他们的平台可以让开发人员把代码自动Check in，由Build Lab产生一个Build，并且自动在Lab里进行测试工作，并将结果保存到一个数据库中。开发人员通过平台提供的网站可以看到结果，立刻知道哪些代码通过了测试，哪些没有通过，从而可以决定这个Build能不能发布，值不值得做更多的测试，或者还需要进一步做哪些工作。节省了测试人员很多查找常规Bug和验证测试结果的时间，也方便了测试人员和开发人之间的沟通，节省了大量的时间和人力。在更高的产品线上工作的测试架构师，涉及到的平台更加庞大，他们通常需要给客户一个解决方案，到数个产品，需要去解决不同产品甚至是产品线之间是否可以进行有效的工作的问题。例如微软很多产品都需要进行.NET Passport的身份验证，当Messenger增加一个功能的时候，它的验证是否可以同Office里新增的身份验证进行合理和有效的信息互通都是测试架构师需要去解决和优化的事情。所以，测试架构师的大部分工作都是在决策和优化整个产品线，或者跨产品线、平台的工作以及合作工作的流程。
这些时候，测试架构师的工作往往涉及到很多的部门和角色。然而由测试架构师提供的工具、方法和要求往往对于其他相关人员来说，只是第二位的，因为虽然这些对于整个项目以及部门都有很大的益处，但是对于每个人来说自己的工作才最重要。这个时候就需要测试架构师对项目经理和管理人员产生必要的正面影响，然后由他们将这种影响传递给参与合作的人员，从而达到影响到所有人。决策、协调和组织就是他们的工作主题。