应用程序性能测试

一. 性能度量

可用性

应用程序对于最终用户的可用时间，即平均无故障时间。可用性不好是很严重的问题，因为即便是一个小小的故障也会导致大量的商务上的花费。在性能测试方面，这将意味着最终用户无法有效地使用该应用程序。

响应时间

应用程序对用户请求给出响应的时间。对于性能测试而言，一个最常用的衡量指标就是系统的响应时间、即从用户端发出请求到完整响应经过的时间。

吞吐量

面向应用程序事件的发生频率。例如，在一段特定的时间内对某个Web页面点击的次数。

利用率

占用系统资源的百分比。例如，当1000个用户同时在线时，在应用程序上消耗了多少网络带宽，以及在服务器上占用了多少内容等。

二. 性能指标

超过15秒

出现这种情况，基本排除了交互的可能性。如果真的发生了延迟，系统就应该设计成可以让用户转向其他操作，并且在后续时间里继续请求响应。

超过4秒

一般对于一个要求最终用户保存在短暂记忆里的会话来说太长了。这样的延迟将妨碍解决问题的活动和破坏数据的录入。

2~4秒

超过2秒的延迟可以被这种需求的高度集中所抑制。当用户专注地去完成一项手头的任务时，终端2~4秒左右的延迟看起来就似乎很长了。

低于2秒

当系统的用户需要记住几个响应信息时，此时的响应时间就必须很短，如果要就住更为详细的信息，则要求就更高了，要求响应时间不能超过2秒。因此，某些复杂的活动，2秒是一个很重要的响应时间限制。

亚秒

对于那些思想密集型的工作来说，尤其是一个图形应用程序，响应时间要非常短，才能保持用户的兴趣和吸引他长时间的关注。

0.1秒

在键盘上桥下一个按键，并在屏幕上出现响应的字符，或者用鼠标点击屏幕上的一个对象，这种响应几乎是瞬时的。

三. 性能测试成熟度

1. Firefighting

应用程序部署之前很少或从来没有进行过性能测试的情况，因此，实际上在生产环境上发现的所有性能方面的缺陷都必须去解决。

2. Performance Validation

这一级别的情况是：公司为性能测试单独安排了一段时间，而不是在产品的后期才开始进行性能测试。因此，在研发过程中，仍然有相当多的性能缺陷被发现（30%）。

3. Performance Driven

在应用程序生命周期中的每一个阶段，均对系统性能加以考虑。因此，当系统上线后，出现的性能缺陷就不会太多（50%）。

四. 性能测试的类型

基准测试

基准测试时指建立了一个可与进一步测试比较的点，通常用户衡量事物响应时间。这个测试通常是单用户在一段时间或一定的循环次数内执行单个事务。在基准测试执行过程中不应进行任何其他系统操作，以便提供在“最好情况下”的测量。通关基准测试所得到的值可用户评估，它随着用户数或吞吐量的增长而导致系统响应性能的衰减。

负载测试

负载测试是典型的性能测试，对应用程序施加负载直到达到目标，但通常不会进一步施压。这样做的目的是满足性能指标的可用性、并发性和吞吐量，以及响应时间。负载测试最接近真实的使用场景，它通常会包括一些虚拟应用程序客户端与用户交互时的影响。

压力测试

压力测试会导致应用程序或部分支撑硬件的崩溃，这样做的目的是确定硬件的支撑大小和上限。因此，压力测试会持续进行，直到有什么东西出了故障：没有更多用户可以登录，响应时间超过了界定的可以接受的范围。进行压力测试的原因是，假设我们的目标是1000个并发用户，但是当仅仅1005个用户时，硬件就崩溃了，则这一点是值得关注的，因为它清楚表明，系统能力几乎没有额外的扩展空间。

压力测试的结果不仅仅可以衡量系统的性能，还可以衡量功能。重要的是要知道应用程序的上限，特别是当未来增长的应用量难以预料的时候。

渗透或稳定测试

渗透测试的目的是找出那些可能只出现在一段较长时间里的问题。一个典型的例子是，在一个事物重复执行时所出现的缓慢增长的内存泄露或者一些不可预见的极限情况。除非能够进行适当的监控，否则这种测试没法有效地进行。这类问题的表现形式通常是逐渐变慢的响应速度，或者是应用程序突然变得不可用。确保准确诊断的关键是与用户和服务器执行失败的故障点相关的数据，以及证明系统变慢的相关数据。

冒烟测试

冒烟测试源自硬件行业，指在硬件的一段或是元件发生了变化或者维修，会对该电气设备简单的通电，如果没有冒烟，就意味着该元件通关了测试。冒烟测试只关注发生改变的部分。一个性能的冒烟测试可能只涉及那些发生了代码修改的事务。

隔离测试

这种完全不同的测试用于在内部确定问题。它通常会重复执行一些特定的事务，这些事务已被确定为会导致系统的性能问题。

 

[...]