业务部门在性能测试中一般都是需求提出方，但是受限于技术背景和性能测试的认知，测试工程师要将业务部门的业务需求转化为可验证的技术指标，如TPS、并发数等。这就给测试工程师带来新的问题：针对技术性的结果指标，业务人员与测试工程师无法形成统一的认知，出现理解偏差。所以线上业务出现性能问题，最后还是由测试团队“背锅”。

例如，测试工程师的测试结果为：当有200个并发用户时，TPS为986.69笔/秒，系统处理响应时间为2.46秒。在最终的评审会上，业务人员可能理解为当前系统只能承载200个用户使用，在动辄用户数超过10万的活动需求下，这个结果一定会被质疑，从而带来更高的解释及沟通成本。因此建议将测试结果从业旁视角进行展示。

一、业务维度的度量指标

为了避免上述的情况，在展示测试数据时，需要将技术数据转化为业务指标数据，直观地呈现给业务人员。仍以上述场景为例，最终的测试结果可以转化为如下形式。

场景：描述测试覆盖的业务场景和测试系统的节点个数，比如在标准下单流程中节点为60个。

业务分布：按照当前业务场景的流量占比来展示，如首页38%，进入菜单38%，加入购物车22%(包括匿名用户)，下单流程(包括加入购物车)11%。另外，还要配合其他数据，如当并发数为200时，TPS为986.69笔/秒，订单为61个/秒，系统处理响应时间为2.46秒。

业务结论一：如果按照用户操作的整体等待时间为5分钟(300秒)来计算，系统能够支持的在线用户效约为986.69x(2.46+300)=298434个。

业务结论二：如果按照用户操作的整体等待时间为3分钟(180秒)来计算，系统能够支持的在线用户值约为986.69x(2.46+180)=180031个。

对此，业务方就能直观地了解到，在60个节点的环境下系统实际承载的用户数、每秒订单数等是多少以便快速判断是否满足预估的业务需求。

二、业务性能基线

针对性能测试，业务人员不仅关注单次的测试结果，还关注每次选代后业务的性能表现是否有所改善。

例如，某个业务一年选代10次，如果每次的选代性能下降1%，在测试阶段感知较小，但是将下降率累计，其性能表现最终会相差10%以上，这个时候很难进行有效补救。因此对于每次业务选代，都要记录测试结果，形成性能基线，从而展示业务性能趋势。当为下降趋势的时候，测试工程师和开发工程师应马上进行补救。如下图所示，3月份出现TPS下降，其实在上一年12月的测试数据已呈现突然下降趋势，若测试工程师只分析了3月下降的原因，可能只修复了一部分缺陷。基于基线模式，建议测试工程师配合上一年12月的测试数据一起分析，查看是否为同一个原因导致的。

将性能测试结果有效地传达给业务部门，是确保技术改进能够支持业务目标的关键环节。以下是几个建议，帮助你更好地与业务部门沟通性能测试的结果：

转换语言：

使用业务部门熟悉的术语来解释技术概念。例如，避免使用过于专业的技术词汇，而是用“响应速度”、“用户等待时间”等更容易理解的语言。

强调性能测试结果如何直接影响用户体验、客户满意度、转化率等业务关键指标。

突出影响：

清晰地展示性能问题对业务的具体影响。比如，如果网站加载时间过长导致用户流失，可以具体说明这可能导致多少潜在客户的损失。

使用图表、图形等方式直观展示性能测试前后的主要变化，使非技术人员也能快速理解。

提出业务价值：

解释性能优化的潜在商业价值，如提高网站访问速度可以增加页面浏览量、提高转化率等。

量化优化带来的预期收益，比如预计可以提升销售额的百分比或是减少运营成本的具体金额。

建议行动：

向业务部门提出具体的改进建议，并说明这些措施如何能够解决问题并带来正面影响。

如果有多个优化方案，可以列出各自的优缺点及预期效果，帮助业务决策者做出选择。

协同工作：

表达愿意与业务部门紧密合作的态度，共同推动性能优化工作的进展。

建立定期汇报机制，让业务部门了解优化工作的最新进展和成果。

教育与培训：

提供必要的培训或研讨会，帮助业务部门成员理解基本的性能概念及其重要性，增强他们对性能优化工作的支持。

案例分享：

分享行业内其他公司成功优化性能的例子，特别是那些与你们公司业务模式相似的企业，以此激励内部团队采取行动。

通过以上方法，你可以更有效地将性能测试结果转化为业务部门可以理解和接受的信息，从而获得他们的支持，共同推进项目的成功。

阅读后若有收获，您的关注，分享，留言评论等是对我最大支持！！！