Board logo

标题: 软件性能测试参数测量了什么 [打印本页]

作者: look_w    时间: 2017-10-19 14:50     标题: 软件性能测试参数测量了什么

性能测试参数测量了什么

参数需要理解性能测试的质量和效果。除非有测量,否则无法提高。现在解释下2种定义:
有许多方法可以测量速度、可扩展性和稳定性,但是每轮性能测试无法使用全部方法。在性能测试中所用的参数,下面的是经常用到的:

响应时间
发送一个请求和获得一个响应的总时间。

等待时间
这也称为平均延迟,这告诉开发人员在发送请求后接收第一个字节需要多长时间。

平均加载时间
从用户的角度来看,交付每个请求所需的平均时间是质量的主要指标。

峰值响应时间
这是完成请求所需的最长时间的测量。峰值响应时间明显长于平均时间,这可能表明出现问题的异常情况。

错误率
这是一个与所有请求相比,计算产生错误的请求的百分比。这些错误通常发生在负载超过容量的时候。

并发用户
这是最常见的负载测量——在任意时刻有多少活跃用户,也称为负载大小。

每秒请求
多少请求被处理。

事务通过/失败
对成功或不成功请求的总数的测量。

吞吐量
以千字节每秒的速度度量,吞吐量显示测试期间使用的带宽量。

CPU利用率
CPU需要多少时间来处理请求。

内存利用率
需要多少内存来处理请求。


性能测试最佳实践

也许性能测试最重要的小建议就是早测试,常测试。一个单独的测试将无法告诉开发人员他们所需知道的全部。成功的性能测试是许多的反复测试和小测试组成的。




除了反复测试,通过一系列性能测试的最佳实践,性能测试将会更加成功。


5个性能测试常犯的错误



还有一些错误会导致性能测试时不太可靠的结果:


性能测试错误理论


性能测试的错误理论可能导致错误或遵循性能测试最佳实践的失败。根据Sofia Palamarchuk的说法,这些理念在开发软件时可能会耗费大量金钱和资源:


性能测试是开发的最后一步
在前面性能测试最佳实践部分中提到过,预期和解决性能测试问题应该是软件开发的早期部分。尽早执行解决方案将比软件开发结束时的主要修复成本要低。

硬件越多就能解决性能问题
增加处理器、服务器或内存,简单的增加成本,不解决任何问题。更多有效的软件可以在硬件增加或改善时更好的运行和避免潜在的问题。

测试环境“非常接近”
在一个类似于生产环境的测试环境中进行性能测试,是一个性能测试的最佳实践。这些元素之间的差异可以显著地影响系统性能。在精确的生产环境中进行性能测试可能是不可能的,但是尝试匹配:


现在什么有用,就全面的起作用
对于推算出的结果要小心。不要采用小的性能测试结果,并且假设当元素发生变化时,它们将是相同的。而且,它们是在对立面工作的。不要根据负载测试来推断最小的性能和需求。所有的假设都应该通过性能测试来验证。


一个性能测试方案就够了
不是每个性能问题都可以在一个性能测试方案中检测到。但是资源确实限制了可能发生的测试数量。在中间的是一系列性能测试,它们针对的是风险最高的情况,对性能会产生最大的影响。此外,问题可能出现在设计良好之外和设计良好的性能测试。监视生产环境也可以检测性能问题。

测试了每个部分等于测试了全部系统
虽然隔离功能用于性能测试是很重要的,但是单独的组件测试结果并不会添加到整个系统范围的评估中。但是,测试一个系统的所有功能可能是不可行的。一个完全可能的性能测试必须使用可用的资源来设计。但是要注意没有测试过的东西。

是什么对他们有用,对我们有用
如果一组用户确实遇到了复杂的问题或性能问题,那么不要认为这是对所有用户的性能测试。使用性能测试来确保平台和配置如预期的那样工作。

软件开发人员经验丰富,不需要性能测试
缺乏经验并不是造成性能问题的唯一原因。即使是过去开发过免费软件的开发人员也犯了错误。特别是当多个并发用户在系统中时,更多的变量开始发挥作用。

一个完整的加载测试说明了一切
在总负载中运行一个测试来发现所有性能问题是很吸引人的。除了这种测试,它往往会暴露出许多性能问题,以至于很难将注意力集中在单个解决方案上。从较低的负载开始,逐步向上扩展可能看起来是一个不必要的缓慢过程,但是它会产生更容易的结果,从而更有效地排除故障。

测试脚本是实际的用户
确保测试自动化正在以真实用户的方式使用该软件。当性能测试参数被更改时,这一点尤为重要。




欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/) Powered by Discuz! 7.0.0