本人仍然在做产品和项目的公司部门从事测试，未曾在第三方中工作过，因而软件测试工作不足之处，本人的观点仅限于非第三方测试团队。
在本人的从业经历中，先后涉及过医疗、水利、政府、军队等行业，以个人的经历来看，在非第三方测试团队中，是不存在专职的团队的。这是因为所在公司的性质以及测试工作任务所决定的。因为处在非第三方的测试团队中，其工作任务就是负责公司的产品或项目的质量保证。在日常的工作中，80%以上的工作属于需求剖析和，其实，对于做产品的公司来说，功能测试中还包含；而性能测试工作仅在功能稳定后，才能即将举办，为此，性能测试的工作量仅占日常工作的20%左右。正是因为性能测试工作所占日常工作量的比重不大，所以，公司不可能成立专职的性能测试团队，由于公司不可能让这种性能测试工程师在一年的大部分时间内都闲着。。。
（其实，性能测试应当从就开始，这样就能提早的发觉问题，这也是美国所推崇的。并且，这不符合我国当前的软件测试发展形势。虽然软件测试行业在国外尚属发展早期，如今能组织性能测试工作的公司就早已很不错了，有相当一部份公司都是只要软件不宕机，压根就不会想起性能测试的。）
责怪完当前的形势以后，俺们言归正传。虽然公司不会成立专职的性能测试团队，并且公司却倡导软件测试人员具备性能测试的技能，平常从事功能测试，一旦有性能测试需求，也可以立刻投入。（给的是功能测试工程师的待遇，干的却有性能测试工程师的活。公司还真会算账。。。）
接出来谈一下测试团队应具备的性能测试技能吧。
首先，性能测试的重点是场景设计。这么，测试团队就必须具备需求督查和剖析的能力。有人会说，性能测试指标都是用户给定的，还须要需求督查和剖析能力么？答案是肯定的。由于相当一部份用户所提出的性能测试指标是不可靠的。她们提出的性能测试指标，常常是拍耳朵拍下来的。如：一个业务发生频度不高的系统，但用户数却在4千人，这时侯用户很可能还会要求并发数在4000左右，但实际上没有这么大的业务量软件测试工作不足之处，系统是不须要这么高的并发数的。反之，有的系统虽然用户数不是太多，而且业务发生频度很高，这些系统要求的并发数也不会很低。为此，测试人员必须具备需求督查和剖析的能力，才能引导顾客，得到真实的业务发生频度、发生类型、业务量以及数据量。因而，剖析出系统可能出现性能困局的业务，并进行场景设计；
其次，应具备一定的系统剖析能力。被测软件所用框架、中间件、业务组件、硬件、网络、部署结构等所有诱因，什么地方有可能出现性能困局。这么，它一定在你的测试场景覆盖范围之内。如：一个使用频度不高的业务组件，但因为业务复杂度较高或资源冲突等诱因，很有可能会成为性能困局的。
最后，就是应具备负载生成工具及监控工具的应用能力。虽然，设计的性能测试场景是须要被执行，性能测试执行结果是须要被采集的。
假如早已把握上述的各项能力，这么说明这支团队早已具备中级的性能测试执行能力。接出来，再谈一下更高的要求。
第一，把握硬件的配置及原理。如：F5负载均衡服务器，采用的是哪种均衡策略，这将直接影响到你的性能测试场景的设计及执行的疗效；
第二，把握被测软件所用的常用命令，它可以帮助你启动/关掉操作系统的服务，以及系统资源使用情况；
第三，把握被测软件所用中间件的配置参数及监控方式；
第四，把握必要的开发能力。商业化的测试工具虽然有一定的局限性，很难完全支撑各种性能测试的执行。为此，须要开发必要的负载生成工具、预埋数据脚本、监控工具等；
第五，把握测试结果剖析和调优的能力。测试结果仅仅是采集到还是不够的，还须要剖析系统运行时的资源使用情况，剖析系统性能困局以及是否存在因为性能诱因引起功能性错误等问题。其实，假如才能依据测试结果，给出性能困局的解决方式，这么，这支测试团队就是支高素养的性能测试团队。
以上仅仅是个人的一些观点，不足之处，还望你们见谅。
原帖地址：
版权申明：本文由会员清风随雨首发于51Testing软件测试峰会每周一问活动。
