学习了《软件开发沉思录》中的实用主义性能测试，对重点内容做下记录：

　　性能测试应该囊括确保产品性能符合要求所需的一切行动。这里有四个关键点:需求、产品性能数据、沟通和流程。

　　1.需求采集

　　需求采集中的几个重要问题:要度量什么?如何知道我们需要什么?以及如何得到确实有用(而非帮倒忙)的数据?

　　要度量什么

　　重要的性能度量点有两个，大吞吐量以及给定吞吐量下的响应时间。一个好的做法是:分别度量几种不同吞吐量下的响应时间，从中分析负载对响应时间的影响。

　　需要通过度量找出两项数据:当响应时间恰好可以接受时的吞吐量，以及达到预期吞吐量时的响应时间。伸缩性度量的关键则在于:随着数据规模、用户数量或者运行系统的硬件变化，起初得到的性能度量数据会发生怎样的变化。

　　可靠性的关键度量点是:当负载量高得超乎寻常，或者连续运行了很长时间以后，系统是否仍然正常工作。

　　如何设定目标

　　要想知道系统需要达到怎样的吞吐量，你首先需要知道有多少用户会使用这个系统，以及他们的使用模式。用户会多频繁地使用某个功能?这个功能需要多快完成?

　　需要有一个可靠的沟通流程与机制来获得所需的信息，及时获知支撑业务需求所需的性能指标。

　　总之：需求采集是为了让所有人都清楚终交付的产品需要有怎样的性能才能支撑业务目标。之所以要让客户参与，是因为他们了解自己的业务，这样才能确保采集到的需求足够准确。而且通过讨论也能帮助客户清晰自己对性能的需求，从而有效管理他们对系统的期望。

　　2.运行测试

　　运行哪些测试

　　单场景和混合场景：所有频繁进行的用户操作都应该有对应的测试。这些测试应该记录吞吐量、错误率和响应时间的统计数据。然后你还应该复用这些测试，从而构建更复杂的测试。所有这些测试应该一起执行，尽可能地模拟真实情况，这样你能从中获悉产品的性能状况。

　　考虑伸缩性：在不同的用户量、不同的数据规模下运行它们，观察性能数据的伸缩情况。如果可能的话，还应该在不同的机器数量下进行测试，从而了解增加硬件能给性能带来多大提升。从这几方面，你能获知产品的伸缩能力。

　　超负荷以及稳定性测试

　　何处运行测试

　　如果可能的话，应该尽量让性能测试环境模拟真实的生产环境。如果生产环境太过庞大而无法整体模拟，那么应该让性能测试环境模拟生产环境的一个部分，然后将真实的性能需求等比压缩到性能测试环境的水平。(包括软硬件环境)

　　应该用多大规模的数据库来做性能测试

　　应该先与关注性能的客户交流，争取拿到一份生产数据库的副本，这样可以针对它来进行测试。尽量模拟线上环境(包括数据量，索引等等)。另外，还应该与客户探讨数据规模发生变化的可能性。

　　如何处理第三方接口

　　如果系统用到很多第三方接口，性能测试好不要直接去使用这些第三方系统。原因有两点:首先，第三方系统可能并不适合成为性能测试的一部分;其次，即便第三方系统提供了测试环境，依赖你无法控制的第三方系统会降低测试的可靠性。好的办法是用一个单独的测试来获知第三方系统的平均响应时间，然后为它写一个 mock或者 stub，直接等待那么长的一段时间然后返回一个固定的响应。