性能测试的个人总结

            最近在和原先的测试朋友聊天发现目前国内大多公司在招聘测试工程师的时候都会要求有一定的代码能力以及一定的接口、自动化、性能测试相关经验，而对于大多数做功能测试很久的朋友来说性能测试等接触的并不是很多，尤其对于一些小的创业型公司来说。有人会说要不要进行性能测试是根据业务量来定，但是就目前我接触到的几个生产问题发现，业务量小的也会存在一定的性能问题而在功能测试中并不能轻易的发现出来。

            以下是个人在做性能测试中遇到或者所涉及的一些流程做了一个简单的总结，希望可以给刚接触性能测试的你有个入门的了解。

一、  性能测试脚本准备；

    1.1、 根据业务量的需要，性能的要求明确性能测试的场景；

            1.1.1在确认性能压测的场景中重要的是首先明确场景的业务逻辑以及上下链路之间的流程；

            1.1.2确认压测场景的接口类型（RSF、MQ、Windq、http、JOB、DPA等）根据接口的类型明确压测脚本的编辑；

            1.1.3需求评审的过程中明确压测的报文数据结构（入参数据的组成形式、产生的日期或者是状态等等的要求）；

            1.1.4需求评审的过程中明确压测的场景的其他要求（铺地数据要求）一般查询类的场景中对于铺地数据的要求会比较多，性能中不仅仅要求对于应用层面的代码的压测也会针对相应的数据库层面的压测；

            1.1.5铺地数据说明：铺地数据同样可根据生产上的实际数据结构（数据的状态，数据所属机构，数据所属的角色，数据创建的时间等等）去准备，一般情况铺地数据的量可根据生产上近三个月的量来定；

        铺地数据准备的方式：铺地数据的准备可有三种方式准备：

            a、同步生产上的数据，可通过DBA协助将生产上的数据去除敏感信息后导出，导入到对应性能测试环境中作为铺地数据用，优点是数据准确性以及可靠性最好，缺点是运作流程较为繁复；

           b、按照正常的接口去铺数据，优点就是涉及到的数据存储覆盖较全，缺点维护新增数据接口环境；

           c、直接连接数据库铺数据，优点铺地数据较快，缺点是涉及到的表以及数据结构需要全面，注意不同的数据库插入数据的方式（mysql&pg 直接insert就可以，ES则是通过插入json）；

    1.2、 在测试脚本的编辑过程中注意的几点；

            注意参数化的应用有些场景的数据可能需要在数据库中已经存在的数据应用，注意数据的利用次数，有些场景对于参数化数据只能应用一次有的则可以重复使用，切勿因为数据的利用次数原因导致压测的结果不正确；

            脚本的接口入参报文的编辑，入参报文最好从生产上捞取的正确的符合生产的入参报文结构，避免报文结构的不正确或者是报文结构的过于简单导致压测的结果与生产出入较大；

            综合场景的中入参报文的结构，可根据产品提供的综合场景不同业务的比例在脚本中设置一定的比例运行入参，以确保压测的结果全面性。

            链路场景中确保测试环境的链路的畅通以及入参在链路中运行顺畅，明确返回结果异步还是同步避免误判导致压测结果不准确。

            脚本编辑成功后可在本地进行调试（前提是对应的系统应用发布成功，数据库等响应的配置正确），调试成功后查看接口返回的执行结果，可作为性能压测的结果判断获取正确的性能TPS；

            备注：在脚本调试的过程中注意查看数据是否进入了让正确的数据库表中，对应的字段是否正确，根据服务器中的日志查看和调试脚本确保脚本正确可用。

        1.3、 将调试好的脚本放入响应的测试平台（本章针对本公司性能测试平台，有的直接在工具上执行脚本即可如：jmeter或者loadrunner等）

            将调试好的脚本放在性能测试平台上首先调试一下（注意依赖的jar等同步到对应的平台上），调试过程如本地脚本调试；

            在蛙测平台上调试压测的策略：代理机、进程、线程等增加和调试并发用户数，注意代理机的使用当压测中发现代理机的CPU超过20%左右的时候需要增加代理及以防止代理机死机；

            平台上的压测策略注意压测时间和压测次数的合理利用（一般脚本使用参数化可利用压测次数，脚本无参数化且对于长时间运行接口使用时间）；

二、  执行压测

        1、执行压测前

            1.1确保性能测试环境的正确运行且为最新版本：

                a、维护性能测试环境版本与开发发布的环境保持一致；

                b、明确性能测试环境中相应的配置与生产保持一致

                    服务器方面：应用服务器的数据源配置、数据库最大和最小连接数配置、应用服务器的JVM各参数的配置；

                   数据库服务器对应数据库连接数的配置，mysql慢sql关注的还需要打开慢日志的开关以及超时阀值。

                c、数据库维护：根据开发所提供的要求确保性能测试环境的数据表结构与生产上的表结构保持一致，包括表结构中的字段，以及索引；注意在版本迭代中的数据库表结构的同步。

           1.2 确保应用和数据库服务器中的日志文件等磁盘空间足够防止压测产生的日志导致服务器down机；

       2、执行压测

           在压测中注意观察应用服务器以及数据库服务器的CPU、IO、连接数等指标是否有异常的情况；

           在压测中注意观察数据库中数据的进入情况，确保压测平台上的执行次数与入表的数据量保持相同，如有出入需要确认定位到问题的出现情况；

       3、执行压测后

            压测结束后整理压测结果，收集正常和正确的压测数据，分析TPS以及CPU等参数作为性能测试报告内容； 

三、常见性能问题的定位

      1、 应用层面的问题定位；

                   问题1：在压测中发现应用服务器的CPU过高，且压测的TPS达不到性能指标的要求，耗时较长；

                   定位：在该压测的场景业务代码中加上耗时，并在本地调试查看耗时较长的代码，给予问题的定位，给出调优方案或者告知开发耗时较长代码的问题所在（有的可能代码使用有问题、有的可能代码中加入了sleep等待时间）；

                   问题2：在压测中发现应用服务器的CPU不高，但是压测的TPS达不到性能指标要求，耗时也不长；

                   定位：这个时候需要在压测中关注服务器的连接数情况，可能是配置的连接低于业务中实际使用的连接数；

       2、 数据库层面的问题定位

                   问题1：在压测中发现数据库服务器的CPU过高；

                   定位：一般这种情况多数由于数据库中存在慢sql导致，这个时候需要在数据库中将慢sql的时间等级调整到合适时间，一般时间调整为0.1S，sql耗时超过0.1S则记为慢sql；调整后可在数据库的对应慢日志文件中查看到对应的慢sql，将获取的慢sql放在数据库中使用explain 查看执行计划，一般情况慢sql的处理方式有两种索引的调整或者是sql语句的调整；

                   问题2：在压测中发现数据库服务器的CPU不高，但TPS上不去；

                   定位：一般情况下同样查看在压测过程中的数据库的连接的大小或者是连接池的大小与环境配置中的大小作比较；