-
字体变化
2007-12-20 11:29:49
-
状态栏显示字体
2007-12-20 11:13:17
-
测试用例题目总结
2007-11-29 16:19:51
-
TestLink
2007-11-26 11:57:02
以下属于本人摘录内容：
使用 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 19:05:08
-
step -by -step install bugzilla
2007-11-21 17:15:42
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 17:39:38
-
性能测试--好文章多学学
2007-11-20 17:13:38
摘要】性能测试不只是测试人员的事情，只有通过不同阶段不同参与人的通力合作才能把性能测试做好。【关键词】性能测试性能优化 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
封/秒
28
SMTP平均发信（SMTPIN+SMTPCLIENT+SMTPOUT)
134
封/秒
29
SMTP流入量=(SMTPIN+SMTPCLIENT)*J
4.68
Mbyte/s
30
SMTP流出量=(SMTPOUT*J)
2.03
Mbyte/s
31
高峰时期邮件平均流入量
6.56
Mbyte/s
32
高峰时期邮件平均流出量
13.57
Mbyte/s
33
高峰时期邮件平均总流量
20.13
Mbyte/s
34
系统带宽要求（流量×8(含协议数据))
160
Mbit/s
35
36
并发数计算
POP高峰并发数目=A*K2 * B*H*G/(F*3600) 次/秒
39.58
次/秒
37
SMTP高峰并发数目=A*B*(D+E)*G/(F*3600) 次/秒
183.06
次/秒
38
HTTP高峰并发数目=A*B* (D+E)*K*L*G*O/(F*3600)次/秒
145
次/秒
39
IMAP高峰并发数目=A*D*K3*B*I*G/(F*3600)次/秒
0.35
次/秒
某模块数据模型图
上表中可以分析出此邮件系统中最主要的应用是webmail,smtp,pop，其中webmail方式大约为活跃用户的70%,而其它方式则占30%,同时它还给出了平时的参数指标，与峰值的时间与指标。这样你后面的场景设计则重点会很清楚，三种方式是测试的重点，用户的分布也很清晰。从上表中还可以看出，此场景的需求人员做了大量的细致的性能分析工作，在国内这样专业的需求人员不是很多，有时候只能靠性能测试人员不断的沟通来获得必要的性能信息，同时在这个阶段也最好与有经验的架构师多沟通，了解系统可能存在的性能瓶颈，以便使自己设计的场景更有针对性。
场景设计完成之后就进入了脚本的编写，在这个阶段，主要是性能测试人员的程序能力。在这一方面，测试工具是比较多的，我所熟知的就有ACT，WAS，LoadRunner等工具。从原理看，其实都是一样的，不过如果是测试复合协议的应用，LoadRunner 则是首选，特别是在几个协议同时使用的应用，比如类似于QQ这样的应用可能会用到多个协议来进行录制。其实在录制脚本的第三个阶段也是需要跟程序员配合的，比如在录制web应用程序中，对session,cookie的处理，对业务上一些请求的处理,这些都需要程序员协助，同时他们也能够帮你确认某一阶段，用什么样的技术，选什么样的协议，从而帮助你更好的编写模拟应用场景的脚本，在这里测试人员经常会认为只要掌握了工具就行了，其实在这里需要很好的编程功底,希望大家多多关注这些脚本的编程，而不是用一两个工具。
脚本的运行与监控，还有分析结果也是重中之重，在运行时，可能会跟据不同的应用选择监控的参数，比如在程序运行中，是否有大量的IO读写，网络交互，或是线程切换，在数据库，是不是有大量的逻辑读写的操作，或是执行频度特别高的SQL执行，这些有可能你是了解的，但是如果身边有DBA的专家，与架构师，他们会更了解应用程序的性能瓶颈，会需要一些有效的监控指标，这时你在选择性能监控指标时，要多听他们的意见。特别是发现性能问题时，可能需要程序员与DBA参与进来时，再次运行场景时，更需要增加一些他们认为可能出问题的监控指标。当然作为测试人员也要了解，这些指标的异常，可能是由于应用程序那一方面不合理的，为研发提出合理的意见。
发现问题后就是tuning ,这也是性能测试最终的目的，发现性能问题，并进行解决。前面的几个阶段，可能是只定性的发现问题，而如可精准的发现问题，则需要扎实的编程功底。对于代码的tuning有如下原则，发现占用时间最长的函数，而不是优化性能不合理的函数。在对代码的tuning中，你可以借助代码分析工具，下面就是IBM-Quantify执行后的图：
Purify的分析图
可能大家使用这个工具时会觉的晕，其实我第一次用时也晕的N次，其实用多了很简单的，工具都是相通的，在这里只要把握程序的脉络，就好像庖丁解牛，最主要是关注程序占用时间最长的函数和调用次数最多的函数，只有对这样的函数进行优化才能事半功倍，而一些程序员往往喜欢优化算法不合理的函数，费了九牛二虎之力，却发现效果并不是很好。在这一阶段经常会碰到以下一些情况：
- 程序调用数据库接口函数时发现时间过长；
- 初始化一些事务的次数过多；
- 某一些函数调用次数过多；
- 有一些不应当出现的异常函数出现。
对于上面的第一种情况，一般是数据库可能是某一些SQL的效率不高，你可以与有经验的DBA把这段应用的SQL取出来，进行分析，确认一下是不是数据库的问题。其实在优化的过程中，数据库的优化是最简单的，不需要修改任何程序，而且效果往往是最好的。第二种情况，一般最大的可能是程序员把事务写在了循环的里面，造成了N多次的重复对事务的构建，众所周知分布式事务的构建是最消耗性能的，所以一般不要放在循环的里面。对于第三种情况可能性就更多了，调用次数多不代表错误，但如果性能因此大受影响，则是不被提倡的。第四种情况，就可能是一些什么不合理的异常出现所导致的，可能就是缺陷。在这个阶段由于要阅读成千上万的代码，即使你的能力超强，也是不可能完全了解了，所以当发现可疑的代码时，应与当事人一起去剖析这段代码，要耐心的分析每一种可能。有时候，这个活比技术还难做，如何在不伤到别人情感的情况下给别人指出错误，这可是测试人员最大的挑战，从技术上，到人的心理都要有所把握。虽然这一阶段难度比较高，但看到产品经过自己的努力，越来越快时，你会感到无限的成就感。
最后只想再说一下，性能测试是一个团队的事情，不是某一种角色可以完全承担的，测试人员在每一个阶段要善于借用团队的力量，协调着做，同时也要不断提升自己的技术，只有不断的努力，帮助研发成功，才能得到在大家的尊重。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
-
软件测试斗志昂扬，多看几遍！
2007-11-20 16:55:09
-
你属于哪一类测试人，今后的路该怎样走？？
2007-11-20 15:46:47
转载：来自51testing
自从本人从事软件测试培训以来，接触了太多的软件测试工程师；发觉从业者多数存在以下现象：
——刚刚毕业，踏入IT行业，不懂开发或开发经验薄弱，被迫或“亚被迫”从事软件测试工作；这心哪，瓦凉瓦凉的，一是根本不懂这工作是干嘛的，二是这工作不被很多公司重视，于是唏嘘的心里留下一声声叹息，蹒跚的人生步履留下一串串疑问…
——从事软件测试工作2年以上，由于公司不正规的测试流程，不标准的测试方法，因此，终日碌碌无为的点击按钮，某日拍脑袋突发奇想，测试出来一个bug，于是兴奋焉…终后没有新思路，于是没有发现新bug，于是不再兴奋；于是这两三年来，无论测试经验，还是测试技术、方法，包括理论，都无长进，于是郁闷甚至极度懊恼这几年来究竟做了些什么，明天又该何去何从呢？仰天长啸，却无语对穹苍….
——有过若干年开发经验，也许由于疲惫于终日编码，也许感觉软件测试是个朝阳领域，于是转做测试…但是好景不长，兴奋度持续一段时间，感觉自己的想法和思维方式与现实工作模式严重分歧，所谓天妒英才，空有一身本领，竟无用武之地！于是满腹的经纶化作无言的泪水，内心的豪情壮志也逐渐泯灭！接着开始逐渐适应了眼前的这份高级测试工程师的头衔和薪水，觉得干工作就是那么回事，何必计较那么多？虽未清晰构建余下二三十年的职业蓝图，但是也觉得起码自己比起很多同行，还算不赖；时间如流水般在烟圈与香水中消逝，吾生就是这样终日撞钟，铛——铛——铛——（好响！斑竹，猪头切一半给我，堵耳朵！）…
如果您作为一名测试工程师，看了上述三种状况，感觉自己不属于任何一种，那么只有两种可能：一是您是超级高手——您聪明绝顶，有着可以大展宏图的工作机会，又有满意的薪资，而且对这一行业无限热爱…反正对您来说，一切都太完美了，无懈可击！二呢，也许您是个漠视一切、目空一切的家伙，天塌下来当被盖的那种，反正什么言论对您都无懈可击！为此，本人建议此两种人不看本文，以免互相拍砖，破坏安定团结的大好局面^-^。
好啦，气氛活跃至此止，以下是严肃话题。
如果您是个积极进取、想在年轻时成就一番事业的人，那么请绝对相信这几句话：
——行行出状元！
——人生能有几回搏！
——错过这村，就没这店了！
为此，有必要说明下这几句俗语在软件测试行业的应用。首先，我们国内的很多软件测试从业者，是对软件开发不太擅长，但是又对软件行业又由衷的热爱，所以做了软件测试。但苦于读书时候没有学习过该方面知识，公司里又不一定有经验丰富的人员给予指导；因此，初涉软件测试的年轻朋友，大多做了半年、一年，感觉自身技能提高并不大，再加上整体行业发展缓慢，和网上的同行一交流，更是感觉软件测试没有希望，自己的前途黯淡无光！无奈只好终日吟唱“我的天是灰色，我的心是蓝色…”常言道，“男怕选错行，女怕嫁错郎！”——当然如今男女平等了，尤其软件测试从业者，男女比例基本上还算对等——那么，是不是软件测试行业真的没前途？软件测试工程师真是低人一等呢？当然不是，而且绝对不是！和软件开发领域相比，测试发展不过短短的10来年，而且主要是近三五年，所以整体行业不成熟也就情有可原。但是换句话说，乱世出英雄！如果你学软件开发，你知道作为一名合格开发工程师需要学习什么，知道开发工程师的待遇如何，知道开发工程发展前景如何；但是测试行业还没有发展到让你足够看清这些东西的阶段，所以在软件行业中对于喜欢挑战性职业的人，那么软件测试绝对是个好的突破口。各种统计数据表明，国内软件测试的人才缺口，未来几年将达到30到40万，所以对于朋友们来说，干这行还是有相当大的发展空间！但是，如何在众多的从业者中独树一帜、成为行业状元呢？这就需要技巧了！
再说第二方面。记得有句歌词叫“无怨无悔我走我路，走不尽天涯路…”！如今这个年代，各行各业竞争都很激烈，很难再有90年代初猛然蹦出一批暴发户的机会；因此，不管你因为什么选择了软件测试行业，都要无悔的走下去，只要有决心和毅力，终会成就正果！网上有篇文章叫《不做浮躁的人》，说的很好，我想我们确实该脚踏实地的做些事情，提高自己。抱怨这个行业只会让心情更加压抑，投入的做些具体的事情，待到自己有足够能力的时候，那么你就是推动这个行业发展的先驱；如此一举多得的事情，干吗不做呢！做踏实的人，不做抱怨的人，就算我们改变不了这个世界，也不要在这个世界里迷失自我。换句话说，年轻时候不卖力做点事情，老来方悔则一切晚矣，回首这一生，碌碌无为，可怜、可叹…这也是我要说的“人生能有几回博”。
唱了这么多高调，鼓舞一下大家的气势。那么，究竟如何在国内的软件测试行业现状下找到一条适合自己发展、并能快速提高职业技能的捷径呢？
我想应该从测试工程师的职业生涯定位谈起。从宏观意义讲，软件测试可以划分为以下三个方面：
- 软件测试管理：测试流程管理、测试职业管理，测试技能方法管理等。
- 软件测试技术方法：根据软件测试的不同阶段周期、不同测试类型、不同软件类型等，深入研究软件测试的技术及方法。
- 软件测试自动化：自动化测试流程、自动化测试管理、自动化测试工具等。
软件测试大致分为以上三类，每类可细化为更多子方面，例如第二类根据测试类型还可细化为功能测试、性能测试、安全测试等，根据测试方法可细化为黑盒测试、白盒测试、灰盒测试等。因此，软件测试工程师的职业发展方向，也大致可以如此粗略分类，并逐渐细化。这里，之所以将软件测试自动化单独列出来，是考虑到软件测试自动化既包括技术方法方面，又包含管理方面；更重要的是，软件测试自动化是软件测试领域无法逾越的发展阶段，随着应用软件程序规模的不断扩大，业务逻辑的不断复杂，以及从业者相互协作关系的日益重要，在软件的测试活动里适当使用自动化测试是非常必要的；并且，这种思维已经逐渐在国内外众多软件企业的测试领导者头脑中定型，他们也都意识到自动化测试的种种优势，并都或多或少希望购买和培训自动化测试工具。我们接触的很多大中型软件公司，包括外企，甚至早就在内部实施自动化测试，其中以使用mercury loadrunner、quicktestpro以及testdirector等工具的企业用户居多。
这里我想对喜欢自动化测试或立志成为自动化测试工程师的同行朋友说点个人想法，并结合mercury自动化测试工具，推荐些许学习方法，以供大家参考。
- 如果你有过开发经验，哪怕一点点，并且一直以来从事的是功能测试工作，那么推荐你学习自动化功能测试工具，并在此方面深入研究下去。该职位待遇一般是本地城市手工测试工程师的两倍左右，如果到达高级自动化测试工程师职位，从事自动化测试设计或测试框架的开发，待遇会更高。Mercury公司的winrunner和quicktestpro，是目前最主流的自动化功能测试工具，学习二者的方法也很简单，只要懂得c语言和VBscrīpt即可。要深入学习，当然还要熟悉自动化功能测试的流程、管理及深层开发（包括测试框架、库函数等）。当前国内的应用软件开发，主流还是c/s与b/s两种架构，前者一般采用vb、vc、delphi、pb或java等开发，而winrunner工具对此类软件支持得比较好，很适合在这样的软件测试活动中采用自动化测试；后者一般是采用.net或j2ee技术开发的基于浏览器类软件，测试该类软件就非quicktestpro莫属了，它是mercury公司专门针对web程序的自动化测试工具。由于自动化功能测试工具品牌多，入门简单，因此，也是众多立志成为自动化测试工程师的首选。
- 作为一名软件测试从业者，我们知道执行性能测试，使用手工方式是无法想象的，因此借助工具来实现是非常必要的。目前业内存在两种现状：一是很多公司为了节约购买工具的成本或本身不要求软件性能指标而干脆不执行性能测试；二是由于性能测试是一门博大精深的技术工作，起步较高，因此这方面的高手不多，造成很多大中型软件企业或外企严重缺乏性能测试工程师！性能测试工程师待遇，一般是本地手工测试工程师的三倍甚至更多；我们接触的企业客户需求里，很多开价上万的性能测试工程师职位，竟然很难招到。随着软件开发技术越来越高深，业务逻辑越来越复杂，对软件的质量要求同样也会越来越高，软件一定会存在性能缺陷，因此对软件的性能要求也会随之而来；况且，软件的性能指标是软件用户手册里的重要组成部分，从正规测试流程上来说，凡是网络应用软件，不可不做性能测试！但是，从事性能测试的工程师，需要掌握太多的知识，包括计算机网络、数据库、操作系统、服务器等，而且还要有深厚的性能测试计划、设计、分析能力，以及丰富的性能测试经验，这些如果单靠个人的自行摸索，肯定是不太实际的。Mercury公司的loadrunner，是目前国际上性能测试工具的绝对领导者，具有百分之75的市场占有率；在国内，业界同行也都是提起性能测试首先想到loadrunner；因此loadrunner是在软件测试领域里立志成为一名合格的、优秀的性能测试工程师的朋友们的绝对首选。
- 如果你从来没有过软件开发经验，一直从事的只是手工测试，而且对软件测试的流程管理有着浓厚的兴趣，尤其对于那些从事测试的姑娘们！testdirector都听说吧？它集测试需求、测试用例、测试执行、软件缺陷管理于一身，将软件测试的整个流程统一管理，并支持异地分布式测试资源管理。和众多的软件测试同行接触，我们愈加发现一个问题，那就是我们很多的业界朋友，缺乏完整的、系统的软件测试知识体系，喜欢满足现状，而不去思考如何更加有效的实施软件测试活动，优化软件测试流程。针对这种现状，学习国外优秀的软件测试流程与管理经验，就理所当然了。而testdirector就是当前市场上最优秀的软件测试流程与资源管理的工具，目前本人还未见过一款测试管理工具集成如此众多功能（当然它的升级版quality center也是mercury公司的）。因此，掌握该款工具的使用，是立志成为软件测试管理者的一个非常必要的方面。
- 其他自动化测试领域，本文暂不讨论，例如白盒测试、特殊类型测试等。
那么，什么是开拓上述三种自动化测试职业的捷径呢？
答案很简单，如果你可以抛开世俗观念，考取mercury认证绝对是捷径！
下面我要向大家论证考取mercury认证的几大理由：
首先，mercury公司是软件质量保证工具开发商中的绝对领导者。下图是美国gartner公司的最新调查结果，位于坐标第一象限最右上角的就是mercury，图中还有其他我们熟知的几个公司，如IBM rational、compuware等，但是mercury长久以来，一直独占着软件测试工具提供商的领先地位，包括很多在华投资成立软件研发基地的外企，他们多数都是使用mercury测试工具。如果有了这个测试工具供应商的王者，那么，想要学习自动化测试工具，有什么理由不选择mercury呢？
其次，拿本人经验来说，有了mercury工具的使用经验，即便将来所在公司不使用该款工具，那么再学习其他的工具也会相当顺手，不费吹灰之力！为什么呢？举例来说，比如loadrunner的网络协议是本人所接触的性能测试工具中，支持最多的（相信很多人会同意我这个观点），如果将来你打算换用webload、silkperformer（当然它们的局限性要比loadrunner大的多）等性能测试工具，绝对不会比loadrunner还复杂；再比如拿quicktestpro和其他针对web程序的测试工具（如qawizard、XDE Tester等）相比，使用更是完全类似（不了解的人可以到本人blog查看我的文章去亲自对比）。至于testdirector，更是独一无二的功能强大的测试管理工具，没的选择！
再次，如果你的眼光足够长远，能够看清未来软件测试中自动化测试的重要地位，那么你更应该选择。回想当年的思科认证，刚刚推出时候价格昂贵，但是依然有那么多的人去考。为什么呢？因为有大量的需求！认证通过的人过后都认为这笔投入值得！类比软件测试行业，虽然现在还没到达计算机网络行业发展的那样成熟，但是未来的两三年后，如果有一天到处都是自动化测试的人才需求，到时再临时抱佛脚，相信你不会有什么优势了。任何认证都是初期最有价值的，如果抓住机会在推广初期考取，等到这个认证普遍到一定程度，你已经有了几年的实用经验，所以优势仍在、风采依然！顺便提醒一句，计算机行业发展是相当快的，回首过去这3年，软件测试行业一直是在飞速前进的。如果错过如今这段大好时光，没有及时为自己充电，那么如今你这位软件测试新手，到了3年以后，依然是新手，只是比那时刚毕业的热血青年显得沧桑了一些… 所谓岁月不等人咧，这也是我前边要说的“过了这村就没这店啦”…
然后，我要说明为什么要考取mercury认证，而不考其他认证。理由很简单，本人一直坚定的认为软件测试是实用性学科，是实践性工作，重理论而不强调理论，不断实践同时积累经验，遵守规范并不断创新！如果你为了眼前一个工作机会而花点小钱，获得一个什么机构颁发的资格认证，尤其那种完全理论性的、满篇题目都是“负载测试与压力测试什么区别”之类的恶心至极的题目的考试，那么恕我直言，你真是鼠目寸光！试问这样的认证有什么用呢？哪个企业的老板会笨到雇用一个纸上谈兵的军师呢？况且你这个军师也是“墙上芦苇，嘴尖皮厚腹中空”！坦诚的说一句，为了应付这样的考试花2个星期背那些题目，都不如下载个试用版loadrunner，对照网上的使用手册练习一下工具的使用！
最后，我要说一个实际的问题，那就是money了。相比当年的思科认证、微软认证的上万元报名费，mercury认证的三千多、六千多，还是相当便宜的。最直白的说一句，如果你的眼下薪资有3k，花一个月或两过月的薪水买个“国际认证”，那么这件事绝对值得！当然，考取mercury认证的真正核心价值，完全是顺应软件测试自动化的时代潮流，掌握最先进的软件测试自动化技术和管理方法。
最最后，再为有志于考取mercury认证的同行朋友给予一点点建议。
- 如果你是初涉软件测试行业的测试工程师，没有或很少接触过自动化测试，那么可以从mercury认证的CPE（certification product education）开始，该认证是mercury认证的汉化版，通过者可以掌握mercury认证工具的完全使用。
- 如果你具有了3个月以上的mercury工具使用经验，英文能力还不错，或者通过了CPE考试，那么可以直接考取CPS(certification product specialist)，之后考取CPC(certification product consultant)。这两种考试都是英文，证书由美国mercury总部颁发，后者价值大于前者，考试难度也大于前者。并且，二者认证已经不限于工具本身的使用，而是结合了代表mercury公司作为软件测试行业龙头地位的先进、正规的自动化测试流程，其通过者也相当受大中型软件公司、尤其外企的青睐，当然这一需求也是我们在长期积累的企业客户关系中总结出来的。
- 详细mercury认证咨询，请登陆www.51testing.com查阅。
送上最后一句至理名言，“命运掌握在自己的手中”！如果你对一件事物犹豫不决的时候，那么请尝试学习《卡耐基成功之道》里介绍的方法，在纸上分别写下做此事的理由与不做此事的理由，如果此事的可行性是百分之五十一，那么就别再踌躇了，放心大胆的去做吧！时间会证实一切，因为你的确在进行着一件该行业前所未有的划时代式活动；记住，上帝宠爱勤奋的孩子，他会与你并行….（
-
TD测试工具
2007-11-20 15:26:23
-
bugzilla测试工具
2007-11-20 15:09:13
Bugzilla操作说明
1、 用户登录及设置
1.1用户登录
1． 用户输入服务器地址 http://IP/bugzilla/index.cgi 。
2． 进入主页面后，点击【Log in to an existing account】，再点击【login in】进入。
3． 进入注册页面，输入用户名和密码即可登录。用户名为Email 地址，初始密码为用户名缩写。登录后自动进入查询页面。
4． 如忘记密码，输入用户名,点击【submit request】,根据收到的邮件进行重新设置。
1.2、修改密码及设置
1．Login登录后，【Edit prefs】->【accout settings】 进行密码修改。
2．【Edit prefs】->【email settings】 进行邮件设置。
3．【Edit prefs】-> 【permissions】 进行权限查询
2、Bug的处理过程
2.1、报告Bug
2.1.1测试人员报告Bug
1． 请先进行查询，确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主，让bug的属主看到这个而自己去修改。
2． 若Bug不存在，创建一份有效的bug报告后进行提交。
3． 操作：点击New，选择产品后，填写下表。
4． 填表注意：Assigned to: 为空则默认为设定的 owner, 也可手工制定。CC: 可为多人，需用"，"隔开。Desription中要详细说明下列情况：
1） 发现问题的步骤
2） 执行上述步骤后出现的情况
3） 期望应出现的正确结果
选择group设置限定此bug对组的权限，若为空，则为公开。
5. 操作结果：Bug状态（status）可以选择Initial state 为New或Unconfirmed.
系统将自动通过Email通知项目组长或直接通知开发者。
6．帮助： Bug writing guidelines
2.1.2 开发人员报告Bug.
1. 具体方法同测试人员报告。
2. 区别： Bug初始状态将自动设为Unconfirmed，待测试人员确定后变为“New".
2.2、Bug的不同处理情况
2.2.1 Bug的属主 (owner) 处理问题后，提出解决意见及方法。
1 . 给出解决方法并填写Additional Comments，还可创建附件（如：更改提交单）
2．具体操作（填表项如下）
3 . 填表注意：
FIXED 描述的问题已经修改
INVALID 描述的问题不是一个bug (输入错误后，通过此项来取消)
WONTFIX 描述的问题将永远不会被修复。
LATER 描述的问题将不会在产品的这个版本中解决.
DUPLICATE 描述的问题是一个存在的bug的复件。
WORKSFORME 所有要重新产生这个bug的企图是无效的。如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。
2.2.2 项目组长或开发者重新指定Bug的属主。（owner）
1． 为此bug不属于自己的范围，可置为 Assigned,等待测试人员重新指定。
2． 为此bug不属于自己的范围，但知道谁应该负责，直接输入被指定人的Email， 进行Ressigned。
3. 操作：（可选项如下）
* Accept bug (change status to ASSIGNED)
* Reassign bug to
* Reassign bug to owner and QA contact of selected component
4． 操作结果：此时bug状态又变为New，此bug的owner变为被指定的人。
2.2.3测试人员验证已修改的 Bug.
1． 测试人员查询开发者已修改的bug，即Status为"Resolved",Resolution为"Fixed".进行重新测试。（可创建test case附件）
2． 经验证无误后，修改Resolution为VERIFIED。待整个产品发布后，修改为CLOSED。
若还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
3． 具体操作（可选择项）
1. Leave as RESOLVED FIXED
2. Reopen bug
3. Mark bug as VERIFIED
4. Mark bug as CLOSED
2.2.4 Bug报告者（reporter）或其他有权限的用户修改及补充Bug
可以修改Bug的各项内容。
可以增加建立附件，增加了相关性, 并加一些评论来解释你正在做些什么和你为什么做。
操作结果：每当一些人修改了bug报告或加了一个评论，他们将会被加到CC列表中，bug 报告中的改变会显在要发给属主、写报告者和CC列表中的人的电子邮件中。
2.2.5测试人员确认开发人员报告的Bug是否存在.
查询状态为“Unconfirmed"的Bug,
测试人员对开发人员提交的Bug进行确认，确认Bug存在。
具体操作：选中“Confirm bug(change status to New)"后，进行commit.
操作结果：状态变为“New".
2.3、查询Bug
1．直接输入Bug Id，点击find 查询。可以查看Bug的活动纪录。
2．点击Query，输入条件进行查询。
3．查询Bug活动的历史
4．产生报表。
5．帮助：点击Clue.3、关于权限的说明
1． 组内成员对bug具有查询的权利,但不能进行修改。
2． Bug的owner 和 reporter 具有修改的权利。
3． 具有特殊权限的用户具有修改的权利。
4、 BUG处理流程
1． 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。
2． 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
3． 开发者收到Email信息后，判断是否为自己的修改范围.
1） 若不是,重新reassigned分配给项目组长或应该分配的开发者。
2） 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）
4． 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）
1） 经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED。
2） 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
5． 如果这个BUG一周内一直没被处理过。Bugzilla就会一直用email骚扰它的属主，直到采取行动。
Bugzilla管理员操作指南
主要工作内容：
1． 产品（Product）、版本号(versions)和模块(Components)的定义，同时指定模块相应的开发者(owner)和测试人员(QA Contact)。
2． 小组的定义和划分
3． 测试中Bug严重程度、优先级的定义
4． 增加用户，并分别设定全部用户的分组、权限。
5． 主要参数（parameters）的设置
1） urlbase: 输入bugzilla 工具所在的服务器IP地址。
2） usebuggroupsentry: 设为ON,可以分组。
3） whinedays：Bug在whinedays设定的期限内若未被处理，将自动重发mail，默认为7天。
4） defaultpriority:设定默认的优先级
5） commentonresolve：设为ON，系统将强制要求开发者处理完Bug 后，必须填写修改的内容。
基本操作：
1． 创建默认的管理员用户。
运行checksetup.pl。若不小心删除管理员，重新运行checksetup.pl.
2． 管理用户
1） 增加新用户
点击页面右下角【users】,submit后，出现【Add new user】页面。输入相应输入即可。Login name: 一般为邮件地址，可以设为其他标识。
2） 禁止一个用户
填写Disabled text 输入框即可。
3）修改用户
可以修改用户注册名、密码。
设置权限
QA的权限一般设为: Canconfirm, editbugs
Developer的权限设为: none
分组控制：group
管理group
1． 增加group
edit groupàadd groups (New User Regexp可不填/active 选择则可选)->add
2． 修改group ,submit 即可。
管理Product 和 component
1)增加产品Product
2) 增加组件Component 对应一个owner(进行fixed),QA Contact（确保已fixed）
3) Component Number of Unconfirmed =10000,此产品将选择bug的初始状态（Unconfirmed,New）Bugzilla中的Bug流程图
由word 到 记事本，再复制过来结果成这样子了。。。将就看吧。。
