第一点优势自不必说，而第二点更是关键。试想WaitN和Selenium，都是通过编写代码在浏览器中打开页面。这意味着我们的在测试代码和被测试的网页分别在不同的进程中。在这个前提下，如果我们要将测试代码中定义的数据传递给被测试的网页（也就是视图对象），我们就必须进行跨进程的通信。而无论怎么实现，都逃不过“序列化”一途，这无疑增加了复杂度。而使用LTAF之后，这个问题瞬间烟消云散了，因为我们可以直接在内存中“传递”测试数据，一切都只是个引用而已。

  不过任何事物都具有两面性，LTAF也有一些难以天生的，而且是永远无法弥补的缺点。例如：

  由于LTAF将待测试的页面放置在Frame中，因此该页面上的window.top等基于浏览器frame结构的属性会被改变。

  由于LTAF的本质是使用JavaScript来操作DOM，这意味着任何会阻塞程序进行的操作（例如alert）都不能使用，否则将阻塞整个测试过程。

  幸运的是，这两点都不会成为严重的问题。对于第一种情况，我们只需要编写一个自定的getTop方法来替换直接访问windows.top的做法即可。而第二种情况——老赵从来不喜欢alert或confirm这种“纯浏览器功能”，因为它们会带来很差的用户体验，更何况现在的JavaScript类库/框架都能很轻松的做出这种效果，您觉得呢？

  比较

  虽然老赵推荐使用LTAF，不过究竟哪款测试框架最适合您的项目，还需要读者根据需要自己的需要做出判断。以下表格列出了他们的横向比较：