服务世界开发未来 : 软件测试

UI自动化测试与软件测试开发工程师所面临的挑战

STB China Blog — Tue, 28 Apr 2009 00:30:00 GMT

在前面李敏的一位软件测试开发工程师的成长体验中, 她提到了微软的自动化测试. 在软件开发流程中, 这种开发一次、自动执行的测试方法被看作测试领域的尖端技术。在Wikipedia中对其的定义是:

“Test automation is a process of writing a computer program to do testing that would otherwise need to be done manually. Once the testing has been automated, a large number of test cases can be validated quickly.
“Test automation can be expensive, and it is usually employed in combination with manual exploratory testing. It can be made cost-effective in the longer term though, especially in regression testing.”

对于任何一个需要开发有持久生命力软件的组织来说, 自动化测试显得必不可少。比如像Windows这样的产品, 通常的生命周期可以长达10年以上。试想一下, 没有自动化测试的话, 任何一次的产品改动、升级、补丁、导致的测试成本有多大。

之所以说自动化测试是尖端技术, 原因在于自动化测试的技术难度, 特别是UI测试自动化。跟软件产品一样, 自动化测试程序也讲究性能、稳定性、可伸缩性等指标。测试程序除了要实现目标程序一样的功能才能够进行结果检验以外, 测试程序还要实现额外的功能去观察目标程序的行为。比如要自动化测试 “dir C:\*.txt” 这个命令, 测试程序除了要实现跟dir一样的文件读取, 通配符展开的功能外, 还需要读取dir命令的输出结果才能够进行结果的比对。同时也要支持跟dir命令一样的灵活性和扩展性。这使得自动化测试在实现起来有可能比其测试目标的实现更加困难。而对于UI产品的自动化，实现起来就牵涉到读取GUI的图像输出（比如检查是否正确弹出了MessageBox），模拟用户的鼠标键盘输入（比如模拟用户在保存文件的时候选择正确的保存路径），同步测试产品和用户的交流等等。这些技术门槛使得自动化测试成为一把双刃剑，成败不在于是不是去做它，而是有没有能力把它做好。接下来的介绍会让你对微软的UI测试自动化和软件测试开发工程师（Software Development Engineer in Test以下简称SDET）有更深入详细的了解。
举一个十分具体的UI自动化的例子：

1. 启动计算器程序(calc.exe)
2. 模拟用户进行菜单输入，从普通模式切换到科学模式
3. 模拟用户计算(4+6/2)的阶乘
4. 检查计算结果是否正确

要求:
1. 整个流程的执行在4秒以内完成
2. 能够适应于不同分辨率和语言 (不同语言的菜单项文字是不同的！)
3. 能够稳定执行，若非产品本身的确有bug，该序列不允许失败
4. 如果下一版本的calc.exe修改UI风格 (Win7中已经修改了)，或者改为WPF实现，要求现有的测试代码仅做简单修改即可继续使用

对于刚入职的SDET来说，其实现难度已经足够大得让其宁愿去写一个calc.exe程序本身。无论是学校的教学还是课外的研究，针对UI自动化的资料几乎是零。上诉功能和需求，需要工程师结合已知的知识和技能，研究出解决问题的最佳办法。

UI自动化其实是一种进程与进程之间的通信。测试程序需要跟目标程序通过某种进程通信方式来获取目标程序的信息，包括UI元素的位置，显示的文字内容，然后再模拟用户的操作比如在特定位置点击鼠标。就进程之间通信方式来说，Windows平台上有很多选择，比如管道，TCPIP，Windows消息，共享文件，RPC等等。对于UI自动化，最容易想到的解决方案是Windows消息。通过Windows消息以及跟Windows相关的API可以获取计算器窗口，菜单和按钮位置。但真正开始用Windows消息来实现UI自动化测试的时候，就会发现Windows消息的一些不足，比如Windows消息无法用于WPF程序，无法获取Excel或者IE里面的UI子元素。

所以，除了Windows消息外，工程师还需要更深入地考虑其它技术。其间就需要研究微软内部的各种UI Test Framework，了解不同Framework的实现技术，优劣以及和测试目标的匹配程度。在进行不断的摸索，尝试，原代码分析后，工程师才会对微软平台各种技术有深入的了解，整个过程是把基础的理论知识转换为产品相关的生产力的过程。

UI自动化对于SDET来说有两层含义。其一，对该技术的熟悉程序决定测试工作的质量。另外，由于UI自动化涵盖的技术范围和深度，使得该技术是锻炼SDET的一个很好的平台。微软对工程师的技术技能要求不是限制在某一固定领域的，而是要求工程师锻炼能够通用的核心竞争力。比如，作为SDET，通过2年的努力，在Visual Studio的界面测试上取得了90分的成功，那么，如果该工程师愿意换一个项目做SDE(Software Development Engineer, 即软件开发工程师)的话，比如到SQL Server开发存储过程的图形化设计，他在前两年所积累的技术技能，要能够确保他在新的项目和职位上，取得同级别的90分。而UI自动化，对于锻炼这样的核心竞争力是一个非常好的平台，因为它至少包括了：

1. 精通微软通用的开发工具和技术, 比如C#, .NET Framework, 多线程。把开发技巧运用到实际的项目中。
2. 熟悉Windows平台的系统知识,比如进程间通信, Win32消息机制。站在微软工程师的角度，通过具体的项目和代码充分了解Windows平台。
3. 锻炼在压力环境下解决实际问题的能力, 比如深入分析COM/DCOM，研究UI Automation Framework的底层实现来解决技术上的细节问题。
4. 熟练掌握调试技巧。UI自动化的开发过程牵涉到测试程序和目标程序，在调试的时候需要处理两者的同步问题。同时，UI自动化的稳定性是比较难解决的问题。调试一个偶尔发生的错误是一个非常有挑战性的任务。
5. 在自动化测试的开发过程中熟悉微软的项目流程，最后，给SDET带来的不仅仅是测试技能的飞跃，同时也让工程师更加熟悉所测试的产品，更好地保证产品质量。

当一个SDET经历了UI自动化测试，武装上了上述技能，就意味着他熟知微软平台的开发技巧，体验过程序开发过程中通常是如何犯错，如何调试，工程师在怎样的情况下容易做出错误的判断和假设，那么，他就能够很轻松地破坏别人的程序，找出漏洞。这不仅仅对测试工作来说是一个很好的起点，这样的坚实技术背景还能够让工程师学习和发展其它技能的时候事半功倍。换言之，自动化测试对微软的产品来说，是保证其可以持续成功的重要技术；对于优秀的SDET来说，是一项必不可少的重要的技能；对于刚入职的工程师来说，亲身体验和研究自动化测试，特别是UI自动化，能够让你实现学生生涯到职业生涯的转变。

在后续的文章中，我打算介绍自动化测试和手动测试的比较，看看自动化测试所达到的效果是否等同于手动测试的录制和重复。同时，也会具体介绍UI自动化测试开发的有趣细节。

熊力
软件测试开发工程师

TAO 项目: 一个直观的UI 测试工具集 (一)

STB China Blog — Mon, 20 Apr 2009 04:45:00 GMT

简介

如今，几乎所有的商业软件都有一个图形用户界面（GUI）。从用户的角度看，一个直观的功能正确的GUI往往比软件的功能更重要。根据论文“A Comprehensive Framework for Testing Graphical User Interfaces” 的统计显示，GUI通常占总代码量的45% - 60%。测试GUI代码对于软件测试开发工程师而言，既独特又富有挑战。

首先，在软件开发周期中，GUI的改变是绝对的，而稳定则是相对的。在用户进行Beta版本的试用时，他们的反馈往往集中在用户体验即GUI上。而与之相对应的是，开发人员也乐意修改这样的问题因为其开销通常相对可以控制。但是，这给测试组带来了极大的挑战。他们不但要确保最小的回归（REGRESSION）风险，而要承担诸如更新测试用例和自动化等额外的工作[2]。

再则，管理大量的GUI测试用例也是个难题。 GUI上一个貌似简单的改变，会影响到几百个已有的测试用例。根据我们的经验，软件产品的测试用例中，25%甚至更多都是GUI相关的，其中80%的都可以自动化。在软件开发周期中，一个对话框可能会改变多次，其相应的管理成本也随之水涨船高。

最后，传统的测试标准可能不能很好的对GUI测试进行评估。比如：通常测试经理认为70%以上的代码覆盖率为可以接受的测试结果，然而对于GUI来说，你只要简单通过打开每一个对话框，就可以达到较高的代码覆盖率。由此可见，代码覆盖率和GUI测试覆盖的层次、深度没有直接的关系，还必须采用其他的测试标准。

现在已经有了一些关于GUI测试方面的研究，例如，GUITAR项目。GUITAR利用模式对话框的属性去获得“事件流图”，然后围绕“事件流图”自动生成测试用例。但是，GUITAR可能不适合非模式对话框为主的软件（比如基于MMC开发的GUI），而且它也缺少系统的途径去管理整个测试过程。

这篇文章介绍了一套GUI测试工具集，我们内部将它命名为“Tao项目”。这是个全面的解决方案，包括用户引导的测试用例和测试自动化生成器、静态二进制分析器、GUI变化跟踪器和综合的报表机制。

接下来，本文的第二节会概要介绍Tao项目，第三节详细描述Tao项目的不同组成部分，第四节列出了Tao项目可能的未来研究工作。

Tao项目概述

道可道，非常道。道是一种传统的中国哲学思想，其精髓乃万物皆有其规律，人类需顺应自然法则以实现游刃有余。根据这种思想，我们设计了这个GUI测试工具组来应对第一节中所提到的挑战。图1描绘了通常GUI测试周期中的主要测试活动。

图1 通常GUI测试周期的主要活动

Tao针对这些测试步骤，提供了一个完全解决方案，图2显示了它的主要构成部分。

图2 TAO工具组

TAG (测试用例自动化生成器) ：用户引导的测试用例和测试自动化生成器。根据预先定义好的规则和基于知识系统的模型，它能生成测试用例和相应的自动化测试代码。

Visual Tree (可视化树图) ：这个树图描绘了GUI的结构，能够形象地显示测试用例报告、自动自动化报告和UI差别变化结果。

Static Binary Analysis (静态二进制分析器) ：对于用支持反射（REFLECTION）的编程语言编写的GUI，这个工具会生成静态分析结果。

Automation Framework (自动化框架) ：执行测试自动化的底层工具。

UI Diff Tool (UI差别跟踪器) ：它能扫描目标GUI的差别，并把这些差别在树图中用图形化的方式显示出来。作为输出的一部分，它会建议用户可能需要更新的相应测试用例和测试自动化。

Bug Filer (Bug 管理器) ：是专门发送GUI bug的工具。它把GUI bug根据不同的原因进行分类，这可用作bug趋势分析和质量评估。

王景村（测试经理）、李敏（测试主管）

系统压力测试

STB China Blog — Sun, 12 Apr 2009 11:20:00 GMT

对我们的系统和组件进行压力测试是非常重要的。压力测试可以发现很多在正常情况下不会被暴露的问题，也就是说可以发现更多其他测试无法发现的系统缺陷。虽然压力测试和负载测试在某些方面有共同点，但是两者并不相同。负载测试是通过在系统上运行已经定义好的工作负载从而确保系统能够在一定的负载系正常工作。而压力测试是测试系统过载的情况，并帮助回答这样一个问题“什么原因导致了系统错误？”

以下是我曾经参与过的一些压力测试:

Windows 客户端的压力测试

在这个系统测试中，我们同时运行许多应用程序，伪应用程序以及测试程序。如果你没有看到过这种情形，你应该去尝试一下。此时，很多子系统会被同时频繁地调用。由于现实中，一个人很难同时做很多事，所以一般Windows用户是很难出现这样的负载。

Xbox 压力测试

在这个系统测试中，许多测试程序和一个游戏引擎同时在Xbox的进程空间中以多线程的方式运行。在Xbox中的所有测试都被设计成与系统内核同时运行在同一个进程空间中。而这也正是Xbox系统的模型。每个测试都是一个线程，每个线程都知道自己不能独享整台机器。我们同时运行所有的测试，于是就出现了图形测试，I/O测试,声音测试，网络测试和控制器测试同时运行的情形。

HPC 压力测试

在这个系统测试中，我们在管理控制台运行的时候提交许多简单的MPI作业，从而模拟了一个很大的工作负载。事实上，它模拟了一个实际中不可能出现的工作负载，因为真正的用户不会喜欢一个集群同时有成百上千的作业在队列中等待处理。成千上万的MPI作业同时运行，就会有几百万个状态更新信息被发送到管理控制台。此时管理控制台就需要同时处理几百万条消息。

这些测试都如下共同点：

没有用户会这样使用系统!
负载是完全不合理的
系统最终可能会崩溃
我们可能不会修复这样的BUG，因为用户不会碰到它。

这是一种设计出来的不合理的负载。实际中用户不会给系统带来如此强度的工作负载。而这种负载强度应该会导致系统崩溃。但是我们并不会修复每一个这样的BUG。其实这些都并不是重点。重点是我们可以通过这样的测试很快发现系统的弱点，并决定这些弱点是否应该被修复或者处理并由此调整测试。一个在正常使用情况下可能需要一个月才暴露的BUG,在压力测试中可能几分钟就会暴露出来。这是一种很有效并高效的寻找BUG的方法。

压力测试的关键是：

一个通过了压力测试的系统在正常的工作负载下将很难出错。这样的系统才是好系统！

John Daly

高性能计算(HPC)美国团队测试经理

翻译：周毅，高性能计算中国团队测试开发工程师

一位软件测试开发工程师的成长体验

STB China Blog — Mon, 02 Mar 2009 01:42:00 GMT

[原文发表地址] 在微软当软件开发测试工程师的故事

[原文发表时间] 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等。

测试初体验二、测试有时候就像是玩游戏，找问题的能力很重要

测试就像是玩游戏？也许你会觉得不可思议。李敏拿了道面试题来打比方，给你一台笔记本电脑，你会怎么去测试它？这是一道典型的开放式问题，即使是没有测试知识的人也可以想出很多的“测试用例”。比如检查笔记本的型号、颜色、硬件配置、屏幕、电池、操作系统等，相信这是很多人拿到新买的笔记本之后做的第一件事情，这些多半都属于常规的正向功能测试；还有些人指出，外观要小巧方便携带，键盘手感如何布局如何，功能键是不是方便易用，这些人对可用性要求比较高；还有些会想到用它来玩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测试工作。

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

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

李敏

资源分配测试—失败及恢复

STB China Blog — Wed, 04 Feb 2009 01:50:00 GMT

我们知道所有程序都会和各种资源打交道，硬件资源类型如硬盘，系统资源如句柄，因此如何做好资源相关的测试很重要。大家熟知的是测试资源的泄漏，但这里我想更多的从资源分配失败及恢复角度去谈资源分配测试。

对于资源通常有如下操作：

1．分配资源

我们熟知的一个典型例子就是 C语言中'malloc()' 系列函数。

2．释放资源

同样的一个例子就是C语言中'free()'系列函数。

3．资源计数

比较常见的例子就是性能计数器，比如文件句柄计数器，它能够提供“有多少文件句柄被打开”的信息

我们编写软件的时候，我们一般都会经常使用这些资源管理类函数来帮助我们，从而得以申请和释放多种类型的资源。当然我们也会编写一些自己的代码来申请和释放资源。一般情况下，这些代码会处于我们的软件架构的相对底层上。我们可能有一个系统，在这个系统里，我们分配资源，使用资源，还可能管理并监控资源，最后当处理完后释放掉这些资源。同时还存在着当代码运行时替我们分配资源的情况。

由于各种原因，资源的申请和分配并不总是能够成功的。其中一个原因可能是某种特殊的资源被消耗殆尽了。比如在磁盘空间不够时，我们申请使用更多磁盘资源的话就会失败；还比如内存总是是有限的；句柄空间总是那么多。总之软件有可能因为各种原因而出错，但一个主要的原因就是资源的消耗。

对于服务型软件而言，提供长期稳定的服务是重要的设计目标之一。从而，相对于客户端程序，它需要运行得更加可靠、健壮。为了确保软件的可靠性和健壮性，我们必须确保它在资源可用率发生异常变动的情况下，它还是可以正常运行。如果某一个程序消耗了所有的内存，那么我们可以假定它肯定会出错了；但如果由于系统内存的不足导致内存分配的偶尔失败，那么我们的软件应不应该完全崩溃？还是应该仅仅让当前操作出错并让软件其他部分能够继续正常运行？同样的问题也适用于其他类型的动态分配并被共享的资源，比如磁盘空间，内存，文件，网络连接等。

致错测试是一个重要的测试场景，可以帮助我们了解当资源使用达到极限的时候会发生什么。简单地说，这种测试可以用以下伪代码描述：

Pallocatedthing[<use more than enough space here>]

counter n

While(Pallocatedthing[n++]=allocate(<whatever size you like>))

While(n)

free(Pallocatedthing[n--])

这种测试很简单，就是申请分配资源直到失败，然后释放掉所有分配的资源。这只是一种最简单的测试，如果你确保它可以工作了，那么还有几件事情等着你去做。

首先，将它放到一个循环里面，然后执行很多次。它是否依然可以正常工作？

其次，在它运行的时候观察整个系统，看被测试进程是否有内存，句柄或者其他资源的泄漏。这种场景下的一个典型的BUG就是资源分配函数发生错误时没有被正确处理。即使它不会立即导致崩溃，但仍可能会导致内存泄漏或者错误。这种事情我以前也遇到过。

如果要更深入此类测试场景，则需要理解资源的依赖关系，以及在软件依次消耗掉所有的这些资源情况下其是否正确处理了所有的资源错误。这方面的一个例子就是处理消息的软件。它将在等待处理的消息在磁盘上保存为一个队列。那么磁盘如果满了的话会发生什么？这种场景可能会比较难设置，它看起来类似于：

1. 限制硬盘空间

2. 将消息注入到队列中

3. 停止从队列中取消息

4. 磁盘满了，会发生什么？相应的工作行为是正确的吗？

5. 重新开始从队列中取消息。是否一切工作正常？

接下来的几个步骤类似于我们上面已经做的，那就是在更多的情况下去重复测试它，并观察结果：

尝试取出所有的消息，直到队列为空。

建立一个稳定的消息输入流，但时而暂停并再恢复取出消息，反复执行磁盘空间测试用例，看是否在这样的情况下仍然工作正常？如果出错的话，是否该出错被正确处理？是否有副作用，比如内存泄漏，句柄泄漏或者数据出错？是否队列的生产者和消费者都正确处理了错误用例？

在你的软件中还会有很多关于这个主题的情况等待你去挖掘，我不准备将所有可能的情况都列在这里。我想你能够自己考虑这些事情。

John Daly

高性能计算美国团队测试经理

翻译：周毅，高性能计算(HPC)中国团队测试开发工程师

有趣的Test Mentor Ring

STB China Blog — Thu, 15 Jan 2009 07:37:00 GMT

在微软做测试开发已经快要两年了，经常会被人问工作压力大不大，测试会不会比较枯燥。而我的回答总是，很有意思，甚至还有点在学校里读书时的感觉。为什么这么说呢？因为在这里做测试开发，不仅仅是完成工作任务，还是一个充满学习和提高机会的过程。

参加Test Mentor Ring就是一个例子。我对Mentor（导师）这个词最早的认识是在刚加入微软的时候。在这里，新员工入职后除了各种培训外，还会有一个一对一的mentor来帮助自己更快地熟悉和掌握这里的工作环境、流程以及产品知识。这对于员工融入新的工作很有帮助。而当我在这里工作一年之后，在一次一对一的谈话中，我的老板又向我介绍了Test Mentor Ring这个项目。

Test Mentor Ring针对的是有1-2年工作经验的软件测试开发工程师。一个Ring由2-3个mentor和6-7个mentee组成。在我们这个Ring中，mentor有从Redmond过来交流的工程师和来自这里其他部门的资深测试主管；而mentee则是6个和我一样有着相似经历和对自己的工作充满热情的测试开发工程师。每两个星期我们会碰一次头，花1小时左右讨论一些跟大家工作相关的问题，为期6个月。这样的形式让我想起了在学校时候的研讨会或学习小组，但不同的是Test Mentor Ring的讨论方式，讨论主题等等都是由mentee自己发起和决定的，而mentor们则会给我们提供帮助和分享他们的经验。

长长的讨论列表

第一次开会的时候，我们决定为之后的讨论先搜集一些大家都感兴趣的话题。结果，最后汇集出来的列表居然非常长，内容除了各种测试方法和工具外，还包括职业发展路线的选择，与其它专业的同事间的合作，有效地管理时间和设定工作优先级，工作计划、测试文档、测试用例的互相交流等等。而在讨论中，我们又会时不时地想出新的内容，以至于当6个月结束的时候，我们列表上的话题还没有被全部讨论完。

生动的时间管理讨论

在平时的工作中，我们的面前往往会同时摆着多项不同的任务，要写测试用例，要测developer给的最新的代码，要回答关于自己负责模块的问题，要帮助合作伙伴的测试工程师解决测试代码运行中出现的问题，还要验证之前找到bug是不是已经被解决。我们通常每个人都有两台电脑两个显示器，但是有时候左看看右看看反而很慢。怎么样安排才能有效地完成工作呢？

于是，我们把其中一次的主题定为了如何进行有效的时间管理。那天当我们踏进会议室的时候，Redmond来的mentor Srini就已经在白板上写了八个问题，要我们先做个小游戏，在十分钟内写好答案。问题包括，你现在手里有几个bug，你今天早饭吃了什么，写一个计算n!的程序，写出提高工作效率的六个建议等等。我们看着这些问题都有些疑惑，但还是写了起来。十分钟过去了，我们还没有回答完全部的问题，Srini就拿走了我们的答案，并问了我们一个问题，我们是按什么顺序回答问题的。我们一边想，一边突然明白了过来。这不就是一个时间管理的例子吗？对于提高工作效率的建议这样的问题，应该是我们最先回答的，因为正是我们本次讨论的主题；手里的bug虽然和测试工作相关，却和这次讨论没有关系；而我们参加Test Mentor Ring的讨论并不是为了来学习怎样写n!的程序；至于早饭吃了什么更是没有任何关系。按照这样的分析，我们就可以很快列出问题的优先级，在有限的时间内完成真正重要的内容。而我们的日常工作管理，不也是这样吗？

纵向和横向的学习

Test Mentor Ring的主要目之一就是学习和提高自己的工作能力，而这一点在我们的讨论中得到了充分的体现。对mentee来说，在加入微软工作到现在的一年多时间里，我们参加了各种关于产品知识、测试开发技能的培训。然而在实际工作中，我们会不断遇到新的挑战，关心的问题也越来越多。当我们把这些问题拿出来讨论的时候，我们会交流自己所做的项目的情况，比较各种方法的优缺点，并提出自己遇到的问题，这样在交流的过程中我们可以互相学习。

而对于mentor们来说，他们有丰富的工作经验，他们往往会从全局上来给出他们的建议。记得有次讨论的话题是如何选择职业发展的方向，一个mentee提出的问题是如果想往管理的方向发展，却几乎没有这方面的实践机会要怎么办。我们的mentor 光安和Glen结合自己的经验，给出了许多建议：如要采取积极主动的态度，和自己的老板进行沟通，请他帮助提供这方面的机会和培训；还有可以通过负责一些虚拟团队的项目（如卓越工程，跨组的测试框架合作开发）来锻炼自己的能力。这些建议无疑对我们十分有帮助。

轻松开放的讨论氛围

在Test Mentor Ring进行的6个月中，我们的积极性一直很高。每次的讨论前，我们总有一个mentee出来组织接下来的讨论。我们会通过email确定要讨论的主题，商量需要准备的材料，而mentor会帮助我们找到相关的资源。每次的讨论会议上，我们还会做会议纪要，并保存到网站上，作为将来的参考。由于mentor和mentee来自于不同的部门，我们的讨论氛围更为轻松和开放。有时候，我们甚至会提出一些在工作中看到的问题，而mentor们也会给出公正的评价和建议。比如有一次的话题是如何与program manager以及developer合作。我们的mentor分别为我们找来了一位资深的program manager和developer，于是我们和他们一起交流了从不同工作角度出发造成的差异和如何解决可能出现的问题。

六个月的讨论学习给我的工作带来了更为宽阔的视野。在今后的不同职业阶段，我还会找对应的 career mentor来帮助我的个人发展。希望有一天我也可以作为一个mentor，再次参与到这样的活动中，分享我的经验和知识。

陆梦嫣

坚守在产品开发的最后一道防线上

STB China Blog — Thu, 03 Apr 2008 06:30:00 GMT

——介绍微软的SDET

不一样的SDET

首先，我要强调的是这篇文章讨论的是微软的Software Development Engineer in Test，中文翻译为测试开发工程师，简称SDET。不同于以手工或者脚本帮助测试的软件测试工程师 (STE, Software Test Engineer)，SDET是用编程方法结合正确的测试方法学来确保软件符合正确的设计和用户的需求，这里强调的是用编程语言来设计程序并完成自动化的高效测试。下面我就细说一下我们SDET的不同之处。

首先，SDET和SDE具有一样的设计和编程能力，这是我们筛选简历的基本条件之一。无论在美国还是中国，我们从大学招来的SDET都要具有Computer Science的背景，不一定是Computer Science系毕业的（虽然有不少人的确如此）。几所美国大学甚至开设了软件测试博士站，我原来的产品组就聘用了一位软件测试博士。SDET的代码和设计要比SDE的代码(产品)还要有更高的稳定性和坚韧性（Robustness）。产品有专人（就是SDET!）来测试，一个版本一个版本地发布。但是SDET的代码没有这种阶段性，只要它要测的功能还在，SDET的测试代码就得执行下去而且得无误！即便测试的一线管理者，就是测试主管，也同样需要有开发、设计能力。

第二个不一样是对开发式创造性思维的独特要求。这种独特性体现在SDET设计的测试用例的完整性。SDET需要有开放性的思维，才可能设想到千千万万用户的各种需求，他们来自五湖四海，有不同文化、不同年龄、不同职业等等。同时，SDET又不能迷失在用户的个案中，需要从众多案例之中，选择有代表性的进行重点测试，以点概面，用有限的时间达到较高的测试覆盖率。

第三个独特之处是SDET的工作在微软软件开发过程中扮演着确保高品质产品的重要角色。因为SDET在整个过程中始终扮演着用户的角色，对一个产品从开始编写代码到最后发布的整个过程有全盘的了解，更能对用户的体验感同身受。SDET必须与PM、SDE紧密合作确保正确理解用户需求和产品功能设计的正确性，同时还要保证产品的可测试性。比如，一项功能或设计是不可测的或是用户不需要的，SDET可以要求PM或SDE修改设计说明或功能说明甚至提供修改意见。需要特别指出的是，SDET对软件质量的Sign Off也是微软所有产品中期和最终发布的前提条件之一。

SDET的职业发展

那么微软SDET的职业发展机会又是如何呢？总的来讲，和微软其他专业的同事大同小异，主要有几个方向：

继续做SDET，级别一级一级往上升，责任和影响力也越来越大。有些产品组设有技术主管乃至软件测试架构师，一般不管人，其领导能力体现在技术上，负责整个产品的测试框架工作包括自动化系统的设计、新工具的开发和现有系统的改进等等。他们对这个产品组的贡献和影响力很大，不仅限于测试团队，甚至可以对Dev和PM等专业产生推动作用。
乐于帮助他人成长的SDET可以选择往软件测试主管，软件测试经理等的管理人员道路发展。软件测试主管通常带领3至7位 SDET，负责产品一个或几个关键构件的质量；软件测试经理监督一个产品组的测试工作，设计主要测试计划书和时间表，并经常会管理2至4位测试主管。顺便透露一下，服务器与开发工具事业部中国团队的总经理就曾经是一位测试开发工程师，并历经测试主管、测试经理，产品总监，测试总监等多个测试专业的岗位。很明显，这个过程需要具备战略性思维方式、有效沟通、团队协作，决策和执行等诸多能力。

当然，如果个人兴趣发生变更，技术带头人也可以通过一定培训转为培养、发展人才的管理人员，管理人员也可以回到技术带头人的轨道。SDET也有转为SDE或PM的，甚至转入技术咨询、支持或市场方向，最终的职业道路不外乎是上述的两个大方向。

SDET的日常工作

除了之前提及的在产品设计阶段审核并批准PM的功能说明和SDE的设计说明外，SDET也要制订相关的测试计划书和时间表，比如，为什么产品中必须提供这个功能，而不是其他的；为什么这个版本应该实现这么多功能；设计测试用例去决定什么应该测试，什么可以暂时放在一边，需要什么样的自动化测试系统，需要新的测试工具与否，测试所需要的时间等资源的预计等诸如此类。

在测试计划书和时间表审议通过后，每位SDET接下来的主要任务是用合适的编程语言去测试产品，需要考虑是共享他人的工具或代码，还是自己重写；SDET的代码的可维护性要很强，因为没有人给SDET写的代码找Bug，当然代码出错误，SDET得自己分析原因并进行修理。SDET同时不断找Bug，分析Bug产生的原因、跟踪处理Bug的进展。SDET 其它的日常工作还包括对现有系统的改进，当前系统的性能报告等等。

SDET的乐趣

做SDET没有比找到厉害的Bug更高兴的了，这会让SDE折服，让PM对产品更有信心。成功的SDET会到处听到人们在讨论他或她找到的Bug。如果找到产生这个Bug的背后原因，大家更会竖起大拇指！

做SDET都想让微软其他人采用自己发明的测试方法或工具来发现新bug！SDET承担着微软公司内部的诸多系统和工具的开发和维护工作。许多工具被内部几万人使用，这些系统和工具的开发涵盖了所有开发产品所必需的流程，技术含量更加不俗。整个微软有数千SDET，有在操作系统部的，在Office组的，在服务器的，做硬件的（譬如XBOX，ZUNE），更有Services。他们的产品各不相同，如果能研究出一个通用并且高效的做法，其它组的人必然会欣然接受。我们服务器与开发工具事业部就有一位刚从大学毕业不久的SDET，工作第二年就开发了一个UI Compliance方面的自动化测试工具，已被多个中美产品组的测试团队广泛使用，并正在申请相关专利，这也是一件值得骄傲的事情。

最让SDET自豪的是用户喜欢使用自己测试的产品，并让他们的工作更轻松、便捷。

我还清楚记得我在微软的第一次发布产品的经历。那时我在MSXML组做SDET, MSXML3.0刚发布时，我总是惶惶不可终日，生怕自己的产品支持工程师来电，说自己负责的那个领域有问题，或者是newsgroup上有人报告坏消息。一天过去了，没事，一个周过去了，还是没事，一个月过去了，还是没事，心情渐渐放下，自傲感开始上升。最后，几个季度过去还是没事，我就彻底放心，可以大胆地告诉他人，我们产品质量没问题，我做到了！

优秀的SDET

不是所有的Computer Science毕业生都适合做SDET，除了上文提到的设计和编程能力、独到的创造性外，一位优秀SDET还需要：

有测试天赋；
细心，什么都逃不过SDET的眼睛；
能建立精确的bug报告，提供简洁和准确地重现步骤和调试信息；
追求高质量的测试代码和测试工具；
有主人翁精神；
不断自我批评，寻找可能的测试遗漏点
对自己的工作负责。

卓越的SDET

主动拓展自身工作范围之外的技能和知识；
能平衡产品质量保证与产品发布时限；
是软件测试和软件测试原则的最佳传道者；
愿意做任何能最终使软件发布的努力；
在整个开发过程中始终被视作能解决问题的人物；
不断推动软件质量和跨部门交流与合作。

谈了这么多，你是否对Software Development Engineer in Test这个专业有了全新的认识呢？

对测试感兴趣的你还等什么，快加入我们的队伍吧！！！

吴光安

（注：本文作者为微软中国研发集团服务器与开发工具事业部高级测试主管）

Technorati Tags: Software Development Engineer in Test,SDET,Microsoft

服务世界 开发未来 : 软件测试