框架是什么，框架有什么用（转）

框架是什么，框架有什么⽤（转）
前两天跟⽼板出去做pre-sales. 主要是去卖我们的⾃动化测试服务，⼯具⽤的是HP UFT。

做过⾃动化的⼈应该知道，UFT在⾃动化测试领域已经算是最好的⼯具之⼀了。

客户是个有技术背景的⼈，所以不那么好忽悠。

我们准备了⼀⼤堆⾃动化测试优点的幻灯⽚，他倒好，上来直接问，你们的⼯具的缺陷有哪些。

然后我就开始巴拉巴拉地跟他说有哪些缺点，⼀发不可收拾的是，每解释完⼀个问题，他就会有更多问题。

最后⼝⼲⾆燥也没能全部解释清楚，除了感叹⼀声钱不那么好赚，只能怪⾃⼰不能⽤英语流利地吹⽜逼吧。

其中有⼀个问题，我回来以后⼜想了很久。

当时他指着我做的POC（Prove of Concept）脚本，问道：”既然record & playback可以做⼀个脚本，那么为什么还需要⾃动化测试框架呢？” 简⽽⾔之就是，我凭什么要多花钱买你们的框架？我当时第⼀反应是，什么？你在逗我吗？⾃动化测试没框架怎么做？当然我的回答官⽅的很，主要是从维护，可重⽤性，易⽤性地⾓度去跟他解释了⼀遍，他似乎也不是很满意。

回头我想了想，到底为什么我们需要⾃动化测试框架呢？越想越觉得委屈，因为我想问问各位开发，你们做项⽬的时候为什么要⽤框架呢？那⾃动化的本质不就是写程序去测程序嘛，既然开发需要框架，那么⾃动化测试为什么不要呢。

牢骚归牢骚。

认真地查了些资料。

什么是框架？
框架（Framework）是整个或部分系统的可重⽤设计，表现为⼀组抽象构件及构件实例间交互的⽅法;另⼀种定义认为，框架是可被应⽤开发者定制的应⽤⾻架。

前者是从应⽤⽅⾯⽽后者是从⽬的⽅⾯给出的定义。

可以说，⼀个框架是⼀个可复⽤的设计构件，它规定了应⽤的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为⼀组抽象类以及其实例之间协作的⽅法，它为构件复⽤提供了上下⽂(Context)关系。

因此构件库的⼤规模重⽤也需要框架。

其实⽬前为⽌，框架还没有统⼀定义，我⽐较喜欢Ralph Johnson所给出的定义：
⼀个框架是⼀个可复⽤设计，它是由⼀组抽象类及其实例间协作关系来表达的【Johnson 98】。

这个定义是从框架内涵的⾓度来定义框架的，当然也可以从框架⽤途的⾓度来给出框架的定义：⼀个框架是在⼀个给定的问题领域内，⼀个应⽤程序的⼀部分设计与实现【Bosch 97】。

为什么要⽤框架？
⼜是⼀个理所当然的问题。

因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。

在某些⽅⾯使⽤别⼈成熟的框架，就相当于让别⼈帮你完成⼀些基础⼯作，你只需要集中精⼒完成系统的业务逻辑设计。

⽽且框架⼀般是成熟，稳健的，他可以处理系统很多细节问题，⽐如，事物处理，安全性，数据流控制等问题。

还有框架⼀般都经过很多⼈使⽤，所以结构很好，所以扩展性也很好，⽽且它是不断升级的，你可以直接享受别⼈升级代码带来的好处。

为什么要搭建⾃动化测试框架？
从前我以为，⾃动化测试最重要的事情是找对象（Find Test Object）。

现在我明⽩了⼀个道理，没有框架的⾃动化测试是找不到对象的，即使找到了也不会幸福的。

就跟现实中，没有车没有房的⼈是很难找到对象的⼀个道理。

⾃动化测试的开发，通常是由⾃动化测试的需求决定的。

这个需求主要包括：
1. ⾃动化测试更便于实施。

这个说的是，你写测试脚本要⽅便。

⼀个好的⾃动化测试框架是可以让不那么懂技术的⼈也可以写⾃动化测
试脚本的，哼。

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

3. 测试易于维护。

⾃动化测试项⽬，基本都是没有好的管理以及维护，⼀定是个⼤坑。

我可以很负责地说，⾃动化测试没有⼀年半载，
你是看不到产出的。

所以管理及维护就成了最重要的事情。

⽽好的框架，可以减少你在管理维护中所投⼊的⼈⼒物⼒精⼒。

4. 可重⽤性。

框架的意义之⼀就在于可重⽤吧。

所以在框架⾥，你可以实现⼀些通⽤功能，简化脚本开发过程。

5. 美观易读的测试报告。

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

还有很多测试需求，我没办法⼀⼀列举出来，多数需求我们都可以在测试框架⾥去定制。

现在可以回答上⾯那个问题了，record & playback 是不会幸福的，你需要⾃动化测试框架。

请慎重考虑是否需要⾃动化测试（成本投⼊⾼，风险⼤）
⾃动化测试是个很傲娇的东西，它很挑项⽬。

⾸先项⽬周期要长，但是需求不会频繁变更；其次系统中多数对象要可以被识别，并且不存在⼤量第三⽅插件。

⽽且你要清楚，你不能指望⾃动化测试去帮你发现新的bug，⾃动化测试本⾝是不具备想象⼒的（相对于⼿⼯测试）。

它的优势在于反复迭代，它的价值产出在于长期的回归测试，以保证被测产品长期稳定地版本更新。

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

⽬前我所做的⾃动化测试成功案例，⽆⼀不具备良好的管理和优良的测试框架。

⼆者缺⼀，⾃动化测试必然成为⼤坑。

最后，填坑这种事⼉，收费可是很贵的~。