《软件开发沉思录》之实用主义性能测试

关键字： 性能测试 , 流程 , 需求 , 沟通

 

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

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

1.需求采集

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

@要度量什么

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

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

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

@如何设定目标

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

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

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

2.运行测试

@运行哪些测试

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

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

超负荷以及稳定性测试

@何处运行测试

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

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

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

@如何处理第三方接口

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

@多次度量响应时间和吞吐量

需要得到系统最大吞吐量，最佳响应时间、当响应时间正好符合要求时的负载量以及负载达到事先测量的最大吞吐量的 80%和 90%时的响应时间等信息

@有必要测试所有功能吗

对系统的所有功能进行测试基本上是不现实的。重点在于要覆盖最常用的功能。 所以你需要识别出系统的主要使用场景,并针对这些场景创建不同的测试。 

比如说,在线购物网站最主要的使用模式应该是“浏览”和“购买”。来购物的人不全会浏览很多页面,浏览的时间通常也不都会太长。所以 你需要创建一个“浏览”的测试脚本和一个“购买”的测试脚本。为了让测试脚本更贴近真实 ,你需要知道用户浏览商品的平均数量、每次购买的平均商品数以及正常情况下一天时间内被浏览过的商品数占商品总数的百分比。

3.沟通

需要做的就测试结果进行沟通。

根据讨论出的性能需求和目前的性能水平来解读测试结果。

@指出系统性能与目标的接近程度(与目标的差距有多少,或是超出目标多少)

@说明产品的性能是否发生了重大变化。

@各个关键点时各种系统资源的使用情况

不同的人会对不同的信息感兴趣（客户，项目经理，开发者）。建议用一个网站向所有人展示最新的性能测试结果。

4.流程

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

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

@如何把各种工作连接起来

每周循环工作：1.每周开始时开会，讨论正在开发的功能的性能需求，介绍测试计划;2.编写新功能对应的脚本，维护已有脚本，执行测试；3.每周结束时开会，展示本周成果：脚本，测试结果等并进行讨论

@如何确保不拖后腿

1.确定任务列表；2.确定优先级；3.时间确实紧张时按照前面2点来减少任务量(高难度，低优先级)或者增加人手

5.总结

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