组件测试是将被测试应用系统的各个组件的分别进行性能测试，确保单个组件的性能达到设计指标，然后将已经通过性能测试的组件再进行测试，按照应用系统业务的需求，将组件从简单到复杂进行组合。这种测试方法适合集成了比较多组件或子系统的大型程序，如大型多人在线角色扮演的网络游戏。
满足组件测试的条件是，系统中的组件很松耦合的，可以相对独立，并可以作为一个独立的软件进行测试。组件测试适应的情况，之一是：性能测试直接对整个庞大的应用程序，没有办法执行测试，或测试的执行的效果不好。之二是：因为开发和软件复用等多方面的原因，被测试的系统中有些组件或子系统是现成的，做少量的修改就可以整合到新的系统里面，而有些组件还需要全新的开发。通过首先对组件进行测试，逐个找出系统组件内部和组件之间调用可能存在的性能问题，预先找出和解决整个系统中可能存在的“短板”，减轻项目后期的工作压力。组件测试是首先对每一个组件进行单独的性能测试，确认每一个组件的性能满足设计目标后。再按照不同的组合条件，将所有的组件进行“集成”测试，从简单的两个组件的“集成”到相对复杂的“集成”，找出定位并消除两个或两个以上子系统集成时性能互相影响的地方。直到最后系统组件的总“集成”，这个时候，就基本形成了这个被测试的应用系统。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
2008年8月27日
并发测试
并发在负载测试或压力测试测试的核心部分。但为了比较真实的运营生产的过程，一般不在负载测试和压力测试时，针对某个特别关注的点设置很大的并发量，而将并发测试作为一种独立的测试方法单独执行。
应对来自多客户端并发的请求，应用系统服务端对应派生出多个线程实例进行处理，线程大多是以互斥的方式访问服务器端共享数据和临界资源的。大量的并发加大了数据竟争，对共享数据造成访问冲突，加大了数据库等临界资源死锁的可能；同时，并发的线程意味着一个线程中的代码有可能被其他线程中的代码中断，可能引发一连串的线程等待，以及其他因并发引起的错误。大量来自客户端的并发的操作会导致应用系统服务端性能低下，有可能会对应用系统造成巨大破坏。
并发测试的关键点有3个：首先是测试应用系统服务器能否与客户端快速建立并发连接，这个是并发测试的前提条件；然后再测试应用系统能否在既定的并发量的条件下快速处理业务，使响应时间也在预期的范围内。根据测试的应用程序的不同，不同的系统有很大的差别，这个是并发处理的关键；最后测试系统能否及时释放这些连接，如果系统不能及时释放连接的话，系统的关键资源之一，文件描述符将在很短的时间内被消耗殆尽，如果这样的话，系统将没有足够的文件描述符来建立新的连接。
在执行测试的时候，需要测试脚本或测试程序中的检查点之前设置“集合点”，测试脚本或测试工具执行到这个“集合点”时，在这里等待稍执行较慢的线程，然后以设置的并发量通过这个检查点。并发请求以不同速度通过这个检查点后，然后再在下一个检查点聚集。直到退出系统，释放链接。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
应对来自多客户端并发的请求，应用系统服务端对应派生出多个线程实例进行处理，线程大多是以互斥的方式访问服务器端共享数据和临界资源的。大量的并发加大了数据竟争，对共享数据造成访问冲突，加大了数据库等临界资源死锁的可能；同时，并发的线程意味着一个线程中的代码有可能被其他线程中的代码中断，可能引发一连串的线程等待，以及其他因并发引起的错误。大量来自客户端的并发的操作会导致应用系统服务端性能低下，有可能会对应用系统造成巨大破坏。
并发测试的关键点有3个：首先是测试应用系统服务器能否与客户端快速建立并发连接，这个是并发测试的前提条件；然后再测试应用系统能否在既定的并发量的条件下快速处理业务，使响应时间也在预期的范围内。根据测试的应用程序的不同，不同的系统有很大的差别，这个是并发处理的关键；最后测试系统能否及时释放这些连接，如果系统不能及时释放连接的话，系统的关键资源之一，文件描述符将在很短的时间内被消耗殆尽，如果这样的话，系统将没有足够的文件描述符来建立新的连接。
在执行测试的时候，需要测试脚本或测试程序中的检查点之前设置“集合点”，测试脚本或测试工具执行到这个“集合点”时，在这里等待稍执行较慢的线程，然后以设置的并发量通过这个检查点。并发请求以不同速度通过这个检查点后，然后再在下一个检查点聚集。直到退出系统，释放链接。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
2008年8月26日
负载测试
进行负载测试的应用系统，要求最终用户需要有一定数量，但这个数量可以预知或可以限制在既定范围内，因为这些系统在生产时候将要面对的最高的负载是确定的。如一个企业的内部业务处理系统，政府机关办公系统，最终用户的数量都在一个预定的范围内。多人在线网络游戏，为了保证服务器为玩家提供良好的服务，在一组服务器中就限制了最高点上限人数，对用户数量实现技术限制。
应用系统在处理多个用户同时操作的时候，系统要为每一个用户派生一个线程（进程）处理不同的请求，当系统忙于处理各种不同请求的时候，有可能出现各种各样的缺陷。负载测试可以使那些只有在负载的情况下才能出现的缺陷有了提前“露脸”的机会，特别是那些有可能导致死锁或使系统崩溃的问题将会暴露出来。
负载测试一般通过测试工具模拟真实的多用户的操作的场景，根据业务流程的需要，适当设置业务处理流程的长度，设置合适的思考和运行时间，请交易求的频率，事务的大小，业务数据，在线用户数量，活动用户数量等，模拟不同类型的用户的行为，检验系统在预定负载条件下的处理效率及其状况，发现和定位在系统资源开销超出预期的地方，判断能否系统是否满足被用户接受的基本条件之一。
负载测试是针对整个产品系统进行的，目的是验证系统是否满足了需求规定的性能指标，提前了解真实运行时的系统性能状况，找出并发现造成这些性能瓶颈的地方，最终目的是解决本来存在的性能瓶颈。负载测试需要搭建与实际使用环境相类似的测试环境，被测试系统的数据库的数据量也需要跟在运行时候的同样一个数量级别的，使负载测试结果比较真实地反映出软件的负载性能，这样测试出来的性能数据才具有比较高的评估价值。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
应用系统在处理多个用户同时操作的时候，系统要为每一个用户派生一个线程（进程）处理不同的请求，当系统忙于处理各种不同请求的时候，有可能出现各种各样的缺陷。负载测试可以使那些只有在负载的情况下才能出现的缺陷有了提前“露脸”的机会，特别是那些有可能导致死锁或使系统崩溃的问题将会暴露出来。
负载测试一般通过测试工具模拟真实的多用户的操作的场景，根据业务流程的需要，适当设置业务处理流程的长度，设置合适的思考和运行时间，请交易求的频率，事务的大小，业务数据，在线用户数量，活动用户数量等，模拟不同类型的用户的行为，检验系统在预定负载条件下的处理效率及其状况，发现和定位在系统资源开销超出预期的地方，判断能否系统是否满足被用户接受的基本条件之一。
负载测试是针对整个产品系统进行的，目的是验证系统是否满足了需求规定的性能指标，提前了解真实运行时的系统性能状况，找出并发现造成这些性能瓶颈的地方，最终目的是解决本来存在的性能瓶颈。负载测试需要搭建与实际使用环境相类似的测试环境，被测试系统的数据库的数据量也需要跟在运行时候的同样一个数量级别的，使负载测试结果比较真实地反映出软件的负载性能，这样测试出来的性能数据才具有比较高的评估价值。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
2008年8月25日
关于压力测试
系统在超出预期的负载的时候，应用系统比正常状态下接收到更多来自于用户的请求，由于系统不能按正常的速度处理和响应用户的请求，有很大部分比例的用户的操作也是不正常的，如他们会不停的刷屏，重复的点击“确定”或“提交”按钮等，这些操作会引起系统处理上的混乱。在这种情况下，有些系统仅仅是处理速度慢一些，这个是在响应时间上不能满足用户的需求；有些系统则会出现灾难性的失败，并有可能扩散到整个服务器群，这是系统级的异常。
超出预期的压力在在现实生活中是经常存在的，在前几年中央某个电台向公众传播了“威客”的概念并播放了他们采访“威客”网站的CEO后，节目中提到的几个网站在几个月内都不能正常提供服务，用某些人的话来说，是“网络暴民”将这几个网站给压垮了。恰当的说法是突如其来的访问量，远远超过了网站的承受范围，导致不能提供正常的服务。
面对公众的应用服务程序，如网站和网络游戏，都应该将压力测试列入进行常规测试列表中，在上线生产前检查应用系统可以承受的压力强度，根据系统的表现作为评价系统压力性能、核实被测系统的性能行为在异常或极端条件之下的可接受性。
应用系统软件在处理超出设计指标的负载时，所反映出来的信息是非常丰富的，涉及到整个系统的各个方面，如普通用户看响应时间超出预期，业务管理人员看它的生产效率很低，系统管理员看到部分临界系统资源被消耗殆尽。这些情况的出现，除了跟被测试的应用系统本身，运行该应用软件机器硬件配置有关外，还与系统结构、重要的代码和算法、编译优化、编程工具，甚至与测试方法等都有关系。
压力测试也是需要实际使用环境相类似的测试环境进行，通过向应用系统发送超出系统处理能力的交易请求，测试系统在超出设计指标的压力情况下的处理效率及其状况。在执行测试的时候，首先是执行负载测试，在压力提升超出了设计指标就成了“压力测试”，再增加压力直到系统不能正常处理为止。分析压力测试中所获得的计数器信息，结合具体的测试用例，可以快速定位出现瓶颈的地方，如某个模块中不当的算法，或系统中不当的配置等。使开发人员或系统管理人员能快速的找到需要修改的地方等，对系统进行有针对性的优化。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
超出预期的压力在在现实生活中是经常存在的，在前几年中央某个电台向公众传播了“威客”的概念并播放了他们采访“威客”网站的CEO后，节目中提到的几个网站在几个月内都不能正常提供服务，用某些人的话来说，是“网络暴民”将这几个网站给压垮了。恰当的说法是突如其来的访问量，远远超过了网站的承受范围，导致不能提供正常的服务。
面对公众的应用服务程序，如网站和网络游戏，都应该将压力测试列入进行常规测试列表中，在上线生产前检查应用系统可以承受的压力强度，根据系统的表现作为评价系统压力性能、核实被测系统的性能行为在异常或极端条件之下的可接受性。
应用系统软件在处理超出设计指标的负载时，所反映出来的信息是非常丰富的，涉及到整个系统的各个方面，如普通用户看响应时间超出预期，业务管理人员看它的生产效率很低，系统管理员看到部分临界系统资源被消耗殆尽。这些情况的出现，除了跟被测试的应用系统本身，运行该应用软件机器硬件配置有关外，还与系统结构、重要的代码和算法、编译优化、编程工具，甚至与测试方法等都有关系。
压力测试也是需要实际使用环境相类似的测试环境进行，通过向应用系统发送超出系统处理能力的交易请求，测试系统在超出设计指标的压力情况下的处理效率及其状况。在执行测试的时候，首先是执行负载测试，在压力提升超出了设计指标就成了“压力测试”，再增加压力直到系统不能正常处理为止。分析压力测试中所获得的计数器信息，结合具体的测试用例，可以快速定位出现瓶颈的地方，如某个模块中不当的算法，或系统中不当的配置等。使开发人员或系统管理人员能快速的找到需要修改的地方等，对系统进行有针对性的优化。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
2008年8月22日
模拟用户人工化
虽然模拟用户的操作是简单的重复，但是这种方式克服了人工操作不能逾越的障碍，使得可以用相对较低成本的获得大量的协作同步用户，可以长时间的按照指定的指令不停的操作，这个就是模拟用户的测试工具存在的价值。
随着软件技术的发展，模拟用户的模拟人工操作技术现有了令人瞩目的发展，目前主要是在操作速度，测试数据，网络带宽，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/。
随着软件技术的发展，模拟用户的模拟人工操作技术现有了令人瞩目的发展，目前主要是在操作速度，测试数据，网络带宽，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/。
2008年8月21日
模拟操作跟人工操作的对比
对一个系统进行性能测试，其实就是要系统同时正确处理很多来自于用户的请求。发起这种请求可以通过手工操作实现或通过测试工具模拟实现。手工操作是通过真实的人进行操作，模拟操作先准备一些特定的程序或脚本，通过脚本或程序不断的向用户发送请求。以下对比一下手工操作跟模拟用户的操作，
手工操作存在的优势：
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． 人工操作，测试结果接近真实。
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/。
2008年8月19日
系统产生负载的手段
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/。
我们经常理解的系统的负载性能就是“能支持多少并发量”，无论是软件还是硬件产品，宣传他们产品的质量的时候第一个一般都是“支持多少并发量，响应时间在多少秒（毫秒）内”，可见对并发请求的处理对产品的重要性。有不少商业软件产品都根据这个参数的异同而制定了不同的价格，如一些中间件产品，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/。
2008年8月18日
性能测试的一些见解
一般需要进行性能测试的都是使用人数多，而且数目不确定，将响应时间限制的一定范围内的应用系统。如面对公共服务的系统，如果门户网站，大型的商业购物网站，大型多人在线网络游戏（当然也有使用人数少，实时要求比较对应的系统需要性能测试，这个不在本文讨论范围内）。在测试的时候不可能召集这么多的用户，所以一般的测试会通过模拟用户自动化的方式来执行。
性能测试是系统测试的一个子集，这种测试是针对整个产品系统进行的，目的是验证系统是否满足了需求规定的定义，找出并发现影响这些定义的地方，也就是普通意义上说的性能瓶颈。由于一般的系统性能包括有几个方面，比如压力性能，负载性能，稳定性等，在实际执行的时候我们一般将它进行一些分解成为对应的，可执行性比较强的测试步骤，如负载测试、压力测试等，而将这些测试行为的总称为性能测试。
这些所谓的“性能指标”在项目需求阶段就应当提出，套用软件行业一般的说法，可以说这个就是“性能需求”。跟系统设计一样，在设计阶段需要将这些需求分解和细化到具体的数值。性能测试执行是需要搭建与实际使用环境相接近的测试环境，通过模拟业务场景来验证应用程序在设置的的测试条件下服务器的运行状况，这些运行的状况可以通过服务器的一些计数器统计出来，如CPU利用率状况、内存占用率等、网络流量、响应时间等。将这些测试数据跟细化后的性能指标进行对比，就可以知道被测试的系统是否满足了“性能需求”。通过实际的性能测试可以发现系统中存在一些在开发和设计阶段没有考虑到问题，是这些隐藏的问题导致了系统存在性能瓶颈。一般刚开发出来的应用软件很少能不经任何调整优化就可以通过性能测试的。
在性能测试的执行中，可以根据具体的性能指标，通过设置不同的场景，就可以演绎出负载测试、压力测试等不同目标的测试，在不同的时间和不同的机器上执行。具体方法是：将一个测试用例写成脚本后，在不同的测试阶段，都可以执行同样的测试脚本，但要配置不同的测试场景跟测试数据。因为在测试场景、测试数据等条件中有一个测试条件有变化的话，都有可能会引起系统在性能响应的变化。通过对测试数据、系统配置、设计指标等进行数据上的对比对比，可以看到那些配置的组合是系统性能的最佳点。
在开始进行执行测试的时候，不管开始时候的测试的硬件环境怎么样，到最后提交测试报告的时候，必须具有运行环境接近的测试环境。对一般的公司而言，搭建测试环境中服务器群都不难实现，实现难度大的地方是运行的时候需要的是互联网的环境。这个也要通过模拟来实现，至于这个差别之间存在的风险，一个比较好的解决方法是专业的评估和在运行环境中不断观察、对比和总结。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
性能测试是系统测试的一个子集，这种测试是针对整个产品系统进行的，目的是验证系统是否满足了需求规定的定义，找出并发现影响这些定义的地方，也就是普通意义上说的性能瓶颈。由于一般的系统性能包括有几个方面，比如压力性能，负载性能，稳定性等，在实际执行的时候我们一般将它进行一些分解成为对应的，可执行性比较强的测试步骤，如负载测试、压力测试等，而将这些测试行为的总称为性能测试。
这些所谓的“性能指标”在项目需求阶段就应当提出，套用软件行业一般的说法，可以说这个就是“性能需求”。跟系统设计一样，在设计阶段需要将这些需求分解和细化到具体的数值。性能测试执行是需要搭建与实际使用环境相接近的测试环境，通过模拟业务场景来验证应用程序在设置的的测试条件下服务器的运行状况，这些运行的状况可以通过服务器的一些计数器统计出来，如CPU利用率状况、内存占用率等、网络流量、响应时间等。将这些测试数据跟细化后的性能指标进行对比，就可以知道被测试的系统是否满足了“性能需求”。通过实际的性能测试可以发现系统中存在一些在开发和设计阶段没有考虑到问题，是这些隐藏的问题导致了系统存在性能瓶颈。一般刚开发出来的应用软件很少能不经任何调整优化就可以通过性能测试的。
在性能测试的执行中，可以根据具体的性能指标，通过设置不同的场景，就可以演绎出负载测试、压力测试等不同目标的测试，在不同的时间和不同的机器上执行。具体方法是：将一个测试用例写成脚本后，在不同的测试阶段，都可以执行同样的测试脚本，但要配置不同的测试场景跟测试数据。因为在测试场景、测试数据等条件中有一个测试条件有变化的话，都有可能会引起系统在性能响应的变化。通过对测试数据、系统配置、设计指标等进行数据上的对比对比，可以看到那些配置的组合是系统性能的最佳点。
在开始进行执行测试的时候，不管开始时候的测试的硬件环境怎么样，到最后提交测试报告的时候，必须具有运行环境接近的测试环境。对一般的公司而言，搭建测试环境中服务器群都不难实现，实现难度大的地方是运行的时候需要的是互联网的环境。这个也要通过模拟来实现，至于这个差别之间存在的风险，一个比较好的解决方法是专业的评估和在运行环境中不断观察、对比和总结。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
2008年8月14日
工具跟实际人工操作的差异
理论上来说，通过工具执行的测试应该跟人工操作是完全相同的。软件测试界有句俗话说得好“好的测试都是自动化测试”。前提条件是你对用户可能的操作方式有充分的考虑并有对应的设计。但即使是你将这些条件你都考虑清楚并将他们都实现了，通过工具测试跟人工测试还是有一些不同的地方。
1. 操作
工具跟实际人工最大的差别应该就在操作上面，工具的操作其实就是执行录制的动作，对一个测试用例而言客户端的操作都是同样的操作流程，每次向系统提交的不同的地方只是一些测试数据。而真实的用户的话，有可能有各种不同的操作方式，和操作流程。即使你将用户可能的操作方式都考虑到了，在实际上还会有一些疏忽的，你不可能将所有的操作方式都考虑到，有句很流行的话是这样说的“在网上，没有人知道你是一条狗”。特别是面对公众服务的网站或网络游戏，更应该充分考虑各种不同用户的操作方式。
2. 思考时间
思考时间也是差别比较大的一个。工具的操作在一个测试的脚本里面，可以设置的停顿点都是完全一样的，停留时间当然也完全一样，除非服务器响应不及时。人工操作的话，在一个完整的流程中每一个点会有不同的停顿。
3. 上线和下线
如果用测试工具来执行，虚拟用上线和下线都是有规律的。而真实的用户，基本是随机的，在一个短的时间段内没有可以可以追踪的规律。
4. 用户数量
但是由于在真实的Internet环境中，Web服务器的用户数量是以百万来计的，有些著名的网站访问人数更多，因此用模拟固定的少量的客户端来评测服务器所得到的结果是不充分的。需要有能够产生并且维持稳定负载的工具，使用这种工具就可以近似模拟无限多的用户。
5. 用户分布
如果这个应用系统是分布在一个局域网内的话，正常运营跟测试条件下的用户分布是没有多大区别，如果这个应用系统是面向互联网提供的服务系统，在实际运营环境中测试阶段差别最大的应该是这个，因为在实验条件下，无论你的条件如何，你还是没有办法模拟到众多千万里之外，有可能随机分布在这个星球任何角落的用户。
6. 网络流量
网络流量是差别是最大的，测试环境和真实环境下，服务器端发送和接受的流量是一样的，链接客户端和服务器之间的线路的流量差别比较大，但不在我们的关注对象范围之内。差别大的是，真实环境下，没有一个客户端的流量一般不太大，除测试用例是在下载某些内容。测试环境下的客户端流量比较大。因为一个客户端要模拟几十上百个真实的客户端。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
1. 操作
工具跟实际人工最大的差别应该就在操作上面，工具的操作其实就是执行录制的动作，对一个测试用例而言客户端的操作都是同样的操作流程，每次向系统提交的不同的地方只是一些测试数据。而真实的用户的话，有可能有各种不同的操作方式，和操作流程。即使你将用户可能的操作方式都考虑到了，在实际上还会有一些疏忽的，你不可能将所有的操作方式都考虑到，有句很流行的话是这样说的“在网上，没有人知道你是一条狗”。特别是面对公众服务的网站或网络游戏，更应该充分考虑各种不同用户的操作方式。
2. 思考时间
思考时间也是差别比较大的一个。工具的操作在一个测试的脚本里面，可以设置的停顿点都是完全一样的，停留时间当然也完全一样，除非服务器响应不及时。人工操作的话，在一个完整的流程中每一个点会有不同的停顿。
3. 上线和下线
如果用测试工具来执行，虚拟用上线和下线都是有规律的。而真实的用户，基本是随机的，在一个短的时间段内没有可以可以追踪的规律。
4. 用户数量
但是由于在真实的Internet环境中，Web服务器的用户数量是以百万来计的，有些著名的网站访问人数更多，因此用模拟固定的少量的客户端来评测服务器所得到的结果是不充分的。需要有能够产生并且维持稳定负载的工具，使用这种工具就可以近似模拟无限多的用户。
5. 用户分布
如果这个应用系统是分布在一个局域网内的话，正常运营跟测试条件下的用户分布是没有多大区别，如果这个应用系统是面向互联网提供的服务系统，在实际运营环境中测试阶段差别最大的应该是这个，因为在实验条件下，无论你的条件如何，你还是没有办法模拟到众多千万里之外，有可能随机分布在这个星球任何角落的用户。
6. 网络流量
网络流量是差别是最大的，测试环境和真实环境下，服务器端发送和接受的流量是一样的，链接客户端和服务器之间的线路的流量差别比较大，但不在我们的关注对象范围之内。差别大的是，真实环境下，没有一个客户端的流量一般不太大，除测试用例是在下载某些内容。测试环境下的客户端流量比较大。因为一个客户端要模拟几十上百个真实的客户端。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
性能测试中的经验公式和定律
1. 90/10局部性原理
一个程序中10％的代码执行90％的指令。
2. Little定律
系统中的平均任务量＝到达率×平均响应时间。假定系统处于稳定状态。
一个队列进入稳定状态以后,可以用下列参数来描述队列的特性：
①K—队列的请求平均达到速率(以每秒请求到达的个数计算)。
②N—队列的平均长度,即队列中等待和正在接受服务的请求的平均个数。
③T—一个请求通过队列所需的平均时间，包括在队列中等待的时间加上接受服务的时间。于是：N=KT
3. ForcedFlow定理
假设平均每个事务访问队列i的次数是Vi,在单位时间内,系统完成X0个事务,那么队列i的吞吐量Xi为Xi=Vi×X0.
4. Arrival定理
一个客户观察到的系统状态等于这个客户离开系统时的系统状态.对于队列网络系统来说，一个请求到达队列时看到的队列中已有请求的平均数等于这个请求离开系统时队列中的平均请求数。
完估计高峰和典型资源需求的最好方法是使用排队模型，如 BEST/1。可以使用静态模型，但有冒高估或低估高峰资源的危险。在任一情况下，从资源需求的观点出发，您都需要理解工作负载中的多个程序是如何交互的。
如果正在构建一个静态模型，请使用时间间隔，这是对大多数频繁运行或苛求的程序（通常两者是相同的）而言可接受性最差的响应时间。决定在每个时间间隔中通常运行哪些程序，这要基于您所规划的用户数、他们的思考次数、击键输入速率以及预期的混合操作。
5. Amdahl/Case定律
一个平衡的计算机系统，应该是每MIPS的CPU性能对应1MB存储器和1Mb/s的I/O带宽。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
一个程序中10％的代码执行90％的指令。
2. Little定律
系统中的平均任务量＝到达率×平均响应时间。假定系统处于稳定状态。
一个队列进入稳定状态以后,可以用下列参数来描述队列的特性：
①K—队列的请求平均达到速率(以每秒请求到达的个数计算)。
②N—队列的平均长度,即队列中等待和正在接受服务的请求的平均个数。
③T—一个请求通过队列所需的平均时间，包括在队列中等待的时间加上接受服务的时间。于是：N=KT
3. ForcedFlow定理
假设平均每个事务访问队列i的次数是Vi,在单位时间内,系统完成X0个事务,那么队列i的吞吐量Xi为Xi=Vi×X0.
4. Arrival定理
一个客户观察到的系统状态等于这个客户离开系统时的系统状态.对于队列网络系统来说，一个请求到达队列时看到的队列中已有请求的平均数等于这个请求离开系统时队列中的平均请求数。
完估计高峰和典型资源需求的最好方法是使用排队模型，如 BEST/1。可以使用静态模型，但有冒高估或低估高峰资源的危险。在任一情况下，从资源需求的观点出发，您都需要理解工作负载中的多个程序是如何交互的。
如果正在构建一个静态模型，请使用时间间隔，这是对大多数频繁运行或苛求的程序（通常两者是相同的）而言可接受性最差的响应时间。决定在每个时间间隔中通常运行哪些程序，这要基于您所规划的用户数、他们的思考次数、击键输入速率以及预期的混合操作。
5. Amdahl/Case定律
一个平衡的计算机系统，应该是每MIPS的CPU性能对应1MB存储器和1Mb/s的I/O带宽。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
2008年8月13日
软件性能测试几个方面--有点乱
从“性能”字意上来理解，很难理解它本身包含的意义，软件性能是个比较大的概念，它是一个具体的软件系统在既定环境下运行时对效率的衡量。人们一般用“性能测试”来检验被测试软件系统或构件对于其设计目标的符合程度。对一个纯粹的应用系统而言，最为软件从事人员熟悉的“性能”经常会被描述成：“某一段时间中所能完成的工作量”。比较常用的软件性能参数有响应时间和工作效率等的，应用程序在单位时间内完成的工作量越多，它的性能就越好。我们在这个工作量的概念往下层剖析，在预定的时间内通过程序把输入（数据）单位转换成为输出（数据）单位的数量。从这个意义上而言，这个问题仅仅是说明了性能的一个方面，那就是执行速度快。但性能问题还包含其他方面，如稳定性、系统资源开销等，在目前的日趋复杂的社会环境中，要保证一个软件具有比较好的“性能”，除了需要考虑很多技术问题外，还需要考虑更多非技术的因素。
有时正确的代码、正确的业务逻辑并不能保证项目的成功，性能往往是最后决定一个应用系统是否成功关键。为了追求商业上的利益，满足市场和消费者的要求，在现在的很多应用系统中，提供符合功能需求但不符合性能需求的软件是不能被接受的。但是在没有到投入商业生产的时候，系统真正的系统性能状况谁都不可能知道，这个就需要搭建测试环境进行测试，这是一个面都尽量模拟生产时可能发生的事情。性能测试可以发生在各个测试阶段中，一段重要的业务逻辑代码、重要的SQL语句，语句都可以进行单独的性能测试，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能完整的，全面的，从各个视角来检查一个系统的真正性能，这个关联的因素就更多了。
目前对性能测试没有明确的定义和标准，对从事这个工作的技术人员也基本没有一个基本的知识结构要求，一般的工作是，针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值。
跟其他行业的测试一样，软件性能测试也不例外，我们要实施软件测试的目的是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度，软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件性能测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是：Keep it simple but not too simple。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
有时正确的代码、正确的业务逻辑并不能保证项目的成功，性能往往是最后决定一个应用系统是否成功关键。为了追求商业上的利益，满足市场和消费者的要求，在现在的很多应用系统中，提供符合功能需求但不符合性能需求的软件是不能被接受的。但是在没有到投入商业生产的时候，系统真正的系统性能状况谁都不可能知道，这个就需要搭建测试环境进行测试，这是一个面都尽量模拟生产时可能发生的事情。性能测试可以发生在各个测试阶段中，一段重要的业务逻辑代码、重要的SQL语句，语句都可以进行单独的性能测试，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能完整的，全面的，从各个视角来检查一个系统的真正性能，这个关联的因素就更多了。
目前对性能测试没有明确的定义和标准，对从事这个工作的技术人员也基本没有一个基本的知识结构要求，一般的工作是，针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值。
跟其他行业的测试一样，软件性能测试也不例外，我们要实施软件测试的目的是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度，软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件性能测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是：Keep it simple but not too simple。
若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
一点感想------关于性能测试职业的
随着软件系统的规模日益庞大，结构日趋复杂，对软件系统的性能测试已经成为必须和趋势。尤其大型的分布式软件系统更要在正式运营前进行性能测试，因为这样的系统在投入生产之后，往往要处理大批量的业务量，这对应用程序本身，操作系统, 中心数据库服务器，中间件服务器，网络设备的处理能力可能是一个严峻的考验。在其中任意一个环节出现的问题都可能给用户带来巨大的经济上或其他方面的损失。预见软件系统的并发承受能力以避免商业风险，这是在软件测试阶段就应该解决的。
虽然软件测试是这么的重要，但是执行这个工作却是痛苦的，首先因为测试本身是一个非常枯燥和痛苦的事情，整天面对的一大堆繁杂的数据，谈不上“清爽和整洁”，即使你将这些数据都整理好，最后拿出可靠的测试报告出来后，也基本不可能有什么成就感，因为你测试的对象是别人的作品，而存在的问题也是别人修改好的，你所做的事情不过是帮他们找到了存在的问题，你做的再好也不过是给别人做嫁衣。但没有测试的话，很多软件不可能成为产品，至少不能成为优秀的产品，没有经过充分的测试，导致是国内大多数赶工期的软件产品错误百出的问题所在。其次是测试人员的感受是比较痛苦，国内大多数公司到目前为止，同样是做技术活，测试人员跟开发人员相比，在待遇等很多方面还是处于“二等公民”的状态。本来，国内软件从业人员的心态比较浮躁，测试人员的心态的浮躁程度在行业内应该是最高的，很多测试人员选择当一个“测试工程师”，是因为他的开发技术水平还不能充当一名“开发工程师”，很多公司也习惯将编写代码相对较差的人员“降格”为测试人员。很多测试人员在工作的时候有一种“技不如人”感觉，而暂时“屈”在测试部门的，在业务时间或工作相对闲暇的时候，他们很大多数人的很少去研究他所从事的测试技术的钻研，而去学习和研究软件开发编码技术。相反，在软件产业比较发达的美国和印度，他们都是的测试人员大多是技术好、经验丰富的人员组成。这个不能不说是国内软件开发行业的一个怪象。当较为优秀的人才都离开了测试而都去做开发的时候，测试人员将永远由一些初学者和技术相对比较差的人员组成，而且大家都心不在焉的时候，要打造优秀的国产软件产品根本就无从谈起。
性能测试的对象一般是一个完整的应用系统，而这个应用系统又是建立在特定的操作系统之上，连接这些机器的又有网络和一些网络设备。在测试过程中，需要测试工程师对系统出现的问题有个比较准确的定位和分析，这样才能跟开发工程师、网络工程师进行有效的沟通，方便它们定位到更具体的问题。这就需要性能测试工程师不仅要熟练的使用测试工具，还应该程序设计、开发工具以及应用平台，软件构架，数据库以及网络等方面的知识。当然，最重要的一个是对系统可能出现的系统瓶颈的职业敏感，并且能综合利用所掌握的知识，设计出行之有效的测试用例，能尽快、最大程度的发现和解决系统存在的错误和缺陷。
若需转载或其他需要，请跟作者朱汉强联系：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
虽然软件测试是这么的重要，但是执行这个工作却是痛苦的，首先因为测试本身是一个非常枯燥和痛苦的事情，整天面对的一大堆繁杂的数据，谈不上“清爽和整洁”，即使你将这些数据都整理好，最后拿出可靠的测试报告出来后，也基本不可能有什么成就感，因为你测试的对象是别人的作品，而存在的问题也是别人修改好的，你所做的事情不过是帮他们找到了存在的问题，你做的再好也不过是给别人做嫁衣。但没有测试的话，很多软件不可能成为产品，至少不能成为优秀的产品，没有经过充分的测试，导致是国内大多数赶工期的软件产品错误百出的问题所在。其次是测试人员的感受是比较痛苦，国内大多数公司到目前为止，同样是做技术活，测试人员跟开发人员相比，在待遇等很多方面还是处于“二等公民”的状态。本来，国内软件从业人员的心态比较浮躁，测试人员的心态的浮躁程度在行业内应该是最高的，很多测试人员选择当一个“测试工程师”，是因为他的开发技术水平还不能充当一名“开发工程师”，很多公司也习惯将编写代码相对较差的人员“降格”为测试人员。很多测试人员在工作的时候有一种“技不如人”感觉，而暂时“屈”在测试部门的，在业务时间或工作相对闲暇的时候，他们很大多数人的很少去研究他所从事的测试技术的钻研，而去学习和研究软件开发编码技术。相反，在软件产业比较发达的美国和印度，他们都是的测试人员大多是技术好、经验丰富的人员组成。这个不能不说是国内软件开发行业的一个怪象。当较为优秀的人才都离开了测试而都去做开发的时候，测试人员将永远由一些初学者和技术相对比较差的人员组成，而且大家都心不在焉的时候，要打造优秀的国产软件产品根本就无从谈起。
性能测试的对象一般是一个完整的应用系统，而这个应用系统又是建立在特定的操作系统之上，连接这些机器的又有网络和一些网络设备。在测试过程中，需要测试工程师对系统出现的问题有个比较准确的定位和分析，这样才能跟开发工程师、网络工程师进行有效的沟通，方便它们定位到更具体的问题。这就需要性能测试工程师不仅要熟练的使用测试工具，还应该程序设计、开发工具以及应用平台，软件构架，数据库以及网络等方面的知识。当然，最重要的一个是对系统可能出现的系统瓶颈的职业敏感，并且能综合利用所掌握的知识，设计出行之有效的测试用例，能尽快、最大程度的发现和解决系统存在的错误和缺陷。
若需转载或其他需要，请跟作者朱汉强联系：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
2008年8月12日
可能影响系统并发处理性能的因素
1 应用服务的配置部署
应用服务的整合方法，每个服务所起的个数，不同服务的优先级设置等诸多部署，都会对系统的并发处理能力产生影响。
2 数据库表的配置
每个数据库表的锁模式（页面锁或记录锁）、以及索引的策略也是影响应用系统并发处理能力的一个因素。
3 中间件的并发处理能力
中间件对服务的并发处理能力，以及中间件的配置方法对系统并发处理能力的影响，也是决定应用系统并发处理能力的一个因素。
4 进程数
负载越大，产生的进程数越多，过多的进程数是否会对系统的性能产生影响，也是影响系统并发处理能力的一个因素。
5 网络连接数
网络的连接数过多对系统性能的影响情况，也是影响系统并发处理能力的一个因素。
6 磁盘I/O的处理能力
负载情况下会产生大量的磁盘I/O操作，因此磁盘I/O的处理能力是影响应用系统并发处理能力的一个因素。
7 CPU
负载情况下会消耗大量的CPU资源，有可能会影响应用系统的并发处理能力。
8 服务堆积情况
负载测试时会有一定的服务堆积情况，并占用系统的消息队列资源，也有可能对应用系统的并发处理能力产生影响。
9 文件处理能力
一些业务需要生成相应的文件，而在负载测试时会导致同一个路径下生成大量的文件，也有可能对应用系统的并发处理能力产生影响。
若需转载或其他需要，请跟作者朱汉强联系：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
应用服务的整合方法，每个服务所起的个数，不同服务的优先级设置等诸多部署，都会对系统的并发处理能力产生影响。
2 数据库表的配置
每个数据库表的锁模式（页面锁或记录锁）、以及索引的策略也是影响应用系统并发处理能力的一个因素。
3 中间件的并发处理能力
中间件对服务的并发处理能力，以及中间件的配置方法对系统并发处理能力的影响，也是决定应用系统并发处理能力的一个因素。
4 进程数
负载越大，产生的进程数越多，过多的进程数是否会对系统的性能产生影响，也是影响系统并发处理能力的一个因素。
5 网络连接数
网络的连接数过多对系统性能的影响情况，也是影响系统并发处理能力的一个因素。
6 磁盘I/O的处理能力
负载情况下会产生大量的磁盘I/O操作，因此磁盘I/O的处理能力是影响应用系统并发处理能力的一个因素。
7 CPU
负载情况下会消耗大量的CPU资源，有可能会影响应用系统的并发处理能力。
8 服务堆积情况
负载测试时会有一定的服务堆积情况，并占用系统的消息队列资源，也有可能对应用系统的并发处理能力产生影响。
9 文件处理能力
一些业务需要生成相应的文件，而在负载测试时会导致同一个路径下生成大量的文件，也有可能对应用系统的并发处理能力产生影响。
若需转载或其他需要，请跟作者朱汉强联系：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
软件性能测试之 测试时间
我们经常理解的系统的性能就是“能稳定运行多少天，而不出任何故障”，这个指标我怀疑是从传统工业产品中直接生吞活剥过来的，如很多家用电器，还有一些服务器，就经常打出这样的宣传广告。这个指标虽然来路有点不是很明白，但不影响软件测试人员对它套用在软件产品性能上的诠释。在计算机硬件能达到像现在这个运行速度的今天，除非你的运行环境配置是非常离谱的不合理，同时软件系统的代码也是写的超级糟糕，数据库相关表的记录数以T为基本单位来计算，否则运行一个即使是很冗长的测试用例最长也不会超过30分钟。要实现“能稳定运行多少天”的目的的话，或许你很容易就可以猜到，能让应用系统带“负载”运行多少天的基本方法就是－重复，多次的重才能构成应用系统长时间的运行的条件。
测试执行的重复就是一遍又一遍毫不间断地执行某个操作或功能，让系统在处理完一个请求后马上就处理新的请求。系统刚处理完一个请求，可能还没有来得及释放刚才那个请求所占用的资源，马上又接到新的请求的话，还能不能正常释放上一个请求所占用的资源。应用系统在这样的条件下会不会在响应时间变慢甚至功能上发生混乱。
比如执行一个脚本一遍需要30秒，如果想让系统执行12个小时，就在该测试用例的测试“场景”上设置让该测试用例重复执行1440遍。如果要让这个系统运行多少天，运行的遍数如此类推就可以了。这个所谓的重复虽然简单，却是发现问题的最有效的方法之一，因为在一个应用系统投入运营之后，它也是这样重复的接受用户的请求的。接连不断重复的次数多，才能完成数量的积累，才能发现隐藏的比较深的问题，如许多隐蔽的代码错误、系统连接数被消耗殆尽、线程泄漏、内存泄漏等等。
在这里我们将这个问题稍微扩展一下。简单重复能发现问题是真实不虚的，但针对不同的测试用例，在执行之前，应该评估一下执行多少遍或多长时间已经足够暴露系统可能存在的问题。免得但不是特别重要的测试用例，浪费了宝贵的执行时间。例如对一个B/S系统进行压力测试的时候，首先执行的一般是网站首页，同时这个首页的页面是静态网页的话，这样的测试用例就可以不用运行这么多天，或许有几个小时的重复负载测试就可以了。对比较复杂业务逻辑的测试用例，倒是可以将时间安排的稍微长一些。如何安排这些测试用例的执行时间，应该在测试方案中就规划好。
如需转载，请跟作者联系。johannes_zhu@yahoo.com。
广州易标软件技术有限公司为您提供高质量的软件测试服务。
欢迎访问：http://www.3rdtest.com。
测试执行的重复就是一遍又一遍毫不间断地执行某个操作或功能，让系统在处理完一个请求后马上就处理新的请求。系统刚处理完一个请求，可能还没有来得及释放刚才那个请求所占用的资源，马上又接到新的请求的话，还能不能正常释放上一个请求所占用的资源。应用系统在这样的条件下会不会在响应时间变慢甚至功能上发生混乱。
比如执行一个脚本一遍需要30秒，如果想让系统执行12个小时，就在该测试用例的测试“场景”上设置让该测试用例重复执行1440遍。如果要让这个系统运行多少天，运行的遍数如此类推就可以了。这个所谓的重复虽然简单，却是发现问题的最有效的方法之一，因为在一个应用系统投入运营之后，它也是这样重复的接受用户的请求的。接连不断重复的次数多，才能完成数量的积累，才能发现隐藏的比较深的问题，如许多隐蔽的代码错误、系统连接数被消耗殆尽、线程泄漏、内存泄漏等等。
在这里我们将这个问题稍微扩展一下。简单重复能发现问题是真实不虚的，但针对不同的测试用例，在执行之前，应该评估一下执行多少遍或多长时间已经足够暴露系统可能存在的问题。免得但不是特别重要的测试用例，浪费了宝贵的执行时间。例如对一个B/S系统进行压力测试的时候，首先执行的一般是网站首页，同时这个首页的页面是静态网页的话，这样的测试用例就可以不用运行这么多天，或许有几个小时的重复负载测试就可以了。对比较复杂业务逻辑的测试用例，倒是可以将时间安排的稍微长一些。如何安排这些测试用例的执行时间，应该在测试方案中就规划好。
如需转载，请跟作者联系。johannes_zhu@yahoo.com。
广州易标软件技术有限公司为您提供高质量的软件测试服务。
欢迎访问：http://www.3rdtest.com。
2008年8月11日
性能测试分析-CPU部分
性能测试中，首先要确定的是本测试用例的资源消耗类型，然后判断系统的处理速度，在Loadrunner里面这个即时处理速度的计数器是TPS(Transaction Per Second )。在这里假设本测试用例的资源消耗类型为CPU bound（限制）。对CPU的分析方法和步骤如下：
今天先写到这里，明天继续用文字描述。估计有点基础的同行能看懂八九不离十。
若需转载或其他需要，请跟作者朱汉强联系：johannes_zhu@yahoo.com。 广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。 欢迎访问：http://www.3rdtest.com/。
大型网络游戏自动化性能测试可行性分析
在普通的B/S或C/S结构的应用程序中，客户端跟服务端是简单的多对一关系，客户端之间是透明的。性能测试的方法一般是首先录制用户在客户端的操作过程，形成某种语言支持的脚本，将输入部分做成可以供调用的参数，然后模拟多用户重复的执行这些脚本，对输入每次调用相同或不同的数据。服务器端只是对来自客户端的请求做出相应的请求就可以了。
多人角色扮演网络游戏（MMORPG）是一种基于互联网上的C/S结构的应用程序，它包含了很多个系统，如：玩家系统、物品系统、技能系统、经验值/级别系统、 帮派/称号系统、 地图系统、NPC系统、 格斗系统 、交友聊天系统、交易系统 、行动/导航系统、 任务系统、定位系统、咨询系统、问答系统、博彩系统、人工智能等，这些多个系统共同作用，形成一个复杂的应用程序，对用户端一个细微的差异都会引起服务端极大差别的响应，在同一个区域的用户知道彼此存在的状态，这样，试图模仿多用户活动的没有办法操作，即使实现了这种设想操作的话，他的价值也仅仅在于“知道”服务端在这个条件下的性能状况。如果有性能缺陷的话，也无从知晓具体的原因，不知道到底是那个子系统过多占用了资源，要进行性能优化将无从下手。
让MMORPG客户端知道彼此存在需要服务器对客户端进行统一的数据同步，包含：用户，NPC，物品的属性、活动和状态，以及他们所在的地图位置、属性等，这些数据同步消息发出频率是每秒16帧或更多。同时，服务器中其他子系统会对活动的用户，NPC触发的事件做出响应，这些消息包含有“战斗”，“行走”，“聊天（即使通信）”，这些消息个体之间还存在极大的差别，还有需要消耗资源较多的就是“AI(人工智能)”。
玩家在不同子系统活动是可以单独存在的，一个可行的方法是将自动化测试用例从复杂的场景中抽取出来，每一个测试用例只对应测试一个单独子系统，让必须同时存在的子系统场景保持不变，隔离其他不必要的子系统，监控服务器为这个受测试的子系统所付出的开销。如在一个战斗的场景中，我们仅单独让用户和NPC仅拥有有“格斗”的活动能力，让用户、NPC固定好位置（地图的位置和属性不变），在一个不变的地图里一对一，或一对多进行战斗，在同一段时间里，同样等级用户用同样的技能进攻和防守，同样级别的NPC用都用相应同样的技能防守和进攻，随着测试的深入，将覆盖到所有级别的用户，所有级别的NPC和整个“格斗”系统里面所有的技能。
按照上面的分析，在测试中需要变化的内容有以下几个：
1. 用户角色和跟角色相关的性格和行为。
2. 不同级别用户及所相关联的属性；
3. 子系统；
4. 同一个子系统内部不同的功能；
5. NPC种类；
6. 不同种类NPC及所相关联的属性；
7．测试执行时间；（循环执行次数）
8. 并发量。
在测试中，需要设计的测试用例在不同的载体-地图系统里面，不同级别，不同角色的用户，使用不子系统里的所有或部分功能。NPC总是伴随着用户的活动而出现，在测试场景中控制好出现的种类以及它们的相关属性。对于执行时间跟并发量，可以在执行测试的时候根据实际情况而定。通过以上的方法，可以将测试用例扩展到网络游戏中所有的子系统，这样，通过“纵”和“ 深”两个方向的扫描，就可以发现和定位绝大部分的性能缺陷。
若需转载或其他需要，请跟作者朱汉强联系：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
多人角色扮演网络游戏（MMORPG）是一种基于互联网上的C/S结构的应用程序，它包含了很多个系统，如：玩家系统、物品系统、技能系统、经验值/级别系统、 帮派/称号系统、 地图系统、NPC系统、 格斗系统 、交友聊天系统、交易系统 、行动/导航系统、 任务系统、定位系统、咨询系统、问答系统、博彩系统、人工智能等，这些多个系统共同作用，形成一个复杂的应用程序，对用户端一个细微的差异都会引起服务端极大差别的响应，在同一个区域的用户知道彼此存在的状态，这样，试图模仿多用户活动的没有办法操作，即使实现了这种设想操作的话，他的价值也仅仅在于“知道”服务端在这个条件下的性能状况。如果有性能缺陷的话，也无从知晓具体的原因，不知道到底是那个子系统过多占用了资源，要进行性能优化将无从下手。
让MMORPG客户端知道彼此存在需要服务器对客户端进行统一的数据同步，包含：用户，NPC，物品的属性、活动和状态，以及他们所在的地图位置、属性等，这些数据同步消息发出频率是每秒16帧或更多。同时，服务器中其他子系统会对活动的用户，NPC触发的事件做出响应，这些消息包含有“战斗”，“行走”，“聊天（即使通信）”，这些消息个体之间还存在极大的差别，还有需要消耗资源较多的就是“AI(人工智能)”。
玩家在不同子系统活动是可以单独存在的，一个可行的方法是将自动化测试用例从复杂的场景中抽取出来，每一个测试用例只对应测试一个单独子系统，让必须同时存在的子系统场景保持不变，隔离其他不必要的子系统，监控服务器为这个受测试的子系统所付出的开销。如在一个战斗的场景中，我们仅单独让用户和NPC仅拥有有“格斗”的活动能力，让用户、NPC固定好位置（地图的位置和属性不变），在一个不变的地图里一对一，或一对多进行战斗，在同一段时间里，同样等级用户用同样的技能进攻和防守，同样级别的NPC用都用相应同样的技能防守和进攻，随着测试的深入，将覆盖到所有级别的用户，所有级别的NPC和整个“格斗”系统里面所有的技能。
按照上面的分析，在测试中需要变化的内容有以下几个：
1. 用户角色和跟角色相关的性格和行为。
2. 不同级别用户及所相关联的属性；
3. 子系统；
4. 同一个子系统内部不同的功能；
5. NPC种类；
6. 不同种类NPC及所相关联的属性；
7．测试执行时间；（循环执行次数）
8. 并发量。
在测试中，需要设计的测试用例在不同的载体-地图系统里面，不同级别，不同角色的用户，使用不子系统里的所有或部分功能。NPC总是伴随着用户的活动而出现，在测试场景中控制好出现的种类以及它们的相关属性。对于执行时间跟并发量，可以在执行测试的时候根据实际情况而定。通过以上的方法，可以将测试用例扩展到网络游戏中所有的子系统，这样，通过“纵”和“ 深”两个方向的扫描，就可以发现和定位绝大部分的性能缺陷。
若需转载或其他需要，请跟作者朱汉强联系：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。
订阅：
博文 (Atom)