浅谈关于HP UFT中的GUI测试局限

关于HP 的UFT，简单做一下评价，总体来说是一款很好的软件，极容易上手和使用（这个也估计只是我没有往深入研究），测试流程和思路也很清晰，重点是和HP一些其他自动化工具，比如Loadrunner，QC可以结合起来用，堪称完美。拍完马屁说点实际的。

其实对于目前所在公司的项目，我一直很犹豫要不要引进HP的这款软件，首先我对于这款软件不是很熟悉，当然现在这个理由是可以排除的，对于这个软件的效果怎么样，我也不确定，之前公司没有使用这个软件，所以也没有什么积累，一切都要从零开始。明确知道这个软件可能在后期的回归测试会减少点人力，但是前期的的脚本录制，调试，以及维护，感觉也不是一个小工程。

学习使用HP UFT软件的过程不算很艰难，网上的资料还算是比较多的，加上采用录制的模式，只需点点点的就可以了，使用起来还是很轻松的，当然也会遇到一些问题，不过在网上查查资料基本上可以解决大部分。底层的脚本录制基本上解决的差不多了，开始关注整个测试流程框架，也就是在这个地方，突然间发现HPUFT的GUI测试不灵活，感觉有些死板。

简单说就是动作Action的执行顺序只能按你设定好的跑，由于之前本人是测试android产品的，有使用过Monkeyrunner相关的测试工具，对于这种按设定路线走的自动化测试工具有些不是很习惯。于是乎，突发奇思妙想，要是HPUFT的GUI测试也可以做到这种随机的测试就好了，当然了也不是像Monkeyrunner那样。

初步的想法是将各个Action进行封装，采用随机调用的方式执行测试，调用的次数可以是随机的也可以设定，这个整体架构的改变会对Action的录制有相应的要求，比如说执行完一个Action，它的出口和入口要一致，各个Action的要在同一级别，比如在同一页面。如此可能会出现多个层次，比如一个Action中又可以划分出多个Action，这个需要采用分层的思想进行解决，至于要分多少层，使用者可以按照自己的软件的特点进行划分。

说的好像又些复杂了，简单的说就是按照一定的要求录制Action，采用随机的方式执行Action。此方案可以检测出不同功能之间因调用顺序的不同而出现的BUG，实际测试也证明这种BUG是存在的，同时，这种模式也使得该软件的使用更为灵活。

暂且想法就这些，后续有再补上。