沟通

　　就测试的结果进行沟通是很重要的。所以接下来的问题是，我们究竟在沟通些什么？所谓就测试结果进行沟通，可不止是报告几个数据那么简单。如果你这样做的话，团队里的所有人在身担其他任务的情况下都得花时间来分析这些结果数据。如果先对测试结果做一些基本的分析和解读，并给出一段概述，其他人理解起来就会容易得多。

　　所以你需要根据讨论出的性能需求和目前的性能水平来解读测试结果。首先，你需要指出系统性能与目标的接近程度（与目标的差距有多少，或是超出目标多少）。其次，你需要说明产品的性能是否发生了重大变化。不管这种变化是否导致产品无法达到性能目标，都应该将相关的信息告知所有相关人员。引起这种变化的原因可能是新增了一大块功能，这时对产品性能的影响是不可避免的，几乎没有能够改进的空间。但也可能是因为别的小问题，例如数据库缺少了某些索引，这样的问题应该很容易解决。

　　谁需要知道测试结果

　　有三组人需要了解测试结果：开发者、项目经理和客户。开发者和项目经理应该在测试运行完毕之后立即知道结果，这样他们就能在问题出现之初尽快合理地将问题解决。另一方面，没必要每天都拿一些小问题去打扰客户，否则当你说到真正重要的问题时他们就不会全神贯注；但也不应该疏忽与客户的交流。你可以每周安排一次会议，定期把性能测试的结果通报给客户。

　　此外，要记住不同的人会对不同的信息感兴趣。客户和项目经理可能希望看到比较高层面的概述，而开发者则对原始数据（以及给定时间内的响应数量等内容更感兴趣。如果能把适当的信息提供给不同的人，就能更有效地沟通产品的状态。）

　　是否只需要写一份报告

　　不完全是。你当然可以写一份报告，然后用邮件发给所有人，但问题是大部分人很可能不会看这个报告，于是你想要传达的信息也就丢失了。报告只是一种用来帮助你传送信息的工具，而不是你的最终目的。

　　用一个网站向所有人展示最新的性能测试结果是很实用的。然后你走到某个人的座位跟前讨论性能测试结果时，你就可以打开这个网站，把你发现的情况指给他看。不幸的是，大多数并不善于看测试护报告，所以为了确保你的信息能够传达到位，唯一的办法就是走到别人的座位旁边，或是拿起电话，向别人解释整个测试报告。

　　小结

　　你的目标是建立这样一种沟通机制：由于性能需求已经很清楚，因此无须拿着每次测试的结果去问客户是否可以接受，在每周介绍项目的当前性能状态时，你只需指出测试结果中的异常之处，并向客户解释异常情况出现的原因；如果某个区域的性能特别差，但经过判断这不是一个严重的问题，你就应该告诉客户为什么这块性能比较慢，为什么项目经理认为这不是一个高优先级的问题；如果该客户不同意这个决定，那么项目经理和客户就应该坐下来具体讨论当前的情况。

　　流程

　　性能测试经常放在项目结束前进行，这种安排严重影响了性能测试的效果。性能测试中最重要的事就是要定期进行测试。如果直到项目最后几周才做性能测试，那么你将有很多事情要做，而时间却非常紧迫。大部分时间会被用于编写测试脚本，并得到一些和产品有关的数据。这时你就会处于一种不好的境地，你大概知道系统运行运行得多快，但基本无从知道它是否足够快，而且也没有时间做任何改进。

　　当第一段代码被编写出来，性能测试就应该开始了。虽然这里可能还没有任何可供测试的东西，但还是有很多事可以去做。你可以向开发者了解他们将要使用的技术，评估合适的工具，找出功能足以测试当前产品的工具。此外还需要识别出关注性能的客户，并且与他们一起启动需求采集的流程。

　　如何把各种工作连接起来

　　从这个阶段起，你的工作就开始进入一个循环。每周开始时，你会第一时间与关注性能的客户开会，讨论当前正在开发的功能的性能需求，同时介绍你的测试计划，以及如何展示需求得到了满足。客户也可以在这时要求更多的测试。剩下的几天内，你可以为最近完成的功能编写性能测试，维持已有的自动化测试，以及查看测试结果。一周将要结束时，你再次和关注性能的客户开会。这个会议有两项任务：首先是向客户展示本周编写的性能测试，并和客户讨论这些新的测试是否能表示产品满足早先提出的性能需求；其次是与客户一起查看现有性能测试的最新结果。

　　如何确保不拖后腿

　　只要按照这个每周的循环在工作，一旦性能测试的进度滞后，你很快就能清楚地看到。这里要想赶上进度，你可以增加用于性能测试的资源，也可以减少工作量。至于具体怎么做，很大程度取决于性能需求对于项目有多重要。

　　你可建立一个任务列表，将本周与客户所决定执行的测试任务都写在上面。然后你就可以与客户一起对这些测试排定优先级。每周你尽量完成列表上的任务。如果这样做下来导致测试覆盖率很成问题，那可能你需要投入更多人手来做性能测试；但也有可能在扔掉一些高难度、低优先级的测试之后，你完全能够保证足够的测试覆盖率，而又不会拖项目后腿。

　　如何确保每个问题得到解决

　　必须在项目开始之初就和项目经理沟通，决定如何修复性能问题。你需要确保项目经理认同你的工作方式和你采集到的性能需求；你还要确保项目经理同意将性能问题作为bug提出，并且一旦性能问题出现就会有所行动，否则你就只能在项目结束时对着一大堆已知的性能问题徒呼奈何了。毕竟，如果性能问题出现之后不采取措施去解决，那么即使测出当前的性能水平也是毫无意义的。

　　总结

　　这个流程最大的好处在于它能确保你知道自己手上有什么，需要什么，而且你能肯定系统的每个部分都有测试覆盖，从而大大增加了发现问题解决问题的机会。让性能测试与开发同步，对每个功能都有测试覆盖，这样如果性能出了问题你就有时间应对。有一份性能需求在手上，你就能判断当前的系统是否需要改变。这份需求是客户根据业务流程和规模制订的，所以整个团队都对它有信心，大家也会乐于花时间来解决性能问题，因为他们知道这是一件有价值的工作。