高级性能测试（翻译）

高性能测试

测试主管和经理们，让你的性能测试团队走出困境，立于不败之地！

介绍

作为一项工作，性能测试被人们，尤其是那些测试主管和经理们的普遍误解。这种误解会带来很多麻烦——包括项目彻底的失败。本文详细的谈一谈我在给那些测试主管和经理们上课时一遍又一遍谈到的话题。学习，理解，并将这些知识应用于你的性能测试项目中，会让你很快的走向成功！

重视经验

经验丰富的性能测试员会用你能听得懂的话，指导你实现你的目标，即使你还无法描述那些目标。经验丰富的性能测试员不仅知道如何用商业危机，短、长期成本以及计划变动的影响等术语和测试主管打交道，他们更知道如何避免用行话，和技术语言解释自己的工作。经验丰富的测试员习惯于解释最新的“ performance buzz ”与你的系统的相关性。他们花了几年的时间从一些孤立起来毫无意义的单词，比如：“快速”，“最大吞吐量”，“ *** 同时在线用户”，提取测试目标。看一下这个例子：某个测试主管要求，“每一页都要百分之百的在 * 秒内显示。”虽然这是可以量化和测试的，但是这句话本身没什么意义。性能测试员的工作就是确定目标应用在什么样的环境下，换句话说，就是确定目标的所属的环境。为了使目标有意义，它必须注明诸如用户连接速度，登陆到网站的用户有多少，以及这些用户在从事什么样的活动等。这些都是影响网页反应速度的变量。一个完整一些的测试目标应该用这种格式写：

在“ peak order ”工作量模式下，在每小时 500 用户量负载的情况下，静态网页反应时间在 * 秒内，动态网页的反应时间在 ** 秒内，而搜索、排序的网页会在 ** 秒内，当通过企业局域网登陆时百分之 95 的时间是不出错误的。

另外，经验丰富的性能测试员知道如何收集数据，并且会用以这种方式：“系统是否达到目标，在那些方面达到或偏离目标，偏离多少”，向那些观察者说明。而且不要求这些观察者掌握多少关于被测系统的专门的技术知识。

注意，在谈到性能测试时我用了“目标”并非“需求” 一词。我之所以这么做是因为，我从来没有经历过因为测试结果未能达到设定的要求而被迫延迟或取消发布的性能测试项目。我选择“目标”一词的另一个原因是实际上在新版本发布之前没人期望它的性能和想象中的一样优秀，人们只是希望“现在够好”就行了。有人认为性能会在测试中得到优化，开发环境会解决测试环境中发现的性能问题，或者说当性能问题随着开发过程出现时，采纳上述方法可以很好的解决这些问题。一位经验丰富的性能测试员会帮助把你对性能测试的感觉转换成目标和项目计划。总之，作为一名测试主管，性能测试员要求你领会理解性能测试，这样你才能做出明智、有见地的决定。作为一名测试主管你要在程序处于开发周期时做出很多重要决策，大部分决策围绕一下三个基本问题：

     1 它为什么目的而开发，能否满足需求？

     2 对系统用户来说，程序功能是否足够？

     3 系统用户能否轻松试用此程序？

有经验的性能测试员知道这三个问题的重要性，并且知道如何回答，他们会和你并肩工作（有时的确是在你旁边），帮助你用性能测试的术语回答以上问题。

首先也是最重要的就是你要让人知道你期望有经验的性能测试员在项目里做什么，而并非人们称呼他们的“拿着工具的傻瓜”。尽早的设定你的期望，这样性能测试员才会和你互动，给你提供足够的信息，让你对性能问题和风险做出明智的决策。无论何时，都要对性能目标有个人的看法，保证有个完整的环境使此目标对于领导层做出决策有意义。

审查性能测试计划和交付产品，然后问自己一下几个问题：

1 这有助于决策吗？

2 此计划的结果是否会给终端客户带来全新的体验

  3 是否能代表真实的生产环境

  4 如果需要调整，对开发人员来说是否依然有用

  5 是否为每一个专门的需求、目标、或者服务等级协议提供相应的解决办法

  6 是否是基于计划的结果而采取行动

 

最后，邀请性能测试员在工作中不断指导你。在帮助你增加对性能测试的了解的同时，测试人员自己也会非常清楚的知道在系统性能上，对你来说最重要的是什么。这种相互的理解和开放的交流是对系统综合测试最有益的事情。

 

在功能完全实现之前进行性能测试

人们对性能测试有个普遍的认识，那就是在软件稳定，大部分功能实现之前，进行性能测试是没有效果的，测试版或正式版发布之前是无法收集测试数据的。实际上这样做的话，一旦产品性能没有预想的那样好的话，我们是没有时间对此做出任何反应。

实际上，早在功能测试团队接到第一份测试版本之前，有经验的性能测试员就能完成大量测试任务，并且生成大量测试数据了。他会争得用户社区模式的同意，测试数据，并且能够收集一下类型的数据：

       1 网络或网路服务器的吞吐量的限制

       2 各种负载下，单个服务器的资源利用情况

       3 搜索速度，查询最佳化，表格 / 行锁，以及数据库容量测试速度

       4 负载平衡总量，容积，效力

       5 安全措施的速度和搜索成本

有些开发人员的系统构建师认为，大部分的任务都要由他们完成。但是实际上，开发人员很少又能生成足够多的，能够有效的完成任务的负载。尽早的投入性能测试人员能够最小化惊讶（？），并且提供大量数据，从而大大提高查找根本原因的速度，并且尽快修复日后在项目周期中发现的性能缺陷。

这一点是显而易见的。要配置一个性能测试工程师贯穿项目的始终。鼓励开发团队利用测试人员的技术和资源，并作为自己的开发工具，而不仅仅是一个开发完成后的验证工具。有一点不再赘述，在项目中，要让性能测试人员在百分之 50 到百分之百的时间里从事性能相关的活动。因为技术素质已经在边栏“技术与经验”里注明，所以此人可以作为一名辅助人员被每一个实际项目团队充分利用。这里有个警告：要清楚的知道，性能测试是此人的主要责任，而并非附加义务。二者严格区别，因为当性能测试到了关键时刻的时候，和测试工程师一起工作的其他团队也到了与紧要的关头。

 

不要混淆“交付”和“完成”

“交付”只是给予风险做出的合乎实际情况的决策，它不应该与“完成”混淆。每一个参与过一段时间测试的人都知道当主管觉得延迟发布比发布风险大时，就要配置系统，即使这意味着发布一款存在未解决或者没测试到的性能缺陷。然而，发布这款软件根本不会影响性能测试。

很多软件都有个实施图和接受率，这些保证负载的峰值在发布之后在很长一段时间内不会出现。那是做性能测试的黄金时间：很少被打断，数据都是实际用户产生的而并非是预计或估算的，还能够监控软件在实际硬件上运行时的性能，一般都会或得更多的资源。如果在用户达到性能极限的时候还没有计划发布维护版本来修复以前的版本，那么马上起草一份这样的计划比起不断修复出现的性能缺陷来成本效率更高。

计划在原始版本发布后继续性能测试，计划在第一次预期的负载高峰前推出性能加强的维护版，把这些计划从一开始就合并到项目中，能够让你发布的后期版本时，用户感觉早期的版本性能还不错。这要好过直到性能调整到能够应付更大的负载时才发布新版本。

 

寻找技术和经验

“性能测试员在项目团队中在技术和经验的宽度和广度上最有资历”。可能你以前读到过这句话，但是我保证这并非是新瓶装老酒，当我被问到“我需要什么技术水平的测试员？”时，我回答说，“你想要的就是那些什么技术都是中等水平的测试员。”“技术和经验”侧栏列出了性能测试员必备的专业技术。这就成了一个求职咨询和自身技术培训的问题了。据我的经验，我觉得，一个顶级的性能测试员应该能够回答面试人员经常问那些中等水平的开发人员，数据库管理员，系统管理员们的问题。显然，并非功能测试人员的标准，例如，当面试一名应聘功能测试员的人时，可能会问到“让你直接与代码打交道，你感觉能行吗？”，当面试一名应聘性能测试员的人时，完全可以这么问“哪个是你用代码写的最复杂的自定义功能，并且能使你的负载生成脚本确切的模拟现实使用场景？是什么让这个功能这么复杂？你先在还有这些编码吗？你能否轻松的重新再写一遍呢？”

 

技术和经验

性能测试要求一种独特的技术素质，这种素质远高于对功能测试团队人员的要求，很多时候也比开发团队人员要求的更宽。除了要求对他们自身所选择的工具的掌握，我特别看重以下经验和技术（粗略的按照由重到轻的顺序排列如下）：

       1 用户社区的建模和虚拟

       2 被测系统的通信协议

       3 网络搭建

       4 数据统计

       5 图解复杂信息

       6 程序开发，比如问“如果就在晚间备份开始前，我做 X 的同时别人做 Y 而且还有 20 个人做 Z ，那会怎么样？”

       7 可靠，稳定，安全测试

       8 系统监控，和管理

       9 功能测试

       10 作为一个培训者和帮手很有经验