今天我们为大家带来一则数据压力测试的小故事，还原甲乙双方的沟通过程，从中找到问题从而避免问题在自己的工作中再次发生!

最近配合某客户做了一个关于XX系统的压力测试，其实经过和客户的沟通得知，客户此系统上线后压力并不大，但由于应用方前期的表现不是特别尽如人意，对此不太信任，所以要求本次压力测试着重观察。

参与方

我、客户、应用方(我和客户简称甲方，应用方简称乙方)

环境配置

数据库：RAC一体机集群(为方便统计，应用统一链接一个节点)

压测工具：jmeter

压测场景

大概10个大场景，每个场景有100、200、300 3个级别的并发小场景，每个小场景压测10分钟

压测数据量

压测数据为应用方编造，数据库大小2G，其中涉及的关键业务表数据量大概有40万，10万，3万不等的数据

压力测试

此前也做过很多次压力测试，对于数据库方面来说，主要是搜集服务器当时的CPU，内存使用，以及关注AWR报告SQL执行部分是否有异常，便于正式上线后，系统资源的分配，从压测数据量来看，2G数据可以说是很小的数据量，另外并发最大300，对于2G数据来说，也不算大，本以为压力测试可以顺利进行，那也只是理想很丰满。

插曲一

在测试其中一个场景A 300并发，jmeter压测工具开始报错(具体报的什么错，暂不追究)，乙方给的恢复是数据量太大，达不到300，继续下一个场景 B，100并发，在进行完这个100并发的场景后，就有了如下对话。

甲方：xxx表数据 上一个场景A 300并发时，还是10万 ，这个场景B 100并发的场景跑完变成3万条了。

乙方(压测人员)：@经理 这个我不是很懂，你帮忙看下。

乙方(经理)：这个我找人处理的，十万条数据数据量比较大，实际没有那么大的

甲方：这在测试呢，你们数据清理了?

甲方：今天把你们做测试数据的表和对应的数据量都写到方案里确定下来。

甲方：不要测试过程中删数据。

甲方：不能为了达到并发标准在哪删数据，达不到就是达不到，后期可以优化的。

甲方：确定下来，测试过程中不要做小动作。

乙方(压测人员)：删数据这个我就不知道了，一般压力测试的时候都不会让他们做什么操作的。

从上面的对话，大概对情况有一个了解，乙方可能是认为，数据量大所以场景A 300并发报错，在没有和甲方沟通的情况下，私下清理了主业务表数据量，不巧被甲方发现，甲方大为不满。其实压力测试就是为了确认系统的运行压力，如果都和乙方那样，私下清理数据，也就失去了压力测试的实际意义，在此，给各位奋战的DBA 和 应用人员一个建议，实事求是，实时沟通。

插曲二

由于压力测试，每个大场景都有3个不同并发级别的小场景，但是在分析AWR报告时发现，其中SQL执行次数部分并没有明显的变化，100并发SQL执行次数30000，200并发SQL执行次数30000多，根据以往的压测经验来看，这肯定是有问题的，同时在系统CPU使用来看，也证明了这一点，两个不同级别的并CPU使用并无明显差异，然后甲方乙方开始。

甲方：100和200在数据库后台执行的SQL次数没有太大差别

乙方(压测人员)：10分钟100个并发，这么多次;10分钟200个并发，应该不会变成2倍吧。

乙方(压测人员)：这个是总次数吧?

甲方：是。

乙方(压测人员)：那我觉得这个没问题吧?

乙方(压测人员)：你说的这个暂时记录着，回头他们看下。

乙方(压测人员)：你说的情形，我咨询过了， 可能会涉及到修改对应的一个服务里面的参数。

乙方(压测人员)：所以今天先100的跑了吧。

看到这里，基本明白了，前面几个并发测试等于是白测试了，这也告诉我们，做事还是细致点好，同时要说服乙方，就要拿出证据，免得双方扯皮，怪不得客户提前都说，这次压力测试要着重点看。假如只是为了应付工作，简单的搜集点数据，然后事后再分析，那反工时必然的，吃一堑长一智。

插曲三

压力测试终于到了最后3个场景，对于前几个CPU压力表现还算正常，起码是有压力的，但最后3个场景的CPU压力几乎没有，难道是一体机的性能太好?那也不应该，再说这个场景是关于客户分析，市场分析的场景，从字面意思看，应该会访问很多数据表才对，这次又实实在在的分析各个运行的SQL，以及具体涉及的业务表。

甲方：上个场景 客户分析中 XXXX表是什么表?

乙方(压测人员)：我问下去。

甲方：那个客户分析的场景 数据库服务器几乎没压力 后台显示访问比较多的是这张表。

乙方(经理)：刚刚那个是地区省份的筛选。

甲方：哦 客户分析 后台的数据来源 只有这一个主表么?

就在这时，乙方测试人员发了一个哭哭的表情，我就意识到问题有出现了。

乙方(压测人员)：你一问，我看了一下。

乙方(压测人员)：xx分析的脚本，之前调的时候有部分禁掉了。

乙方(压测人员)：重新跑下xx分析吧，我停了。

甲方：。。。。。。。。。。。。。。。

看来甲方最开始的不信任还是有依据的，这个压力测试在此之前，乙方已经准备了一周左右，但还是出现各种状况。

总结

针对此次测试，除了插曲一乙方做的不地道之外，另外2个都是乙方前期准备的问题，在此，我们不对乙方做过于‘积极’的评价。

对于我来说，有以下感悟：

1、不管是对自己或者客户，做事要以主人公的心态，抱着应付了事，害人害己呀，比如案例中XX方。

2、和其他环节的人员沟通不确定性问题时，需要拿出确凿证据，免得双方踢皮球。

3、良好的沟通是客户服务的第一环节，或许你能力暂时不够，但不能糊弄客户，谁都不是傻子。

感谢您的阅读，以上就是为大家分享的数据库压力测试的过程，你从中学到了什么，知道在自己以后的工作中如何避免吗?好了，更多软件测试相关的问题，欢迎您来达内软件测试培训机构进行咨询。

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。