灵魂拷问：如何规避生产环境的性能测试风险？

最新推荐文章于 2024-05-07 14:25:27 发布

隐居人家的炊烟

最新推荐文章于 2024-05-07 14:25:27 发布

阅读量778

点赞数 1

文章标签：软件测试性能测试自动化测试

本文链接：https://blog.csdn.net/m0_53918927/article/details/119333586

版权

Hi，大家好，常言道，上线一时爽，事后火葬场。隐秘Bug的哲学之道：不知道藏在哪里，不知道有多少，总是在你准备休息的时候出现。生产环境一旦出问题，内心一阵发凉，当天必须解决，大家手忙脚乱思考解决方案。最紧张的当属测试人员，我漏测了？主机锁表？服务异常？…

以下，主要介绍生产环境中的性能测试风险以及风险规避的方法。

一、生产环境进行性能测试的必要性？

在这里插入图片描述

性能测试是针对系统的既定性能指标，制定测试方案，并执行测试，得出测试结果来验证系统性能是否满足用户要求而进行的测试。性能测试结果的可参考性与测试环境有着直接的关系，如果测试是在模拟环境下进行，会存在一些问题，比如硬件和软件配置与生产环境的不一致、测试数据量和实际生产环境的数据相差太远等，这些因素都会影响测试结果的可参考性，因此，为了获取准确的性能数据，真实的反映系统性能，性能测试应尽量在生产环境进行。

生产环境是业务系统正式运行的环境，一般已经上线使用了一段时间，系统中存在大量的真实业务数据，且业务数据随着系统的运行在不断的增加和更新中，因此在生产环境进行性能测试必然会对业务系统产生影响，甚至造成一定的风险，作为测试方，我们必须预知风险，并有效的规避风险。那么在生产环境进行性能测试可能的风险有哪些？我们在测试中应采用什么样的手段来规避这些风险呢？

二、生产环境进行性能测试存在哪些风险？

在生产环境进行测试可能会对系统造成一定的风险，测试中应尽量规避这些风险的发生。

图片

1、测试可能会导致系统奔溃

考虑到系统的业务发展，通常设定的性能指标会一定程度的高于目前系统运行时承受的压力，在系统能承受的最大压力未知的情况下，测试对系统施加的压力可能超过其所能承受的压力，导致系统崩溃，影响系统正常的业务运行。

2、测试可能会造成数据损坏

在对系统进行压力测试时，可能会因为系统压力过大导致某些事务未成功执行，从而导致相关数据被破坏；有些操作需要直接修改系统中的原始数据等，这些都可能对系统数据造成损坏。

3、测试会产生大量垃圾数据

由于性能测试的并发用户量大，而且要重复执行多次，所以会在系统中产生大量的垃圾数据，影响系统的使用。

为规避以上的风险，在生产环境进行性能测试时，我们应采取有效的手段避免上述风险的发生。

三、如何规避生产环境性能测试的风险？

在生产环境进行测试会对系统造成一定的风险，测试中可以从以下方面规避这些风险。

1、重要数据事前备份、事后恢复

在执行测试前，应尽可能对系统进行备份，至少对系统的重要数据和文件进行备份，确保系统测试结束后可以恢复到初始状态。

2、测试时选择系统空闲时间

对于系统并发负载测试或者其他可能影响系统运行并导致系统崩溃的测试操作，可以安排在系统空闲时间进行，出现系统异常时有时间可进行系统的恢复工作，不致于影响业务的正常运行。

3、给测试数据加标记

对于系统测试过程中产生的垃圾数据要进行特殊标记，测试结束后要及时清理。测试数据可以事先准备并予以特殊标记，也可以是带有特定意义的区域数据或者是特殊时间段内的数据，这样，当系统测试结束后，我们可以根据这些特殊标记将相应的垃圾数据删除，保证系统的正常运行，对于那些需要直接在系统中进行变更的数据在相应的业务操作和功能确认完成后应予以及时恢复，确保将系统恢复到数据变更前的正常状态。

4、实时关注系统状态

在具体实施系统并发负载测试时，应按照指标驱动和用户逐渐增加的方法对系统进行测试。在测试过程中，应实时关注系统状态，当系统不能承受相应的压力时，测试立即终止，以有效保证测试不会超出系统的最大可承受压力，避免系统崩溃和数据损坏。

四、实际运用案例

案例1：“计生委人口宏观管理与决策信息系统”，系统上线运行一年，业务数据实行全国中心集中管理。对系统进行“流入人口登记”负载压力测试，并发用户数分别为100、200、500。

分析该系统的实际情况，全国各区县上报的业务数据在全国中心实行集中管理，在测试过程中如果由于系统压力过大，出现系统崩溃或数据损坏的情况，那么将会导致系统不可用或一整年的业务数据丢失，损失一旦造成将不可挽回。基于以上的考虑，在测试中采用方法一、二、四来进行风险规避。首先，将测试时间安排在周末进行，避开了业务系统使用的繁忙期；其次，在实施测试前，要求厂商进行全库数据备份，并做了数据恢复测试，在确保数据可以正确恢复的情况下开始进行测试；同时，在测试实施过程中，对必要的操作系统、数据库的指标进行监控，根据系统的资源占用情况和响应时间等判断是否可进一步对系统施加压力。在测试结束后，厂商对系统进行了数据恢复，使系统恢复到了测试前的初始状态，避免了数据丢失或损坏的风险。

案例2：“北京市社会保险信息系统升级改造项目”，根据业务情况，需进行“183号令补缴明细录入”操作的负载压力测试。但该操作为不可逆操作，即系统未提供取消补缴的操作，为了清除测试数据，需手工修改数据库。

在这个项目测试中，采用了方法二、三、四进行风险规避，首先选择周末进行测试；其次，为了保障测试结束后系统可恢复到测试前的状态，选择对北京市石景山区的参保用户进行该操作，测试执行完成后，由厂商对石景山区的数据进行了恢复，确保系统与测试前保持一致。

案例3：对线上的两台服务器做性能压测时，发现单台Tomcat的QPS达到600左右处理业务就明显变慢，一次请求处理时间大约上升到七秒左右(正常情况下一秒内就处理完成)，给人的感觉就是Tomcat跑不动。

在Java语言中，凡是涉及到行号信息的获取，只能通过构造异常new Throwable()抛出，之后在函数内部通过异常或上层捕获异常来拿到栈信息，从栈信息中解析出行号信息，因此在Java中凡是涉及到行号信息的获取操作，都非常的耗性能。log4j影响性能的程度依次为：日志的location信息(如:行号函数名) > console(关闭日志输出到控制台) > 异步打印 > 日志文件的大小(日志追加模式)。线上环境如果对性能有一定要求的话，建议关闭location和console控制台。

JVM调优一般来说都是出问题或告警的时候注意进行优化，可谓”水无常形，兵无常势”,具体问题具体分析。

五、总结

在现在的系统测试，特别是大型项目的测试中，系统性能的好坏已经成为评价系统总体质量的一个必不可少的方面，在生产环境实施性能测试的时候，必须对系统进行深入的了解，分析系统特点，采取合适的测试方法并综合运用风险规避手段，既要准确的获得系统的性能数据，又要保证系统的安全，这样才是一个成功的性能测试。

最后，下面是我整理出来的一份软件测试工程师发展方向知识架构体系图。

希望大家能在这个成长过程中收益良多。可以说，这个过程会让你痛不欲生，但只要你熬过去了。以后的生活就轻松很多。正所谓万事开头难，只要迈出了第一步，你就已经成功了一半，古人说的好“不积跬步，无以至千里。”等到完成之后再回顾这一段路程的时候，你肯定会感慨良多。

由于CSDN上传图片大小有限，有需要的朋友可以关注我的公众号：程序员二黑，回复1，即可获取原图。

下面是一份配套的软件测试资源包：

上面是一些配套资源，对于软件测试的的朋友来说应该是最全面最完整的备战仓库，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。