Monthly Archive 九月 2017

Byadmin

Bugzilla使用手册

Bugzilla 是一个开源的缺陷跟踪系统(Bug-Tracking System),它可以管理软件开发中缺陷的提交(new),修复(resolve),关闭(close)等整个生命周期。

Bugzilla是一个搜集缺陷的数据库。它让用户报告软件的缺陷从而把它们转给合适的开发者。开发者能使用bugzilla保持一个要做事情的优先表,还有时间表和跟踪相关性。不是所有的”bugs”都是软件缺陷。一些数据库中的内容是作为增强的请求(RFE)。一个RFE是一个严重级别字段被设为”enhancement”的”Bug”.人们常说”bug”,实际上意思是Bugzilla中的记录,所以RFEs经常被称作bug。

它能够为你建立一个完善的 Bug 跟踪体系, 包括报告 Bug, 查询 Bug 记录并产生报表,处理解决,管理员系统初始化和设置四部分

 

功能表现

1. 强大的检索功能

2. 用户可配置的通过Email公布Bug变更

3. 历史变更记录

4. 通过跟踪和描述处理Bug

5. 附件管理

6. 完备的产品分类方案和细致的安全策略

7. 安全的审核机制

8. 强大的后端数据库支持

9. Web,Xml,Email和控制界面

10.友好的网络用户界面

11.丰富多样的配置设定

12.版本间向下兼容

 

为什么使用Bugzilla

Bugzilla是一个拥有强大功能的错误跟踪系统。它可以使我们更好的在软件开发过程中跟踪软件错误的处理过程,为开发和测试工作以及产品质量的度量提供数据支持,从而有效的保证软件产品的质量。

 

问题的处理

Bug报告状态分类(Status)

待确认的(Unconfirmed)

新提交的(New)

已分配的(Assigned)

问题未解决的(Reopened)

待返测的(Resolved)

待归档的(Verified)

已归档的(Closed)

Bug处理意见(Resolution)

已修改的(Fixed)

不是问题(Nvalid)

无法修改(Wontfix)

以后版本解决(Later)

保留(Remind)

重复(Duplicate)

无法重现(Worksforme)

指定处理人(Assigned To)

可以指定一个处理人

如不指定处理人,则系统指定管理员为默认处理人

新建一个Bugzilla账号

1.当以个人身份需要访问登陆系统时需要 点击“New Account”链接,输入你的Email地址(如:xxx@xx.com)然后点击“send”。

 要创建一个Bugzilla帐号,所有你需要做的就是输入合法的电子邮件地址。在这个地址,您将收到一封电子邮件,以确认您的帐户的创建。您将无法登录,直到你收到的电子邮件。如果没有一个合理的时间内抵达,您可以联系这个Bugzilla安装在管理员维护者。

2. 稍候,你会收到一封邮件。邮件中包含你的登录账号(与你的Email相同)和口令,这个口令时Bugzilla系统随机生成的,你可以根据你的需要进行变更。

3. 在页面的黄色页角中点击“Log In”链接,而后输入你的账号和口令。最后点击“Log in”

There was an error sending mail from ‘bugzilla-daemon@’ to ‘123@163.com‘: Couldn’t connect to 10.175.75.250

 遇到这样问题首先要看服务器的邮件服务开启没,smtp若没启动请启动

There was an error sending mail from ‘bugzilla-daemon@’ to ‘123@163.com‘: Can’t call method “address” on an undefined value at C:/Perl/site/lib/Email/Send/SMTP.pm line 25.

Email::MIME::CreatorBUGZILLA里自带的有SMTP,只要SMTP能够通过认证就可以了,所以第三方,以及代码什么都不用修改,只要设置params里面的参数就可以了!
在..\data\params设置如下参数:
maintainer :                  123@163.com
mail_delivery_method :         SMTP
mailfrom :                     123@163.com
sendmailnow:                   on
smtpserver :                   smtp.163.com
smtp_username:                 123@163.com
smtp_password :                **********
注意:maintainer、mailfrom必须相同!smtp_username邮箱必须是存在的真实的邮箱,smtp_password必须是你真实邮箱的真实密码(要与你所登陆邮箱时的密码相同)!邮件已经发送成功!如果还有不能连接等问题,只能说明你的邮箱和密码有问题!

 

产品和结构

Bug记录按产品分类,每种产品按功能拆分成几类。以Bugzilla产品为例,它由以下几部分构成:

Administration

Bugzilla-General

Creating/Changing Bug

Documentation

Email

Installation

Query/Buglist

Reporting/Charting

User Accounts

Changing Passwords

User Interface

 

一个Bug的生存周期

 

  1. 1.    用户登录及设置流程:

打开浏览器,输入Bugzilla服务器地址:http://server/bugzilla/

 

进入主页面后,点击【新建帐号】New Account,进入注册页面。

在注册页面中输入E-Mail地址和用户代号,然后,点击【New Account】,随后,你将收到一封包含初始密码的E-Mail。

如图所示:

 

在收到E-Mail之后,点击【登录】,在帐号栏输入注册时使用的E-Mail地址,在密码栏输入邮件里通知的初始密码,然后,点击【Log In】。

如忘记密码,在登陆页面中点击Forgot PassWord,点击【Reset PassWord】,根据收到的邮件进行重新设置密码。

(1)File a Bug (2)Search (3)Open a New Account

一、File a Bug 里面。首先选中一个产品后点击New时增加新的Bug

二、在Search 里面 
Simple Search (简单搜索)选择Product的产品比如testproduct在点Search后可以快速定位到某一个产品的所有的Bug如图所示。

还可以高级搜索Advanced Search 如图所示:

 

一:首先有管理员登录系统 进入系统后进行系统配置

Administrator进入如下图所示

点击各个配置如参数配置Parameters 进入页面后进行配置

1若增加用户则点击Users创建新User 如图所示

在点击Add a New User

如图所示:

禁止一个用户:填写Disabled text 输入框即可

输入用户名和密码后点击保存会进入另一个页面设置一下

Login name:必须是用户的邮箱地址
Password是修改密码,
Bugmail Disabled:表示如果有人提交了新Bug后是否自动向我们的邮箱发送信息 
设置一下是否有这些问题的权限。

Disable text:禁用文本
之后再点击保存ADD。

要创建一个Bugzilla帐号,所有你需要做的就是输入一个合法的地址。在这个地址,您将收到一封电子邮件,以确认您的帐户的创建。您将无法登录,直到您收到。如果没有一个合理的时间内抵达,您可以联系这个Bugzilla安装的维护者

创建成功后页面如图所示:

 

除了第一个admin之外其他的最好全部选中 然后点击save changes

最后出现如图所示界面:

 

① 如果要删除一个账户请在参数配置里面 点击【Index】进入界面后如图所示

然后点击【allowuserdeletion】或者直接点击左侧列表菜单【Administrative Policies】进入页面如图所示:选择ON 后然后点击Save Changes 保存更改。

②    在初次设置时一只设置不成功会出现报错之类的信息:Can’t rename data\params.nhYFB to ./data/params: Permission denied at Bugzilla/Config.pm line 301

③   
这时就需要添加你登陆web server
用户对bugzilla文件夹的所有权限,如果用的是administrator登陆:右键c:\bugzilla—>共享和安全—>安全中勾选administrator的所有权限。如果你设置的超级管理员权限用户登录的而在服务器没有超级管理员权限必须设置users完全控制权限
然后在设置系统参数配置就会成功。

④    这样你在对users用户管理一项时进入设置页面有个search按钮全部查询或者根据条件查询显示出users群组这样后面就会有删除【delete】按钮的权限如图所示:

对超级管理员的切记不要随意删除,对已不存在项目组的普通用户可以删除修改。

点击yes delete 删除用户成功。

 

2、创建项目

Administrator进入后点击Products创建新Products
如图所示:

 

点击Add a Product

—输入产品名称和描述后点击Add 进入详细页面

3、当管理员将所有的配置项目都设置好后就可以发Bug了
发Bug的流程为:
点击首页后—>NEW –>File a Bug–>点击某一个产品比如Test,如图所示

其中Component:为哪一个模块组建。

Component Description:组建描述

Version:为版本。

Product: 产品

Reporter:报告者
serverity代表问题的严重程度

Blocker为最严重的。

Critical严重 死机,丢失数据,内存溢出

Major    较大的功能缺陷

Normal   正常

Minor    较小的功能缺陷

Trivial  细小 拼写、对齐类的错误

enhancement为最轻微的需要改进的。
Hardware硬件。

Os代表操作系统。

输入Summary 摘要和Description 描述后

还可以添加Attachment写上附件的描述后点击提交。一个Bug即提交了。
同时。在我们的邮件里面会马上收到一封邮件。

确定保存后进入下一页面如图所示:

Byadmin

Bugzilla使用指南

什么是Bugzilla 
Bugzilla是一个错误跟踪系统,用于对软件产品程序开发过程的错误跟踪。它的强大功能表现在以下几个方面: 
1.         强大的检索功能 
2.         用户可配置的通过Email公布Bug变更 
3.         历史变更记录 
4.         通过跟踪和描述处理Bug 
5.         附件管理 
6.         完备的产品分类方案和细致的安全策略 
7.         安全的审核机制 
8.         强大的后端数据库支持 
9.         Web,Xml,Email和控制界面 
10.     友好的网络用户界面 
11.     丰富多样的配置设定 
12.     版本间向下兼容 
为什么使用Bugzilla 
Bugzilla是一个拥有强大功能的错误跟踪系统。它可以使我们更好的在软件开发过程中跟踪软件错误的处理过程,为开发和测试工作以及产品质量度量提供数据支持,从而有效的保证软件产品的质量。 
  
Bugzilla使用指南 
新建一个Bugzilla账号 
1.       点击“Open a new Bugzilla a<a href=”http://www.ltesting.net/ceshi/ceshijishu/rjcsgj/rational/%3CSTRONG%3E%3C… http:=”” www.ltesting.net=”” ceshi=”” ceshijishu=”” rjcsgj=”” rational=”” clearcase=”” “=””
target=”_blank” style=”box-sizing: border-box; padding: 0px; margin:
0px; background-color: transparent; text-decoration: none; font-weight:
normal; font-family: ‘Microsoft YaHei’, ‘Microsoft YaHei’; color:
rgb(51, 51, 51); background-position: initial initial;
background-repeat: initial initial; “>clearcase
/” target=”_blank” >ccount”链接,输入你的Email地址(如:XXX@office)然后点击“Create Account”。 
2.       稍候,你会收到一封邮件。邮件中包含你的登录账号(与你的Email相同)和口令,这个口令时Bugzilla系统随机生成的,你可以根据你的需要进行变更。 
3.         在页面的黄色页角中点击“Log In”链接,而后输入你的账号和口令。最后点击“Login” 
产品和结构(Product and Component) 
Bug记录按产品分类,每种产品按功能拆分成几类。以Bugzilla产品为例,它由以下几部分构成: 
l          Administration 
l          Bugzilla-General 
l          Creating/Changing Bug 
l          Documentation 
l          Email 
l          Installation 
l          Query/Buglist 
l          Reporting/Charting 
l          User Accounts 
l          Changing Passwords 
l          User Interface 
Bug报告状态分类和Bug处理意见(Status and Resolution): 
1.       Bug报告状态分类(Status) 
l          待确认的(Unconfirmed) 
l          新提交的(New) 
l          已分配的(Assigned) 
l          问题未解决的(Reopened) 
l          待返测的(Resolved) 
l          待归档的(Verified) 
l          已归档的(Closed) 
2.       Bug处理意见(Resolution) 
l          已修改的(Fixed) 
l          不是问题(Nvalid) 
l          无法修改(Wontfix) 
l          以后版本解决(Later) 
l          保留(Remind) 
l          重复(Duplicate) 
l          无法重现(Worksforme) 
指定处理人(Assigned To) 
l          可以指定一个处理人 
l          如不指定处理人,则系统指定管理员为默认处理人 
超链接(URL) 
l          输入超链接地址,引导处理人找到与报告相关联的信息 
概述(Summary) 
l          概述部分“Summary”的描述,应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。 
l          如果是通用组件部分的测试,则必须将这一通用组件对应的功能名称写入概述中,以便今后查询。 
硬件平台和操作系统(Platform and OS) 
l          测试应用的硬件平台(Platform),通常选择“PC” 
l          测试应用的操作系统平台(OS) 
版本(Version) 
l          产生Bug的软件版本 
Bug报告优先级(Priority) 
l          分五个等级即P1-P5,P1的优先级别最高之后逐级递减 
Bug状态(Severity) 
l          Blocker,阻碍开发和/或测试工作 
l          Critical,死机,丢失数据,内存溢出 
l          Major,较大的功能缺陷 
l          Normal,普通的功能缺陷 
l          Minor,较轻的功能缺陷 
l          Trivial,产品外观上的问题或一些不影响使用的小毛病,如菜单或对话框中的文字拼写或字体问题等等 
l          Enhancement,建议或意见 
报告人(Reporter) 
l          Bug报告提交者的账号 
邮件抄送列表(CC List) 
l          Bug报告抄送对象,该项可以不填 
l          如需要抄送多人,可将邮件地址用“,”分隔 
从属关系(Bug “ID” depends on,Bug “ID” blocks) 
l          “Bug “ID” depends on”如果该Bug必须在其他Bug修改以后才能够修改,则在此项目后填写那个Bug的编号 
l          “Bug “ID” blocks”如果该Bug的存在影响了其他Bug的修改,则在此项目后填写被影响的Bug编号 
附加描述(Additional Comments) 
l          在Bug跟踪过程中测试与开发人员通过这里进行沟通 
l          开发人员可以在这里填写处理意见和处理记录 
l          测试人员可以在这里填写返测意见和对在返测过程中发现的新问题进行描述 
Bug查找 
l          可以通过页脚中的“Query”链接进入查找界面 
l          根据查找的需要在界面中选择对象或输入关键字 
l          查找功能能够进行字符或字串的匹配查找 
l          查找功能具有布尔逻辑检索功能 
l          你可以通过在查找页面中选择“Remember this as my default query”将当前检索页面中设定的项目保存。以后可以从页脚中的My bugs中直接调用这个项目进行检索 
l          你还可以通过在“Remember this query, and name it:”后面输入字符,将你当前检索页面中设定的项目保存命名,同时选中“and put it in my page footer”。则以后这个被命名的检索将出现在页脚中。(有关如何在页脚中设定显示的项目请参见1.5.3) 
Bug列表 
l          如果你运行了Bug检索功能,系统会根据你的需要列出相关的项目 
l          你可以通过列表页脚附近的“Change Columns”设定在列表中显示的Bug记录中的字段名称 
l          如果你拥有必要的权限,你还可以通过“Change several bugs”修改列表中罗列出的Bug的记录。例如:修改Bug的所有者 
l          通过“Send mail to bug owners”你可以给列表中罗列的Bug记录的所有者发信 
l          如果你对查找的结果不满意,希望重新调整检索设定。你可以通过“Edit this query”实现 
l          通常情况下,检索结果中只显示最基本的信息。你可以通过“Long Format”显示更详细的内容 
用户属性设置(Edit prefs) 
1           账号设置(Account Settings) 
l          在这里你可以改变你账号的基本信息,如口令,Email地址,真实姓名 
l          为了安全起见,在此页进行任何更改之前你都必须输入你当前的口令 
l          当你变更了你的Email地址,系统会给你的新老Email地

Byadmin

利用bugzilla提交Bug写作指南

为什么你要读这份指南?
简单地说,如果你报告Bug越有效, 工程师完全修复它的可能性就越大。 

这份Bug写作指南是针对新手在书写有效的Bug报告方面进行指导的常规指南,并非每个建议都正好适用于你的软件项目。   

如何写一份有用的Bug报告?
有用的Bug报告是用于正确修复Bug的。因此一份有用的Bug报告通常地有两个特征: 

可复现:

      如果工程师不能发现或最终证明这一Bug存在,工程师或许会将它标记为 “WORKSFORME( 所有要重新产生这个bug的企图是无效的)”或 ” INVALID(描述的问题不是一个bug ) “,并且继续进行下一个Bug的修复工作。任何你能提供的详尽描述将为工程师修复Bug提供帮助。 

详细精确:

       如果工程师能越早隔离、定位问题,就越可能方便地修复。


        让我们举一个例子:你正在测试一个Web阅览器,在访问foo.com网站时崩溃了,因此你想写一个Bug报告: 

       糟糕的Bug报告:“我的浏览器崩溃了。我正在访问foo.com。我的计算机使用 Windows系统。这真是个大问题,你们应该马上修复它。顺便说一下,你们的图标真恶心,如果你们保留那些丑陋的图标,没有人将再使用你们的软件。还有我的祖母的主页看上去外观也不正确,或者,它们全被搞乱了。祝好运。” 

         有用的Bug报告:“每当我访问foo.com时应用程序就崩溃了,我使用的是在Win NT 4.0 (Service Pack 5) 系统上的 10.28.99版本。 我也曾重新引导进入 Linux,使用10.28.99 Linux版本,这个问题也出现了。我发现每次崩溃都发生在绘制这个页面位于上端的 Foo横幅的时候。我分析了页面,发现除非你删除 ” border =0″属性,否则下列图片链接将导致应用程序崩溃 :(附图片) 

如何在Bugzilla中输入你有用的Bug报告?
       在你输入你发现的Bug前,应使用 Bugzilla查询页检查是否你发现的是已知并被报告的Bug。(如果你发现的Bug同第37条已经知道的结果相同,你报告的话,就可能骚扰工程师,从而影响工程师修复Bug的效率。) 

       下一步,确认你发现的Bug是在最新的版本中所发生的。(工程师更倾向于对那些他们正在编写的代码中的严重问题感兴趣,而不是对以前那些废弃代码中数以百计的Bug进行修复。) 

如果你已经在当前版本中发现了一个新的Bug,请在Bugzilla中报告: 

      从你的Bugzilla主页中,选择“Enter a new bug”。 

       选择你发现Bug的产品。 

Byadmin

使用Bugzilla进行软件缺陷跟踪

软件缺陷跟踪是我们在项目开发中的一个很重要的步骤,特别是在多个人合作的项目中。当项目出现Bug时,软件测试人员可以把他提交到缺陷跟踪系统,指定程序员修改进行修改或者由哪个程序员自己认领这个任务,同时可以跟踪这个Bug的状态等等。如果换一种看法,Bugzilla也可以用作任务管理,那么这里的 Bug就不单单指是缺陷,我们在项目进行中所产生的任何任务都可以使用这个系统进行分配和跟踪。

Bugzilla的安装算不上复杂,但是却足以使人人焦头烂额,究其原因,主要是它所依赖的东西太多了,即要有数据库服务器、HTTP服务器和邮件服务器,还需要perl和十多个perl模块。不过,只要像我这样耐心地一步一步来,最终还是可以解决问题。

第一步,当然是软件的下载了,下面的图片中给出的是下载地址,我选择的是2.20.5版,而不是最新的版本,为什么呢?当然是因为在下载页面看到 2.20版有一个汉化的模版了。使用我们的母语当然可以让我们在工作中更加得心应手。按照下面的地址,下载软件和汉化模版,当然,也别忘了下载一份文档。

软件:

<img title=”点击图片可在新窗口打开” alt=”<STRONG><A href=” http:=”” www.ltesting.net=”” html=”” 2=”” category-catid-2.html”=”” target=”_blank”
style=”box-sizing: border-box; padding: 0px; margin: 0px 0px 10px;
border: none; vertical-align: middle; max-width: 650px; width: 500px;
cursor: pointer; “>软件测试工具,缺陷管理,开源” src=”http://www.51testing.com/ddimg/uploadimg/20090525/01.jpg”>

文档:

汉化模版:

软件测试工具,缺陷管理,开源

这里提供的bugzillaModules-2.20就不用下载了,都是基于Windows系统的,对我们的系统没有帮助。

软件下载完成后,先将bugzilla-2.20.5.tar.gz解压,bugzilla的运行需要Perl的支持,红旗桌面中自带的Perl是
5.8.5版,已经够用了。但是Bugzilla需要的Perl模块红旗系统不可能都具备,因此,第一步就是运行bugzilla中的
checksetup.pl脚本来测试一下我们还缺哪些模块,如下图:

软件测试工具,缺陷管理,开源

该脚本运行完之后,发现红旗桌面缺少大约10个模块,当然,其中必需的只缺四个。如下图:

软件测试工具,缺陷管理,开源

不过为了完美起见,我们还是连可选的包都一起装上。Perl模块有两种安装方式,一种方式的命令行如下:

perl -MCPAN -e ‘ install “模块名” ‘

这种方式将从CPAN的网站上面下载Perl模块并安装。但是,这种方法在我们这里是行不通的,因为红旗桌面上网的速度太慢了,而CPAN网站上面,Perl模块太多了,仅一个列表文件都超过2M,按红旗桌面下载的速度,一个月也不可能把这些模块都安装成功

Byadmin

使用Bugzilla进行软件缺陷跟踪

软件缺陷跟踪是我们在项目开发中的一个很重要的步骤,特别是在多个人合作的项目中。当项目出现Bug时,软件测试人员可以把他提交到缺陷跟踪系统,指定程序员修改进行修改或者由哪个程序员自己认领这个任务,同时可以跟踪这个Bug的状态等等。如果换一种看法,Bugzilla也可以用作任务管理,那么这里的 Bug就不单单指是缺陷,我们在项目进行中所产生的任何任务都可以使用这个系统进行分配和跟踪。

Bugzilla的安装算不上复杂,但是却足以使人人焦头烂额,究其原因,主要是它所依赖的东西太多了,即要有数据库服务器、HTTP服务器和邮件服务器,还需要perl和十多个perl模块。不过,只要像我这样耐心地一步一步来,最终还是可以解决问题。

第一步,当然是软件的下载了,下面的图片中给出的是下载地址,我选择的是2.20.5版,而不是最新的版本,为什么呢?当然是因为在下载页面看到 2.20版有一个汉化的模版了。使用我们的母语当然可以让我们在工作中更加得心应手。按照下面的地址,下载软件和汉化模版,当然,也别忘了下载一份文档。

软件:

<img title=”点击图片可在新窗口打开” alt=”<STRONG><A href=” http:=”” www.ltesting.net=”” html=”” 2=”” category-catid-2.html”=”” target=”_blank”
style=”box-sizing: border-box; padding: 0px; margin: 0px 0px 10px;
border: none; vertical-align: middle; max-width: 650px; width: 500px;
cursor: pointer; “>软件测试工具,缺陷管理,开源” src=”http://www.51testing.com/ddimg/uploadimg/20090525/01.jpg”>

文档:

汉化模版:

软件测试工具,缺陷管理,开源

这里提供的bugzillaModules-2.20就不用下载了,都是基于Windows系统的,对我们的系统没有帮助。

软件下载完成后,先将bugzilla-2.20.5.tar.gz解压,bugzilla的运行需要Perl的支持,红旗桌面中自带的Perl是
5.8.5版,已经够用了。但是Bugzilla需要的Perl模块红旗系统不可能都具备,因此,第一步就是运行bugzilla中的
checksetup.pl脚本来测试一下我们还缺哪些模块,如下图:

软件测试工具,缺陷管理,开源

该脚本运行完之后,发现红旗桌面缺少大约10个模块,当然,其中必需的只缺四个。如下图:

软件测试工具,缺陷管理,开源

不过为了完美起见,我们还是连可选的包都一起装上。Perl模块有两种安装方式,一种方式的命令行如下:

perl -MCPAN -e ‘ install “模块名” ‘

这种方式将从CPAN的网站上面下载Perl模块并安装。但是,这种方法在我们这里是行不通的,因为红旗桌面上网的速度太慢了,而CPAN网站上面,Perl模块太多了,仅一个列表文件都超过2M,按红旗桌面下载的速度,一个月也不可能把这些模块都安装成功。

Byadmin

Bugzilla简明使用手则

1 简介:

Bugzilla是Mozilla公司向我们提供的一个开源的免费缺陷跟踪工具。作为一个产品缺陷的记录及跟踪工具,它能够为你建立一个完善的Bug跟踪体系,包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。并具有如下特点:

基于Web方式,安装简单、运行方便快捷、管理安全

有利于缺陷的清楚传达。本系统使用数据库进行管理,提供全面详尽的报告输入项,产生标准化的Bug报告。提供大量的分析选项和强大的查询匹配能力,能根据各种条件组合进行Bug统计。当错误在它的生命周期中变化时,开发人员、测试人员、及管理人员将及时获得动态的变化信息,允许你获取历史纪录,并在检查错误的状态时参考这一记录。

系统灵活,强大的可配置能力。<a href=”http://www.ltesting.net/ceshi/open/ky%3Ca%20href=” http:=”” www.ltesting.net=”” ceshi=”” ceshijishu=”” qxgl=”” ‘=”” target=”_blank” style=”box-sizing:
border-box; padding: 0px; margin: 0px; background-color: transparent;
text-decoration: none; font-family: ‘Microsoft YaHei’, ‘Microsoft
YaHei’; color: rgb(51, 51, 51); “>bugglgj/bugzilla/’ target=’_blank’>Bugzilla工具可以对软件产品设定不同的模块,并针对不同的模块设定开发人员和测试人员;这样可以实现提交报告时自动发给指定的责任人;并可设定不同的小组。设定不同的用户对Bug记录的操作权限不同,可进行有效的控制管理。允许设定不同的严重程度和优先级,可以在错误的生命期中管理错误,从最初的报告到最后的解决,都有详细的记录,确保了错误不会被忽略,同时,可以让开发人员将注意力集中在优先级和严重程度高的错误上。

自动发送Email通知相关人员。根据设定的不同责任人,自动发送最新的动态信息,有效的帮助测试人员和开发人员进行沟通。

2 Bugzilla操作流程:

2.1 用户登录及设置流程:

打开浏览器,输入Bugzilla服务器地址:http://server/bugzilla/

进入主页面后,点击【新建帐号】,进入注册页面。

在注册页面中输入E-Mail地址和用户代号,然后,点击【Create Account】,随后,你将收到一封包含初始密码的E-Mail。

在收到E-Mail之后,点击【登录】,在帐号栏输入注册时使用的E-Mail地址,在密码栏输入邮件里通知的初始密码,然后,点击【Login】。

如忘记密码,在登陆页面中输入注册用户名,点击【Submit Request】,根据收到的邮件进行重新设置密码。

如果成功登录后,点击【Edit属性】->【帐号设置】,进行密码修改。

点击【Edit属性】->【邮件设置】,进行邮件通知设置。

点击【Edit属性】->【权限】,进行权限查询。

2.2 Bug的处理流程概述:

测试人员或开发人员发现bug后,判断属于哪个模块的问题,填写bug报告后,通过Email通知项目组长或直接通知开发者。

项目组长根据具体情况,重新reassigned分配给bug所属的开发者。

开发者收到E-Mail信息后,判断是否为自己的修改范围。

A. 若不是,重新reassigned分配给项目组长或应该分配的开发者;

B. 若是,进行处理,resolved并给出解决方法。(可创建补丁附件及补充说明);

测试人员查询开发者已修改的bug,进行重新测试。(可创建test case附件)

A. 经验证无误后,修改状态为VERIFIED。待整个产品发布后,修改为CLOSED。

B. 还有问题,REOPENED,状态重新变为“New”,并发邮件通知。

如果这个BUG一周内一直没被处理过。Bugzilla就会一直用E-Mail骚扰它的属主,直到采取行动为止。

2.3 一个Bug的生存周期图示:

2.4 测试人员报告Bug的流程:

请先进行查询,确认要提交的bug报告不会在原有纪录中存在,若已经存在,不要提交,若有什么建议,可在原有纪录中增加注释,告知其属主,让bug的属主看到这个后自己去修改。

若Bug不存在,创建一份有效的bug报告后进行提交。

具体操作:点击【新建】,选择产品后,填写一个Bug报告的表格。填表注意:【指派给】为空则默认为设定的owner, 也可手工制定。【抄送】可为多人,需用逗号隔开。【描述】中要详细说明下列情况:

A. 发现问题的步骤;

B. 执行上述步骤后出现的情况;

C. 期望应出现的正确结果。

【平台】、【操作系统】、【优先级】、【严重级】,可以根据具体情况自行选择。

【依赖】是指与这个新Bug有关联的Bug号码。

【Blocks】不太清楚J

填写完毕之后,点击【Commit】提交,发送邮件通知给相关人员。

2.5 Bug的不同处理状态解释:

Bug的属主(owner)确认并接受这个Bug,然后给出解决方法,并填写【附加说明】,还可以【建立新的附件】(如:更改提交单)等等。

开发人员可以调整的Bug状态如下:

A. FIXED => 描述的问题已经修改;

B. INVALID => 描述的问题不是一个bug (输入错误后,通过此项来取消);

C. WONTFIX => 描述的问题将永远不会被修复;

D. LATER => 描述的问题将不会在产品的这个版本中解决;

E. DUPLICATE => 描述的问题是一个存在的bug的复件;

F. WORKSFORME => 所有要重新产生这个bug的企图是无效的。如果有更多的信息出现,请重新分配这个bug,而现在只把它归档。

测试人员收到Bug的修改通知之后,还可以做如下的调整:

A. Leave as RESOLVED FIXED => 保持FIXED状态不变;

B. Reopen bug => 这个bug还有问题,重新打开;

C. Mark bug as VERIFIED => 这个bug确实被正确修改了;

D. Mark bug as CLOSED => 产品已经发布,将这个bug关闭。

2.6 关于权限的说明:

组内成员对bug具有查询的权利,但不能进行修改。

Bug的owner 和 reporter 具有修改的权利。

具有特殊权限的用户具有修改的权利。

Byadmin

利用bugzilla提交Bug写作指南

为什么你要读这份指南?

简单地说,如果你报告Bug越有效, 工程师完全修复它的可能性就越大。

这份Bug写作指南是针对新手在书写有效的Bug报告方面进行指导的常规指南,并非每个建议都正好适用于你的软件项目。

如何写一份有用的Bug报告?

有用的Bug报告是用于正确修复Bug的。因此一份有用的Bug报告通常地有两个特征:

可复现:

如果工程师不能发现或最终证明这一Bug存在,工程师或许会将它标记为 “WORKSFORME( 所有要重新产生这个bug的企图是无效的)”或 ” INVALID(描述的问题不是一个bug ) “,并且继续进行下一个Bug的修复工作。任何你能提供的详尽描述将为工程师修复Bug提供帮助。

详细精确:

如果工程师能越早隔离、定位问题,就越可能方便地修复。

让我们举一个例子:你正在测试一个Web阅览器,在访问foo.com网站时崩溃了,因此你想写一个Bug报告:

糟糕的Bug报告:“我的浏览器崩溃了。我正在访问foo.com。我的计算机使用 Windows系统。这真是个大问题,你们应该马上修复它。顺便说一下,你们的图标真恶心,如果你们保留那些丑陋的图标,没有人将再使用你们的软件。还有我的祖母的主页看上去外观也不正确,或者,它们全被搞乱了。祝好运。”

有用的Bug报告:“每当我访问foo.com时应用程序就崩溃了,我使用的是在Win NT 4.0 (Service Pack 5) 系统上的 10.28.99版本。 我也曾重新引导进入 Linux,使用10.28.99 Linux版本,这个问题也出现了。我发现每次崩溃都发生在绘制这个页面位于上端的 Foo横幅的时候。我分析了页面,发现除非你删除 ” border =0″属性,否则下列图片链接将导致应用程序崩溃 :(附图片)

如何在<a href=”http://www.ltesting.net/ceshi/open/kybugglgj/%3Ca%20href=” http:=”” www.ltesting.net=”” ceshi=”” open=”” kybugglgj=”” bugzilla=”” ‘=”” target=”_blank”
style=”box-sizing: border-box; padding: 0px; margin: 0px;
background-color: transparent; text-decoration: none; font-family:
‘Microsoft YaHei’, ‘Microsoft YaHei’; color: rgb(51, 51, 51); “>bugzilla/’ target=’_blank’>Bugzilla中输入你有用的Bug报告?

在你输入你发现的Bug前,应使用 Bugzilla查询页检查是否你发现的是已知并被报告的Bug。(如果你发现的Bug同第37条已经知道的结果相同,你报告的话,就可能骚扰工程师,从而影响工程师修复Bug的效率。)

下一步,确认你发现的Bug是在最新的版本中所发生的。(工程师更倾向于对那些他们正在编写的代码中的严重问题感兴趣,而不是对以前那些废弃代码中数以百计的Bug进行修复。)

如果你已经在当前版本中发现了一个新的Bug,请在Bugzilla中报告:

从你的Bugzilla主页中,选择“Enter a new bug”。

选择你发现Bug的产品。

输入你的电子邮件地址、密码,然后按“Login”按钮。(如果你遗忘或还没有得到密码,让密码正文框空白,并且按 ” E-mail me a password “按钮,不久你将收到包含你的密码的电子邮件。)

现在,填写那张出现的表格。以下说明表格中的所有含义:

你在哪儿发现了Bug?

1,产品:在哪一个产品中你发现了Bug? 你在上一页已选择 ,enter前已经选择,

2,版本:在产品的哪一个版本中你找到了Bug?

If applicable.如果有的话。

3,产品单元:在产品的哪一个单元中存在Bug?

Bugzilla在你输入一个Bug时,要求你必须选择一个产品单元。(如果你无法确定所列产品单元的意思,单击产品单元链接,那将联接到对每个产品单元的详细描述,这会帮助你作出最好选择。)

4, 平台:在哪一个硬件平台上你找到了这个Bug?

(例如Macintosh、SGI、Sun、PC。)如果你知道这个Bug会发生在所有硬件平台上,请选择“All”,否则请选择相应的你发现Bug的硬件平台,如果列表中没有出现你的硬件平台,请选择“Other”。

5,OS:在哪一个操作系统(OS)中你找到了这个Bug?

(例如Linux、Windows NT、Mac OS 8.5。)

如果你知道这个Bug会发生在所有OS中,请选择“All”,否则请选择相应的你发现Bug的OS,如果列表中没有出现你的OS,请选择“Other”。

这个Bug有多重要?

1,严重性:这个Bug的破坏性有多大?

这项值默认为“normal”。(要为一个特定的Bug界定最适当的严重性,单击严重性链接,你将得到每个选择的完全解释,从Critical到Enhancement。)

2,谁将跟踪解决Bug?

3,分配给:哪一个工程师将负责修复这个Bug?

在你提交Bug报告后,Bugzilla将自动把Bug分配给默认工程师;填写正文框将允许你用手工方式把它分配给其他工程师。(要察看每个产品单元的默认工程师列表,请单击产品单元链接。)

4,Cc:还有哪些人将收到这个Bug修复更新的电子邮件?

列出其他需要通过电子邮件收到这个Bug修复更新的人的完整的电子邮件地址。只要你愿意,你可以输入足够多的电子邮件地址,电子邮件地址之间必须用逗号分隔,不可有空格。

5,关于这个Bug你还能告诉工程师什么?

6,URL:在什么 URL中你发现这个Bug?

如果你是在特殊的 URL中遇到Bug,请在这里提供它(们)。如果你已经将Bug隔离在一段特殊的HTML程序段中,也请在这里为它提供URL。

7,概述:你如何在大约60个字符之内将这个Bug进行描述?

一个好的概述能很快和唯一识别一份Bug报告,否则,开发者将不能通过Bug概述进行有意义的查询,并且在浏览一份有10页长的Bug列表时,可能忽略你的Bug报告。

关于“在Tosh Tecra 780DVD w/ 3c589C上安装PCMCIA失败”的概述是有用的标题,而“软件失败”或 “安装问题”将是糟糕的标题的例子。

8,描述:还有什么你能告诉工程师关于这个Bug的?

如果可能,在这个域中请提供问题诊断的详细细节。

如果适用,下列的Bug报告模板将帮助你保证不会漏掉所有相关信息:(翻译是我自己加的,不准确的话请见谅!)

总的描述:对概述的更为详细的补充

Drag-selecting any page crashes Mac builds in NSGetFactory

Bug复现的步骤:是跟踪Bug必须的最小集,包含所有的特殊安装步骤。

1) View any web page. (I used the default sample page, resource:/res/samples/test0.html) 观看所有网页。 (我使用了缺省样页, 资源:/res/samples/test0.html)

2)
Drag-select the page. (Specifically, while holding down the mouse
button, drag the mouse pointer downwards from any point in the browser’s
content region to the bottom of the browser’s content region.) 扯拽选择页。
(具体地, 当持续鼠标键时, 扯拽鼠标向下从任何点在浏览器的美满的区域对浏览器的美满的区域的底部。)

目前的结果:应用程序在经过那些步骤后的结果

The application crashed. 应用被碰撞。(程序崩溃)

期望的结果:当Bug不再出现时,应用程序应有的结果

The
window should scroll downwards. Scrolled content should be selected.
(Or, at least, the application should not crash.) 窗口应该移动向下。 应该选择移动的内容。
(或, 至少, 应用不应该碰撞。)

时间及硬件平台:第一次出现这个Bug的时间及硬件平台。

11/2/99 build on Mac OS (Checked Viewer & Apprunner) 11/2/99修造在Mac OS (被检查的观察者& Apprunner)

其它环境及硬件平台:Bug是否出现在其他硬件平台或浏览器上。

– Occurs On

Seamonkey (11/2/99 build on Windows NT 4.0)

– Doesn’t Occur On

Seamonkey (11/4/99 build on Red Hat Linux; feature not supported) Internet Explorer 5.0 (RTM build on Windows NT 4.0)

Netscape Communicator 4.5 (RTM build on Mac OS)

-在Seamonkey

(11/2/99修造在Seamonkey (基于windows NT 4.0)

-不发生在11/4/99Red Hat Linux; 特点没支持的) Internet Explorer 5.0 (RTM修造在windows NT 4.0)

Netscape Communicator 4.5 (RTM基于Mac OS)

其它信息:任何其他调试信息

Win32:
if you receive a Dr. Watson error, please note the type of the crash,
and the module that the application crashed in. (e.g. access violation
in apprunner.exe)

Mac OS: if you’re running MacsBug, please provide the results of a how and an sc.

Unix: please provide a minimized stack trace, which can be generated by typing gdb apprunner core into a shell prompt.

Win32: 如果您接受一个 Dr. Watson 错误, 请注意崩溃的型, 和模块, 应用碰撞了in. (即访问违例在apprunner.exe)

Mac OS: 如果你是在运行MacsBug, 请提供怎么和sc 的结果。

Unix: 请提供减到最小的栈检索, 可能由键入的gdb apprunner 核心引起入壳提示。

你已经完成了一篇不错的bug报告!

Byadmin

Bugzilla 使用指南

Bugzilla安装见前一篇博客,本篇文章主要关注于如何高效合理的使用Bugzilla,作为为公司内部人员的培训使用指南。

Bugzilla是一个开源的缺陷跟踪系统,它可以管理软件开发过程中缺陷的提交、修复、关闭等整个生命周期。

 

1. 基本概念

在Bugzilla中,Bug报告状态分为以下几种状态,

    待确认的      unconfirmed

    新提交的      new

    已分配的      assigned

    问题未解决的 reopened

    待返测的       resolved

    待归档的       verified

    已归档的       closed

 

Bug处理意见(Resolution)

    已修改的      fixed

    不是问题       nvalid

    无法修改       wontfix

    以后版本解决  later

     保留           remind

     重复           duplicate

     无法重现      workforme 

2. 使用方法

1. 新建一个Bugzilla账号

    当以个人身份登录Bugzilla系统时,需要新建一个账号,注册流程和一般的注册流程类似。

image

输入邮箱,点击确认后,修改自己的登陆密码,就完成注册流程。

如果用户忘记密码,可以在登陆界面中点击忘记密码就可以,通过注册邮箱来重置密码。

2.  Bug的生命周期

   

3. 创建项目

  管理员身份进入Bugzilla,点击Products创建新的Products。一个产品可以有多个模块,添加具体产品的对应模块,这样才提交Bug时,更有针对性。

4. 测试人员提交Bug流程

测试人员在提交Bug之前,请先进行查询,确认要提交的Bug不会在原有记录中存在,如果已经存在,不要提交,若有什么建议,可以再原有记录中增加注释,告知其属主,让Bug的属主看到这个后自己去修改。

在发现Bug后,先判断是属于哪个模块的问题,填写Bug报告后,通过Email通知项目组长或者直接通知开发者

项目组长根据具体情况,重新reassigned分配给Bug所属的开发者

 

若Bug不存在,创建一份有效的Bug报告后进行提交

image

image

具体流程图如下:

image

 

 

5. 测试人员验证已经修改的Bug

    1. 测试人员查询开发者已经修改的Bug,即Status为“Resolved”,Resolution为“Fixed”

,重新测试

    2. 经验证无误后,修改Resolutiong为VERIFIED,待产品发布后,修改为CLOSED

        若还有问题,将Bug改为REOPENED,状态重新变为“NEW”,并发邮件通知。

如下图所示:

 image

3. Bugzilla的备份与恢复

  Bugzilla的数据大部分放在数据库了,Bugzilla默认安装时的数据库为Bugs,我这里设置的也是一样的。备份的步骤是先备份Bugzilla数据库,然后备份整个Bugzilla的整个目录就可以。

image

 

恢复的过程很简单,把原来的备份和打包好的目录解压放在新机器相应的目录中,然后导入数据库。下图为恢复数据库的命令

image

Byadmin

Bugzilla使用指南

1 Bugzilla简介 

1.1 产生  

Bugzilla是一个共享的免费的产品缺陷记录及跟踪工具。由Mozilla公司提供。创始人是Terry Weissman,开始时使用一种名为“TCL”的语言创建的,后用Perl语言实现,并作为Open source发布。 

1.2 麻烦 

1. 需要Perl和配置MYSQL数据库; 

2. Bug和Case管理部署在两个不同的工具上面;  

1.3 特点  

Bugzilla能够建立一个完善的bug跟踪体系:报告bug、查询bug记录并产生报表、处理解决bug、管理员系统初始化和设置四部分。(Bug管理系统的通性:比如TFS)  

Bugzilla具有如下特点: 

1. 基于Web方式,安装简单、运行方便快捷、管理安全。 

2. 有利于缺陷的清楚传达。本系统使用数据库进行管理,提供全面详尽的报告

输入项,产生标准化的bug报告。提供大量的分析选项和强大的查询匹配能力,能根据各种条件组合进行bug统计。当缺陷在它的生命周期中变化时,开发人员、测试人员、及管理人员将及时获得动态的变化信息,允许你获取历史记录,并在检查缺陷的状态时参考这一记录。
3. 系统灵活,强大的可配置能力。Bugzilla工具可以对软件产品设定不同的模

块,并针对不同的模块设定开发人员和测试人员。这样可以实现提交报告时自动发给指定的责任人,并可设定不同的小组,权限也可划分。设定不同的用户对bug记录的操作权限不同,可有效控制进行管理。允许设定不同的严重程度和优先级。可以在缺陷的生命期中管理缺陷。从最初的报告到最后的解决,确保了缺陷不会被忽略。同时可以使注意力集中在优先级和严重程度高的缺陷上。 

4. 自动发送Email,通知相关人员。根据设定的不同责任人,自动发送最新的动

态信息,有效的帮助测试人员和开发人员进行沟通。(每个人收到邮件后要自觉的进行相关处理)  

2 Bugzilla操作说明 

2.1 用户登录及设置  

2.1.1 用户登录 1. 用户输入服务器地址http://192.168.11.18/bugzilla。 2. 进入主页面后,点击【login in】进入。 3. 输入用户名和密码即可登录。用户名为Email 地址,初始密码为用户名缩写。 4. 

如忘记密码,点击【Forgot Password】,输入用户名,根据收到的邮件进行

重新设置。 2.1.2 用户属性设置 

Login登录后,点击【Preferences】进行属性设置 a) 账号设置(Name and Password) 

在这里你可以改变你账号的基本信息,如口令,Email地址,真实姓名 为了安全起见,在此页进行任何更改之前你都必须输入你当前的口令
当你变更了你的Email地址,系统会给你的新老Email地址分别发一封确认邮件,你必须到邮件中指定的地址对你的更改进行确认 b)
Email设置(Email Preferences) 

你可以在此通过选择告诉系统,你希望在什么条件下收到和你相关的邮件 

c) 保存的查询(Saved Searches) d) 常规属性(General Preferences) e) 用户权限(Permissions) 

2.2 报告Bug  

2.2.1 测试人员报告Bug 

1. 请先进行查询,确认要提交的bug报告不会在原有纪录中存在,若已经存在,

不要提交,若有什么建议,可在原有纪录中增加注释,告知其属主,让bug的属主看到这个而自己去修改。 

2. 若Bug不存在,创建一份有效的bug报告后进行提交。 3. 操作:点击New,选择产品后,填写下表。 4. 填表注意: 

Assigned to: 为空则默认为设定的 owner, 也可手工制定。 CC: 可为多人,需用”,”隔开。 

Description中要详细说明下列情况: 

a) 发现问题的步骤 

b) 执行上述步骤后出现的情况。 c) 期望应出现的正确结果。 

5. 操作结果:Bug状态(status)可以选择Initial state 为New或Assigned. 

a) 系统将自动通过Email通知项目组长或直接通知开发者。 

6. 帮助: Bug writing guidelines 2.2.2 开发人员报告Bug. 

1. 具体方法同测试人员报告。 

2. 区别: Bug初始状态将自动设为Assigned,待测试人员确定后变为“New”. 

2.3 处理Bug 

2.3.1 处理情况1  

Bug的属主 (owner) 处理问题后,提出解决意见及方法。 

1. 给出解决方法并填写Additional Comments,还可创建附件(如:更改提交

单) 

2. 具体操作(填表项如下)

3. 填表注意: 

 FIXED 描述的问题已经修改 

 INVALID 描述的问题不是一个bug (输入错误后,通过此项来取消)  WONTFIX 描述的问题将永远不会被修复。 

 LATER 描述的问题将不会在产品的这个版本中解决.  DUPLICATE 描述的问题是一个存在的bug的复件。  WORKSFORME 所有要重新产生这个bug的企图是无效的。如果有更多的信

息出现,请重新分配这个bug,而现在只把它归档。 2.3.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.3.3 处理情况3 

测试人员验证已修改的 Bug. 

1. 测试人员查询开发者已修改的bug,即Status为”Resolved”,Resolution为

“Fixed”.进行重新测试。(可创建test case附件) 

2. 经验证无误后,修改Resolution为VERIFIED。待整个产品发布后,修改为

CLOSED。 

  若还有问题,REOPENED,状态重新变为“New”,并发邮件通知。 3. 具体操作(可选择项) 

 Leave as RESOLVED FIXED  Reopen bug 

 Mark bug as VERIFIED  Mark bug as CLOSED 2.3.4 处理情况4 

Bug报告者(reporter)或其他有权限的用户修改及补充Bug 1. 可以修改Bug的各项内容。 

2. 可以增加建立附件,增加了相关性, 并加一些评论来解释你正在做些什么和

你为什么做。 3. 操作结果: 

每当一些人修改了bug报告或加了一个评论,他们将会被加到CC列表中,bug报告中的改变会显在要发给属主、写报告者和CC列表中的人的电子邮件中。 

2.4 查询Bug 

1.直接输入Bug Id,点击find 查询。可以查看Bug的活动纪录。 2.点击Search,输入条件进行查询。

根据查找的需要在界面中选择对象或输入关键字 查找功能能够进行字符或字串的匹配查找 查找功能具有布尔逻辑检索功能
你可以通过在查找页面中选择“Remember this as my default query”将当前检索页面中设定的项目保存。以后可以从页脚中的My bugs中直接调用这个项目进行检索
你还可以通过在“Remember this query, and name it:”后面输入字符,将你当前检索页面中设定的项目保存命名,同时选中“and put it in my page footer”。则以后这个被命名的检索将出现在页脚中。 3.查询Bug活动的历史 4.产生报表。
5.帮助:点击Give me some help.
2.5 关于权限的说明 
1. 组内成员对bug具有查询的权利,但不能进行修改。 2. Bug的owner 和 reporter 具有修改的权利。 3. 具有特殊权限的用户具有修改的权利
2.6 BUG处理流程 
1. 测试人员或开发人员发现bug后,判断属于哪个模块的问题,填写bug报告
后,通过Email通知项目组长或直接通知开发者。
2. 项目组长根据具体情况,重新reassigned分配给bug所属的开发者。 3. 开发者收到Email信息后,判断是否为自己的修改范围.
a) 若不是,重新reassigned分配给项目组长或应该分配的开发者。 b) 若是,进行处理,resolved并给出解决方法。(可创建补丁附件及补充
明)
4. 测试人员查询开发者已修改的bug,进行重新测试。(可创建test case附件)
a) 经验证无误后,修改状态为VERIFIED。待整个产品发布后,修改为CLOSED  b) 还有问题,REOPENED,状态重新变为“New”,并发邮件通知。 5. 如果这个BUG一周内一直没被处理过。Bugzilla就会一直用email骚扰它的
owner,直到采取行动。
2.7 表单描述
 模块(Component)
产生Bug的软件模块  版本(Version)
产生Bug的软件版本  严重性(Severity)  硬件平台(Hardware)  操作系统(OS)  优先级(Priority)
分五个等级即P1-P5,P1的优先级别最高之后逐级递减  初始状态(Initial State)  指定处理人(Assigned To)

可以指定一个处理人。如不指定处理人,则系统指定管理员为默认处理人  相关人员(CC)
如需要抄送多人,可将邮件地址用“,”分隔  估计时间(Estimated Hours)  最后期限(Deadline)  超链接(URL)
输入超链接地址,引导处理人找到与报告相关联的信息  概述(Summary)
概述部分“Summary”的描述,应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。
如果是通用组件部分的测试,则必须将这一通用组件对应的功能名称写入概述中,以便今后查询。
 从属关系(Bug “ID” depends on,Bug “ID” blocks)
“Bug “ID” depends on”如果该Bug必须在其他Bug修改以后才能够修改,则在此项目后填写那个Bug的编号
“Bug “ID” blocks”如果该Bug的存在影响了其他Bug的修改,则在此项目后填写被影响的Bug编号  附加描述(Description)
在Bug跟踪过程中测试与开发人员通过这里进行沟通 开发人员可以在这里填写处理意见和处理记录
测试人员可以在这里填写返测意见和对在返测过程中发现的新问题进行描述
 附件(Attachment)
Bug相关的文件或截图
 
3 相关名词解释
3.1 Bug报告状态(Status)
 待确认的(Unconfirmed)  新提交的(New)
 已分配的(Assigned)
 问题未解决的(Reopened)  待返测的(Resolved)  待归档的(Verified) 
已归档的(Closed)
3.2 Bug处理意见(Resolution)
 已修改的(Fixed)  不是问题(Invalid)  无法修改(Wontfix)  以后版本解决(Later)  重复(Duplicate)

无法重现(Worksforme)

 移除(Moved)
3.3 Bug严重性(Severity)
 Blocker,阻碍开发和/或测试工作  Critical,死机,丢失数据,内存溢出  Major,较大的功能缺陷  Normal,普通的功能缺陷  Minor,较轻的功能缺陷 
Trivial,产品外观上的问题或一些不影响使用的小毛病,如菜单或对话框中的文字拼写或字体问题等等  Enhancement,建议或意见
3.4 Bug优先级(Priority)
 分五个等级即P1-P5,P1的优先级别最高之后逐级递减
3.5 Bug硬件平台(Hardware)
 All  PC  IBM 
Other
3.6 Bug操作系统(OS)
 All
 Windows  WindowsXP  Windows2003  AIX  AIX5.3  AIX6.1  Linux 
Other

Byadmin

测试跟踪工具Bugzilla介绍

关键字:测试 跟踪 工具 Bugzilla

     Buzilla作为一个产品缺陷的记录及跟踪工具,它能够为你建立一个完善的Bug跟踪体系,包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。并具有如下特点:  
1。基于Web方式,安装简单、运行方便快捷、管理安全。 

2。有利于缺陷的清楚传达。本系统使用数据库进行管理,提供全面详尽的报告输入项,产生标准化的Bug报告。 提供大量的分析选项和强大的查询匹配能力,能根据各种条件组合进行Bug统计。当错误在它的生命周期中变化时,开发人员、测试人员、及管理人员将及时获得动态的变化信息,允许你获取历史纪录,并在检查错误的状态时参考这一记录。 

3。系统灵活,强大的可配置能力。Buzilla工具可以对软件产品设定不同的模块,并针对不同的模块设定制定的开发人员和测试人员;这样可以实现提交报告时自动发给指定的责任人;并可设定不同的小组,权限也可划分。设定不同的用户对Bug记录的操作权限不同,可有效控制进行管理。允许设定不同的严重程度和优先级可以在错误的生命其中管理错误,从最初的报告到最后的解决,确保了错误不会被忽略,同时可以使注意力集中在优先级和严重程度高的错误上。  

4。自动发送Email,通知相关人员。根据设定的不同责任人,自动发送最新的动态信息,有效的帮助测试人员和开发人员进行沟通。 

  

Bugzilla操作说明 

1、 用户登录及设置 

1.1用户登录 

1. 用户输入服务器地址http://192.168.1.6/bugzilla/。 

2. 进入主页面后,点击【Forget the currently stored login】,再点击【login in】进入。 

3. 进入注册页面,输入用户名和密码即可登录。用户名为Email 地址,初始密码为用户名缩写。 

4. 如忘记密码,输入用户名,点击【submit request】,根据收到的邮件进行重新设置。 

1.2、修改密码及设置 

1.Login登录后,【Edit prefs】->【a<a href=”http://www.ltesting.net/ceshi/ceshijishu/rjcsgj/rational/%3CSTRONG%3E%3C… http:=”” www.ltesting.net=”” ceshi=”” ceshijishu=”” rjcsgj=”” rational=”” clearcase=”” “=””
target=”_blank” style=”box-sizing: border-box; padding: 0px; margin:
0px; background-color: transparent; text-decoration: none; font-weight:
normal; font-family: ‘Microsoft YaHei’, ‘Microsoft YaHei’; color:
rgb(51, 51, 51); background-position: initial initial;
background-repeat: initial initial; “>clearcase
/” target=”_blank” >ccout 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 

1. 可以修改Bug的各项内容。 

2. 可以增加建立附件,增加了相关性, 并加一些评论来解释你正在做些什么和你为什么做。 

3. 操作结果:每当一些人修改了bug报告或加了一个评论,他们将会被加到CC列表中,bug报告中的改变会显在要发给属主、写报告者和CC列表中的人的电子邮件中。 

2.2.5测试人员确认开发人员报告的Bug是否存在. 

1. 查询状态为“Unconfirmed”的Bug, 

2. 测试人员对开发人员提交的Bug进行确认,确认Bug存在。 

3. 具体操作:选中“Confirm bug(change status to New)”后,进行commit. 

4. 操作结果:状态变为“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处理流程