这段时间总在51testing上潜水，QTP这个版块应该是论坛里人气最旺的区域了.每天发贴量都在200左右，这是一个好现象。但是我也发现几乎所有的帖子都是针对 QTP的使用问题的，例如如何参数化、如何识别对象、如何连接管理平台，脚本为什么报错，大家讨论的内容严重的同质化。个人觉的这从侧面反映了一个现象：大部分的人仍然将自动化测试与测试工具等同起来，好象自动化测试的全部工作就是如何使用测试工具。

　　我做自动化测试的时间也只有一年左右，之前做的都是手工测试，经验不敢说丰富，但是我能肯定这种现象是不正常的，自动化测试是一个过程，它自身也有一个完整的生命周期，需求设计、规格说明、脚本框架、代码实现、部署运行、更新维护，各个环节密切相连，缺一不可，而工具的使用充其量也只是测试实现的内容之一而已，不是自动化测试的全部。看到几乎所有的人都在问工具如何使用，脚本如何编写，我不仅纳闷，难道大家的测试需求和规格设计已经到了炉火纯青的地步，最大的障碍只是脚本编写的问题吗？答案当然是否定的，那么我想剩下的也只有一种解释最合理，那就是在自动化测试的过程中，大家很少涉及或关注过自动化测试的设计和规划过程。

　　自动化测试并不神秘，从软件工程的角度来讲，自动化测试扮演的是一个测试执行的角色，测试脚本执行哪些测试、测试的效果怎么样，完全在与人的参与。相信有过测试经验的人都认同：测试过程中设计重于实现。测试执行是一种附加值很低的工作，往往是重复的、简单的、机械的验证和执行。其实测试脚本的编写也是一样的道理。能写出很复杂的脚本当然是很牛的技术大拿，但是我认为也不能忽视测试设计在自动化测试过程中的重要作用，试想，比如你是一个很牛B的黑客，你能连入美国五角大楼，然后再从五角大楼的服务器矩阵上连入外太空的卫星，最后让卫星发送指令到你的机器上启动QTP，执行测试，最后生成测试报告，这种牛B程度在人类历史上应该是前无古人后无来者的吧，但是如果你的测试设计只是在首页上把鼠标从左上角移到右下角，那有什么用！说这些不是要否定编程技术的重要性，其实编码技术和测试设计对于自动化测试人员来说是同等重要的，就好象人的两条腿，谁能说我的左腿重要右腿就可以不要了？但是在实际的工作中这种情况却比比皆是，我相信很多人在自动化测试的过程过多的关注自动化测试的实现，而有意淡化甚至排斥自动化测试的设计，我个人觉的这不能不说是自动化测试的悲哀。

　　当一个公司或者组织准备引入自动化测试时，往往重视硬环境的投资，如软件、设备、人员，但是却忽视了自动化测试的标准和规范，将所有的希望寄托于几个自动化测试人员，这只能说是一种误区。大家可以在自己的部门内做一个简单的实验，实验的内容就是在你们的部门里问一个简单的问题：什么是自动化测试？我相信如果你的部门有N个同事，这么一个简单的问题你就能得到N个答案，再算上你自己就是N+1个答案了。在这么一个思想模糊、观念和标准都极度混乱的组织中，大家说你们的自动化测试能做起来吗？

　　很多人都问我：自动化测试能做什么？我的回答往往是：你希望自动化测试做什么，这其实体现了两种思路，前者是希望先了解自动化测试工具的能力范围，然后再根据这个范围定义自己的测试需求；而我认为应该反过来，必须定义出明确的测试需求，然后再根据测试需求选择合适的测试工具或自动化测试框架。我们不能让工具束缚住我们，自动化测试应该强化人在测试过程中的主导地位，而不是变成工具的附庸。

　　其实在做测试的同行中，很多人都认同自动化测试工具不是自动化测试这个观点，但是在实际的工作中大家却往往在不知不觉中忽视了这一点。，但是我希望写的这些东西能给大家提个醒，测试工具固然重要，但是别忽视自动化测试的设计过程，那是重中之重啊。