编写性能测试脚本的三个有用技巧

本文跟大家分享一下编写脚本时比较常用也是比较有用的几个操作。

 

◆定义事物

 

事务(Transaction)是这样一个点,为了衡量某个action的性能,需要在action的开始和结束位置插入这样一个范围,这就定义了一个transaction。

LoadRunner 运行到该事务的开始点时,LoadRunner 就会开始计时,直到运行到该事务的结束点,计时结束。这个事务的运行时间在结果中会有反映。

在录制脚本的过程中,需要将关注的每个业务逻辑单位标记为事务并进行命名,这样可以在统计结果得到更多的分析数据并可以直接统计各个功能点对整体性能的影响。

 

◆添加校验

 

对于某些关键功能以及LoadRunner自动增加的校验不能够满足要求时,需要增加检查点,判断在指定点上是否由指定的数据或者元素返回。

同时当出现脚本修改完成后无法回放或者并发过程中出现业务操作没有按照实际情况执行,那么很有可能是LoadRunner忽略了运行阶段的错误,此时,也需要增加检查点来规避排查。

 

◆集合点

 

集合点是一个并发访问的点,集合点经常和事务结合起来使用,常放在事务的前面。

在正常的一般的性能测试过程中,不需要使用集合点,因为使用结合点得到的性能曲线将是成锯齿状,而不是相对平滑的波浪线,同时在实际的生产环境中同时并发的用户也不会是在同一个操作上的并发。

这个主要是因为集合点的排队机制,加载到集合点的用户并不会继续操作下去,而是等待后面用户完成,而后面完成的用户的并发数,就不是实际的并发数了,最后得到的结果也会产生一些偏差。理论上是会更好一点,但这不是我们需要的结果。

使用集合点只是对关键功能或者处理逻辑复杂、响应时间长的关键业务点以及需要严格并发来确定是否存在并发问题的等情况下进行使用。

接下来我们通过实际的脚本去看一下检查点和集合点的具体应用,下面这个图是一个已经录制编辑好的界面,它录制的操作是用户登录之后进入主页面,新增一个文档,再删除一个文档的操作。我们需要测试的操作只有新增和删除的操作,所以我们就把其他一些无关紧要的,包括登录、进入页面以及注销的操作放在init和end中,因为这些不是我们关心的一些功能操作。然后我们将新增和删除的操作尽量精准地录制到Action中。尽量精简是什么概念呢?在新增这个页面只是将“提交”这个操作放在Action中,而之前说的那些新增页面的操作放到了init里面,如果它没有关联的话。在进行了数据参数化及关联这些操作之后,保证这个脚本是可用的之后,我们可以通过添加事务集合点以及校验来进一步增强这个脚本。

首先我们用事务区分开新建文档和删除文档这两个操作,我们将这两个操作的最后一步点击分别设置成“新建文档”和“删除文档”的transaction,然后在所有的transaction前面都设置好集合点,这样就能保障所有的事务都能以预期的并发数进行性能测试

我们以下图这个脚本为例,有的人会认为新建文档在Action开始的时候就是在执行的事务,它一开始就是以并发的状态进行的操作,那么就不用添加集合点了,这种说法是不对的。不添加集合点的话,虽然第一次迭代的时候保证的是你预期的并发数,但是你后面的每一次迭代可能会由于用户的排队机制的问题导致并不是所有的用户都是同时在进行并发,有的是在等待。因此后面的操作就不一定是以这个并发数来操作了。所以针对我们需要关注的所有的事务前面都是需要加一个检查点的,不管它是在脚本里的什么位置。

 

image.png


下面的图是后半段,针对删除操作我们同样也定义了它的事务,在事务的前面我们加上了集合点,去保障它的并发数。最后在里面添加了一个针对删除的返回信息的校验,去看一个文档被成功删除后的提示信息,校验它删除是否成功。如果有这个提示信息就代表它成功了,如果没有这个信息就代表它失败了。在进行了这些操作之后,我们就将原本操作中我们需要验证的内容以事务的形式标识出来,然后再加入集合点和校验来保证并发以及操作的正确性。

 

image.png


这样就可以有效针对相应的测试需求去编辑并增强脚本了,这个脚本也是可用的。