古往今来，天地四海，只要是人，具有独立意识之后，就有了追求幸福的渴望。但幸福是什么？去大街上拦住一百个人问问，没有人会不希望自己幸福，但追求的幸福是什么样，一百个人有一百个答案。

    在《求求你表扬我》电影中，杨红旗有一番自己对幸福的解释：

古国歌：“什么叫幸福？” 杨红旗：“幸福啊？” 古国歌：“嗯！” 杨红旗：“幸福就是我饿了，看别人手里拿个肉包子，那他就比我幸福； 我冷了，看别人穿了一件厚棉袄，他就比我幸福；我想上茅房，就一个坑，你蹲那了，你就比我幸福”

如果这是幸福的话，那么幸福也未免太随意了，按照杨红旗的思路，他要获得幸福很简单，只须向上闭上眼睛，向下睁开眼睛，发现乞丐还食不果腹，居无定所，那么自己不就获得幸福了么？

我以为幸福须满足两个条件，第一为重要性，幸福须是自己人生中重要的目标，可以影响自己活着的价值；第二为持续性，须从内心能够体验持久的快乐。按照这两个条件，其实就可以区分快乐和幸福。一个人饿了两天，吃上一顿美味，虽很满意，但只能持续一天，一个人和妓女春宵一刻，但只获得一时的快感。这些都可称作快乐，但不是幸福。因为他们固然对人本身很重要（食色性也），满足了条件一，但满足不了条件二。

这样说来，幸福既有主观性，也有客观性。像杨红旗那个例子，他对比对象的变化决定是否获得幸福，这完全是主观的。前不久社会科学院有个调查让人啼笑皆非，说社会中幸福感最强的是小城市中生活的市民。这种幸福拿句老话是“比上不足，比下有余”，只要其参考系发生了变化，幸福感就丧失了，所以我说这是虚假的幸福，主观上的幸福。

真正得幸福是辨证的，是主观性和客观性的对立统一，对立性在于幸福具有主观性，也具有客观性，动机和欲望是主观的，目标是客观的，追求的过程也是客观的，统一性体现在主观与客观的变化，并趋于一致。

形象点，就如哲学家罗素曾说过的一句话：‘人如果不改变自己，就注定永远获得不了真正的幸福“。这其实就是在说主观和客观的统一性。

再实际点，当今高学历自杀的人越来越多，硕士，博士跳楼。我相信这些跳楼者都渴望幸福，并有一种与生具来的倔强，坚持并执着自己的幸福，但屡屡在现实中碰壁，一次次希望，又一次次失望，最后成了绝望，改变不了现实的情况下，又无力改变自己，对自己，对现实都绝望了，才会走上不归路。

一个人可以有时可以改变周围的事，但却改变不了自己，那么他纵然可以获得让人羡慕的东西，但内心却是痛苦的，注定获得不了幸福。

这两个看似不相关的论述是我在春节期间听到妈妈和老同学的闲聊电话而触发联系思考的。当时，妈妈的老同学感慨地说：时间过得真快，恍惚中觉得昨天还是刚出嫁，今天就子孙满堂了。这真是“时光如箭”，从她的体验来看，时光之箭从70年前射出到现在，她中间必然经历了一定人事风物，但为什么在主观体验中，没有留下特别的记忆呢？也就是说，为什么她一下子想到的上一个参考点是“出嫁时”，而不是昨天，前天呢？

我思考良久，发现这个问题其实一点都不简单，必然会牵涉到“唯物”与“唯心”的庞大话题上来。所以我打算从“飞矢不动”悖论开始，做一些简单的思考分析。

芝诺的“飞矢不动”在现人来看，似乎很荒谬，但这个论题的逻辑是完整清晰的，可以经得起推敲的。芝诺的想法是，如果箭从A1点运动到An点，在某个时间点上，必然停留在A2，A3，A4……某个点上，那么一系列静止点的集合最后怎么就会变成运动了呢？由此又可进步思考，运动是否只是人的主观体验，而非事物的本来真相？

简单的表象背后往往蕴含着复杂的道理，古往今来，哲学家们对一个简单的“飞矢不动”悖论认真地进行了分析和论证（参看注）。我把他们的观点归纳为两种人生态度，一种是“虚无派”，即认为飞矢只是从一个位置移动到到另外一个位置，中间到底经历过了哪些位置，是无法分析的，就如人一辈子只有“生”和“死”是真实的，中间的经历都是虚无的，可谓“人生如梦”。另一派则为“现实派”，飞矢的目的是An，只要经历过A1,A2，A3……就可顺利到达An，就如人生需要按部就班，进行周密规划，但为什么人生的目标是An，为什么A1之后必然是A2，“现实派”给不出答案，最后它只好寻求上帝来解答，这也就是为什么伟大的牛顿在晚年转而开始宗教信仰。

在我想来，芝诺的悖论是一个客观存在的矛盾。飞矢的运动本身就是一个矛盾，飞矢在某个时刻到达A点的时候，也是它离开A点的时候，所以飞矢的运动是既到达，又离开。它并非真的静止停留在A点。

同样，“虚无派”和“现实派”也是一对矛盾，“虚无派”是人的主观体验，“现实派”则是客观的考究。

破解“虚无派”的方法应该很简单，假设在A1到An之间的路上设置一个铜铃，当飞箭经过的时候，会引发铜铃发出振动响声，那么可以飞箭就能知道自己真实地经过了此处。这种体验又类似量子力学中的“测不准”，当你对电子进行观测时，电子不知在何处，但一旦设置参考点观测，它就真实地存在在那里。

人生也便如此，人生的虚无感需要引入“铜铃”作为参考点。妈妈的同学的时光之箭上的一个铜铃是“出嫁时”，可惜她从此之后再没有遇到过其它铜铃，因此从“出嫁时”到现在的时光过程是恍惚的。

人一辈子的的生与死，如飞箭的开始与到达，是一个运动的矛盾过程，人经历过某个时空，但也离开了这个时空，虚无感由此而来。要解决这个问题，必须在人生的轨迹上安排多个铜铃，以获得真实感受。

由此，可以推论：

1. 没有目标的人生是虚度的

2. 不能自我超越的人是恍惚的

注1：

尼采：在芝诺的这两个悖论里，“ 无限” 被利用来作为化解现实的硝酸。如果无限是决不可能成为完善的，静止决不可能变为运动，那么，真相是箭完全没有飞动，它完全没有移位，没有脱离静止状态，时间并没有流逝

  首先以地球人为代表的强大的土地开发商集团，看中了潘多拉星球上的土地，但有一批不懂经济只愿过小农生活的穷鬼土著纳威人占这片土地了几百年，不愿搬迁，而且经过拆迁补偿的对话后，开发商集团总裁帕克发现这些纳威人只认死理，忽悠根本不起作用。
   这么好的有着巨大商业开发价值的土地，在你们穷鬼手里也就是个用来栖息的树洞，我们开发商却能开发出价值连城的宝藏，这不符合市场经济嘛。于是，帕总深谋远略，做了两招准备，一招派出公务员杰克去做纳威人的思想工作，当然背地里，杰克还有另外一个重要的任务是搜集被拆迁地的地势地貌，为第二招的执行人城管大队队长迈尔斯提供情报。

本来帕总的如意算盘打得十拿九稳，不料意外还是发生了，久经考验的公务员杰克同志在潜入敌方阵地后，中了美人计，而且革命人道主义爆发，本职间谍工作忘在了脑后不说，还拿起砖头帮助纳威土著暴力抗法，袭击城管车。这下惹怒了城管大队队长迈尔斯，你们这帮穷鬼敬酒不吃吃罚酒，老子花大价钱政府采购的城管装备可不是吃素的！

于是本剧的高潮部分来了，迈尔斯率领的城管大队开动铲车，坦克，燃烧弹，以迅雷不及掩耳盗铃之势强拆了智慧树，而且精确击毙了暴力抗法的杰克同志未来的老岳父，这下子彻底使杰克同志从无间道上转移到正面抗战前线上去了。双方进行了惨烈的拆迁与反拆迁的对抗，手无寸铁的钉子户哪是武器装备精良的城管的对手，眼看在城管大队即将扫平杰克为首的钉子户的时候，伟大的卡梅隆导演实在不忍目睹这种现实的惨烈，立即安排了圣母显灵一场，最终帮助杰克同志钉子户反败为胜。

卡梅隆不仅在欧美电影史的票房上创造了奇迹，而且也为中国电影开创了社会写实的多个第一次，第一次从文化价值观的角度看房屋拆迁的冲突，而非以往官方的市场论；第一次大胆地揭示钉子户只有抗争才能胜利的实践方法，圣母显灵跟“god help who help themselves”一个道理。

 QTPDriver_java的目标：

1.  使用java语言实现qtp automation object model，并在此基础上构建完整的自动化测试解决方案，包括健壮的错误诊断处理，和丰富的自动化测试报告等等。

2. 为qtp脚本提供丰富的框架规范及接口，以解决qtp脚本的健壮性和可诊断性问题。

目前有两个配置文件：

1. QTP 环境配置文件config.xml，格式如下：

主要是qtp启动的相关参数，包括synctimeout，screenshot的设置，测试运行的最大超时时间等等。qtpdriver会读取这些参数，并通过automation object model设置到qtp的运行实例中去

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE properties SYSTEM “http://java.sun.com/dtd/properties.dtd“>
<properties>
<comment>This is Config xml for AC agent,the screen shot value could be ERROR,NONE,ALL</comment>
<entry key=”GENERATE_FILE_ONLY”>false</entry>
<entry key=”RECOVERY_LEVEL”>1</entry>
<entry key=”SCREENSHOT”>ERROR</entry>
<entry key=”SYNC_TIMEOUT”>20000</entry>
<entry key=”TEST_TIMEOUT”>18000</entry>
</properties>

2. 测试执行脚本任务文件，格式如下：

qtpdriver会在运行的时候，读取此xml，执行不同响应的测试任务

<suite name=”demo_test_suite” desc=”this is a suite for demo”>
  <component name=”demo_test_component” desc=”this is a component test for demo”>   
    <casefile file=”D:\learn\cesoo\cesooProject\JavaQTP\QTPAgent\driver\testscripts\flightDemo” desc=”flightDemo”></casefile>
    <casefile file=”testscripts\flightDemo” desc=”flightDemo”></casefile>
  </component>
</suite>

3. java_qtpDriver的功能如下：

1）启动qtp，按照配置文件中的参数，完成qtp的相关设置

2）加载recovery 场景和相关lib

3）读取测试任务xml文件，循环执行指定的测试任务，直到结束

4）生成qtp结果报告，并在qtp报告的基础上，再做一层分析，最终生成xml报告，如下：

总结一下：
qtp_driver的优势是
1. 全java编写，提高测试的稳定性和可靠性
2. java命令即可触发自动化测试的执行和结果报告的收集，完全实现无人值守运行
3. 强大的报告功能，生成基于qtp的总览报告及细分报告，直观简洁，适合回归测试
4. 持续开发改进
qtp_driver的劣势是…..目前下载只对读者用户开放，普通用户必须经过管理员升级，方可获得下载权限
使用指南
1. 下载附件zip包，并解压
2. 双击运行install_driver.bat，完成driver系统文件注册
3. 编辑TestSuite.xml文件。通过增加<casefile>节点，来添加已有的qtp脚本
3. 双击runqtp.bat，开始运行qtp测试任务
4. 会在当前目录下生成results子目录，保存qtp各个脚本的测试结果报告，同时ac会为您生成一份总览报告ACSummary.html，在results/timestamp目录下。

可在本人博客站内论坛下载框架jar包（提示一下，因为本人博客空间性能有限，下载仅对读者用户开放）
http://www.cesoo.com/bbs/viewtopic.php?f=3&t=28

也请您支持我的两本书《性能测试从零开始-loadrunner入门》，《软件自动化测试框架设计与实践》。:)

1.1  案例1：脚本开始处首先进行环境检查
下面是一段linux系统上运行的perl脚本代码，功能是调用产品后台管理位于$ORACLE_HOME/bin目录下的add_user命令，根据存储在users.txt中的用户信息列表，依次在产品系统中创建测试账户。

my $data;
open FH, “< users.txt”;
while (<FH>) {
 chomp;
 print “users are $_\n”;
 $data=$_;
}
my @users=split(’,', $data);
foreach my $val (@users){
print “$ORACLE_HOME/bin/add_user –firstname $val –loginid $val –initial_password 123456 –email_address $val@gmail.com“;
}

上面的这段脚本由负责产品安装测试的工程师小李开发，每次安装完被测软件系统版本后，自动地运行这段脚本，就能直接把测试用户信息等初始数据创建到数据库中去。
但，可以看出要想能够成功运行该脚本，其前提条件是$ORACLE_HOME必须已经在linux系统环境变量设定，如下：
export ORALCE_HOME=/home/oracle/10123/Orahome1
这时，脚本代码
print “$ORACLE_HOME/bin/add_user –firstname $val –loginid $val –initial_password 123456 –email_address $val@gmail.com“;
会将$ORACLE_HOME替换成环境变量里设定的实际目录，实际执行如下：
print “/home/oracle/10123/Orahome1/bin/add_user –firstname $val –loginid $val –initial_password 123456 –email_address $val@gmail.com“;

但这段脚本显然忽略了一个很有可能发生的场景，那就是在脚本运行之前，如果测试人员忘了设定或者设错了$ORACLE_HOME环境变量，脚本就会因为找不到add_user命令，报出一堆莫名其妙的错误。这会降低测试脚本执行的效率，提高诊断错误的难度。
要想解决这个问题，就应该增强脚本的健壮性，在脚本开始处检测$ORACLE_HOME环境变量是否存在，并作相应地处理。修改如下：

#detect the $ORACLE_HOME, if not exist, then prompt info to user and exit
if($ORACLE_HOME eq “”)
{
        print “Error: Please specify the Beehive Home\n”;
        print “\n”;
        print “Usage:\n”;
        print “  perl create_user.pl -beehome <BEE_HOME>\n”;
        print “- beehome: The location of the Beehive Home.\n”;
        exit;
}
#end detect
my $data;
open FH, “< users.txt”;
while (<FH>) {
 chomp;
 print “users are $_\n”;
 $data=$_;
}
my @users=split(’,', $data);
foreach my $val (@users){
print “$ORACLE_HOME/bin/add_user –firstname $val –loginid $val –initial_password 123456 –email_address $val@gmail.com“;
}

修订后，脚本能够在第一时间内检测到环境变量的错误，并提示用户，然后退出，避免了错误扩散。

【思考1】
一个产品安装脚本，在脚本开始处应该考虑做哪些环境检查？
【思考2】
在脚本开始时进行环境检测，那么在脚本结束时应该做哪些操作？

这些都是对自动化测试的致命问题。第一个问题直接质疑自动化测试的有效性，第二个问题是有关自动化测试的可维护性，第三个问题则是自动化测试的可扩展性。
这三个问题综合在一起，就动摇了自动化测试它在项目中本来的作用和意义。而出现这些问题的主要原因就是在一开始的时候，自动化测试项目没有尽早地建立相应的规范体系。

 1.3.2 规范应该考虑哪些因素
规范（standards）是大规模自动化测试实施的一个重要先决条件。通常它也是一个团队自动化测试成熟经验的智慧结晶。它要帮助自动化测试团队建立如下共识。
1. 测试工具
市场有很多自动化测试工具，大多是基于录制-回放的。但在实现中，不同的工具有不同的侧重点，要根据项目自身特点来选择合适的工具。
2. 自动化测试脚本库
自动化测试脚本库的建立原则是每个项目应该有自己的脚本库，并且要保证脚本库里没有冗余的代码。比如我们有一个公共库函数负责创建随机数和随机字符串，那么这样的公共库函数有且只能存在一个。而且，在扩展函数库的时候，不应该影响到已有脚本正常调用函数库。
3. 日志
定义一个共用的日志策略对自动化测试维护来说非常有帮助，它可以让团队的每个成员都能理解和调试自动化产生的报告。策略要明确一些信息：
1）日志采用什么格式？是文本还是html，还是xml？
2）日志存储在什么地方？是放在文件系统里，还是数据库？
3）自动化测试人员在什么情况下写日志？日志里包含哪些信息？
4. 错误处理
当脚本遇到错误的时候，应该怎样处理？应该立即退出脚本运行，还是清除环境再运行一次？如果比较复杂的话，就应该考虑建立一个错误等级制度，以使脚本遇到不同等级的错误时，做出不同的处理。
5. 运行环境
要明确定义脚本运行的环境要求，比如
1）操作系统信息，是XP还是visita
2）被测软件的安装情况
3）是否需要其他产品的安装，比如测试outlook插件的前提是必须先安装outlook。
6. 与框架的接口
框架应该脚本传递什么样的参数信息？采用什么方式传递？这些信息包括被测系统的地址，需要运行的测试集合，测试账户，密码等等。
7. 环境初始化及清除工作
应该定义每个脚本在开始运行之前都应该做环境预检测和初始化操作，在结束的时候做环境的清除工作。每个脚本都要做这些操作，因此以公共函数库的方式提供给脚本开发者更合适些。
8. 编码风格
编码风格包括变量命名规范，函数定义，注释率等等
1.3.3 如何有效地推行自动化测试规范
建立自动化测试规范是自动化测试实施的一个重要环节，但同时要注意的是，规范建立了，不一定代表它就会有效地被遵循。因此，在推行自动化测试规范的时候要注意以下几个因素
1.团队充分参与
在建立规范的时候，一定确保团队中的每个成员都要有效地参与，并最终达成共识。
2.文档化
规范要文档化。一份好的文档会大大提高组内成员的交流效率。
3. 评审
在规范执行的过程中，还应该建立定期评审的机制，以确认规范被切实地执行。

自动化测试的实施和运行的过程中，至少会产生三种工件：
（1）自动化测试案例脚本
（2）自动化测试公共函数库
（3）自动化测试结果报告
一般来说，对于文件有两种管理策略
（1）严格的版本管理策略
比如代码管理工具clearcase，cvs等，它们的特点是提供了先进的版本分支和归并功能，并且同时具有非常严格的检入/检出机制。在很多成熟软件组织的版本控制过程中，开发人员修改一个文件要经过多层流程上的审核，多次测试之后，然后才可以进行归并等操作。
因此，它的优点是保证安全性和稳定性，缺点是流程繁琐，效率不高。自动化测试工件采用代码管理工具的工作流程图如图7-25所示。
 
图7-25 基于严格版本管理系统的自动化测试脚本管理图

在上面的解决方案中，自动化测试脚本的版本分支与归并应该遵循其对应的被测软件产品源码的管理策略。比如1.0.1版本的软件产品代码下建立一个automation目录，专门存储自动化测试工件，这样，每当软件版本升级时，脚本也同样进行升级。
【思考】：为什么这样做？

（2）. 宽松的版本管理策略
宽松的版本管理可以由文件目录存储来实现，通过规划文件目录层次和目录名来描述文件的版本结构。如图7-26所示。
 
图7-26 基于目录结构的测试脚本管理方案

需要注意的是，利用windows文件系统中管理自动化测试工件，一般要符合以下两个原则：
（1）. 一般地，目录结构的深度不超过三层，三层以上的目录会带来查阅的困难和维护工作量。
（2）. 因为在基于目录的代码管理策略中，版本由目录来描述。升级到1.0.2版本，就需要建立一个新的目录来存放1.0.2版本的脚本集。因此，我们的原则是尽量减少版本目录中脚本的个数，以减少相应的维护工作量

【思考】：我们为什么把function lib放在根下，而不是版本目录下？
【思考】：针对目前的QTP自动化测试脚本，我们是采用严格的管理策略还是宽松的策略？那么在框架的实现中，又该如何整合这些管理策略？
 到此，现在我们的框架如图7-27所示。
 
图7-27 UI框架管理方案

5. 自动化测试框架高级解决方案

在完成上述四个步骤后，我们的测试框架已经从从代码到策略到规范上，都有了一套实现和解决方案。到这里，聪明的读者从这一步步的框架完善的过程中，已经意会了框架到底是何物，没错，框架其实就是为解决我们在自动化测试中的种种问题而生。因此，框架不是我们自动化测试的最终目的，它只是高效高质量自动化测试的保障手段。为了提高自动化测试的效益和效率，我们开动脑筋，可以开发代码，可以制定规范，也可以重构流程等等，这些最后形成了一个有机的体系。这个体系我们给它取了个名字，叫软件自动化测试框架。

因此，可以推断，框架是一个自动化测试长实施过程中长期实践积累的最终结果。那么对于一个软件测试自动化刚起步的企业来说，就只能“摸着石头过河”，没有办法缩短这个过程吗？答案当然是否定。根据唯物分析观，世界上有万事万物，每种事物在本质上都具有共性和个性。因此，一个企业遇到的自动化测试实施问题可以划分为：
全部问题=自动化测试的常见问题+企业的独特问题
自动化常见的问题包括健壮性问题，执行拓扑问题和测试报告问题等等，这些完全可以借鉴一些成熟的经验和解决方案，而企业则把更多的精力放在解决个性问题上。
这个通用问题的框架解决方案是什么？它又如何工作？这就是下章我们要介绍的主角-Automation Center分布式测试框架解决方案。

(3)代码实现data层
驱动函数如下：
import java.net.URLEncoder;
public class TestURLEncoder
{
   public static void main(String args[])
  {
try{
//初始化数据源，即完成从xml文件到对象的存储
   MyXMLData data=new MyXMLData()；
   For (int i=0;i<data.getSize();i++)
  {
String strToEncode = data.get(i).getValue(“EncodeString”);
String strEncoding= data.get(i).getValue(“Charset”);
String strExpected= data.get(i).getValue(“Expected”);
;
//调用URLEncoder
 String strAfterEncoded = URLEncoder.encode(strToEncode, strEncoding));
 //对比
 If(strAfterEncoded== strExpected)
   //输出
  System.out.println(”Pass: Verification is successful”);
Else
  System.out.println(”Fail: Verification is fail”);
}
}
catch(Exception e)
{
   e.printStackTrace();
   System.exit(1);
 }
}
}

作了如上修改之后，单元自动化测试框架实现了两个目的。
（1）. 每次测试URLEncoder的数据都通过MyXMLData对象从数据源mydata.xml中提取
（2）. mydata.xml有多少条EncodeData记录，For循环就会运行多少次，从而实现了数据源灵活扩展的目的。
为了达到上述的目标，我们需要自己开发MyXMLData类，至少实现三个方法
1）MyXMLData()初始化方法，实现从xml文件里读取数据
2）MyXMLData.get(int i)方法, 按序号获得某条记录，以哈希表的方式返回
3) MyXMLData.get(i).getValue(String)方法，通过key名获得某条记录的字段值，即我们想要的EncodedString，Charset，Expected。

【注意】：MyXMLData就是我们测试框架的data层的雏形。

【注意】：第二步的整体思路其实就是Junit的功能雏形

1.1  测试的自动化-以工具为中心
自动化测试是在软件质量要求日益提高，测试工作愈加繁重的背景下横空出世的。显然在自动化测试诞生之初，测试人员最迫切的愿望就是通过自动化测试的实施来摆脱重复的工作量，即回归测试中的案例执行工作。怎样完成这个从测试案例到测试程序的转化呢？显然，使用已有的自动化测试工具解决方案是最有效的。
因此，这个阶段最明显的特征是所有的自动化测试实施工作是以工具为中心，在这个阶段的过程中，要完成的工作如下：

…………………………………………………………………

 1.2 百家争鸣-形形色色的自动化测试框架
在众多书籍和网络论坛中，经常被提到的有代表性的自动化测试框架思想有以下几种形式：
1.2.1  数据驱动测试框架（The Data-Driven Testing Framework）

1.2.2关键字驱动或表驱动测试框架（The Keyword-Driven or Table-Driven Testing Framework）

1.3 自动化的测试-测试框架应该是这样的
如果说前面谈到的自动化测试实施还是在一个点上下功夫，那么本阶段就是在一条线上作战了。“自动化的测试”的内涵更加丰富，它意在将软件自动化测试中所涉及的各个环节作为一个统一的整体考虑，从测试脚本的管理，测试脚本的执行到测试报告的展现都有相应的策略，规范定义及自动化实现，故称这个阶段为“自动化的测试”。

简而言之，我们在自动化测试实施中会遇到各种各样的问题，有的是关于流程，有的是关于自动化测试本身，还有的是关于规范等等，这些问题不可能通过单一的自动化测试编程手段解决，而是需要一个有机的系统的解决方案，这个解决方案就是测试框架。

因此，测试框架相比单个的测试脚本具有以下特点：
a．测试框架位于软件测试的战略规划层次，而非执行层面
 很显然，测试框架在测试流程上表现为手工测试与自动化测试的整合策略，在组织上是一套自动化测试管理开发及执行的规范。这些改变对传统手工软件测试的工作内容和方式的影响是巨大而深远的。
b. 测试框架具有组织上的延续性和软件上的扩展性
 测试框架在软件测试组织中的建立和成熟是一个长期的过程，一旦建立，测试框架就可作为组织的知识经验甚至文化的一部分，随着团队的发展而延续，同时，由于被测软件的更新和测试人员技能的不断完善，测试框架也是一个不断进行扩展和更新的发展过程。这必然就对软件框架要求在软件上具有较高的扩展性性。

那么自动化测试框架作为一个整体解决方案，到底包含哪些组成部分呢？

一个好的目标，首先它能够赢得老板的眼球，并有可能逐步转化为老板对你自动化测试实施的支持。
自动化测试项目的实施离不开上级领导的支持，这是一个组织上很关键的因素。因为自动化测试前期的准备要投入人，时间，金钱等资源，比如自动化测试需要买工具，工具则需要培训，而开发工具脚本又需要投入人和时间，如果领导不能在这些方面给予支持，测试人员就真的就成了“巧妇难为无米之炊”，自动化测试的成功更无从谈起了。
所以，在自动化测试的启动阶段，一定要先有一个好的而且可行的自动化测试的目标或想法，它会吸引老板的注意力，并可能获得支持。尤其在自动化测试实施已经比较成熟的企业里，在众多自动化测试解决方案里，一个让人耳目一新甚至拍案叫绝的方案会给老板留下深刻的印象。

但是对于自动化测试刚起步的企业来说，有一些需要特别注意和警惕的地方。这是因为，在知识和经验都不丰富到足以洞察自动化测试本质和规律的时候，很多老板表面上对自动化测试是热情的支持，但实际真实的态度却是底气不足，半信半疑。
我曾遇到过两个极端的例子，一个是某通讯企业的研发总监，在软件开发和测试领域都有深厚的经验，但对自动化测试却有着深刻的怀疑，他认为QTP等测试工具并不能真正地从根本上解决测试效率的问题，因此他一直下意识地回避和推迟团队中自动化测试的实施；而另外一个例子是某大型外企的测试经理则是一个技术专家，他对软件自动化测试十分地钟情，几近狂热，认为任何工作都可以交付给程序来做，因此他把自动化测试推到了极致，他的团队开发了大量的脚本和程序，有的只为demo，有的只为验证bug。
这两个极端的例子其实是当前软件业界自动化测试实施的缩影，实际上，这两个人的表现更像是同一个人的两面性格，自动化测试上马时盲目乐观，失败后“恨屋及乌”。一番折腾下来，他们对自动化测试是敏感和谨慎的，对于你提出的任何自动化测试目标，他们表面上会支持，实际上更多采用的是观望态度。换句话说，在这种情形下，老板对自动化测试项目的支持是犹豫的和脆弱的。因此，老板是否能够保持对你强有力和持续的支持，不光你要有一个好的自动化测试目标，而是更取决于后续的自动化测试实施能带来实实在在的效益。 

【案例】：
测试主管小王打算在自己的测试部门实施系统测试自动化，在经过工具评估后（有关评估详见第三章Evaluation一节），他和他的团队决定使用java开源的selenium做为测试工具。这个想法获得了小王上级张总的认可和支持。
挑战：小王在着手实施的时候，有如下疑惑和困扰：
（1）小王和他的团队没有丰富的自动化测试实施经验，因此，虽然经过了前期的测试自动化效益估算，但对于selenium的解决方案到底能否在项目中实施成功，要开发投入多少人力，维护量有多大，小王依然心里没有十足的把握。
（2）小王的上级张总是一个雷厉风行的人，他对这次自动化测试的实施也抱有很高的希望，小王如何能够说服张总认识到自动化测试实施的风险，并能给予理解和持续的支持，这是一个要考虑的问题。

对策：小王决定采取以下的措施来最大程度地减小风险，并获得张总的理解和支持。
（1）对于第一个问题，由于对测试脚本程序的规模和功能都无法准确预测，小王决定采用快速原型法来开发自动化测试程序，首先在部分核心功能模块中做试点，一边实施一边总结经验，然后再将成功经验进一步推广到整个产品模块。
（2） 关于和张总的沟通交流问题，小王决定先准备一个自动化测试的演示程序，邀请张总参加演示会。在演示会上，小王准备了三个演示点，一个是有关自动化测试能替我们做那些工作，一个是自动化测试不能替我们做的工作，另外一个是自动化测试运行中的各种风险和干扰因素。
结果：最后实施的结果是：
a. 小张通过快速原型开发方法，以时间为代价换来了自动化测试实施的稳定和高质量，这为自动化测试的成功实施提供了技术保障。
b. 张总对演示会的内容十分感兴趣，并且和小王约定每隔一个月就进行一次演示会，以便了解自动化测试的状态和进展，并及时解决中间出现的问题。这为自动化测试的成功实施提供了组织保障。