2012-02-21 21:33:38|  分类： LoadRunner |  标签： |字号大中小 订阅

作者：吴老师   发布时间：2012-02-18  浏览次数：164 次

本文转载与互联网

在大多数的性能测试工作中，我们可以看出很多内容都是互相关联的。这就给我们提供了一个思路：性能测试的很多内容可以经过一定的组织统一来进行。统一开展性能测试的巨大好处是可以由浅入深按照层次对系统进行测试，进而减少不必要的工作量，以实现节约测试成本的目的。为此，本文提出了“全面性能测试模型”的概念。

　　“全面性能测试模型”提出的主要依据就是一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，而这些类型的测试实施也是很类似的。例如：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。

1 全面性能测试模型

　　在“全面性能测试模型”中，把Web性能测试分为八个类别。下面首先介绍八个性能测试类别的主要内容。

　　（1）预期指标的性能测试：系统在需求分析和设计阶段都会提出一些性能指标，这些指标是性能测试要完成的首要工作之一，本模型把预先确定的一些性能指标的测试称为预期指标的性能测试。

　　这些指标主要是指诸如“系统可以支持并发用户1000”、“系统响应时间不得高于10秒”等在产品说明书等文档中中十分明确的内容，对这种预先承诺的性能要求，测试小组应该“首当其冲”完成这类测试。

　　（2）独立业务性能测试：独立业务主要是指一些核心业务模块，这些模块通常具有功能比较复杂、使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能测试重点。我们通常不但要测试这类模块的一些和性能相关的算法，还要测试这类模块对并发用户的响应情况。

　　核心业务模块在需求阶段就可以确定，在系统测试阶段开始单独测试其性能。如果是系统类软件或者特殊应用的软件，通常从单元测试阶段就开始进行测试，在后继的集成测试、系统测试、验收测试中进一步进行测试，以保证核心业务模块的性能稳定。

　　用户并发测试是核心业务模块的重点测试内容，“并发”的主要内容是模拟一定数量的用户同时使用某一核心模块的“相同”或者“不同”的功能，并且持续一段时间。对“相同”的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作，例如打开同一条数据记录进行查看；另外一类是在同一时刻使用完全一样的功能，例如同时提交数据进行保存。可以看出后者是包含前前者的，后者是前者的特例，这种并发测试都要持续一定的时间。

　　从微观角度讲，同时使用某一核心模块“不同”的功能，也是一种组合业务性能测试，只不过这种组合的相关业务大分类是一致的。

　　（3）组合业务性能测试：通常不会所有的用户只使用一个或者几个核心业务模块，每个功能模块都可能被使用到，所以Web性能测试既要模拟多用户的“相同”操作(这里的“相同”指很多用户使用同一功能)，又要模拟多用户的“不同”操作(这里的“不同”指很多用户同时对一个或者多个模块的不同功能进行操作)，对多个业务进行组合性能测试。组合业务测试是最接近用户实际使用情况的测试，因而是性能测试的核心内容。我们通常按照用户的实际使用情况来模拟使用各个模板的人数比例。

　　由于组合业务测试是最反映用户使用系统情况的测试，因而组合测试往往和服务器（操作系统、Web服务器、数据库服务器）性能测试结合起来，在通过工具模拟用户行为的同时，还通过测试工具的监控功能采集服务器的计数器信息，进而全面分析系统的瓶颈，为改进系统提供有利的依据。

　　用户并发测试是组合业务测试的核心内容。“组合”并发的突出特点是分成不同的用户组进行并发，每组的用户比例要根据实际情况来进行匹配。组合业务测试可以理解为包含了“核心业务模块并发”和“非核心业务模块并发”同时进行的并发用户测试。

　　（4）疲劳强度性能测试：疲劳强度测试是在系统稳定运行下模拟较大的用户数量、并长时间运行系统的测试，通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能，主要目的是为了测试系统的稳定性。

　　（5）大数据量性能测试：大数据量测试分为两种：一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试,主要是测试数据增多时的性能情况，这类一般都是针对某些特殊的核心业务或者一些日常比较常用的组合业务的测试。

　　第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者日常常用的组合业务。例如系统的数据每年只备份转移一次，可分别选择一个季度、半年、一年作为参考，模拟输入各个时间段的预计数据量，然后测试系统的性能，进而预估系统的性能走向。

　　由于大数据量仍然是为了测试系统的业务处理能力，因此大数据量性能测试可以独立进行，也可以和前面的独立、组合业务测试结合起来进行，主要由性能测试策略来决定。由于大数据量测试一般在投产环境进行，因此把它单独独立出来，和疲劳强度测试放在一起，在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或者组合业务测试。

　　（6）网络性能测试：网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。在实际的软件项目中，主要是测试应用系统的用户数目与网络带宽的关系。

　　（7）服务器性能测试（操作系统、Web服务器、数据库服务器）：服务器性能测试分为初级和高级两种形式。“初级服务器性能测试”主要是指在业务系统工作或者进行前面其它种类性能测试的时候，监控服务器的一些计数器信息，通过这些数据对服务器进行综合性能分析，找出系统瓶颈，为调优或者提高性能提供依据。“高级服务器性能测试”一般不由测试人员进行，由专门的系统管理员来进行，例如数据库服务器由专门的DBA来进行测试和调优。本文主要讨论在测试中常用到的“初级服务器性能测试”，既通过工具对服务器资源进行监控的性能测试。

　　（8）一些特殊测试：主要是指配置测试、内存泄漏测试一些特殊的Web性能测试。这类性能测试或者和前面的测试结合起来进行，或者在一些特殊情况下会独立进行，本文重点来讨论前一种情况，因为后一种情况往往通过特有的工具、较大投入的进行，可以不作为性能测试的范畴来研究。

2性能测试通用策略

2.1性能测试策略通用方法

　　本节主要介绍一下通用的性能测试策略制定方法。性能测试策略一般从需求设计阶段开始讨论制定，策略的内容决定着性能测试工作投入多少资源、什么时间开始实施等后继工作如何安排。其制定的主要依据是“软件自身特点”和“用户对性能的关注程度”两个因素，其中软件的自身特点起决定作用。

　　软件按照用途的不同分为两大类：系统类软件和应用类软件。系统类软件对性能一般要求比较高，因此性能测试应该尽早介入。应用类软件分为特殊类应用和一般类应用，特殊类应用主要指银行、电信、电力、保险、医疗、安全等领域类的软件，这类软件使用比较频繁，用户较多，一般也要较早进行性能测试；一般类应用主要指一些普通应用，例如办公自动化软件、MIS系统等，一般应用类软件多根据实际情况决定性能测试策略，比如OA系统，可以早开始、也可以最后进行性能测试，这类软件受用户因素影响比较大。

　　用户一般可以分为四类：即对性能特别关注、中等重视、一般关注、不怎么关注四类。这里这么划分并不意味着用户不关注性能测试人员就可以忽略性能测试。不过，用户如果特别关注性能，测试人员也应该特别重视性能测试。表1列出了性能测试策略制定的基本原则。（注意：这里的用户是广义范围的用户，包括所有和我们的产品有利害关系的群体。因而不单单指最终使用产品的用户，这些用户既可以是为我们提出需求的产品部，也可以是公司的董事会，甚至是我们研发人员自己。）

　　软件的特点决定性能测试策略另外一个重要原因就是“一般应用类软件”通常耗费资源较少，因此可以通过提高硬件配置，进而改善运行环境来提高“一般应用类软件”的性能。从硬件方面解决性能问题往往更容易做到，同时可以降低我们的开发成本，不过也不能过分让用户进行较大的硬件投入，否则会降低我们的“客户满意度”。我们调整性能最好的办法还是软硬件相结合。

　　用户对待系统性能的态度影响性能测试策略，但不起决定作用的根本原因是我们最终要把产品交付给用户来使用，而不是做出来给用户欣赏。因此不管用户是否重视性能测试，即使根本不关心，对于性能要求高的软件产品我们都应该按照测试上面的策略进行合理的安排。同时，如果我们的上帝——用户如果特别重视，这意味着我们需要进行更多的性能测试方面的投入，因为我们有义务使我们的用户满意。

3 Web性能测试模型使用方法

　　“全面性能测试模型”是针对Web性能测试而提出的一种方法，主要目的是为了比较全面的开展性能测试，使Web性能测试更容易组织和开展。本模型包含了测试策略制定的通用方法和测试用例设计通用方案，测试用例的设计覆盖了应用软件、服务器、操作系统多方面的内容，按照由浅入深的顺利对性能测试进行了合理的组织。

　　“全面性能测试模型”是一种经很多性能测试项目抽象出来的方法论，主要用来指导测试，它一般不适合具体的性能测试项目，因为任何一个项目都会有它的特定背景。要想通过“Web全面性能测试模型”做好性能测试工作，首先要制定好性能测试策略，同时还要按照一些基本指导原则来使用“Web性能测试用例设计模型”的内容。这些原则主要包括如下的内容：

　　测试策略遵从最低成本原则。Web性能测试本身是一种高投入的测试，而实际中国内公司通常在测试上进行较低的投入，Web性能测试只是全部测试工作的一部分，很多项目只能进行一些重要的性能内容，这就决定测试经理制定性能测试策略时在资源投入方面一定要遵从最低成本化原则。最低成本的衡量标准主要指“投入的测试成本能否使系统满足预先确定的性能测试目标”，只要我们经过反复的“测试——系统调优——测试”后，系统符合性能需求并有一定的扩展空间，就可以认为性能测试工作是成功的。反之，如果系统经过测试后不满足性能需求或者满足性能需求后仍然投入资源，都可以认为是不合理的。

　　策略为中心原则。本原则不但对性能测试工作有效，对其他类型的测试工作都具有同样的指导意义。测试策略不但决定了我们测试用例设计时的主要内容，还决定着我们实施测试工作时如何根据项目的实际情况进行处理，例如：如果项目时间比较紧张，我们完全可以按照测试用例的优先级只执行一部分性能测试用例。因此，性能测试策略应该贯穿整个性能测试过程。

　　适当裁剪原则。裁剪原则主要是针对性能用例设计而言。Web性能测试用例设计模型主要是针对电信、银行级的应用而提出的，包含的测试内容比较全面，而这类项目的性能测试一般周期较长、投入较大，作者曾亲身经历过测试周期为一年的银行项目。要想性能测试用例设计模型在大多数测试项目中使用，必须对测试用例模型包含的内容进行合理的裁剪，这样做的主要目的是为了适合特定项目的测试需求，进而节约测试成本。

　　裁减的主要依据是性能测试策略，我们根据策略制定方法制定出测试策略，然后依据策略从“五类性能测试用例”中选择适当的内容来编写测试用例。例如有些要求不高的静态门户网站，用户也没有提出性能方面的要求，我们完全可以只测试一下用户并发情况作为系统性能的参考。

　　完善模型原则。本模型只是作者的工作经验总结，由于不同的性能测试任务都有自己的项目背景，因而需要对模型内容进行不断的调整、补充、完善，才能使之适合更多的性能测试工作。不断完善具体来说就是要在工作中不断总结自己的经验，形成自己的“Web全面性能测试模型”。只有“自己的”测试模型，才是最符合自己需要的模型。

　　模型具体化原则。模型具体化主要是指把本模型运用到具体的项目中，是前面所有原则的目标。如果只记住模型的这些条条框框，然后生搬硬套框架来设计测试，只能得到适得其反的结果。要想使模型在Web性能工作中发挥作用，只有根据实际项目的特点制定合理的性能测试策略、编写适当的性能测试用例，并在测试实施中灵活的执行测试方案。

　　综合上面的分析，可以看出模型使用完全可以概括成两个字——“活用”。要想真正做好性能测试工作，最有效的办法就是在掌握基本理论和方法后，在工作中不断的去探索和总结，不断的完善该模型，形成自己的“Web全面性能测试模型”。

　　“全面性能测试模型”是一种很有效的做Web性能测试的“兵法”，这正是本篇命名为“兵法篇”的目的。“兵法”是“将帅”们“打仗”的必备知识，学会了兵法才可以指挥战争，但是兵法毕竟不能代替具体的“战术”，它只是“打胜仗”的前提条件，具体的“仗”怎么去“打”，仍然要根据具体的战场情况来指挥。因此，具体的Web性能测试工作仍然按照项目的自身特点去组织和实施。

作者：吴老师   发布时间：2012-02-18  浏览次数：128 次

       路由器是IP网络的核心设备，其性能的好坏直接影响IP网网络规模、网络稳定性以及网络可扩展性。路由器区别于一般简单的网络互连设备，在性能测试时还应该加上路由器特有的性能测试。路由器在计算机网络中有着举足轻重的地位，是计算机网络的桥梁。通过它不仅可以连通不同的网络，还能选择数据传送的路径，并能阻隔非法的访问。 路由器的配置对初学者来说，并不是件十分容易的事。　　(一)功能测试

　　路由器功能通常可以划分为如下方面。

　　(1)接口功能：该功能用作将路由器连接到网络。可以分为局域网接口及广域网接口两种。局域网接口主要包括以太网、令牌环、令牌总线、FDDI等网络接口。广域网接口主要包括E1/T1、E3/T3、DS3、通用串行口(可转换成X.21DTE/DCE、V.35DTE/DCE、RS232DTE/DCE、RS449DTE/DCE、EIA530DTE)等网络接口。(2)通信协议功能：该功能负责处理通信协议，可以包括TCP/IP、PPP、X.25、帧中继等协议。(3)数据包转发功能：该功能主要负责按照路由表内容在各端口(包括逻辑端口)间转发数据包并且改写链路层数据包头信息。(4)路由信息维护功能：该功能负责运行路由协议，维护路由表。路由协议可包括RIP、OSPF、BGP等协议。(5)管理控制功能：路由器管理控制功能包括五个功能，SNMP代理功能，Telnet服务器功能，本地管理、远端监控和RMON功能。通过多种不同的途径对路由器进行控制管理，并且允许纪录日志。(6)安全功能：用于完成数据包过滤，地址转换，访问控制，数据加密，防火墙，地址分配等功能。

　　路由器对上述功能并非必要完全实现。但是由于路由器作为网络设备，存在最小功能集，对最小功能集所规定的功能，路由器必须支持。因为绝大多数功能测试可以由接口测试、性能测试、协议一致性测试和网管测试所函盖，所以路由器功能测试一般可以只对其他测试无法涵盖的功能作验证性测试。路由器功能测试一般采用远端测试法。 
　　(二)性能测试　路由器是IP网络的核心设备，其性能的好坏直接影响IP网网络规模、网络稳定性以及网络可扩展性。由于IETF没有对路由器性能测试作专门规定，一般来说只能按照RFC2544( Benchmarking Methodology for Network Interconnect Devices)作测试。但路由器区别于一般简单的网络互连设备，在性能测试时还应该加上路由器特有的性能测试。例如路由表容量、路由协议收敛时间等指标。

路由器性能测试应当包括下列指标。

　　(1)吞吐量：测试路由器包转发的能力。通常指路由器在不丢包条件下每秒转发包的极限，一般可以采用二分法查找该极限点。(2)时延：测试路由器在吞吐量范围内从收到包到转发出该包的时间间隔。时延测试应当重复20次然后取其平均值。(3)丢包率：测试路由器在不同负荷下丢弃包占收到包的比例。不同负荷通常指从吞吐量测试到线速(线路上传输包的最高速率)，步长一般使用线速的10%。(4)背靠背帧数：测试路由器在接收到以最小包间隔传输时不丢包条件下所能处理的最大包数。该测试实际考验路由器缓存能力，如果路由器具备线速能力(吞吐量=接口媒体线速)，则该测试没有意义。(5)系统恢复时间：测试路由器在过载后恢复正常工作的时间。测试方法可以采用向路由器端口发送吞吐量110%和线速间的较小值，持续60秒后将速率下降到50%的时刻到最后一个丢包的时间间隔。如果路由器具备线速能力，则该测试没有意义。(6)系统复位：测试路由器从软件复位或关电重启到正常工作的时间间隔。正常工作指能以吞吐量转发数据。

　　在测试上述RFC2544中规定的指标时应当考虑下列因素。
　　帧格式：建议按照RFC2544所规定的帧格式测试;帧长：从最小帧长到MTU顺序递增，例如在以太网上采用64, 128, 256, 512, 1024, 1280, 1518字节;认证接收帧：排除收到的非测试帧，例如控制帧、路由更新帧等;广播帧：验证广播帧对路由器性能的影响，上述测试后在测试帧中夹杂1%广播帧再测试;管理帧：验证管理帧对路由器性能的影响，上述测试后在测试帧中夹杂每秒一个管理帧再测试;路由更新：路由更新即下一跳端口改变对性能的影响;过滤器：在设置过滤器条件下对路由器性能的影响，建议设置25个过滤条件测试;协议地址：测试路由器收到随机处于256个网络中的地址时对性能的影响;双向流量：测试路由器端口双向收发数据对性能的影响;多端口测试：考虑流量全连接分布或非全连接分布对性能的影响;多协议测试：考虑路由器同时处理多种协议对性能的影响;混合包长：除测试所建议的递增包长外，检查混合包长对路由器性能的影响，RFC2544除要求包含所有测试包长外没有对混合包长中各包长所占比例作规定。笔者建议按照实际网络中各包长的分布测试，例如在没有特殊应用要求时以太网接口上可采用60字节包50%，128字节包10%，256字节包15%，512字节包10%，1500字节包15%。除上述RFC2544建议的测试项外还建议测试如下内容。　　

    ①路由震荡：路由震荡对路由器转发能力的影响。路由震荡程度即每秒更新路由的数量可以依据网络条件而定。路由更新协议可采用BGP。②路由表容量：测试路由表大小。骨干网路由器通常运行BGP，路由表包含全球路由。一般来说要求超过10万条路由，建议通过采用BGP输入导出路由计数来测试。③时钟同步：在包含相应端口例如POS口的路由器上测试内钟精度以及同步能力。④协议收敛时间：测试路由变化通知到全网所用时间。该指标虽然与路由器单机性能有关，但是一般只能在网络上测试，而且会因配置改变而变化。可以在网络配置完成后通过检查该指标来衡量全网性能。测试时间应当根据具体项目以及测试目标而定。一般认为测试时间应当介于60秒到300秒之间。另外一般可以根据用户要求和测试目标作设定选择。路由器性能测试一般可采用远端测试法。

2012-07-12 16:24:09|  分类： 设计 |  标签： |字号大中小 订阅

2012-10-31 21:46:52|  分类： LoadRunner |  标签： |字号大中小 订阅

在开始这篇文章之前，大家可以移步去看一下酷壳以前发表的《代码优化概要》，这篇文章基本上告诉你——要进行优化，先得找到性能瓶颈！ 但是在讲如何定位系统性能瓶劲之前，请让我讲一下系统性能的定义和测试，因为没有这两件事，后面的定位和优化无从谈起。
一、系统性能定义让我们先来说说如何什么是系统性能。这个定义非常关键，如果我们不清楚什么是系统性能，那么我们将无法定位之。我见过很多朋友会觉得这很容易，但是仔细一问，其实他们并没有一个比较系统的方法，所以，在这里我想告诉大家如何系统地来定位性能。 总体来说，系统性能就是两个事：

• Throughput ，吞吐量。也就是每秒钟可以处理的请求数，任务数。
• Latency， 系统延迟。也就是系统在处理一个请求或一个任务时的延迟。
  

一般来说，一个系统的性能受到这两个条件的约束，缺一不可。比如，我的系统可以顶得住一百万的并发，但是系统的延迟是2分钟以上，那么，这个一百万的负载毫无意义。系统延迟很短，但是吞吐量很低，同样没有意义。所以，一个好的系统的性能测试必然受到这两个条件的同时作用。 有经验的朋友一定知道，这两个东西的一些关系：

• Throughput越大，Latency会越差。因为请求量过大，系统太繁忙，所以响应速度自然会低。
• Latency越好，能支持的Throughput就会越高。因为Latency短说明处理速度快，于是就可以处理更多的请求。
  

二、系统性能测试经过上述的说明，我们知道要测试系统的性能，需要我们收集系统的Throughput和Latency这两个值。

• 首先，需要定义Latency这个值，比如说，对于网站系统响应时间必需是5秒以内（对于某些实时系统可能需要定义的更短，比如5ms以内，这个更根据不同的业务来定义）
  

• 其次，开发性能测试工具，一个工具用来制造高强度的Throughput，另一个工具用来测量Latency。对于第一个工具，你可以参考一下“十个免费的Web压力测试工具”，关于如何测量Latency，你可以在代码中测量，但是这样会影响程序的执行，而且只能测试到程序内部的Latency，真正的Latency是整个系统都算上，包括操作系统和网络的延时，你可以使用Wireshark来抓网络包来测量。这两个工具具体怎么做，这个还请大家自己思考去了。
  

• 最后，开始性能测试。你需要不断地提升测试的Throughput，然后观察系统的负载情况，如果系统顶得住，那就观察Latency的值。这样，你就可以找到系统的最大负载，并且你可以知道系统的响应延时是多少。
  

再多说一些，

• 关于Latency，如果吞吐量很少，这个值估计会非常稳定，当吞吐量越来越大时，系统的Latency会出现非常剧烈的抖动，所以，我们在测量Latency的时候，我们需要注意到Latency的分布，也就是说，有百分之几的在我们允许的范围，有百分之几的超出了，有百分之几的完全不可接受。也许，平均下来的Latency达标了，但是其中仅有50%的达到了我们可接受的范围。那也没有意义。
  

• 关于性能测试，我们还需要定义一个时间段。比如：在某个吞吐量上持续15分钟。因为当负载到达的时候，系统会变得不稳定，当过了一两分钟后，系统才会稳定。另外，也有可能是，你的系统在这个负载下前几分钟还表现正常，然后就不稳定了，甚至垮了。所以，需要这么一段时间。这个值，我们叫做峰值极限。
  

• 性能测试还需要做Soak Test，也就是在某个吞吐量下，系统可以持续跑一周甚至更长。这个值，我们叫做系统的正常运行的负载极限。
  

性能测试有很多很复要的东西，比如：burst test等。 这里不能一一详述，这里只说了一些和性能调优相关的东西。总之，性能测试是一细活和累活。
三、定位性能瓶颈有了上面的铺垫，我们就可以测试到到系统的性能了，再调优之前，我们先来说说如何找到性能的瓶颈。我见过很多朋友会觉得这很容易，但是仔细一问，其实他们并没有一个比较系统的方法。
3.1）查看操作系统负载首先，当我们系统有问题的时候，我们不要急于去调查我们代码，这个毫无意义。我们首要需要看的是操作系统的报告。看看操作系统的CPU利用率，看看内存使用率，看看操作系统的IO，还有网络的IO，网络链接数，等等。Windows下的perfmon是一个很不错的工具，Linux下也有很多相关的命令和工具，比如：SystemTap，LatencyTOP，vmstat, sar, iostat, top, tcpdump等等 。通过观察这些数据，我们就可以知道我们的软件的性能基本上出在哪里。比如：
1）先看CPU利用率，如果CPU利用率不高，但是系统的Throughput和Latency上不去了，这说明我们的程序并没有忙于计算，而是忙于别的一些事，比如IO。（另外，CPU的利用率还要看内核态的和用户态的，内核态的一上去了，整个系统的性能就下来了。而对于多核CPU来说，CPU 0 是相当关键的，如果CPU 0的负载高，那么会影响其它核的性能，因为CPU各核间是需要有调度的，这靠CPU0完成）
2）然后，我们可以看一下IO大不大，IO和CPU一般是反着来的，CPU利用率高则IO不大，IO大则CPU就小。关于IO，我们要看三个事，一个是磁盘文件IO，一个是驱动程序的IO（如：网卡），一个是内存换页率。这三个事都会影响系统性能。
3）然后，查看一下网络带宽使用情况，在Linux下，你可以使用iftop, iptraf, ntop, tcpdump这些命令来查看。或是用Wireshark来查看。
4）如果CPU不高，IO不高，内存使用不高，网络带宽使用不高。但是系统的性能上不去。这说明你的程序有问题，比如，你的程序被阻塞了。可能是因为等那个锁，可能是因为等某个资源，或者是在切换上下文。
通过了解操作系统的性能，我们才知道性能的问题，比如：带宽不够，内存不够，TCP缓冲区不够，等等，很多时候，不需要调整程序的，只需要调整一下硬件或操作系统的配置就可以了。
3.2）使用Profiler测试接下来，我们需要使用性能检测工具，也就是使用某个Profiler来差看一下我们程序的运行性能。如：Java的JProfiler/TPTP/CodePro Profiler，GNU的gprof，IBM的PurifyPlus，Intel的VTune，AMD的CodeAnalyst，还有Linux下的OProfile/perf，后面两个可以让你对你的代码优化到CPU的微指令级别，如果你关心CPU的L1/L2的缓存调优，那么你需要考虑一下使用VTune。 使用这些Profiler工具，可以让你程序中各个模块函数甚至指令的很多东西，如：运行的时间，调用的次数，CPU的利用率，等等。这些东西对我们来说非常有用。
我们重点观察运行时间最多，调用次数最多的那些函数和指令。这里注意一下，对于调用次数多但是时间很短的函数，你可能只需要轻微优化一下，你的性能就上去了（比如：某函数一秒种被调用100万次，你想想如果你让这个函数提高0.01毫秒的时间 ，这会给你带来多大的性能）
使用Profiler有个问题我们需要注意一下，因为Profiler会让你的程序运行的性能变低，像PurifyPlus这样的工具会在你的代码中插入很多代码，会导致你的程序运行效率变低，从而没发测试出在高吞吐量下的系统的性能，对此，一般有两个方法来定位系统瓶颈：
1）在你的代码中自己做统计，使用微秒级的计时器和函数调用计算器，每隔10秒把统计log到文件中。
2）分段注释你的代码块，让一些函数空转，做Hard Code的Mock，然后再测试一下系统的Throughput和Latency是否有质的变化，如果有，那么被注释的函数就是性能瓶颈，再在这个函数体内注释代码，直到找到最耗性能的语句。
最后再说一点，对于性能测试，不同的Throughput会出现不同的测试结果，不同的测试数据也会有不同的测试结果。所以，用于性能测试的数据非常重要，性能测试中，我们需要观测试不同Throughput的结果。
四、常见的系统瓶颈下面这些东西是我所经历过的一些问题，也许并不全，也许并不对，大家可以补充指正，我纯属抛砖引玉。关于系统架构方面的性能调优，大家可移步看一下《由12306.cn谈谈网站性能技术》，关于Web方面的一些性能调优的东西，大家可以看看《Web开发中需要了解的东西》一文中的性能一章。我在这里就不再说设计和架构上的东西了。
一般来说，性能优化也就是下面的几个策略：

• 用空间换时间。各种cache如CPU L1/L2/RAM到硬盘，都是用空间来换时间的策略。这样策略基本上是把计算的过程一步一步的保存或缓存下来，这样就不用每次用的时候都要再计算一遍，比如数据缓冲，CDN，等。这样的策略还表现为冗余数据，比如数据镜象，负载均衡什么的。
  

• 用时间换空间。有时候，少量的空间可能性能会更好，比如网络传输，如果有一些压缩数据的算法（如前些天说的“Huffman 编码压缩算法” 和 “rsync 的核心算法”），这样的算法其实很耗时，但是因为瓶颈在网络传输，所以用时间来换空间反而能省时间。
  

• 简化代码。最高效的程序就是不执行任何代码的程序，所以，代码越少性能就越高。关于代码级优化的技术大学里的教科书有很多示例了。如：减少循环的层数，减少递归，在循环中少声明变量，少做分配和释放内存的操作，尽量把循环体内的表达式抽到循环外，条件表达的中的多个条件判断的次序，尽量在程序启动时把一些东西准备好，注意函数调用的开销（栈上开销），注意面向对象语言中临时对象的开销，小心使用异常（不要用异常来检查一些可接受可忽略并经常发生的错误），…… 等等，等等，这连东西需要我们非常了解编程语言和常用的库。
  

• 并行处理。如果CPU只有一个核，你要玩多进程，多线程，对于计算密集型的软件会反而更慢（因为操作系统调度和切换开销很大），CPU的核多了才能真正体现出多进程多线程的优势。并行处理需要我们的程序有Scalability，不能水平或垂直扩展的程序无法进行并行处理。从架构上来说，这表再为——是否可以做到不改代码只是加加机器就可以完成性能提升？
  

总之，根据2：8原则来说，20%的代码耗了你80%的性能，找到那20%的代码，你就可以优化那80%的性能。 下面的一些东西都是我的一些经验，我只例举了一些最有价值的性能调优的的方法，供你参考，也欢迎补充。
4.1）算法调优。算法非常重要，好的算法会有更好的性能。举几个我经历过的项目的例子，大家可以感觉一下。

• 一个是过滤算法，系统需要对收到的请求做过滤，我们把可以被filter in/out的东西配置在了一个文件中，原有的过滤算法是遍历过滤配置，后来，我们找到了一种方法可以对这个过滤配置进行排序，这样就可以用二分折半的方法来过滤，系统性能增加了50%。
  

• 一个是哈希算法。计算哈希算法的函数并不高效，一方面是计算太费时，另一方面是碰撞太高，碰撞高了就跟单向链表一个性能（可参看Hash Collision DoS 问题）。我们知道，算法都是和需要处理的数据很有关系的，就算是被大家所嘲笑的“冒泡排序”在某些情况下（大多数数据是排好序的）其效率会高于所有的排序算法。哈希算法也一样，广为人知的哈希算法都是用英文字典做测试，但是我们的业务在数据有其特殊性，所以，对于还需要根据自己的数据来挑选适合的哈希算法。对于我以前的一个项目，公司内某牛人给我发来了一个哈希算法，结果让我们的系统性能上升了150%。（关于各种哈希算法，你一定要看看StackExchange上的这篇关于各种hash算法的文章 ）
  

• 分而治之和预处理。以前有一个程序为了生成月报表，每次都需要计算很长的时间，有时候需要花将近一整天的时间。于是我们把我们找到了一种方法可以把这个算法发成增量式的，也就是说我每天都把当天的数据计算好了后和前一天的报表合并，这样可以大大的节省计算时间，每天的数据计算量只需要20分钟，但是如果我要算整个月的，系统则需要10个小时以上（SQL语句在大数据量面前性能成级数性下降）。这种分而治之的思路在大数据面前对性能有很帮助，就像merge排序一样。SQL语句和数据库的性能优化也是这一策略，如：使用嵌套式的Select而不是笛卡尔积的Select，使用视图，等等。
  

4.2）代码调优。从我的经验上来说，代码上的调优有下面这几点：

• 字符串操作。这是最费系统性能的事了，无论是strcpy, strcat还是strlen，最需要注意的是字符串子串匹配。所以，能用整型最好用整型。举几个例子，第一个例子是N年前做银行的时候，我的同事喜欢把日期存成字符串（如：2012-05-29 08:30:02），我勒个去，一个select  where between语句相当耗时。另一个例子是，我以前有个同事把一些状态码用字符串来处理，他的理由是，这样可以在界面上直接显示，后来性能调优的时候，我把这些状态码全改成整型，然后用位操作查状态，因为有一个每秒钟被调用了150K次的函数里面有三处需要检查状态，经过改善以后，整个系统的性能上升了30%左右。还有一个例子是，我以前从事的某个产品编程规范中有一条是要在每个函数中把函数名定义出来，如：const char fname[]=”functionName()”, 这是为了好打日志，但是为什么不声明成 static类型的呢？
  

• 多线程调优。有人说，thread is evil，这个对于系统性能在某些时候是个问题。因为多线程瓶颈就在于互斥和同步的锁上，以及线程上下文切换的成本，怎么样的少用锁或不用锁是根本（比如：多版本并发控制(MVCC)在分布式系统中的应用 中说的乐观锁可以解决性能问题），此外，还有读写锁也可以解决大多数是读操作的并发的性能问题。这里多说一点在C++中，我们可能会使用线程安全的智能指针AutoPtr或是别的一些容器，只要是线程安全的，其不管三七二十一都要上锁，上锁是个成本很高的操作，使用AutoPtr会让我们的系统性能下降得很快，如果你可以保证不会有线程并发问题，那么你应该不要用AutoPtr。我记得我上次我们同事去掉智能指针的引用计数，让系统性能提升了50%以上。对于Java对象的引用计数，如果我猜的没错的话，到处都是锁，所以，Java的性能问题一直是个问题。另外，线程不是越多越好，线程间的调度和上下文切换也是很夸张的事，尽可能的在一个线程里干，尽可能的不要同步线程。这会让你有很多的性能。
  

• 内存分配。不要小看程序的内存分配。malloc/realloc/calloc这样的系统调非常耗时，尤其是当内存出现碎片的时候。我以前的公司出过这样一个问题——在用户的站点上，我们的程序有一天不响应了，用GDB跟进去一看，系统hang在了malloc操作上，20秒都没有返回，重启一些系统就好了。这就是内存碎片的问题。这就是为什么很多人抱怨STL有严重的内存碎片的问题，因为太多的小内存的分配释放了。有很多人会以为用内存池可以解决这个问题，但是实际上他们只是重新发明了Runtime-C或操作系统的内存管理机制，完全于事无补。当然解决内存碎片的问题还是通过内存池，具体来说是一系列不同尺寸的内存池（这个留给大家自己去思考）。当然，少进行动态内存分配是最好的。说到内存池就需要说一下池化技术。比如线程池，连接池等。池化技术对于一些短作业来说（如http服务） 相当相当的有效。这项技术可以减少链接建立，线程创建的开销，从而提高性能。
  

• 异步操作。我们知道Unix下的文件操作是有block和non-block的方式的，像有些系统调用也是block式的，如：Socket下的select，Windows下的WaitforObject之类的，如果我们的程序是同步操作，那么会非常影响性能，我们可以改成异步的，但是改成异步的方式会让你的程序变复杂。异步方式一般要通过队列，要注间队列的性能问题，另外，异步下的状态通知通常是个问题，比如消息事件通知方式，有callback方式，等，这些方式同样可能会影响你的性能。但是通常来说，异步操作会让性能的吞吐率有很大提升（Throughput），但是会牺牲系统的响应时间（latency）。这需要业务上支持。
  

• 语言和代码库。我们要熟悉语言以及所使用的函数库或类库的性能。比如：STL中的很多容器分配了内存后，那怕你删除元素，内存也不会回收，其会造成内存泄露的假像，并可能造成内存碎片问题。再如，STL某些容器的size()==0  和 empty()是不一样的，因为，size()是O(n)复杂度，empty()是O(1)的复杂度，这个要小心。Java中的JVM调优需要使用的这些参数：-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold，还需要注意JVM的GC，GC的霸气大家都知道，尤其是full GC（还整理内存碎片），他就像“恐龙特级克赛号”一样，他运行的时候，整个世界的时间都停止了。
  

4.3）网络调优
关于网络调优，尤其是TCP Tuning（你可以以这两个关键词在网上找到很多文章），这里面有很多很多东西可以说。看看Linux下TCP/IP的那么多参数就知道了（顺便说一下，你也许不喜欢Linux，但是你不能否认Linux给我们了很多可以进行内核调优的权力）。强烈建议大家看看《TCP/IP 详解 卷1:协议》这本书。我在这里只讲一些概念上的东西。
A） TCP调优
我们知道TCP链接是有很多开销的，一个是会占用文件描述符，另一个是会开缓存，一般来说一个系统可以支持的TCP链接数是有限的，我们需要清楚地认识到TCP链接对系统的开销是很大的。正是因为TCP是耗资源的，所以，很多攻击都是让你系统上出现大量的TCP链接，把你的系统资源耗尽。比如著名的SYNC Flood攻击。
所以，我们要注意配置KeepAlive参数，这个参数的意思是定义一个时间，如果链接上没有数据传输，系统会在这个时间发一个包，如果没有收到回应，那么TCP就认为链接断了，然后就会把链接关闭，这样可以回收系统资源开销。（注：HTTP层上也有KeepAlive参数）对于像HTTP这样的短链接，设置一个1-2分钟的keepalive非常重要。这可以在一定程度上防止DoS攻击。有下面几个参数（下面这些参数的值仅供参考）：

1 2 3

net.ipv4.tcp_keepalive_probes = 5 net.ipv4.tcp_keepalive_intvl = 20 net.ipv4.tcp_fin_timeout = 30

对于TCP的TIME_WAIT这个状态，主动关闭的一方进入TIME_WAIT状态，TIME_WAIT状态将持续2个MSL(Max Segment Lifetime)，默认为4分钟，TIME_WAIT状态下的资源不能回收。有大量的TIME_WAIT链接的情况一般是在HTTP服务器上。对此，有两个参数需要注意，

1 2	net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_tw_recycle=1

前者表示重用TIME_WAIT，后者表示回收TIME_WAIT的资源。
TCP还有一个重要的概念叫RWIN（TCP Receive Window Size），这个东西的意思是，我一个TCP链接在没有向Sender发出ack时可以接收到的最大的数据包。为什么这个很重要？因为如果Sender没有收到Receiver发过来ack，Sender就会停止发送数据并会等一段时间，如果超时，那么就会重传。这就是为什么TCP链接是可靠链接的原因。重传还不是最严重的，如果有丢包发生的话，TCP的带宽使用率会马上受到影响（会盲目减半），再丢包，再减半，然后如果不丢包了，就逐步恢复。相关参数如下：

1 2 3 4

net.core.wmem_default = 8388608 net.core.rmem_default = 8388608 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216

一般来说，理论上的RWIN应该设置成：吞吐量  * 回路时间。Sender端的buffer应该和RWIN有一样的大小，因为Sender端发送完数据后要等Receiver端确认，如果网络延时很大，buffer过小了，确认的次数就会多，于是性能就不高，对网络的利用率也就不高了。也就是说，对于延迟大的网络，我们需要大的buffer，这样可以少一点ack，多一些数据，对于响应快一点的网络，可以少一些buffer。因为，如果有丢包（没有收到ack），buffer过大可能会有问题，因为这会让TCP重传所有的数据，反而影响网络性能。（当然，网络差的情况下，就别玩什么高性能了） 所以，高性能的网络重要的是要让网络丢包率非常非常地小（基本上是用在LAN里），如果网络基本是可信的，这样用大一点的buffer会有更好的网络传输性能（来来回回太多太影响性能了）。
另外，我们想一想，如果网络质量非常好，基本不丢包，而业务上我们不怕偶尔丢几个包，如果是这样的话，那么，我们为什么不用速度更快的UDP呢？你想过这个问题了吗？
B）UDP调优
说到UDP的调优，有一些事我想重点说一样，那就是MTU——最大传输单元（其实这对TCP也一样，因为这是链路层上的东西）。所谓最大传输单元，你可以想像成是公路上的公交车，假设一个公交车可以最多坐70人，带宽就像是公路的车道数一样，如果一条路上最多可以容下100辆公交车，那意味着我最多可以运送7000人，但是如果公交车坐不满，比如平均每辆车只有20人，那么我只运送了2000人，于是我公路资源（带宽资源）就被浪费了。 所以，我们对于一个UDP的包，我们要尽量地让他大到MTU的最大尺寸再往网络上传，这样可以最大化带宽利用率。对于这个MTU，以太网是1500字节，光纤是4352字节，802.11无线网是7981。但是，当我们用TCP/UDP发包的时候，我们的有效负载Payload要低于这个值，因为IP协议会加上20个字节，UDP会加上8个字节（TCP加的更多），所以，一般来说，你的一个UDP包的最大应该是1500-8-20=1472，这是你的数据的大小。当然，如果你用光纤的话， 这个值就可以更大一些。（顺便说一下，对于某些NB的千光以态网网卡来说，在网卡上，网卡硬件如果发现你的包的大小超过了MTU，其会帮你做fragment，到了目标端又会帮你做重组，这就不需要你在程序中处理了）
再多说一下，使用Socket编程的时候，你可以使用setsockopt() 设置 SO_SNDBUF/SO_RCVBUF 的大小，TTL和KeepAlive这些关键的设置，当然，还有很多，具体你可以查看一下Socket的手册。
最后说一点，UDP还有一个最大的好处是multi-cast多播，这个技术对于你需要在内网里通知多台结点时非常方便和高效。而且，多播这种技术对于机会的水平扩展（需要增加机器来侦听多播信息）也很有利。
C）网卡调优
对于网卡，我们也是可以调优的，这对于千兆以及网网卡非常必要，在Linux下，我们可以用ifconfig查看网上的统计信息，如果我们看到overrun上有数据，我们就可能需要调整一下txqueuelen的尺寸（一般默认为1000），我们可以调大一些，如：ifconfig eth0 txqueuelen 5000。Linux下还有一个命令叫：ethtool可以用于设置网卡的缓冲区大小。在Windows下，我们可以在网卡适配器中的高级选项卡中调整相关的参数（如：Receive Buffers, Transmit Buffer等，不同的网卡有不同的参数）。把Buffer调大对于需要大数据量的网络传输非常有效。
D）其它网络性能
关于多路复用技术，也就是用一个线程来管理所有的TCP链接，有三个系统调用要重点注意：一个是select，这个系统调用只支持上限1024个链接，第二个是poll，其可以突破1024的限制，但是select和poll本质上是使用的轮询机制，轮询机制在链接多的时候性能很差，因主是O(n)的算法，所以，epoll出现了，epoll是操作系统内核支持的，仅当在链接活跃时，操作系统才会callback，这是由操作系统通知触发的，但其只有Linux Kernel 2.6以后才支持（准确说是2.5.44中引入的），当然，如果所有的链接都是活跃的，过多的使用epoll_ctl可能会比轮询的方式还影响性能，不过影响的不大。
另外，关于一些和DNS Lookup的系统调用要小心，比如：gethostbyaddr/gethostbyname，这个函数可能会相当的费时，因为其要到网络上去找域名，因为DNS的递归查询，会导致严重超时，而又不能通过设置什么参数来设置time out，对此你可以通过配置hosts文件来加快速度，或是自己在内存中管理对应表，在程序启动时查好，而不要在运行时每次都查。另外，在多线程下面，gethostbyname会一个更严重的问题，就是如果有一个线程的gethostbyname发生阻塞，其它线程都会在gethostbyname处发生阻塞，这个比较变态，要小心。（你可以试试GNU的gethostbyname_r()，这个的性能要好一些） 这种到网上找信息的东西很多，比如，如果你的Linux使用了NIS，或是NFS，某些用户或文件相关的系统调用就很慢，所以要小心。
4.4）系统调优
A）I/O模型
前面说到过select/poll/epoll这三个系统调用，我们都知道，Unix/Linux下把所有的设备都当成文件来进行I/O，所以，那三个操作更应该算是I/O相关的系统调用。说到  I/O模型，这对于我们的I/O性能相当重要，我们知道，Unix/Linux经典的I/O方式是（关于Linux下的I/O模型，大家可以读一下这篇文章《使用异步I/O大大提高性能》）：
第一种，同步阻塞式I/O，这个不说了。
第二种，同步无阻塞方式。其通过fctnl设置 O_NONBLOCK 来完成。
第三种，对于select/poll/epoll这三个是I/O不阻塞，但是在事件上阻塞，算是：I/O异步，事件同步的调用。
第四种，AIO方式。这种I/O 模型是一种处理与 I/O 并行的模型。I/O请求会立即返回，说明请求已经成功发起了。在后台完成I/O操作时，向应用程序发起通知，通知有两种方式：一种是产生一个信号，另一种是执行一个基于线程的回调函数来完成这次 I/O 处理过程。
第四种因为没有任何的阻塞，无论是I/O上，还是事件通知上，所以，其可以让你充分地利用CPU，比起第二种同步无阻塞好处就是，第二种要你一遍一遍地去轮询。Nginx之所所以高效，是其使用了epoll和AIO的方式来进行I/O的。
再说一下Windows下的I/O模型，
a）一个是WriteFile系统调用，这个系统调用可以是同步阻塞的，也可以是同步无阻塞的，关于看文件是不是以Overlapped打开的。关于同步无阻塞，需要设置其最后一个参数Overlapped，微软叫Overlapped I/O，你需要WaitForSingleObject才能知道有没有写完成。这个系统调用的性能可想而知。
b）另一个叫WriteFileEx的系统调用，其可以实现异步I/O，并可以让你传入一个callback函数，等I/O结束后回调之， 但是这个回调的过程Windows是把callback函数放到了APC（Asynchronous Procedure Calls）的队列中，然后，只用当应用程序当前线程成为可被通知状态（Alterable）时，才会被回调。只有当你的线程使用了这几个函数时WaitForSingleObjectEx,WaitForMultipleObjectsEx, MsgWaitForMultipleObjectsEx, SignalObjectAndWait 和 SleepEx，线程才会成为Alterable状态。可见，这个模型，还是有wait，所以性能也不高。
c）然后是IOCP – IO Completion Port，IOCP会把I/O的结果放在一个队列中，但是，侦听这个队列的不是主线程，而是专门来干这个事的一个或多个线程去干（老的平台要你自己创建线程，新的平台是你可以创建一个线程池）。IOCP是一个线程池模型。这个和Linux下的AIO模型比较相似，但是实现方式和使用方式完全不一样。
当然，真正提高I/O性能方式是把和外设的I/O的次数降到最低，最好没有，所以，对于读来说，内存cache通常可以从质上提升性能，因为内存比外设快太多了。对于写来说，cache住要写的数据，少写几次，但是cache带来的问题就是实时性的问题，也就是latency会变大，我们需要在写的次数上和相应上做权衡。
B）多核CPU调优
关于CPU的多核技术，我们知道，CPU0是很关键的，如果0号CPU被用得过狠的话，别的CPU性能也会下降，因为CPU0是有调整功能的，所以，我们不能任由操作系统负载均衡，因为我们自己更了解自己的程序，所以，我们可以手动地为其分配CPU核，而不会过多地占用CPU0，或是让我们关键进程和一堆别的进程挤在一起。

• 对于Windows来说，我们可以通过“任务管理器”中的“进程”而中右键菜单中的“设置相关性……”（Set Affinity…）来设置并限制这个进程能被运行在哪些核上。
  

• 对于Linux来说，可以使用taskset命令来设置（你可以通过安装schedutils来安装这个命令：apt-get install schedutils）
  

多核CPU还有一个技术叫NUMA技术（Non-Uniform. Memory Access）。传统的多核运算是使用SMP(Symmetric Multi-Processor )模式，多个处理器共享一个集中的存储器和I/O总线。于是就会出现一致存储器访问的问题，一致性通常意味着性能问题。NUMA模式下，处理器被划分成多个node， 每个node有自己的本地存储器空间。关于NUMA的一些技术细节，你可以查看一下这篇文章《Linux 的 NUMA 技术》，在Linux下，对NUMA调优的命令是：numactl 。如下面的命令：（指定命令“myprogram arg1 arg2”运行在node 0 上，其内存分配在node 0 和 1上）

1	numactl --cpubind=0 --membind=0,1 myprogram arg1 arg2

当然，上面这个命令并不好，因为内存跨越了两个node，这非常不好。最好的方式是只让程序访问和自己运行一样的node，如：

1	$ numactl --membind 1 --cpunodebind 1 --localalloc myapplication

C）文件系统调优
关于文件系统，因为文件系统也是有cache的，所以，为了让文件系统有最大的性能。首要的事情就是分配足够大的内存，这个非常关键，在Linux下可以使用free命令来查看 free/used/buffers/cached，理想来说，buffers和cached应该有40%左右。然后是一个快速的硬盘控制器，SCSI会好很多。最快的是Intel SSD 固态硬盘，速度超快，但是写次数有限。
接下来，我们就可以调优文件系统配置了，对于Linux的Ext3/4来说，几乎在所有情况下都有所帮助的一个参数是关闭文件系统访问时间，在/etc/fstab下看看你的文件系统 有没有noatime参数（一般来说应该有），还有一个是dealloc，它可以让系统在最后时刻决定写入文件发生时使用哪个块，可优化这个写入程序。还要注间一下三种日志模式：data=journal、data=ordered和data=writeback。默认设置data=ordered提供性能和防护之间的最佳平衡。
当然，对于这些来说，ext4的默认设置基本上是最佳优化了。
这里介绍一个Linux下的查看I/O的命令—— iotop，可以让你看到各进程的磁盘读写的负载情况。
其它还有一些关于NFS、XFS的调优，大家可以上google搜索一些相关优化的文章看看。关于各文件系统，大家可以看一下这篇文章——《Linux日志文件系统及性能分析》
4.5）数据库调优
数据库调优并不是我的强项，我就仅用我非常有限的知识说上一些吧。注意，下面的这些东西并不一定正确，因为在不同的业务场景，不同的数据库设计下可能会得到完全相反的结论，所以，我仅在这里做一些一般性的说明，具体问题还要具体分析。

查看(294) 评论(0) 收藏 分享 管理

一，数据类型转换51Testing软件测试网Z_.AW+A)D7H0c

没有使用过C编程的LoadRunner脚本编写者会发现在数据类型转化方面比较困难。下面介绍这方面的知识。

1． 相似函数的输出在不同的位置51Testing软件测试网;X6w/h(r D

象很多C函数一样，使用atoi函数的结果即为返回值

如intResult = atoi( charY );51Testing软件测试网5M4Prp0@y.v,R*yQ

而：itoa的返回结果为第二个参数。

itoa( intX, charY, 10);51Testing软件测试网/SB#XI,l$T

  第一个参数是需要转换的数字，第二个参数是转换后存储的字符数组，需要注意的是数组必须定义为固定的长度，如：char chary[20]；51Testing软件测试网7MC-Y4ZUiBWf+[
f)D

数组的最大长度为32064（32K），否则会出现“too many variables”编译错误。

如果定义为变长的字符串如char *charY，则程序会出错。

  第三个参数不是数组的长度，而是数字的基数，10进制是最常用的，其他还有二进制，八进制，十六进制。51Testing软件测试网
Cz3`:WU |

2． 有一些函数实现了同样的功能

itoa不是一个标准的ANSI C函数但是是C的stdlib.h中的一个函数。所以它不被包括在unix机器上的LibC中。我们可以使用标准的sprintf函数来代替：51Testing软件测试网Efkd.f

sprintf（charY，“%d”，intX）；

3． 是用%X来转换一个十六进制数51Testing软件测试网3E6w cp5h1~q8^

int intNum；51Testing软件测试网L;F#S!xK9c

sscanf（“ffff”，“%X”，&Num）;51Testing软件测试网}aPYx5^

lr_output_message(“%d”,intNum); //打印65535 ,ffff的整数值

4． 从文本中提取数字的规则51Testing软件测试网aQY!S xy7`8d3A-D c

如果第一个字符不是数字或者为空，atoi返回0，即“e24”会返回051Testing软件测试网l&_0H&q4kk

atoi转换一个非数字的字符会返回组成这个字符的数字，如“-3.2”返回-3.0。“123XXX345”返回123。51Testing软件测试网3JeG4Jy_ y ^5VyM

5． LoadRunner脚本中的参数必须转换成C字符串。有两种方式来转化LR的参数为C语言的数字。

 i = atoi( lr_eval_string("{pX}") );51Testing软件测试网RKh*P6j.K

sprintf( intX, "%d", lr_eval_string("{pX}") );51Testing软件测试网x E(^/N^2[0IX

6． 参数的算术运算

LoadRunner没有提供对参数的算术运算的函数。所以LR的参数必须：51Testing软件测试网 e)v!D"P6T K^

1） 转换成C的整数

2） 使用C的函数来运算最后返回一个C的字符串51Testing软件测试网mHjc jj

3） 把返回的字符串保存成参数51Testing软件测试网WYCg
^c8S[b

char cBuf[10];51Testing软件测试网'e s&[&\7@3Q~`

int i;51Testing软件测试网0tN N?&_.H@

// 1. Evaluate parameter into a C integer:

i = atoi( lr_eval_string("{pNum_in}") );51Testing软件测试网 iy N{r$L

// 2. Do the math and output the result to a C string:

sprintf( cBuf, "%d", i+1);

// 3. Save the string as a parameter to be passed on:

lr_save_string( cBuf, "pNum_out");51Testing软件测试网(x1D ]`"}M

//Print out the parameter value after incrementing it.51Testing软件测试网}!xQ+hl1weW

lr_message("**** Parameter from %s to %s",

    lr_eval_string("{pNum_in}"));

    lr_eval_string("{pNum_out}"));51Testing软件测试网qFP1Z/O1M

zibeike注：除了对于数字类型的参数的运算之外，对于文本形式的参数的操作，可以参考我的另一篇文章的内容：http://www.51testing.com/?34866/action_viewspace_itemid_75592.html51Testing软件测试网Axy ?7}:l1~

二．字符串操作51Testing软件测试网.`-t a9OS

在C语言中，字符串是固定长度的，因为他们本身由独立的字符组成的字符数组。数组是只读的。任何修改字符串长度的函数调用都会报错：51Testing软件测试网f { ~*Z`g!\%V*G

)gdP9k&a241266Error: "C interpreter runtime error - memory violation error during replay.51Testing软件测试网%Zp6zT%x Ol2N*W

在LoadRunner的as_web.h库中的字符串函数可以使用“prototyping”声明的方式读写内存：

char *strtok(char *, char *); // tokenizer prototype

char *strstr(char *, char *); // substring prototype

char *strdup(char *); // String duplication prototype

float atof(); // alpha to return float datatype

#include "as_web.h"

char *strtok(char *, char *); // prototype function call.

ActionX()

{

  char aBuffer[256]; // input string to be parsed.

  char *cToken; // individual token from strtok.

  char cSeparator[] = " "; // blank separator.

  int i; // incrementer

  char val[3][20]; // output array of strings.

  char modified_val[20];

  // Create a parameter named pDate:

  lr_save_string("January 2, 2001", "pDate");

  // Put parameter into a string buffer:

  strcpy( aBuffer,lr_eval_string("{pDate}"));

  // Show the buffer for debugging:

  lr_output_message("%s\n",aBuffer);

  // get first word (to the first blank):

  cToken = strtok( aBuffer,cSeparator);

  i = 1;

  if(!token) { // first token was not found:

          lr_output_message("No tokens found in string!");

          return( -1 );

  } else {

          while( cToken != NULL) { // tokens are not NULL:

                 lr_output_message("Token=%s", cToken);

                  // Stuff in another array:

                  strcpy( val[i], cToken );

                  // Get next token:

                  cToken =strtok( NULL, cSeparator);

                  i++; // increment

          }

          lr_output_message("Val #1 is: %s", val[1]);

          lr_output_message("Val #2 is: %s", val[2]);

          lr_output_message("Val #2 is: %s", val[3]);

          strncpy( modified_val, val[2], 1 );

          modified_val[2] = '\0';

          while (modified_val[2] != NULL) {

                  lr_output_message("===>%s", modified_val);

                  modified_val[2] = strtok(NULL, " ");

          }

  }

  return 0;

}

strcat连接两个字符串

strchr返回指向第一个要查找的字符出现的位置的指针

strcmp比较两个字符

strcpy复制字符串到另一个

stricmp执行一个大小写敏感的比较

其他还有strdup，strncat，strncpy，strnicmp，strrchr，strset，strspn，strstr等字符串操作的函数。

引入"业务组件"的概念，有助于我们实现业务流程之间的组合，组合不同的组件实现不同的流程测试，规范业务流程，提高测试的覆盖率，这是个扩展应用，但是我们暂时用不到这个功能，所以将之屏蔽掉
屏蔽的方法，管理员进入qcbin之后-》自定义-》用户访问模块-》将业务组件对于相应的组进行关闭即可。

注：
Business Process Testing（业务组件测试）需要Mercury Quality Center与QuickTest Professional配合才能运作。同时测试团队中也需要二种角色，一是熟悉QuickTest Professional测试工具的人员（Automation Engineer），负责建立并维护Application Area、物件库（object repository）、library files、recovery scenarios，另外也需要负责对Business Component进行除错的工作；另一是非常熟悉业务流程的人员（Subject Matter Expert），透过Quality Center介面，设计Business Component以及Business Process Test并运用Application Area将其自动化。
其实qc的业务组件模块功能与测试计划模块功能类似，一般企业不适合用业务组件这个功能，因为他需要业务人员参与到测试的整个流程中，而实际一般的公司这不存在这个情况。
业务组件的操作流程，业务组件中的组件可以等同于测试计划中的测试用例。
业务人员组织开发业务的测试流程（非脚本，仅限操作步骤）-》测试人员开发qtp的脚本与维护-》测试人员在测试计划中将业务组件（也就是测试用例）添加到测试计划中来，后面的流程与qc的基本测试流程是一致的。

怎样做一个让领导和开发人员认可的测试人员

发布时间: 2011-7-18 16:00    作者: 槛外人    来源: 51Testing软件测试网采编

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： 软件测试

如何写好测试用例

发布时间: 2011-8-03 15:00    作者: 未知    来源: 51Testing软件测试网采编

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： 软件测试 用例设计 测试用例