软件功能自动化测试工具给我们带来了什么及来自微软讨论组的争论

首先说说为什么做测试的人喜欢搞自动化。

第一，自尊心。计算机科班出身的人都喜欢作开发(Dev)。做测试工作经常是身不由己，可是测试工作很多时间不需要编程，于是做测试的人想方设法写些程序，以显示自己也会编程。结果往往是欲罢不能，测试自动化程序越写越多，越写越复杂。后面我会谈谈测试自动化框架复杂的代价。

第二，为了出成绩。很多测试组为了向管理层展示成绩，往往要拿出例如测试自动化达到80%，程序覆盖率达到90%。要我说，这些都是Bull Shit. 就象小平同志说的“实践是检验真理的唯一标准”，我认为在测试中“用户不出问题是检验质量的唯一标准”。自动化做的再多，用户出了问题，也是白搭。另外，一个人就可以做的测试，自动化往往需要两个，三个。倒是解决就业的好方法。

我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化，想方设法写一些从头到尾自动化的框架，觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想，用自动测试发现的问题基本上可以一个人用手工测试完成，最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时，所有户界面完全变了，80%以上的自动测试程序都需要改动。做完第一个版本，我们三个人全都走掉了。后面来的人往往宁可自己再写一套，也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的，所有人都想另搞一套。
接下来我先以我的多年工作经验来说一下有关功能自动化测试工具的详情吧。
功能自动化测试工具给我们带来了什么?我不知道大家如何看待这个问题，我总觉的很多人把功能的自动化测试工具看的特别的“厉害”，觉得可以完成很多的工作。领导会说，如果我们用工具进行回归测试，会很快的发现问题，然后减少回归测试的时间，提高项目的效率，如此这般公司开始推行自动化工具。

　　幸运的，我开始成为自动化工具的推广者，曾经用过自动化测试工具selenium进行简单的自动化测试，因为项目是多省系统，进行系统测试时，重复内容比较多，但是程序又相对稳定。于是在测试的间隙，完成自动化测试脚本，在系统测试中运行测试。效果还是比较好的，现在想想当时的脚本真的是非常脆弱而且是简单的，没有任何的控制语句，场景回复，脚本的维护量比较大，一旦出现问题，脚本跑不通，只能人工排查原因，自动化测试的部分只在系统测试中站系统测试百分之五十的工作量，但是在整个测试的工作量中百分之十都不到，大家仿似看到此时自动化测试的甜头，希望在整个公司中推广自动化测试工具，觉得自动化测试是一种趋势，一种必然，于是我站在风头浪尖开始试着完成这项工作。

　　自动化测试同手工测试一样，都需要有一个计划，测试的覆盖率，评估自动化测试工具是否能带来收益来确定测试的内容，其实，并不是所有项目都适合自动化测试工具的，如果项目周期短，是不适宜做自动化测试的，自动化测试虽然在运行中比较省时间，但是在前期的设计，脚本的编写和维护都会浪费较多的时间，如果自动化测试脚本不能重复利用多次，自动化对于我们只是一种时间的浪费，只会令整个项目延期。如果你要用qtp这种识别gui属性的工具必须要等待页面功能稳定以后才能进行自动化脚本的设计，因为任何一个控件的修改都会导致自动化工具不能识别控件。其次，自动化和手工测试都需要完成用例的设计，手工测试用例有相应的输入输出，自动化脚本也需要，最好能参数化进行。

　　自动化测试是否能代替手工测试呢?多少人重复的问这这个问题，答案是不能，自动化测试最大的用处是保证测试的质量，而不是发现问题，而手工测试是发现问题。因为我们每次的回归测试，如果是手工测试的情况由于时间的关系并不能因为一个模块的bug，去测试其他的模块，而自动化测试工具的加入，可以保证所以模块的基本功能，每次回归用手工去发现验证问题，用自动化工具去保证整个软件的基本功能正常运行，自动化的推广是逐步的，首先做一些冒烟测试的自动化，随后把一些主要的功能和测试点也加进来，但是千万不要太细化，到所有手工测试的点，这样，会带来很大的风险，自动化程度越高，风险将越大。

　　自动化的另外一个注意点就是管理，引入一项内容，必然就需要花一定的时间对引入的内容做管理，例如用td管理工具，一定有相应的说明文档，使他不依赖于某个人，以至于某个人的离职不会对自动化工作造成太大的打击。