在测试工程师的日常工作中,最经常做的也是必须做的就是提交缺陷报告.在提交Bug的时候,我们要给出这个Bug的优先级(Priority),开发人员会根据Bug的优先级来决定先修那个Bug,后修哪个Bug.所以优先级的正确与否会影响到Bug的解决时间进而可能会影响测试和开发的进度.对于一个Bug的优先级也往往是QA和RD争论的焦点.

   在我们的公司中Bug的优先级根据其严重度和发生的频率和环境来决定.首先一个Bug有5种严重程度的定义:

严重度A--系统Crash,不能进行安装等;

严重度B--需求说明书中要求的重要功能没有实现;

严重度C--功能存在缺陷;

严重度D--功能可以进一步改进;

严重度E--建议

优先级的定义如下:

Priority 1--必须立即修复;

Priority 2--在Beta前必须修复;

Priority 3--在release前必须修复;

Priority 4--在下一版修复;

Priority 5--可以修复或不修;

接下来根据Bug发生的频率和环境建立一张优先级Mapping表.

根据这张表就可以很容易定义Bug的优先级了.

    网络是所有子系统中最难监控的了。首先是由于网络是抽象的，更重要的是许多影响网络的因素并不在我们的控制范围之内。这些因素包括，延迟、冲突、阻塞等等。

    大部分的以太网络都是自适应速度的，因为一个网络中可能有不同的网络设备采用不同的速率和工作模式（全双工或半双工）。大部分企业网络都工作在100到1000BaseTX。ethtool命令可以设置网卡的工作速率和模式。

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
                      100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

我们可以看到网卡工作在10Mb/s，模式为半双工，并且打开了自适应开关。我们通过下列命令强制设置网卡工作在100Mb/s全双工模式，并关闭自适应功能。

# ethtool -s eth0 speed 100 duplex full autoneg off

再次运行ethtool显示如下：

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
                      100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

用iptraf工具可以清楚的看到每个网卡的工作情况。

# iptraf –d eth0

利用iptraf还可以监听固定TCP端口的流量，如对于Web服务器我们希望监听80端口的流量，对于邮件服务器我们关注25端口的流量。

网络中最常见的错误就是冲突，由于网络中目前基本采用交换机环境，因此冲突问题已被消除。但是当网络流量不断增大的时候，就会出现丢包，网卡过载等情况。在网络流量很大的时候我们用sar命令来给出网络中可能的错误:

# sar -n FULL 5 100
Linux 2.6.9-55.ELsmp (sapulpa) 06/23/2007
11:44:32 AM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s
11:44:37 AM lo 6.00 6.00 424.40 424.40 0.00 0.00 0.00
11:44:37 AM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:37 AM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:32 AM IFACE rxerr/s txerr/s coll/s rxdrop/s txdrop/s txcarr/s rxfram/s rxfifo/s txfifo/s
11:44:37 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:37 AM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:37 AM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:32 AM totsck tcpsck udpsck rawsck ip-frag
11:44:37 AM 297 79 8 0 0

   rxerr/s是接受错误率；txerr/s是发送错误率；coll/s冲突率；rxdrop/s接受帧丢失率；txdrop/s发送帧丢失率；txcarr/s载波错误率；rxfram/s帧排列错误；rxfifo/s接受FIFO错误；txfifo/s发送FIFO错误。从上面输出看出各种错误为零，证明网络工作良好。

   总的来说监视网络性能，我们有遵循一下几点：

1. 检查所有网络接口确保他们都运行在正确的速率；

2. 检查每块网卡的吞吐量确保没有造成过载；

3. 检查流量的类型确保正确的数据流在传送。

    最近用了badboy软件做了一些自动化测试，总体感觉还是很不错的。它的一个优点是可以支持2种录制方式，一种是只录制http请求，一种是录制真正的UI操作如QTP。另外一个好处是它可以将Http请求形式的脚本存成Jmeter的jmx格式，这样JMeter中就可以直接使用。这点对于测试Https协议很有用，因为JMeter并不能录制Https连接中的内容。当然其他UI自动化所必须的基本功能它也具备，如参数化，断言等。另外它还可以给出一些性能方面的数据Response Time。

   当然也有缺点。如只支持IE浏览器，但最大的缺点就是没有办法手工编辑录制的脚本，不像robot和QTP可以直接用支持的语言来修改录制好的脚本。有兴趣的话可以去badboy网站下载玩玩：

http://www.badboy.com.au/

    黑盒测试和白盒测试是两种不同的测试方法.在整个的测试过程中两种方法都会用到,但以经验来看,在一个项目中测试工程师还是以黑盒测试为主,白盒测试为辅.对于有些人认为黑盒测试没有技术含量,这是完全错误的一种看法,好的黑盒测试需要丰富的经验和敏锐的思维.

黑盒测试的特点:

1. 不基于对系统内部的设计和实现.

2. 用例设计基于功能的定义和需求说明书.

3. 关注于测试数据的选择和测试结果的分析.

常见的黑盒测试有,功能测试、压力测试、易用性测试和性能测试等。

使用的测试方法有，等价类划分、边界值测试、错误测试、启发性测试等。

当然黑盒测试也存在一些弊端：

1. 对用例设计人员的经验要求较高，包括数据的选择，对潜在错误的敏感性；

2. 对于内部实现的bug不容易发现；

3. 不能提供直观的测试覆盖率。

白盒测试的特点：

1. 需要了解系统的整体设计和实现；

2. 对源代码进行审查；

3. 在单元测试阶段发现大量的缺陷；

4. 关注于系统的控制流和数据流；

常用的一些白盒测试方法有，独立路径测试、逻辑判断测试、数据结构测试、覆盖率测试等。

白盒测试的不足之处有：

1. 不能确保系统是否完全符合需求说明书；

2. 白盒测试的代价会大于黑盒测试；

3. 需要源代码首先完成才能进行测试；

   在我们的项目中的实践方法是，在早期开发人员通过做单元测试和代码审查来完成白盒测试的大部分，相应的测试模块的分责人也会参与开发人员的Design Review Meeting。在集成测试和系统测试部分主要是测试人员进行黑盒测试，必要时会对一些核心模块或者bug比较多的模块与开发人员一起重新做Code Review。在产品比较稳定之后，会采用一些测试工具如Rational Purecoverage来做覆盖率测试，通过覆盖率测试可以发现哪些函数没有跑到，进而更新或加入新的测试用例。但覆盖率不可能100%，一般采取的标准是函数覆盖率90%，语句覆盖率70%。

    JMeter也支持POP3邮件协议的测试(通过Mail Reader Sampler),但默认的发行版没有包含JavaMail包,所以要进行POP3测试之前先要下载JavaMail,目前最新版本为1.4.1.否则将会出现图1所示的错误.下载地址:

http://java.sun.com/products/javamail/index.jsp.

下载完成后将lib中的jar包(smtp.jar,pop3.jar等)放入JMeter_Home\lib下. 然后重新启动JMeter.

                              图 1

   接下来用5个thread从邮件服务器收信(设置Thread Group的User数为5),当一个用户登录POP3服务器之后,帐户就被lock.因此同一账户不能再次登录.我们需要参数化登录的用户,使每个Thread用不同的帐号来登录.否则就会出现用户登录错误的异常. 通过在Mail Reader Sampler下加入CSV date set config来实现.我定义了2个变量一个user,一个passwd,代表了POP3登录所要求的用户名和密码.在user.txt中有5行记录,分别是5个用户的用户名和密码.如图2:

                                     图 2

这个时候,每一个thread就会读取user.txt文件中的一行.因此5个thread模拟5个不同的用户收信.当测试计划的loop count大于1的时候,JMeter的thread会多次登录用户邮箱,还需要加入一个Constant Timer来防止在用户邮箱还没unlock的情况下,紧接着就进行下一轮测试进而产生用户帐户锁定的异常.

设置Mail Reader Sampler的参数如图3:

                                  图 3

运行测试计划,通过View Results Tree来观察结果.测试全部成功.如图4:

                                  图 4

   对于Web的性能测试,我们可以选择JMeter的Sampler(Http Request)来实现发送请求.但是在大多数时候,我们并不十分清楚测试用例所包含的所有http请求.在这种情况下,我们可以用Http Proxy Server来录制测试步骤中的Http请求.

1. 加入Http Proxy Server(右键WorkBench,选择Add->Non-Test Elements-Http Proxy Server)

2. 进行相应配置,如录制的请求的存放地点(Target Controller),默认的时候会查找Recording Controller,将请求放在它的下面.还需要设置Grouping来确定是否对请求进行分组.Patterns to Include和Patterns to Exclude用来过滤请求,进而只录制我们需要的请求类型,如"*.\.html"只记录html请求.

3. 设置浏览器的proxy server指向JMeter的机器,端口为8080.

4. 点击Http Proxy Server上的Start按钮,操作浏览器进行测试,点击Stop按钮停止录制.

你将会看到一系列的http请求加入到测试计划中.

    如果在Target Controller或它的父Controller中存在 HTTP Request Defaults,那么在录制好的Http请求中,所有HTTP Request Defaults中定义的元素将会以空白代替,比如 HTTP Request Defaults中定义了Server Name or IP,那么所有 HTTP Request中的此项都为空.

    如果在Target Controller或它的父Controller中存在User Defined Variables,并且定义了一些变量,那么录制的请求中的任何符合次变量值的内容都会被变量代替.如,定义server为www.google.cn,那么所有请求中的google地址都会替换为${server}.

    通过加入 View Results Tree可以看到实际的请求和对应的相应.加入Save Responses to a file可以将相应存到文件中.

接下来我们分析一些具体的情况，在这些情况下I/O会成为系统的瓶颈。我们会用到工具top，vmstat，iostat，sar等。每一个工具的输出都从不同的方面反映除系统的性能情况。

情况1：同一时间进行大量的I/O操作

   在这种情况时我们会发现CPU的wa时间百分比会上升，证明系统的idle时间大部分都是在等待I/O操作。

# vmstat 1

procs -----memory----- ---swap---io---- --system--cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa

3 2 0 55452 9236 1739020 0 0 9352 0 2580 8771 20 24 0 57

2 3 0 53888 9232 1740836 0 0 14860 0 2642 8954 23 25 0 52

2 2 0 51856 9212 1742928 0 0 12688 0 2636 8487 23 25 0 52

    从这个输出我们可以看到CPU有50%的时间都在等待I/O操作，我们还可以看到系统的bi值很大，证明系统有大量的I/O请求将磁盘内容读入内存。

没有很好的工具能看到到底是哪个进程在进行I/O读写。但我们可以通过top命令的输出来猜测

# top -d 1

top - 19:45:07 up 1:40, 3 users, load average: 6.36, 5.87, 4.40

Tasks: 119 total, 3 running, 116 sleeping, 0 stopped, 0 zombie

Cpu(s): 5.9% us, 87.1% sy, 0.0% ni, 0.0% id, 5.9% wa, 1.0% hi, 0.0% si

Mem: 2075672k total, 2022668k used, 53004k free, 7156k buffers

Swap: 2031608k total, 132k used, 2031476k free, 1709372k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND

3069 root 5 -10 450m 303m 280m S 61.5 15.0 10:56.68 4562 vmware-vmx

3016 root 5 -10 447m 300m 280m S 21.8 14.8 12:22.83 3978 vmware-vmx

3494 root 5 -10 402m 255m 251m S 3.0 12.6 1:08.65 3829 vmware-vmx

3624 root 5 -10 401m 256m 251m S 1.0 12.6 0:29.92 3747 vmware-vmx

    将top的输出通过faults进行排序。我们可以看到vmware产生最多的page faults。也就是说它进行了大量的IO操作。

情况2：管道太小

任何I/O操作都需要一定的时间，而且这些时间对于硬盘来说是确定的，它包含磁盘旋转的延时RD（rotation delay）和磁头搜索时间DS（disk seek）。RD由磁盘转速（RPM）决定。RD是磁盘旋转一周所需时间的一半。如RPM为10000.

RPS=RPM/60=166

1/166=0.0006=6ms 磁盘旋转一周要6毫秒

RD=6ms/2=3ms

磁盘平均搜索时间是3ms，数据传输的平均延时是2ms，这样一次I/O操作的平均时间是：

3ms+3ms+2ms=8ms

IOPS=1000/8=125  这块磁盘的每秒IO数（IOPS）为125。所以对于10000RPM的磁盘来说它所能承受的IO操作在IOPS在120～150之间。如果系统的I/O请求超过这个值，就会使磁盘成为系统的瓶颈。

对与系统而言有两种不同种类的I/O压力，连续I/O和随机I/O。

连续I/O常常出现在企业级数据库这样的应用中，需要连续的读取大量数据。这种系统的性能依靠它读取和移动数据的大小和快慢。我们用iostat来监控，会发现rKB/s,wKB/s会很高。

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

/dev/sda 0.00 12891.43 0.00 105.71 0.00 106080.00 0.00 53040.00 1003.46 1099.43 3442.43 26.49 280.00

从输出我们看到w/s=105,wKB/s=53040.所以53040/105=505KB per I/O.

对于随机I/O的系统来说性能的关注点不在搜传输数据的大小和速度，而是在磁盘的IOPS。这类系统的I/O请求比较小但是数量很大，如Web服务器和Mail服务器。他们的性能主要依赖每秒钟可处理的请求数：

# iostat -x 1

avg-cpu: %user %nice %sys %idle

2.04 0.00 97.96 0.00

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

/dev/sda 0.00 633.67 3.06 102.31 24.49 5281.63 12.24 2640.82 288.89 73.67 113.89 27.22 50.00

从输出我们看到w/s=102,wKB/s=2640.所以2640/102=23KB per I/O.

因此对于连续I/O系统来说我们要关注系统读取大量数据的能力即KB per request.对于随机I/O系统我们注重IOPS值.

  JMeter是一款开源免费的性能测试工具,可以支持多种协议如http,https,ftp,LDAP,JDBC,JUnit等.大家可以去http://jakarta.apache.org/jmeter查找有关信息.

   安装JMeter首先要安装JRE(Java runtime environment)1.4以上版本,为了支持其他协议的测试我们可以下载相应的jar包把它放在Jmeter的classpath下:

• JMETER_HOME/lib - used for utility jars
• JMETER_HOME/lib/ext - used for JMeter components and add-ons

例如我们要支持Mail的功能就要下载JavaMail.

在JMeter中,Test Plan由thread group组成, Thread Group代表了一组虚拟的用户.在Thread Group中定义用户的行为,我们可以加入其他任何元素,Samplers,Controllers,Listener,Timers,Assertions,Configure elements,Pre-Processors,Post-Processors.

Samplers用来产生各种请求如,Http sampler,ftp sampler. Controller和Logic Controller用来控制测试的顺序和逻辑.Listener用来显示测试结果.Timers用来产生延时.Assertion用来测试结果是否符合预期.Pre-Processor执行需要在sampler产生request之前进行的操作.Post-Processors执行需要在sampler产生request之后进行的操作. Timer比较特殊,当一个Thread Group中出现多个Timer的时候,JMeter会将所有的时间相加来做为sampler发送request之前的延时时间.

Samplers和Controllers是按顺序执行的,如下图

执行顺序是One, Two,Three,Four

其它元素的作用区域就是它本身所在的区域和它的子区域.例如一个Assertion应用于某一个请求,它就只对该请求生效,如果应用于Controller就会影响controller下的所有请求.

Assertion#1应用于One, Assertion应用鱼Two和Three

所有这些元素的执行顺序如下:

1. Pre-Processors

2. Timers

3. Sampler

4. Post-Processors (unless SampleResult is null)

5. Assertions (unless SampleResult is null)

6. Listeners (unless SampleResult is null)

例如一个test plan如下

• Controller
  • Post-Processor 1
  • Sampler 1
  • Sampler 2
  • Timer 1
  • Assertion 1
  • Pre-Processor 1
  • Timer 2
  • Post-Processor 2

执行顺序是:

Pre-Processor 1
Timer 1
Timer 2
Sampler 1
Post-Processor 1
Post-Processor 2
Assertion 1

Pre-Processor 1
Timer 1
Timer 2
Sampler 2
Post-Processor 1
Post-Processor 2
Assertion 1

    在进行网络测试的时候,我们经常需要进行抓包的工作,当然有许多测试工具可以使用,比如sniffer, ethreal等.但最为方便和简单得就非TCPDump莫属. Linux的发行版里基本都包括了这个工具. TCPDump将网络接口设置成混杂模式以便捕获到达的每一个数据包.下面给出TCPDump的部分常用选项:

-i <interface> 指定监听的网络接口

-v 指定详细模式输出详细的报文信息

-vv 指定更详细模式输出更详细的报文信息

-x 指定以16进制数格式显示数据包

-X 规定以ASCII码格式显示输出

-n 规定在捕获过程中不需向DNS查询IP地址

-F <file> 从指定文件中读取表达式

-D 显示可用网络接口

-s <length> 设置捕获数据包的长度

TCPDump的表达式:

默认情况下TCPDump将捕获所有到达网络的数据包.这并不是我们想要的,因此就必须通过表达式来限制不必要的流量,只输出我们需要监听的数据包.

1. 类型限定词

类型限定词有: host, port和net. host用来指定主机或目的地址,port指定端口,net可以用来指定某一子网. 如:

tcpdump 'port 80' 监听80端口

tcpdump 'net 192.168.1' 监听子网192.168.1.0

tcpdump 'net 192.168.1.0/24'

2. 逻辑运算符

逻辑运算符有AND,OR和NOT. ()可将多个表达式组合起来.

tcpdump 'port 80 and (host 192.168.1.10 or host 192.168.1.11)'

监听主机192.168.1.10 或 192.168.1.11的80端口.

3. 传输方向限定词

关键词src指定源地址,dst指定目的地址

tcpdump 'port 80 and (src 192.168.1.10 or src 192.168.1.11)'

tcpdump 'dst port 25'

4. 协议限定词

用来捕获特定协议的数据包有: ether(Ethernet), TCP,UDP,ICMP,IP,ip6(IPv6),ARP,rarp(reverse ARP)等.

5. 原语

原语主要有: 算术运算符(+,-,*,/,>,<,>=,<=,!=等), broadcast, gateway, greater, less.

broadcast捕获广播数据包, greater和less相当于>=和<=.

iptables中nat表可以实现SNAT, DNAT, 双向NAT和两次NAT.

一. 源地址NAT

1. 标准的SNAT

SNAT的目的是进行源地址转换,应用于POSTROUTING规则链.在路由决定之后应用.SNAT与出站接口相关,而不是入站接口. 语法如下:

iptables -t nat -A POSTROUTING -o <outgoing interface> ... \

         -j SNAT --to-source <address>[-<address>][:port-port]

2. MASQUERADE源NAT

MASQUERADE没有选项来指定在NAT设备上使用的特定源地址,使用的源地址就是出站好接口的地址.

iptables -t nat -A POSTROUTING -o <outgoing interface> ... \

         -j MASQUERADE [--to-ports <port>[-port]]

二. 目的地址NAT

   目的地址NAT有2种形式: DNAT和REDIRECT. REDIRECT是目的地址转换的特殊形式,将数据包重定向到NAT设备的输入或回环接口. 目的地址NAT应用于nat表的PREROUTING和OUTPUT规则链,在做出路由决定前对目的地址进行修改.在PREROUTING中,DNAT和REDIRECT规则与用来接受通过本地路由转发或送到主机的入站接口的数据包的入站接口有关.在OUTPUT中,DNAT和REDIRECT规则用来处理来自NAT主机本身生成的出站数据包.

1. 标准目的地址NAT(DNAT)

iptables -t nat -A PREROUTING -i <incoming interface> ... \

         -j DNAT --to-destination <address>[-<address>][:port-port]

iptables -t nat -A OUTPUT -o <outgoing interface> ... \

         -j DNAT --to-destination <address>[-<address>][:port-port]

目的地址用来替换数据包中的原始目的地址,多位本地服务器地址.

2. REDIRECT

iptables -t nat -A PREROUTING -i <incoming interface> ... \

         -j REDIRECT [--to-ports <port>[-port]]

iptables -t nat -A OUTPUT -o <outgoing interface> ... \

         -j REDIRECT [--to-ports <port>[-port]]

REDIRECT重定向数据包到执行REDIRECT操作的那台主机.

最近学习了一下Linux的防火墙,也就是iptables.现在总结一下给大家分享希望有所帮助:

   早期的Linux系统采用的防火墙是IPFW，其管理程序是ipchains。而现今的发行版都已经采用了新的防火墙架构Netfilter，管理程序是iptables，所以也称作iptables防火墙。

   iptables防火墙是基于表，链和规则来实现的，它有三张表：filter、NAT和mangle。每张表里都有内建的一些规则链（用户也可自定义规则链），规则链顾名思义就是由多条规则组成，每个规则就是一条iptables命令。当数据包进入或输出或转发的时候就会经过相应的规则链，系统会按顺序来匹配这些规则，当匹配其中一条的时候就做这条规则所定义的动作，不再继续匹配后面的规则。如果没有匹配任何一个规则，就进行默认的操作，用户可以定义是接受还是禁止。当然，禁止是安全的选择。

   filter表是默认的表，主要进行数据包过滤功能。有内建的3个规则链INPUT，OUTPUT和FORWARD。INPUT是处理输入或即将进入防火墙的数据的规则链，OUTPUT是处理输出或即将离开防火墙的规则链，FORWARD是处理转发或通过防火墙被送出的数据的规则链。

   NAT表的功能主要就是实现网络地址转换（NAT）。它有3个内建的规则链：PREROUTING规则链在传递入站数据包到路由功能前修改其目的地址（DNAT），OUTPUT规则链指定了在作出路由决定之前对本地产生的出站数据包目的地址的修改，POSTROUTING规则链制定了对将要通过防火墙路由出去的出站数据包源地址的修改（SNAT）。iptables支持4个常见的NAT类型：SNAT、DNAT、MASQUERADE（伪装）和REDIRECT（本地端口重定向）。

   mangle表能够给数据包打上标记或者将一个由Netfilter维护的值与数据包联系起来。它有5个内建的规则链，PREROUTING规则链指定了当入站数据包到达网络接口但还没有作出任何路由或本地传递时对数据包所做的修改。INPUT规则链指定了进行数据包处理时对数据包所做的修改，在PREROUTING后使用。FORWARD规则链指定了对转发出防火墙的数据包所做的修改。OUPUT规则链指定了对本地出站数据包所做的修改。POSTROUTING规则链指定了数据包将要离开防火墙时对数据包所做的修改，在OUTPUT后使用。

   具体一个数据包的过滤流程如下图所示:

Hi,

 大家好, 本人是一名南京的软件测试工程师. 希望找到也在南京工作的一些同行,大家可以空闲时间出来小聚,交流经验, 吃喝打牌:). 有意愿的朋友可以留言.

UI Testing Guideline

IO系统是整个系统中最慢的部分，因为它需要真正的物理操作磁盘的转动和检索。比起内存来要差几个数量级。Linux内核将硬盘IO分页，每一页的大小默认为4K。这时，内存和磁盘的读写以页为单位进行，这些页叫做内存页。用time命令可以检查页的大小：

# /usr/bin/time -v date

<snip>

Page size (bytes): 4096

<snip>

主要页错误（Major Page Faults）和次要页错误（Minor Page Faults）：

MPF（Major Page Faults）表示进程需要的数据并不在内存中，需要从磁盘读取。

一旦内存页读入到内存的缓冲区中，程序就在内存中读取或写入数据，叫做MnPF（Minor Page Faults）。MnPF通过重复使用内存页而缩短了内核时间。Time命令可以显示一个进程中MPF和MnPF的数量，在evolution程序第一次启动的时候会有很多MPF：

# /usr/bin/time -v evolution

<snip>

Major (requiring I/O) page faults: 163

Minor (reclaiming a frame) page faults: 5918

<snip>

如果再次启动evolution程序，我们就看到MPF消失了，因为此时进程需要的数据已经全部在内存中了：

# /usr/bin/time -v evolution

<snip>

Major (requiring I/O) page faults: 0

Minor (reclaiming a frame) page faults: 5581

<snip>

当进程不断的进行IO操作的时候，系统会将这些数据缓存到内存中。所以我们会看到系统的FreeMemory越来越少，而Cache越来越大。如下:

# cat /proc/meminfo

MemTotal: 2075672 kB

MemFree: 52528 kB

Buffers: 24596 kB

Cached: 1766844 kB

有些人为系统的可用内存太少而担心，而事实不是这样，这种情况恰恰证明系统正在高效的利用cache，进而减少MPF，增加MnPF。但从这个输出我们无法断定内存是否为系统瓶颈。

前面讲了内存页的定义，接下来我们说说内存页的分类：

1.    Read Pages-这些页通过MPF从磁盘读入，并且是只读的。这些页存在与cache中包括不能修改的静态文件，二进制文件，库文件。内核在需要的时候会将他们读入内存，当内存资源紧张时，内核会释一些放此类的内存页，当程序在此需要的时候，就只能通过MPF重新读入。

2.    Dirty Pages-这些页是内核在内存中修改过的页面。这些页面需要同步回磁盘上。Pdflush负责将他们写回磁盘。当内存不够时，kswapd就会触发pdflush将页面写回磁盘以释放内存。

3.    Anonymous Pages-这些页属于某个进程，但是没有任何磁盘文件与之相关。他们不能和磁盘同步。当内存不够时，kswapd会将他们写入swap分区。

应用程序可以用系统调用fsync()和sync()将Dirty Page立即写回磁盘。如果应用程序没有调用此类函数，pdflush进程会定期与磁盘进行同步。

我们来看内存监控的一个例子，用vmstat命令的输出如下：

# vmstat 3
procs          memory            swap     io        system      cpu
r b  swpd   free   buff cache   si so    bi   bo    in   cs   us sy id wa
3 2 809192 261556 79760 886880 416 0    8244  751   426  863  17 3   6 75
0 3 809188 194916 79820 952900 307 0    21745 1005  1189 2590 34 6  12 48
0 3 809188 162212 79840 988920 95  0    12107 0     1801 2633 2  2   3 94
1 3 809268 88756 79924 1061424 260 28   18377 113   1142 1694 3  5   3 88
1 2 826284 17608 71240 1144180 100 6140 25839 16380 1528 1179 19 9  12 61
2 1 854780 17688 34140 1208980 1   9535 25557 30967 1764 2238 43 13 16 28
0 8 867528 17588 32332 1226392 31  4384 16524 27808 1490 1634 41 10  7 43
4 2 877372 17596 32372 1227532 213 3281 10912 3337  678  932  33 7   3 57
1 2 885980 17800 32408 1239160 204 2892 12347 12681 1033 982  40 12  2 46
5 2 900472 17980 32440 1253884 24  4851 17521 4856  934  1730 48 12 13 26
1 1 904404 17620 32492 1258928 15  1316 7647  15804 919  978  49 9  17 25
4 1 911192 17944 32540 1266724 37  2263 12907 3547  834  1421 47 14 20 20
1 1 919292 17876 31824 1275832 1   2745 16327 2747  617  1421 52 11 23 14
5 0 925216 17812 25008 1289320 12  1975 12760 3181  772  1254 50 10 21 19
0 5 932860 17736 21760 1300280 8   2556 15469 3873  825  1258 49 13 24 15

其中:swpd为虚拟内存的使用大小单位为KB.

     Free为空闲的物理内存的大小(KB);

     Buff为内存中缓存的大小,这些缓存是read()和write()函数使用的(KB);

     Cache进程的地址空间在物理内存中的映射(KB);

     So为从内存写入swap空间的数据大小(KB);

     Si为从swap空间写入内存的数据大小(KB);

     Bo为从内存写入硬盘或swap的页数量;

     Bi为从硬盘或swap写入内存的页数量;

从上面的输出我们可以看到:

1. 大量的disk pages(bi)被写入内存,这点可以从cache的不断增长来证明;

2. 在这个过程中,物理内存始终保持在17MB虽然不断有数据从硬盘读入来消耗内存;

3. 为了保持可用物理内存,kswapd不断的从Buff中偷取内存,来加入空闲列表,buff不断减小;

4. 同时kswapd不断的将垃圾页写入swap空间,我们可以看到so和swpd不断增加.

现在我们可以得出结论,这是一个IO Bound的程序,并且造成了虚拟内存的大量使用,加大物理内存可以改善性能.

总结下来:

1. 当一个系统有越少的页错误(所需数据不在内存,需要从硬盘读入),就会有越好的响应时间.因为内存比硬盘快得多.

2. Free memory数量低是一个好的征兆,因为证明了cache在起作用,除非同时存在大量的bi和so.

3. 如果一个系统有持续的si和so,就说明系统的内存是一个瓶颈.

首先说说虚拟内存和物理内存：

虚拟内存就是采用硬盘来对物理内存进行扩展，将暂时不用的内存页写到硬盘上而腾出更多的物理内存让有需要的进程来用。当这些内存页需要用的时候在从硬盘读回内存。这一切对于用户来说是透明的。通常在Linux系统说，虚拟内存就是swap分区。在X86系统上虚拟内存被分为大小为4K的页。

每一个进程启动时都会向系统申请虚拟内存（VSZ），内核同意或者拒就请求。当程序真正用到内存时，系统就它映射到物理内存。RSS表示程序所占的物理内存的大小。用ps命令我们可以看到进程占用的VSZ和RSS。

# ps –aux

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

daemon 2177 0.0 0.2 3352 648 ? Ss 23:03 0:00 /usr/sbin/atd

dbus 2196 0.0 0.5 13180 1320 ? Ssl 23:03 0:00 dbus-daemon-1 --sys

root 2210 0.0 0.4 2740 1044 ? Ss 23:03 0:00 cups-config-daemon

root 2221 0.3 1.5 6108 4036 ? Ss 23:03 0:02 hald

root 2231 0.0 0.1 2464 408 tty1 Ss+ 23:03 0:00 /sbin/mingetty tty1

    内核会定期将内存中的数据同步到硬盘，这个过程叫做Memory Paging。同时内核也要负责回收不用的内存，将他们分给其他需要的进程。PFRA算法（Page Frame reclaim algorithm）负责回收空闲的内存。算法根据内存页的类型来决定要释放的内存页。有下列4种类型：

1．  Unreclaimable – 锁定的，内核保留的页面；

2．  Swappable – 匿名的内存页；

3．  Syncable – 通过硬盘文件备份的内存页；

4．  Discardable – 静态页和被丢弃的页。

除了第一种（Unreclaimable）之外其余的都可以被PFRA进行回收。与之相关的进程是kswapd。在kswapd中，有2个阀值，pages_hige和pages_low。当空闲内存页的数量低于pages_low的时候，kswapd进程就会扫描内存并且每次释放出32个free pages，直到free page的数量到达pages_high。具体kswapd是如何回收内存的呢？有如下原则：

1.    如果页未经更改就将该页放入空闲队列；

2.    如果页已经更改并且是可备份回文件系统的，就理解将内存页的内容写回磁盘；

3.    如果页已经更改但是没有任何磁盘上的备份，就将其写入swap分区。

# ps -ef | grep kswapd

root 30 1 0 23:01 ? 00:00:00 [kswapd0]

在回收内存过程中还有两个重要的方法，一是LMR（Low on memory reclaiming），另一个是OMK(Out of Memory Killer)。当分配内存失败的时候LMR将会其作用，失败的原因是kswapd不能提供足够的空闲内存，这个时候LMR会每次释放1024个垃圾页知道内存分配成功。当LMR不能快速释放内存的时候，OMK就开始其作用，OMK会采用一个选择算法来决定杀死某些进程。当选定进程时，就会发送信号SIGKILL，这就会使内存立即被释放。OMK选择进程的方法如下：

1.    进程占用大量的内存；

2.    进程只会损失少量工作；

3.    进程具有低的静态优先级；

4.    进程不属于root用户。

进程管理中另一个程序pdflush用于将内存中的内容和文件系统进行同步，比如说，当一个文件在内存中进行修改，pdflush负责将它写回硬盘。

# ps -ef | grep pdflush

root 28 3 0 23:01 ? 00:00:00 [pdflush]

root 29 3 0 23:01 ? 00:00:00 [pdflush]

每当内存中的垃圾页（dirty page）超过10%的时候，pdflush就会将这些页面备份回硬盘。这个比率是可以调节的，通过参数vm.dirty_background_ratio。

# sysctl -n vm.dirty_background_ratio

10

Pdflush同PFRA是独立运行的，当内核调用LMR时，LMR就触发pdflush将垃圾页写回硬盘。

正如我们之前讨论的任何系统的性能比较都是基于基线的，并且监控CPU的性能就是以上3点，运行队列、CPU使用率和上下文切换。以下是一些对于CPU很普遍的性能要求：

1.       对于每一个CPU来说运行队列不要超过3，例如，如果是双核CPU就不要超过6；

2.       如果CPU在满负荷运行，应该符合下列分布，

a)         User Time：65%～70%

b)        System Time：30%～35%

c)        Idle：0%～5%

3.       对于上下文切换要结合CPU使用率来看，如果CPU使用满足上述分布，大量的上下文切换也是可以接受的。

常用的监视工具有，vmstat, top,dstat和mpstat.

# vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa

0 0 104300 16800 95328 72200 0 0 5 26 7 14 4 1 95 0

0 0 104300 16800 95328 72200 0 0 0 24 1021 64 1 1 98 0

0 0 104300 16800 95328 72200 0 0 0 0 1009 59 1 1 98 0

r表示运行队列的大小，

b表示由于IO等待而block的线程数量，

in表示中断的数量，

cs表示上下文切换的数量，

us表示用户CPU时间，

sys表示系统CPU时间，

wa表示由于IO等待而是CPU处于idle状态的时间，

id表示CPU处于idle状态的总时间。

dstat可以给出每一个设备产生的中断数：

# dstat -cip 1
----total-cpu-usage---- ----interrupts--- ---procs---
usr sys idl wai hiq siq| 15 169 185 |run blk new
6 1 91 2 0 0| 12 0 13 | 0 0 0
1 0 99 0 0 0| 0 0 6 | 0 0 0
0 0 100 0 0 0| 18 0 2 | 0 0 0
0 0 100 0 0 0| 0 0 3 | 0 0 0

我们可以看到这里有3个设备号15，169和185.设备名和设备号的关系我们可以参考文件/proc/interrupts, 这里185代表网卡eth1.

# cat /proc/interrupts

CPU0

0: 1277238713 IO-APIC-edge timer

6: 5 IO-APIC-edge floppy

7: 0 IO-APIC-edge parport0

8: 1 IO-APIC-edge rtc

9: 1 IO-APIC-level acpi

14: 6011913 IO-APIC-edge ide0

15: 15761438 IO-APIC-edge ide1

169: 26 IO-APIC-level Intel 82801BA-ICH2

185: 16785489 IO-APIC-level eth1

193: 0 IO-APIC-level uhci_hcd:usb1

mpstat可以显示每个CPU的运行状况，比如系统有4个CPU。我们可以看到：

# mpstat –P ALL 1

Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006

05:17:31 PM CPU %user %nice %system %idle intr/s

05:17:32 PM all 0.00 0.00 3.19 96.53 13.27

05:17:32 PM 0 0.00 0.00 0.00 100.00 0.00

05:17:32 PM 1 1.12 0.00 12.73 86.15 13.27

05:17:32 PM 2 0.00 0.00 0.00 100.00 0.00

05:17:32 PM 3 0.00 0.00 0.00 100.00 0.00

总结的说，CPU性能监控包含以下方面：

检查系统的运行队列，确保每一个CPU的运行队列不大于3.

确保CPU使用分布满足70/30原则（用户70%，系统30%）。

如果系统时间过长，可能是因为频繁的调度和改变优先级。

在这篇文章中,主要介绍CPU的一些基础知识.

首先介绍一下Linux kernel中的调度器(scheduler),调度器负责调度系统中的两种资源，一是线程，二是中断。调度器给不同资源不同的优先级。从高到低为：

1. 硬件中断（Hardware Interrupts）--这些请求由硬件触发，比如磁盘已经完成了读写任务或是网卡受到了新的数据包。

2. 软件中断（Software Interrupts)--这里指的是维护内核运行的内核态软件中断。比如内核的时钟管理进程。

3. 实时进程（Real time threads)--实时进程比内核本身具备更高的优先级，它可以抢占内核的CPU时间片，在2.4内核是一个不可抢占的内核，它中不支持实时程序。

4. 内核进程（Kernel threads）--包括所以的内核程序。

5. 用户进程（User threads）-- 所有运行在用户态的进程。

关于CPU，有3个重要的概念：上下文切换（context switchs），运行队列（Run queue）和使用率（utilization）。

上下文切换：

      目前流行的CPU在同一时间内只能运行一个线程，超线程的处理器可以在同一时间运行多个线程（包括多核CPU），Linux内核会把多核的处理器当作多个单独的CPU来识别。

       一个标准的Linux内核何以支持运行50～50000个进程运行，对于普通的CPU，内核会调度和执行这些进程。每个进程都会分到CPU的时间片来运行，当一个进程用完时间片或者被更高优先级的进程抢占后，它会备份到CPU的运行队列中，同时其他进程在CPU上运行。这个进程切换的过程被称作上下文切换。过多的上下文切换会造成系统很大的开销。

运行队列：

       每个CPU都会维持一个运行队列，理想情况下，调度器会不断让队列中的进程运行。进程不是处在sleep状态就是run able状态。 如果CPU过载，就会出现调度器跟不上系统的要求，导致可运行的进程会填满队列。队列愈大，程序执行时间就愈长。“load”用来表示运行队列，用top命令我们可以看到CPU一分钟，5分钟和15分钟内的运行队列的大小。这个值越大表明系统负荷越大。

CPU使用率：

       CPU使用率可分为一下几个部分

       User Time—执行用户进程的时间百分比；

       System Time—执行内核进程和中断的时间百分比；

       Wait IO—因为IO等待而使CPU处于idle状态的时间百分比；

       Idle—CPU处于Idle状态的时间百分比。

关于时间片和动态优先级：

时间片对于CPU来说是很关键的参数，如果时间片太长，就会使系统的交互性能变差，用户感觉不到并行。如果太短，又会造成系统频繁的上下文切换，使性能下降。对于IO Bound的系统来讲并不需要太长的时间片，因为系统主要是IO操作；而对于CPU Bound的系统来说需要长的时间片以保持cache的有效性。

每一个进程启动的时候系统都会给出一个默认的优先级，但在运行过程中，系统会根据进程的运行状况不断调整优先级，内核会升高或降低进程的优先级（每次增加或降低5），判断标准是根据进程处于sleep状态的时间。IO Bound进程大部分时间在sleep状态，所以内核会调高它的优先级，CPU Bound进程会被内核惩罚降低优先级。因此，如果一个系统上即运行IO Bound进程，又运行CPU Bound进程，我们会发现，IO Bound进程的性能不会下降，而CPU Bound进程性能会不断下降。

我们运行一个CPU Bound的程序：cpu-hog。用ps命令可以看出它的优先级在不断下降。

term1# ./cpu-hog

term2# while :; do ps -eo pid,ni,pri,pcpu,comm | egrep

'hog|PRI'; sleep 1; done

PID NI PRI %CPU COMMAND

22855 0 20 84.5 cpu-hog

PID NI PRI %CPU COMMAND

22855 0 18 89.6 cpu-hog

PID NI PRI %CPU COMMAND

22855 0 15 92.2 cpu-hog

PID NI PRI %CPU COMMAND

22855 0 15 93.8 cpu-hog

    我们运行find命令，是一个IO Bound的程序，可以观察到它的优先级不断提高。

term1# find /

term2# while :; do ps -eo pid,ni,pri,pcpu,comm | egrep

'find|PRI'; sleep 1; done

PID NI PRI %CPU COMMAND

23101 0 20 0.0 find

PID NI PRI %CPU COMMAND

23101 0 21 4.0 find

PID NI PRI %CPU COMMAND

23101 0 23 3.5 find

PID NI PRI %CPU COMMAND

23101 0 23 4.3 find

PID NI PRI %CPU COMMAND

23101 0 23 4.2 find

PID NI PRI %CPU COMMAND

23101 0 23 4.4 find

       如果同时运行2个程序就可看出明显的变化

# while :; do ps -eo pid,ni,pri,pcpu,comm | egrep 'find|hog';

sleep 1; done

23675 0 20 70.9 cpu-hog

23676 0 20 5.6 find

23675 0 20 69.9 cpu-hog

23676 0 21 5.6 find

23675 0 20 70.6 cpu-hog

23676 0 23 5.8 find

23675 0 19 71.2 cpu-hog

23676 0 23 6.0 find

23675 0 19 71.8 cpu-hog

23676 0 23 6.1 find

23675 0 18 72.8 cpu-hog

23676 0 23 6.2 find

23675 0 16 73.2 cpu-hog

23676 0 23 6.6 find

23675 0 14 73.9 cpu-hog