在前面几篇文章基于Selenium和VSTT的网站测试自动化系统、数据驱动测试、在测试代码中硬编码测试数据里，大概介绍了编写测试代码的过程。然而光把代码写完了是不够的，自动化测试不仅仅是将原本手工执行的测试用例通过编码的方式自动化。一个完整的自动化测试过程应该包括如下几个过程：
1. 在实验室里面自动选择机器来执行测试过程，比如说为了测试一个软件产品，以Office举例。因为微软已经为Windows发布了很多的版本，Windows XP， Windows Vista， Windows 7等，而每一个版本的Windows还有不同的变种，例如Vista有企业版，旗舰版，专业版等等，每个变种提供的功能有一点的差别。另外，还要考虑在64位和32位操作系统上安装，还有国际化测试等等。这样一来，为了完全测试Office，测试矩阵肯定非常大，也许需要测试几百个平台，即使以每个平台需要一台测试机估计的话，也需要几百台机器。如果是纯粹人工来管理这些机器的话，不仅费时费力，而且出错的几率会很大—比如说你不能找一台32位处理器的机器安装64位的操作系统。因此，一般来说，一个大的软件产品团队都会使用或者自己编写工具来管理测试机。
测试网站也是一样的，需要考虑到浏览器之间的兼容性，不同测试类型需要不同的测试机器，以及国际化等方面的因素，同样会要求不少的机器执行测试。因为这个软件的制作涉及到分布式开发的一些理念，所以我不会在这系列的文章里讲解如何实现这种系统。
2. 自动准备测试环境，既然机器已经从测试机集群中挑选出来了，下一步就是准备测试环境，例如重装系统（当然啦，Ghost还原也行），安装产品所依赖的软件，以及安装最新版本的产品（每日编译完成以后生成的新版本），将自动化测试用例程序拷贝到测试机，准备测试数据等等。
3. 执行自动化测试用例。这一过程，包括我们通常理解的将需要手工执行的测试用例使用编码的方式使之自动运行。另外，这一过程还包括一些可选的子过程：
a) 自动生成测试用例所需要的测试数据，生成随机的合法的测试数据不是一件容易的工作。虽然你可以random()之类的函数生成随机数据，但是采用这种简单的方法很难生成合法的数据。比如说，为了测试网站的用户登录系统，大部分网站都是要求用户名不能包括特殊字符，这样你就需要在随机生成数据的过程中添加一些限制条件。
一般来说，软件产品在接受用户输入的时候，都会有一些不同的限制条件；因此提供一个生成随机但又合法的测试数据的通用代码库不是一件容易的事情。这也是为什么，我在这系列文章里面，介绍数据驱动测试的原因。
b) 自动生成自动化测试用例。这一步骤并不是说录制测试步骤，根据测试步骤生成C#或者其他语言的代码。这里说的是，软件自动生成测试用例，并生成对应的自动化测试代码。比如说，单元测试一般就是根据函数的参数，设计对应的测试用例；在程序中，参数类型一般来说都是有限的，要么就是编程语言自带的固定类型，要么就是程序员自定义的类型。这样我们是有机会根据参数类型，自动生成测试用例的，微软的Pex就是一个这个领域很好的例子。
又比如，测试人员可以设计产品的模型，即描述产品应该实现的功能，然后通过特定的软件分析这个模型生成测试用例，微软的Spec Explorer就是这方面的例子。
再比如，如果你是在测试一个函数库，例如.NET Framework。一般来说，用户（程序员）使用函数库的时候无非就是一些API的排列组合。我们可以先针对每个公开的API设计单元测试代码，然后编写一个程序将这些单元测试用例随机组合，生成新的测试用例。举个例子，假设要测试数据库连接方面的API，先单独根据Open, ReadData, Close等函数编写好单元测试用例，然后由程序将这些用例随机排列成一些新的用例。当然，随机排列的问题就是会生成非法的调用序列，比如Close, ReadData, Open这个序列的就是非法的。因此测试用例随机产生程序的一个很重要的工作就是在测试工程师的配合下，移除掉这些非法的序列。
4. 测试结果收集自动化，因为是同时在多台机器上执行测试用例，要求测试人员手工收集测试结果是一个很麻烦的过程；所以这一部分由程序自动完成是非常必要的， 一般来说，测试用例执行完毕以后，自动化测试脚本会将测试结果自动发布到一个中心数据库上。项目管理团队会通过一些报表服务—例如SQL Server Reporting Services等系统来评估以下几个内容：
a) 产品哪些组件的风险比较高，即容易出错或者没有完整地测试过。
b) 产品的健壮程度。
c) 是否可以发布产品，或者延期发布？
这篇文章大致总结了自动化测试系统应该完成的任务，本来应该当作绪论写的。不过我觉得可能很多人对纯理论的东西不感兴趣，因此将一些实现细节放在前面先写了。
相关链接：
