什么是可伸缩性测试

skinapi

提到性能测试，大家马上脑海里马上会出现负载测试、压力测试、容量测试等概念，那么大家知不知道还有可伸缩性测试。可伸缩性测试可以看成性能测试的一个扩展，关注系统本身的可伸缩性，下面给大家具体介绍。
    系统的可伸缩性可以从硬件和软件两个方面来理解：
    1、硬件的可伸缩性
    是不是可以通过硬件设备的增加来支持更多的用户，比如通过增加cpu个数或者存储器空间大小等。
    2、软件的可伸缩性
    是不是可以通过运行更多的实例或者采用分布式处理来支持更多的用户。
    那么再具体一点就是一个可伸缩的系统必须具有随负荷增加响应时间也线性增加的特点。这样就可以通过线性的增加硬件设备、实例个数或者分布式处理点来处理更多的数据量。也就能更好的在不增加响应时间的前提下支持更多的用户。
    可伸缩性测试具体的测试过程为：进行负载测试，记录不同负载下的平均响应时间，然后查看平均响应时间是否线性增加。如线性增加，说明系统具有可伸缩性，否则则说明系统可伸缩性较差或者没有。
    原文请参见：
    http://skinapi.cnblogs.com/archive/2005/08/17/217155.html

B2CPC

恩，长了见识。
我也说说看到的一个新概念。叫ALAC测试，可能有人听说过的。

[ Last edited by B2CPC on 2005-8-23 at 09:13 ]

安心

呵呵，楼上的介绍新概念可以稍微详细一点呀。方便大家学习嘛^_^
我查了下中国软件评测中心关于ALAC测试的定义。————
ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。

我觉得那个定义有点拗口，我自己的理解是，ALAC(Act-like-a-customer)测试从其字面上的意思来看就是测试人员站在用户角度进行测试。ALAC测试的前提是认为复杂软件中存在许多错误，而用户通常遇到的只占其中的小部分比例，所以针对普通用户在使用时最容易遇到的错误进行测试，改进测试的有效性。
个人认为这种方法应该是和其他测试方法结合进行的，否则这种低密度的测试肯定会遗漏掉非常多的错误。不过在赶进度的时候，倒是可以考虑将ALAC的测试用例优先执行。

B2CPC

hehe，不好意思，是看看大家对这个概念有什么反应才这么说的
其实自己感觉ALAC测试和冒烟测试很相近。都是测试一些重要的功能点。软件中用户常用的功能必定要被测到的。
而楼主说到的可伸缩性测试也和压力测试很相近。压力测试指测试系统超负荷、长时间运行时，系统的稳定性和恢复能力。

安心

恩，我也觉得ALAC测试和冒烟测试在某方面来讲很相近，比如它们的测试对象一般都是一些用户使用最频繁的重要的功能点。不过我觉得就其测试的目的而言，两者还是有区别的，冒烟测试目的是要确认软件基本功能正常，偏向于正向测试；而ALAC测试相比较而言可能更偏向于逆向测试。
呵呵，自己的一点比较浅薄的理解，也不知道正不正确，大家一起切磋一下：）

另外，我觉得可伸缩性测试和压力测试这两个概念好象是不一样的哦：）
据skinapi老师文章中的定义————

Originally posted by skinapi at 2005-8-20 12:18 AM:
可伸缩性测试具体的测试过程为：进行负载测试，记录不同负载下的平均响应时间，然后查看平均响应时间是否线性增加。如线性增加，说明系统具有可伸缩性，否则则说明系统可伸缩性较差或者没有。

我想可伸缩性测试应该是在负载测试的基础上，对不同负载进行性能指标地跟踪记录，观察其性能指标的变化曲线，以此分析系统的可伸缩性。而并不是像压力测试那样对系统进行超负荷、长时间的性能观察测试。
嘿嘿，不知道理解得对不对，大家一起讨论讨论：）

B2CPC

恩说的是,细细想来skinapi老师说的可伸缩性---“随负荷增加响应时间也线性增加”，这是说到了---“伸”，而“缩”应该是“随负荷减少响应时间也线性减少”是吧？？（尽管文中未说明） 这样才能称为可伸缩性呢。
因此在下觉得这种能“伸”能“缩”的属性---“伸缩性”和压力测试中提到的恢复能力差不多。就好比老师举的那个大力士举重的例子。也可以说是物理中弹簧的非范性形变了。（弹簧超过承受负载的范围不能再收缩---范性形变）
而压力测试中提到的1.长时间2.高负荷  确实在可伸缩性中没有体现呢

cxsquirrle

好佩服楼上的几位呢,我真是长见识了，要想你们多多学习呢.

hwrong

你们都厉害啊，我也要多学些东西了，否则就落后啦！

edifier

不是很明白 还是慢慢来吧

kpxl

如果ALAC四个单词是象大家说的那样解释的话，那我的理解就是，不考虑软件功能和计算逻辑的正确性（这个由功能测试把握），而专门从用户友好性，操作方便，提示语言是否考虑到了使用用户的风俗习惯以及宗教信仰等，当然还可能从性能方面做测试，比如采用不同的接入方式来访问系统，看速度是否可以忍受。

我以前在的公司有一个Team专门做这种测试，因为系统主要给老外使用，所以这个组的同事的E文都很强。
有不同意见和看法的朋友，欢迎砸砖头！

liyb

感觉是用例驱动测试，当然，每一种测试方法只能覆盖软件的某一部分，需要用其他方法补充。至于楼上说的似乎是软件的本地化测试，哈哈，不太懂，随便说了两句。欢迎指教。