本节书摘来自异步社区《精通QTP——自动化测试技术领航》一书中的第1章1.10节QTP的验证点与测试报告，作者余杰 , 赵旭斌，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.10 QTP的验证点与测试报告
精通QTP——自动化测试技术领航
阶段要点
了解验证点在自动化测试中的重要性。
Spy可以在做验证点时起到很好的作用。
QTP自带验证点函数CheckProperty。
自定义验证点。
自定义验证点-HTML模式。
1.10.1 自动化测试的有效性取决于验证点的质量
在自动化测试过程中，测试结果验证是最后一道关卡。前面所学的知识都只是使用QTP操控我们的业务。那么，在这些业务顺利按照轨迹行动以后，就该进行最后的“总结”了。“总结”什么？当然不是总结前面所学的知识点……这里的“总结”就是检查，最后一道关卡就是利用QTP去检查、去验证之前所做的操作的正确性和预期性（即自动化测试用例的预期结果部分）。
在本章节中，将会学到这最后一道关卡的技能，它分为和包括两项。
如何使用QTP做一系列的验证。
如何查看测试报告，从而判断自动化测试用例的预期结果正确与否。
1.10.2 侦探Jack再度登场
如图1-244所示。
问：“在做手工功能测试时是如何验证【百度搜索框】这个功能是否好用的？是否可以正确地输入各类测试数据（字符串）的？”
答：“在【百度搜索框】中输入测试数据【QTP自动化测试技术领航】，然后看其是否可以正常输入！”
没错，在手工测试中，所做的验证功能通常以观察去判别。那么，当我们无人值守自动化测试时，如何才能使计算机代替观察呢？如何相信QTP自动执行的结果是可靠的呢？在没有开始学习本章节之前，我们根本不敢说自动化测试是可靠的，即使在这个文本框中输入了字符串，又如何敢肯定地说：“所输入的测试数据一定成功键入了！”
该怎么办？如何让QTP代表我们的观察？谜底是—透彻地利用UI对象的属性值，一旦获得有效且具有威慑力的属性值，就完全有理由敢肯定自动化测试是可靠的测试。
验证点有很多，本章节以最大众的UI对象为例，其他诸如数据库验证等不会再此涉及！
“属性”，好熟悉的两个字！没错，在前面的章节学习中就早已把这两个字与QTP和自动化测试关联起来了。
怎么获得属性？万变不离其宗，我们要再度请出QTP风云榜冠军得主—Mr. Spy了（绰号：侦探Jack）!
相信学到这章节，大家早已经熟悉它了。那么，操作步骤就省略了，本人引导性地为读者抓取第一个关键属性，目的是为了让上面这个实例中的自动化测试成为一个可靠的行为，如图1-245所示。
如图1-245所示，在茫茫“属性”海中，通过不懈努力终于找到了一个关键属性‘value’。这个属性足以代替我们的观察来证明测试数据被成功输入到文本框了。为什么？在下一个小节介绍。
最后，在本小节末，建议读者还是好好研究一下图1-245，可以看到当前窗口是封装属性窗口。本人从来就没有说过，旁边的自身接口属性窗口中的属性没有可利用的关键属性，也从没说过除了‘value’就一定没有其他可利用的属性了。请读者集思广益，去尝试找到更多的属性，利用它们完成实例。任何属性都可能成为“关键先生”，Impossible is nothing！
**1.10.3 抛弃工具的使用，请使用QTP验证点函数
1.10.3.1 请抛弃QTP自带的验证点功能**
图1-246是QTP自带的检查点“功能”。它只是一项功能，尝试着随意打开一个功能点（Standard Checkpoint）看看，如图1-247所示。
如图1-247所示，好复杂的功能，包括图1-246中，为什么有的功能是可以选择的，而有的功能却是灰色的，不能点击的呢？什么原理？实在不想去研究这些，因为再研究下去，我们将永远摆脱不了QTP录制模式！当你翻开这本书的第一页起，我们就有一个共同的目标“编写QTP自动化测试脚本”！下面，一起开始编写第一个检查点、验证点代码！这才是我们要做的！
1.10.3.2 使用QTP“原装”验证点函数进行一切检查工作
首先，揭开之前未解的一个小谜底。为什么获得‘value’这个属性值可以帮助我们实现QTP代替观察。原理其实挺简单，并且也很好理解，说的通俗点，从观察的角度上讲，只要我们看到测试数据嵌入在文本框里那就说明输入成功了。那么从观察（QTP代码）的角度上来讲，虽然我们看不到，但可以通过获得文本框的value值来判断测试数据是否成功输入，如果获取到的这个value值等于“QTP自动化测试技术领航”，那就证明了测试数据输入成功了。那么知道了大致的原理后，我们就来看一下具体如何实现吧，如图1-248所示。
如图1-248所示，在第2行代码中，在最后一个子对象（也就是要验证的文本框对象）后面敲击“点”键，QTP会进行代码提示，会显示出很多QTP已经封装好的方法（关于这点，在本书之前的内容中就已经介绍过了），其中第二项就是目前要隆重推介的QTP“原装”的检查点、验证点方法-CheckProperty方法。如何使用呢？如下：
---语法部分---
object.CheckProperty (PropertyName, PropertyValue, [TimeOut])
作者翻译：对象.CheckProperty方法(参数“属性名”, 参数“属性值”, 非必填项“延时”)。
---详解部分--- 语法的前半段还是比较好理解的，这里主要介绍括号里的参数设置部分。
PropertyName：要检查的属性名，在本实例中是‘value’。
PropertyValue：预期结果值，在本实例中预期结果是“QTP自动化测试技术领航”，如果最后检查完毕，发现不符合预期，则会返回False，并引入QTP测试报告；反之，则返回True，并在测试报告中以Passed显示。
TimeOut：单位是milliseconds，可以不填，不填则代码瞬间验证结束，如果设置成5000的话，则会等待5秒钟。第1秒如果没验证对没关系，只要在5秒内验证对就算对。
---代码部分---
Browser("百度一下，你就知道").Page("百度一下，你就知道")._
WebEdit("wd").Set "QTP自动化测试技术领航"
Browser("百度一下，你就知道").Page("百度一下，你就知道")._
WebEdit("wd").CheckProperty "value","QTP自动化测试技术领航"
上面这段代码的预期结果是“QTP自动化测试技术领航”，即正常的预期结果，输入了什么就显示什么。看一下运行后的测试报告，如图1-249所示。
如图1-249所示，我们可以看到，自动化测试检查已经通过，那么假设现在预期结果不写成“QTP自动化测试技术领航”，看看QTP在自动化测试之后会不会检查出来，代码如下所示：
Browser("百度一下，你就知道").Page("百度一下，你就知道")._
WebEdit("wd").CheckProperty "value","QTP"
运行后的测试结果如图1-250所示。
这次可以看到QTP的测试报告Failed掉了，虽然是报错了，但是这也证明了自动化测试的成功，最后再让我们来看看报错的详细情况，如图1-251所示。
1.10.4 灵活地自定义验证点
上一节是伴随着一张截图结束的，似乎有一些草率。其实，这是有意这样写的，目的是为了引出本小节的内容。在上一节最后的图1-251中可以看到，这些详细介绍情况都是QTP自己生成的，它有自己的一套规则。那么，难道就一直要循规蹈矩地去使用这份默认的报告格式吗？显然不是！QTP提供了一个非常好的测试报告机制，这个机制将是今后最常使用的一个功能，这就是Reporter函数！
首先，Reporter函数是一个Completed Word，可以快速定位它，如图1-252所示。
在选中函数以后，单击一下“点”，就会出现3个属性和一个方法，如图1-253所示。
下面主要介绍的是ReportEvent方法，本小节的主题也是围绕这个方法展开的。选中这个方法，如图1-254
如图1-254所示，在选中了ReportEvent方法以后，QTP自动提示了4个参数，具体怎么用？还是请教一下我们的“兵法书”吧（一定要学会这个方法，作者也绝对不会将兵法书里的内容说成是作者自己原创，它是现成的），双击选中ReportEvent，然后点击F1键，如图1-255所示。
“兵法书”（QTP帮助文档）真的很给力！上半部分是语法介绍，下半部分是示例，已经很简明了。在这里的作用只是通过这个大致框架给广大读者做细分介绍。
首先，一起来看第一个参数EventStatus，在QTP中，一共可以使用4种不同的状态来标识报告的状态，它们分别是。
micPass：对应数字0。
micFail：对应数字1。
micDone：对应数字2。
micWarning：对应数字3。
对应数字的作用就是，既可以直接键入字符，也可以输入字符对应的数字。其实输入字符也很快捷，不用一个一个字母输入，只需很简单地在ReportEvent后输入一个空格，QTP就会自动给出这4个事件状态选项，如图1-256所示。
这里需要注意的地方是，ReportEvent后面必须跟一个“空格”，不能是其他任何字符或按键，不然会产生语法错误，这也是新手很容易犯的一个错误，而且不容易输入察觉。在选中一个事件状态以后（假设这里选中micDone），输入一个“逗号”，就可以开始设置ReportStepName了，可以根据需要输入任何字符，然后仍然是输入一个“逗号”，开始设置Details，具体内容都由自己决定。最后一个参数是ImageFilePath，这个参数不是必填项，作用是将截图填入到报告中，当然得把图片相应的路径填对。
这个函数意义大致讲解了一遍，接下来开始进入主题，为什么自定义验证点就比自带的CheckProperty灵活，作者大致总结了一下几点。
（1）CheckProperty使用到的ReportEvent只有两种，Pass和Fail，而后者可以使用4种。
（2）前者似乎永远只是在检查属性，后者可以检查各种各样的代码逻辑，从多角度去验证自动化测试，如For循环，条件判断，嵌套循环等，任意组合都能使用到Reporter函数。
（3）前者的StepName和Details由系统自己生成，显得生硬，后者可以自由键入自己想要的东西。
（4）前者没有将截图写在测试报告里的功能，而后者有。
下面写了一段很简单的代码来抛砖引玉，并在下一小节中一起看看各种报告事件的结果：
For i = 1 to 4
If i = 1 Then
Reporter.ReportEvent micPass,"Step 1","micPass = 0"
ElseIf i = 2 Then
Reporter.ReportEvent micFail,"Step 2","micFail = 1"
ElseIf i = 3 Then
Reporter.ReportEvent micDone,"Step 3","micDone = 2"
ElseIf i = 4 Then
Reporter.ReportEvent 3,"Step 4","3 = micWarning"
Else
End If
Next
1.10.5 走进QTP Report—Test Report正式登场
请结合上一小节末尾的代码理解图1-257和图1-258所示。
先来看第一张图1-257，我们可以看到，根据代码中的循环顺序，测试报告的状态依次分别是Passed、Failed、Done和Warning，并且请读者记住它们左侧对应的图标，这是有关Reporter函数和测试报告的第一个知识点。
然后再看看，当前的Test最终属于Failed状态，为什么？尽管在4个检查点中，有过Passed（通过）的测试点，但是在QTP中，只要整个测试过程中出现了一个测试点Failed（失败）了，那么它的本次Test迭代就算Failed，哪怕你Passed了99个，但是Failed了一个都不行，这是它们之间的第二个知识点。
再来看看第二张图1-258，可以看到当前有且只有一次迭代，最终结果Failed了。在下方部分则详细地分别显示了Passed、Failed、Warning的测试点次数，但是Done状态的不计算在内，这是第三个相关知识点。
同理，如果两个测试点中有一个Passed，而另一个Warning（警告），Test的最终报告会以Warning显示，先来看下面这个示例脚本：
For i = 1 to 2
If i = 1 Then
Reporter.ReportEvent micPass,"Step 1","micPass = 0"
ElseIf i = 2 Then
Reporter.ReportEvent micWarning,"Step 2","micWarning = 3"
Else
End If
Next
运行一下QTP，结果如图1-259中的Test Result。
在最后，再来看看如果两个测试点中有一个Passed，另一个Done的话，Test的最终报告会以Done显示吗？来看下面这段脚本：
For i = 1 to 2
If i = 1 Then
Reporter.ReportEvent micPass,"Step 1","micPass = 0"
ElseIf i = 2 Then
Reporter.ReportEvent micDone,"Step 2","micDone = 2"
Else
End If
Next
运行一下QTP，结果如图1-260中的TestResult。
如图1-260所示，可以清楚地看到micDone不会影响micPass。最后，对它们之间的优先级做总结，从优先级高到低排列：
关于QTP Report的一些功能点，读者可以亲自使用一番，有的功能点还是比较实用的，比如右键单击一些步骤，可以直接跳转到QTP的脚本中、和QC的交互操作等……更多亮点期待读者去挖掘、尝试、探索！
1.10.6 自定义验证点—HTML模式
这一小节是扩展知识，讲的是自定义过程校验，内容比较特别，正常情况通过前面小节的学习都已经知道了：自定义报告可以直接使用Report对象，或者直接使用验证点函数CheckProperty，然后让QTP去自动在Report里生成一条验证结果。以上的就不多说了，相信读者已经掌握。这里主要是讲一下怎么结合验证点在QTP Report中输出HTML格式的结果，看下面这个例子，如图1-261所示。
图1-261就是我们需要实现的最终结果，来看一下脚本的实现。
1．报告生成函数（过度函数）
注意：这里的GetTOProperty ("testObjName")是一个隐藏属性，可以获取QTP对象库里的对象的LogicName：
'######################### 报告生成 ###########################
private Function HReport(ExpectedValue,ActualValue,testStatus,nodename)
Set oEventDesc = CreateObject("Scripting.Dictionary")
'添加状态
oEventDesc("Status") = micFail
'添加是否过滤
oEventDesc("EnableFilter") = False
'添加节点名称
oEventDesc("NodeName") = nodename
'添加HTML结果
oEventDesc("StepHtmlInfo") = "<TABLE border='1'>" & _
"<TR><TD>Actual Value</TD><TD>"+ExpectedValue+"</TD></TR>" & _
"<TR><TD>Expected Value</TD><TD>"+ActualValue+"</TD></TR>" & _
"<TR><TD>Checkpoint Status</TD><TD style='background-color:red'><b>Failed</b> </TD></TR>" & _
"</TABLE>"
'判断状态
If testStatus Then
oEventDesc("Status") = micPass
oEventDesc("StepHtmlInfo") = Replace(oEventDesc("StepHtmlInfo"),_
"<TD style='background-color:red'><b>Failed</b></TD>","<TD style='background-color: green'><b>Passed</b></TD>")
End If
'生成报告
newEventContext = Reporter.LogEvent ("Replay",oEventDesc,Reporter.GetContext)
'释放资源
Set oEventDesc = nothing
End Function
2．验证函数-调用第一个报告生成函数自动判断成功与失败：
'########################### 自定义过程校验 ##########################
Function ValidateProperty (Object, PropertyName, ExpectedValue)
'判断预期是否与实际值相等
If Object.GetROProperty (PropertyName) = ExpectedValue Then
'成功
HReport ExpectedValue,Object.GetROProperty(PropertyName),true,_
"check "+Object.GetTOProperty("testObjName")+"<"+PropertyName+">属性"
ValidateProperty = True
Exit Function
Else
' 失败
HReport ExpectedValue,Object.GetROProperty(PropertyName),false,_
"check "+Object.GetTOProperty("testObjName")+"<"+PropertyName+">属性"
ValidateProperty = False
Exit Function
End If
End Function
这里的验证函数使用了测试对象的抽离技术。调用时可以直接把对象传入。把以上两个函数都存放在函数库中，然后直接调用验证函数（ValidateProperty）即可：
Set oWebEdit = Browser("百度一下，你就知道").Page("百度一下，你就知道")._
WebEdit("搜索框")
VaildateProperty oWebEdit,”name”,”wd”
ValidateProperty oWebEdit,"name","wd1"
结果1：wd验证成功，如图1-262所示。
结果2：wd1验证失败，如图1-263所示。
1.10.7 总结
验证点和测试报告作为自动化测试脚本的最后一关是非常关键的。验证点随着业务逻辑的复杂度而千变万化。验证点的质量直接反应自动化测试的可靠性；测试报告是一门技术活，测试报告写的好，能一目了然地反应程序或者代码本身的问题。在本章中，凡是关于这类的内容上，不过这些都将在第二大章中逐步展现。
同时，随着验证点和测试报告的学习完毕，也就意味着读者已经掌握了所有基本理论操作知识和实战技巧，接下来的积累已经不再是“学习”这个层面上了，应该是积累和扩展！
知识点巩固和举一反三练习
一、使用自身接口的方式验证“百度一下”这个按钮的界面是否符合需求。
二、学会将关键信息输入至Test Result中。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
