版权声明：本文为原创文章，转载请先联系并标明出处
在正式介绍检查点之前，我们先思考一个问题：在性能测试的过程中，如何才能算是脚本正确执行？
我们说，一个性能测试负载模型建立的再好，一个性能测试方案设计的再完美，如果在实际落地的时候，脚本实现或者执行却有问题，那么前面的一切也都是白搭。所以，问题来了，到底怎么样才能算是一个脚本正确的执行呢？
我认为这个正确应该分为两点：一是脚本正确；二是执行正确；
脚本正确很容易理解，就是你的脚本完全实现了你对应的用例，使用用户、操作步骤、输入数据都与你的用例一般无二；
而执行正确，我认为至少要分三点：
1、最基本的一点是脚本执行没有报错；
2、再者，即便测试脚本没有报错并不代表测试脚本是正确的按照预期输出，不仅是HyperPacer，对于任何一种测试工具来说，都是根据HTTP状态码来判断返回成功还是失败的。也就是说只要HTTP的状态码是200它就认为这个请求通过了，而我们系统在设计的时候为了用户体验，一般不会直接报错，而是设计相应的错误页面或者异常提示页面，这样在执行过程中，我们的操作或者数据出现异常了，然后返回有一个异常提示的页面。这时候，对于工具来说也是有响应返回，而且状态码为200，所以测试工具认为是正确的，但是对于我们的测试用例中预期输出来说，实际上这是失败了，所以这样也不算是执行正确；
3、最后一点就是脚本跑并发的时候是按照测试方案设计的模型运行的，即并发用户数、每个模拟用户使用的参数化数据、处理数据都是按照方案设计运行的。譬如，我们性能测试方案中设计的是要并发的每个用户都使用不同的用户名，录入不同的数据，如果我们运行的时候所有并发用户都是使用一个用户名，录入的数据也都一样，那么就跟我们方案预期的运行模式不一样，这样也不算是执行正确。
满足以上三点，我认为才是一个脚本正确的执行了。
基于以上的理解，我们再来看，第一点很容易验证，执行一下看有没有报错就可以了。第二点和第三点该如何保证和确认呢，这就说到我们这次要介绍的另一种技巧了——检查点。
检查点，顾名思义就是用来进行检查，一般是通过预期的文本内容或者大小等特征来与实际返回进行比对，与比对规则能匹配上，则检查通过，反之则不通过。
在HyperPacer中提供5种不同的检查类型，分别为：
- Response：响应内容检查
- Duration：响应时间检查
- Size：响应文件大小检查
- Variables：响应内容中变量检查
- Function：自定义功能检查
下面我们来逐个说明。
1、RESPONSE：响应内容检查
响应内容检查一般应用在响应的结果验证，即我们上文中所提到的第二点，响应需要是成功的。
取值范围：设置进行检查点校验的取样器范围
- 父节点：检查点仅应用于父节点
- 兄弟节点：检查点应用于所有平行节点
- 所有节点：检查点应用于所有节点
检查范围：此选项可以设定测试的响应域。
- TextResponse：来自服务器的响应文本，即主体，不包括任何HTTP头
- Document(text)：从不同类型的文档中提取的文本
- URLSampled
- ResponseCode：例如200
- ResponseMessage：例如OK
- ResponseHeaders：包括设置的Cookie头(如果有的话)
忽略响应状态：将响应的初始状态设置为成功。
HTTP响应状态在4xx和5xx范围内，通常被认定为失败。"忽略响应状态"设置为true，可以在进行进一步检查之前将响应状态强制设置为成功。请注意，这种设置将会导致清除之前任何失败的检查点，所以请确保这只是设置在第一个检查点上。
匹配规则：设定使用哪种模式测试文本。
- 包含：文本中包含正则表达式
- 完全匹配：整个文本能够完全匹配正则表达式
- 相等：整个文本等于匹配字符串（区分大小写）
- 包含子字符串：文本中包含匹配字符串（区分大小写）
- 不包含：文本中不包含正则表达式
- 不完全匹配：文本不能够完全匹配正则表达式
- 不相等：文本不等于匹配字符串（区分大小写）
- 不包含子字符串：文本中不包含匹配字符串（区分大小写）
注意！相等和子字符串模式使用的是纯字符串，不是正则表达式。
匹配项列表：被测试的匹配项列表。
分别测试每个匹配项。如果一个匹配项失败，那么不会继续检查下面的匹配项。添加一个设置多种匹配项的检查点和添加多个只设置一种匹配项的检查点，效果是一样的（假设其他的选项是一样的）。
2、DURATION：响应时间检查
持续时间（ms）： 检查的持续时间，如果为0，那么此检查点将被忽略。
3、SIZE：响应文件大小检查
取值范围： 进行取值判断的范围，包括Full、Head、Body、Code、Message。
比较规则：检查时使用的运算规则。包括：相等、不相等、大于、小于、大于等于、小于等于。
比较大小：要检查的字节数。需配合比较规则使用。
4、VARIABLES：响应内容中变量检查
名称： 要检查的变量名称
类型： 选择要检查的变量类型：数值、字符串、对象。
匹配规则： 根据选择的类型，选择执行的匹配规则。
值： 输入要对变量进行检查的值。
5、FUNCTION：自定义功能检查
函数： 在其他检查类型均不满足时，可通过自动义编写的函数进行检查。编写的语法可参考HyperPacer帮助手册中的计算表达式语法手册，如果有疑问，可以QQ用户服务群（237936872）咨询。
介绍完了原理，我们以“用户登录业务系统”为例来说明一下检查点在实际的性能测试工作中是怎么使用的。
首先，我们需要创建一个检查点，在HyperPacer中，支持对测试场景、事务、具体的请求等设置检查点。此例中，我们要验证用户登录成功，所以将检查点创建在用户登录的取样器下，命名为Check：
我们要验证登录是成功的而非登录异常，即需要检查响应代码为200或者响应消息为OK，则Check检查点选择Response响应内容检查，检查范围选择Response Code，匹配规则为完全等于，设置完成后保存检查点设置：
检查点设置成功后，需要调试运行，校验检查点是否设置正确：
在快照浏览器中选择登录取样器，查看“检查结果”页签，Check检查点没有出现异常，状态为ture，表明该检查点被执行通过。
当检查点执行失败时，快照浏览器中该取样器快照标红显示，且检查结果页签，状态为false，并给出错误的详细信息，如下图：
以上这个检查点设置，很好的解决了“脚本执行通过但数据执行失败”的问题。那么，为了保证我们的脚本完全正确，是不是可以在每个请求下面都添加这样一个检查点呢？可以。但是我们强烈建议您不要这么做。因为每个检查点的对比校验都是一次性能损耗，尽管这种损耗非常小，但是量变引起质变，做的太多的话，脚本本身的性能损耗可能导致性能测试结果的严重失真。所以，只要在每个事务中选择最关键的一个请求进行检查就可以了。
参考文章： LoadRunner技巧之检查点
原文出处