请大家重视自动化测试的设计过程

dreamever

这段时间总在51上潜水,QTP这个版块应该是论坛里人气最旺的区域了.每天发贴量都在200左右，这是一个好现象。但是我也发现几乎所有的帖子都是针对QTP的使用问题的，例如如何参数化、如何识别对象、如何连接管理平台，脚本为什么报错，大家讨论的内容严重的同质化。个人觉的这从侧面反映了一个现象：大部分的人仍然将自动化测试与测试工具等同起来，好象自动化测试的全部工作就是如何使用测试工具。
    我做自动化测试的时间也只有一年左右，之前做的都是手工测试，经验不敢说丰富，但是我能肯定这种现象是不正常的，自动化测试是一个过程，它自身也有一个完整的生命周期，需求设计、规格说明、脚本框架、代码实现、部署运行、更新维护，各个环节密切相连，缺一不可，而工具的使用充其量也只是测试实现的内容之一而已，不是自动化测试的全部。看到几乎所有的人都在问工具如何使用，脚本如何编写，我不仅纳闷，难道大家的测试需求和规格设计已经到了炉火纯青的地步，最大的障碍只是脚本编写的问题吗？答案当然是否定的，那么我想剩下的也只有一种解释最合理，那就是在自动化测试的过程中，大家很少涉及或关注过自动化测试的设计和规划过程。
    自动化测试并不神秘，从软件工程的角度来讲，自动化测试扮演的是一个测试执行的角色，测试脚本执行哪些测试、测试的效果怎么样，完全在与人的参与。相信有过测试经验的人都认同：测试过程中设计重于实现。测试执行是一种附加值很低的工作，往往是重复的、简单的、机械的验证和执行。其实测试脚本的编写也是一样的道理。能写出很复杂的脚本当然是很牛的技术大拿，但是我认为也不能忽视测试设计在自动化测试过程中的重要作用，试想，比如你是一个很牛B的黑客，你能连入美国五角大楼，然后再从五角大楼的服务器矩阵上连入外太空的卫星，最后让卫星发送指令到你的机器上启动QTP，执行测试，最后生成测试报告，这种牛B程度在人类历史上应该是前无古人后无来者的吧，但是如果你的测试设计只是在首页上把鼠标从左上角移到右下角，那有什么用！说这些不是要否定编程技术的重要性，其实编码技术和测试设计对于自动化测试人员来说是同等重要的，就好象人的两条腿，谁能说我的左腿重要右腿就可以不要了？但是在实际的工作中这种情况却比比皆是，我相信很多人在自动化测试的过程过多的关注自动化测试的实现，而有意淡化甚至排斥自动化测试的设计，我个人觉的这不能不说是自动化测试的悲哀。
    当一个公司或者组织准备引入自动化测试时，往往重视硬环境的投资，如软件、设备、人员，但是却忽视了自动化测试的标准和规范，将所有的希望寄托于几个自动化测试人员，这只能说是一种误区。大家可以在自己的部门内做一个简单的实验，实验的内容就是在你们的部门里问一个简单的问题：什么是自动化测试？我相信如果你的部门有N个同事，这么一个简单的问题你就能得到N个答案，再算上你自己就是N+1个答案了。在这么一个思想模糊、观念和标准都极度混乱的组织中，大家说你们的自动化测试能做起来吗？
    很多人都问我：自动化测试能做什么，我的回答往往是：你希望自动化测试做什么，这其实体现了两种思路，前者是希望先了解自动化测试工具的能力范围，然后再根据这个范围定义自己的测试需求；而我认为应该反过来，必须定义出明确的测试需求，然后再根据测试需求选择合适的测试工具或自动化测试框架。我们不能让工具束缚住我们，自动化测试应该强化人在测试过程中的主导地位，而不是变成工具的附庸。
    其实在做测试的同行中，很多人都认同自动化测试工具不是自动化测试这个观点，但是在实际的工作中大家却往往在不知不觉中忽视了这一点。，但是我希望写的这些东西能给大家提个醒，测试工具固然重要，但是别忽视自动化测试的设计过程，那是重中之重啊

lqin1982121

楼主说的很中肯,很多人往往觉得只要掌握了自动化测试工具就掌握的自动化测试,这个是有误区的.

lishengtest

这和手工测试一样，测试时不用看测试用例，有的甚至没有用例

假装不在

QTP就是一个自动化测试其中的一种思想。

willturner

在我看来,手动都不会测的,更不要说用自动化测试去测了

lz说得很在理

jessica42237728

楼主说的很对。
   但是，测试框架的技术需要慢慢积累。
   测试工具的使用则是一个比较迫切，比较容易学习，也比较容易操作的东西。
   最后，我还是觉得楼主说的很对。

小九

这样的好文章要顶

happychap

路漫漫其修远兮，只能上下求索。
由于项目时间冲突的原因，又有个把月没摸QTP了，最近又忙着写年度总结，痛~~~
这个问题我是这样认为的：
1、如果是初学者，关注QTP的使用重于关注自动化测试流程
2、如果你有一定的基础了，就不要再整天抱着技术了，确实应该想想怎么去组织你的自动化工作，这是一个长期、持续的过程，乃至是一个会让人崩溃的过程。
3、我个人建议在自动化测试工程化的过程中，一切随缘，其实当你QTP的技术到了一份儿上，自然而然地就会去想到工程化的事情了，因为不工程化，QTP其实是很难用的东西，有大量的重复性体力活儿要做。如果QTP的使用技巧没掌握，QTP的实践环节太薄弱了，说工程化也是空谈。

fishy

小马菜菜是你吗？

alex1919

楼主说得很对。
我就有个挺失败的经验，就是如楼主所说的一样，前期没有整个自动化测试的规划，最后导致花了很多时间去实现，但却最终没有得到预期的效果。这里简单说下：
我们一开始用QTP去做自动化测试就是简单的根据从软件需求出发写的manual cases来实现，而且要就自动化出来的case必须和manual cases的完全相同。结果导致写了很多的auto case,而且每次华很多的时间去maintain. 最后发现maintain的时间都足够把这所有的cases手动跑完还不止。效率非常低。
现在想来，根本一开始的定位就不对。如果能一开始的时候，从manual的cases为参考，对case进行分级，首先实现对主要的功能点的自动化，然后一步一步细化应当会收到更好的效果。
哎。。。不过或许原本是有规划的，但前面的人走了，这些规划根本就没传递下来。。。。
无奈。。。

heqingbluesky

LZ说得是对的，如果没有好的框架和设计方案，你的实现方法就存在一定的问题。我们目前的项目曾经经历过这样的尴尬。
在开发2.0版本的自动化框架时候，否定了1.0版本的框架，导致所有的代码要重新写，工作量相当的巨大。工具永远只是工具而已。

zhangxinnow

楼住的思想很好，应该是需求驱动自动化测试而不是自动化测试驱动需求。