微软是怎样做测试的(二)

国内一般的测试人员,面对的测试对象大部分都是应用软件，对于平台软件的测试,接触得相对较少。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， 就需要自己编写测试工具来开展工作。