LR 第一节

性能测试流程

注意点：

性能测试用例设计，特别关注数据容量的问题

性能测试环境搭建，与被测试环境区分开

执行：跑脚本、记录数据

数据记录：cpu   io   内存   网络

调优：一般由开发人员进行

调优有成本，适当即可

写好报告，才能让老板看到劳动成果，怎么写好看，写清晰

LR在性能测试流程中的位置

LR在性能测试过程中能帮我们完成的东西如上图所示，只是性能测试的一个“前端”工具

脚本开发很重要，决定性能测试结果的正确与否

LR能帮我们做什么

1、 让我们开发脚本简单化

我们可以不用管系统真正在传输的东西是什么，不需要理解系统的实现机制是什么，只需要简单了解相关的协议，就能开发脚本了

性能测试是基于协议的。只需要知道使用的协议，使用协议相关的函数，就可以开发脚本了

2、 让我们更好的模拟用户行为

不管是脚本开发中的参数化、自定义逻辑，还是场景中的用户行为控制，利用好这些东西，我们就能够轻松的模拟用户行为，最大程度上让系统的压力符合现实运行情况

可以模拟多个用户（参数化），模拟用户并发（集合点）

3、 能够方便的采集事务响应时间

LR的分析结果中，最有用的监控数据就是事务的响应时间，在合理设置事务的前提下，我们能够很方便的知道每个事务花费的时间，为我们的调优提供了大的方向

可以自己定义事务 通过start-end采集时间

4、其他一些常用的指标

如虚拟用户运行情况，TPS大小、波动情况，错误分布等

LR不能帮我们做什么

1、 监控

虽然lr的场景中自带了很多的计数器，linux的，数据库的，中间件的。对性能测试工程师来说，选择什么计数器，都是很为难的事情。因为不知道这些计数器是什么意思。所以大部分情况下，我们看到一些人的推荐就是选择默认的那些（help里有一些说明），如果我们遇到的问题正好在我们选择的那几个计数器里有体现，还真是太幸运了。而且作为压力机而言，模拟用户行为时，就会产生大量的负载，这时候再去处理服务器传回来的监控数据，会对测试结果造成一定的影响。

lr能监控到的，是程序呈现给用户的，已经处理过的错误信息，与实际程序中报出来错误不一定好对应。而且计数器需要提前设定好，也许不一定能采集到分析过程中，真正需要的数据

建议：采用第三方工具来处理。现在很多的第三方监控工具都做得小而精，对服务器产生的压力可以忽略不计。如nmon，spotlight系列，jprofiler、jconsole、AWR报告等。

2、 分析

通常情况下，lr中能够体现出来的问题，已经是经过了系统中一系列的处理之后抛到lr上的，所以我们再讨论lr的某个错误代号和打印出来的一串串红色字符串已经没有实质的意义了，还需要进一步去分析应用的整个通信过程，才能找到最终问题本质。

我们可以发现某个事务慢了，但是你无法定位出来是为什么慢，在哪一层慢了，是中间件的问题，系统的问题，还是数据库处理的时间长了？

对于web界面而言，我们能从lr上知道哪个页面响应慢了，在哪个环节响应慢了，但是我们也无法得知它为什么慢了

系统组成：前段--中间件--系统--数据库

建议：在性能测试执行过程中，我们需要有意识的利用第三方工具去监控一些数据，如线程数的运行情况，服务器资源的消耗情况，jvm内存的使用情况等，以便于我们后期的分析

3、 调优

这块内容不是任何工具可以帮到我们的，都是具体情况具体分析。同一个现象，可能会有N多种不同的情况引起，需要我们日积月累的经验以及对系统的敏感程度来解决。很多时候这块并不是测试能参与的

建议：对于目前来说，调优还是块很难啃的内容，它需要很广的知识面以及一定的经验。我们所需要做的，是帮助有能力的人去尽可能正确的定位问题。如果不能做到定位到某个代码片段，至少要告诉人家是哪个层面的问题