1.设定职业发展目标
很多人问我这样一个问题：吴老师，我是不是应该把我的职业方向设定为性能测试。我就会告诉他：性能是一个很重要的一个技能我们必须掌握它，但是不建议把它设定为一个职业发展的目标，当然也有朋友会在问:性能这么火为什么不建议我把它做为我的职业发展目标呢？当然听者我也会问：现在测试除了自动化就性能比较火了，如果能够进入到这两个测试圈内，1.身价和地位的提高 2.离大神的阶梯更近了一层，3.测试的荣耀也包含在里面，那为什么吴老不建议做为一个发展目标，我们下面继续听听吴老的看法。
首先我讲一下我对性能测试的一个理解，首先性能测试它相对来说上手是比较容易的，昨天也讲过一个案例，我给一个做开发朋友讲了差不多4个小时的性能，他就基本可以上手去干了，4小时就可以去干的一个活，你说他能够作为你的职业发展目标吗？我觉得这个还是有些短浅，（听者的我会问：4个小时就可以去干性能，那他的悟性是多么高，难道只是使用loadrunner单纯的录制脚本，加压）而且还有一点性能测试会有一些极端。
第一个极端，在小公司里没有性能，为什么呢，总共做的东西也没有多少人用，可能是给国企或者小公司开发的一个软件，不需要性能。或者我做的一个小网站，总共的访问量1天或者2天也还没有到一两万的访问量，这有必要做性能吗？这个肯定也不需要。还有一个就是大公司，大公司做性能机会可能很多，你可能做到一个性能测试组的一个组长或者是一个负责人，但这个团队的一般都会非常的小，为什么这么说呢，做性能本身它不会投入太多的人，可能一个人能顶5个项目，他也能同时做，或者说他能排期一天做一个，性能就是一个熟练工作，它本身那就是讲究很强的一个方法论，也讲究很强的科学实操，但它本身呢，做性能测试并不耗费太多的时间，所以一个人可以顶很多的事儿，那就意味着一件事情，你可以做性能测试工程师，但你想将来在这个方向上去做一个管理层。可能团队没有那么大，可能团队也就2-3个人，根据我的了解，大一点的性能组可能也就七八个人，所以从管理的角度来说没有太大的一个发展。从现在大部分公司来说，我们大部分的这个软件测试都是以做功能测试为主，功能测试完了，可能达到了某个阶段之后才会从事这个性能测试。
这个性能测试也就是说，它是一个阶段性的工作，他不会每天都有，所以如果你真的要长期的去做这个性能测试，我可能觉得大部分的工作都不会太饱满。因为这个事儿不是每天都会有，大公司可能会有，但是这样的公司确实也不太多，而且说实话天天都做性能测试，我觉得蛮无聊的一件事情，因为他就是一个固定的套路，按固定的思维去录制一些脚本设计场景执行然后写报告，基本上这样一个过程。每天做这样一个事儿我觉得太无聊了，所以总体来说了性能测试对大家来说是一个非常重要的一个技能，但是我是不太建议大家把这个技能做成一个长期的职业发展方向，如果说除了性能，其他的都什么不干，自动化不干，手工测试也不干，这个反正我是不太建议，当然这样也要看自己的想法。当然在网上看招聘性能测试的工程师待遇不错，月薪可以1万到2万块钱，这个也确实能给，并没有太大的问题，但是呢我觉得你可以干个事儿，但是不要仅仅把性能这一件事儿，做成你所有测试的发展的一个目标，这个我觉得目标还是有些短浅，可以设定更高一点。
而且目前来说待遇更高的还是 我以前提过测试开发工程师的待遇会更高一点，发展也还是不错的。所以我的建议呢就是:性能测试要会做，但是不作为你长期发展方向，我们可以从事更多的自动化测试的工作或测试开发的工作，这个我觉得结合你的性能测试工作，把性能测试和自动化测试结合，还能带带人做项目，这个是个比较好的发展方向！所以我建议把性能要学会，但是不是做为一个长期目标，这是我的一个意见。
2.性能测试定义
好言归正传，我们先说一下我们为什么要做性能？测试性能测试有哪些分类？我对性能理解那就是，在不同的请求的情况下，要看被测系统整体是一个什么表现。他的工作是否能够符合我们设计和使用的一个预期，这个我们称为性能测试，性能测试也会分很多种，一种呢，称为负载测试，负载测试简单来说，也就看看这个系统能够最大承载一个并发的访问量，还有一个就是压力测试就看看我们在高并发的情况下，在什么情况下这个系统会出现访问的错误，这个是压力测试，还有稳定性测试，也就是7×24小时的长期的运行他们系统会不会出现一些资源的泄漏会不会宕机？是否能够7×24稳定的提供服务，这个是稳定性测试。一般来说我们做性能测试一般就是这3种居多。
但是还有一些其他的性能。如前端性能和后端性能，这也是有区分，我们大家可能就是在前端浏览器的时候我，已经关注了一个叫做前端性能，前端性能简单来说，如我们打开一个页面，页面要加载各种，文字、图片flash等等这些资源，然后也可能会执行一些JavaScript的调用，然后我们会关注每个页面是不是加载的都很快，总体的加载时间是否满足用户的需求，这就是我们的前端性能，或许会看到前端开发人员去使用一个工具叫fiddler或者firebug，这块可以看到每个页面加载的速度，以及每个脚本或者页面的耗时，这块我就知道前端到底哪个资源或者程序执行加载会比较慢，这样我们就可以找到一个前端性能问题，可以着重做一个目标的解决。
然后还有一种就是后端性能，也就是我们说的服务器端的性能测试，这里先说一下手机端的测试，很多人会说手机端的压力测试怎么做，这里让我想到两个点，第一点使用monkey在APP里面做随机的业务，各种做随机操作，这也是一种稳定测试也有人认为他是一种压力测试，这对客户端来说，它测试的是App本身，他对服务器的压力基本没有太多，因为他没有产生一个对服务端的一个请求。所以这块我们要搞清楚我们测试的手机app还是服务器端的后台，这两个完全是分开的。
如果我们想测试的是前端的话，也就是APP，那我们就可以用我们刚刚说的monkey长时间的运行看它是否会出问题，但这个一般来都是功能测试工程师会去做的事情，我们可能关注的是这个服务器端。
如果有很多的并发，大并发的情况登录我们服务器端。就好像双11过,各种秒杀活动，这个经常会考虑服务器是不是能够撑住，这块一般是由后台服务器端进行测试，这一块也是重重之重，因为现在服务端处理能力直接决定你网站的处理速度，决定用户的体验。
有可能年领比较大的朋友或者从业比较长的朋友，可能会记得08年购买奥运会门票，当天都长排着队去买票，结果服务器宕机了，长时间没有工作，当天宣布门票系统，售票网站系统关闭，然后过了很长时间才开始卖票了，然后他也不敢说是大家抢票了，只是说大家可以去申请，申请完了去抽票而且不是当时就出结果所以呢，后来这个系统太扛得住大家这样一个高并发的访问，你想全世界的人去订票知道这也是一个多么让人激动的一个事情，系统可能也就宕机了，很正常。所以性能也非常的重要如果你没有搞定的话可能就会出现各种各样的灾难，刚才说到的我们08的订票系统。现在还有我们，春节必干的这一件事，干什么？刷票，就是去访问12306，这个网站其实我觉得是也可以是中国目前，访问量并发量最大的一个系统，确实技术含量很高，全国人几亿人民买火车票等着回家，而且写各种程序，使用各种浏览器插件，所有人都面对12306这个系统，如果他不能做得很坚固的话，肯定会完蛋。而且现在大家可以看到，现在12306的验证码，也只能用变态来形容，可能每次选择两三回都不一定准确，还是人为选择，这个就说明性能有多重要，如果他不加这些东西的话系统可能被别人刷机，
3.制定性能指标
说这么多我们说下我们到底应该如何设定我们这个性能指标呢？嗯首先我们要设定一个原则就是，我们测试性能实际上在做一些事情，就是要模拟出来所有可能发生的最极端情况，最极端访问情况，这个就是它的意义。就是什么是最极端这个其实是完全靠你来自定义的，一般来说，这个目标那我设定这个性能测试目标，会有几个方式或者说说场景
第一个方式（场景），我先到了一家公司，是一个创业公司，也是从无到有，设计了一个系统，然后呢大家都在一起寻思打算做个性能测试，别一上线，系统就被要压死了，然后大家开会，大家就开始讨论：我们怎么设定这个指标呢，定义这个性测试的结果是ok的或者是这个性能测试成功？大家都开始大眼瞪小眼了，有经验的人可能会说，我作为有经验的产品运营人来说，我知道系统大概有多少人多少活动做推广，然后会有什么运营活动，大概估算一个值，大概一天会有1万个在线用户吧，然后一年在10W的在线就可以了，测试人员听了之后频频点头，测试人员觉得听着好像还是比较合理，1W人在同时在线用户，听着挺合理的，然后我就会问这个问题，这个1W在线是什么概念？是说这1W 个人登录了网站后，就什么也不干了，然后就是1w次登请求，登录完了以后，就对你这个系统有没有压力了呢，那这个你到底该怎么测试呢？那么是不是该模拟一个我用1万个用户需登录了之后什么都不干，这个是否就OK了？是指让这1万个人在系统中保留了一万个session，是否就算就Ok了？这个好像离我刚才说的一个原则就很远，我们刚才说的我在重复一下，就是模拟所有可能发生的最极端访问的情况，你说1万个人登陆这个最极端吗？肯定不是，什么是极端呢，就是1W个用户登录频繁的去访问每个系统的多个页面，对吧，这个我觉得是最极端，但是又回到一个话题，多频繁呢，那么我们到底应该如何设定这个指标呢？其实我认为最重要就是两个指标，可能性能会有很多的辅助指标，什么资源的参考指标，但是真正能衡量系统的就两个指标，第一个指标就是：TPS也就是每秒处理的事务个数了，第二个指标就是每个事务处理的平均耗时，就是average response time，这两个指标是完全可以做为你的性能的一个指标,这个也在我的公开课上讲过，只要把这两个数制定出来就可以了。
嗯其实不管你的后台是什么访问的，其实后台看大的就是一秒钟内有多少用户来访问了或者一分钟内有多少用户来访问，或者说是1小时有多少用户访问，然后访问产生了多少次访问请求，这些请求是在不同的页面也就是看到的这些页面，每次请求花费的时间是多长，比如这个登录的操作到底要耗时多久，这个服务器端也是可以做统计了，所以呢，大家记住了这两个指标就可以了，一个是：TPS 就是每一个事务的处理个数，还有一个：average response time平均每个请求的平均处理时间，这些都是loadrunner里面的一些念法。
对于新的系统我们该怎样设定这样的指标的呢，我建议也别设定指标，就把刚才说的那两个指标验证就好，怎么验证呢，我要测试出来我们新设计的系统到底在系统在最极端的情况下，做一个压力测试，看他在在一个TPS和平均响应时间在多少的时候会出少量错误，在这个时候就是系统的极限了，只要在这个时候我们只要记录TPS和 average response time 就可以了。
然后还要证明一点，就是我们系统是可以做水平扩展的。什么叫水平扩展，就是我通过加机器可以提高系统的并发处理能力，这点是非常重要的，首先我们要知道我们系统极限是多少，当然在测试这个极限呢你可以让开发不断的去进行优化，直到开发说我已经优化不了了，达到了优化的顶点了，那么就可以把这个数字下来。另外还要强调的是，为什么要做水平扩展，因为你也不知道这个系统到底应该在半年或者一年后的还能支持多少人并发去访问，你也不知道，虽然可能有经验的技术总监和产品总监，运营总监会在总结大会并总结给一个具体的数字，但是真正，你觉得他说的数靠谱吗，这个数肯定也不靠谱，因为大家都不知道了业务量一年后会怎么样？这个谁也不知道，只能看运气，做到好还是不好，但是我们要做的是一定要验证它是否支持水平扩展，通过加机器改善我们的性能，为什么这么说呢，万一到了极限怎么办？至少可以通过加机器，提到系统处理能力，这个是很有必要的，因为如果你这样是做不了，有些系统并不能做水平扩展，通过有些加机器就以后性能没有提升反而下降了，这种也是有可能的，所以就是我们测试到是否达到了系统的处理的极限，还有一点，证明他是可以水平扩展的，就是简单的操作过程当中我通过加机器1秒钟可以处理100，通过加机器1秒钟处理150或者200，这个都是一个好的现象，但是不同压力下，你的瓶颈也会发生一些变化，可能加了机器CPU没有问题了，但是突然发现别的地方出现瓶颈，这种也是有可能的，所以我们需要做增加多台机器的测试，这样一个水平扩展的的方式，针对一个新系统来说，能达到这样一个目标，我觉得就没有问题了。
还有一种就是对于老系统，如果对运行一年多的老系统来说，然后突然说我们提高性能处理能力？然后重新给架构做了一个设计做了一个优化，然后这个怎么测试，简单来说，就是把你一年前记录的指标全部拿出来，然后现在有做了一些新的，基于新的架构做测试，然后两个数据做对比，只要证明你的新系统比老系统更强，至于强多少只有自己看，只有自己看，我觉得能够提高40%或者50%或者提高更高的这样TPS处理能力我觉得就可以了，这个就是一个基本的方式。
还有一个是敏捷开发中的一种方式，敏捷也是在业内比较流行，敏捷有时候也没有一个好的目标，它做的指标也是这样，就是说每个小周期进行迭代的时候，会出一个性能指标，然后每次迭代都会做性能测，然后会对比，这次不比上次的性能差，这个也算通过了，这个是敏捷开发里面中性能测试的一个原则，所以呢，这个就是刚才我说到的几种的这种性能测试的指标，希望对大家有帮助。
简单总结下：我们测试要选择一个合适的发展方向，我不建议把性能测试做为你的职业发展方向，我建议还是测试开发，当然性能还是一个很重要的技能，你至少能够承担性能测试的工作，但是不要把它作为所有测工作的一个选择，还是要多做一些自动化，和测试开发的事情，然后设计这个性能的时候，要分前端性能和后端性能，而且还有多个性能测试种类，压力测试、负载测试、还有稳定测试，我们设立这个指标的时候呢有一个原则就是我们要模拟所有可能发生的极端情况，其中的两个指标是核心的，一个是TPS每秒的处理事务，和avage respone time ，这个平均每秒事务处理时间，这两个指标在新系统中能够测试出一个极限，我觉得也是ok的。并且系统支持水平扩展我觉得就ok了，通过加机器可以提高性能，这个就算结束任务了，就是在老的系统做优化，就是把新的系统结果和老的系统结果进行对比，证明没有问题，新系统也就是ok，如果是敏捷开发，在小周期内都有一些结果，然后不断去做优化，每次数据做比对，只要现在数据比以前的还要好，我觉得就可以了，一般性能测试在敏捷测试开发是这样做的。