摘 要：本文主要写了
QTP检查点在QTP实际应用中问题与解决方法。
关键词：检查点 扼杀，比喻压制发展中的事物。
首先，简单说下，什么是检查点。因为检查点在
测试领域中涉及面较广，所以我们这里主要针对QTP的检查点做个概念性的介绍，它是QTP在运行过程中，对被测试对象的属性、输入、输出值做的一个检查，如果发现预期结果与实际结果不同，便会以报告的方式显示出来给用户或者返回值。 其次，知己知彼，方能百战不殆。让我们了解下，QTP检查点的基本
工作原理，QTP把某个对象添加到一个“库”中，并记录了它的属性，值等，在运行的时候，把用户指定的属性，值与运行过程中(类似getroproperty)的属性与值进行比较。直到V9.5出台，检查点管理才上升到界面上，并归并于对象库中。至此，检查点的原理在9.5的粉饰下更让人容易接受和入门。 再次，为什么要添加检查点?因为使用QTP，无论是回归测试，或者
其它方面的测试，我们需要一个检查点，一个触发点来达到捕获BUG或者触发事件的目的。因此，渐渐的很多刚用QTP的人便把检查点看成一个能够解决自动化瓶颈的一个出路。所以在一个简单的脚本中，检查点是一个接一个的插进去，琳琅满目。 最后，关于检查点的用法，可以在网上搜索下关于这方面的资料，它包括了表、对象、
数据库、位图、文本、页面、输入输出值等等。 在这里介绍个简单的Link检查点的玩转方法，自然不是挑战XEnu之类的工具，在这里之所以介绍这个方法，是想让更多的读者学会思考，教材是死的，人才是活的。
1) 设置一个URL让它去跑，我们选择了Google，然后随便做个操作，例如做个set操作。没办法，添加检查点就是要这么麻烦。
2) 第1步其实是让谷歌首页的页面截图有出现到我们的Screen中。好了，点击停止。然后在Screen上邮件添加"Images"为标准检查点。
3) 我们只选择了html tag和URL(不要outerhtml之类的)，让html tag为a(连接其实有很多中节点方式，需要根据实际去做参数化)，URL用正则表达式参数化成"http://(.*)"。
4) 然后到对象库中，把刚才的Link("Images")的text做个参数化，例如添加个环境变量Environment “Images_text”。
5) 关于这个对象库中的，我们不要添加太多的属性进去，特别是URL不要加进去，我们就是要通过URL来做检查的(为什么不把对象库中的URL同样也做这种表达的参数化?这点留给细心的读者去思考)
6) 运行下面代码：
7) 第5行就是我们自己添加的检查点，区别8.2和9.5，前者使用的复制黏贴Screen不会跟踪，直到9.X才改善了这个问题。
8) 大家很高兴的在Report中看到了若干个检查点的成功报告，而报告的内容就是HTML与URL的检查。至于它的实用性，抛砖引玉。
好了，检查点我们也大概知道个二三，现在我们来说说，这么好的一个检查点，为什么要扼杀它，或者说是对许多QTP用户一个新触发点。
1) 在比较稳定的版本QTP8.2中，检查点的添加，保存都是以这一个文件的形式，并未体出一个可维护性高的特点。
Browser("Google").Page("Google").Link("Images").Check CheckPoint("Images")
-1 Dim LinkObj
-2 Set LinkObj=browser("Google").Page("Google").Object.links
-3 For i=0 to LinkObj.length-1
-4 Environment.Value("Images_text")=LinkObj(i).outertext
-5 Browser("Google").Page("Google").Link("Images").Check CheckPoint("Images") -6 Next
2) 对象变更，检查点毛病会体现出来，需要重新添加一次检查点或者像在9.5中需要修改属性，因为它的原理基于对象库。
3) 项目保存或者移植(被测项目修改)，screen丢失或者错乱，会让检查点添加是个让人头痛的问题，因为你需要整理screen或者重新添加，更甚是在8.2中不支持检查点图片跟踪，导致了复制同样的检查点，没办法做到维护。
4) 某些检查点的添加是基于screen，当screen出现了第3点中的情况后，项目的维护成为QTP脚本管理员的一个隐痛，自然，琳琅满目的检查点更是让情况发生恶化。
5) 检查点的原理基于对象库，因此，对象库中的毛病也会体现出现，维护，移植，管理...
6) 框架的可拓展性，因为检查点的特点，导致了它的添加必须基于录制，过渡依赖于Action的使用。会让检查点的添加不能在单独的Function中使用而。
7) 功能局限性，检查点虽然提供了哪么多类型的检查点，但实际上它能做到的或者是读者想要的，远远不只这些东西。
那么，不用检查点，我们有更好的方法去解决吗?我们用检查点干什么?就是为了发现包括回归过程，测试过程中找到与预期结果不同的页面元素。考虑到重用性、可维护性、框架拓展性，我们采用了Function的编写。这并不是舍简求繁，路需要走得更远，这是一个积累的过程。在这里简单举1，2个例子。
'WebEdit_CheckPoint 输入框检查点函数，输入参数为预期值
' '参数 'WebEdit_Obj 输入框对象
'CanVisible 可见
'CanEdit 可编辑
'MaxLength 最大长度
******************************************
Public function WebEdit_CheckPoint(WebEdit_Obj,CanVisible,CanEdit,MaxLength) If WebEdit_Obj.getroproperty("visible")<>CanVisible then Reporter.ReportEvent micWarning, "WebEdit visible is not expect "&CanVisible, "WebEdit visible is not expect "&CanVisible end if If WebEdit_Obj.getroproperty("readonly")=CanEdit then Reporter.ReportEvent micWarning, "WebEdit CanEdit is not expect "&CanEdit, "WebEdit CanEdit is not expect "&CanEdit end if If WebEdit_Obj.getroproperty("max length")<>MaxLength then Reporter.ReportEvent micWarning, "WebEdit MaxLength is not expect "&MaxLength, "WebEdit visible is not expect "&MaxLength end if End Function WebEdit_CheckPoint browser("Google").Page("Google").WebEdit("q"),false,false,100
******************************************
'IMG_CheckPoint 输入框检查点函数，输入参数为预期值 '参数 'IMG_Obj 输入框对象 'CanVisible 可见 'Filename 文件路径 'URL 超连接地址 'LoadOver 加载完毕
以上2个方法，都是可以根据实际情况再做修改和完善的。 自然，这些都是检查点可以做到的，我们也做到了，但是，什么是检查点做不到的呢?因为它的名字叫“检查点”，是点就自然有它覆盖不到的地方!大家在做网页测试的时候，是否发现有些地方会出现类似Http 错误之类的提示，或者页面出现某些错误但QTP却无动于衷?更甚至是出现在Frame内部，让人难以捉摸。所以到了项目提交，感觉可以了，但给用户使用时候，却发现某个页面里面，页面出现了某些页面报错或者加载出错，从而动摇了自动化回归的价值，在下一篇中将介绍如何把点扩张到线乃至面。
