性能测试重构方案

96
秋之川 Excellent
2016.06.16 23:36* 字数 1624

进公司以来,对于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请求。仅仅反应的是客户端提交的请求数,而不能表现服务器端当前承受的压力,因为服务器端不一定会全部处理,有可能出现被拒绝,所以每秒点击率不能直接反映服务器处理请求的能力。


图片发自简书App
学以致用の性能测试
Web note ad 1