性能测试个人经历演变

综述

个人从事软件测试已经大概5个年头了，有幸参与到一个WEB项目中负责了性能测试的工作。可以说是一段有得有失，有苦有甜的一段过程。也认识到性能测试要做好并不是简简单单的压测几个字能体现的；特别是在现在微服务化，快速迭代流行的背景下。本文主要记载一段经历，不会细讲到具体实现上；讲讲自己的一些性能经历和认识，算是一段记录。细化的每个点都值得写一篇博客，后面再慢慢更新吧。

阶段一：解决有无问题

这是最初的阶段，这是解决有无的问题。这时候，系统还是一个大包解决问题，是一个大型的WEB项目。看护性能并不是那么的迫切，由于用户量并不多，各种文件和接口请求的处理甚至TPS不用到20。在这个时候，做了一次性能的测试，测试目的当然只是版本发布需要。
简单讲下测试思路：
（1）环境：找台机器安装数据库，找台机器安装服务。规格跟现网一样。
（2）基础数据量：无
（3）测试范围：测试觉得应该测试这些接口，于是就测试这些接口。
（4）指标：没指标，只关注相应时间。甚至脱离了并发在看响应时间。资源啥的都没很关注。
（5）测试工具：jmeter，然后和jenkins搞了个自动化测试。
本阶段，可以说只是进行了一次性能的摸底。很粗的了解了下某些业务场景的响应时间的情况。

阶段二：微服务化第一阶段

随着业务的可预期的增加和需求的增多，架构上进行了重构。微服务化，原来大的一个包，现在根据业务模块，拆分了十几个微服务，微服务与微服务直接通过总线交互。随着微服务的拆分就有了设计上对接口的性能要求。不在是一次性的测试，而是随着版本进行性能测试的看护。每月看护。
这个阶段的测试思路：
（1）测试环境：依旧根据现网的规划，在研发环境搭建了一套一比一的。（此时的服务并不能弹性伸缩，所以规格很重要）
（2）测试目标：根据设计的基线，测试业务是否满足基线需求。此时的基线是一个场景，或者一段流程。如：下个单需要多长时间。用户打开一个页面需要多长时间。同时规定了并发要支撑到多少。
（3）测试工具：依旧jmeter+jenkins+nmon
这个阶段，有了明显的指标性。以并发和响应时间作为双指标。要求在某个并发下，响应时间需要达到多少。文本处理单位时间内要端到端处理多少数据。
这个阶段，开始关注了服务器的CPU，内存，数据库的IO，慢sql。
在情况上，有哪些困难：
（1）其实性能测试有个难点就是数据的构造。特别是在端到端流程特别长，依赖特别多的时候。如何做到测试数据满足性能测试要求是很重要的。在这个阶段，还是通过人工梳理出业务上的依赖。比如下一个单，到底涉及哪些服务，哪些接口，又依赖哪个库，哪个表的数据，具体到他们的那个字段。都需要通过日志和业务的学习梳理出来。这个过程是是否枯燥无味的。
（2）基础数据。首先我们并不知道要有多少数据量在库里。多少合适呢？其实并没有个结论。于是，这个阶段，只是将数据控制在量级上，根据现网的情况，去评估数量级，并没有严格控制基础数据也业务之间的关系。
（3）性能问题很快发现。其实，由于性能测试一直并没有很系统的去测试，所以问题很快暴露。但是在能硬件解决的问题，通常不愿意软件去解决。最先出现问题的是数据库。最简单的是排查出了业务中的慢sql。对于这种问题， 团队会去尝试解决你的慢sql,然而，并不是所有的数据库慢都是sql编写不规范导致的。比如：数据量大，数据分布离散。这种问题，其实需要业务架构设计去优化。然而选择了一种捷径，换磁阵。后来证明，换磁阵，躲得了一时，躲不了一世。
（4）定位手段单一：业务日志，Tomcat堆栈日志。
这个阶段的特点是性能测试场景简单，自动化程度低。测试指标依据凭空想象，性能看护初级，无预见性。
无论如何，测试人员手拉肩抗，终于搞完了一些看似重要的接口场景的性能测试，也总算生产上，并没有爆发性能问题。总的来说，还是因为业务有限。

阶段三 业务爆发期

这是个业务爆发期的过程。很明显，系统已经感受到压力，而性能测试并不能告诉大家系统能扛到什么时候。另外服务增多到将近七十 八十的样子，在增加覆盖率的同时，如何提高效率是一个很重要的问题。
大致思路有两点：
（1）端到端看护重点场景。这个主要是看护重点场景的全流程情况。由于微服务未docker化，还是在固定节点运行。依赖的数据库未云服务化，需要自己管理。那么就少不了合设资源竞争问题。
（2）mock测试。通过mock及时，将服务依赖mock化，在单个节点上测试服务本身接口的性能。
两个互补，互相印证。
提高效率及测试有效性的点：
（1）借助现网日志分析ELK：分析出现网的接口调用高频率和高耗时，作为重点接口。涉及的接口和场景作为场景和mock测试的输入。同时能印证测试环境测试结果和现网实际的情况。
（2）测试环境采用了两套资源监控的方案，各有好处：
<1>jmeter的permon metrics collector :好处很明显，就是能在测试的时候收集你想要的资源监控。坏处是会影响jmeter的性能，而且在你没法进行界面化测试的时候，你得想办法将数据给展示出来。
<2>另外一种：采用nmon+ELK ,nmon负责采集资源监控，ELK负责解析及图形化。坏处需要做解析规则（并不容易，主要是ELASTICSEARCH的解析）另外就是和自动化之间要建立联系。如果将ELK上存储的数据跟用例建立关系也是需要考虑的。在场景测试，综合场景测试中，ELK这种方案有明显的优势，应为那时候你关注的并不是一个节点，而是多个节点，多个数据库
<3>最推荐一种：利用pinpoint的agent,定制开发获取jvm，节点资源，数据库执行时间的数据，一站式搞定所有数据的监控获取和展示。需要有较强的工具定制开发能力。
（3）性能的定位：分两块：服务的性能和数据库的性能。
服务的性能，我们可以用jprofiler,但是这个是侵入式的，会影响服务的性能。优点是能很快定位到那个方法那个类。耗时多长。还有一种是pinpoint类的，能快速定位，并且不是侵入式的，那么其实不影响业务，测试发现性能影响在7%以下；这样我们能边执行用例边分析实时的pinpoint监控。包括jvm的情况，sql的情况（sql监控是需要定制支持的）都可以监控到。并将其应用的现网，实时监控现网情况，对比差异点，分析原因。能补充和印证测试的有效性和正确性。
数据库的性能，通过上面的方案其实能很好的看护测试和现网的数据库使用情况。数据库节点资源使用情况，特别是内存IO，及慢sql的获取，并定期审视对比慢sql。
（4）测试的预测性：必须建立好系统中的主要性能影响因素或场景。以及这些场景的决定因子。这些因子将影响系统的容量。性能其实更加关注容量，就是系统撑得住吗？最大到多少？什么时候可能出问题？我们该怎么办。这就是需要去分析现网的数据库数据及接口调用情况。分析哪些业务是主流，这些业务的主要决定性因子是哪些？比如是客户的多少？订单的多少？数据库的存量数据已经是一个很重要的影响因素了，他已经不是万的级别了，而是到了亿的级别。建立数据库和业务TPS的关系是很重要的。多少业务其实都是会跑在多少数据量上的。
（5）关于数据预置：存量数据有两种方式：从现网脱敏获取或者自己生成。无论哪种，其实就是做成数据包的形式，需要的时候load到数据库中，这个是个耗时的过程。另外，除了存量数据，还有测试数据。有两个方式可以生成：一种是通过跑接口跑业务让系统自动生成，一种是梳理业务的数据依赖，然后通过脚本或者工具生成数据包，又或者利用脱敏数据进行测试。其实即使用脱敏数据测试，你也逃不了业务依赖数据梳理和生成；毕竟脱敏后的不一定是你要的。另外，业务产生的数据也是你要考虑的，在高并发下会迅速产生大量数据，如何清理也是需要梳理的。业务的并发和业务的存量数据又在一定的情况下是有联系的。比如非抢购时段，你的业务增长，必然累计了大量的数据。
（6）测试体系：现阶段已经不是一种测试能完成的了：你需要做接口指标测试，场景指标测试，接口压测，场景压测，综合场景测试压测，接口及场景弹性测试，浪涌测试，大数据请求测试。而这一切，不是一次测试，一个版本解决的。你得常规看护，如果实现平台化，自动化，测试结果可对比回溯，系统性能可预测都是一个课题，
（7）测试的最终目的:性能测试的最终目的是告诉我们，系统按这个趋势发展，能抗多久，在什么时候会不行，在哪种峰值情况下哪里会出问题。我们有什么方案应对，这种方案又能抗多久。
（8）这过程涉及到分库分表，业务增高，资源增配，节点扩容，数据库合设拆分，大数据量处理优化等经历都是随着业务的发展自然而然会遇到的。其中积累的一些测试分析方法另外写博客分享。

那么接下来呢？

其实到这里，也并不是业内最先进的测试方式。接下来，需要的是云平台化，在线化，智能化。
云平台化：性能测试应该有统一的平台管理，从环境管理，数据管理，用例管理，用例执行，结果收集，结果分析，提单，测试报告输出都应该自动化，否则如何应对越来越快的节奏
在线化：灰度为啥不能是性能测试灰度，流量为什么不能录制回放
智能化：人可以预测，机器也能。只要提供足够的数据，让机器告诉我，什么时候，在什么条件下，哪里会出问题。让机器告诉我测试偏差在哪里。让机器告诉我，用户习惯是否转移了变动了，这些都对测试有帮助，都能用于实时调整用例。

先写到这里，只是一个阶段总结。后面坚持写些具体性能工具，分析等用到的技能和方法吧。安~~