标签：http os 使用 sp strong 数据 on 问题 代码
前两天跟老板出去做pre-sales. 主要是去卖我们的自动化测试服务，工具用的是HP UFT。做过自动化的人应该知道，UFT在自动化测试领域已经算是最好的工具之一了。客户是个有技术背景的人，所以不那么好忽悠。我们准备了一大堆自动化测试优点的幻灯片，他倒好，上来直接问，你们的工具的缺陷有哪些。然后我就开始巴拉巴拉地跟他说有哪些缺点，一发不可收拾的是，每解释完一个问题，他就会有更多问题。最后口干舌燥也没能全部解释清楚，除了感叹一声钱不那么好赚，只能怪自己不能用英语流利地吹牛逼吧。
其中有一个问题，我回来以后又想了很久。当时他指着我做的POC（Prove of Concept）脚本，问道：”既然record & playback可以做一个脚本，那么为什么还需要自动化测试框架呢？” 简而言之就是，我凭什么要多花钱买你们的框架？我当时第一反应是，什么？你在逗我吗？自动化测试没框架怎么做？ 当然我的回答官方的很，主要是从维护，可重用性，易用性地角度去跟他解释了一遍，他似乎也不是很满意。
回头我想了想，到底为什么我们需要自动化测试框架呢？越想越觉得委屈，因为我想问问各位开发，你们做项目的时候为什么要用框架呢？那自动化的本质不就是写程序去测程序嘛，既然开发需要框架，那么自动化测试为什么不要呢。
牢骚归牢骚。认真地查了些资料。
什么是框架？
框架（Framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。其实目前为止，框架还没有统一定义，我比较喜欢Ralph Johnson所给出的定义：
一个框架是一个可复用设计，它是由一组抽象类及其实例间协作关系来表达的 【Johnson 98】。这个定义是从框架内涵的角度来定义框架的，当然也可以从框架用途的角度来给出框架的定义：一个框架是在一个给定的问题领域内，一个应用程序的一部分设计与实现【Bosch 97】。
为什么要用框架？
又是一个理所当然的问题。因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事物处理，安全性，数据流控制等问题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。
为什么要搭建自动化测试框架？
从前我以为，自动化测试最重要的事情是找对象（Find Test Object）。现在我明白了一个道理，没有框架的自动化测试是找不到对象的，即使找到了也不会幸福的。就跟现实中，没有车没有房的人是很难找到对象的一个道理。
自动化测试的开发，通常是由自动化测试的需求决定的。这个需求主要包括：
还有很多测试需求，我没办法一一列举出来，多数需求我们都可以在测试框架里去定制。现在可以回答上面那个问题了，record & playback是不会幸福的，你需要自动化测试框架。
请慎重考虑是否需要自动化测试（成本投入高，风险大）
自动化测试是个很傲娇的东西，它很挑项目。首先项目周期要长，但是需求不会频繁变更；其次系统中多数对象要可以被识别，并且不存在大量第三方插件。而且你要清楚，你不能指望自动化测试去帮你发现新的bug，自动化测试本身是不具备想象力的（相对于手工测试）。它的优势在于反复迭代，它的价值产出在于长期的回归测试，以保证被测产品长期稳定地版本更新。
关于自动化测试的切入点，通常要在完整的系统测试之后才算具备引入自动化测试的基本条件。
目前我所做的自动化测试成功案例，无一不具备良好的管理和优良的测试框架。二者缺一，自动化测试必然成为大坑。
最后，填坑这种事儿，收费可是很贵的~
参考：百度百科 框架 http://baike.baidu.com/view/66971.htm?fr=aladdin
标签：http os 使用 sp strong 数据 on 问题 代码
原文地址：http://www.cnblogs.com/ryansunyu/p/4080985.html
