前段时间，阿里学习频道组织《性能测试》微课堂，公司里一些多年从事性能测试工作的专家在线答疑解惑，非常好的一种互动模式。其间有同事发问：“性能测试的发展方向是什么？性能对系统的架构和系统的选型起到多少的关键性”。

　　我当时随性而发，也没做过多的思考，大致写了三个看法：

　　领域化：前端性能/客户端性能、后端性能、无线性能，各自本身的技术范畴差异很大，测试方法和分析方法也都大相径庭，所以性能测试会走向领域化

　　去测试化：业务专家、开发、数据库工程师、架构师在更加专业、更加易用的性能测试工具的帮助下自主测试，更加侧重分析

　　流程化：随着参与方的增多，大型公司如何保证性能测试的质量，降低系统风险，需要有更加标准的性能测试流程建立，减少由于评估不足、分析不足带来的性能点遗漏、缺陷遗漏

　　回想起来，觉得对这个话题还是需要补充一些。我从06年开始从事性能工程的工作，当时公司也没有专门从事性能工作的团队，所以我们团队成立之初叫PEL——Performance Engineering Lab，是一个实验室，性能应该怎么做，能够怎么做？去尝试一下吧。经过1年多的摸索，大家八仙过海，各自研究。但终基本上形成了性能模型研究学术派和性能测试调优实践派两大阵营，后来由于性能测试调优立竿见影，疗效确切，慢慢便成为性能工程小组的主要手段。但是通过研究，大家对于系统性能有了更加全面的认识，也了解了什么是排队网络，什么是马尔科夫链。

　　确定了性能工程团队的工作模式，团队名称变成了：PEG——Performance Engineering Group。团队的组织架构则是放在架构部门，此时的架构组主要研究SOA、系统安全和系统性能。性能小组应该算接地气，做了很多性能测试/优化项目。随着名气越来越大，工作也越来越多，后没有办法支持，于是有了矛盾，有了扯皮，有了责任不清。但是也没有办法通过加人来解决这个矛盾：一是因为性能测试/调优需要有非常扎实的技术功底，没有这么多这样的人；二是项目增长的速度肯定是快于人员的扩张和培养的。怎么办？于是大家开始把知识工具化、流程化，给你个方便的Eclipse插件，开发自己去测性能吧；流程上更加重视性能评估，有所为有所不为；培养性能专家组，参与架构评审，代码审查，把性能做到研发流程的前面。让大家都知道，性能是软件的一个必备属性，好的性能不是测出来的，是做出来的。

　　这样做了有风险，也有挑战，对于性能专家组的成员，必须足够和有性能方面的经验。必须要从流程、方法和工具层面给予充足的支持和专注；但是能力和经验从何而来？必须是做项目做出来的，写代码写出来的，操作系统、网络分析里面折腾出来的。所以我们的技能发展通道不能局限在开发团队，测试团队这样的单个团队里面。风险在于如果这种模式没有很好的流程支持，团队之间的良好协作很容易形成割裂，终回归系统性能靠某个或者某几个牛人的状态。性能专家组日趋落寞，趋向于无。

　　所以我对于性能测试发展会有去测试化的想法。性能本事自家事，奈何更名瓦上霜。对自己的架构负责，对自己的设计负责，对自己的代码负责，请从性能测试开始。很庆幸的看到，在淘宝的性能自动化平台上，越来越多的开发、DBA乃至架构师经常通过测试来验证自己的设计、代码，进行调优迭代。这又回归验证了性能是做出来而不是测出来的论点。当然针对这种工作模式，我们更需要从性能测试流程、平台和工具上去做好支撑。质量部门则更应从项目、流程和产出上面去把控整体的研发质量。