学习了《软件开发沉思录》中的实用主义性能测试，对重点内容作下记录：数据库
性能测试应该囊括确保产品性能符合要求所需的一切行动。这里有四个关键点:需求、产品性能数据、沟通和流程。工具
1.需求采集性能
需求采集中的几个重要问题:要度量什么?如何知道咱们须要什么?以及如何获得确实有用(而非帮倒忙)的数据?学习
@要度量什么测试
最重要的性能度量点有两个,最大吞吐量以及给定吞吐量下的响应时间。一个好的作法是:分别度量几种不一样吞吐量下的响应时间,从中分析负载对响应时间的影响。网站
须要经过度量找出两项数据:当响应时间刚好能够接受时的吞吐量,以及达到预期吞吐量时的响应时间。伸缩性度量的关键则在于:随着数据规模、用户数量或者运行系统的硬件变化,起初获得的性能度量数据会发生怎样的变化。spa
可靠性的关键度量点是:当负载量高得超乎寻常,或者连续运行了很长时间之后,系统是否仍然正常工做。索引
@如何设定目标接口
要想知道系统须要达到怎样的吞吐量,你首先须要知道有多少用户会使用这个系统,以及他们的使用模式。用户会多频繁地使用某个功能?这个功能须要多快完成?资源
须要有一个可靠的沟通流程与机制来得到所需的信息,及时获知支撑业务需求所需的性能指标。
总之：需求采集是为了让全部人都清楚最终交付的产品须要有怎样的性能才能支撑业务目标。之因此要让客户参与,是由于他们最了解本身的业务,这样才能确保采集到的需求足够准确。并且经过讨论也能帮助客户清晰本身对性能的需求,从而有效管理他们对系统的指望。
2.运行测试
@运行哪些测试
单场景和混合场景：全部频繁进行的用户操做都应该有对应的测试。这些测试应该记录吞吐量、错误率和响应时间的统计数据。而后你还应该复用这些测试,从而构建更复杂的测试。全部这些测试应该一块儿执行,尽量地模拟真实状况,这样你就能从中获悉产品的性能情况。
考虑伸缩性：在不一样的用户量、不一样的数据规模下运行它们,观察性能数据的伸缩状况。若是可能的话,还应该在不一样的机器数量下进行测试,从而了解增长硬件能给性能带来多大提高。从这几方面,你就能获知产品的伸缩能力。
超负荷以及稳定性测试
@何处运行测试
若是可能的话,应该尽可能让性能测试环境模拟真实的生产环境。若是生产环境太过庞大而没法总体模拟,那么就应该让性能测试环境模拟生产环境的一个部分,而后将真实的性能需求等比压缩到性能测试环境的水平。(包括软硬件环境)
@应该用多大规模的数据库来作性能测试
应该先与关注性能的客户交流,争取拿到一份生产数据库的副本,这样就能够针对它来进行测试。尽可能模拟线上环境(包括数据量，索引等等)。另外，还应该与客户探讨数据规模发生变化的可能性。
@如何处理第三方接口
若是系统用到不少第三方接口,性能测试最好不要直接去使用这些第三方系统。缘由有两点:首先,第三方系统可能并不适合成为性能测试的一部分;其次,即使第三方系统提供了测试环境,依赖你没法控制的第三方系统会下降测试的可靠性。最好的办法是用一个单独的测试来获知第三方系统的平均响应时间,而后为它写一个 mock或者 stub,直接等待那么长的一段时间而后返回一个固定的响应。
@屡次度量响应时间和吞吐量
须要获得系统最大吞吐量，最佳响应时间、当响应时间正好符合要求时的负载量以及负载达到事先测量的最大吞吐量的 80%和 90%时的响应时间等信息
@有必要测试全部功能吗
对系统的全部功能进行测试基本上是不现实的。重点在于要覆盖最经常使用的功能。 因此你须要识别出系统的主要使用场景,并针对这些场景建立不一样的测试。
好比说,在线购物网站最主要的使用模式应该是“浏览”和“购买”。来购物的人不全会浏览不少页面,浏览的时间一般也不都会太长。因此 你须要建立一个“浏览”的测试脚本和一个“购买”的测试脚本。为了让测试脚本更贴近真实 ,你须要知道用户浏览商品的平均数量、每次购买的平均商品数以及正常状况下一天时间内被浏览过的商品数占商品总数的百分比。
3.沟通
须要作的就测试结果进行沟通。
根据讨论出的性能需求和目前的性能水平来解读测试结果。
@指出系统性能与目标的接近程度(与目标的差距有多少,或是超出目标多少)
@说明产品的性能是否发生了重大变化。
@各个关键点时各类系统资源的使用状况
不一样的人会对不一样的信息感兴趣（客户，项目经理，开发者）。建议用一个网站向全部人展现最新的性能测试结果。
4.流程
性能测试常常被放在项目结束前进行,这种安排严重影响了性能测试的效果。性能测试中最重要的事就是要按期地进行测试。若是直到项目最后几周才作性能测试,那么你将有不少事要干,而时间却很是紧迫。大部分时间会被用于编写测试脚本,并获得一些和产品有关的数据。这时你就会处于一种尴尬的境地,你大概知道系统运行得多快,但基本无从知道它是否足够快,并且也没有时间作任何改进。
当第一段代码被编写出来,性能测试就应该开始了。虽然这时可能尚未任何可供测试的东西,但仍是有不少事能够去作。你能够向开发者了解他们将要使用的技术,评估合适的工具,找出功能足以测试当前产品的工具。此外还须要识别出关注性能的客户,而且与他们一块儿启动需求采集的流程。
@如何把各类工做链接起来
每周循环工做：1.每周开始时开会，讨论正在开发的功能的性能需求，介绍测试计划;2.编写新功能对应的脚本，维护已有脚本，执行测试；3.每周结束时开会，展现本周成果：脚本，测试结果等并进行讨论
@如何确保不拖后腿
1.肯定任务列表；2.肯定优先级；3.时间确实紧张时按照前面2点来减小任务量(高难度，低优先级)或者增长人手
5.总结
这个流程最大的好处在于它能确保你知道本身手上有什么、须要什么,并且你能确定系统的每一个部分都有测试覆盖,从而大大增长了发现问题解决问题的机会。让性能测试与开发同步,对每一个功能都有测试覆盖,这样若是性能出了问题你就有时间应对。有一份性能需求在手上,你就能判断当前的系统是否须要改变。这份需求是客户根据业务流程和规模制订的,因此整个团队都对它有信心,你们也会乐于花时间来解决性能问题,由于他们知道这是一件有价值的工做。