发表于：2018-07-17 作者：swiminger 来源：网络转载

　　性能测试不能没有并行, 为什么?
　　首先,为了模拟器, 性能测试一定需要模拟多个终端,并行是最好的方案；
　　其次,为了性能, 如果没有性能上的压力,就不是性能测试了.
　　并行是一个大课题,需要分几部分来考虑, 第一是硬件平台, 第二是软件平台(操作系统), 第三是软件架构.
　　第一,并行计算机可以有两种, 一种是集群式的, 比如机框的板卡, 刀片式服务器,还有就是多个普通PC搭建成的集群网络, 一种是多处理器的, 一般都是SMP, 还有多核CPU的.
　　第二,软件平台而言, 可以是一个支持并行的OS(WIN 或者LINUX, UNIX), 也可以是一种虚拟机,比如JVM.软件平台提供的是并行的开发库,运行库,资源管理与调度.通信平台也是很重要的.并行系统中的各个并行过程在通信上如果不能达到高效的要求, 并行就没有了意义.
　　第三, 软件架构, 对实际应用而言, 软件需要设计成可并行的架构模式.比如多进程或多线程.或者两者并有.多进程的好处是调试阶段出了问题时定位方便, 而多线程如果一个线程CORE DUMP, 那么整个进程被退出, 定位问题就难了.
　　软件架构最重要的是并行算法设计,可以采用Foster的设计方法, 分四步来进行并行算法设计, 第一步:划分,第二步:通信, 第三步:聚集, 第四步: 映射.
　　性能测试中的数据
　　性能测试是为了得出一个结果, 这个结果有可能是测试对象已经出现了问题, 或者是得到一批数据.这些数据不能马上就能看出测试对象有没有问题, 有时候还不能评定是测试工具的错还是测试对象的错.这时候数据尤其重要.
　　性能测试中的数据, 包括有:
　　1). 测试对象的运行过程的统计数据, 日志文件,数据库记录, 状态信息等,这些数据是在测试对象正常运行过程中产生的.
　　2). 测试工具的运行过程的统计数据, 日志文件等,这些数据也是在测试工具正常运行过程中产生的, 当测试工具运行出了问题时, 这些数据就不再可信.
　　性能测试一个CASE结束, 首先就是看测试对象的状态正不正常, 测试工具的状态正不正常, 如何没有问题, 则可以初步认为双方输出的统计数据是有效的,在某种程度上是可信的.第二步就是将双方的数据进行对比, 如何要对比就需要考虑双方的数据项是否有可比性的问题, 统计数据应该是基于双方在通信共有部分, 排除各自私有的统计.另外还要进行单位的统一.对统计的有效区间进行检验, 每秒的统计数据与每小时的统计数据以及每个CASE,每个用户的统计数据需要分开.测试工具的统计数据有可能只是一个模拟器上的统计, 那就需要将多个模拟器的数据进行汇总后才能与测试对象的统计进行对比. 最后得出结论, 双方是否有运行缺陷, 以及测试对象的性能报告.
　　测试对象的性能报告中, 应该包含有如下信息:系统的容量, 处理能力, 带宽及吞吐量, 可靠性, 稳定性, 当前面的项目都通过时, 测试人员还有一个很重要的工作就是通过统计数据(测试工具的也好, 测试对象的也好)来分析出测试对象的处理瓶颈的大概范围(系统的模块), 这样可以提供给开发人员一个很好的提示作用.
　　另外,有个问题是性能测试中非常重要的问题, 测试人员设计的测试用例如果没有遵循实际应用的环境, 那么得出的结论(比如性能瓶颈提示)就会对开发人员有误导作用, 开发人员因为在性能优化时常常会有两难的选择, 如果为了作某一方面的优化就会把相关方面的性能降低, 到最后就是积重难返了. 测试用例设计的重要性可见一斑.
　　定时器框架的设计是性能测试工具开发的重心
　　性能测试在一定程序上也是自动化测试, 在大量用户及数据的情况下, 是以一定速度的自动的运行某些功能.如何驱动以及管理这种自动的过程,是测试工具中非常重要的设计考虑.
　　定时器分为两种, 一种是通信交互上的等待对方应答的定时器, 一种是自动化中驱动信令面及数据面的定时器.
　　第一种定时器而言,
　　特点是粒度小, 只在通信交互过程中有效,在用户信令面中,在进行协商,认证,鉴权过程,会有N次请求应答对, 这中间都需要有等待定时器,定时器的时间长短可以不一样,但它是与用户相关的, 每一个用户都是独自占有一个定时器, 所以定时器的数量与用户数成正比. 这些定时器一般是用数组实现，但超时的轮询机制算法需要考虑实际的测试模型来提高性能，避免给正常的测试带来影响，拖了后腿。
　　第二种定时器
　　是测试所需要的, 由一个总的定时器来驱动, 选择用户,另外每一个用户也需要一个定时器来等待用户上线的结果, 即每一个用户的状态变迁需要由定时器来等待具体功能的实现结果.当用户成功上线后, 它进入数据面状态时,也是需要一个定时器来驱动这个用户的自动发送数据的, 它的数量与用户数是对应的.
　　如上两种定时器的创建,停止与销毁都是要管理的,有些实现是提供一个代码框架平台, 在代码上统一API, 在运行时就用一个实体(可能是线程)来中断地检测超时并触发消息到相应用户的状态机中作相应的处理.而当用户量上升上到一个层次时,这就会形成瓶颈.例如:在一个用户每秒发送N个数据包的功能需求下, 一个定时检测线程要轮询检查上万个用户的超时状态, 在一秒内轮询完成所有用户的状态真是有点困难.因为一个线程在一个CPU上是一个流水线的处理, 没有并行性. 而在这个思路下设计出来的定时器代码框架就不能满足要求了.
　　补充:
　　定时器可以进一步细分, 实时性要求高的定时器和实时性要求不高的,比如用户上线后的定时发包, 是实时性要求很高的, 它要求在每秒内都要发出定量的包, 那么定时器的精确度应该在秒以内, 延时就会产生连锁反应, 大量用户在每秒发包的情况下更是考验定时器实现的实时能力.另外如等待超时响应的定时器实时性要求就没那么高, 前一秒与后一秒检查到超时,对流程及测试目标的影响微乎其微.所以定时器框架的设计是性能测试的重心.
　　性能测试时, 速度就是测试的核心, 它可以分为信令速度和数据速度.
　　1).信令速度:
　　是指一个用户通过与测试对象的协商,认证,授权后,成功上线的速度. 单位一般是用户每秒, 就是每秒最多可以有多少用户成功通过以上过程, 以及失败率为多少, 还有，最大的用户容量也是测试指标之一.
　　2).数据速度:
　　是指一个用户成功上线之后,上行或下行,或都两都有时,通过测试对象的数据包数量和大小.单位一般是每个用户每秒发多少个数据包, 每个数据的长度大小.数据包的数量测试的是测试对象的转发能力或者处理能力, 数据包的大小测试的是测试对象的吞吐量.
　　3).两种速度混合:
　　就是一定量的用户以某一速度不断上线(每秒N个用户上线), 上线后立即发包, 这样时间越往后, 后面上线的用户就在一个越大的数据背景上进行信令的交互, 更加测试了测试对象的处理能力.
　　用户管理
　　性能测试时, 模拟器只是模拟与测试对象直连的物理设备, 而性能测试过程必然需要大量的用户, 测试工具就是需要在最少的资源下模拟出最多的用户量(对于测试对象而言, 有总容量).
　　对用户管理,需要有三个重要的设计,第一是用户数据的产生, 大量用户需要自动产生, 而且需要能在测试对象的认证中通过.第二,是用户数据在运行过程的分配, 是所有的用户都映射到一个模拟器上, 还是不同用户分配到不同的模拟器中, 更加难的是, 用户如何在不同的模拟器间切换(在测试对象能感知并业务平滑切换).第三,是在并行计算机环境下, 如何将用户分解到不同的CPU上进行处理, 提高吞吐量.并行程序的设计也是很重要的一个问题.它决定整个测试工具的优与劣.
　　测试性能的时候, 搭建环境会有两种模式:
　　第一种,树型连接
　　这种连接方式,特点是模拟器有多个物理设备, 但测试对象只有一个对外物理接口, 测试就是在一种多对一的环境下进行, 对测试对象而言, 压力点在于并发的处理能力上.而性能测试工具设计时, 一个重要的问题就是考虑如何用最少的物理设备模拟出最多的模拟器出来, 比如用多网口的多CPU单机来实现就可以在一个物理设备上模拟出多个模拟器, 但并发性并没有减少, 因为多个网口可以产生多个网线的速度, 而每个网线是独占式的, 到测试对象这一端时, 刚好形成汇聚, 集中在一条网线上的压力就大了, 对测试对象的处理极限是有很多的效果.
　　第二种, 星型连接
　　这种连接方式的特点是测试对象有多个物理接口, 它与模拟器就是一对一的测试环境, 物理上对等, 那么在测试工具设计时, 很重要的一点就是要怎样尽量提高模拟器的性能, 多台物理设备是必然选择, 不然模拟器的CPU比不过测试对象设备的CPU就不能形成压力, 测试就显得没有底气.
　　总的来说, 要做性能测试, 测试工具的设计原则就是创造和利用一切可以形成不对等的性能优势.