想来想去，这个文章的名字还是叫理性看待性能测试更为妥当。今天在微博上看到有人@到我提到一个关于性能测试的问题，我在回复了之后，感觉意犹未尽。由于微博上打字太费劲了，想说的话还没说完就不让输入了。只能回来自己写一个文章以平复一下想说未说完的憋闷。
我们总是会听到这样的话：性能测试工程师应该会操作系统、数据库、网络、应用、代码等等。这样的话，大部分是从有经验的性能测试所谓的前辈的嘴里说出来，让一些人觉得说这样的话的人牛B而且非常值得膜拜。可气的是没有说明白这个程度到底是什么样的，其实从我个人从业这么多年的角度来看，没有哪一个人可以把这些东西，全都精通到不可一世的程度。要是说完全不知道，那也不太可能，哪个IT行业的人一生不得总是接触这些东西呢。接触并不代表可以掌握和控制它，这种完全不同的视角会在含糊其词之间被无视。所以，我觉得对性能测试工程师，没有必要这么苛刻。要求可以，但是要理智的要求。要求懂操作系统、数据库、网络、应用？没有关系，正常的操作是可以做的，和性能有关的常用的判断手段是可以做的，和性能有关的常用的参数配置是可以知道的。（其他亦如此）。我觉得这样的要求对中级性能测试工程师就可以了。至少可以做大部分的工作了。也许会有人接着问了，高级性能测试工程师又要求什么呢？我觉得：性能测试的思维是高级性能测试工程师必须修炼的内功心法。面对一个未做过的系统，如果出现性能问题，从自己的经验教训中去判断寻找一些蛛丝马迹，配合整体的团队寻找解决问题的方法，这才是要体现出来的价值。
同时，我们还会听到另一种声音：性能测试不就是拿着工具录个脚本，加些用户跑一下就行了吗？于是乎，经常会有一些人提出一些比较苛刻的性能测试需求：很短的时间内出一个性能测试的结果，并且要说出性能瓶颈在哪里。这种性能需求大部分来自于一些对性能测试并不十分了解的人群，但是这部分人群又有足够的能量影响着性能测试的方向。比如说，客户方的某个领导。在这样的情形之下，做为性能测试的行内人，就有引导客户需求、说服客户的职责了。当然，在现在这种利益驱动的市场模式之下，花个大价钱做个完整的性能测试，可能还没有给某些关键人物来点贿赂更为有效。毕竟系统上线就死的也不是很多嘛，哪有那么多的系统都像某订票网站那么悲摧呢。只有实际的损失才能有切肤之痛。
说到性能测试产生的实际的损失，我记得我在一次测试沙龙上说过一句话：在某些感受不到性能测试价值的企业里，性能测试是在谩骂和鄙视中被从踏得满是灰尘的地上捡起来的。在一些实际的利益损失之后，那些各相关部门才会捡起这个大海中救命的木头。可惜的是，这个时候各种动作都是亡羊补牢，损失的再也不会回来。那些被终端用户的嘲笑也被记录在企业的发展历史中。话说，前一阵子，一个金融行业巨头的某系统由于参数配置的问题一上线就死了，幸好产生的社会影响并不大；还有某证券公司的渠道总线因为性能不达标导致停了半个小时，损失了1个亿；还有某互联网公司的系统上线之后，因为数据库承受不了压力而出现了大量的用户失败的现象，等等。这样的情况举不胜举，我都不用众所周知的某订票网站做例子。
不管是在什么样的行业中，我觉得都要正视行业的处境，也需要明白自己的能力在行业中的位置。在自己的岗位上，就要明白自己的职责。我们不应该给性能测试相关的岗位太多的压力，也不应该报有过高的期望。同时，我们也要知道性能测试的岗位能做到什么样的事情。做为一个性能测试工程师，本身就要明白性能测试的工作职责。我看到很多个招聘性能测试职位的要求，有些要求招的不是人，而是神。由于神不多，所以只能抱怨现在这个行业真是整体能力太差了。性能测试的整个过程中确实应该包括完整的性能分析、优化工作，也需要给足够的时间、资源和支持。
一个性能项目，如果想做到完整的性能分析，必须要有其他团队的支持。我们可以定位到一个具体的函数，但是如果我们也把函数改了，是不是更能体现我们强大呢？显然这不符合逻辑。这不是我们该干的事情，除非把开发的工资也发给我们。所以，我的观点是：性能分析是性能测试过程中的一个必然的环节；性能分析需要各个相关团队的支持。当然有些团队可能因为时间比较紧，最后留给系统性能测试的只有一点点可怜的时间。在这样的情况之下，就不要再指望性能测试能带来多大的强心剂了，最多也就是安慰安慰领导或者客户罢了。
还是总结一下：认清楚性能测试职位能做到的事情，明确性能测试工作中需要的支持。不要有无谓的天马行空的论调和不切实际的需求。真正的理性的看待性能测试，才能让性能测试发挥它本应该发挥的也可以发挥的最大的价值。
后记：希望行内人和行外人都给性能测试一个合理的判断。
版权声明：本文出自 Zee 的51Testing软件测试博客：http://www.51testing.com/?17369
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。