如果你对VSTS的测试员版本感兴趣，而又没有TFS2010，只装了VSTS2010 BETA 1，那么就只能体验一下VSTS2010的一个新功能–CodedUI Test。微软在VSTS2010以前的版本都不太重视手工测试和功能测试的支持，估计是因为Visual Studio本来是一个集成开发环境的原因吧，不过到了2010，情况完全不一样了，微软想把VS改造成为一个贯穿整个ALM（Application lifecycle management）的主要工具，所以在VSTS2010中加强了对测试计划，测试用例，相关报告等的支持，CodedUI Test就是面向功能测试工程师，给他们提供自动化测试支持的这么一个新功能。

下面我一步步演示一下怎么用CodedUI Test来对WINDOWS自带的计数器实现简单的自动化功能测试。

1. 新建一个测试项目，这个步骤与前几个版本的VS一样，就不重复累赘了。

2. 在该测试项目中新建一个CodedUI Test，如图所示

3. 当CodedUI Test被创建以后，VS会提示用户，是否立刻创建相关的自动化测试代码，如图所示：

这里会看到3个选项

1. Use an action recording associated with a test case or shared steps，这个选项是建立在有TFS的情况下才能实现的，因为在2010中，测试工程师可以编写测试用例，并且保存在TFS中，当有人要用CodedUI Test来实现某个测试用例的时候，就可以通过这个选项来把自动化测试和测试用例关联起来，不过可惜我没有TFS……
2. Use the recorder，这个选项比较常用，就是启动一个VSTS自带的录制工具来实现自动化测试，这个也是下面要详细分享的。
3. User the UI control Locator，这个选择会直接用VS的UI Control Locator来对被测程序的控件进行识别。本文不会详细描述。

4. 选择User the recorder，然后就会弹出一个录制的窗口，如图：

点击那个“Record Actions”就能开始录制了。VS的录制器做的挺人性化的，如果焦点不在录制器上，那么录制器就会变成透明，方便用户对被测软件的关注，下面是两个比较的图片。

选中录制器

没有选中录制器，而且在被测软件的标题栏中还有一个状态提示，表面现在录制器在工作。

5. 开始执行测试用例，录制器会记录下所有的步骤，如图：

我是在计算器上进行了1+1的操作。录制器记录下了所有操作（大家可以看到是Click ’1′ button, Click ‘+’ button等操作），现在把这3个操作合并成为一个方法，填入方法名，然后点击“Generate Method”，测试方法就被生成了，回到刚才的Record Actions的TAB，我们可以看到所有已经被录制的操作，如图：

这里每一个操作，到最后对应的都是一个方法，也意味着这些操作都是可以被重用的，所以每一个Action的颗粒度大家可以自己把握，个人认为不应该做太大颗粒度的Action，首先不利于重用，其次也不利于维护。

6. 增加检查点，对于一个自动化测试来说，自动化执行和自动化检查都是必不可少的。

现在把标签从Record Actions切换到 Add Assertions中，选中“UI Control Map”下方那个唯一可用的按钮，系统会弹出一个新的窗口，如图：

拖动右上角的那个十字按钮到某个控件上，这里可以把这个十字拖动到计算器的结果栏中。这时候VS识别出这是可以Edit控件，我也确定这个就是我想要对之进行验证的地方。点击ADD

选择了正确的控件，还需要对正确的属性进行比较。第一步是显示该控件的所有属性

如图：

图中，上面的部分是公共的属性，例如类名，名称，是否激活等；下面的部分是该控件特有的属性，例如它的文字属性（Text），是否是只读的等等。我现在只需要比较Text属性是等于2.的就可以了。因为很简单，1+1=2. 完成这一步以后就能看到一个控件被添加到了UI Control Map中，里面已经记录了那些属性需要进行比较。

7. 回放检查，浏览到刚才生成的测试，然后点进运行，我们就会看到VSTS在重复我们刚才的操作，并且对结果进行了比较，测试执行完毕。

至此，我们已经完成了一个简单的CodedUI Test。微软的VSTS2010提供了与其他类似的自动化功能测试软件的录制回放功能，但是与常见的功能测试自动化工具（例如QTP，微软的RFT）比较而言，VSTS2010所提供的Recordor使用起来并不是十分方便，感觉操作起来都不如其他测试工具用起来方便。不过有一点是非常值得肯定的，就是微软没有大肆宣扬他的工具能够实现录制回放功能，而解除过自动化测试的朋友都知道，用录制回放来实现自动化测试是相当地危险的，而且成功的机会也很小。这可能就是微软把VSTS2010提供的功能测试自动化的功能命名为CodedUI Test的原因吧。首先这是一种测试，其次，它还是一种针对UI的测试，而其实现是代码。这个对于以后修改和维护测试来说，是比较方便的。

由于没有TFS，所以没有能把自动化测试和测试用例联系起来，我个人觉得，如果单独使用CodedUI Test的话，实现自动化测试真的比较费劲（可能由于BETA,加上我在虚拟机上安装，奇慢无比），而且看不出来VSTS2010比其他商业软件或者开源解决方案有什么优势。不过我感觉如果能把CodedUI Test与测试用例管理结合起来，然后再利Lab Manager上的一些功能，一定会有不错的效果。不过Lab Manager这个东西太大太重，在中小公司估计是比较难推广的。

VSTS版本不断升级，慢慢地从一个纯粹的集成开发环境，过度到贯穿整个应用程序开发生命周期管理的平台了。

Related posts:

1. VSTS 2010 Test Edition文章收集
2. 《Software Testing》（软件测试）读书笔记系列 – 第十六章

早上来看到一篇文章，大概讲的是在单元测试中容易用到了Try…Catch语句而容易出现的一个错误，这里想说一下我对单元测试中异常处理的。记得一个牛人曾经说过（实在想不起来谁也搜不到），大概的意思就是“处理一个问题的最好的办法就是不去处理它”。我不知道当时他讲这句话的具体场景是什么，不过我觉得这句话用在单元测试的异常处理中还是比较合适的。

首先来看看两条关于异常处理的原则

• 如果无法处理某个异常，那么就不要捕获它
• 如果捕获到一个异常，那么不要胡乱处理它

单元测试的代码和开发的生产代码，虽然同是程序代码，但是他们存在的意义是不一样的。前者是验证程序的正确性，属于为程序服务的；后者是实现某种功能，属于为客户服务的。然后在看上面的两条异常处理的原则。

• 作为测试代码，如果捕获到一个异常，其实是无法处理它的。从某种角度来看，测试代码和被测代码是不在一个系统中，AUT所抛出的异常，测试代码无法处理，其实也无需处理。
• 假如测试代码捕获了一个异常，那么唯一能做的事情就是把这个异常重新包装一下，或者直接重新抛出给单元测试框架，然后由单元测试框架打印到界面上或者是执行结果中。但是其实我们什么都不做（不用Try…Catch）也能达到这样的效果。

可能会有这样的一些测试用例：在输入某些数据的情况下，该函数会抛出某异常。测试工程师就是要验证有异常的抛出。如果是这样的情况，可以用ExpectedException的Attribute（.NET）来标识出该测试代码必须要抛出该异常，如果没有抛出，该测试就是失败。

所以在单元测试的代码中出现Try…Catch其实是没有必要的，如果是真的觉得要使用Try…Catch才能完成某些用例，那么我觉得可以重新设计测试用例，或者测试用例的实现。Try…Catch增加了测试代码的不确定性，而这样的不确定性会导致诡异的自动化测试脚本的出现。在回归测试的过程中就有可能出现运行10次测试，有2次失败8次成功的情况。

不过在单元测试（集成测试）中Try…Finally语句的使用还是很有必要的，例如我们会把数据库链接释放的代码放在Finally语句块中，保证测试运行无论成功还是失败，都能释放数据库链接，或者其他昂贵的系统资源。

总结：在单元测试（集成测试等……）中，尽量不要使用Try…Catch代码块；如果需要释放昂贵或者有限的系统资源、做清理工作，可以把相关的代码放在Finally代码块中。

参考资料：

异常处理 – MSDN

异常处理原则

理解.NET中的异常

单元测试之新手最容易犯的错误

Related posts:

1. 自动化单元测试要点

所谓的测试的坏味道，有三种：

1. 项目（Project）
2. 行为（Behavior）
3. 代码（Code）

按照《重构》书中提出的坏味道的概念来看，如果说是有坏味道（Smell），那么大多数都是指代码级别的。什么的坏味道？就是程序有可能会有大问题的一种征兆（symptom）。个人理解就是不能被直接观察到的现象，可以称之为坏味道。

对于自动化测试代码来说，如果有了项目级的坏味道，通常变现就是生产环境出现了BUG。如果出现这样的情况，那么自动化测试代码就不是有味道那么简单了，而是有问题了，自动化测试的安全网没有能够抓住这个BUG。

而行为的坏味道，其中一个表现形式就是我以前写过的在自动化测试中需要避免“诡异”的测试脚本提到的现象。还有诸如编译错误、不能被重复运行的测试等。其实如果我们碰到行为级别的坏味道，那么可以肯定，我们必须要修改它。如果不修复好这些问题，自动化测试根本无法进行。

代码的坏味道，这个才是我们需要注意的问题，因为代码有了坏味道，并不代表着自动化测试代码会运行出错，通常人们是不会去修改没有出错的代码，人之常情。发现测试代码的味道，并且去修复它，会让我们的自动化测试更加健壮。《XUnit Test Patterns》这本书的前言部分给出一个典型的例子来说明单元测试代码中有哪些坏味道，如何去修改。例子中的一些对单元测试的重构方法，我在平时的工作中也应用到了，不过看完了以后真是觉得裨益良多，虽然做了快一年的单元测试，集成测试，但是却没有停下来总结一年中学到了什么，真的要借着读这本书的机会，好好总结。

最近在接回以前的一些测试项目，个人觉得如果测试代码里面不写注释，这样也是一种坏味道。对于一堆测试代码，半年后可能都忘记了当初为什么这样写，尤其是对于没有注释的测试代码。就像我在译言翻译的第一篇文章里面说的那样，“很多时候，你就是注释的第一位受益者，或者受害者”。对于有坏味道的自动化测试代码，你可以让他继续发酵，腐烂，总有一天，你自己要收拾这个残局。

No related posts.

在某些情况下，那一次失败，的确抓住了程序的某个BUG。原因可能是：

• 程序在运行一段时间后会出错
• 程序会出错，但错误不是每次都发生
• 在某些特殊输入下把错误暴露出来

但是在某些情况下，那1次失败的测试其实只是告诉测试的人，你写了一个“诡异”的测试脚本，实现了一个诡异的测试（Flakey Test）。不幸的是，导致一个自动化测试的行为变得诡异的原因实在太多太多。下面是一些常见的：

• 竞争条件
• 测试数据选择不当
• 测试的前置条件不受控

当发现一个诡异的自动化测试脚本，必须要下决心去改掉它：

• 使用一些常见有效的用例设计模式，例如“准备，执行，断言(Arrange, Act, Assert)”
• 使用MOCK技术

总之，当出现一个诡异的测试（Flakey Test）的时候，总是很郁闷的，但是为了以后不要遇到更大的郁闷，我们要尽早发现并且改掉那些诡异的测试。

Related posts:

1. 单元测试的坏味道
2. 自动化测试中的sleep

The Benefits of Automation and Tools – 自动化测试和使用工具的好处
自动化？那要人干啥！呵呵……人不就是用来实现自动化囖。自动化测试有什么好处，面试的时候经常有人问，答案其实没有十分标准的，不过通常都离不开那些老论调。

The principal attributes of tools and automation – 其实是工具的属性。与生俱来的能力

1.Speed – 速度。机子执行的速度是人的N倍，不顾这是要付出代价的，在你教会电脑做事之前，那就是一堆废铁。
2.Efficiency – 高效。当机子在一边跑case的时候你还能设计出新的case。事情真的是这样子的么？估计是在调试脚本吧。
3.Accuracy and Precision – 准确和精确。电脑可以全天工作不休息而且不会出错。人是铁饭是钢，一顿不吃饿得荒。

4.Resource Reduction – 节省资源。这个对于性能测试是最能体现出来的，雇用100个人来胡点还不如人家一台电脑模拟出来的用户牛！
5.Simulation and Emulation – 模拟。电脑可以模拟很多东西，例如变成一台打印机，不是变形金刚，只是一个虚拟的设备。
6.Relentlessness – 电脑可以没日没夜地干活，只要有电！
工具永远都不能替代测试员，它们只是帮助人们更好地完成工作而已。所以说自动化测试并不能替代手工测试。

Test Tools – 测试工具
作为一个测试工程师，我们肯定接触过很多类型的软件，帮助我们更好地完成工作。不同厂商提供针对不停场景下应用的软件，不过这些软件来来去去都是下面要介绍的一些。设置公司里面自己写来帮助测试进行的软件，也必将落入以下的分类，嘿嘿，听起来很神奇~来看看吧。书中特别强调了两种不同风格的工具，non-invasive and invasive。非侵略性的与侵略性的。前者不会修改被测试的软件，只是检视和观察。后者就是指能够对操作环境进行某种方式的修改和对代码进行修改的测试软件。

1.Viewers and Monitors – 观察器与监视器。这些监视器就是能让你看到一些在一般情况下看不到的细节。例如白盒测试里面的代码覆盖率，分支覆盖，条件覆盖等等。这些都是可以在工具的帮助下轻松得到具体的数据的。这类型的软件算是Invasive的。因为需要编译代码链接等等~~在计算机网络里面还有一种经常被使用的工具sniffer – 嗅探器。嗅探器是属于Non-invasive的工具。反正如果有一个软件能够让你看到平常人看不到的信息的话，这个软件就是一个Viewer。

2.Drivers – 驱动器。就是一个控制器，可以控制软件的操作的工具。其实我们平时用的很多自动化测试工具，功能的性能的，都应该算是这一类。

3.Stubs – 桩。桩更好跟驱动是相反的。例如现在要测试一个打印程序，如果打印出来的话第一比较麻烦，第二可能会有一些发现不到的细节上的错误。那么桩和仿真器emulator有什么区别呢，他们之间的区别就是桩还能看到不同系统之间发送的信息，而仿真器只能仿真，不具备查看内部数据的功能。

4.Stress and Load Tools – 压力和负载工具。压力工具，可以创建一个比较苛刻的系统环境，譬如说让系统可用内存在一个很低的水平，然后运行被测试软件。负载测试工具可以帮测试工程师对被测试系统进行负载的增加。例如模拟10000个web的用户。

5.Interference Injectors and Noise Generators – 冲突注入器和噪声生成器。

我们可以在两台机子中间加一个电脑，中间人，呵呵。然后可以加入噪声或者对包进行更改什么的，达到测试的效果。

6.Analysis Tools – 分析工具
这里面包括：
Word processing software 文字处理
Spreadsheet software 表格处理
Database software 数据库
File comparison software 文件比较
Screen capture and comparison software 抓图
Debugger 调试
Binary-hex calculator 二进制计算器
Stopwatch 计时器
VCR or camera 磁带机摄像机

Software Test Automation – 软件测试自动化。
软件测试自动化的目标就是达到在无人干预的情况下能自动跑脚本，自动找出相应的bug，自动报告，做log记录等等……反正就是！一条龙。鉴于书中讲的自动化方法比较过时，这里就偷懒不说了。不过其实用上先进的工具都是同样的一个过程。1.录脚本回放，最最低级的过程。2.修改脚本加入检查点，实现了检查bug的自动化。3.模块化脚本，实现少量脚本的重用。4.数据驱动，实现广义上的重用。就是写一次脚本，运行N个case。5.关键字驱动，据说可以实现自动化脚本和测试用例同步产生。这个有待验证。

Random Testing -随机测试。
这里书上用了一个猴子做比喻，呵呵，其实一个软件给了用户以后，我们根本不知道他们会怎么使用，有时候可能觉得不会有人那样子用软件的，但是什么事情都有可能发生，书上介绍了一种模拟随机时间的方法，就是搞一个robot，这个robot就像一个猴子那样子乱点，而且这个猴子还是个瞎子，软件挂了他还在乱点~

Realities of Using Test Tools and Automation – 使用测试工具和自动化的现实。
前途是光明的道路是曲折的。所以要认清楚其本质！
1.软件在变，文档在变，需求在变。做自动化就要适应这些变化。由此得出，录脚本死路一条。
2.工具不能代替人的眼睛和直觉。因为是我们赋予了工具能力，那些我们没有“教”那些软件的事情他是不会做的
3.检查点是比较难做到。
4.测试工程师很容易就依赖于测试工具了。不过测试工具并不是银弹。
5.不要花费过多的时间在测试工具和自动化上面，这些都是为测试服务的，但是他们不是测试。
6.自动化脚本就是程序，所以也要跟开发程序一样，有代码控制，遵守指引。
7.一些带有侵略性(Invasive)的工具有可能对我们的测试造成影响。

Related posts:

1. 测试工程师需要懂编程么？
2. 《Software Testing》第二十一章 – 软件质量保证
3. 《Software Testing》第二章 – 软件开发过程