性能测试如何创造业务价值

如何看待技术和业务的关系

做技术的同学对这点应该很熟悉的，面试或者同行交流时，都会说要懂技术还要懂业务，或者基于什么业务场景，采取了什么技术方案，解决了什问题。所以技术和业务的关系在我看来挺简单的，互相成就而已。我理解的技术和业务的关系，用一句话概括就是：技术是为业务目标达成提供支撑和效率工具，业务目标更好的达成对技术有更高的要求。

业务的目标：运营业务增长

常见的业务场景，具备的几种特性：

1、业务可视

业务的可视，简单理解就是业务的状态，处在什么阶段，目前的效果可以直观的以可视化的状态来呈现，常见的场景就是业务监控大盘（想想监控大盘需要技术做什么？数据采集/数据存储/数据展示）

2、业务可管

最常见的就是一些促销活动的配置，比如活动时间、涉及的商品/优惠券、用户类型以及标签体系（这里又需要技术做什么呢？活动会场搭建工具/优惠信息缓存/活动消息推送）

3、业务可控

业务可控也可以通过字面意思理解，即：各个业务维度的运行监控/业务配置发布回滚以及防资损；

4、业务可优

这一点，我们现在最常见的有电商的千人千面，短视频的智能推荐、针对不同等级会员的优惠营销体系等；

5、阶段挑战

每个阶段每个环节都对技术部门提出了挑战：
从需求提出到发布
研发成本、研发效率、交付质量；
从下单到订单履约
提高业务成交履约率（撮合交易/成单匹配/留存转化）；
业务活动的营销推广
活动搭建、抽奖&优惠券&营销短信等方面的快速响应；
线上故障的快速发现解决
监控告警、问题定位、风险评估、线上服务的SLA；

性能测试如何创造业务价值

性能测试出现的初衷

先思考一个问题：我们开展性能测试的初衷或者说需求从何而来？
可能是线上用户反馈APP响应太慢，可能是财务或成本部门反映IT的硬件成本太高，也可能是某次业务运营活动由于系统无法及时正确的处理导致了业务目标未达成（问：双11零点线上系统挂了是什么体验）。这些问题归类来说，都是源于用户和业务的痛点或诉求：

1. APP响应太慢：想办法提升处理速度；
2. 硬件成本太高：想办法降低硬件成本；
3. 业务目标未达成：想办法提升系统稳定性；

为什么要做性能测试？

从性能测试的几个关键指标展开来讲，性能测试中大家最关心的是TPS/RT/资源使用率。
TPS即每秒事务数，表示既定配置下某个服务单位时间内的处理能力。
RT也有平均RT/99RT等，是从不同的维度衡量系统处理单个请求的耗时。
资源使用率即运行于某服务器上的服务在处理请求时所耗费的资源。
当然还有请求成功率这个指标，该指标主要用来衡量系统处理请求的成功率和异常请求的容错能力。
从性能测试行为来看，性能测试目标是在尽可能提升系统处理能力&异常容错能力/降低请求耗时的同时，追求资源耗用达到最低。

性能测试创造了什么价值

接着上文继续聊，用户有反馈，财务有诉求，业务遇到了痛点，怎么办？想办法解决问题！
用户反馈慢，那就通过性能测试不断的调优验证，提升单位时间内的处理能力，降低处理耗时，提升用户体验。
财务反馈成本高，那就提高既定配置下服务器的资源利用效率，用更少的资源处理更多的请求，降低硬件成本。
业务遇到了痛点（技术导致业务目标未达成），就想办法利用技术手段解决业务的痛点。
总结一下就是“降低成本/提升用户体验/保障业务目标达成”，这就是所谓的业务价值！

性能测试创造价值的前提

前面我提到了技术是为业务目标达成提供支撑和效率工具，性能测试可以直接或间接创造业务价值，但并不是说有工具就能创造正向的价值。
我觉得性能测试只要做起来还是在成就业务价值的。
这需要满足几个条件：企业有需求，有资源投入，有看得见这个价值的领导支持，有不断迭代前进的流程规范和技术体系建设。否则性能测试依然是低端run工具水平。
其实技术要创造业务价值很简单，只需要遵循这几点：

• 发现业务痛点；
• 找到合适的方案；
• 用更低的成本更高的效率更好的解决业务痛点；