进化的测试

VSTS2010 Beta 1 终于出来了，安装的体积不大，只有1.22GB。之前看了很多VSTS2010的新特性，尤其是测试方面的，非常期待，昨天从MSDN下下来以后，失望了一下，因为很多新功能都是基于TFS2010的，我没有装，所以很多新功能都体验不了。例如让人很激动的Lab Manager，这个需要TFS，还有支持虚拟化技术的CPU。
如果你对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会提示用户，是否立刻创建相关的自动化测试代码，如图所示：

最近项目不是十分多，所以大部分的学习来自于书本还有同行的博客，淘宝的QA Team博客就是一个很好博客，里面N多淘宝的工程师写，而且更新的非常频繁，质量也很好。翠翠同学以后就要加入淘宝了，以后就能看到他写的博客了。
早上来看到一篇文章，大概讲的是在单元测试中容易用到了Try…Catch语句而容易出现的一个错误，这里想说一下我对单元测试中异常处理的。记得一个牛人曾经说过（实在想不起来谁也搜不到），大概的意思就是“处理一个问题的最好的办法就是不去处理它”。我不知道当时他讲这句话的具体场景是什么，不过我觉得这句话用在单元测试的异常处理中还是比较合适的。
首先来看看两条关于异常处理的原则

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

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

Martin Fowler有一本很出名的书《重构》，里面有个很出名的概念，Code Smell。前阵子我也刚发现一本很好的书，《XUnit Test Patterns》。这本书主要讲的是如何重构测试代码，这里的测试代码指的就是自动化测试的代码，再进一步细化就是单元测试为主的自动化测试代码的重构。由于此书已经让清华大学翻译烂了……所以建议大家下载英文版。
所谓的测试的坏味道，有三种：

项目（Project）
行为（Behavior）
代码（Code）

按照《重构》书中提出的坏味道的概念来看，如果说是有坏味道（Smell），那么大多数都是指代码级别的。什么的坏味道？就是程序有可能会有大问题的一种征兆（symptom）。个人理解就是不能被直接观察到的现象，可以称之为坏味道。
对于自动化测试代码来说，如果有了项目级的坏味道，通常变现就是生产环境出现了BUG。如果出现这样的情况，那么自动化测试代码就不是有味道那么简单了，而是有问题了，自动化测试的安全网没有能够抓住这个BUG。

什么是“诡异”的测试脚本呢？就是这个脚本在多次运行的情况下，测试结果并非每次都是一致，例如运行10次，有9次是通过的，有1次是失败的，那么这个测试究竟算是通过呢，还是失败呢？答案是：It depends
在某些情况下，那一次失败，的确抓住了程序的某个BUG。原因可能是：

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

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

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

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

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

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

我终于看到自动化测试了，呵呵，不过这章不是我想象中的那样子，可能这本书并不是主要介绍自动化测试的吧。
The Benefits of Automation and Tools – 自动化测试和使用工具的好处
自动化？那要人干啥！呵呵……人不就是用来实现自动化囖。自动化测试有什么好处，面试的时候经常有人问，答案其实没有十分标准的，不过通常都离不开那些老论调。
The principal attributes of tools and automation – 其实是工具的属性。与生俱来的能力
1.Speed – 速度。机子执行的速度是人的N倍，不顾这是要付出代价的，在你教会电脑做事之前，那就是一堆废铁。
2.Efficiency – 高效。当机子在一边跑case的时候你还能设计出新的case。事情真的是这样子的么？估计是在调试脚本吧。
3.Accuracy and Precision – 准确和精确。电脑可以全天工作不休息而且不会出错。人是铁饭是钢，一顿不吃饿得荒。