早上看到我们的学员发的一个贴子（http://bbs.51testing.com/thread-63522-1-1.html），是关于自动化测试流程的一些问题。我也参与了讨论，感觉还不错，呵呵，就整理了一下搬到博客上来，和大家一起分享、交流。

==============================================

wssgily:

我想请教几个自动化测试流程.

请问大家,你们公司的自动化测试是什莫阶段开始介入的?
自动化测试的入口和出口准则是怎样定义的？
大家又是如何保证自动化测试的质量的？

--------------------------------------------------------

xiaonan:

3种常见的配置方法，前两种方法已在Redhat8、9上验证通过正常使用。
1.配置系统XDMCP（X Display Manager Control Protocol）服务
  在linux服务器上的主菜单，选择系统设置－登陆屏幕，在弹出的对话框中，选择XDMCP选项卡，选中“启动XDMCP”、“允许非直接请求”复选框，并在安全选项卡中选中“允许根用户通过GDM登录”、“允许根用户通过GDM远程登录”。
  如果服务器还启动了防火墙，则必须保证XDMCP服务默认的177端口能被正常访问。
  可通过此命令进行防火墙配置：iptables  -A  INPUT  -p udp -s 0/0 -d 0/0 --dport 177 -j ACCEPT
  配置完XDMCP服务后即可在Xmanager的Xbrowser中看到该机器名称，双击即可进入到系统图形化登录界面。
  
2.通过Xclients命令启动
  启动Xmanager中的Xstart，配置xterm连接方式，如：
    Host：172.16.16.4
    Protocol:SSH
    Username:xxx
    Password:xxx
    Execution Command(按默认方式):/usr/bin/X11/xterm -ls -display $DISPLAY
  点击Run，进入Xstart界面。
  在Xstart界面中启动图形终端命令：
  export DISPLAY=172.16.16.222:0.0 (配置终端输出到哪台机器上)
  cd /etc/X11/xinit
  ./Xclients
  即进入到系统图形化登录界面

3.同样是配置XDMCP服务
  用文件配置的方式配置XDMCP服务。由于过程比较复杂没有写上来，具体参考：http://www.ccw.com.cn/server/yyjq/htm2005/20050906_0994B.htm

源文来源：http://agiletesting.blogspot.com ... stress-testing.html
作者：Grig Gheorghiu
作者联系方式：http://agiletesting.blogspot.com/
译者：AlexanderIII
译文联系方式：

cnalexanderiii@gmail.com

http://blog.51testing.com/?61747

［译者注］欢迎转载，但转载请尊重一下作者及译者，请把作者，译者及联系方式也转上，谢谢！同时如果有建议或者认为有什么不妥之处，欢迎来信交流，大家一起提高测试水平。
本篇译文是本人第一次尝试着翻译比较长一点的测试文章，因此有一些地方可能还不是翻得太准确，在相应的地方我都打上了*号，请指正！

＊一切将本贴子用于商业的行为，请在得到允许之后再进行，谢谢合作．
［源文内容］
Monday, February 28, 2005
Performance vs. load vs. stress testing
Here's a good interview question for a tester: how do you define performance/load/stress testing? Many times people use these terms interchangeably, but they have in fact quite different meanings. This post is a quick review of these concepts, based on my own experience, but also using definitions from testing literature -- in particular: "Testing computer software" by Kaner et al, "Software testing techniques" by Loveland et al, and "Testing applications on the Web" by Nguyen et al.

Update July 7th, 2005

From the referrer logs I see that this post comes up fairly often in Google searches. I'm updating it with a link to a later post I wrote called 'More on performance vs. load testing'.

Performance testing

The goal of performance testing is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing. To conduct performance testing is to engage in a carefully controlled process of measurement and analysis. Ideally, the software under test is already stable enough so that this process can proceed smoothly.

A clearly defined set of expectations is essential for meaningful performance testing. If you don't know where you want to go in terms of the performance of the system, then it matters little which direction you take (remember Alice and the Cheshire Cat?). For example, for a Web application, you need to know at least two things:
•        expected load in terms of concurrent users or HTTP connections
•        acceptable response time
Once you know where you want to be, you can start on your way there by constantly increasing the load on the system while looking for bottlenecks. To take again the example of a Web application, these bottlenecks can exist at multiple levels, and to pinpoint them you can use a variety of tools:
•        at the application level, developers can use profilers to spot inefficiencies in their code (for example poor search algorithms)
•        at the database level, developers and DBAs can use database-specific profilers and query optimizers
•        at the operating system level, system engineers can use utilities such as top, vmstat, iostat (on Unix-type systems) and PerfMon (on Windows) to monitor hardware resources such as CPU, memory, swap, disk I/O; specialized kernel monitoring software can also be used
•        at the network level, network engineers can use packet sniffers such as tcpdump, network protocol analyzers such as ethereal, and various utilities such as netstat, MRTG, ntop, mii-tool
From a testing point of view, the activities described above all take a white-box approach, where the system is inspected and monitored "from the inside out" and from a variety of angles. Measurements are taken and analyzed, and as a result, tuning is done.

However, testers also take a black-box approach in running the load tests against the system under test. For a Web application, testers will use tools that simulate concurrent users/HTTP connections and measure response times. Some lightweight open source tools I've used in the past for this purpose are ab, siege, httperf. A more heavyweight tool I haven't used yet is OpenSTA. I also haven't used The Grinder yet, but it is high on my TODO list.

When the results of the load test indicate that performance of the system does not meet its expected goals, it is time for tuning, starting with the application and the database. You want to make sure your code runs as efficiently as possible and your database is optimized on a given OS/hardware configurations. TDD practitioners will find very useful in this context a framework such as Mike Clark's jUnitPerf, which enhances existing unit test code with load test and timed test functionality. Once a particular function or method has been profiled and tuned, developers can then wrap its unit tests in jUnitPerf and ensure that it meets performance requirements of load and timing. Mike Clark calls this "continuous performance testing". I should also mention that I've done an initial port of jUnitPerf to Python -- I called it pyUnitPerf.

If, after tuning the application and the database, the system still doesn't meet its expected goals in terms of performance, a wide array of tuning procedures is available at the all the levels discussed before. Here are some examples of things you can do to enhance the performance of a Web application outside of the application code per se:
•        Use Web cache mechanisms, such as the one provided by Squid
•        Publish highly-requested Web pages statically, so that they don't hit the database
•        Scale the Web server farm horizontally via load balancing
•        Scale the database servers horizontally and split them into read/write servers and read-only servers, then load balance the read-only servers
•        Scale the Web and database servers vertically, by adding more hardware resources (CPU, RAM, disks)
•        Increase the available network bandwidth
Performance tuning can sometimes be more art than science, due to the sheer complexity of the systems involved in a modern Web application. Care must be taken to modify one variable at a time and redo the measurements, otherwise multiple changes can have subtle interactions that are hard to qualify and repeat.

In a standard test environment such as a test lab, it will not always be possible to replicate the production server configuration. In such cases, a staging environment is used which is a subset of the production environment. The expected performance of the system needs to be scaled down accordingly.

The cycle "run load test->measure performance->tune system" is repeated until the system under test achieves the expected levels of performance. At this point, testers have a baseline for how the system behaves under normal conditions. This baseline can then be used in regression tests to gauge how well a new version of the software performs.

Another common goal of performance testing is to establish benchmark numbers for the system under test. There are many industry-standard benchmarks such as the ones published by TPC, and many hardware/software vendors will fine-tune their systems in such ways as to obtain a high ranking in the TCP top-tens. It is common knowledge that one needs to be wary of any performance claims that do not include a detailed specification of all the hardware and software configurations that were used in that particular test.

Load testing

We have already seen load testing as part of the process of performance testing and tuning. In that context, it meant constantly increasing the load on the system via automated tools. For a Web application, the load is defined in terms of concurrent users or HTTP connections.

In the testing literature, the term "load testing" is usually defined as the process of exercising the system under test by feeding it the largest tasks it can operate with. Load testing is sometimes called volume testing, or longevity/endurance testing.

Examples of volume testing:
•        testing a word processor by editing a very large document
•        testing a printer by sending it a very large job
•        testing a mail server with thousands of users mailboxes
•        a specific case of volume testing is zero-volume testing, where the system is fed empty tasks
Examples of longevity/endurance testing:
•        testing a client-server application by running the client in a loop against the server over an extended period of time
Goals of load testing:
•        expose bugs that do not surface in cursory testing, such as memory management bugs, memory leaks, buffer overflows, etc.
•        ensure that the application meets the performance baseline established during performance testing. This is done by running regression tests against the application at a specified maximum load.
Although performance testing and load testing can seem similar, their goals are different. On one hand, performance testing uses load testing techniques and tools for measurement and benchmarking purposes and uses various load levels. On the other hand, load testing operates at a predefined load level, usually the highest load that the system can accept while still functioning properly. Note that load testing does not aim to break the system by overwhelming it, but instead tries to keep the system constantly humming like a well-oiled machine.

In the context of load testing, I want to emphasize the extreme importance of having large datasets available for testing. In my experience, many important bugs simply do not surface unless you deal with very large entities such thousands of users in repositories such as LDAP/NIS/Active Directory, thousands of mail server mailboxes, multi-gigabyte tables in databases, deep file/directory hierarchies on file systems, etc. Testers obviously need automated tools to generate these large data sets, but fortunately any good scrīpting language worth its salt will do the job.

Stress testing

Stress testing tries to break the system under test by overwhelming its resources or by taking resources away from it (in which case it is sometimes called negative testing). The main purpose behind this madness is to make sure that the system fails and recovers gracefully -- this quality is known as recoverability.

Where performance testing demands a controlled environment and repeatable measurements, stress testing joyfully induces chaos and unpredictability. To take again the example of a Web application, here are some ways in which stress can be applied to the system:
•        double the baseline number for concurrent users/HTTP connections
•        randomly shut down and restart ports on the network switches/routers that connect the servers (via SNMP commands for example)
•        take the database offline, then restart it
•        rebuild a RAID array while the system is running
•        run processes that consume resources (CPU, memory, disk, network) on the Web and database servers
I'm sure devious testers can enhance this list with their favorite ways of breaking systems. However, stress testing does not break the system purely for the pleasure of breaking it, but instead it allows testers to observe how the system reacts to failure. Does it save its state or does it crash suddenly? Does it just hang and freeze or does it fail gracefully? On restart, is it able to recover from the last good state? Does it print out meaningful error messages to the user, or does it merely display incomprehensible hex codes? Is the security of the system compromised because of unexpected failures? And the list goes on.

Conclusion

I am aware that I only scratched the surface in terms of issues, tools and techniques that deserve to be mentioned in the context of performance, load and stress testing. I personally find the topic of performance testing and tuning particularly rich and interesting, and I intend to post more articles on this subject in the future.
posted by Grig Gheorghiu at 7:33 AM  

［译文内容］
在面试测试人员的时候，这是一个很好的问题：你如何定义性能/负载/压力测试？在很多时候，人们都是将它们作为可互相替换的相同术语来使用，然而实际上他们之间的差异是比较大的。这个贴子是根据我自己的一些经验，针对这三个概念写的一个比较简单的评论，当然也同时参考了一些测试文献资料里的定义，比如说：
"Testing computer software" by Kaner et al
"Software testing techniques" by Loveland et al
"Testing applications on the Web" by Nguyen et al


Update July 7th, 2005
'.
从网站的访问日志中我可以看到这篇贴子经常会被人们在GOOGLE中搜索到，所以我在这里加上一个我写的一个后续贴子的地址连接'More on performance vs. load testing'.

性能测试

性能测试的目的不是去找bugs,而是排除系统的瓶颈，以及为以后的回归测试建立一个基准。而性能测试的操作，实际上就是一个非常小心受控的测量分析过程。在理想的情况下，被测软件在这个时候已经是足够稳定了，所以这个过程得以顺利的进行。

一组清晰已定义好的预期值是让一次有意义的性能测试的基本要素。如果连你自己都不知道系统性能有些什么是要测的，那么它对于你要测试的方法手段是没有指导意义的*。例如，给一个web应用做性能测试，你要知道至少两样东西：
        在不同并发用户数或者HTTP连接数情况下的负载预期值*
        可接受的响应时间

当你知道你的目标后，你就可以开始使用对系统持续增加负载的方法来观察系统的瓶颈所在。重新拿web应用系统来做例子，这些瓶颈可存在于多个层次，你可以使用多种工具来查明它们的所在：
        在应用层，开发人员可以通过profilers来发现低效率的代码，比如说较差的查找算法
        在数据库层，开发人员和数据库管理员（DBA）可以通过特定的数据库profilers及事件探查器*（query optimizers）
        在操作系统层，系统工程师可以使用一些工具如在Unix类的操作系统中的top,vmstat,iostat,在Windows系统中的PerfMon来监控CPU，内在，swap,磁盘I/O等硬件资源；专门的内核监控软件也可以在这一层面上被使用。
        在网络层上，网络工程师可以使用报文探测器（如tcpdump）,网络协议分析器（如ethereal）,还有其它的工具（如netstat,MRTG,ntop,mii-tool）

从测试的观点来看，上面所有描述的活动都是一种白盒的方法，它对系统从内到外及多角度进行审查及监控。测度数据*被取得及分析后，对系统的调整则成为理所当然的下一个步骤。

然而，（除了上面的方法外）测试人员在给被测系统运行负载试验*（这里为了不与我们所理解的负载测试-load testing的概念搞混，特译做负载试验）的时候，也采取了黑盒的方法。像对于WEB应用来讲，测试人员可以使用工具来模拟并发用户或者HTTP连接及测量响应时间。在我以前使用过的轻量级的负载测试开源工具有ab,siege,httperf。一个更重量级的工具是OpenSTA，但我没用过。我也还没有用过The Grinder这个工具，但它在我将要做的事情中排名靠前。

当负载试验*的结果显示出系统的性能来没有达到它的预期目标时，这就是要对应用和数据库的调整的时候了。同时你要确保让你的代码运行得尽可能高效，以及数据库在给定的操作系统和硬件配置的情况下最优化。测试驱动开发（TDD）的实践者会发现这种上下文结构框架是非常有用的*，如可以通过负载试验*及时间试验的函数性*来增强现存单元测试代码的Mike Clark的jUnitPerf*。当一个特定的函数或者方法被剖析过*和调试过后，开发人员就可以在jUnitPerf中，放入它的单元试验*来确保它可以达到负载及时间上的性能需求。Mike Clark称这为“持续性能测试”。我顺便也提一下我已经做了一个基于Python的jUnitPerf的初步研究，我称之为pyUnitPerf.

假若在调试过应用程序及数据库后，系统还是没有达到性能的预期目标，在这种情况下，还是有一些其它的调试的流程*可以针对前面讲过的那几个层次来使用的。下面就是一些在应用程序代码*之外仍可以提高WEB应用系统性能的例子：
        使用WEB缓存装制，如Squid提供的装置
        将高访问量的网页静态化，以避免这些高访问量对数据库进行大量的调用
        通过负载平衡的方法来水平缩放WEB服务器的结构*
        在水平缩放数据库群及将它们分为读写服务器和只读服务器后，还要对只读服务器群负载平衡。*
        通过增加更多的硬件资源（CPU，内存，磁盘等）纵向的缩放WEB及数据库服务器群
        增加网络的带宽

由于现在的WEB应用系统都是十分复杂的系统，性能调试有时要具有一些艺术性才行。在每次修改一个变量及重新测度的时候一定要非常小心，否则的话，在变化中将会有很多难于确定和重复的不确定因素*。

在一个规范的测试环境比如说一个测试实验试，它是不会常常的重现实际应用时的服务器配置环境。在这样的情况下，分段测试环境，也就是生产实际环境的一个子集就可以派上用场了。但同时系统的期望性能也需要相应的调低一点。

“运行负载试验*->测度性能->调试系统”这个循环一直要被重复执行到被测试系统达到了期望的性能标准了才可以停。在这个时候，测试人员就可以明了在正常条件下的系统运转怎么样，同时这些就可以做为以后在回归测试中，评价新版本的软件性能的一个标准了。

性能测试还有另一个目标就是建立一组被测系统的基准数据。在很多行业中都会有这种行业标准的基准数据，比如说TPC公布的。还有很多软硬件厂家都为了在TCP排名中靠前而对他们的机器进行精心调试。所以说你应当非常谨慎的说明在你进行测试的时候，并没有在种类繁多的软硬件产品中进行全部测试*。

负载测试
我们都已经在性能测试调试的过程中，见识过负载测试了。在那种环境中，它意味着通过自动化工具来持续对系统增加负载。但对于WEB应用来讲，负载则是并发用户或者HTTP连接的数量。
术语“负载测试”在测试文献资料中通常都被定义为给被测系统加上它所能操作的最大任务数的过程。负载测试有时也会被称为“容量测试”，或者“耐久性测试/持久性测试”*

容量测试的例子：
        通过编辑一个巨大的文件来测试文字处理软件
        通过发送一个巨大的作业来测试打印机
        通过成千上万的用户邮箱来测试邮件服务器
        有一种比较特别的容量测试是叫作“零容量测试”，它是给系统加上空任务来测试的。
耐久性测试/持久性测试的的例子：
        在一个循环中不停的运行客户端超过一个扩展时间段*。
负载测试的目的：
        找到一些在测试流程中前面的阶段所进行的粗略测试中没有被找出的bugs,例如，内存管理bugs,内存泄露，缓冲器溢出等等。
        保证应用程序达到性能测试中确定的性能基线。这个可以在运行回归试验时，通过加载特定的最大限度的负载来实现。

尽管性能测试和负载测试似乎很像，但他们的目的还是有差异的。一方面，性能测试使用负载测试的技术，工具，以及用不同的负载程度来测度和基准化系统。在另一方面来讲，负载测试是在一些已经定义好的负载程度上进行测试的，通常对系统加上最大负载之后，系统应该仍然可以提供全部功能。这里需要明确一点，负载测试并不是要对系统加载上过度的负载而使系统不能工作，而是要使系统像一个上满了油的机器嗡嗡叫*。

在负载测试的相关内容中，我想应该非常重要的是要有十分充足的数据来进行测试。从我的经验中得知，假若不用非常大的数据*去测的话，有很多严重的bug是不会的到的。比如说，LDAP/NIS/Active Directory数据库中成千上万的用户，邮件服务器中成千上万的邮箱，数据库中成G成G的表，文件系统中很深的文件或者目录的层次，等等。显然，测试人员就需要使用自动化工具来产生这些庞大的数据集，比较幸运的是任何优秀的脚本语言都可以胜任这些工作。

压力测试

压力测试是指通过对系统加载过度的资源或者例系统没有应该具有的令系统可以正常运作的资源，来使系统崩溃（在某些情况的时候，它又可以叫做负面测试）。进行这个疯狂行为的主要目的是为了保证系统出故障及可以适当的恢复，而这个恢复得怎么样的特性则是叫做可恢复性。

当性能测试需要的是一个可控制的环境和不断的测度的时候，压力测试则是令为欢喜的引起混乱及不可预测性（译者按：从这一点可以看出作者是一个很优秀的测试人员）。还是举WEB应用系统为例，下面是一些对系统可行的压力测试方法：
        两倍的已经基线的并发用户数或者HTTP连接数
        随机的关闭及重开连接到服务器上的网络上集线器/路由器的端口（例如，可以通过SNMP命令来实现）
        把数据库断线然后再重启
        当系统还在运行的时候，重建一个RAID阵列
        在WEB和数据库服务器上运行消耗资源（如CPU，内存，磁盘，网络）的进程

我可以肯定一些经常使用非常规方法来破坏系统的测试人员可以进一步充实这个列表的。只是压力测试并不是简单的为了一种破坏的快感而去破坏系统，实际上它是可以让测试工程师观察系统对出现故障时系统的反应。系统是不是保存了它出故障时的状态？是不是它就突然间崩溃掉了？它是否只是挂在那儿啥也不做了？它失效的时候是不是有一些反应*？在重启之后，它是否有能力可以恢复到前一个正常运行的状态？它是否会给用户显示出一些有用的错误信息，还是只是显示一些很难理解的十六进制代码？系统的安全性是否为因为一些不可预料的故障而会有所降低？这些问题可以一直问下去的。

结论
我明白我只是提到一些在性能/负载/压力测试中应该值得注意的一些比较基础的问题，工具及方法。我个人觉得性能测试及调试是一个很有趣的话题，我将会在以后贴更多的相关内容上来的。

一、简要介绍：

    sysstat这个工具，可以说是linux &Unix 以及Freebsd最常用的工具。它的主要用途就是观察服务负载，比如CPU和内存的占用率、网络的使用率以及磁盘写入和读取速度等。

    sar
    iostat
    sa1
    sa2
    sadf
    mpstat
    sadc
    sysstat

   这几个命令中，有的是服务，有的是查看结果的命令。也有的是即时服务器CPU，内存以及网络的使用率,比如先要打开sa1 sa2或者sysstat 才能使用sar sadf sadc, 还要即时服务器的CPU，内存，网络使用率的命令，比如：mpstat iostat
二、安装：

    首先您到 [url]http://perso.wanadoo.fr/sebastien.godard/[/url] 下载最新的版本，最好是源码包，比如我下载的是sysstat-5.1.1.tar.gz

    安装方法比较简单：

    1.解包：

    #tar zxvf sysstat-5.1.1.tar.gz

    2.安装：

    #cd sysstat-5.1.1
    #make config 这步可以省略，因为我在安装的过程 中，发现在有些发行版中出错，如果不用这个命令，可以直接安装到其默认的/usr/local/lib目录中
    make config这个命令就是用来配置sysstat安装的，比如安装路径，log存放等，如下：

    代码:
    Installation directory: [/usr/local]
    sadc directory: [/usr/local/lib/sa]
    System activity directory: [/var/log/sa]
    Clean system activity directory? [n]
    Enable National Language Support (NLS)? [y]
    Linux SMP race in serial driver workaround? [n]
    sa2 uses daily data file of previous day? [n]
    Number of daily data files to keep: [7]
    Group for manual pages: [man]
    Set crontab to start sar automatically? [n]

    #make 注：这步是必须的，如果您不用第一步，这步也是必要的。

    #make install

    这样就安装好了。

    三、使用：

    对于这个工具，如何使用呢？？如果您想看即时 服务器的CPU，内存，网络使用率的命令，比如：mpstat iostat ，您可以简单的用下面的命令，如果更复杂一点，您可以用man来查看所有命令的用法。

    比如：
    [beinan@S11 beinan]$ iostat
    Linux 2.4.22-2f (S11) 2004年10月30日

    avg-cpu: %user %nice %system %iowait %idle
    8.64 0.00 0.95 0.00 90.41
    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    dev3-0 2.97 55.28 38.84 213314 149856

    [beinan@S11 beinan]$ mpstat
    Linux 2.4.22-2f (S11) 2004年10月30日

    03时13分56秒 CPU %user %nice %sys %iowait %irq %soft %idle intr/s
    03时13分56秒 all 8.56 0.00 0.94 0.00 0.00 0.00 90.50 84.32

    比如观察磁盘的读写速度：

    [beinan@S11 beinan]$ iostat -p
    Linux 2.4.22-2f (S11) 2004年10月30日

    avg-cpu: %user %nice %system %iowait %idle
    33.54 0.00 4.95 0.86 60.65

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    hda 26.26 186.57 481.17 16117015 41564960
    hda1 3.29 1.33 26.01 115138 2246456
    hda2 19.86 26.49 149.65 2288449 12927104
    hda3 40.16 158.57 305.51 13697580 26391400
    hda5 0.00 0.00 0.00 8 0

  

    如果是想让服务器自动运行，并且想每个小时都有一个数据反馈，我们可以用cron 来让执行sa1 sa2，这样就有一份日志文件存在/var/log/sa/目录中。我们到时运行sar就能知道所有过去时间每个小时运行情况：

    可以写一个命令到一个文件中。。。把这个文件设置为755的执行权限，放在/etc/cron.hourly目录中。

    [root@S11 root]# cd /etc/cron.hourly/ 进入目录
    [root@S11 cron.hourly]# touch sa1ho 创建文件，这个文件名可以自己来命名
    [root@S11 cron.hourly]# chmod 755 sa1ho
    然后在这个文件中写入下面的一行

    /usr/local/lib/sa/sa1&

    这样每一个小时，就有日志文件写入/var/log/sa/目录中了，当然还有一个/usr/local/lib/sa/sa2的命令，也可以写一个文件到 在/etc/cron.weekly/目录中，sa2是做什么用的呢？自己先看看帮助文件，当然也可以写入/etc/cron.hourly/ ，这样就每小时一次。

linux 和unix下SAR命令的用法，对机器性能检测很有帮助

linux 和unix下SAR命令的用法，对机器性能检测很有帮助

dmesg可以直接查看cpu的主频，要查看CPU、内存的使用情况可以使用sar！

sar 命令行的常用格式：
sar [options] [-A] [-o file] t [n]

在命令行中，n 和t 两个参数组合起来定义采样间隔和次数，t为采样间隔，是必须有
的参数，n为采样次数，是可选的，默认值是1，-o file表示将命令结果以二进制格式
存放在文件中，file 在此处不是关键字，是文件名。options 为命令行选项，sar命令
的选项很多，下面只列出常用选项：

　　　　　　-A：所有报告的总和。
　　　　　　　　-u：CPU利用率
　　　　　　　　-v：进程、I节点、文件和锁表状态。
　　　　　　　　-d：硬盘使用报告。
　　　　　　　　-r：没有使用的内存页面和硬盘块。
　　　　　　　　-g：串口I/O的情况。
-b：缓冲区使用情况。
-a：文件读写情况。
-c：系统调用情况。
-R：进程的活动情况。
-y：终端设备活动情况。
-w：系统交换活动。

下面将举例说明。

例一：使用命令行 sar -u t n

例如，每60秒采样一次，连续采样5次，观察CPU 的使用情况，并将采样结果以二进制
形式存入当前目录下的文件zhou中，需键入如下命令：

# sar -u -o zhou 60 5

屏幕显示：

　　SCO_SV　　　scosysv　3.2v5.0.5　i80386　　　10/01/2001
　　　　14:43:50　　　%usr　　　%sys　　%wio　　　　%idle(-u)
　　　　14:44:50　　　0　　　　　1　　　　4　　　　　　94
　　　　14:45:50　　　0　　　　　2　　　　4　　　　　　93
　　　　14:46:50　　　0　　　　　2　　　　2　　　　　　96
　　　　14:47:50　　　0　　　　　2　　　　5　　　　　　93
　　　　14:48:50　　　0　　　　　2　　　　2　　　　　　96
　　　　Average　　　 0　　　　　2　　　　4　　　　　　94

在显示内容包括：

　　%usr：CPU处在用户模式下的时间百分比。
　　%sys：CPU处在系统模式下的时间百分比。
　　%wio：CPU等待输入输出完成时间的百分比。
　　%idle：CPU空闲时间百分比。

在所有的显示中，我们应主要注意%wio和%idle，%wio的值过高，表示硬盘存在I/O瓶颈，
%idle值高，表示CPU较空闲，如果%idle值高但系统响应慢时，有可能是CPU等待分配内存，
此时应加大内存容量。%idle值如果持续低于10，那么系统的CPU处理能力相对较低，表
明系统中最需要解决的资源是CPU。

如果要查看二进制文件zhou中的内容，则需键入如下sar命令：

　　　　# sar -u -f zhou

可见，sar命令即可以实时采样，又可以对以往的采样结果进行查询。

例二：使用命行sar -v t n

例如，每30秒采样一次，连续采样5次，观察核心表的状态，需键入如下命令：

# sar -v 30 5

屏幕显示：
　　　　　　SCO_SV scosysv 3.2v5.0.5 i80386 10/01/2001
　　　　　　10:33:23 proc-sz ov inod-sz ov file-sz ov lock-sz　　 (-v)
10:33:53　305/　321 　0　1337/2764　 0　1561/1706　0　40/　128
10:34:23　308/　321 　0　1340/2764　 0　1587/1706　0　37/　128
10:34:53　305/　321 　0　1332/2764　 0　1565/1706　0　36/　128
10:35:23　308/　321 　0　1338/2764　 0　1592/1706　0　37/　128
10:35:53　308/　321　 0　1335/2764　 0　1591/1706　0　37/　128

显示内容包括：

proc-sz：目前核心中正在使用或分配的进程表的表项数，由核心参数MAX-PROC控制。

　　inod-sz：目前核心中正在使用或分配的i节点表的表项数，由核心参数
MAX-INODE控制。

　　file-sz： 目前核心中正在使用或分配的文件表的表项数，由核心参数MAX-FILE控
制。

　　ov：溢出出现的次数。

　　Lock-sz：目前核心中正在使用或分配的记录加锁的表项数，由核心参数MAX-FLCKRE
控制。

显示格式为

实际使用表项/可以使用的表项数

显示内容表示，核心使用完全正常，三个表没有出现溢出现象，核心参数不需调整，如
果出现溢出时，要调整相应的核心参数，将对应的表项数加大。

例三：使用命行sar -d t n

例如，每30秒采样一次，连续采样5次，报告设备使用情况，需键入如下命令：

# sar -d 30 5

屏幕显示：

　　　　　　SCO_SV scosysv 3.2v5.0.5 i80386 10/01/2001
11:06:43 device　%busy　　　avque　　　r+w/s　　blks/s　　avwait avserv (-d)
11:07:13 wd-0　　　1.47　　　2.75　　　4.67　　　14.73　　 5.50 3.14
11:07:43 wd-0　　　0.43　　　18.77　　 3.07　　　8.66　　　25.11 1.41
11:08:13 wd-0　　　0.77　　　2.78　　　2.77　　　7.26　　　4.94 2.77
11:08:43 wd-0　　　1.10　　　11.18　　 4.10　　　11.26　　 27.32 2.68
11:09:13 wd-0　　　1.97　　　21.78　　 5.86　　　34.06　　　69.66 3.35
Average wd-0　　　1.15　　　12.11　　 4.09　　　15.19　　　31.12 2.80

显示内容包括：

device： sar命令正在监视的块设备的名字。
　　%busy： 设备忙时，传送请求所占时间的百分比。
　　avque： 队列站满时，未完成请求数量的平均值。
　　r+w/s： 每秒传送到设备或从设备传出的数据量。
　　blks/s： 每秒传送的块数，每块512字节。
　　avwait： 队列占满时传送请求等待队列空闲的平均时间。
　　avserv： 完成传送请求所需平均时间（毫秒）。

在显示的内容中，wd-0是硬盘的名字，%busy的值比较小，说明用于处理传送请求的有
效时间太少，文件系统效率不高，一般来讲，%busy值高些，avque值低些，文件系统
的效率比较高，如果%busy和avque值相对比较高，说明硬盘传输速度太慢，需调整。

例四：使用命行sar -b t n

例如，每30秒采样一次，连续采样5次，报告缓冲区的使用情况，需键入如下命令：

# sar -b 30 5

屏幕显示：

　　SCO_SV scosysv 3.2v5.0.5 i80386 10/01/2001
14:54:59 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s (-b)
14:55:29　0　　147　　100　 5　　21　　78　　 0　　　0
14:55:59　0　　186　　100　 5　　25　　79　　 0　　　0
14:56:29　4　　232 　　98　 8　　58　　86　　 0　　　0
14:56:59　0　　125　　100　 5　　23　　76　　 0　　　0
14:57:29　0　　 89　　100　 4　　12　　66　　 0　　　0
Average　 1　　156 　　99　 5　　28　　80　　 0　　　0

显示内容包括：

bread/s： 每秒从硬盘读入系统缓冲区buffer的物理块数。
lread/s： 平均每秒从系统buffer读出的逻辑块数。
%rcache： 在buffer cache中进行逻辑读的百分比。
bwrit/s： 平均每秒从系统buffer向磁盘所写的物理块数。
lwrit/s： 平均每秒写到系统buffer逻辑块数。
%wcache： 在buffer cache中进行逻辑读的百分比。
pread/s： 平均每秒请求物理读的次数。
pwrit/s： 平均每秒请求物理写的次数。

在显示的内容中，最重要的是%cache和%wcache两列，它们的值体现着buffer的使用效
率，%rcache的值小于90或者%wcache的值低于65，应适当增加系统buffer的数量，buffer
数量由核心参数NBUF控制，使%rcache达到90左右，%wcache达到80左右。但buffer参数
值的多少影响I/O效率，增加buffer，应在较大内存的情况下，否则系统效率反而得不到
提高。

例五：使用命行sar -g t n

例如，每30秒采样一次，连续采样5次，报告串口I/O的操作情况，需键入如下命令：

# sar -g 30 5

屏幕显示：

SCO_SV scosysv 3.2v5.0.5 i80386　　11/22/2001
17:07:03 　ovsiohw/s　 ovsiodma/s　　ovclist/s (-g)
17:07:33　　　0.00　　　0.00　　　0.00
17:08:03　　　0.00　　　0.00　　　0.00
17:08:33　　　0.00　　　0.00　　　0.00
17:09:03　　　0.00　　　0.00　　　0.00
17:09:33　　　0.00　　　0.00　　　0.00
Average 　　　0.00　　　0.00　　　0.00

显示内容包括：

ovsiohw/s：每秒在串口I/O硬件出现的溢出。

ovsiodma/s：每秒在串口I/O的直接输入输出通道高速缓存出现的溢出。

ovclist/s ：每秒字符队列出现的溢出。

在显示的内容中，每一列的值都是零，表明在采样时间内，系统中没有发生串口I/O溢
出现象。

sar命令的用法很多，有时判断一个问题，需要几个sar命令结合起来使用，比如，怀疑
CPU存在瓶颈，可用sar -u 和sar -q来看，怀疑I/O存在瓶颈，可用sar -b、sar -u和sar-d来看。
--------------------------------------------------------------------------------
Sar
-A 所有的报告总和
-a 文件读，写报告
-B 报告附加的buffer cache使用情况
-b buffer cache使用情况
-c 系统调用使用报告
-d 硬盘使用报告
-g 有关串口I/O情况
-h 关于buffer使用统计数字
-m IPC消息和信号灯活动
-n 命名cache
-p 调页活动
-q 运行队列和交换队列的平均长度
-R 报告进程的活动
-r 没有使用的内存页面和硬盘块
-u CPU利用率
-v 进程，i节点，文件和锁表状态
-w 系统交换活动
-y TTY设备活动


-a 报告文件读，写报告
</> sar –a 5 5
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/07/2002
11:45:40 iget/s namei/s dirbk/s (-a)
11:45:45 6 2 2
11:45:50 91 20 28
11:45:55 159 20 18
11:46:00 157 21 19
11:46:05 177 30 35
Average 118 18 20

iget/s 每秒由i节点项定位的文件数量
namei/s 每秒文件系统路径查询的数量
dirbk/s 每秒所读目录块的数量

＊这些值越大，表明核心花在存取用户文件上的时间越多，它反映着一些程序和应用文件系统产生的负荷。一般地，如果iget/s与namei/s的比值大于5，并且namei/s的值大于30，则说明文件系统是低效的。这时需要检查文件系统的自由空间，看看是否自由空间过少。


-b 报告缓冲区（buffer cache）的使用情况
</> sar -b 2 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/07/2002
13:51:28 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s (-b)
13:51:30 382 1380 72 131 273 52 0 0
13:51:32 378 516 27 6 22 72 0 0
13:51:34 172 323 47 39 57 32 0 0
Average 310 739 58 58 117 50 0 0

bread/s 平均每秒从硬盘（或其它块设备）读入系统buffer的物理块数
lread/s 平均每秒从系统buffer读出的逻辑块数
%rcache 在buffer cache中进行逻辑读的百分比（即100％ - bread/lreads）
bwrit/s 平均每秒从系统buffer向磁盘（或其它块设备）所写的物理块数
lwrit/s 平均每秒写到系统buffer的逻辑块数
%wcache 在buffer cache中进行逻辑写的百分比（即100％ - bwrit/lwrit）.
pread/sgu 平均每秒请求进行物理读的次数
pwrit/s 平均每秒请求进行物理写的次数

＊所显示的内容反映了目前与系统buffer有关的读，写活。在所报告的数字中，最重要的是%rcache和%wcache（统称为cache命中率）两列，它们具体体现着系统buffer的效率。衡量cache效率的标准是它的命中率值的大小。
＊如果%rcache的值小于90或者%wcache的值低于65，可能就需要增加系统buffer的数量。如果在系统的应用中，系统的I/O活动十分频繁，并且在内存容量配置比较大时，可以增加buffer cache，使%rcache达到95左右，%wcache达到80左右。
＊系统buffer cache中，buffer的数量由核心参数NBUF控制。它是一个要调的参数。系统中buffer数量的多少是影响系统I/O效率的瓶颈。要增加系统buffer数量，则要求应该有较大的内存配置。否则一味增加buffer数量，势必减少用户进程在内存中的运行空间，这同样会导致系统效率下降。



-c 报告系统调用使用情况
</ > sar -c 2 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/07/2002
17:02:42 scall/s sread/s swrit/s fork/s exec/s rchar/s wchar/s (-c)
17:02:44 2262 169 141 0.00 0.00 131250 22159
17:02:46 1416 61 38 0.00 0.00 437279 6464
17:02:48 1825 43 25 0.00 0.00 109397 42331
Average 1834 91 68 0.00 0.00 225975 23651

scall/s 每秒使用系统调用的总数。一般地，当4~6个用户在系统上工作时，每秒大约30个左右。
sread/s 每秒进行读操作的系统调用数量。
swrit/s 每秒进行写操作的系统调用数量。
fork/s 每秒fork系统调用次数。当4~6个用户在系统上工作时，每秒大约0.5秒左右。
exec/s 每秒exec系统调用次数。
rchar/s 每秒由读操作的系统调用传送的字符（以字节为单位）。
wchar/s 每秒由写操作的系统调用传送的字符（以字节为单位）。
＊如果scall/s持续地大于300，则表明正在系统中运行的可能是效率很低的应用程序。在比较
典型的情况下，进行读操作的系统调用加上进行写操作的系统调用之和，约是scall的一半左右。


-d 报告硬盘使用情况
</ > sar -d 2 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/07/2002
17:27:49 device %busy avque r+w/s blks/s avwait avserv (-d)
17:27:51 ida-0 6.93 1.00 13.86 259.41 0.00 5.00
ida-1 0.99 1.00 17.33 290.10 0.00 0.57
17:27:53 ida-0 75.50 1.00 54.00 157.00 0.00 13.98
ida-1 9.50 1.00 12.00 75.00 0.00 7.92
17:27:55 ida-0 7.46 1.00 46.77 213.93 0.00 1.60
ida-1 17.41 1.00 57.71 494.53 0.00 3.02
Average ida-0 29.85 1.00 38.14 210.28 0.00 7.83
ida-1 9.29 1.00 29.02 286.90 0.00 3.20


device 这是sar命令正在监视的块设备的名字。
%busy 设备忙时，运行传送请求所占用的时间。这个值以百分比表示。
avque 在指定的时间周期内，没有完成的请求数量的平均值。仅在队列被占满时取这个值。
r+w/s 每秒传送到设备或者从设备传送出的数据量。
blks/s 每秒传送的块数。每块512个字节。
avwait 传送请求等待队列空闲的平均时间（以毫秒为单位）。仅在队列被占满时取这个值。
avserv 完成传送请求所需平均时间（以毫秒为单位）
＊ida-0和ida-1是硬盘的设备名字。在显示的内容中，如果%busy的值比较小，说明用于处理
传送请求的有效时间太少，文件系统的效率不高。要使文件系统的效率得到优化，应使%busy的数值相对高一些，而avque的值应该低一些。


-g 报告有关串口I/O情况
</ > sar -g 3 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/13/2002
11:10:09 ovsiohw/s ovsiodma/s ovclist/s (-g)
11:10:12 0.00 0.00 0.00
11:10:15 0.00 0.00 0.00
11:10:18 0.00 0.00 0.00
Average 0.00 0.00 0.00

ovsiohw/s 每秒在串囗I/O硬件出现的溢出。
ovsiodma/s 每秒在串囗I/O的直接输入，输出信道高速缓存出现的溢出。
ovclist/s 每秒字符队列出现的溢出。


-m 报告进程间的通信活动（IPC消息和信号灯活动）情况
</ > sar -m 4 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/13/2002
13:24:28 msg/s sema/s (-m)
13:24:32 2.24 9.95
13:24:36 2.24 21.70
13:24:40 2.00 36.66
Average 2.16 22.76

msg/s 每秒消息操作的次数（包括发送消息的接收信息）。
sema/s 每秒信号灯操作次数。
＊信号灯和消息作为进程间通信的工具，如果在系统中运行的应用过程中没有使用它们，那么由sar命令报告的msg 和sema的值都将等于0.00。如果使用了这些工具，并且其中或者msg/s大于100，或者sema/s大于100，则表明这样的应用程序效率比较低。原因是在这样的应用程序中，大量的时间花费在进程之间的沟通上，而对保证进程本身有效的运行时间必然产生不良的影响。


-n 报告命名缓冲区活动情况
</ > sar -n 4 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/13/2002
13:37:31 c_hits cmisses (hit %) (-n)
13:37:35 1246 71 (94%)
13:37:39 1853 81 (95%)
13:37:43 969 56 (94%)
Average 1356 69 (95%)

c_hits cache命中的数量。
cmisses cache未命中的数量。
(hit %) 命中数量/(命中数理+未命中数量)。
＊不难理解，(hit %)值越大越好，如果它低于90％，则应该调整相应的核心参数。


-p 报告分页活动
</ > sar -p 5 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/13/2002
13:45:26 vflt/s pflt/s pgfil/s rclm/s (-p)
13:45:31 36.25 50.20 0.00 0.00
13:45:36 32.14 58.48 0.00 0.00
13:45:41 79.80 58.40 0.00 0.00
Average 49.37 55.69 0.00 0.00

vflt/s 每秒进行页面故障地址转换的数量（由于有效的页面当前不在内存中）。
pflt/s 每秒来自由于保护错误出现的页面故障数量（由于对页面的非法存，取引起的页面故障）。
pgfil/s 每秒通过”页—入”满足vflt/s的数量。
rclm/s 每秒由系统恢复的有效页面的数量。有效页面被增加到自由页面队列上。
＊如果vflt/s的值高于100，可能预示着对于页面系统来说，应用程序的效率不高，也可能分页参数需要调整，或者内存配置不太合适。


-q 报告进程队列（运行队列和交换队列的平均长度）情况
</ > sar -q 2 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/13/2002
14:25:50 runq-sz %runocc swpq-sz %swpocc (-q)
14:25:52 4.0 50
14:25:54 9.0 100
14:25:56 9.0 100
Average 7.3 100

runq-sz 准备运行的进程运行队列。
%runocc 运行队列被占用的时间（百分比）
swpq-sz 要被换出的进程交换队列。
%swpocc 交换队列被占用的时间（百分比）。
＊如果%runocc大于90，并且runq-sz的值大于2，则表明CPU的负载较重。其直接后果，可能使系统的响应速度降低。如果%swpocc大于20，表明交换活动频繁，将严重导致系统效率下降。解决的办法是加大内存或减少缓存区数量，从而减少交换及页—入,页—出活动。


-r 报告内存及交换区使用情况（没有使用的内存页面和硬盘块）
</> sar -r 2 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/14/2002
10:14:19 freemem freeswp availrmem availsmem (-r)
10:14:22 279729 6673824 93160 1106876
10:14:24 279663 6673824 93160 1106876
10:14:26 279661 6673824 93160 1106873
Average 279684 6673824 93160 1106875

freemem 用户进程可以使用的内存页面数，4KB为一个页面。
freeswp 用于进程交换可以使用的硬盘盘块，512B为一个盘块。


-u CPU利用率
</> sar -u 2 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/14/2002
10:27:23 %usr %sys %wio %idle (-u)
10:27:25 2 3 8 88
10:27:27 3 3 5 89
10:27:29 0 0 0 100
Average 2 2 4 92
.
%usr cpu处在用户模式下时间（百分比）
%sys cpu处在系统模式下时间（百分比）
%wio cpu等待输入，输出完成（时间百分比）
%idle cpu空闲时间（百分比）
＊在显示的内容中，%usr和 %sys这两个值一般情况下对系统无特别影响，%wio的值不能太高，如果%wio的值过高，则CPU花在等待输入，输出上的时间太多，这意味着硬盘存在I/O瓶颈。如果%idle的值比较高，但系统响应并不快，那么这有可能是CPU花时间等待分配内存引起的。%idle的值可以较深入帮助人们了解系统的性能，在这种情况上，%idle的值处于40~100之间，一旦它持续低于30，则表明进程竟争的主要资源不是内存而是CPU。
＊在有大量用户运行的系统中，为了减少CPU的压力，应该使用智能多串卡，而不是非智能多串卡。智能多串卡可以承担CPU的某些负担。
＊此外，如果系统中有大型的作业运行，应该把它们合理调度，错开高峰，当系统相对空闲时再运行。


-v 报告系统表的内容（进程，i节点，文件和锁表状态）
</> sar -v 2 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/14/2002
10:56:46 proc-sz ov inod-sz ov file-sz ov lock-sz (-v)
10:56:48 449/ 500 0 994/4147 0 1313/2048 0 5/ 128
10:56:50 450/ 500 0 994/4147 0 1314/2048 0 5/ 128
10:56:52 450/ 500 0 994/4147 0 1314/2048 0 5/ 128

proc-sz 目前在核心中正在使用或分配的进程表的表项数
inod-sz 目前在核心中正在使用或分配的i节点表的表项数
file-sz 目前在核心中正在使用或分配的文件表的表项数
ov 溢出出现的次数
lock-sz 目前在核心中正在使用或分配的记录加锁的表项数
＊除ov外，均涉及到unix的核心参数，它们分别受核心参数NPROC,NIMODE,NFILE和FLOCKREC的控制。
＊显示格式为：
实际使用表项/整个表可以使用的表项数
比如，proc-sz一列所显示的四个数字中，分母的100是系统中整个进程表的长度（可建立100个表项），分子上的24，26和25分别是采样的那一段时间所使用的进程表项。inod-sz，file-sz和lock-sz三列数字的意义也相同。
三列ov的值分别对应进程表，i节点表和文件表，表明目前这三个表都没有出现溢出现象，当出现溢出时，需要调整相应的核心参数，将对应表加大。


-w 系统交换活动
</> sar -w 2 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/14/2002
11:22:05 swpin/s bswin/s swpot/s bswots pswch/s (-w)
11:22:07 0.00 0.0 0.00 0.0 330
11:22:09 0.00 0.0 0.00 0.0 892
11:22:11 0.00 0.0 0.00 0.0 1053
Average 0.00 0.0 0.00 0.0 757

swpin/s 每秒从硬盘交换区传送进入内存的次数。
bswin/s 每秒为换入而传送的块数。
swpot/s 每秒从内存传送到硬盘交换区的次数。
bswots 每秒为换出而传送的块数。
pswch/s 每秒进程交换的数量。
＊swpin/s，bswin/s，swpot/s和bswots描述的是与硬盘交换区相关的交换活动。交换关系到系统的效率。交换区在硬盘上对硬盘的读，写操作比内存读，写慢得多，因此，为了提高系统效率就应该设法减少交换。通常的作法就是加大内存，使交换区中进行的交换活动为零，或接近为零。如果swpot/s的值大于1，预示可能需要增加内存或减少缓冲区（减少缓冲区能够释放一部分自由内存空间）。




-y 报告终端的I/O活动（TTY设备活动）情况
</> sar -y 2 3
SCO_SV scosvr 3.2v5.0.5 PentII(D)ISA 06/14/2002
11:38:03 rawch/s canch/s outch/s rcvin/s xmtin/s mdmin/s (-y)
11:38:05 5 0 951 0 1 0
11:38:07 10 0 996 0 0 0
11:38:09 4 0 2264 0 0 0
Average 6 0 1404 0 1 0

rawch/s 每秒输入的字符数（原始队列）
canch/s 每秒由正则队列（canonical queue）处理的输入字符数。进行正则处理过程中，可以识别出一些有特殊意义的字符。比如，<Del>(中断字符)，<ctrl>(退出符)，<Bksp>(退格键)等。因此，canch/s中的计数不包括这些有特殊意义的字符。
outch/s 每秒输出的字符数。
rcvin/s 每秒接收的硬件中断次数。
xmtin/s 每秒发出的硬件中断次数。
mdmin/s 每秒modem中断次数。
＊应该特别说明，sar命令可以对任意终端活动进行统计，所谓任意终端，是指任意tty设备。它们可以是串行终端，主控台，伪终端等等。
＊在这几个量中，modem中断次数mdmin/s应该接近0。其它没有特殊要求，但如果每发送一个字符，中断的数量就动态地增加，这表明终端线出了差错，可能是接触不好。

John Lee写的一篇“Tricks of Software testing”中提到的：

    (2)用例： 一般考虑3个方面的，合理的，不合理的和边界的。

    感觉这里提到的合理的、不合理的应该是针对输入而言的，或者也可以用合法的、不合法的以及有效的、无效的来进行替代，这样与之相对应的方法就是等价类划分。

    我们经常说设计用例时要考虑合法的情况也要考虑非法的情况，但这种思路容易让我们把测试用例的设计简单化、机械化。为什么这样说呢，原因有二：
    1、单纯的合理不合理容易产生遗漏。比如现在有这样一个软件，是专门用来统计我们写的.c文件中的代码行数的。如果要测试这个软件统计代码行数的功能，很容易想到的就是统计一个合法的.c文件，考虑有不同的代码行数；统计一个非法的.c文件，这里的非法有多种情况。但这样是否就意味着是比较好的测试用例设计了呢？我们是不是还应该看看这个软件会不会把注释行误判成代码行等等呢。
    2、为了使用方法而使用方法，比如等价类、边界值、正交分析等等，反而忽略了我们设计这些用例到底是为了什么目的、每个测试用例的测试点到底在什么地方。

    既然单纯考虑合理不合理并不是一种很好的方式，那么应该按照一个什么思路来去考虑我们的用例设计呢？其实这个思路已经有了，那就是正向（positive testing）和逆向（negative testing）。

    先来看一下正向测试和逆向测试的含义：
    正向测试：验证被测对象是不是做了它该做的事情。
    逆向测试：验证被测对象有没有做它不该做的事情。
    可以看出，正向测试并不一定就是简单的输入合法数据，而逆向测试也不一定就是简单的输入非法数据。正向和逆向不仅让我们知道如何去选择测试数据，还让每组数据的目的性也突出出来了。

    还是回到前面提到的统计代码行软件的测试，测试该软件会不会把注释行误判成代码行就是一种逆向测试。

    从上面的分析可以看出，选择正向逆向比合理不合理更能让我们把握测试用例设计的本质，也更有助于我们去不断提高自己的测试水平和能力，因为下面我们要做的一个工作就是搞清楚哪些是被测对象该做的事情而哪些是被测对象不该做的事情，分析的越细越清楚，测试用例设计的就越好。

PS：接下来准备针对
    (5)黑盒测试的典型方法： 正交矩阵法是减少测试用例的有效方法。等价类划分的缺点是没有考虑边界。
    再写一篇“正交分析法到底好在哪”。

    写这篇文章的想法来源于John Lee写的一篇“Tricks of Software testing”中提到的：

    (1)群集现象：发现问题越多的地方，隐含的缺陷也越多，需要重点处理。 
    佩瑞多定理：（80-20定律）许多软件现象都遵循佩瑞多分布规律：80%的贡献来自于20%的贡献者。例如20%的模块含有80%的错误。

    这里提到集群现象也就是我们一般所说的bug的群居现象（我们为什么把在软件中发现的问题叫bug呢？除了众所周知的美国海军计算机继电器的故事，再就是软件中的问题也像bug一样具有群居性和抗药性）。

    如果简单归纳一下软件测试中的80-20定律，大致有这些：
    1、80%的bug隐藏在20%的代码中；
    2、80%的bug是由20%的测试人员发现的；
    3、80%的bug属于20%的错误类型；
    4、80%的时间用在测试计划、测试设计、测试实现上，20%的时间用于测试执行上；
    5、80%的bug通过静态测试发现，20%的bug通过动态测试发现；
    6、80%的bug通过人工测试发现，20%的bug通过自动化测试发现；
    7、对于一个测试人员而言，20%的时间发现80%的bug，而剩余的80%的时间只能发现20%的bug。
    。。。。。。
    （一下子也想不到太多了，想到了再更新，也欢迎大家补充）

    这里不想对这些所谓的定律做更多的说明，主要是想关注一下80-20中的20这个小部分（比如80%的代码中包含的20%的错误），80这个大的部分大家已经重视的很多了（比如进行缺陷分析时针对的是属于20%错误类型的80%的bug）。

    提到80-20定律，就不得不提下长尾定律（没见过的去google一下：））：简单一点说就是看似不起眼的20%的部分，有可能产生的影响要等于甚至大于80%的部分。这个听起来比较绕口，还是针对上面提到的80-20定律好了：
    1、20%的bug隐藏在80%的代码中。那说明这些bug其实是很难去查找的，也就是说我们前面发现的80%的错误更多的是比较明显的错误，那下面就有这样一个问题了，怎样去尽量快的把这20%的bug找出来呢？
    2、80%的测试人员只发现了20%的bug。这说明从整个团队而言，能力上存在比较明显的等级分化，真正的高级测试工程师很少，更多的是茫然的、无助的、民工似的普通测试工程师，而这些普通测试工程师又是公司测试的主力军，怎样去提高这80%的测试人员的水平呢？
    3、一个测试人员80%的时间只能发现20%的bug。因此不少测试人员会感觉自己很多时间都在做无用功、没有什么收获，那么应该怎样去充分利用这80%的时间呢？

    这里只是胡乱抛出了几个问题，希望能和大家交流。

PS：接下来准备针对
    (2)用例： 一般考虑3个方面的，合理的，不合理的和边界的。
    再写一篇“合理不合理还是正向逆向”。