从前我以为，自动化测试最重要的事情是找对象(Find Test Object)。现在我明白了一个道理，没有框架的自动化测试是找不到对象的，即使找到了也不会幸福的。就跟现实中，没有车没有房的人是很难找到对象的一个道理。

　　自动化测试的开发，通常是由自动化测试的需求决定的。这个需求主要包括：

　　自动化测试更便于实施。这个说的是，你写测试脚本要方便。一个好的自动化测试框架是可以让不那么懂技术的人也可以写自动化测试脚本的，哼。

　　解决自动化测试脚本本身存在的问题，如异常处理和场景恢复。

　　测试易于维护。自动化测试项目，基本都是没有好的管理以及维护，一定是个大坑。我可以很负责地说，自动化测试没有一年半载，你是看不到产出的。所以管理及维护就成了最重要的事情。而好的框架，可以减少你在管理维护中所投入的人力物力精力。

　　可重用性。框架的意义之一就在于可重用吧。所以在框架里，你可以实现一些通用功能，简化脚本开发过程。

　　美观易读的测试报告。拿UFT来说，它产出的测试报告只是基于测试脚本的，并没有那种基于测试集的报告，所以如果你要，测试框架里可以实现。

　　还有很多测试需求，我没办法一一列举出来，多数需求我们都可以在测试框架里去定制。现在可以回答上面那个问题了，record & playback是不会幸福的，你需要自动化测试框架。

　　请慎重考虑是否需要自动化测试(成本投入高，风险大)

　　自动化测试是个很傲娇的东西，它很挑项目。首先项目周期要长，但是需求不会频繁变更;其次系统中多数对象要可以被识别，并且不存在大量第三方插件。而且你要清楚，你不能指望自动化测试去帮你发现新的bug，自动化测试本身是不具备想象力的(相对于手工测试)。它的优势在于反复迭代，它的价值产出在于长期的回归测试，以保证被测产品长期稳定地版本更新。

　　关于自动化测试的切入点，通常要在完整的系统测试之后才算具备引入自动化测试的基本条件。

　　目前我所做的自动化测试成功案例，无一不具备良好的管理和优良的测试框架。二者缺一，自动化测试必然成为大坑。