【IT168 技术文章】

    项目的情况简介：

    项目属于客户端/服务端模式产品，要求每个服务端能支持连接500个客户端

    测试环境简介：

    服务端支持三级连接模式，每个服务端能支持连接500个客户端，总要求支持大约5000个客户端。

    测试的过程描述：
   
    在测试实验室中，只能搭建10个客户端的环境以及三级连接的环境。服务端初次连接客户端后，客户端会保留服务端的IP地址。下次客户端机器启动时，会自己连接服务端。每次连接属于短连接。在产生事件时，客户端会自己上报给服务端。

    测试过程遇到的问题：

    在实验室中测试系统稳定可用，但在用户那里遇到服务端异常退出。

    问题分析：

    客户端同时大量上报事件时，服务端处理出问题，导致系统异常退出。

    希望寻求的帮助：
   
    如何模拟多客户端问题？如何进行产品的性能测试？如何保证产品的稳定性？

    相关分析

    分析一：

    分析内容：
   
    很简单，这种情况，用loadrunner最合适了，用loadrunner这种压力测试工具，模拟多用户环境，不知道你们是用什么语言开发，如果是java的甚至可以利用loadrunner的Tunning组件，达到代码级的调优。如果是C#.net,那很要等啦，Mercury同意支持C＃.net，但支持版本还没有出来。我在给你个建议，找个系统整合专家，看看是不是他们的网络有问题，或者是服务器没有调试好。有时候，机子CPU多，没有调试好，可能大量的CPU资源用于频繁的调度，而造成系统异常。有时候，还要改进算法。这种系统调试最麻烦了！

    分析二：

    分析内容：

    个人意见：对这个问题的分析应该考虑两个层次：

    1、解决现有问题的层次；

    2、探讨测试不充分问题产生的根源并从根源上避免此类问题的发生。

    这个问题本身是比较好解决的，在现场出现问题后，我们要做的是利用实验室的环境（或者现场的环境）确定问题产生的原因，从例子的描述来看，应该是在客户端大量建立连接时服务端无法支持，产生异常退出。对该问题的定位可以用LR等性能测试工具（或是自己编写的工具）模拟进行大并发量的突发连接测试，并据此给出改进的方法。

    其次我们还应该探讨测试不充分问题产生的根源。在这个例子中，由于设备不足够，可能根本就没有进行压力和负载测试，这本身就留下了隐患。其次，作为测试负责人，对这种项目的经验不足，一般来说，基于短连接方式的C/S结构应用最大的可能出问题的地方就是大量用户同时进行连接操作，即使没有环境在实验室中进行测试，也必须把这个作为一个大的项目风险列出，要求在交付最终用户使用前进行这类测试。

    主要分析

    本案中，作者的描述有些歧义：

    1、“三级连接模式”，不知道是不是有服务器，有端站，有客户端的模式，还是采用了服务器集群，多台服务器分三级级连。

    2、“每个服务端能支持连接500个客户端，总要求支持大约5000个客户端。”

    3、“服务端初次连接客户端，”这个不知道是不是应该是“客户端初次连接服务端”，而书写的当时，思维太快了，手没跟上，请教开发工程师都说“一般都是客户端去连接服务端的“拉”模式，而极少服务端向客户端“推”的模式。”

    4、“在产生事件时，客户端会自己上报给服务端”，不知道是不是以发送日志文件的形式上报。

    5、“在实验室中测试系统稳定可用”，实验室中测试是不是只有10个端站的情况下，而并没有采用任何的测试工具来做模拟端站和用户，已达到实际需要的量级。

    6、“下次客户端机器启动时，会自己连接服务端。”这个连接，是指自动登录还是会同步数据或者仅是网络连接？

    所以，对于本案编者只能按照性能测试的一般做法做一个介绍，不能详细的分析本案为什么会出现了不稳定运行的状况了，希望能对本案作者及遇到相同问题，或者准备做性能测试的同行们有所启发。

    首先，我们为什么做性能测试呢？
    性能测试的目的：

    一、评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的数据处理能力，并帮助作出决策。

    二、识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。

    三、系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。

    四、验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

    性能测试类型包括：

    负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
   
    强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。
   
    容量测试：确定系统可处理同时在线的最大用户数

    性能测试观察指标：

    性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

    在实际中作中我们经常会对两种类型软件进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？Bs结构程序一般会关注的通用指标如下（简）：

    Web服务器指标指标：

    1、   Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

    2、   Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；

    3、   Successful Rounds：成功的请求；

    4、   Failed Rounds ：失败的请求；

    5、   Successful Hits ：成功的点击次数；

    6、   Failed Hits ：失败的点击次数；

    7、   Hits Per Second ：每秒点击次数；

    8、   Successful Hits Per Second ：每秒成功的点击次数；

    9、   Failed Hits Per Second ：每秒失败的点击次数；

    10、Attempted Connections ：尝试链接数；

    11、CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：

    12、User 0 Connections ：用户连接数，也就是数据库的连接数量；

    13、Number of deadlocks：数据库死锁；
   
    14、Butter Cache hit ：数据库Cache的命中情况

    当然，在实际中我们还会察看多用户测试情况下的内存，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。

    性能测试的流程步骤

    和做其他的测试没有什么区别，做性能测试也要如下步骤来做：

    1、   测试需求分析

    2、   测试设计

    3、   测试脚本开发

    4、   测试实施

    5、   测试结果分析

    测试需求分析，性能测试（或者其他的测试）做的好与坏完全取决于测试分析做得好不好。软件最终始要被应用的，要在应用的实践中考验，所以，任何类型的测试分析都要以实际业务的要求为依据。那么，性能测试的测试需求分析都需要分析哪些内容呢？

    1、   性能测试的需求来源。客户需求和期望，实际业务需求，系统需求。
   
    2、   业务数据量级，要根据实际业务分析可能出现数据吞吐瓶颈的地方，比如本案中作者提到的要求每个服务端连接500个客户端，总要求连接5000个客户端。分析到这个程度还不够，还要进一步分析业务操作集中的点，时间段和量。如，本案中客户端开启会自动连接服务端，那么在每天开始上班的时候客户端的开启就会出现峰值，可能会持续20分钟，服务端需要响应客户端的连接请求，请求还可能并发至少 5000/120次每秒，同时短时间内集中请求的频率也是有阈值限制的。

    3、   系统架构，在每种不同的系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。我们不可能对每种技术都详细解说，这里只是介绍一种方法提供给你如何选择测试策略，从而帮助分析软件不同部分的性能指标，进而分析出整体架构的性能指标和性能瓶颈。

    4、   测试策略和评估标准，任何测试的目的都是确保软件符合预先规定的目标和要求。性能测试也不例外。所以必须制定一套标准。通常性能测试有四种模型技术可用于评估：

    * 线性投射：用大量的过去的，扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况对比。

    * 分析模型：用排队论公式和算法预测响应时间，利用描述工作量的数据和系统本质关联起来

    * 模仿：模仿实际用户的使用方法测试你的系统

    * 基准：定义测试和你最初的测试作为标准，利用它和所有后来进行的测试结果进行对比

    测试设计，测试设计是在了解软件业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可能发现软件的性能瓶颈。

    测试脚本开发，性能测试是通过工具，模拟大量用户操作，对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过winsock,http等协议纪录用户操作。而协议选择是基于软件的系统架构实现（web一般选择http协议,cs选择winsock协议），不同的性能测试工具，脚本语言也不同，比如rational robot中vu脚本用类c语言实现。

    开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软件架构的性能测试工具。

    测试结果分析，运行测试用例后，收集相关信息，进行数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网络带宽，流量对用户操作响应的影响，而cs结构我们可能更关心会系统整体配置对用户操作的影响。

    希望能对大家做性能测试有所启发。