向上汇报是一个越来越重要的环节，汇报对象可能包括CTO、CIO等领导，因此我们度量的视角要拔高一个层次，不仅要体现测试工作的苦和累，还要进行价值总结。
对内部IT价值的呈现
对领导层面来说，除了业务的价值外，企业内部的IT价值也是关注点，因此测试团队的产出可以合以下几个评估及展示维度。
1.降低系统部署资源成本
降本即降低企业内部的成本。对企业来说，由于测试活动天然不与业务收益直接挂钩，因此测试团队直被打上“成本中心"的标签，所以对于成本的优化可以作为测试团队价值呈现的重要方向。
对业务部雾资源进行有效规划可以作为性能测试价值体现的方面之一。在性能测试过程中，通过性能调优，被测业务的CPU消耗下降，TPS明显提升。但是在部分业务系统中，系统的TPS不需要达到非常高的水平，只需维持在一定的范围内即可支撑对应业务。因此，针对这类系统，测试团队可以将空间优化方面的提升转变为部署资源的减少，从而达到降本的效果。前提是企业内部的建设具备一定的成熟度，否则不建议直接以缩减部署资源的方式进行降本，因为测试团队应优先保障线上业务的稳定性。
(1)降本思路
下面为阅读者展示一个实际的降本调优思路。
在A企业内部，线上业务稳定性标准为：达到业务核定TPS时，CPU利用率的峰值不超过60%，即为稳定状态。
在这个背景下，测试部门针对部分CPU消耗较高的系统进行了统一梳理和专项性能测试，在满足业务TPS要求时，通过性能测试及调优降低被测应用的峰值CPU利用率。若峰值CPU利用率出现明显下降，则减少部署节点的CPU核数，针对业务场景进行复测。若发现峰值CPU利用率依然低于60%且TPS无异常，则将生产环境部解节点的CPU核数减少，释放更多的资源用于其他业务的部署。配合生产监控手段，若在一定时间内无异常，则认为降本成功。
具体思路如下图所示。
对上图所示的降本步骤说明如下。
1)性能压测：对被测应用进行高并发压测。
2)性能评估：通过查看性能测试过程中的性能指标，评估其可能的优化点。性能标包括TPS、响应时间、CPU利用率、内存占用率、代码响应时间、全链路拓扑等。
3)性能分析：包括如下3个维度。
针对CPU消耗较高的被测应用，进行CPU热点分析及线程追踪分析。以可视化报表查看应用在高CPU利用率时运行的代码段及线程ID，深度分析代码段源码及线程调用栈，定位高CPU利用率根因。
针对内存消耗较高的被测应用，通过内存透视分析，以低开销方法获取JVM的新生代、老年代、GC堆外内存、内存对象、类对象等指标。通过可视化报表实时查看异常指标或曲线，分析与其对应的内存对象，定位根因。
针对代码响应时间长的被测应用，通过子方法调用分析，以实时字节码增强技术对代码中发的子方法调用进行微秒级耗时分析。在定位至最耗时的代码段后，开启源码分析，查看源码逻辑并定位根因。
4)性能调优：针对找到的CPU、内存、线程、代码问题，与项目组沟通，进行修复。
5)降本验证：针对优化后的被测应用，使用相同的场景及并发数进行验证，确保被测应用的CPU指标内存指标有所改善。针对已确认优化后的被测应用，降低CPU、内存配置，再使用相同场景及并发数进行性能测试，确认降配后的性能指标符合上线标准。
若降配后被测应用指标未达到上线标准，则从性能评估的步开始，再次进行分析。
(2)降本案例
基于以上降本思路，A企业内部的实际系统调优过程如下
1)问题现象描述：在高并发压测场景下，系统中应用的平均CPU使用情况如下图所示，实际CPU利用率达到70.07%，最高达到100%。
2)定位过程描述：通过性能分析平台的热点分析，发现大部分CPU都消耗在日志爬栈操作过程中。
3)确定性能风险点：频繁的日志爬栈在高并发下会导致CPU消耗过大，影响整体应用体验。
4)提出优化建议：从开发规范角度来说，不建议通过行号来定位，因为这样做的成本太高，资源浪费太多，最好使用带有准确标志的输出日志字符串来明确哪段代码逻辑有问题。对于该案例，首先，建议将打印行号的参数%1、%L删除。其次，删除%method或者%m配置，目前Debug、Info、Wam、Error这些级别的日志使用的是同一套输出格式，即pattern配置相同，建议Debug和Info不要打印方法名和行号，直接打印Warn和Error就可以。
5)实际优化效果：通过修改配置，TPS从260笔/秒提升到320笔/秒，提升25%以上。
6)降本效果：应用服务器配置降低50%后，整体指标仍满足目标值。
2.提升业务测试覆盖度
在传统情况下，因受限于测试工具，会出现测试资产无法快速复用，测试规范无法同步到每个测试工程师的情况。这一方面导致较多的无效执行，严重浪费了测试工程师的时间，另一方面使测试团队的精力投入在大量的重复执行上，无法开拓更多的测试方向。
由于测试过程中的调优阶段涉及多部门的沟通、协调，以上情况会造成测试团队在规定时间内只能针对核心业务的核心接口进行性能测试。随着企业的性能测试体系建设逐步完善，测试团队的执行效率将会越来越高。以回归测试为例，测试工程师可以复用已归类的测试脚本、测试场景，从而快速开展测试，并且通过链路分析能力快速发现性能缺陷，再结合根因分析快速进行调优。对此，测试团队可以在短时间内完成基本的回归测试，然后将更多的时间和精力投入到全系统、全工程、全接口的全量测试上。
当然，这是企业一个长期的建设目标。要达成这个目标，测试团队不仅需要先完成自我能力的提升，完成现有测试需求，提供质量保障，还需要在不影响现有业务需求的情况下逐步进行能力拓展。但是，从给测试团队带来的价值上考虑，上述举措值得测试工程师去尝试。
首先，测试团队可以化被动测试为主动规划。在传统情况下，由需求方提出测试目标，测试团队再开展性能测试，所有的指令来源于业务，测试团队处于被动状态。
随着测试效率的提升，现有业务系统的测试结果有了质量保证，测试团队将有时间、精力去规划其他需要进行性能测试的业务，而领导层也愿意让测试团队去完成更多的业务覆盖，从而更全面地提升整体生产系统的稳定性。
其次，测试团队承接更多的业务，将具备更大的话语权。测试团队可以结合历史测试数据和稳定性结果，对需求方提出测试标准规范，让测试需求更加明确、精准，方便后期更快地开展测试工作，以此形成一个良性循环，让测试团队的测试效率再次提升并承接更多的业务。
同时，随着测试团队覆盖的业务需求增多，从企业管理层面来说，测试部门逐渐由成本中心转为质量中心。测试团队能更好地完成平台化能力建设、人员扩张、测试体系赋能，将提升业务系统稳定性作为核心质量目标。
阅读后若有收获，不吝关注，分享，留言等操作！！！！
