原来，无论是 SuperODCControl 的父类 ParentCompsite，还是其父类的父类 Grandcomposite，在文档打开之前，都是不存在的。只有打开文档的操作开始后，软件才会一步步创建 compsite 类的实例，最终再创建 SuperODCControl 对象。
那我们要在 objDialog.Open.click() 之前获取 compsite 的 TestObject，自然是得不到的。那 Grandcomposite 的父类呢？它是否 click 之前就已经存在了，我们可以获取它的引用吗？如果不是的话，它的上一层父类是吗？
我们可以在 ObjectMap 中可以看到，软件中有着一系列的容器包容结构，怎样才能找到哪一个 Composite 是文档没有打开时就已经存在的通用容器窗口呢？一层层的去尝试的话显然是不太可行的，我们这里介绍一个小小的技巧：
利用 RFT 抓取 TestObject 的不同方法，我们可以巧妙的知道到底哪一个 Composite 是真正的当文档没有打开时，就存在的窗口父类。
首先，我们只运行文档管理软件，但是不打开任何文档，这时使用 RFT 的手型对象抓取工具，选择文档管理软件的当前空白窗口：
图 7 抓取的当前空白窗口
选择之后，我们并不是直接选择工具界面下方的 Next，而是选择下拉列表中的 TestObject Brower 方式。
图 8 TestObject Brower
这时，我们可以看到，我们选择的窗口对象的在整个软件中的树形结构。
图 9 窗口对象浏览
我们只需要记住这个结构即可，然后再将 Select Method 的下拉列表选择成 Drag Hand Select。
接下来，使用我们的文档管理软件打开一个文档，再使用手型工具选择我们打开文档的窗口：
图 10 抓取的文档窗口
选择之后，我们同样的再次选择下拉列表中的 TestObject Brower 方式：
图 11 文档窗口对象浏览
得到 SuperODCContrl 对象的树形结构，这时我们再比较一下，打开文档前后两个树形结构的差别，从而找到统一的 Composite 父类。这样，我们可以在 ObjectMap 中添加这个父类的父类 SSashForm，然后在代码中通过 find 方法找到这个统一 Composite 父类的直接引用，之后就可以用这个直接引用的 find 方法来找到 SuperODCControl 对象了。
CommParentComposite = SSashForm.find(atChild("class","org.eclipse.swt.widgets.Composite")); SuperODCControl = CommParentComposite[0] .find(atDescendant ("class","com.ibm.productivity.tools.core.SuperODCControl") ); |
需要注意的是，由于 SuperODCControl 不是 CommParentComposite 的直接子类对象，因此在使用 find 方法是，参数是 atDescentdant 而不是 atChild。
我们可以测试一下这种方式的效率，得到的结果是只花费了几十个毫秒。
在使用上面的方法后，我们最后测试得到的软件打开文档 Load Show 的时间平均是 901 毫秒，这与我们 Manual 测试的结果是非常类似的。
而对于 LoadFinish 来说，我们则需要判断软件状态栏下方的 TotolPage 状态栏对象是否存在，并且其 Text 内容变化为文档的总页数时，才表示文档全部 load 结束了。这种判断方式与我们之前的保存结束判断方式是一致的，我们可以采取类似的方法来进行测试。而最终的测试结果为 3635 毫秒，与我们的 Manual 测试结果也非常的接近。
总结：
通过上述的介绍。我们大概的了解了使用 RFT 对普通应用软件进行操作响应速度自动测试的基本情况。如何准确的确定应用软件操作的起始和终止的时间，并进行准确适时的判断和测试，以及在编写 RFT 脚本时可能会遇到的一些问题和一些小的技巧等等。但是，在使用 RFT 进行软件性能测试时，还存在着种种的问题，比如说如何进一步减小 RFT 程序的判断时间，减小 RFT 运行本身给软件性能带来的干扰，采用更科学合理的算法对测试结果进行分析而不是简单的算术平均等等。这些问题，我们会在后续的内容中继续讨论。
