我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化，想方设法写一些从头到尾自动化的框架，觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想，用自动测试发现的问题基本上可以一个人用手工测试完成，最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时，所有户界面完全变了，80%以上的自动测试程序都需要改动。做完第一个版本，我们三个人全都走掉了。后面来的人往往宁可自己再写一套，也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的，所有人都想另搞一套。
下面分几点讲讲为什么要放弃对测试自动化的幻想，和怎样进行低成本的有效测试。如果你还不能同意我对测试自动化的看法，可以去这个微软员工的Blog http://minimsft.blogspot.com/2006/08/dev-vs-test-vs-pm.html 去看看为什么Windows测试组用的WTT测试框架被称作“Waste of Tester Time". 我最基本的观点不是说测试自动化不能测出bug，而是想问: 一个比较复杂的测试自动化框架所造成的人力浪费，值不值得最终的结果？如果不做测试自动化，能不能达到同样的效果。以我的亲身经历，去年我的测试组两个人对应开发组五个人，项目经理三个人的工作量，去年做了好几个Release，Hotfix只有两三个。我们旁边的测试组七八个人对应五六个Dev. 他们又是自动化，又是搞程序覆盖率，好不热闹，Hotfix 也不少。按一个人的人工成本12万美元，我们组省至少三个人的成本36万美元。
[comments]在进行第二部分的时候，我想简单说一个问题。以我个人的看法，功能测试根据被测试对象主要可以分三种类型：UI测试，Command line测试和API测试。我认为后两部分是非常适合用自动化来作为主要方法进行测试的。作者只是提到了UI自动化，然后就推广到整个的自动化。我认为这不是很reasonable的。如果谁要是认为API和command line的测试不适合自动化，我们可以单独讨论。不过这里，我们就要把topic nail down了。我们只谈UI的自动化。如果我们要谈整个的自动化，作者的观点一下子就错了，没必要继续谈下去了。
我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化，想方设法写一些从头到尾自动化的框架，觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想，用自动测试发现的问题基本上可以一个人用手工测试完成，最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时，所有户界面完全变了，80%以上的自动测试程序都需要改动。做完第一个版本，我们三个人全都走掉了。后面来的人往往宁可自己再写一套，也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的，所有人都想另搞一套。