BPT(business process testing) 研究（一）

    Mercury从测试工具系列8.2就提供了BPT的测试思想和实现流程，只是我们测试人员还没有深入地对这种新型的测试思想进行过深入的探讨（当然，海龙老师和文广老师已经是先行者了）。

    由于项目需要使用BPT进行自动化测试，测试框架和底层Component建模任务就落到了我和另一个同事身上，开始对BPT进行现学现卖了。

    BPT不能算是一种新型测试方式，它只是一种新的测试思想，它将整个测试参与角色定位为两类人：

    一类是测试工程师，另一类是业务工程师。

    业务工程师不用熟悉脚本，不用去理解Component的构建（当然他也可以参与构建），他们的主要职责是使用已经建模好的所有Component，也就是被测对象的操作步骤零件，进行实际业务流程处理的案例拼接，设计完成充分，有效的案例集。

    就拿附带小程序flight来说，原本我们的登陆步骤起码需要四步骤：

    1.打开程序，出现login窗口

    2.输入用户名

    3.输入密码

    4.点击确认

    而在BPT中，我们可以把整个登陆打包成一个Component，它只需要测试案例设计人员拼接案例时拖拽进案例步骤，而后在实际运行时给予两个输入就可以执行（注意，这里注重的是重用性，也就是说，该登陆Component在今后所有的BPT案例里都可以选择复用，而不用重新录制或者写脚本）。

    BPT的执行一般正确流程是由QC远程调用QTP来运行，参数的输入在QC段点击Component上的输入参数列表就可以实时输入了。

    刚接触时，总想使用business component，但实际上对我们测试工程师来说，该对象的定制性实在太差，它只适用于很简单的对象操作，对于逻辑控制，判断等操作显得力不从心，从我的角度来看，它的存在只是为了业务工程师的Component自行设计。

    我们关注的应该是scrīpted Component，这才是可以充分发挥我们脚本定制的利器，实行的角度和粒度不同，但最后封装完毕呈现给案例设计者的其实都是同样的接口，所以我这边基本上忽略了business component，今后的研究偏重于scrīpted Component，当然，其实只要你后者熟练掌握了，前者也就无师自通了。