开发者需要性能测试告诉他们什么
开发者的需求有很多种，但背后的驱动力总是一致的。如果某段代码需要返工，他们就需要更多的信息来了解当时的情况。这些信息可能来自代码检查工具，也可能来自线程转储，甚至于来自日志。他们可能需要知道与应用程序服务器相比数据库的忙碌程度，或是负载达到峰值时网络的忙碌程度。
预先回答所有这些问题可能并不值得一试，因为这会需要很大工作量。我们能做的是：当问题出现时，弄清哪些信息有助于开发者解决问题，然后把获取这些信息的任务加到你的任务列表上，并告知客户。此时你就可以考虑以下问题：从此刻开始为所有测试获取信息是否容易，这是否针对眼下的特定的问题所做的一次性测试。
如果开发者的需求是以这种方式在会议上提出的，那么，所有人都会知道这些需求的存在。客户可以为这些需求排优先级，可以把它们纳入项目计划。最终性能测试将满足各方的需求：它让客户对正在开发的软件保持信心，它也能帮助开发者找到并解决性能问题。
找不到关注性能的客户怎么办
如果找不到一个关注性能需求的客户，就会有以下风险。首先，正在开发的软件可能不符合业务要求，项目可能彻底失败。其次，不管最终的产品如何，客户都可能说它不符合要求，因为他们感觉开发团队没有征求他们的意见。最后，这可能在团队内部造成紧张气氛。开发团队会觉得自己在被迫做不必要的工作，因为需求不是来自客户-不管项目经理的担心是否正确，这种想法都有可能出现，并导致必要的工作没有被完成。亦或相反，开发者们浪费时间去做不必要的工作。
如果客户不懂技术又非要坚持不可能的需求该怎么办
这种可能性问题存在：客户希望产品的性能达到某个水平，而达到这个水平是不可能或者不经济的。这时你就需要提出一些中肯的问题，把对话引导到真实的业务需求上来，从而打消客户不切实际的要求。
如果客户的要求是关于吞吐量的，可以考虑的问题有：每个工作日处理多少事务？这些事务的时间分布如何？是平均分布还是有明显的峰谷之分？每个周五下午有集中访问，还是说峰值的出现没有特别的模式可循？
关于响应时间表，可以考虑的问题有：用户界面的响应时间会对系统的处理能力造成什么影响？能不能把界面与实际的计算操作分离？比如说，可能有这样一种场景，用户输入一些数据，然后进行较长时间的数据处理。此时用户不希望一直等到处理完成，而是希望立即输入下一段数据。所以这时合理的期望不是在一秒钟内完成数据处理，而是将用户界面与数据处理分离，让系统在后台处理一段数据，同时让用户在界面上输入更多的数据。
通过上述方式，我们就能让开发者与客户共同寻找一个对业务价值有意义的性能水平，并且分清什么是当务之急以及什么是锦上添花。我们都曾遇到下面这种情况：在项目的现有条件下，客户急切希望的某个性能目标不可能达到或是需要付出高昂的代价。如果相关的分析能尽早开展，客户就有可能在更早的时候做出决定，从而使这些目标成为可能。
如果客户期望的目标不能达成，他们会对最终交付的系统感到失望，哪怕系统其实足以满足业务需求。上述这些讨论有两方面的作用，不仅让开发团队了解客户的真实需求，而且让客户自己也有一个清晰的目标。这样一来，只要系统达到了双方认可的目标，客户就会感到满意。有这些讨论作为基础，客户就不太会坚持不切实际的期望；如果他们仍然感到失望，至少那也是出于合理的原因。
何不让业务分析师一并采集这些需求
采集性能需求时不一定需要业务分析师在场，原因有几点。首先，此时功能需求的采集应该已经完成了；其次，即使业务分析师在场，开发者还是不能缺席，因为只有开发者才清楚分析性能问题需要获得哪些信息，也只有他们才能判断获得这些信息的途径和难度。性能测试人员应该提出前面介绍的这些问题，以此推动讨论进行，他们也能够判断每个需求是否容易测试。所以，当这些人坐在一起讨论时，业务分析师就可以把时间花在其他更有价值的地方。
小结
需求采集是为了让所有人都清楚最终交付的产品需要有怎样的性能才能支撑业务目标。之所以要让客户参与，是因为他们最了解自己的业务，这样才能确保采集到的需求足够准确。而且通过讨论也能帮助客户清晰自己对性能的需求，从而有效管理他们对系统的期望。
运行测试
下面我们将简单讨论需要运行哪些测试以及何时运行它们。
运行哪些测试
所有频繁进行的用户操作都应该有对应的测试。这些测试应该记录吞吐量、错误率和响应时间的统计数据。然后你还应该复用这些测试，从而构成更复杂的测试。所有这些测试应该一起执行，尽可能地模拟真实情况，这样你就能从中获悉产品的性能状况。
准备好这些测试以后，就可以在不同的用户量、不同的数据规模下运行它们，观察性能数据的伸缩情况。如果可能的话，还应该在不同的机器数量下进行测试，从而了解硬件能给性能带来多大提升。从这几个方面，你就能获知产品的伸缩能力。
最后，你还应该在超负荷的情况下进行测试，从而找出系统的失败点。还应该在用户分布情况下基本不变的前提下加快用户操作速度进行测试。此外长时间运行性能测试有助于了解系统的可靠性。
