系统产生负载的手段

1. 并发量
我们经常理解的系统的负载性能就是“能支持多少并发量”，无论是软件还是硬件产品，宣传他们产品的质量的时候第一个一般都是“支持多少并发量，响应时间在多少秒（毫秒）内”，可见对并发请求的处理对产品的重要性。有不少商业软件产品都根据这个参数的异同而制定了不同的价格，如一些中间件产品，web服务器产品，商业测试工具等都是根据这个可以支持不同的“并发量”而要求不同的价格。对应用系统而言，对并发的处理是基本上可以说是“同时”执行多个操作的行为，多线程技术支持的应用系统为每一个用户派生出来一个线程进行处理这些请求，面对公众提供服务的系统必须具备这些能力，如网站或网络游戏，如果不能对请求的并发处理的话，是没有任何应用或商业价值的，无论你这个应用软件有多么的漂亮，除了这个之外没有任何纰漏。
在功能测试或单元测试中，发出请求都是“单个”的，系统可以有条不紊的处理测，而并发请求虽然不是“并行”的发出，但发出的间隔时间非常的短，一般是在“毫秒”级别内的，如在100毫秒内接到来自100个客户端发出的100个请求，服务就必须为这100请求启动100个线程，服务器要处理这些请求，就需要消耗相当部分的系统资源。这就是并发所产生的负载。
2. 事务大小
相对并发和重复能给系统带来的负载而言，在一个已经写成代码实现了的应用系统中，要尽量增加系统处理的压力，还有一个可以变通的手段就是在单个的操作中增加每一个业务功能的处理量。如在即时通讯的聊天中，每次发送的消息包含汉字的数目在1个字符到100个字符之间的话，如果平均的数目是15个。那在设计测试用例时，可以将每次发送的100个字符定为95个到100个之间。再举个例子，对数据的查询的操作，精确的查询、模糊查询、不同的模糊查询将会对系统产生不同的压力。
单独的增大的事务，如果是在系统设计指标范围内的话，可能发现不了代码错误（或者仅能发现功能上的缺陷），但与其他压力手段结合在一起时，可以增加发现问题的机会。
3. 干扰因素
在实际系统的运营中，面对多人提供服务的系统多多少少都会有一些来自客户端的干扰，他们会经常用你意想不到的方式去操作，如误操作也算其中一种， 但这些干扰基本上是没有任何规律的。这些所谓的干扰迫使应用系统应该有更完善的旁路来解决这些问题。如果使用前面介绍的手段产生负载，应用系统在处理这些负载时，走的“路径”仅仅局限于主要业务逻辑的“主干道”。通过在测试中安排一些随机的干扰因素，相当于在主干道上面设置了一些“路障”，就能够在测试运行时迫使应用许多不同的代码路径，以检验系统在处理含有一些干扰的因素时，系统的性能状况将会是怎么样的。
如果模拟干扰的测试采用功能测试或单元测试人工操作的方式，因为很难发现系统在负载或大压力下出现的错误，即使出现了这种错误也是偶尔的，要重现出来就难上加难。在测试用例的脚本中加入一些干扰的因素，迫使系统走一些系统非业务逻辑的一些旁路，以检查系统在一些干扰因素后将会是怎么样的性能状态，这样，在测试执行过程中，增加了一些干扰因素，并与其他压力手段结合在一起执行时，发现错误的机会就会更大，将这些问题都修改好后，系统将会更稳定。
4. 恶意行为
恶意行为是干扰因素的一些扩展，系统在正常处理过程中，除了能将这些恶意行为处理之外，还要求不要在性能上付出太大的代价。在网络刚大众化的时候流行“在网上，没有人知道你是一条狗”，在面对公众的服务系统，如网站和网络游戏，使用者有刚入门的菜鸟，也有技术力量深厚的高手，大家都通过一个延伸到地球各个角落的网络进入一个系统，能供识别的仅有一个能确定大概范围的IP地址，如果他们在玩的过程中发现那点不符合他个人的习惯，（实际上一个为公众提供的服务的系统不可能满足所有人的口味）。他就可能会想着展示一下个人的技术，做一些攻击性的行为。（我们在这里姑且不谈安全方面的攻击，这个范围太广，不在我们本专题的讨论范围内）。我们关注的是那些攻击而言对一个应用系统的，会造成系统的一般会是一些边界值内外的数据，还可能是一些恶意数据，如包含有SQL语句的数据。
如果模拟恶意的测试采用功能测试或单元测试人工操作的方式，基本没有办法发现系统在这时为这些恶意行为付出的多大的性能方面的开销，即使这样的行为只是占到其中的很少一部分，如一万个用户里面有一个用户有恶意行为，系统也不能因为这样的原因崩溃，或出现其他预料之外的事情。
一个完善的性能测试方案通常会结合上述的所有给系统增加负载的手段， 再在其中加塞一些干扰和恶意的行为，并且在允许的范围内尽可能长时间地运行。测试被允许的执行时间越长，就可以执行越多的代码路径，并且发现的错误也越多。

若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。