性能测试VS负载测试VS压力测试

        负载测试

        我们都已经在性能测试调试的过程中，见识过负载测试了。在那种环境中，它意味着通过自动化工具来持续对系统增加负载。但对于WEB应用来讲，负载则是并发用户或者HTTP连接的数量。

        术语“负载测试”在测试文献资料中通常都被定义为给被测系统加上它所能操作的最大任务数的过程。负载测试有时也会被称为“容量测试”，或者“耐久性测试/持久性测试”*

        容量测试的例子：

        *通过编辑一个巨大的文件来测试文字处理软件

        *通过发送一个巨大的作业来测试打印机

        *通过成千上万的用户邮箱来测试邮件服务器

        *有一种比较特别的容量测试是叫作“零容量测试”，它是给系统加上空任务来测试的。

        耐久性测试/持久性测试的的例子：

        *在一个循环中不停的运行客户端超过一个扩展时间段*。

        负载测试的目的：

        *找到一些在测试流程中前面的阶段所进行的粗略测试中没有被找出的bugs,例如，内存管理bugs,内存泄露，缓冲器溢出等等。

        *保证应用程序达到性能测试中确定的性能基线。这个可以在运行回归试验时，通过加载特定的最大限度的负载来实现。

        尽管性能测试和负载测试似乎很像，但他们的目的还是有差异的。一方面，性能测试使用负载测试的技术，工具，以及用不同的负载程度来测度和基准化系统。在另一方面来讲，负载测试是在一些已经定义好的负载程度上进行测试的，通常对系统加上最大负载之后，系统应该仍然可以提供全部功能。这里需要明确一点，负载测试并不是要对系统加载上过度的负载而使系统不能工作，而是要使系统像一个上满了油的机器嗡嗡叫*。

        在负载测试的相关内容中，我想应该非常重要的是要有十分充足的数据来进行测试。从我的经验中得知，假若不用非常大的数据*去测的话，有很多严重的bug是不会的到的。比如说，LDAP/NIS/Active Directory数据库中成千上万的用户，邮件服务器中成千上万的邮箱，数据库中成G成G的表，文件系统中很深的文件或者目录的层次，等等。显然，测试人员就需要使用自动化工具来产生这些庞大的数据集，比较幸运的是任何优秀的脚本语言都可以胜任这些工作。

        压力测试

        压力测试是指通过对系统加载过度的资源或者例系统没有应该具有的令系统可以正常运作的资源，来使系统崩溃（在某些情况的时候，它又可以叫做负面测试）。进行这个疯狂行为的主要目的是为了保证系统出故障及可以适当的恢复，而这个恢复得怎么样的特性则是叫做可恢复性。

        当性能测试需要的是一个可控制的环境和不断的测度的时候，压力测试则是令为欢喜的引起混乱及不可预测性（译者按：从这一点可以看出作者是一个很优秀的测试人员）。还是举WEB应用系统为例，下面是一些对系统可行的压力测试方法：

        *两倍的已经基线的并发用户数或者HTTP连接数

        *随机的关闭及重开连接到服务器上的网络上集线器/路由器的端口（例如，可以通过SNMP命令来实现）

        *把数据库断线然后再重启

        *当系统还在运行的时候，重建一个RAID阵列

        *WEB和数据库服务器上运行消耗资源（如CPU，内存，磁盘，网络）的进程

        我可以肯定一些经常使用非常规方法来破坏系统的测试人员可以进一步充实这个列表的。只是压力测试并不是简单的为了一种破坏的快感而去破坏系统，实际上它是可以让测试工程师观察系统对出现故障时系统的反应。系统是不是保存了它出故障时的状态？是不是它就突然间崩溃掉了？它是否只是挂在那儿啥也不做了？它失效的时候是不是有一些反应*？在重启之后，它是否有能力可以恢复到前一个正常运行的状态？它是否会给用户显示出一些有用的错误信息，还是只是显示一些很难理解的十六进制代码？系统的安全性是否为因为一些不可预料的故障而会有所降低？这些问题可以一直问下去的。

        结论

        我明白我只是提到一些在性能/负载/压力测试中应该值得注意的一些比较基础的问题，工具及方法。我个人觉得性能测试及调试是一个很有趣的话题，我将会在以后贴更多的相关内容上来的。

上一页  [1] [2] 

【责编:michael】