1      简介：
Bugzilla是Mozilla公司向我们提供的一个开源的免费缺陷跟踪工具。作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的Bug跟 踪体系，包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。并具有如下特点：
●       基于Web方式，安装简单、运行方便快捷、管理安全。
●      有利于缺陷的清楚传达。本系统使用数据库进行管理，提供全面 详尽的报告输入项，产生标准化的Bug报告。提供大量的分析选项和强大的查询匹配能力，能根据各种条件组合进行Bug统计。当错误在它的生命周期中变化 时，开发人员、测试人 员、及管理人员将及时获得动态的变化信息，允许你获取历史纪录，并在检查错误的状态时参考这一记录。
●      系统灵活，强大的可配置能力。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骚扰它的属主，直到采取行动为止。

　　本文介绍了基于B/S模式的软件缺陷跟踪管理系统的设计与实现。软件缺陷是在软件生命周期中不可避免的对象。缺陷跟踪管理是软件管理的重要组成。现有管理方法是将进入到系统中的问题,都认为是软件缺陷进行处理。但是实际情况却可能有虚假或重复的缺陷报告。不及时处理这些问题,它本身又可能形成新的缺陷。从软件系统考虑,应将软件缺陷跟踪管理纳入到项目管理信息系统之中,成为项目管理信息系统的一个子系统。对维护人员提交的缺陷报告认真鉴定、筛选、分类,进入不同的处理流程,以获得真正的缺陷跟踪数据。本文在分析讨论这些问题的基础上,提出新的软件缺 陷跟踪管理系统的总体结构。

　　软件缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是，并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。CMM及CMMI都对软件缺陷跟踪给予了关注并做出了相关规定。本文的侧重点放在了讨论这个程序的需求分析、设计、实现及所用到的项目管理知识。借着实现这个简单的缺陷跟踪系统，探讨了个人软件开发过程当中遇到的各种问题，以及解决它们的方法，展示了个人软件开发的一般过程。

　　缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。

　　1、 缺陷跟踪管理的目标

　　缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标：

　　确保每个被发现的缺陷都能够被解决；这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；

　　收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。

　　收集缺陷数据并在其上进行数据分析，作为组织的过程财富。

　　上述的第一条是最受到重视的一点，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。

　　2、 缺陷的描述

　　对缺陷的描述应该包含以下的内容： 可追踪信息

　　缺陷ID：唯一的缺陷ID，可以根据该ID追踪缺陷

　　缺陷基本信息

　　缺陷状态：缺陷的状态，分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭”

　　缺陷标题：描述缺陷的标题

　　缺陷的严重程度：描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“建议”四种

　　缺陷的紧急程度：描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级

　　缺陷提交人：缺陷提交人的名字（邮件地址）

　　缺陷提交时间：缺陷提交的时间

　　缺陷所属项目/模块：缺陷所属的项目和模块，最好能较精确的定位至模块

　　缺陷指定解决人：缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改

　　缺陷指定解决时间：项目经理指定的开发人员修改此缺陷的deadline

　　缺陷处理人：最终处理缺陷的处理人

　　缺陷处理结果描述：对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改

　　缺陷处理时间：缺陷处理的时间

　　缺陷验证人：对被处理缺陷验证的验证人

　　缺陷验证结果描述：对验证结果的描述（通过、不通过）

　　缺陷验证时间：对缺陷验证的时间

　　缺陷的详细描述：对缺陷的详细描述；之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细

　　测试环境说明：对测试环境的描述

　　必要的附件：对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的

　　除上述描述项外，从统计的角度出发，还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等项目。

　　3、 缺陷管理的一般流程

　　缺陷管理的流程比较简单，图1是一个缺陷状态图。

　　流程中的角色：

　　1、 测试人员：进行测试的人员，缺陷的发起者；

　　2、 项目经理：对整个项目负责，对产品质量负责的人员；

　　3、 开发人员：执行开发任务的人员，完成实际的设计和编码工作；

　　4、 评审委员会：对缺陷进行最终确认，在项目成员对缺陷达不成一致意见时，行使仲裁权力。

　　缺陷的状态

　　1、 初始化：缺陷的初始状态；

　　2、 待分配：缺陷等待分配给相关开发人员处理；

　　3、 待修正：缺陷等待开发人员修正；

　　4、 待验证：开发人员已完成修正，等待测试人员验证；

　　5、 待评审：开发人员拒绝修改缺陷，需要评审委员会评审；

　　6、 关闭：缺陷已被处理完成。

　　4、 缺陷数据统计

　　如前所述，缺陷数据统计也是缺陷跟踪管理系统的目标。一般而言，生成的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。

　　5、 缺陷跟踪管理系统

　　目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软 件）、Mozilla公司的Bugzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然， 也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。我公司采用的是自己开发的基于Notes的缺陷跟踪系统，除了具有上述功能外，还能够通过Notes的邮件系统方便地向相关人员发送提醒信息（缺陷处理超时提醒、缺陷待处理提醒等）。

　　除此之外，作为一个缺陷跟踪管理系统，还必须注意权限分配的问题。缺陷记录作为软件开发过程中的 重要数据，不能轻易被删除；对于已经关闭的缺陷，也不能随意进行修改。因此，缺陷跟踪管理系统必须设置严格的管理权限，非相关人员不得进行相应操作，修改相应数据。在这一点上，通过Notes也很容易控制。

易用性
考察评定软件的易学易用性，各个功能是否易于完成，软件界面是否 友好等方面进行测试，这点在很多类型的管理类软件中是非常重要的。
对于易用性测试可遵循以下原则：
1、完成相同或相近功能的按钮用Frame.框起来，常用按钮要支持快捷方式。
2、完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3、按功能将界面划分局域块，用Frame.框起来，并要有功能说明或标题。
4、界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5、界面上首先应输入的信息和重要信息的控件在Tab顺序中应当靠前，位置也应放在窗口上较醒目的位置。
6、同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
7、分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
8、默认按钮要支持Enter操作，即按Enter后自动执行默认按钮对应操作。
9、可输入控件检测到非法输入后应给出说明信息并能自动获得焦点。
10、Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
11、复选框和选项框按选择几率的高底而先后排列。
12、复选框和选项框要有默认选项，并支持Tab选择。
13、选项数相同时多用选项框而不用下拉列表框。
14、界面空间较小时使用下拉框而不用选项框。
15、选项数较少时使用选项框，相反使用下拉列表框。
16、专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
17、对于界面输入重复性高的情况，该界面应全面支持键盘操作，即在不使用鼠标的情况下采用键盘进行操作。
对于易用性测试还可从以下几个方面入手：
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决 定一个应用系统是否易于导航：导航是否直观？系统的主要部分是否可 通过主页存取？系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。应用系统的用户趋向于目的驱动，很快地扫描一个应用系统，看是否有满足自己需要的信息，如果没有，就 会很快地离开。很少有用户愿意花时间去熟悉应用系统的结构,因此，应用系统导航帮助要尽可能地准确。导航的另一个重要方面是应用系统的页面结构、导航、菜 单、连接的风格是否一致。确保用户凭直觉就知道应用系统里面是否还有内容，内容在什么地方。
应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮 等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链 接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错 误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文 章列表"。
4、整体界面测试
整体界面是指整个应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览应用系统 时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。对所有的可用性 测试来说，都需要有外部人员（与应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户 的参与。

中科院软件测试工程师视频课程（清晰版全集）

淘宝网上订购		新科海名师视频课程－软件测试工程师视频课程光盘 一口价 10.00

本视频为中科院新科海学校出品,更多信息请访问：http://www.jobedu.com.cn/,咨询QQ:373750059,903367690,电话:010-82622282,010-82622285.院校合作：010-82608892.