服务器系统的性能测试

服务器系统的性能测试

摘 要：

软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情，另一方面是确认软件以正确的方式来做了这个事件。第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。本文就海量服务器的性能做用户登录的压力测试，设计此测试程序只是一个简单的多线程和网络程序，不用涉及线程同步和高级的网络模型就能达到测试目的。在测试程序实现过程中用到了WinSock API 和多线程的有关知识及SQL Server 数据库，文中介绍了一般的测试流程、简单常用的测试方法和网络聊天程序的服务器工作模式。重点是测试大量用户同时登录服务器时服务器所能承受的压力状况，该思想可用于大量基于TCP/IP 或UDP 协议的网络服务器。

()t i t A t E 02

2exp exp ),0(ωσπσπ-??

????-=

式中的 ω代表频率。

关键词：测试流程、性能测试、WinSock API 、服务器

Abstract ：

The software testing is the important component of software developing, is used to confirm whether a procedure quality or performance conform to some requests

proposed before the development. The purpose of the software testing: first, confirming the quality of software. On the one hand , software has done which you expected ;second, confirming software has done what you wanted by the correct way. Second ,The second is to provide the information .For example , feedback information for risk assessment. to the development personnel or procedure manager. The third ,software testing is to test not only the software product itself, but also the process of the software development .If there are many problems after software development,the process of software development is likely to be defective. We makes the pressure testing about the magnanimous server performance when the users register on this article ,and design this testing programme to be a simple multithreading and the network procedure. It can achieve the test goal and does not need to involve line regulation synchronization and the high-level network model . In the test process,we used WinSock API and the knowledge about multi-thread and the SQL server https://www.360docs.net/doc/7616514580.html,ed WinSock API and the multi-thread related knowledge and the SQL server database in the test order realization process. In the article we introduced the general testing flow, the simple and commonly testing method and the working pattern of network chat procedure server. The key point is to test the pressure condition when a lot of users simultaneously register the server, we can use this thought in network servers based on TCP/IP or the UDP agreement.

Keywords: flow of testing, ability testing, WinSock API, server

第一章引言

编程大师说：“任何一个程序，无论它多么小，总存在着错误。”初学者不相

信大师的话，他问：“如果一个程序小得只执行一个简单的功能，那会怎样？”“这样的一个程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生一个错误。”但初学者不满足，他问：“如果操作系统不失效，那么会怎样？”“没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生一个错误。”初学者仍不满足，再问：“如果硬件不失效，那么会怎样？”大师长叹一声道：“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是一个错误。”没有错误的程序世间难求。[James 1999]

错误是一种严重的程序缺陷。测试的目的是为了发现尽可能多的缺陷，并期望通过改错来把缺陷统统消灭，以期提高软件的质量医生可以把他的错误埋葬在地下了事，但程序员不能。我们必须要学会测试与改错，并且把测试与改错工作做好。

软件测试在中国目前的软件行业属于比较薄弱的一环,前些年,国内企业对产品的测试工作都不太重视,很少有人实施过海量服务器的性能测试工作。对于海量用户的大型服务器系统,在数百万或更高访问量的情况下,对服务器的稳定性、可靠性等方面有极高的要求,因此我们在开发这种类型的服务器系统上需要进行严格甚至苛刻的性能测试,以保证服务器能够承受极大用户量的同时访问。本课题就目前广联公司的eWork系统进行这种海量服务器的性能测试。

第二章测试简介

2.1 测试方法简介

2.1.1 测试方法分类

有一次文学考试，问高尔基是哪国人。一考生乐极而吟：“尔基啊尔基，你若不姓高，我怎知你是中国人。”这是一种瞎猜法。如果这种方法用于软件测试，人累死也测不出什么结果来。

软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。

不论是对软件的模块还是整个系统，总有共同的内容要测试，如正确性测试，容错性测试，性能与效率测试，易用性测试，文档测试等。“白盒测试”是指开发人员从程序内部对上述内容进行测试，而“黑盒测试”是指独立的测试人员从程序外部对上述内容进行测试。

正确性测试又称功能测试，它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素，所以其测试也最重要。基本的方法是构造一些合理输入，检查是否得到期望的输出。这是一种枚举方法。倘若枚举空间是无限的，那可惨了，还不如回家种土豆有盼头。测试人员一定要设法减少枚举的次数，否则没好日子过。关键在于寻找等价区间，因为在等价区间中，只需用任意值测试一次即可。

容错性测试是检查软件在异常条件下的行为。容错性好的软件能确保系统不发生无法意料的事故。

易用性测试没有一个量化的指标，主观性较强。调查表明，当用户不理解软件中的某个特性时，大多数人首先会向同事、朋友请教。要是再不起作用，就向产品支持部门打电话。只有30%的用户会查阅用户手册。[Cusumano 1995] 文档测试主要检查文档的正确性、完备性和可理解性。好多人甚至不知道文

档是软件的一个组成部分。正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。

2.1.2黑盒测试与白盒测试

黑盒测试顾名思义就是将被测系统看成一个黑盒，从外界取得输入，然后再输出。整个测试基于需求文档，看是否能满足需求文档中的所有要求。黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或经验，它适用于对系统的功能进行测试。

黑盒测试的优点有：

1）比较简单，不需要了解程序内部的代码及实现；

2）与软件的内部实现无关；

3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；

4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

5）在做软件自动化测试时较为方便。

黑盒测试的缺点有：

1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量30%；

2）自动化测试的复用性较低。

白盒测试是指在测试时能够了解被测对象的结构，可以查阅被测代码内容的测试工作。它需要知道程序内部的设计结构及具体的代码实现，并以此为基础来设计测试用例。如下例程序代码：

HRESULT Play( char* pszFileName )

{

if ( NULL == pszFileName )

return;

if ( STATE_OPENED == currentState )

{

PlayTheFile();

}

return;

}

读了代码之后可以知道，先要检查一个字符串是否为空，然后再根据播放器当前的状态来执行相应的动作。可以这样设计一些测试用例：比如字符串（文件）为空的话会出现什么情况；如果此时播放器的状态是文件刚打开，会是什么情况；如果文件已经在播放，再调用这个函数会是什么情况。也就是说，根据播放器内部状态的不同，可以设计很多不同的测试用例。这些是在纯粹做黑盒测试时不一定能做到的事情。

白盒测试的直接好处就是知道所设计的测试用例在代码级上哪些地方被忽略掉，它的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

白盒测试的缺点有：

1）程序运行会有很多不同的路径，不可能测试所有的运行路径；

2）测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；

3）系统庞大时，测试开销会非常大。

2.2 性能测试

2.2.1性能测试的概念

本课题主要研究eWork系统服务器承受能力来研究这种性能测试方案的可行性。

性能测试是在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体，它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该于性能测试一同进行。举例说明：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。压力测试是对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个Web 站点在大量的负荷下，何时系统的响应会退化或失败。压力测试注重的是外界不断施压，强度测试注重的是极限或者异常情况下系统的测试。

2.2.2 性能与效率测试

性能与效率测试主要是测试软件的运行速度和对资源的利用率。有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。

在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如计算机主频，总线结构和外部设备都可能影响软件的运行速度；若与多个计算机共享资源，软件运行可能慢得像蜗牛爬行。在获取测试的“相对值”时，我们要确保被测试的几个软件运行于完全一致的环境中。硬件环境的一致性比较容易做到（用同一台计算机即可）。但软件环境的因素较多，除了操作系统，程序设计语言和编译系统对软件的性能也会产生较大的影响。如果是比较几个算法的性能，就要求编程语言和编译器也完全一致。性能与效率测试中很重要的一项是极限测试，因为很多软件系统会在极限测试中崩溃。例如，连续不停地向服务器发请求，测试服务器是否会陷入死锁状态不能自拔；给程序输入特别大的数据，看看它是否吃得消。

2.3 压力测试

2.3.1压力测试的流程

压力测试的目的就是要通过搭建与实际使用环境相类似的测试环境, 用测试程序在同一时间内、或某一段时间内, 向系统发送预期数量的交易请求, 测试系统在不同压力情况下的效率状况, 以及系统可以承受的压力情况, 然后做针对性的测试与分析. 找到影响系统性能的瓶颈, 并根据该数据评估系统在实际使用环境下的效率情况, 作为评价系统性能、以及判断是否需要对应用系统进行优化处理或结构调整的依据, 然后对系统资源进行优化, 提高响应时间与吞吐量是压力测试的最终目的。

压力测试流程：（如图2.1）

图2.1压力测试流程

2.3.2编写压力测试计划

编写内容全面的、高质量的压力测试计划书是取得压力测试成功的关键。好的计划书能使压力测试具有全面性、针对性、有效性。为了完成测试计划书, 一定要与用户和开发人员交流, 了解掌握用户需求, 并把他贯彻于测试之中. 通过对需求的了解、对数据库应用系统的分析, 确定压力测试对象, 做到有的放矢；同时, 这些工作也是测试结果的分析的基础.编写计划书分为以下三个阶段: 分析应用系统

分析数据库应用系统的两个主要任务: 第一, 搞清系统对各个资源的分布与使用情况,它将帮我们确定可能系统性能的瓶颈；第二, 搞清用户事务的分布, 确

定压力测试的针对点。我们定义事务是用来表示用户要求服务器连续完成的操作任务。

因为大多数系统都是网络系统,而且网络常常也是降低响应时间的主要原因, 所以我们通过资源示意图来分析系统的资源。为了更详细的说明资源的性能, 我们要求对资源示意图中的每个资源的属性进行列表说明。例如, 对于路由器, 说明它运行的系统, 它的网络处理能力, 响应时间等; 对于通信媒介, 它的性能, 容量等；对于主机, 说明它的CPU 性能, 内存大小, I/O 外设性能, 运行的操作系统, 数据库系统, 应用软件系统, 还有运行应用软件系统的系统配置文件等；对于客户端, 它的CPU 性能, 内存大小, 操作系统版本, 应用软件系统客户端运行软件, 与主机通信机制, 及整个系统客户端的个数。

我们用事务分布图来分析实际用户的事务操作时间分布。用X 轴表示时间, 用Y 轴表示各个事务, (x, y) 表示在X 时刻, Y 事务操作的用户个数。我们举例如下(如图1.2)。

图2.2事务分布图

得到系统事务分布图后, 可以大致确定压力测试点, 压力测试一定要模拟用户事务操作最繁忙的时刻来进行. 对于上图中在12 点到2 点有210 个用户登录, 15 个用户在完成记帐操作, 180 个用户做创建记录操作, 30 个用户做查询操作, 90 个用户做数据更新操作. 与别的时刻相比这一段时间内户的事务比较繁忙, 我们应模拟这一时刻进行压力测试。根据实际情况, 也可以选几个点进行压力测试。

2）定义压力测试目标

在压力测试计划书中要定义我们测试的对象, 并对每一个测试对象给出清

晰说明，也要定义测试结束的目标。为控制测试的有效性以及完成程度, 必须定义准则和策略, 以判断何时结束测试阶段。准则必须是客观的, 可量化的, 而不能是经验或感觉。

3）评审修改压力测试计划

当压力测试计划书完成后, 应对其进行评审。压力测试计划书的评审人员应包括有经验的用户, 软件需求书的提交人员, 系统设计人员, 系统开发人员, 软件测试人员。然后根据评审意见修订并完成测试压力计划书。

有效的用例评审通常由下面两种形式组成：测试部门外部评审——主要是由开发部、项目实施部、甚至销售人员参加的评审，目的主要是查找测试工程师编写的用例是否缺少内容。一般采用非正式评审的形式进行，因为很难把开发人员组织在一起，通常他们开发进度通常很大，他们能够抽出时间看您的文档已经是“很给面子了”。当然不统一进行会耽误评审的进度，所以在实际工作中如果时间紧迫可以提前启动测试，待评审完成后进行用例的修改工作。通常测试工作进行一段时间评审就会结束，这个时候测试执行人员可以在工作中对测试用例的内容进行动态的调整，再次执行已经执行过的并且进行修改的部分用例。（如果能够采用正式评审效果肯定更好。）测试部门内部评审——部门内部同行对测试策略的评审，中心是测试策略和用例编制思路是否正确，以次来保证测试用例的有效性。可以组织正式的评审，由用例的设计人员进行讲解，然后大家共同评审；也可以把文档发给部门的同事进行评审。内部评审有些象开发人员在单元测试中交叉测试。其中的外部评审最重要，因为开发人员很容易发现您的用例遗漏了什么内容没有编制进去，同时还可以发现错误的用例——因为您可能对需求理解存在偏差。用例外部评审可以理解为开发人员在查找您的“程序”的缺陷。通常情况下先执行内部评审，然后执行外部评审。很多时候，内部评审会被忽略，建议要进行内部评审。这样至少有两个好处：集思广益和提高测试小组输出文档的质量。

2.3.3用多线程模拟多用户(设置测试数据)

压力测试的执行通常是通过工具执行脚本语言, 具有灵活性, 可修改性, 是发展的主流方向, 它的思想是通过多进程运行相同或不同的测试脚本, 来模拟多个用户执行相同或不同的任务, 实现压力测试。压力测试软件采用解释测试脚本语言实现的, 脚本中包含测试工具中使用的指令和数据, 并包含有控制信息。

压力测试脚本采取数据驱动方式。为了让所有的进程顺利执行, 必须对测试数据进行参数化。参数化的方法如下:

1) 找到需要参数化的域，可以通过比较测试脚本, 找到需要参数化的域。比如, 我们比较执行同一事务的两个可运行的脚本, 它们不同之处, 常常是需要参数化的域；

2) 合理的设置输入数据，同时运行的一组测试数据有时需要彼此是唯一的, 有时需要顺序的, 有时需要随机的,有时需要数据在一个区间内, 有时需要从数据库的某个表提取数据。参数化后的数据与原数据类型应保持一致。应根据情况, 具体问题具体分析。设置测试数据的灵活性很大, 对测试的结果影响也很大, 需要仔细分析设计。

2.3.4 设置并发点

一个测试脚本常常包含多个事务, 即使多个进程同时运行同一个脚本, 也难以保证脚本内的某个事务同时运行, 这将影响我们对这个事务的响应时间的测试。为了解决这个问题, 我们设置并发点, 先运行到并发点的进程将等待, 当所有进程都运行到并发点时, 我们进行释放, 使所有的进程同时运行同一个事务, 这样我们就可以测定与实际比较接近的响应时间. 我们可以设置多个并发点, 对多个事务的响应时间进行测试。

2.3.5 运行测试程序并监测系统资源

当准备好测试案例与测试脚本后, 就可以运行测试程序, 进行压力测试。有时, 还需要根据运行情况, 增加或减少并发的进程。在测试运行时, 要对一些结果进行自动记录, 它们一般都是一些与时间有关的数据。在运行压力测试时的另一个任务就是监测系统资源, 可以使用一些工具来监视并记录资源使用情况。监测的对象有: 网络传输情况；主机CPU 使用情况；内存使用情况；缓存使用情况；数据库系统中的数据锁；回滚段；重做日志缓冲区等。

分析结果

压力测试运行结束后, 把所有记录的数据汇总并记录到文件中. 必须对测试的结果进行分析, 才能得到结论。可以使用一些图形来比较、观察测试结果。分析对象也是测试运行时记录的内容, 下面是压力测试的分析对象:

1) 测试使用的时间和被测事务的响应时间(有多少个用户同时运行)；

2) 压力测试参与的进程个数, 成功个数, 失败个数；

3) 压力测试参与进程失败的原因。如设置失败、执行错误、网络连接失败、测试数据不合理等；

4) 事务的响应时间随用户增加的变化图；

5) 资源限制。

2.3