日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
搜索标题
最新评论
统计信息
- 访问量: 1415
- 日志数: 12
- 建立时间: 2007-11-20
- 更新时间: 2007-12-20
RSS订阅
我的最新日志
-
字体变化
2007-12-20
-
状态栏显示字体
2007-12-20
-
测试用例题目总结
2007-11-29
-
TestLink
2007-11-26
以下属于本人摘录内容：
使用 TestLink 进行测试管理
TestLink用于进行测试过程中的管理，通过使用TestLink提供的功能，可以将测试过程从测试需求、测试设计、到测试执行完整的管理起来，同时，它还提供了好多种测试结果的统计和分析，使我们能够简单的开始测试工作和分析测试结果。
TestLink 是sourceforge的开放源代码项目之一。作为基于web的测试管理系统，TestLink的主要功能包括：
- 测试需求管理
- 测试用例管理
- 测试用例对测试需求的覆盖管理
- 测试计划的制定
- 测试用例的执行
- 大量测试数据的度量和统计功能。
TestLink的最新版本是1.6.2。在本文接下来的部分里，作者将详细地介绍使用TestLink1.6.0来进行测试管理的完整过程。
1、 在安装TestLink1.6.0前，需要完成以下安装运行所需要的环境：Webserver、php4和MySQL。笔者推荐的安装环境如下：
- Apache HTTP Server 2.0.59
- Php 4.4.1
- Mysql 4.1.21
2、 将 TestLink 安装包保存到服务器，解压缩到 Apache2 的 htdocs 目录下，并重命名为 testlink。
3、 自动安装 TestLink
- 在浏览器输入访问地址http://yoursite/testlink/install/index.php，如：http://localhost:80/testlink/install/index.php
- 选择new install，在进入的页面中，输入登录MySQL的用户名和密码，如root。提示安装成功，详细的安装说明请参照http://blog.csdn.net/judyxm/archive/2006/01/12/577148.aspx
4、 登录testlink首页面。系统为testlink创建一个默认管理员账号，用户名和密码为：admin/admin。你可以使用这个账号访问TestLink 。登录http://127.0.0.1:80/testlink/index.php，如果你看到的页面如下，就说明你已经安装成功了。
回页首
在TestLink系统中，每个用户都可以维护自己的私有信息。admin可以创建用户，但不能看到其它用户的密码。在用户信息中，需要设置Email地址，如果用户忘记了密码，系统可以通过mail获得。
TestLink系统提供了六种角色，分别是admin、leader、senior tester 、tester、guest、testdesigner。相对应的功能权限如下：（详见图）
- Guest：只有读的权限，适合于查看测试用例和测试需求，以及项目分析的用户。
- Testdesigner：可以开展测试用例和测试需求的所有工作。
- Tester：只能执行测试用例。
- Senior tester：可以查看和维护测试用例，并且可以执行测试用例，但是不能管理测试计划、分配测试任务。
- Leader：可以开展测试规格和测试需求的所有工作，还可以管理测试计划、分配测试任务。
- Admin：维护产品，用户。
同时，支持不同地域用户对不同语言的需求，可以根据用户的喜好对用户提供不同的语言支持。
TestLink可以对多个产品进行管理，Admin进行产品设置后，测试人员就可以进行测试需求、测试用例、测试计划等相关管理工作了。TestLink支持对每个产品设置不同的背景颜色，方便管理。
回页首
测试需求是我们开展测试的依据。首先，我们对产品的测试需求进行分解和整理。一个产品可以包含多个测试需求规格，一个测试需求规格可以包含多个测试需求；
- 创建测试需求规格
对测试需求规格的描述比较简单，内容包含名称、范围。 - 创建测试需求
测试需求内容包含：需求ID、名称、范围、需求的状态，以及覆盖需求的案例。 TestLink提供了两种状态来管理需求：正确的（Valid）、不可测试的（not testable）。
- 从文件导入测试需求
Testlink提供了从文件导入测试需求的功能，支持的的文件类型有csv和csv（door）两种。
回页首
TestLink支持的测试用例的管理包含三层：分别为Component、Category、Test case。我们把Component对应到项目的功能模块，而把Category跟每个模块的function对应，Test case就是写在这些Category里的。我们可以使用测试用例搜索功能从不同的项目、成百上千的测试用例中查到我们需要的测试用例，甚至于可以直接将别的项目里写的测试用例复制过来，这样就解决了测试用例的管理和复用问题。
但是，还有一个问题没有解决，那就是与测试需求的对应问题。在测试管理中，测试用例对测试需求的覆盖率是我们非常关心的，从需求规格说明书中提取出测试需求之后， Testlink提供管理测试需求与测试用例的对应关系的功能。
- 创建Component
Component的内容包括：名称、介绍、范围、相关的内容、约束。 - 创建Category
Category的内容包括：名称、测试范围和目标、配置信息、测试数据、测试工具 - 创建 Test case
测试用例的要素包括：测试用例名称、简要说明、步骤、期望结果、关键字。
创建好的测试用例树如下：
- 建立测试用例和测试需求的覆盖关系。
选中左侧用例树中的测试用例，再选择右侧对应的测试需求，进行Assign即可。
回页首
在TestLink系统中，一个完整的测试计划包括：
- 测试阶段的名称（如集成测试阶段、系统测试阶段）
- 里程碑（明确每个测试阶段的开始和截止时间，以及完成A、B、C三种优先级的比例）
- Build版本（定义本测试计划中需要测试的build版本，一般以产品名+时间来命名。）
- 安排测试人员 （从用户列表中选择本测试计划的参与人员。）
- 测试用例集
- 制定优先级规则。优先级分为A、B、C三级，系统会根据用户定义的重要级别和风险级别的组合来确定优先级的归属。重要级别分为三级：Low、Medium、High。风险级别包括三级：1、2、3。
- 从测试用例中选择本测试计划的测试用例集
- 设置每个测试用例Category的重要级别和风险级别
- 设置每个测试用例Category的责任归属。从本测试计划的测试人员列表中选择每个Category的Owner，由他来负责和完成测试用例的执行。
回页首
执行测试用例，按照对每个build版本的执行情况，记录测试结果。测试结果有四种情况可以选择：
Not Run：还没有执行过
Pass：执行通过
Failed：执行失败
Blocked：由于其它用例失败，导致此用例无法执行，被阻塞。
回页首
TestLink根据测试过程中记录的数据，提供了较为丰富的度量统计功能，可以直观的得到测试管理过程中需要进行分析和总结的数据：
- 测试用例对测试需求的覆盖情况：哪些需求已经通过测试，哪些需求未通过测试，哪些需求处于阻塞状态，哪些需求还未开始测试。
- 针对每个版本的测试用例执行情况：
1）各种优先级的测试用例执行的比率
2）各个模块的测试用例执行的比率
3）各个测试人员测试用例的执行比率
- 每个版本的执行情况
- 所有测试用例在不同build版本的执行情况，显示？的地方表示还未执行。
- 阻塞的测试用例列表
- 失败的测试用例列表
- 每个测试用例的bug数
如果和bug跟踪系统连接的话，在下表中可以统计出每个测试用例的bug的数目
回页首
TestLink提供了与多种bug跟踪系统关联的接口配置，目前支持的bug系统有Jira、bugzilla、mantis。配置方法的相关文档参照帮助。
回页首
TestLink还提供了很多易用性的功能，比如：
- 从测试需求直接生成测试用例
- 文档的导入、导出功能
- 测试报告可以导出为excel
- 支持设定keyword
回页首
TestLink用于进行测试过程中的管理，通过使用TestLink提供的功能，我们可以将测试过程从测试需求、测试设计、到测试执行完整的管理起来，同时，它还提供了好多种测试结果的统计和分析，使我们能够简单的开始测试工作和分析测试结果。
本文中，作者根据自己的使用经验，详细演示了如何使用TestLink来进行测试管理的全部过程，简单的介绍了TestLink的使用方法。希望能够帮助大家学会使用TestLink的基本功能，同时，大家可以参考这个过程和TestLink的帮助文档来实现对测试过程的管理。
- TestLink的帮助文档
- Judy Shen的 Blog中的TestLink1.6.0的安装说明，详细内容请参考：http://blog.csdn.net/judyxm/archive/2006/01/12/577148.aspx
-
最新测试术语大全
2007-11-23
-
step -by -step install bugzilla
2007-11-21
this day ,the bugzilla in server computer appears internal error,and the manager is out.so i want to install the other one bugzilla by myself.
this is the document about bugzilla installration
i found on the web .very good !
please fllow me to install !
ok begin!4.1. Step-by-step Install
4.1.1. Introduction
Bugzilla has been successfully installed under Solaris, Linux, and Win32. Win32 is not yet officially supported, but many people have got it working fine. Please see the Win32 Installation Notes for further advice on getting Bugzilla to work on Microsoft Windows.
4.1.2. Package List
If you are running the very most recent version of Perl and MySQL (both the executables and development libraries) on your system, you can skip these manual installation steps for the Perl modules by using Bundle::Bugzilla; see Using Bundle::Bugzilla instead of manually installing Perl modules.
The software packages necessary for the proper running of Bugzilla (with download links) are:
MySQL database server (3.22.5 or greater)
Perl (5.005 or greater, 5.6.1 is recommended if you wish to use Bundle::Bugzilla)
Perl Modules (minimum version):
Template (v2.07)
AppConfig (v1.52)
Text::Wrap (v2001.0131)
File::Spec (v0.8.2)
Data::Dumper (any)
DBD::mysql (v1.2209)
DBI (v1.13)
Date::Parse (any)
CGI::Carp (any)
GD (v1.19) for bug charting
Chart::Base (v0.99c) for bug charting
XML::Parser (any) for the XML interface
MIME::Parser (any) for the email interface
The web server of your choice. Apache is highly recommended.
It is a good idea, while installing Bugzilla, to ensure that there is some kind of firewall between you and the rest of the Internet, because your machine may be insecure for periods during the install. Many installation steps require an active Internet connection to complete, but you must take care to ensure that at no point is your machine vulnerable to an attack.
Linux-Mandrake 8.0 includes every required and optional library for Bugzilla. The easiest way to install them is by using the urpmi utility. If you follow these commands, you should have everything you need for Bugzilla, and checksetup.pl should not complain about any missing libraries. You may already have some of these installed.
bash# urpmi perl-mysql bash# urpmi perl-chart bash# urpmi perl-gd bash# urpmi perl-MailTools (for Bugzilla email integration) bash# urpmi apache-modules 4.1.3. MySQL
Visit the MySQL homepage at www.mysql.com to grab and install the latest stable release of the server.
Many of the binary versions of MySQL store their data files in /var. On some Unix systems, this is part of a smaller root partition, and may not have room for your bug database. You can set the data directory as an option to configure if you build MySQL from source yourself.
If you install from something other than an RPM or Debian package, you will need to add mysqld to your init scrīpts so the server daemon will come back up whenever your machine reboots. Further discussion of UNIX init sequences are beyond the scope of this guide.
Change your init scrīpt to start mysqld with the ability to accept large packets. By default, mysqld only accepts packets up to 64K long. This limits the size of attachments you may put on bugs. If you add -O max_allowed_packet=1M to the command that starts mysqld (or safe_mysqld), then you will be able to have attachments up to about 1 megabyte. There is a Bugzilla parameter for maximum attachment size; you should configure it to match the value you choose here.
If you plan on running Bugzilla and MySQL on the same machine, consider using the --skip-networking option in the init scrīpt. This enhances security by preventing network access to MySQL.
4.1.4. Perl
Any machine that doesn't have Perl on it is a sad machine indeed. Perl can be got in source form from perl.com for the rare *nix systems which don't have it. Although Bugzilla runs with all post-5.005 versions of Perl, it's a good idea to be up to the very latest version if you can when running Bugzilla. As of this writing, that is Perl version 5.6.1.
You can skip the following Perl module installation steps by installing Bundle::Bugzilla from CPAN, which installs all required modules for you.
bash# perl -MCPAN -e 'install "Bundle::Bugzilla"'
Bundle::Bugzilla doesn't include GD, Chart::Base, or MIME::Parser, which are not essential to a basic Bugzilla install. If installing this bundle fails, you should install each module individually to isolate the problem.
4.1.5. Perl Modules
All Perl modules can be found on the Comprehensive Perl Archive Network (CPAN). The CPAN servers have a real tendency to bog down, so please use mirrors.
Quality, general Perl module installation instructions can be found on the CPAN website, but the easy thing to do is to just use the CPAN shell which does all the hard work for you. To use the CPAN shell to install a module:
bash# perl -MCPAN -e 'install "<modulename>"'
To do it the hard way:
Untar the module tarball -- it should create its own directory
CD to the directory just created, and enter the following commands:
bash# perl Makefile.PL
bash# make
bash# make test
bash# make install
Many people complain that Perl modules will not install for them. Most times, the error messages complain that they are missing a file in "@INC". Virtually every time, this error is due to permissions being set too restrictively for you to compile Perl modules or not having the necessary Perl development libraries installed on your system. Consult your local UNIX systems administrator for help solving these permissions issues; if you are the local UNIX sysadmin, please consult the newsgroup/mailing list for further assistance or hire someone to help you out.
4.1.5.1. DBI
The DBI module is a generic Perl module used the MySQL-related modules. As long as your Perl installation was done correctly the DBI module should be a breeze. It's a mixed Perl/C module, but Perl's MakeMaker system simplifies the C compilation greatly.
4.1.5.2. Data::Dumper
The Data::Dumper module provides data structure persistence for Perl (similar to Java's serialization). It comes with later sub-releases of Perl 5.004, but a re-installation just to be sure it's available won't hurt anything.
4.1.5.3. MySQL-related modules
The Perl/MySQL interface requires a few mutually-dependent Perl modules. These modules are grouped together into the the Msql-Mysql-modules package.
The MakeMaker process will ask you a few questions about the desired compilation target and your MySQL installation. For most of the questions the provided default will be adequate, but when asked if your desired target is the MySQL or mSQL packages, you should select the MySQL related ones. Later you will be asked if you wish to provide backwards compatibility with the older MySQL packages; you should answer YES to this question. The default is NO.
A host of 'localhost' should be fine and a testing user of 'test' with a null password should find itself with sufficient access to run tests on the 'test' database which MySQL created upon installation.
4.1.5.4. TimeDate modules
Many of the more common date/time/calendar related Perl modules have been grouped into a bundle similar to the MySQL modules bundle. This bundle is stored on the CPAN under the name TimeDate. The component module we're most interested in is the Date::Format module, but installing all of them is probably a good idea anyway.
4.1.5.5. GD (optional)
The GD library was written by Thomas Boutell a long while ago to programatically generate images in C. Since then it's become the defacto standard for programatic image construction. The Perl bindings to it found in the GD library are used on millions of web pages to generate graphs on the fly. That's what Bugzilla will be using it for so you must install it if you want any of the graphing to work.
The Perl GD library requires some other libraries that may or may not be installed on your system, including libpng and libgd. The full requirements are listed in the Perl GD library README. If compiling GD fails, it's probably because you're missing a required library.
4.1.5.6. Chart::Base (optional)
The Chart module provides Bugzilla with on-the-fly charting abilities. It can be installed in the usual fashion after it has been fetched from CPAN. Note that earlier versions that 0.99c used GIFs, which are no longer supported by the latest versions of GD.
4.1.5.7. Template Toolkit
When you install Template Toolkit, you'll get asked various questions about features to enable. The defaults are fine, except that it is recommended you use the high speed XS Stash of the Template Toolkit, in order to achieve best performance. However, there are known problems with XS Stash and Perl 5.005_02 and lower. If you wish to use these older versions of Perl, please use the regular stash.
4.1.6. HTTP Server
You have a freedom of choice here - Apache, Netscape or any other server on UNIX would do. You can run the web server on a different machine than MySQL, but need to adjust the MySQL "bugs" user permissions accordingly.
We strongly recommend Apache as the web server to use. The Bugzilla Guide installation instructions, in general, assume you are using Apache. If you have got Bugzilla working using another webserver, please share your experiences with us.
You'll want to make sure that your web server will run any file with the .cgi extension as a CGI and not just display it. If you're using Apache that means uncommenting the following line in the httpd.conf file:
AddHandler cgi-scrīpt .cgi
With Apache you'll also want to make sure that within the httpd.conf file the line:
is in the stanza that covers the directories into which you intend to put the bugzilla .html and .cgi files.Options ExecCGI
AllowOverride Limit
AllowOverride Limit allows the use of a Deny statement in the .htaccess file generated by checksetup.pl
Users of older versions of Apache may find the above lines in the srm.conf and access.conf files, respecitvely.
There are important files and directories that should not be a served by the HTTP server - most files in the "data" and "shadow" directories and the "localconfig" file. You should configure your HTTP server to not serve these files. Failure to do so will expose critical passwords and other data. Please see .htaccess files and security for details on how to do this for Apache; the checksetup.pl scrīpt should create appropriate .htaccess files for you.
4.1.7. Bugzilla
You should untar the Bugzilla files into a directory that you're willing to make writable by the default web server user (probably "nobody"). You may decide to put the files in the main web space for your web server or perhaps in /usr/local with a symbolic link in the web space that points to the Bugzilla directory.
If you symlink the bugzilla directory into your Apache's HTML heirarchy, you may receive Forbidden errors unless you add the "FollowSymLinks" directive to the <Directory> entry for the HTML root in httpd.conf.
Once all the files are in a web accessible directory, make that directory writable by your webserver's user. This is a temporary step until you run the post-install checksetup.pl scrīpt, which locks down your installation.
Lastly, you'll need to set up a symbolic link to /usr/bonsaitools/bin/perl for the correct location of your Perl executable (probably /usr/bin/perl). Otherwise you must hack all the .cgi files to change where they look for Perl. This can be done using the following Perl one-liner, but I suggest using the symlink approach to avoid upgrade hassles.
Change /usr/bin/perl to match the location of Perl on your machine.perl -pi -e
's@#\!/usr/bonsaitools/bin/perl@#\!/usr/bin/perl@' *cgi *pl Bug.pm
processmail syncshadowdb4.1.8. Setting Up the MySQL Database
After you've gotten all the software installed and working you're ready to start preparing the database for its life as the back end to a high quality bug tracker.
First, you'll want to fix MySQL permissions to allow access from Bugzilla. For the purpose of this Installation section, the Bugzilla username will be "bugs", and will have minimal permissions.
Begin by giving the MySQL root user a password. MySQL passwords are limited to 16 characters.
From this point on, if you need to access MySQL as the MySQL root user, you will need to use mysql -u root -p and enter <new_password>. Remember that MySQL user names have nothing to do with Unix user names (login names).bash# mysql -u root mysql mysql> UPDATE user SET Password=PASSWORD('<new_password'>) WHERE user='root'; mysql> FLUSH PRIVILEGES; Next, we use an SQL GRANT command to create a "bugs" user, and grant sufficient permissions for checksetup.pl, which we'll use later, to work its magic. This also restricts the "bugs" user to operations within a database called "bugs", and only allows the account to connect from "localhost". Modify it to reflect your setup if you will be connecting from another machine or as a different user.
Remember to set <bugs_password> to some unique password.
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,INDEX, ALTER,CREATE,DROP,REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY '<bugs_password>'; mysql> FLUSH PRIVILEGES; If you are using MySQL 4, the bugs user also needs to be granted the LOCK TABLES and CREATE TEMPORARY TABLES permissions.
4.1.9. checksetup.pl
Next, run the magic checksetup.pl scrīpt. (Many thanks to Holger Schurig for writing this scrīpt!) This scrīpt is designed to make sure your MySQL database and other configuration options are consistent with the Bugzilla CGI files. It will make sure Bugzilla files and directories have reasonable permissions, set up the data directory, and create all the MySQL tables.
The first time you run it, it will create a file called localconfig.bash# ./checksetup.pl This file contains a variety of settings you may need to tweak including how Bugzilla should connect to the MySQL database.
The connection settings include:
server's host: just use "localhost" if the MySQL server is local
database name: "bugs" if you're following these directions
MySQL username: "bugs" if you're following these directions
Password for the "bugs" MySQL account; (<bugs_password>) above
Once you are happy with the settings, su to the user your web server runs as, and re-run checksetup.pl. (Note: on some security-conscious systems, you may need to change the login shell for the webserver account before you can do this.) On this second run, it will create the database and an administrator account for which you will be prompted to provide information.
The checksetup.pl scrīpt is designed so that you can run it at any time without causing harm. You should run it after any upgrade to Bugzilla.
4.1.10. Configuring Bugzilla
You should run through the parameters on the Edit Parameters page (link in the footer) and set them all to appropriate values. They key parameters are documented in Section 5.1.
-
想当测试人，你具备这些知识吗？
2007-11-20
-
性能测试--好文章多学学
2007-11-20
摘要】性能测试不只是测试人员的事情，只有通过不同阶段不同参与人的通力合作才能把性能测试做好。【关键词】性能测试性能优化 DBA
随着项目越来越大，性能问题层出不穷。如何做好性能测试成为测试人员经常讨论的话题。很多时候，大家都在疑惑性能测试如何来做，性能标准从那里来，有没有通用的标准，性能测试由谁来做，如何规划。首先我们了解一下，什么是性能测试。性能测试的目的：通过性能测试了解系统的性能有没有满足需求，对于不满足需求的模块则通过测试发现可能的性能瓶颈，并进行相应的性能调优，从而达到最终用户的要求。由于项目巨大，所以性能测试不仅仅是测试人员的事情，可能需要整个项目组的参与，而测试人员则更需要清晰的了解到性能测试分几个阶段，每个阶段如何来做，需要协调那些资源？
在性能测试的每一个阶段，性能测试的参与人是不一样的，下面的图就是不同阶段的人员参与表。
性能测试人员图
从上图中可以看出，其实性能测试不是一个人可以搞定的事情，在需求阶段，制定性能初步的标准则需要需求人员的协助，了解那些场景是重要的，大约有多少人用，有多大数据量；而在设计场景时不仅要从需求中设计出必需要测试的场景，有时候需要通过功能测试人员了解，他们在测试过程中那些场景运行的比较慢。而运行脚本时，则需要SA（System Administrator系统管理员，编者注）,程序员帮你增加分析所需要的性能指标，而DBA（DataBase Administrator数据库管理员，编者注）则增加数据库监控的参数。在分析结果的阶段则需要三者相互灵活的配合，当发现性能问题时，可能会根据程序员或DBA的要求，不断的调整监控的参数，以便更精确的定位问题。而在优化阶段，则是找出性能的瓶颈并优化，更需要多方的配合，不仅仅是测试。
在性能测试前期，也就是上图的前三个阶段，重点需要了解，系统有那一些重要的功能模块，大约的用户是多少，用户的行为是如何分布的，每个模块的使用频度，大约的数据量，使用什么样的硬件，系统稳定性的要求等等。当然需求人员不是专业的测试人员，这时专业性能测试人员就是跟据需求人员大致的描述或是文档，提取出这些重要信息，建立系统模型。下面的一份表就是某个大型系统邮件模块的数据模型：
序号
分类
项目
数据
单位
1
统计数据及经验数据
A:总用户数
5,000,000
个
2
B:激活用户比例，每天访问用户数点总用户数的比例
60%
3
C:每个激活用户邮件数
50
封
4
D:每个用户每天收到信数
8
封
5
E:每个用户每天发送信数
6
封
6
F:系统高峰时间(小时)
4
小时
7
G:高峰时间内收发的邮件数占一天总邮件数
50%
8
H:每个用户每天收发件次数
6
次
9
J:每封邮件大小平均为(K)
30
Kbyte
10
K1:据统计，使用WEBMAIL的用户数百分比：
70%
11
K2:使用邮件客户端软件的用户数百分比：
28%
12
K3:使用IMAP用户数百分比：
2%
13
L:平均每通过web访问一封信，大约要访问页面数为:
4
个
14
M:假定每个页面大小约为
30
Kbyte
15
N:通过本系统向外转送百分比
75%
16
O:发送给本系统的邮件百比分
25%
17
Q:系统峰值时CPU利用率
60%
18
19
处理能力计算
POP的处理能力=A*K2*B*D*G/(F*3600)
52.78
封/秒
20
POP流出系统量＝（POP的处理能力*J)
1.58
Mbyte/s
21
HTTP的收信件处理能力=A*K1*B*D*G/(F*3600)
83
封/秒
22
HTTP的发信件处理能力=A*K1*B*D*G/(F*3600)
62.5
封/秒
23
HTTP流出系统量（平均页面大小*页面数* HTTP处理能力)
9.96
Mbyte/s
24
HTTP流入系统量（HTTP发信数*J)
1.88
Mbyte/s
25
SMTPIN(从其它系统收到邮件）=A*K2*B*D*G/(F*3600)
52.78
封/秒
26
SMTPCLIENT(客户端发送系统)=A*B*E*G/(F*3600)
104.17
封/秒
27
SMTPOUT(发送到其它系统）=A*B*E*G*N/(F*3600)
78
封/秒