随着Flex在企业应用领域中的逐步发展，已经有越来越多的企业愿意选择使用Flex技术来实现他们的产品。这当中不乏有功能非常复杂的Flex应用。我今天想给大家分享的就是如何在一个复杂的Flex项目里使用QTP搭建一个可持续扩展的自动化测试框架。
在2007年，我们(siloon)开始和一家北美公司合作一个“云应用程序平台”，这个平台允许用户在线搭建以业务驱动的应用程序，用户可以在线创建数据库，建立表间的关系；创建应用程序 UI， 建立 UI与数据库的关系；创建复杂的业务逻辑，工作流；建立程序需要的各种视图，报表；创建多级的与业务逻辑有关的用户权限；以及其他一些辅助性的功能。 而这一切的整合实际上就是大多数企业应用需要的。 我们在Flex中实现了创建上述功能的Web 客户端。 而与此同时还有一个任务是如何保证我们的开发工作时正确的。我们需要测试，在经过一系列的讨论以后我们决定使用 QTP来保证平台的在我们持续开发的过程中不会出现任何大的错误。但是因为这个程序的特殊性（我们不知道它上面会产生什么样的应用程序），我们的测试方法就必须特殊，我们要搭建一个可以随意扩展的测试框架，保证测试人员可以快速的在上面开发自动化测试用例。我现在就将我们实现这一框架的经验与大家分享一下。这篇文章中你不会看到任何具体的代码或者很具体的例子，我想与大家分享的是我们思考这个框架的过程。如果你正好需要在你的Flex项目中使用到QTP, 这会是一个不错的参考。
首先第一个问题，为什么我们要使用QTP,它到底能帮助我们做到什么？
- QTP可以帮助我们做到回归 测试（Regression Test），它能帮助你保证已经正确的程序一直正确运行。但是永远别指望它去发现未知的错误。
- QTP可以保证它的测试一丝不苟，人工测试可以测试到更多的东西，但是如果每天让测试人员测试相同的东西，很多细节会被忽略，而QTP绝对不会。
- QTP可以帮助你做很好的持续测试，现在非常的多开发团队使用的持续集成工具，所以QTP能很好的在每次新版本编译的时候保证你的程序的主要功能正确。
- QTP可以节约测试成本。这点其实是相对的。完全取决于如何在在人工测试和QTP中做平衡。这两方面看似冲突但是其实是相辅相成的。
OK, 以上就是QTP也是其他任何自动化测试工具能帮我们办到的事，如果你还在犹豫是否应该在项目中使用自动化测试，相信这能帮助你判断。其中第一点是最重要的，也是为什么QTP不能取代人力测试的原因，如果你指望它去发现一个连你都不知道的bug,然后给你准确的报告，这是不可能的。当然我们可以让它在程序发生意外bug时给出简单的报告，截图，这是没问题的。但是最终你仍然需要人去确认，去重现这个问题。
说回到QTP在Flex项目中的测试，QTP是基于对象的测试工具，因此Adobe 在SDK里加入了几个帮助QTP识别Flex对象的包，关于如何让QTP测试Flex的配置我就不说了，大家只需要google一下QTP测试Flex会得到非常多的结果，跟着做一遍就可以了。我说几点QTP测试Flex对象的缺陷问题。
- 尽量不要让你的程序层次结构太复杂（过多层级的Box,Panel等容器），这样qtp的去找你的对象会话费很多时间，QTP的对象分为两块，第一块是保存在qtp library里的，这里实际只是实际对象的描述，在测试时qtp会去动态的根据保存的对象的描述去寻找真正的对象，所以如果结构太复杂，花的时间会越多。
- QTP不认识itemrenderer. 如果你的DataGrid里加入诸如combobox之类的itemrenderer, qtp无法对combobox进行操作。这时候你需要通过坐标的方式来对itemrender进行选择。
- 如果DataGrid里每一行中有重复的数据，QTP不能对其进行正确的选择或判断。
- QTP的录像功能不对对复杂对象的动作进行录制。
- QTP不能识别图表，比如饼图，柱状图等等，都不能识别，QTP只知道他是一个Object, 这时你可能需要截图对比的方式来判断结果。
总的来说QTP对复杂的Flex控件的操作会有一些小问题，大家使用的时候会碰到。说完了为什么用QTP以及它的一些问题后我们可以考虑如何搭建我们的框架了。QTP有一个最快捷的测试功能是录像，回放。在其他的Flex自动测试工具，比如一个开源的很不错的FlexMonkey.也是基于这样的方式。 把用户的动作录下来，然后可以经过一些修改，再保存。 这就算一个UI测试用例了。但是这种方法对我们的平台来说是远远不够的。试想一下我们要测试一个登录，创建应用程序界面，运行，这样一个过程。当然我们可以通过录像。但是当我们想要创建另一个应用程序界面时怎么办呢？再录吗？如果我要新建100个应用程序呢？这还只是一个简单的测试用例，试想一下我们可能的测试用例，测试权限，测试视图，测试工作流，等等。这些每一个都有N种不同的组合。我们不可能单靠记录和修改来完成测试。所以，我们需要在QTP中想办法能快速的做到这些。 而我们则基于面向对象编程的思想来搭建了这个框架。简单的说就是当测试人员需要写一个测试用例时，他只需要很自然的在qtp里描述这个过程。比如他现在需要简单的测试登录是否成功，他只需要这样写
Login(userName, password)
CheckLoginResult()
这样的写法，测试人员不需要知道太复杂的技术，他只需要知道自己的测试用例，只需要花时间来思考如何写很好的测试用例就好，所有中间的操作过程，我们都尽量封装。只需要少数的人来完成封装的工作，其他大部分人可以集中在测试用例的开发上。下面就是我们如何实现这种方式的一个描述
1. 构建基本对象库
QTP是面向对象的测试工具，我们基本对象库就是将项目中最最顶层的对象保存起来。比如保存最上层的Browser，在加上一些几乎不会改变的容器路径，比如主程序界面Browser(“browser”).FlexCanvas(“xxx”)。
2. 创建公用方法库
前面说到QTP的语言是VB script, 我们现在建立一个文件夹，叫做library. 里面会存放我们所有的vb脚本，这里我们创建第一个VB脚本Common.vbs, 这个文件里会存放我们测试项目中需要用到的公用方法，我们这里需要的第一个方法就是获取对象。QTP中的对象除了可以通过录像，spy的方式抓取外，还可以直接用表达式描述。 我们为什么要在第一步中把尽量把固定不动的容器抓取下来，是因为用表达式寻找的方式会消耗稍微多一些的时间，所以我们没必要所有的东西都描述，只需要描述比较动态的内容就好。表达式找对象的方式很多，下面是一个很简单的方式，通过automationname。
Public function getAName(fieldName)
Set result = description.Create()
result(“automationname”).value = fieldName
Set getAName = result
End function
3. 动态构建和返回其他容器对象
我们往library里加入第二个文件ObjectMap.vbs, 这个文件负责返回我们测试中需要用到的任何对象路径。比如我们要获取登录窗口，我们就会有一个方法叫做getLognPanel, 这个方法返回了loginPanel的容器对象，其中我们在FlexCanvas()里使用了getAName来获取一个automation的描述。这样FlexCanvas(getAName(loginBox))就能返回在FlexApplication(xx)对象下的id是loginBox的Canvas对象。我们就可以进一步操作里面的其他对象
4. 模块类文件
在2和3中我们已经往library加了两个文件，分别用来描述我们的对象路径和一些公用的方法，公用的方法的话还可能有比如waitObject(用来等待一个对象出现)，CheckAlert(检查警告框)， ScrollForm(滚动条滑动)等等这些和业务逻辑无关但是任何其他的脚本里都可能用到的东西。而现在说到的模块文件就是针对某个程序里的模块对应的文件。 比如程序里有登录View，那么我们可能就会建一个vb文件叫Login.vbs. 这里会放置和登录框有关的方法。比如上面写的login, checkResult。 这些模块文件就需要由对qtp掌握比较好的人来负责，他们需要更加的熟悉VB以及QTP本身的功能，而普通的测试人员可以只知道简单的QTP语法就好。所以当测试人员调用loing(userName,password)时，login方法里就会操作UI,填入用户名，密码，然后点击登录。checkResult方法自然就负责检查登录是否成功。接下来就是创建程序中对应的各个模块的文件，并实现他们能做到的UI操作方法, 所以当我们最终完善第四步以后，我们就可以模拟任何真实用户的操作了。实际上我们现在已经在使用QTP来直接根据客户的要求创建各种应用程序。
5. 创建测试脚本
有了第四步以后我们从测试脚本（Action）中就可以创建任意的测试脚本了，关于Action的使用就没有太多需要说明的。在Action中可以写一些公用(re-useable)的测试用例，拿我们的项目来说比如初始化一个应用程序的脚本。
6. 其他
在这个框架中还有一些其他的东西，比如config文件，用来配置比如测试服务器地址，测试文件保存位置等等全局的通用配置，根据实际需要加或者不加。
8. 善用DataTable
QTP有一个电子表格一样的东西叫DataTabel,它可以用来保存任何信息。善用DataTable可以帮助我们节省很多事，比如用它来保存测试时的全局变量，用来批量测试数据等等，这方面的知识使用到的时候可以查询资料。
好了，就写到这了。如果大家有兴趣探讨更多的话题，欢迎留言一起讨论。我们今年帮助SAP搭建了这样的框架，有效的帮助SAP和我们的测试人员在几个月内就完成了超过100+小时的测试用例。使用这个框架的好处有两个1. 大幅度节约测试用例开发时间。2. 最小限度的保证测试代码在平台不断开发时可以快速的适应。试想如果我们通过截取对象和录像的方式写了独立的很多测试用例，一旦测试程序有大的修改，我们修改测试用例的代价会有多大。