（原创）如何在性能测试中更有效的设置检查点

版权声明：本文为原创文章，转载请先联系并标明出处

在正式介绍检查点之前，我们先思考一个问题：在性能测试的过程中，如何才能算是脚本正确执行？

我们说，一个性能测试负载模型建立的再好，一个性能测试方案设计的再完美，如果在实际落地的时候，脚本实现或者执行却有问题，那么前面的一切也都是白搭。所以，问题来了，到底怎么样才能算是一个脚本正确的执行呢？

我认为这个正确应该分为两点：一是脚本正确；二是执行正确；

脚本正确很容易理解，就是你的脚本完全实现了你对应的用例，使用用户、操作步骤、输入数据都与你的用例一般无二；

而执行正确，我认为至少要分三点：

1、最基本的一点是脚本执行没有报错；

2、再者，即便测试脚本没有报错并不代表测试脚本是正确的按照预期输出，不仅是HyperPacer，对于任何一种测试工具来说，都是根据HTTP状态码来判断返回成功还是失败的。也就是说只要HTTP的状态码是200它就认为这个请求通过了，而我们系统在设计的时候为了用户体验，一般不会直接报错，而是设计相应的错误页面或者异常提示页面，这样在执行过程中，我们的操作或者数据出现异常了，然后返回有一个异常提示的页面。这时候，对于工具来说也是有响应返回，而且状态码为200，所以测试工具认为是正确的，但是对于我们的测试用例中预期输出来说，实际上这是失败了，所以这样也不算是执行正确；

3、最后一点就是脚本跑并发的时候是按照测试方案设计的模型运行的，即并发用户数、每个模拟用户使用的参数化数据、处理数据都是按照方案设计运行的。譬如，我们性能测试方案中设计的是要并发的每个用户都使用不同的用户名，录入不同的数据，如果我们运行的时候所有并发用户都是使用一个用户名，录入的数据也都一样，那么就跟我们方案预期的运行模式不一样，这样也不算是执行正确。

满足以上三点，我认为才是一个脚本正确的执行了。

基于以上的理解，我们再来看，第一点很容易验证，执行一下看有没有报错就可以了。第二点和第三点该如何保证和确认呢，这就说到我们这次要介绍的另一种技巧了——检查点。

检查点，顾名思义就是用来进行检查，一般是通过预期的文本内容或者大小等特征来与实际返回进行比对，与比对规则能匹配上，则检查通过，反之则不通过。

在HyperPacer中提供5种不同的检查类型，分别为：