该案例是某省电信公司的业务系统的性能测试。该业务系统用于管理省电信公司的所有电信交换机设备，业务系统的重点在于4个方面：从交换机定期获取并处理话务报告；接收交换机发出的告警消息；允许用户通过应用界面对交换机进行操作（发送命令）；允许其他业务系统发送的交换机操作要求通过网关的处理后转换成相应的交换机命令并下发。
由于该业务系统是电信运营商的核心支撑业务系统，因此用户对该系统的稳定性非常关注，要求系统能够7×24小时不间断运行，在最终决定的系统方案中，也为该系统的采集服务器进行了N+1的冗余配置，为应用服务器和数据库服务器进行了1+1的冗余配置。
对业务系统的性能测试是在开发接近完成时进行的，主要目的包括几个方面：验证系统是否达到了预期的性能指标；验证系统是否能稳定运行；验证系统的失效恢复方案是否有效；在测试过程中有针对性的进行部分调优工作，以保证系统能够达到预期的性能要求。
该项目的最大特点是选用的架构复杂，使用的协议基本上都是基于TCP/IP的自定义协议。该业务系统需要使用多种中间平台，所以架构设计为一个复杂的分层结构。另一方面，应用各模块之间的通信方式也比较复杂，考虑到与其他系统的接口，该业务系统采用了多种基于TCP/IP的自定义协议。
对性能测试来说，本系统的一个重要特点是系统涉及较多的外部设备（交换机等），而这些设备由于是用户的实际生产设备，不可能按照测试的要求对其进行设置和操作，必须通过一定的手段来模拟这些外部设备。
该系统的另一个特点是性能测试关注的内容中交互界面很少，除了用户下发命令外，其他的性能测试关注内容都没有人工交互的干预，因此，测试中对系统性能的体现主要是业务处理能力，只在用户下发命令这一个方面用响应时间来描述系统性能表现。
图1简单描述了该业务系统。
图1
从图1中可以看到，该业务系统是一个全省集中的处理系统，系统管理的话务交换机设备通过MOXA设备(1)转接或是直接通过省电信公司的网络传输的话务交换机设备通过MOXA到省电信中心的中心机房，所有服务器都放置在中心机房，通过网络交换设备进入电信公司的网络。为了保证系统的稳定运行，将服务器进行了分组管理，每组都设置了一台设备进行热备份。
由于这里给出的话务交换机设备都是实际在网运行的设备，因此，在实际的测试中，不可能利用这些实际的话务交换机设备进行测试。本业务系统管理的话务交换机数量较多，在全省规模下，有600台左右的实际设备。
此外，该性能测试的部分性能目标在需求和设计中进行了明确的定义，性能测试目标的确定可以通过对需求和设计的分析获取，这也是本案例的重要特点之一。
本节描述性能测试的全过程，根据本书第5章的性能测试过程描述，按照PTGM模型分别对性能测试的各阶段进行阐述。
在了解该项目的基本状况之后，首先开始测试前期准备工作。
1、系统基础功能验证
本案例中描述的性能测试安排在功能验收测试之后，因此在性能测试中不需要额外安排基础功能验证。
2、组建测试团队
根据该项目的具体情况，建立一个7人的团队负责本次测试工作。团队的7个成员中，1名是数据库工程师，1名是系统工程师，3名是性能测试设计和分析人员，2名是性能测试开发和实施人员。
在测试开始之前，已经预计到该系统的性能测试可能需要投入较大力量进行测试方案设计，其次还需要自行实现部分测试工具，因此，安排了3名性能测试设计和分析人员与2名性能测试开发和实施人员。
3、测试工具需求确认
考虑到系统测试的要求，该系统面临的最大问题在于需要模拟现有设备和系统使用的协议多，因此，综合项目的状况，最终确定的测试工具需求如下：
- 支持TCP/IP协议层上的测试。
- 能够方便地模拟现有设备，由于我们关注的是现有设备的定时发送报告、不定时发送告警和接受下发命令（包括用户和其他业务系统下发命令），因此对设备的模拟至少需要包括能定期发送指定数据、能随机发送指定数据并满足一定的频度要求、能接受命令并给出响应。
- 能够记录每个操作消耗的时间，便于进行性能分析。
- 考虑到用户的稳定性要求，工具要求能够监控系统是否稳定。
4、性能预备测试
性能预备测试用于对系统建立直观的认识，我们安排接入少量设备，并对少量设备接入后的系统运行进行体验，体验结果表明，在少量设备接入的情况下，系统能够顺利地完成话务报告数据处理，能够在3秒之之内将设备产生的告警呈现在系统界面上。
测试工具的引入对本案例来说是一个比较重要的过程。
根据测试前期准备确定的测试工具需求可以发现，在目前市面上的商业工具中几乎没有工具可以完全满足这些需求，因此经过讨论，最终将测试工具的引入方式定位在“创建”上，即完全自行开发需要的测试工具。
对测试工具的需求再次进行分析和分解，从模拟设备程序、记录程序和压力工具3个方面来考虑，形成了本案例需要的工具列表，如表1、2所示。
表1
表2
多学两招：
从表1、2中可以看到，为了完成本案例的性能测试，在测试工具上的投入就需要花费33人天。实际上，测试结束后的统计表明，花费在工具设计和开发上的工作量远远高于这个数值，原因是该工具也需要进行反复的设计修改和开发修改，并需要通过测试验证工具的功能正确性。
与测试工具相关活动的资源投入，从测试结束后的统计数据中得到的数据是51人天，如果按照工作日22天/月来计算，相当于是2.3个人1月的投入。
细心的读者应该能注意到，上表的测试工具中，前两个工具都要求能够在Windows和UNIX平台上运行，之所以这样要求，是因为我们希望能够充分利用设备资源。
表中的“模拟设备”的前两个测试工具最终用Perl实现，这样可以方便实现跨平台；后一个测试工具用C语言实现，因为该工具对程序效率要求较高。
测试计划阶段需要分析用户活动，确定系统的性能目标。
1、性能测试领域分析
根据对项目背景的了解，本性能测试要解决的主要问题问题包括：验证系统是否达到了预期的性能指标、验证系统是否能稳定运行、验证系统的失效恢复方案是否有效以及在测试过程中有针对性的进行部分调优工作，以保证系统能够达到预期的性能要求。
这些内容涵盖了第2章中给出的能力验证、性能调优两个应用领域。进一步根据第2章的内容，本测试可用的性能测试方法为除ConcurrencyTesting外的其他性能测试方法。
2、用户活动剖析与业务建模
在本案例中，用户活动主要通过话务交换机的行为来体现，因此，本活动的主要内容集中在为应用建模上。
通过对话务交换机的行为进行抽象，可以得到一个简化的话务交换机模型。就本案例关注的交换机功能，简化后的话务交换机模型如图2所示。
图2
对本案例的业务系统来说，交换机可以简化成具有3个端口的设备，这3个端口分别是话务口、告警口和操作口。
(1)话务口
话务口可被看作一个TCP/IP端口，该端口等待连接，在给定的话务周期到达时，向所有连接在该端口上的连接发送话务报告，话务报告以二进制数据流方式发送，不同交换机的话务报告格式和数据量均不不同。
(2)告警口
告警口可被看作一个TCP/IP端口，该端口等待连接，在交换机内部发生故障或错误时，向所有连接在该端口上的连接发送告警报告，告警报告以二进制数据流方式发送，不同交换机的告警报告格式和数量均不同。
(3)操作口
操作口可被看作一个向其发送具有一定格TCP/IP端口，该端口等待连接，连接上该端口的连接可以式的命令，当命令格式正确时，交换机执行命令请求的操作并以二进制数据流方式返回结果。
因为这3个端口之间没有直接的关联，因此，采用表1描述的测试工具可以完全模拟图2给出的话务交换机简化模型。
对本案例而言，需要进行性能测试的业务系统需要连接这3种不同的端口，并对下发和接收到的数据进行处理，业务系统的处理方式有以下4种。
（1）话务报告处理
话务报告处理过程从系统接收到话务数据流开始，接收到数据后先进行初步分析（分离报告），将报告形成文本文件保存在本地，同时向消息队列中发送一个消息。
分析进程阻塞消息队列，当在消息队列中发现消息后就取出该消息并按照消息指示对本地文件进行处理。对本地文件的处理是从文件中分析出数据并写入数据表的相应字段。
该业务系统的话务报告处理过程如图3所示。
图3
（2）告警报告处理
告警报告的处理过程从系统接收到告警数据流开始，在该业务系统中，告警数据直接由HP的Temip平台进行处理，告警数据流直接发送给Temip平台。通过一个入库进程，告警数据在处理后进入数据库。告警报告的处理过程如图4所示。
图4
（3）用户操作处理
用户操作的处理过程从用户下发交换机命令开始，用户通过一个被称为“仿真终端”的应用向交换机发送命令，通过一个连接交换机代理程序将命令排队处理后发送给交换机。用户操作的处理过程如图5所示。
图5
（4）其他业务系统操作处理
其他业务系统的操作处理从其他业务系统发送消息开始，通过一个业务接口程序，将其他业务系统发送的消息分析形成交换机命令，通过连接交换机的代理程序将命令排入命令队列进行处理，如图6所示。
图6
多学两招：
分析应用的行为对于这种类型的应用非常重要，不深入了解应用系统的实现方式，就不可能明确知道性能测试时究竟应该关注哪些内容。对于大部分属于用户交互的应用来说（如OA系统），往往只需要考虑用户的感觉（也就是用户感受到的响应时间），对性能测试条件的分析也集中在对用户行为的分析上；而对于本案例描述的这些应用（银行的某些业务系统也是典型的此类应用），对性能测试条件的分析就需要明确知道应用的工作方式，这样才能明确在性能测试中需要关注哪些内容。
分析应用行为的最好方法是用流程图的形式描绘出业务系统中涉及的各进程和数据交互过程，由此可以清晰地得到性能测试中需要关注的内容。
3.确定性能目标
本性能测试的应用领域已被确定为能力验证和性能调优，因此在确定性能目标时，应该围绕这两个方面进行。
本项目是一个开发项目，需求和设计中已经对部分性能目标进行了定义。在本案例中，从需求和设计中得到的与性能相关的描述包括。
（1）系统能够及时处理完全省交换机的话务数据。
（2）系统能够处理平均值为300次/秒的告警，能够承受峰值为600次/秒的告警。
（3）系统能够快速响应用户下发的命令。
（4）系统能够及时处理其他业务系统发送的交换机操作消息。
（5）系统能够稳定运行。
（6）系统能够在一台采集服务器、一台应用服务器和一台数据库服务器由于特殊原因崩溃时不间断运行。
在这些描述中，除了第（1）、（2）、（6）条是比较清晰的性能需求描述外，其他3条都是非明确的性能需求。而且，即使是第（1）、（2）条，也同样需要进一步的确认。为此，在该活动中，性能测试组通过与项目经理和客户的多次沟通，对性能测试需求进行了更加明确的确认。
（1）系统能够及时处理完全省交换机的话务数据：该业务系统接入的全省话务交换机数量为600台，其中约20%的交换机话务周期设置为15分钟，这部分交换机的话务报告平均大小约为4KB；约有30%的交换机话务周期设置为30分钟，这部分交换机的话务报告平均大小约为6KB；约50%的交换机话务周期设置为1小时，这部分交换机的话务报告平均大小为7KB。
（2）系统能够处理平均值为300次/秒的告警，能够承受峰值为600次/秒的告警：该业务系统接入的交换机数量为600台，300次/秒的告警发生频率相当于每台交换机每秒发生0.5次告警，考虑到各交换机具有不同的告警发生频率，经过对现网运行系统一周数据的分析表明，发生告警最多的设备大约每秒发生2次，发生告警最少的设备大约每小时发生2次，差别巨大。并且，用户实际还有一个并未在需求文档中给出的隐含要求：告警从产生到呈现的时间延迟小于5秒。
（3）系统能够快速响应用户下发的命令：经过与用户的确定，“快速”被重新定义为用户下发命令与在没有命令排队的情况下，交换机接收到命令的延时不得大于2秒，交换机反馈信息与用户接收到反馈信息的延时不得大于2秒。而且，明确的并发用户数量为100名。
（4）系统能够及时处理其他业务系统发送的交换机操作消息：经过与用户的沟通，用户对该业务系统的要求实际上是系统不能丢失其他业务系统发送的交换机操作消息，因此该需求实际描述的是系统的命令缓存能力，最终该需求被描述为：系统能够缓存1000条其他业务系统发送的消息不再接受新的消息并返回给发送消息的业务系统一个错误信息，当缓存区满时，。经过这样的分析，该需求变成了一个功能的需求，不再需要在功能测试中体现。
（5）系统能够稳定运行：该需求最终被表述成系统在压力下的性能表现，根据其他可参考的系统稳定性依据，该需求被描述为系统能够在比稳定运行时大2倍的压力条件下持续运行14天，期间各应用进程占用的内存及应用响应速度都不会发生明显变化。
（6）系统能够在一台采集服务器、一台应用服务器和一台数据库服务器由于特殊原因崩溃时不间断运行：对该需求的一个补充是，由服务器失效引发的切换必然会使正在进行的业务收到影响，因此，允许切换过程中产生不完整的数据。另外，应用的切换必然存在一个切换时间，商定的允许切换时间为5分钟。
指点迷津：
需求文档、设计文档以及其他相关文档中给出的性能需求通常都会存在含混不清的地方，在设计性能测试之前，必须将这些地方彻底理清。甚至在某些情况下，不同来源的文档之间会存在冲突，这时应该向项目经理说明此事，并由客户代表进行最终的决定，决定后的结果需要明确记录下来。
表3给出了分析整理后的性能需求描述。
表3
对能力验证应用领域来说，本测试需要重点关注的是业务的响应时间、各服务器的资源使用状况，结合性能测试需求，性能目标可以定义如下：
- 在满足全省话务数据规模的情况下，服务器CPU平均使用率不高于75%，内存使用率不高于75%。
- 在平均告警规模下，服务器CPU平均使用率不高于75%，内存使用率不高于75%；峰值情况下，服务器CPU平均使用率不高于90%，内存使用率不高于85%。
- 没有命令排队情况下，交换机接收到命令的延时小于2秒，用户接收到反馈信息的延时小于2秒。
- 各组单台设备故障时，系统切换时间不大于5分钟，切换后业务如常进行。
对性能调优应用领域来说，本测试关注的重点是通过各种设置和部署的调整（原则是：除非确定是应用问题，否则优先考虑调整设置和部署方法），使系统性能表现能够达到预期的要求。
指点迷津：
对上线的应用系统来说，影响其性能表现的因素很多，我们建议的调优顺序是优先考虑系统级的调优，例如对应用服务器设置的调优、数据库设置的调优和应用部署方式的调优。只有在确认是应用的问题，或是其他调优方法都不能奏效时，才考虑对应用代码进行调优。
根据笔者的性能测试项目经历，将近60%的应用系统性能问题都可以通过调整应用服务器设置、调整部署或调整数据库设置获得良好的性能提升，只有少数情况不得不对代码进行调优。
4.制定测试时间计划
本案例的特点之一在于测试中使用的大部分测试工具都是自行开发的，因此必须留出较多的时间进行工具的设计和开发。另外，由于系统本身的复杂性，测试环境构建也需要一定的时间。本案例的测试时间计划安排如表4、5所示。
表4
表5
注：①在本案例的前期己经对工具开发的工作量进行了估算，估算得到的数值是33人天，此处的时间安排即是按照该估算进行的。
②这里用了一些虚拟的人名表示测试组成员。特别要提醒的是，在FailoverTesting过程中，一定要系统工程师和数据库工程师的参与并准备好应急方案，一旦测试过程中发生意外，要按照预先制定好的应急方案对系统进行恢复。
测试设计与开发包括测试环境设计、测试场景设计、测试用例设计和测试辅助工具开发多个活动。对类似本案例的业务系统而言，测试场景关注的主要内容不是用户感受，而是系统的业务处理能力，因此在测试场景设计上，注重的是通过何种方式获取和性能相关的数据及如何对获取的数据进行解释。
1.测试环境设计
本性能测试需要验证系统在实际生产部署环境上的性能，因此，尽可能选择接近实际生产环境的环境来进行测试。
该项目测试的一个特点是需要通过模拟手段来模拟实际的话务交换机设备，结合前文中建立的话务交换测试模型，和图1给出的系统示意图，最终确定的测试环境包括预计用于实际运行的全部服务器条件，通过工具模拟的话务交换机运行于中心机房的PC机和非测试用服务器上。
这个测试环境与实际环境之间唯一的差异在于：系统接入的话务交换机不是真正的设备。对本系统来说，可能存在以下风险：
（1）因为报告传输速度不同，可能导致测试结果上出现不同。
（2）实际设备可能发出不完整报告，而模拟的设备不会，两者之间存在的差异可能导致性能测试的结果不正确。
当然，这两个风险在一定条件下可以解决，在本案例中，通过约束和分析解决了这两个风险：对第1个风险，根据对各不同地市的不同机型交换机传输速度的调查，最慢的交换机（通过MOXA转接方式）也可以在2分钟内完成所有报告的传输，而且这些慢速传输的交换机的话务报告周期都设置为1小时；对第2个风险，实际设备发出的不完整报告会被接入进程丢弃，在性能测试过程中只要能验证不完整报告不会对接入进行的性能造成显著影响即可。
指点迷津：
使用非生产环境作为测试环境进行性能测试时，最好对环境之间的差异进行详细分析并评估由此带来的风险，在测试计划中需要明确说明风险的解决方法或相应的对策。
该性能测试的另一个应用领域是性能调优，因此在性能测试过程中，需要合理且合适的测试环境维护方法，保证在调优的测试过程中测试环境能够保持可信的基准。最终确定了5个测试环境，如6、7所示。
表6
表7
本案例中的测试数据环境设计根据系统的运行预期来确定。该系统的数据备份清除原则是：系统数据每3个月进行一次备份和清除操作，每次清除操作将数据库中两个月以前的业务数据全部清除。
从以上的描述可以看出，系统在稳定运行后，数据库中的业务数据至多保留3个月，最少两个月，为了考察性能表现，我们以3个月的业务数据作为数据库中数据的基准。
采用类似第一个案例的计算方法，计算得出的数据库中历史数据环境如下：
话务数据表：19440000条记录。
告警数据表：2120000条记录。
为了保证数据环境在每次测试中保持一致，首次生成数据记录后，将数据库输入（export）为本地文件并保存，在每次测试开始前，都通过输入（import）方法将数据直接导入到数据库，保证数据环境的一致。
另一方面，由于本性能测试使用的测试工具多且分散，在实际测试中将工具的启动形成shell脚本或是bat文件，以具有意义的名称进行管理。
另一个需要设计的是时间同步方案。本案例中需要记录的测试结果数据很多，部分数据的处理需要根据记录时的时间进行，而根据测试环境，应用部署较为分散，因此有必要为整个测试环境设计一个时间同步方案，以使整个测试环境中的各台设备具有精确一致的时间。
本案例涉及的是一个UNIX和Windows的混合环境，因此采用ntp协议进行各设备之间的时间同步。
2.测试场景设计
根据表2、3，可以很容易地为该案例给出需要的测试场景，如表8、9所示，其中每个场景对应一个测试需求。
表8
表9
由表8、9看出，只要按照场景名称、场景业务及比例分配、测试指标、性能计数器的描述方式，就可以非常清晰地对场景进行描述。
3.测试用例设计
确定测试场景之后，在原有的业务操作描述上，可以更进一步完善为可映射为脚本的测试用例描述。如果测试过程中需要较多的辅助工具进行协作，在用例设计中可能还需要描述工具部署情况。
在本案例中，用例设计的主要考虑内容是如何获得与系统性能相关的数据，因此在本案例的测试用例设计描述过程中，我们设计了6个对应测试场景的方案。方案采用测试模型、测试说明、测试用例概述的方式进行描述。
（1）方案1——对应场景。测试系统能否及时处理完全省交换机的话务数据，测试模型如图7所示。
图7
①测试过程中采用600个模拟交换机设备发送话务数据，120个模拟的5ESS设备，话务周期为15分钟，话务报告为4KB；180个模拟的Siemens设备，话务周期为30分钟，话务报告为6KB；300个模拟的Ericsson设备，话务周期为1小时，话务报告为8KB；600个模拟设备的进程分布在15台测试机上，每台测试机运行40个模拟设备的进程。
②测试过程中，采用3台采集机，每台采集机上运行一个接入进程和6个处理入库进程。之所以用6个处理入库进程，是因为采集服务器设备有6个CPU，6个进程可以最大限度地提高处理效率。
③为了记录话务数据处理过程中的各个时间点（模型中的T1、T2、T3标识），约定如下：
- 在模拟设备程序目录下的sendlog.log文件记录发送出话务数据的时间戳和局号。
- 接入程序的日志记录该程序发送的消息等内容，文件存放在采集服务器的/opt/mytest/data/目录下。
- 分析入库程序的日志位于采集服务器的/opt/mytest/log/plog目录下。该程序的日志内容包含接收消息的时间、处理的时间以及数据入库时间。
【验证方法】
以最后一个报告已入库的时间作为全部报告的入库结束时间，该时间提前于下一话务周期。
（2）方案2—对应场景：测试系统能否处理平均值为300次/秒的告警，测试模型如图8所示。
图8
①每个模拟设备进程等待1～20秒的随机时间，发送5条告警，总的告警频度为600×5/10=300次/秒，告警持续发送8小时。之所以采用随机等待的方式，是为了更好地模拟真实的生产环境，使测试结果具有更大的可信度。
②模拟设备进程发送的告警附带的告警发生时间是运行模拟设备进程的机器当前时间，检查告警是否在5秒内呈现的方法是在告警呈现应用（PC应用）上直接查看告警的发送时间和实际呈现的时间，比较时间差。
【验证方法】
通过对比已发送告警和界面上呈现告警、数据库中的数据来核对数据的准确性，包括：界面呈现告警和实际发送告警的数量、类型是否一致；数据库中入库的告警数据与界面呈现告警是否一致。
（3）方案3——对应场景：测试系统能否处理峰值为600次/秒的告警，其测试模型与方案2相同。
①600个模拟设备进程中，200个进程每秒发送2条告警，400个进程随机等待0～4秒，发送1条告警，总的告警频度为200×2＋0.5×400=600次/秒，告警持续发送1小时。
②模拟设备进程发送的告警附带的告警发生时间是运行模拟设备进程的机器当前时间，检查告警是否在8秒内呈现的方法是在告警呈现应用（PC应用）上直接查看告警的发送时间和实际呈现的时间，比较时间差。
【验证方法】
通过对比已发送告警和界面上呈现告警、数据库中的数据来核对数据的准确性，包括：界面呈现告警和实际发送告警的数量、类型是否一致；数据库中入库的告警数据与界面呈现告警是否一致。
指点迷津：
在方案2和方案3中，检查告警是否在规定时间内呈现的方法是在告警呈现应用（PC应用）上直接查看告警的发送时间和实际呈现的时间，比较时间差。但设想一下，在实际操作中，当用户界面上以每秒300或600次的频率呈现告警时，要计算出每条告警的实际呈现时间几乎不可能。
此时可以采用一种被称为“探针”（Probe）的技术，其原理是：将负载和实际观察数据分开，选用特殊的便于识别的数据作观察用。具体在本案例中，可视方案中设定的告警产生为负载，为了知道告警是否在指定时间内得到呈现，在负载之外用一个特殊的模拟设备进程发出特殊的告警，在告警呈现应用中仅计算该特殊告警的呈现时间。
（4）方案4——对应场景：测试系统能否快速响应用户下发的命令，测试模型如图8.9所示，其逻辑简化图如图9、10所示。
图9
图10
该模型用于测试命令下发和命令结果回显，根据测试用例的描述，在测试中需要记录时间点T1、T2、T3、T4。
①模拟200个话务交换机设备，模拟程序能接收用户下发的交换机命令perftest、lgi并发送回应。
②用模拟程序SimTerm模拟200个终端连接设备，充当负载。该模拟程序以每分钟一条命令的频率发送perftest命令。
③实际运行一个命令终端应用，在该应用进程中由用户手工输入命令，程序记录下用户输入命令时间等关键时间点。
④为了记录时间T1、T2、T3、T4，有以下约定：
- SimTerm发送的命令附带发送时的时间戳，一个典型的命令格式为：perftest：2004-09-2015:23:00。
- 终端应用程序在发送命令时，附带一个用户输入命令结束的时间戳，一个典型的命令格式为：igi:2004-09-2015:23:00，这个时间就是我们定义的时间T3。
- 交换机设备模拟程序记录接收到命令的时间T1，并从接收到的命令中分离出时间T3，记录T1、T3和T3-T1；交换机设备模拟模拟程序在发送回应的时候在回应的报文中附带发送时的时间戳（T2）。
- 命令终端程序接收交换机设备模拟程序发送的回应报文，分离并记录出其中的时间T2、记录报文回显完成的时间T4，并计算T4-T2。
⑤持续测试1小时，在1小时中通过命令终端发送命令。
【验证方法】
T3-T1小于2秒，T4-T2小于2秒。
指点迷津：
方案4中除了应用到上文介绍的探针技术外（方案4同样将负载和实际观察响应时间的应用分开），还使用了一种被称为“时间戳”的技术。时间戳技术一般在需要记录大量与时间相关的数据时使用，例如在本方案中，需要记录每条命令的下发时间（T1）、被设备接收到的时间（T3）、设备返回命令的时间（T2）、返回命令被应用呈现的时间（T4）。其中的时间当然可以由各个相关应用写入本地日志中，但如果采用这种方式，每个应用写入日志的资源开销都会非常大，导致性能测试结果出现偏差。时间戳技术则避免每个应用单独用日志方式记录时间，而是采用在发送的消息报文中附带当时的时间的方法，这样一个经过完整处理的数据报中就带有每个节点处理时的时间，只需要在其中任意一个应用进行记录和处理即可（甚至是经最终得到的消息再次转发，由一个额外的应用记录和处理时间信息）。相比写日志的开销，这种时间戳技术的额外开销显然要小得多。
当然，在应用时间戳技术时不得不指出，采用这种方式必然要求各个应用在设计时都考虑这种方法。
（5）方案5——对应场景：测试系统能否稳定运行。
该方案测试系统能否稳定运行，其测试模型是一个综合模型，采用压力测试的方法，重点检查运行过程中系统的各性能计数器值和应用进程的内存使用状况。
【验证方法】
各服务器的CPU使用率小于90%，内存使用率小于85%，各应用进程所占用的内存在测试期间没有明显变化。
（6）方案6——对应场景：测试系统能否顺利实现故障切换，其测试模型是方案1和方案2的测试模型综合。
①采用模拟程序和应用程序部署整个测试环境，测试环境包括600个模拟的话务交换机设备，以方案1和方案2的条件部署整个环境。
②采用拔网线的方式模拟设备故障，记录设备故障时间。
③检查系统能否在5分钟内完成切换。
【验证方法】
系统完成切换的标志是告警能重新呈现，话务数据能继续采集和处理。
4.脚本和辅助工具的开发
脚本和辅助工具的开发需求在上文中进行了详细的描述。
在测试执行与管理之前的过程和活动中，已经明确规划了本性能测试的环境、场景和脚本，在本过程中，只需要按照前面阶段的要求，将测试场景和脚本进行部署，然后执行测试并记录结果即可。
1.建立测试环境
建立测试环境就是按照测试设计中设计的环境设计内容部署测试环境，本测试需要进行性能调优测试，因此必须在保证测试基准环境上下工夫。本测试过程中使用了CheckList来检查具体的数据库设置和应用服务器设置，并由系统工程师对其进行仔细的调整。
时钟同步是本案例环境设置的重要内容之一，设置方法的描述如下:
（1）首先选定一台UNIX服务器作为时钟源服务器。
（2）在其他的UNIX平台上，修改//etc/ntp.conf文件，将其时间源服务器设置为选定的源服务器。
（3）在Windows平台上安装NetTime工具（//nettime.sourceforge.net），然后运行NetTime程序，按照图10的描述进行设置（其中的HostnameorIPAddress设置为时钟源服务器的IP地址）。
进行设置（其中的HostnameorIPAddress设置为时钟源服务器的IP地址）。
2.部署测试脚本和测试场景
在本案例中，部署测试脚本和测试场景的过程就是在测试环境中部署测试辅助工具和脚本。辅助工具和脚本部署的内容在测试方案中均已经描述，在此不再赘述。
图11
这里给出一种本案例中采用的部署表描述，读者可以在自己的工作中使用。为了简便，此处只给出场景1的场景部署内容，如表10所示。
表10
3.执行测试和记录结果
在本性能测试中，采用UNIX平台上的性能计数器数值采集脚本获取并记录UNIX服务器上的CPU使用率、Memory使用率等数据，获取的数据以文本文件方式存在服务器上，对这些文本文件的处理通过Excel工具实现，具体操作在第12章中进行描述。
给定的方案执行完成后，需要对获得的测试结果和数据进行分析，本节展示对该性能测试进行分析的方法和手段。
1.测试系统能否及时处理完全省交换机的话务数据
模拟设备发送话务报告的部分日志（sendlog.log文件）如下：
图12
从该日志可以看到，模拟设备按照预期的方式发送话务报告。
在一个话务周期完成后，通过检查数据是否入库完整判断处理和入库时间的结束，经过检查，在整个测试期间，最长的入库时间为41秒，这个结果完全可以满足预期的性能要求。
关注此时的服务器性能计数器数值，考虑到本业务需要生成大量的本地文件和对本地文件进行读写，DiskI/O是一个可能的性能瓶颈，因此首先关注Disk1/O相关的性能计数器值。
以下是采集服务器的部分DiskI/O数据，给出的数据中包含了rps和wps最大的几组数据（粗体标识的数据）：
图13
按照本书第3章的内容介绍，计算每磁盘的I/O数（采集服务器使用RAID10方式，共4个磁盘），则计算如下：
最大的每磁盘I/O数＝（112＋2×10.2）/2=66.2
而磁盘标识的I/O处理能力为85，可见磁盘不是采集服务器的性能瓶颈。
再看看采集服务器的CPU和内存使用情况，如图14和图15所示。
图14
图15
从图中可以看到，采集服务器的CPU使用率较高，在话务周期到达的一段时间内一直忙于进行话务报告的处理，从获取的原始数据看，阻塞进程数量仅为1～2个，由此说明CPU使用率高的主要因素是程序自身确实在进行复杂的运算操作，CPU为系统的性能瓶颈之一，可以考虑通过优化算法等改善应用的CPU使用状况。
内存的使用率很低，稍大于50%。这说明当前的内存配置对应用而言是足够的，不构成性能瓶颈。
对应用服务器进行了类似的分析，结果表明应用服务器的CPU和内存使用率都在60%以下，因此应用服务器本身也不构成该测试项目的性能瓶颈。
对数据库的分析稍微复杂一些，在本测试方案中，主要选取了数据库服务器的CPUUsage、MemUsage、SGAMemUsage和IndexedQuery等性能指标进行监控，如图16所示。
图16
从图16中可以看到，这些值都处在可以接受的水平上，数据库服务器本身的状态比较正常。当然，由于系统性能表现比较好，在测试中就没有深入对使用的SQL语句等进行分析。
2.测试系统能否处理平均值为300次/秒的告警
通过告警呈现应用上显示的告警时间与实际的告警发出时间进行对比，由于采用了Probe技术，因此只需要统计少数告警消息即可。经过统计，告警从报告发出到呈现的平均时间为3.4秒。该数据说明，系统完全能够满足预期的告警性能要求。
除了计算这些特殊设计告警的呈现时间外，还需要验证测试过程中，是否所有负载告警均己经被正常处理了。因此在验证该结果时，还需比对Temip实际接收到的告警数量和发出的告警数量是否一致。经过比较，结果完全一致。
随后是对各服务器的性能计数器数据的分析。表11是用vmstat获取的应用服务器的部分性能指标。
表11
从表11中可以看到，内存和CPU的使用率都非常低，可见，应用服务器不构成告警业务的性能瓶颈。
3.测试系统能否处理峰值为600次/秒的告警
该项目的测试结果分析与上一方案的测试结果分析类似，在此不再赘述。
对结果的分析表明，系统能够达到预期的性能要求，且应用服务器不构成性能瓶颈。
4.测试系统能否快速响应用户下发的命令
通过分析工具对日志进行分析后的结果（部分）如下：
图17
从分析结果可以看到，T3-T1和T4-T2的时间延迟都非常小，其值接近0。因此，系统完全可以满足用户对命令下发时间响应的性能要求。
使用和上几个方案结果分析类似的方法，对涉及的服务器进行性能分析，结果发现在该测试过程中，相关服务器的性能计数器值都接近低水平。
5.测试系统能否稳定运行
测试系统能否稳定运行，主要方法是：检查在压力条件下，系统长期运行是否会出现异常。造成系统不稳定的主要原因在于内存使用、资源不合理使用等，这些都可以从进程占用的内存量、系统运行速度等看出端倪。
在本方案的测试中，设定好运行条件后，系统在压力条件下运行，此时用脚本监测服务器可用内存以及所有应用的内存使用，如图18所示是测试过程中发现的采集服务器的可用内存曲线。
图18给出了一个令人吃惊的结果：采集服务器的可用内存曲线呈现锯齿状。刚看到该图形时，很有些觉得莫名其妙，但在查看其他应用的内存使用状况时，马上就恍然大悟了。原来，报告入库分析程序的开发人员出于习惯，为该进程准备了一个防止进程意外退出的机制——Watchdog，他用一个后台进程对多个报告入库分析程序进行管理，一旦发现某个报告入库分析程序进程退出，该后台进程就立刻重新装载一个报告入库分析程序进程。而刚巧报告入库分析程序本身存在内存泄漏，在大压力、长时间的运行条件下，进程的占用内存一直增长，直到系统内存不能再支撑为止，此时进程会被操作系统关闭；但由于Watchdog的存在，进程被关闭后又会立即被重新装载进来，如此反复，最终造成了采集服务器的可用内存曲线呈现锯齿状。
图18
此外，在压力测试中出现问题的应用还包括交换机的代理进程，如图19所示是该进程在测试过程中的内存使用情况。
图19
从图19中可以看到，该进程在测试过程中的内存使用占用呈现持续增长的趋势，这明显是该进程的内存泄漏所致。后经过对代码进行分析，该进程确实存在内存泄漏问题，每次建立和释放一个连接会产生2KB左右的内存泄漏，由于内存泄漏量非常小，如果不通过这种长时间、大压力的测试，很难发现。
另一个在稳定性测试中发现的问题与资源使用相关。测试完成后检查各应用的日志时，发现在接入进程的日志中出现了许多“无法打开文件”的错误信息，且这些错误信息发生在测试开始2天后。由于整个测试过程都采用同样的压力条件，因此该问题不太可能由环境引起。后来经过开发人员的定位，该问题产生的原因是接入进程在某种情况下打开文件后没有及时关闭文件句柄（handle），从而导致在一段时间后无法再打开新的文件。
判断系统是否能够稳定运行的另一个指标是测试过程中应用的响应时间或效率是否发生明显变化，在本测试中，采用方案1和方案2的检查方法对其进行检查。当然，在存在内存泄漏的情况下，随着持续运行时间的增加，系统的业务处理能力明显变小。
在修正了内存泄漏的问题后，经过再一次测试，发现各服务器的可用内存曲线在整个测试期间没有明显变化，各进程占用的内存在整个测试期间也没有明显变化，系统的业务处理能力亦没有发生明显变化。综合以上，可以说明，应用在测试的初期存在内存泄漏导致的不稳定隐患，经过修正，系统已经可以满足预期的稳定性要求。
指点迷津：
对于大型的应用系统来说，稳定性测试一般都是必不可少的。最容易出现的稳定性方面的问题是内存、资源使用方面的问题，前者会导致内存不足或是系统性能表现不稳定（存在GC机制的情况），后者会导致出现一些异常（如应用没有及时释放句柄导致无法打开文件等）。
6.测试系统能否顺利实现故障切换
根据测试方案的描述，测试系统能否顺利实现故障切换的方法比较简单。由于性能需求中允许部分数据不完整，因此，测试过程只需要关注在指定时间达到后系统能够正常运行业务即可。
测试结果表明，在5分钟内业务顺利恢复，因此，系统在故障恢复方面能够满足预期的性能要求。
该项目是一个较大型的性能测试项目，大量采用自定义通信协议，因此没有采用商业的性能测试工具，而是在整个项目中采用自行构建性能测试工具的方法。本案例描述的项目具有一定的代表性，可作为对此类项目性能测试的参考。
在本案例的性能测试实现中，采用了探针和时间戳的技术，这两种技术是性能测试过程中常用的技术，读者可以自行体会。
本案例涉及的项目的很多模块都是以后台进程的方式工作，对其测试往往只能通过日志、时间戳等技术来了解模块的工作状态。由于设计的问题，有些开发人员会制造出“既不输出信息，也不打印日志”的后台应用，在性能测试过程中，对测试结果进行分析时，涉及到该模块的结果分析只能是“摸黑”，如果遇到这样的问题，直接且唯一的方法就是要求开发人员根据测试要求在模块中加入日志或是其他手段，本案例的性能测试过程就相当得益于应用完整和规整的信息输出。
当然，要注意的是，为应用模块添加日志可能会导致应用的性能表现发生变化，对这一副作用一定要认识到。时间戳技术就是对日志的一种替代方法。
本案例的描述进一步明确说明了一个事实：性能测试过程最重要的是分析过程，只要分析工作做得充分，执行工作基本是水到渠成的事情，而分析也很大程度基于设计的完备性。
【注释】
(1)MOXA设备可以使原本不具备以太网口并分散各地的串行设备通过MOXA设备的转换，以TCP/IP方式连接到网络。
(2)为了使图形更清晰，此图仅大致给出了可用内存的曲线趋势，并不完全是实际的数据。
(3)为了使图形更清晰，此图仅大致给出了进程内存使用的曲线趋势，并不完全是实际的数据。
标签：
性能测试软件测试技术软件测试
本站文章除注明转载外，均为本站原创或翻译。欢迎任何形式的转载，但请务必注明出处、不得修改原文相关链接，如果存在内容上的异议请邮件反馈至chenjj@cahobeh.cn
彩票走势图 
6次
相关产品
最新文章 
彩票走势图相关的文章 
微信
在线咨询
渝公网安备
50010702500608号
客服热线