性能的闻道先后
测试其实是一种有效保障交付变更质量的保证方法，那么反过来看不保证交付质量可以吗？答案其实是可以，这样就会导致不良质量成本的出现。举一个非IT的例子，一个生产电风扇的厂商如果不做质量保证，流水线生产出来的电风扇就直接上市销售。我们假设流水线生产的电风扇的良品率是90%，一台电风扇生产成本是售价的50%。一台电风扇从生产完成到售卖到用户手中包含了包装、运输、营销等一系列的过程，这个过程总费用是一台电风扇售价的50%。那么如果这个电风扇生产厂商1个月生产10万台电风扇，每一台售价100元，那么要是没有质量保证，这一个月不良质量造成的成本就是10万台*90%*100元，结果就是900万的不良质量成本的损失。如果一切都不改变，仅仅是在流水线生产完成后加上质量保证环节，那么至少可以可以不让质量问题的产品流入市场，因此不良质量成本就减少了450万。
那么我们再回到我们软件的系统变更过程，测试在制品过程中越早的投入，就可以越早的发现质量问题从而减少不良质量成本。在功能测试活动中我相信所有人都能理解，所以缺陷逃逸率几乎是现在每一个团队都要度量的指标。为什么到性能测试就会有人本末倒置呢，当生产发现服务相应慢的时候，就是性能缺陷的逃逸，也是制品团队交付了不良质量的变更。也就是说性能测试在前，APM监控在后，不做性能测试使得一些性能缺陷逃逸，虽然APM发现了问题，但是也是事后的手段，同样对用户的使用造成了影响，这也造成了不良质量成本。
性能测试的开展时机
随着现在技术的发展，DevOps包含饿了越来越多的内容，DevSecOps、DevPerfOps等等Dev{}Ops就变成了每一个角色讲故事的通用范式了。那么无论叫什么，性能是任何产品交付过程中无法逾越的特性，也是八大软件质量特性中的一个，保证产品的性能效率质量特性的方法性能测试就是必不可少的一个环节。
在10年前每次有性能测试的需求测试小伙伴都会认为是一个大任务，需要很多天很多投入去验证，也相对应的让性能测试变成了一个很难做的任务。那个时候很多大规模公司都有专属的性能测试团队，性能测试团队在这个那个测试团队中的地位还是相对较高的，话语权非常重，尤其是在银行类系统的交付团队里。随着容器化的不断普及，被测环境和测试工具的部署可以在分钟级交付，性能测试已经降低了很大的门槛，节省了很多成本，这也是为什么很多互联网大厂能够实现的性能测试常态化的基础，那么性能测试的开展时机就是任何时机，只要有需求就可执行、可验证、可度量、可优化。
在测试领域，互联网远远领先于其他行业，那么在全部测试团队推行常态化的性能测试常态化估计还需要很长的一段路要走。既然不能马上进入高速路，性能测试的开展时机仍就是一个需要多方面考虑的问题，当然也是按需的进行，也不能随心所欲的投入。那么什么时候就应该是需要性能测试开展的时机呢？如下几点出现任意一种情况，都应该开展对应业务流程的性能测试，除非该业务并不关注性能表现：
- 有并发业务访问模式，并且第一次在系统中交付
- 单接口测试响应时间超过1秒钟
- 3个月没有对系统关键业务流程或者并发业务流程做性能评估
- 被测系统业务数据增长1个月内超过预期增长速度1倍以上
- 其他明显会影响性能的变更或者基础数据的变化
当如上情况出现的时候，我们就应该立即按照预期的数据规模、访问规模、并发规模完成性能测试，给出优化建议。
总结
《史记·鹖冠子》记载，魏文王问扁鹊：“子昆弟三人其孰最善为医？”扁鹊曰：“长兄最善，中兄次之，扁鹊最为下。”魏文王曰：“可得闻邪？”扁鹊曰: “长兄于病视神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于闾。若扁鹊者，镵（chán）血脉，投毒药，副肌肤，闲而名出闻于诸侯。”
所以，APM是事后，性能测试是事前。性能测试是“治未病”，否则APM发现问题也是性能缺陷的逃逸，也会造成不良质量成本。
