进公司以来，对于LoadRunner的使用以及对性能测试的理解和认识，一直都是一知半解，仅仅停留在基本脚本的编写和优化上，对于脚本对服务端的压力和性能的测试，总是模模糊糊，没有系统的认识。经过几次跟同事的讨论，碰撞，产生了一些思路，今夜凉风习习，骑着车，脑海里任由思路上蹿下跳，慢慢地变得规律起来，到家之后，略作整理，形成了一套重构方案，将之前的一些牛角尖问题解了开来。后续会慢慢同步学习和实践的经验教训和心得。
1、独立单个接口的脚本结构，尽量避免接口之间的互相依赖，因为我们做【性能测试】的目的是测试服务端的性能，而不是逻辑或流程，那个属于【接口测试】或【功能测试】的范畴；
2、剥离登录、登出接口，放入init和end里；
3、每个原本就相对独立的接口，按场景封装到一个USR文件或Action里，便于分析不同接口对应的服务端和DB的处理性能；
4、测试数据的准备：现网数据或者创建数据；
a. 例如Phone数据，要根据实际估算量来选定数据源，不能无限制的使用，没有意义；
b. 商户数据，老用户，新用户，不同状态的订单数据，
5、原本互相依赖的接口，尽可能地剥离开来，针对该接口所处理的业务，设计业务数据的准备脚本：
以订单接口为例：
a. 建立LR Test的服务类型，在手工测试和性能测试的数据库没有分离开之前避免影响手工测试；
b. 取一组号码创建该服务类型的店铺；--数据库查询当前50VUser，生成店铺的效率；
c. 取同一组号码发送对应服务项目的订单；--数据库查询当前50VUser，生成订单的效率，包括用户订单和商户订单；
d. 同一组号码的店铺执行抢单；
e. 依次进行，放在不同的USR文件里，分组执行，比如b/c可以顺序执行，d可以隔天执行；
6、将不同场景的脚本分发到不同的负载终端上执行，模拟接近真实的线上场景；
阶段I：
负载测试：对系统不断加压，直到饱和不能再压了，目的是为了找到系统最大的负载能力，为性能调优提供数据。
压力测试：指将系统压到一定的饱和程度，此时系统处理业务的能力，系统是否会出现错误。
阶段II：
配置测试：通过调整系统软硬件环境，将系统调优到最佳配置。
并发测试：通过模拟用户并发访问某个模块或接口，观察系统是否会出现死锁、处理速度是否明显下降等性能问题。
阶段III：
基准测试：在一定的软件、硬件和网络环境下，模拟一定数据量的VU运行一种或多种业务，将测试数据作为基线数据，在系统调优或评测过程中，通过运行相同的业务场景来比较调优效果。
可靠性测试：当系统在一定的业务压力下，持续运行一段时间，观察系统是否达到要求的稳定性，比如无故障运行多少天。
【原计划细节】
1、基于梳理好的接口做用户场景分析，甄别出需要做接口测试的和性能测试的接口；
2、采用当前的运行场景，执行10次脚本，执行过程中可以在40
3、分析baseline数据，从多维度检查存在性能问题的地方，并提交给开发做优化方案；
4、同步基于产品运营提供的期望并发用户数+不同场景，换算成期望的性能targetline；
5、根据产线服务器配置和本地服务器配置的对比，粗略换算出当前的baseline和targetline的差距；
6、评估不同优化方案的可行性；
7、代码调优或配置调优；
8、脚本验证，并更新baseline；
9、重复6、7、8；
吞吐量=（虚拟用户数*在测试时间内每个虚拟用户数 发出的请求字节数）/测试时间，即单位时间内服务器处理的字节数。
吞吐量应该是随着VU数量的增加而增大，当系统出现性能瓶颈时，吞吐量就不会随着VU的数量而增大了，而是趋于平衡，所以我们必须通过不断添加VU来测试吞吐量的拐点，即服务器吞吐量的最大值。
吞吐率=吞吐量/测试时间：单位时间从服务器返回的字节数，也可以指单位时间内服务器处理客户提交的请求数，是衡量网络性能的一个重要指标。
从事务的角度说，如果把每次点击作为一次提交事务来对待，那么TPS和每秒点击率的概念是等同的。
注意：每秒点击率是Web系统服务器处理的最小单位，但点击一次不代表客户端只向服务器端发送一个HTTP请求。仅仅反应的是客户端提交的请求数，而不能表现服务器端当前承受的压力，因为服务器端不一定会全部处理，有可能出现被拒绝，所以每秒点击率不能直接反映服务器处理请求的能力。
性能测试重构方案
网友评论