压力测试(Stress Test)

压力测试严格地说不属于效能测试。压力测试要验证的问题是:软件在超过设计负载的情况下是否仍能返回正常结果，没有产生严重的副作用或崩溃。
问:为啥不要求软件在这种情况下仍然在23秒钟内返回结果?
答:因为我们做不到。
提示:我们在这一部分要求返回"正常结果"，啥叫"正常"?我们也要就此与客户达成一致。比如，同一个购物网站，所有请求都能在网络返回"超时"错误前返回，就可以认为是"正常"。或者网站返回"系统忙，请稍候"，也是正常结果。但是，如果用户提交的请求一部分执行，另一部分没有执行，或者出现用户信息丢失，这些都是不正常的结果，
应该避免。那我们怎样增加负载呢?对于网络服务软件来说，主要考虑以下两个方面。
1.沿着用户轴延长
以刚才的购物网站为例，正常的负载是20个请求/分钟，如果有更多的用户登录，怎么办?那么负载就会变成30、40、100个请求/分钟，或更高。
2.沿着时间轴延长
做过网络服务的都知道，网络的负载有时间性，负载压力的波峰和波谷相差很大，那么如果每时每刻负载都处于峰值，程序会不会垮掉?这就是我们要做的第二点:沿着时间轴延长。一般要模拟48小时的高负载才能认为系统通过测试。与此同时，可以减少系统可用的资源来增加压力。注意，压力测试的重点是验证程序不崩溃或产生副作用。即看看在超负载的情况下，我们的程序是否仍能正确地运行，而不会死机。在给程序加压的过程中，程序中的很多"小"问题就会被放大，暴露出来。最常见的问题是:
内存/资源泄漏，在压力下这会导致程序可用的资源枯竭，最后崩溃;
一些平时认为"足够好"的算法实现会出现问题。比如，WindowsPlatfor SDK有一个GerTickCount()函数，它返回自系统启动后所经过的毫秒数，用DWORD来表示。经过47.9天之后DWORD会溢出，GetTickCount()会从O开始重新计数，你的程序如果用了不同的TickCount来计算时间，不要假设后来的Tick-Count一定会比先前的TickCount大，也许系统在运行一段时间后会出现莫名其妙的错误，但是系统重新启动后，又找不到原因。
进程/线程的同步死锁问题，在压力下一些小概率事件会发生，看似完备的程序逻辑也会出现问题。