组件测试

组件测试是将被测试应用系统的各个组件的分别进行性能测试，确保单个组件的性能达到设计指标，然后将已经通过性能测试的组件再进行测试，按照应用系统业务的需求，将组件从简单到复杂进行组合。这种测试方法适合集成了比较多组件或子系统的大型程序，如大型多人在线角色扮演的网络游戏。
满足组件测试的条件是，系统中的组件很松耦合的，可以相对独立，并可以作为一个独立的软件进行测试。组件测试适应的情况，之一是：性能测试直接对整个庞大的应用程序，没有办法执行测试，或测试的执行的效果不好。之二是：因为开发和软件复用等多方面的原因，被测试的系统中有些组件或子系统是现成的，做少量的修改就可以整合到新的系统里面，而有些组件还需要全新的开发。通过首先对组件进行测试，逐个找出系统组件内部和组件之间调用可能存在的性能问题，预先找出和解决整个系统中可能存在的“短板”，减轻项目后期的工作压力。组件测试是首先对每一个组件进行单独的性能测试，确认每一个组件的性能满足设计目标后。再按照不同的组合条件，将所有的组件进行“集成”测试，从简单的两个组件的“集成”到相对复杂的“集成”，找出定位并消除两个或两个以上子系统集成时性能互相影响的地方。直到最后系统组件的总“集成”，这个时候，就基本形成了这个被测试的应用系统。

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

并发测试

并发在负载测试或压力测试测试的核心部分。但为了比较真实的运营生产的过程，一般不在负载测试和压力测试时，针对某个特别关注的点设置很大的并发量，而将并发测试作为一种独立的测试方法单独执行。
应对来自多客户端并发的请求，应用系统服务端对应派生出多个线程实例进行处理，线程大多是以互斥的方式访问服务器端共享数据和临界资源的。大量的并发加大了数据竟争，对共享数据造成访问冲突，加大了数据库等临界资源死锁的可能；同时，并发的线程意味着一个线程中的代码有可能被其他线程中的代码中断，可能引发一连串的线程等待，以及其他因并发引起的错误。大量来自客户端的并发的操作会导致应用系统服务端性能低下，有可能会对应用系统造成巨大破坏。
并发测试的关键点有3个：首先是测试应用系统服务器能否与客户端快速建立并发连接，这个是并发测试的前提条件；然后再测试应用系统能否在既定的并发量的条件下快速处理业务，使响应时间也在预期的范围内。根据测试的应用程序的不同，不同的系统有很大的差别，这个是并发处理的关键；最后测试系统能否及时释放这些连接，如果系统不能及时释放连接的话，系统的关键资源之一，文件描述符将在很短的时间内被消耗殆尽，如果这样的话，系统将没有足够的文件描述符来建立新的连接。
在执行测试的时候，需要测试脚本或测试程序中的检查点之前设置“集合点”，测试脚本或测试工具执行到这个“集合点”时，在这里等待稍执行较慢的线程，然后以设置的并发量通过这个检查点。并发请求以不同速度通过这个检查点后，然后再在下一个检查点聚集。直到退出系统，释放链接。

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

负载测试

进行负载测试的应用系统，要求最终用户需要有一定数量，但这个数量可以预知或可以限制在既定范围内，因为这些系统在生产时候将要面对的最高的负载是确定的。如一个企业的内部业务处理系统，政府机关办公系统，最终用户的数量都在一个预定的范围内。多人在线网络游戏，为了保证服务器为玩家提供良好的服务，在一组服务器中就限制了最高点上限人数，对用户数量实现技术限制。
应用系统在处理多个用户同时操作的时候，系统要为每一个用户派生一个线程（进程）处理不同的请求，当系统忙于处理各种不同请求的时候，有可能出现各种各样的缺陷。负载测试可以使那些只有在负载的情况下才能出现的缺陷有了提前“露脸”的机会，特别是那些有可能导致死锁或使系统崩溃的问题将会暴露出来。
负载测试一般通过测试工具模拟真实的多用户的操作的场景，根据业务流程的需要，适当设置业务处理流程的长度，设置合适的思考和运行时间，请交易求的频率，事务的大小，业务数据，在线用户数量，活动用户数量等，模拟不同类型的用户的行为，检验系统在预定负载条件下的处理效率及其状况，发现和定位在系统资源开销超出预期的地方，判断能否系统是否满足被用户接受的基本条件之一。
负载测试是针对整个产品系统进行的，目的是验证系统是否满足了需求规定的性能指标，提前了解真实运行时的系统性能状况，找出并发现造成这些性能瓶颈的地方，最终目的是解决本来存在的性能瓶颈。负载测试需要搭建与实际使用环境相类似的测试环境，被测试系统的数据库的数据量也需要跟在运行时候的同样一个数量级别的，使负载测试结果比较真实地反映出软件的负载性能，这样测试出来的性能数据才具有比较高的评估价值。

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

关于压力测试

系统在超出预期的负载的时候，应用系统比正常状态下接收到更多来自于用户的请求，由于系统不能按正常的速度处理和响应用户的请求，有很大部分比例的用户的操作也是不正常的，如他们会不停的刷屏，重复的点击“确定”或“提交”按钮等，这些操作会引起系统处理上的混乱。在这种情况下，有些系统仅仅是处理速度慢一些，这个是在响应时间上不能满足用户的需求；有些系统则会出现灾难性的失败，并有可能扩散到整个服务器群，这是系统级的异常。
超出预期的压力在在现实生活中是经常存在的，在前几年中央某个电台向公众传播了“威客”的概念并播放了他们采访“威客”网站的CEO后，节目中提到的几个网站在几个月内都不能正常提供服务，用某些人的话来说，是“网络暴民”将这几个网站给压垮了。恰当的说法是突如其来的访问量，远远超过了网站的承受范围，导致不能提供正常的服务。
面对公众的应用服务程序，如网站和网络游戏，都应该将压力测试列入进行常规测试列表中，在上线生产前检查应用系统可以承受的压力强度，根据系统的表现作为评价系统压力性能、核实被测系统的性能行为在异常或极端条件之下的可接受性。
应用系统软件在处理超出设计指标的负载时，所反映出来的信息是非常丰富的，涉及到整个系统的各个方面，如普通用户看响应时间超出预期，业务管理人员看它的生产效率很低，系统管理员看到部分临界系统资源被消耗殆尽。这些情况的出现，除了跟被测试的应用系统本身，运行该应用软件机器硬件配置有关外，还与系统结构、重要的代码和算法、编译优化、编程工具，甚至与测试方法等都有关系。
压力测试也是需要实际使用环境相类似的测试环境进行，通过向应用系统发送超出系统处理能力的交易请求，测试系统在超出设计指标的压力情况下的处理效率及其状况。在执行测试的时候，首先是执行负载测试，在压力提升超出了设计指标就成了“压力测试”，再增加压力直到系统不能正常处理为止。分析压力测试中所获得的计数器信息，结合具体的测试用例，可以快速定位出现瓶颈的地方，如某个模块中不当的算法，或系统中不当的配置等。使开发人员或系统管理人员能快速的找到需要修改的地方等，对系统进行有针对性的优化。

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

模拟用户人工化

虽然模拟用户的操作是简单的重复，但是这种方式克服了人工操作不能逾越的障碍，使得可以用相对较低成本的获得大量的协作同步用户，可以长时间的按照指定的指令不停的操作，这个就是模拟用户的测试工具存在的价值。
随着软件技术的发展，模拟用户的模拟人工操作技术现有了令人瞩目的发展，目前主要是在操作速度，测试数据，网络带宽，IP地址欺骗和动态session捕捉等方面：
操作速度，很多测试工具都可以在脚本任何地方设置“思考时间”，这样就可以根据实际用户的操作具体业务的速度，在某些地方设置适当的停顿，而不是让测试一直往下执行，这样会使测试的操作执行速度方面更接近人工的操作。
测试数据，程序或脚本都是被不断重复的执行的，如果每次都输入同样的业务数据的话，这样可能会引起比较大的失真，因为现实中肯定不会出现这样的情况。理想的境界是让测试脚本可以选择输入同样或不一样的指定测试数据。功能比较完善的测试工具都提供了这个功能，
网络带宽，如果被测试的程序是基于互联网上面的应用，如果在局域网内以100M的链接带宽向服务器发送请求的话，这样出来的测试结果肯定会有所失真。在国内现在普通家庭用户的带宽是512Kbit的,商业用户的带宽是1M或2M，如果还可以支持WAP的话，带宽方面的失真会更厉害一些。测试工具可以对每一个模拟用户的带宽可以进行配置和限制。
模拟IP地址，对服务器来说，模拟用户就是一个线程或进程，几百个模拟用户在一个机器里面运行，他们用的都是同一个IP地址，这个跟现实情况相差太远。有些测试工具就提供了这个IP地址欺骗的技术，让每一个线程或进程都用不同的IP地址。
Session捕获，基于B/S或C/S的服务器为每一个新进来的请求都会新开一个session,而测试工具所回放的脚本是以前早就准备好的，如果没有这个Session捕获技术的话，服务器会将这个不含Session或已经过时的Session来的请求不予应答。Session捕获技术可以让测试人员提前好多天准备好测试脚本，而不担心测试脚本会被服务器拒绝的问题。

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

模拟操作跟人工操作的对比

对一个系统进行性能测试，其实就是要系统同时正确处理很多来自于用户的请求。发起这种请求可以通过手工操作实现或通过测试工具模拟实现。手工操作是通过真实的人进行操作，模拟操作先准备一些特定的程序或脚本，通过脚本或程序不断的向用户发送请求。以下对比一下手工操作跟模拟用户的操作，
手工操作存在的优势：
1． 人工操作，测试结果接近真实。
2． 测试是否成功清楚。
3． 人工操作可以多样化，接近实际情况。
4． 可以执行基本所有的程序，不管测试程序多复杂
5． 测试内容可以随时根据需要临时变化。
手工操作存在的问题：
1． 调动很多人进行操作这个被测试的系统，每个人操作1台安装有被测试系统客户端的电脑。
2． 需要对这些操作人员进行操作上的培训指导。
3． 设计一个很完善的操作指导，告诉每一个具体的人员，在某个时间段需要输入什么数据，进行什么样的操作。
4． 操作同步时间需要精确到秒以下的级别，基本上不能实现。
5． 测试现场需要安排一个人进行操作指挥。
6． 用户操作时间难以统计，服务器在某个时间执行什么样类型的操作不清楚。
7． 人工不可能长时间持续的操作。
8． 测试数据收集困难，统计和分析这些测试数据就更加困难。
很明显，如果进行人工的操作的话，不管是人力，物力，时间，协调，管理上将要付出巨大的成本，如果并发量比较小，测试结果比较可靠，随着并发量的增大，测试结果也将成反比快速下降。
机器模拟操作存在的优势：
1． 一台机器可以虚拟几百个模拟的用户。
2． 模拟用户可以按照准备好的流程进行操作，不需要对操作用户进行培训。
3． 可以设置同步操作集合点，让模拟用户进行大批量密集的并发。
4． 客户端跟服务器有统一的时间轴，服务器很清楚知道客户端的操作。
5． 操作方式简单，而且操作内容在既定的范围内，测试数据容易分析。
6． 操作方式可以设置很单一而且同步，测试数据容易获取，而且测试数据容易分析。
7． 模拟用户方便控制，可以随心所欲制造出不同的场景。
机器模拟存在的问题：
1． 模拟用户的操作简单，不容易变动。
2． 模拟用户不能模拟太复杂的场景。如对端到端的应用系统。
3． 模拟用户不容易模拟应用服务器有需要随机返回测试结果的应用程序。
4． 程序操作跟人工操作有一定的区别。
5． 测试结果有一定的失真度。
虽然模拟用户的测试有些智能判断方面的欠缺，但是它的优势是非常明显的，可以用少量的机器就可以达到大量的并发的目的，通过模拟用户实现一些比较单一应答的系统还是很有作用的。如一些应用软件或普通的网站浏览。


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

系统产生负载的手段

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/。