关键性能指标(Key Performance Indicator, KPI)

关键性能指标是最能描述系统性能的一种数据。 关键性能指标的类型如下表所示。

其中服务能力指标是最核心的指标。 也是用户最关心的指标。对于最常见的Web网站， 服务能力指标最常用的是“相应时间”和“吞吐量”

分类	举例
服务能力指标*	l  响应时间： 表示从发出request到收到response的时间 l  吞吐量：表示单位时间系统处理的request的数量 对于吞吐量，不仅仅限于单位时间Request的数量，比如对于一个文件服务器，单位时间读写的字节数也是“吞吐量
资源利用率指标	主要是CPU和Mem利用率
稳定性指标	长时间运行， 系统服务能力是否下降， 资源利用率是否非正常上升。
可扩展性指标	增加更高级的硬件(Scale up), 或者增加更多的节点(Scale out), 对于服务能力的提升程度。

 

对于 流水线模型的软件， 其服务能力的获得相对OLTP模型的软件会比较困难。 对于Response Time， 需要收集信息入口和出口的时间；对于Throughput， 需要收集各个关键module的吞吐量。

性能计数器  

性能计数器是在性能测试执行时收集的数据。 关键性能指标其实就是从性能计数器中直接或者间接产生出来。 但是性能计数器不仅仅包括关键性能指标， 性能计数器的范围会宽广很多。

 

从性能计数器的来说， 通常分为以下几类。

l  压力模拟器的计数器

单位时间比如Request的数量， 及其响应时间。

l  被测试产品本身的计数器

比如内部Queue的长度， 单位时间Queue的输入的量和消费的量。

l  应用服务器和数据库的计数器

参见相应文档。

l  操作系统提供的计数器

参见相应文档。

 

性能计数器除了用来标示系统性能， 还可以用来分析性能瓶颈， 指导性能优化。比如说， 磁盘读写Queue的长度是衡量磁盘是否是瓶颈的关键信息。

 

无论是OS还是商业性能测试软件， 都提供了海量的性能计数器。 通常来说性能计数器的问题是， 如何选择最有价值的性能计数器。这需要对被测试软件， Application服务器， DB服务器， 和操作系统有深入的了解。

前言：
做了很长时间功能测试，自动化测试， 但性能测试一直都是蜻蜓点水的样子。 这半年终于， 能够对性能测试有了比较深入的了解，并积累了一些经验。 所以准备在这里记录下来。

首先， 我想先指出的是， 我所测试的产品不是通常的网站， 而是 企业内部使用的监控类型的 软件产品。和网站相比， 其性能测试有自己的一些特点。

总的来说， 性能测试的经验包括三个方面。

• 性能测试模型分析方法
• 性能测试工具开发(VBS)
• Jmeter的应用和Plugin开发

第一篇， 我想说说 “为什么需要对性能测试模型”

====================================================================

模型的意义在于它化复杂为简单， 同时不丢失最关键的属性。 建立模型是为了帮助我们更好的理解一个复杂的事物。 那么问题是“性能测试很复杂吗?”, 接下来的问题是“如果说性能测试很复杂， 那么复杂性体现在什么地方?”

性能测试复杂吗？ 一句很废话但是也是真话就是， 初看简单， 深入复杂。

我认为性能测试的复杂性体现在三个地方。 第一个是性能参数， 第二个是输入场景， 第三个是性能测试的目的。

性能测试的参数， 就是任何对系统性能有影响的参数。 比如不同硬件配置， 不同的应用服务器或者数据库服务器， 不同的系统的配置参数， 这些参数的变化都会影响最终系统的性能， 那么在搭建性能测试环境是， 到底如何对他们进行选择呢？选i5还是志强， 工作线程选5还是10？

输入场景是对于性能测试时输入的描述。 比如对一个电子商务网站的性能测试， 每一次成功的购物应该包含几个request， 分别是什么类型？ 如果是大型打折活动， 用户的购物流程有什么变化?

性能测试的目的更是令人头疼。 在开始一次性能测试之前，对软件产品的相关角色做一个调查， 会发现你收集到的结果是五花八门。

• l  客户: 我觉得某个页面反应很慢.
• l  客户: 某一个通知邮件本来应该在5分钟内收到, 但是半个小时都没有收到
• l  技术支持: 客户问该系统到底能支持多少用户?
• l  技术支持: 客户问如果交易量提高50%, 需要购买什么样的硬件?
• l  Dev: 我希望性能测试能帮助我们找到系统的瓶颈.
• l  Dev: 我想优化性能, 但是我需要得到不同参数下系统的性能, 你能提供吗?
• l  产品经理: 客户对我们的系统性能抱怨很大, 你能不能告诉我系统的性能到底如何?
• l  产品经理: 新版本性能提高了多少?

作为性能测试项目的Owner， 你要考虑， 应该如何设计性能测试， 使得最少的测试能满足最多的要求？

建立性能测试模型可以帮助我们处理上面所涉及到的复杂性。帮助我们生成最有效率的性能测试案例。

后记

QTP软件测试开发应该是什么样的？怎样才是高效的开发方式？QTP软件测试只需要三个月的培训就能做好吗？

在开始进入QTP自动化测试开发之前和之中， 我有这样一些疑问。 慢慢的， 我体会到自动化测试开发和其他通用的软件开发并无根本之不同。 也就是说软件开发中你能看到的一些概念，比如： 模块化， 低耦合， 面向对象， 敏捷， 设计模式， 可维护性， 接口设计。。。在QTP自动化测试开发中同样适用。 没有软件开发的基本素养， 同样也不能开发好一个QTP自动化测试项目（我承认，或许能够开发出来， 但可维护性会很糟糕）。

但是， 因为从事QTP自动化测试开发的人员很多都是QA而不是Developer， 所以QTP提供了很多方便的智能的工具来降低上手的难度， 并且打出了”不会程序设计也可以做QTP自动化测试”的口号（这种现象其实在别的开发领域也有， 比如“三十天掌握J2EE”等等）但是， 这些工具虽说是捷径但却牺牲了软件开发中一些基本的要素。简单来说， 这些工具像积木， 可以搭房子，但不能建立大厦。所以， 我慢慢的抛弃了这些工具， 而转向了我所熟悉的， 通常的软件开发方式来开发QTP自动化测试项目。

实践也证明了， 通常的软件开发方式也完全可以开发QTP自动化测试项目， 而且开发效率和可维护性还更高（至少对我而言）。

到此为止， 我对于QTP自动化测试开发的绝大部分想法和经验都和你分享了。希望能对你有所启发和帮助。(DFL, 2012/09/07)

QTP使用中的陷阱

不要使用Reuable Action

用Function， 不要用Reusable Action。 没有一种通用的语言里有Reusable Action这个概念。 而且通过Function等一些标准的程序设计语言的元素， 你能够实现任何Reusable Action可以实现的功能， 而且更好， 更快， 更易于维护。

以前我还不能肯定这一点。 现在我能肯定的告诉你， 因为有好几个QTP项目， 上千个Testcases在支持我的观点。

不要用Smart Identification

有一天， 我发现一个奇怪的现象， 一个testcase里某一个点击logout button的步骤运行非常慢， 大概要20秒，但是最终它还能成功点击。 不巧的是每一个testcase几乎都会点击这个button， 所有我还必须把这个问题找出来。 最后发现这是因为button的name有了变化， 但是因为Smart Identification是被enable， 所以QTP会试图去适应这个变化， 但是这个“适应”的效果非常不理想。

我认为测试开发者应该完全控制对象的识别。把选择权交给对被测程序业务一无所知的工具是毫无道理的。我想不到任何使用SmartIdentification的原因。 所以，从那之后， 任何Testcase的Smart Identification我都禁止了。

不要在base目录里添加两个或以上目录

Base目录是用来只能识别相对路径的目录。其配置在Menu: Tools->Options->Folders。我的建议是这里只放项目根目录。其他目录都不要放进去。

 曾经， 我接手了一个QTP项目。 开始的时候我根本就不能把哪怕一个testcase成功跑起来。于是我去问起开发者， 他告诉我需要把某一个特定的Reusable Action添加到"folders"里面。 这种坑是在是让人哭笑不得。

QTP作为一种工具， 或许需要提供这种灵活性。但我们除非有必要， 不要去用它。 如果必须要用， 也要很好的document这点。

不要用keyword view， 而是提供业务逻辑封装层

如果你要让你的testcase简单， 直接，那么你应该通过合理的抽象提供完善的业务逻辑封装层， 它会使得你的testcase script读起来像testcase descript一样。 这个时候， 你根本不需要keyword view。

不用Reporter.ReportEvent 而用Assert

当执行一个Testcase时候， 如果遇到错误， QTP支持两种操作。"stop run" 和"proceed to next step"。（注意， 其实还有另外两个选项。 "pop up message box"是针对开发时使用。 "proceed to next action iteration"不常用。 所以不讨论。）

 

基本上， QTP鼓励"proceed to next step"这种方式：如果出现了错误， 那么记录错误， 但testcase仍旧会执行下去。

对于QTP检查到的错误是这样， 对于测试脚本自己检查到的错误也是如此。 QTP提供了一个错误报告机制。

Reporter.ReportEvent micFail, stepName, errorMsg

这种处理方式违背了一个程序设计的基本原理：如果出现不能处理的错误， 那么就抛出错误。通常来说如果出现了错误， 执行下去是没有意义的。 我猜想QTP之所以会支持这种方式是因为， 如果出现错误马上退出， 那么testcase里的负责cleanup的代码就无法执行。 想想看JUnit里的Setup和Teardown机制， 在VBS里是无法实现的。

即使考虑到这点， 这样做还有一个问题，导致我不采用它的原因。 那就是不能在batch run的结果报告里显示错误。 如果采用"stop run"的方式， 那么batch run脚本能够获得导致testcase退出的错误信息。 然后在产生report的时候， 能够呈现出来。 再结合错误时刻的screenshot， 实践表明， 大多数错误都能在阅读report的时候确定原因。 下面是一个Report里一个失败Testcase的呈现情况。

如果使用Reporter.ReportEvent的方式， 那么在Report里你看不到任何错误消息，只能在Result View里面打开result xml。这是一个耗时的操作，因为Result View很慢。 大多数时候，你是在等待Result View把测试结果渲染出来。

为了更好的支持checkpoint， 我在framwork里定义了一套Assert函数， 可以对大多数情况下的断言语义提供直接的支持， 比如“相等”， “不等”， “包含”， “匹配”， 等。在Assert函数里面， 会抛出一个Error。 下面是一个从popup窗口读取信息， 然后验证信息是否正确的例子。

AssertMatch GUI_MsgBox_Msg("Information"),_

    ".*is invalid or you don't have the permission.", _

    "Error message not displayed or correct"

如果该Checkpoint失败， 那么在HTML report里看到的信息像下面的样子。

AssertMatch: Error message not displayed or correct. Expected<,".*is invalid or you don't have the permission.>, Actual<>

总结一下。在错误处理上，采用"stop run"的方式， 这也是所有程序设计里采用的方式。 在写checkpoint的时候，用Assert而不要用Reporter.ReportEvent, 因为前者会帮助你更快的分析错误。

Project目录架构

在安排QTP test Project的目录树的时候，需要考虑到下面的问题

·         如何组织Function Library, 如何引用function library文件?

·         如何组织Testcase, 如何在testcas间共享数据/代码?

·         如何配置静态参数, 运行时环境和全局测试数据?

如何组织Function Library？

按照前面的设计方法搭建的Function Library会包含大量的函数， 最终代码量也会比较庞大（基本上取决于业务逻辑封装函数的多少）。比如最大的一个项目， 其 Function Library总共代码量达到11000多行， 假设1/4是注释， 那么实际代码行数 大约是8000多行， 按照一个函数20行代码， 总共大约400多个函数。

为了维护这么多函数， 肯定要分成多个文件， 按照Module组织起来。 但是QTP对于外部文件引用支持很差。 基本上10个以上的外部文件引用就让人抓狂了。

所以我采用了一种折中的方法。 首先， 一个Module对应一个vbs文件， 这样代码维护最方便。 然后有一个脚本能把所有的Module文件合并为一个大的qfl文件， 方便QTP引用。

下面是一个真实项目的Library目录。

·         BIZ

业务逻辑封装函数文件所在目录。

·         FRM

VBS 运行时扩展库文件所在目录。因为VBS的运行时库实在是太简陋（当然， 这个也是情有可原， 毕竟是70年代的语言）， 所以必须要写一些基本的扩展例程。 比如断言机制， Log机制， 动态数组， 动态字符串， 文件处理， 时间格式化， 等等。 接口基本上参照JVM做可以了 ：）。

把这些基本功能作为VBS扩展库， 和项目的Function Library分开有助于你维护一个跨项目的VBS function Library， 更有效的利用代码。

所以， 我的项目里， 自testcase script向下有下面的层次

                +----------------------------------------+

                |                                        |

                |            TestCase Script             |

                |                                        |

                +---------------------------------------->

                |                                        |

                |    Function Library (BIZ, GUI, UTI)    |

                |                                        |

                +---------------------------------------->

                |                                        |

                |          VBS Extension Library          |

                |                                        |

                +----------------------------------------+

·         GUI

GUI封装库所在目录。除了前面介绍的GUI元素库用来定位一个GUI元素， 还有对常用的GUI元素操作封装的函数。 比如下面是一个对Java Tree的封装。

 

·         Screen

是所有Screen定义文件所在的目录。

·         UTI

其他功能函数所在的目录。

·         AllInOne_Lib.bat AllInOne_Lib.qfl

AllInOne_Lib.bat把所有上面目录里的vbs文件合并到AllInOne_Lib.qf里， 方便QTP引用。

·         INIT.qfl

初始化函数库里Module的函数所在文件。因为某些Module的初始化可能有依赖关系， 所以提供一个专门用来初始化函数库的地方。

·         Library.cfg

配置函数库里Module的配置文件. 这个文件内容必须满足VBS的语法.因为他也会合并到AllInOne_Lib.qfl里。在实践中我发现， 绝大多数Module其实都不需要外部配置， 因为毕竟这只是一个测试项目的Library，对灵活性的要求远没有开发产品的library那么高。

如何组织TestCase?

TestCase被组织在一个四层树状结构列. 如下所示.

       +-------------+

       | TestRepo    +-----> Test.qfl

       +-+-----------+

         |

         |     +---------------+

         +---->| TestModule    +-----> TestModule.qfl

               +--+------------+

                  |

                  |  +----------------+

                  +->| TestSuite      +------> TestSuite.qfl

                     +--+-------------+

                        |

                        |  +-----------------+

                        +->| TestCase        |

                           +-----------------+

 

最顶层是TestRepo(TestCase Repository Root)。下面是TestModule, 是针对产品的一个功能模块的所有testcase的集合。再下面是TestSuite，一般是针对一个特定的测试点的所有testcase的集合。最下面是TestCase。

对于Testcase组织来说， 有两个重要的问题，

1)      如何在TestCase之间共享数据和函数

对于第一个问题，每一个TestRepo， TestModule和TestSuite都有一个公共库文件。 这个文件会被它所包含的所有Testcase引用。 所以在这个文件里， 一般配置特定范围的， 公共数据和公用方法。 举个例子： 如果某一个Testsuite里的 部分/全部TestCase都依赖于一个特定的对象。 那么可以把这个对象的数据， 比如名字， 配置在TestSuite.qfl里。因为此TestSuite里所有TestCase都引用此文件， 所以数据得以共享。

对于任意一个Testcase， 它的Resource引用都像下面的样子。

·         Library\AllInOne_Lib.qfl

·         ..\..\..\Test.qfl

·         ..\..\TestModule.qfl

·         ..\TestSuite.qfl

·         Library\INIT.qfl

 

2)      如何实现Setup和Cleanup

对于这个问题， 通过增加两个特殊的TestCase， 00_Setup和99_Teardown来解决。一个TestSuite里如果有这两个TestCase， 那么00_Seup会被最先执行， 99_Teardown会被最后执行。 下面是一个实例。

 

如何配置运行时环境

对于一个QTP Test Project， 环境数据必须是可配置的，而不是绑定到代码里。

我使用了QTP风格的Environment配置文件， 方便在运行时被Load进来。 QTP的Environment配置文件是XML格式，位置在 Conf/Environment.xml, 示例 如下

<Environment>

   <Variable>

      <Name>ServerIP</Name>

      <Value>172.17.68.40</Value>

   </Variable>

</Environment>

 

在运行时， 通过Framwork加载此文件， 然后就可以用Environment.Value("ServerIP")的形式在代码里直接获取相应变量的值。

如何把测试数据和测试逻辑分离?

测试数据和测试逻辑分离是一句在自动化测试领域流程甚广的一句话。 但有时候它被过于强调, 成了QA对外宣传的口号， 于是它就成了政治人物. 比如对于QTP Project， 有一种做法是定义一个外部的，集中式的的Testdata文件(Excel文件)。但是因为各个TestCase对数据种类的要求是不一样的， 把所有这些数据强行统一在一张sheet里的结果就是导致大量的column。 我见过在Excel里面用到“T”这个column，也就是用20个Column，简直是维护的灾难。

基本上， 最适合”测试数据和逻辑分离”的是这样一个场景。 某一批testcase具有类似的逻辑， 于是把这个逻辑实现为代码， 而用testdata来表达其每一个testcase的不同点。但是事实是， 对于QTP Project， 这样的情况并不多。 特别有些testcase看上去好像测试逻辑差不多， 但是从实现上来看， 差别很大。 如果强行统一， 那么测试数据会比较复杂， 增加开发和维护的负担。

但是对于QTP Project, “测试数据和测试逻辑分开”其实也是被遵守的。那就是在编写一个具体的testcase的时候，

查看(662) 评论(0) 收藏 分享 管理

测试执行流程与Mngt Tools

一套测试套件设计出来之后， 它的价值在一遍一遍的执行中体现出来。如何能最大化的优化执行的流程， 是Mngt tools 的任务。 在我的项目中， Mngt Tools是由一些VBS脚本和BAT脚本构成。

下图是Mngt Tools所包含的脚本。用户直接调用的脚本都是BAT脚本， 实际实现在VBS脚本里。VBS脚本放在Script文件夹里面， 如下图所示。

测试项目的执行流程定义如下。

                         +-----------------+

                         |  Prepare Test   |

                         +-------+---------+

                                 |

                                 |

                         +-------v---------+

                         |  Execute Test   |

                         +-------+---------+

                                 |

                                 |

                         +-------v----------+

                         |  Generate Report |

                         +-------+----------+

                                 |

                                 |

                         +-------v----------+

                         |  Analyze Result  |

                         +------------------+

Prepare Test

在准备Test阶段， 最重要的是产生一份所有要执行的testcase的清单，在这里是TestCaseList.txt。显然， 可以通过扫描Test Case Repository目录来达成。 这是通过脚本 GenTestCaseList.bat来完成的。

另外， 被测试产品的版本号是一个非常重要的信息， 必须在product.version文件里指定。

Execute Test

通过调用Batchrun.bat，所有定义在TestCaseList.txt里的testcase都会被顺序执行。执行过程中的所有log会记录到Run.log文件里。

执行结果所有信息会在一个目录里保存， 如下图所示。

其中，Batchrun.bat会把每一个Testcase的执行结果和错误信息（如果有的话）保存在TestResult.txt。这个文件会在"Generate Report"阶段被转换成TestResult.html。

Execute Test Twice

因为GUI测试天然的不稳定性， 有时候， 你会希望执行两次，并且取两次运行合并后的结果作为最终结果。合并的算法是， 一个testcase，只要有一次通过， 就认为是通过的。 这钟方式能够有效的消除 不稳定性导致的testcase失败的机会。

对于这种方式， 执行过程是下面这样.

1.   Batch run all test cases in TestCaseList.txt)

2.   Restore test environment

3.   Batch run only failed test cass

4.   Merge test results

BatchRun_Rerun.bat能自动的完成上述的流程。测试结果目录是下面的样子。

注意这里有三个TestResult文件。 TestResult.txt, TestResult_Rerun.txt 和 TestResult_Merged.txt，分别是“第一次”，“第二次”，“合并后”的结果。

Generate Report

在所有testcase执行完之后， 调用GenReport.bat， 会为该次执行产生一个HTML report，如下所示。这个动作已经集成在BatchRun.bat和BatchRun_Rerun.bat脚本里面。 不过也可以在测试执行完成后的任何时候调用GenReport.bat。

 

这个Report由总到分， 逐级展示测试结果。最上面是整个testrun的结果， 下面是TestModule和TestSuite的结果， 最下面是每一个testcase的测试结果。

在查看每一条Testcase结果记录的地方， 你可以立即获得错误信息和当时的Screenshot， 他们都是对于结果分析非常有用的信息。 实践表明， 这种便利性可以大大加快结果分析的效率。 如果你需要在Result Viewer里面查看更详细的信息， 那么可以打开ResultXML，这个文件正是Result Viewer需要的文件。

Analyze Result

为了方便结果分析， 需要用到GenExcel.bat这个脚本。 它可以根据测试结果文件(TestResult.txt)文件, 产生一个TestResult.xls文件。 利用Excel的能力， 你可以方便的根据测试结果过滤所有testcase， 并且可以随时记录下分析结果。

如果需要汇报测试执行结果， 那么可以在邮件正文给出汇总的信息，并附上TestResult.html和TestResult.xls两个文件。 这样你的邮件基本上包含了各种stakeholder(team leader, manager, developer...)可能感兴趣的信息， 而且还不会显得凌乱。

总结2：适应变化和可测试性

适应变化而不是控制变化

相对于单元测试， 接口测试等自动化测试， 对基于GUI的测试面对一个很大的问题是GUI是容易改变的。

对于这种情况， QTP给出了SmartIdentification， 试图让工具更智能， 实践表明大多数时候它只是在帮倒忙。

有些公司出台了一些Policy， 限制Developer对GUI元素识别标识符（比如ID）的修改。比如我现在的公司就提出过修改GUI的一些policy， 结果是不了了之。因为很多Developer根本就记不住那些约束， 或者不愿意被约束。另外， 有些时候， 一些GUI元素是由工具生成的， 其ID变化不在Developer的控制之中。

所以， 在设计GUI元素库的时候， 如何应对GUI的变化是需要重点考虑的。 我的答案是， 不去试图控制变化， 而是提高自己适应变化的能力。这就是“所见即所得”识别方式背后的动因。相对于“对象库”方式， “所见即所得”不仅仅带来了快速定位GUI元素的能力， 它还让修改变得很简单。当GUI元素修改了， 如果你只需要花几分钟就能修改好的你的代码， 那么你也不会太在意这种修改。

可测试性与代码重用率

可测试性与代码重用率看似两个不相干的东西， 但我发现代码重用率高的软件相对有更好的可测试性。 简单来说高质量的软件相对具有更好的可测试性， 及时developer在开发的时候并没有专门去思考“可测试性”这回事。

有一本叫“重构”(refactory)的书说， “重复的代码”是代码臭味的一种。当代码具有臭味时， 你就需要去重构它。通过重构去掉“重复的代码”其实就是在提高代码的重用率。 代码的重用率一定程度上也能反映出代码的整体质量。 简单来说， 通过copy-paste构建的程序肯定比通过抽象构建的程序代码质量差， 因为它导致大量的重复代码。

为什么 代码重用率高的程序一定程度上也是可测试性高的程序？ GUI元素库对于元素定位的每一种基本方法（包括组合元素定位）是针对某一类型的GUI元素的抽象。一个程序， 如果它的GUI部分的代码重用率高，那么就有更多的GUI元素其定位标识是有规律的。 那么同样数量的定位方法就能覆盖更多的GUI元素。 一个程序如果是通过copy-paste建立起来的， 因为paste之后， 程序员是可以任意修改代码的， 这种修改可能破坏了原有的GUI元素定位规律。所以结果就是， 不得不写更多GUI元素定位基本方法（或者组合元素）来覆盖所有的情况。

所以， 我发现， 使用这个GUI元素库， 越是高质量的软件，其测试套件开发起来越轻松。

Different QTP系列文章入口

业务逻辑封装接口设计

 

为了达到“testcase script和testcase的描述有简单而直接的对应”这样一个目标， 需要对产品功能有一个全面而系统的封装， 然后提供一套API供testcase script调用。 显然， 这会导致大量的API单元产生出来。

QTP提供了resuable action作为业务逻辑封装的工具， 但是resuable action过于重型， 而且并没有提供与其重量级相对应的强大功能。  function相比于reusable action提供了同样的封装能力， 但体积只有1/10，而且使用方式更自然。  这也是不用reuable action的若干重要原因之一。

另外一个必须要考虑的问题就是如何降低这套API使用的难度。 这里有一些技巧。

命名规则

VBS没有Module的概念， 但显然数量众多业务逻辑封装函数必须组织在模块里。 所以我们在命名规则上来模块化。一个业务封装函数的命名如下

 BIZ_ModuleName_DoWhat(paramters)

首先BIZ前缀把它与framework里的其他函数分离出来。 ModuleName是第二个前缀， 指出了模块名。 第三个参数才描述了函数所封装的业务。

文档化

VBS没有专门的文档化定义（类似JavaDoc的东东）。当然你不能对它责怪太多， 毕竟这是上个世纪70年代的语言。 我使用Doxygen加上一个定制的filter来生成framwork里所有函数的文档。

比如下面这段的代码

' create account with given parameters.
'
' @param resourceType Hierarchy/Group/Device
' @param param1 the param to set value in page 1
' @param param2 the param to set value in page 2
'
' @see GUI_Field_HierarchySelect_Set
' @see GUI_Field_GroupSelect_Set
' @see GUI_Field_ProfileSelect_Set
Function
BIZ_Account_Create(accountName, roleName, resourceType, param1, param2)

 

通过Doxygen生成的文档像下面的样子

去除页面依赖

这里的“页面依赖“是一种函数前置条件。 它特指业务逻辑封装函数对进入此函数时的当前页面的要求。比如一个BIZ_User_Create函数， 它的前置条件可以是“当前页面在User Management页面”。 不满足前置条件时， 调用一个函数通常会导致object not found错误。

但是如果BIZ_User_Create函数针真的对前置条件如此要求， 那么成百上千的类似的业务封装函数会让Testcase script的设计者“步步惊心”。 为了消除这种不必要的心理负担。 我对业务逻辑封装函数的要求就是：只要有可能， 所有业务逻辑函数都要去除页面依赖。也就是说无论当前应用程序处于那一个页面， 函数都能正常工作。对于大部分应用程序来说，前置条件的要求其实是“用户已经登陆进入系统， 但可以处于任意页面”。

显然， 这会导致更多的执行时间。在函数内部， 首先做的就是导航（通过菜单或别的方式）到实际开始业务逻辑的页面。 但是相对于其带来的接口的简化， 和后续的维护简化。 这点成本简直就是微不足道。

这是一个很小的规则， 但它在提高API的可用性方面效果非常大。

业务逻辑封装原则

业务逻辑封装原则就是 严格分离测试逻辑和业务逻辑

这里的测试逻辑就是指Testcase里面的逻辑， 业务逻辑就是产品功能相关的逻辑。

这个原则看上去很简单明了， 但是实践时非常容易把二者混淆。

为了“严格分离测试逻辑和业务逻辑”， 我对开发人员的角色进行了划分， 分为“framwork开发人员”和“testcase script开发人员”。 framework开发人员在开发封装业务逻辑的API的时候， 心里要忘掉任何具体的某个testcase的测试逻辑， 而只关心如何能从产品业务逻辑的角度提供最合适的API。

其次， 我还对函数所在的位置进行了隔离。 所有业务逻辑封装的代码放在函数库目录里， 而与测试逻辑相关的一些共享函数放在TestCase repository目录里。

即便如此， 开发人员也会遇到“不能确定一个function是属于业务逻辑还是测试逻辑的问题”。 我举了两个个例子。

·         验证用户存在

验证用户存在是一个经常会用到的功能， 所以对于开发人员有极大的诱惑把它封装为一个函数， 放在framework里。 但实际上这是错误的， 因为“验证”这个动作本身就与业务逻辑无关， 而属于测试逻辑。

·         创建一组特定的 “角色，用户， 用户组”

在某件些testcase的前置条件里， 要求一组特定的“角色，用户，用户组”存在。 写一个函数封装这一系列操作是一个好主意， 但这个函数仍然属于测试逻辑。 因为对于产品来说， 并没有一组“角色，用户， 用户组”这个概念。

总结：关于framwork设计的一些思考

到这里， 我已经把这个framework里最重要的部分， 开发testcase的基石， Function Library介绍完了。

在设计这个Function Library的时候， 有两个最重要的抽象层， 一个是对产品业务逻辑的封装， 一个是对GUI元素访问的封装。 对于业务逻辑封装， 最重要的原则是”把业务逻辑和测试逻辑严格分离“， 另外就是不要使用QTP提供的Reusable Action。 对于GUI元素的封装， 我舍弃了QTP本身提供的对象库， 而完全用描述性编程的方式建立了一套”所见即所得“的GUI对象查询库。

为什么是这样子抽象？是两层抽象， 而不是一层（仅仅提供一些GUI元素操作的封装）， 或者三层（提供data-driven/keywork-driven类似的用户接口）？ 我的经验告诉我， QTP软件测试项目最大的挑战其实是可维护性。无论你是用record还是层层封装， 基本上你都能实现一个testcase。 但是真正的问题在于当testcase的总数上升到成百上千的数量级，代码库是否还能保持清晰？ Testcase是否能够适应今后产品的变化？维护人员是否能快速定位错误？当前的抽象模型是我认为对我目前项目最合适的。

我始终认为，好的framwork设计者应该尽可能取悦framwork的用户。 一个QTP test framwork的用户其实有三类，

·         业务逻辑封装函数的开发人员

·         testcase script开发人员

·         testsuite 维护人员

一个framwork的设计者，最好同时也从事上面提到的三种类型的开发 ，这样才能”叫好又叫座“

最后， 是没有最好的framework， 而只有最合适的framework。 如前言说讲， 这是一种“非 常规”的开发模式，特别是 舍弃了很多QTP提供的智能工具。QTP提供这些工具的目的是为了支持它的”keyword driven”这样一种开发模式。客观的说， 这是一种易用，快速的开发模式，但个人之见是仅仅适合小型，且短期的项目， 而且和普通的编程语言开发模式非常不一样（java/c#/c++）。基本上， 我是把QTP测试的开发模式， 转变成了普通语言开发的模式。

我曾经一位在HP工作过的同事告诉我， 在HP内部也是用QTP推荐的模式， 而且其项目也是不小。 所以我有时候怀疑这是不是因为我使用Java太长以至于形成了思维定势， 也许QTP本身的模式并不是那么脆弱， 低效。 但是无论怎么样， 我现在使用 的模式也有成功案例的支持， 所以我想可能这个也是一个因人而异的事情吧。 只是希望一些新的想法， 方法的出现能够激发更多人的灵感， 把QTP测试项目开发模式更加完善， 进一步提高QTP测试开发人员的生产效率。