http://blog.bugols.com Bugols官方博客，系统更新，Bug知识，程序开发 Thu, 01 May 2008 02:44:04 +0000 http://backend.userland.com/rss092 en 缺陷管理作为软件质量管理的重要组成部分,正在成为软件开发管理过程的又一亮点，因为国内外越来越多的公司进行相关管理工具的开发到人们对缺陷管理工具的需求逐渐增多而且更加明确,同时渴望能够得到物美价廉的可用版本(当然大多数都有免费的试用板)。缺陷管理的重要性和被人们所给予的重视程度可见一斑。下面先让我们看看国际、国内比较知名的缺陷管理软件各有何特点。 1. BugRat(Open source) BugRat做为开源项目Giant Java Tree 的一个分支。它的最新版本2.5.3发行于2001年3月12日，之后项目处于停滞状态。BugRat已经具备了普通缺陷管理软件的共同特性，它的特点如下： 1) 使用关系型数据库 2) 数据库连接使用JDBC 3) 使用Serverlet作为数据库的接口 4) 可以跨网络报告bugs 5) 可以通过mail报告bugs 6) 支持通过web浏览或搜索bug 7) 可以从用java编写的客户端管理数据库 2. TrackRecord(Business) 作为Compuware项目管理软件集成的一个重要组成部分，TrackRecord目前已经拥有众多的企业级用户，它基于传统的缺陷管理思想，整个缺陷处理流程完备，界面设计精细，并且对缺陷管理数据进行了初步的加工处理，提供了一定的图形表示。显著特点如下： 1) 定义了信息条目类型（Item type） 在TrackRecord的数据库中，定义了不同的缺陷，任务，组成员等内容；通过图形界面进行输入 2) 定义规则（rules） 规则引擎（Rules engine）允许管理者对不同信息类型创建不同的规则，规定不同字段的值的范围等 3) 工作流程（Workflow） 一个缺陷，任务或者其它条目，从它被输入到最后排除（closed）期间经历的一系列状态。 4) 查询（Queries） 对历史信息进行查询，显示结果 5) 概要统计或图形表示（Outline and graphs） 动态的对数据库中的数据进行统计报告，可按照不同的条件进行统计，同时提供了几种不同的图形显示： ---- 文本方式显示不同缺陷状态、列表。 ---- 立体彩色条形图显示不同优先级的缺陷状态 ---- 立体彩色条形图显示不同开发者不同优先级的缺陷状态 ---- 彩色饼图显示所有人员发现缺陷占总缺陷数的百分比 6) 网络服务器（WebServer） 网络服务器允许用户通过网络浏览器访问数据库。 7) 自动电子邮件通知 提供报告的缺陷邮件通知功能，并为非注册用户提供远程视图（在保证项目信息安全的情况下，让某些非项目组人员可以了解项目的相关信息） 3. ClearQuest(Business) Rational一向以功能强大产品类型全面而著称。Rational ClearQuest 是基于团队的缺陷和变更跟踪解决方案，它包含在Rational Suite中。Rational Suite 是针对分析人员、开发人员和测试人员进行了优化的一套软件开发全面解决方案。作为它主要组件之一的Rational ClearQuest 是一套高度灵活的缺陷和变更跟踪系统，适用于在任何平台上，任何类型的项目中，捕获各种类型的变更。 它的强大之处和显著特点表现在以下几个方面： 1) 支持数据库MS ACCESS和SQL SERVER6.5 2) 拥有可完全定制的界面和工作流程机制，能适用于任何开发过程 3) 可以更好地支持最常见的变更请求（包括缺陷和功能改进请求），并且便于对系统做进一步的定制，以便管理其他类型的变更 4) 提供了一个可靠的集中式系统，该系统与配置管理、自动测试、需求管理和过程指导等工具相集成，使项目中每个人都可以对所有变更发表意见，并了解其变化情况 5) 与Rational的软件管理工具ClearCase完全集成，让用户充分掌握变更需求情况 6) 能适应所需的任何过程、业务规则和命名约定。可以使用ClearQuest 预先定义的过程、表单和相关规则，或者ClearQuestDesigner 来定制––几乎系统的所有方面都可以定制，包括缺陷和变更请求的状态转移生命周期、数据库字段、用户界面布局、报表、图表和查询等 7) 强大报告和图表功能，使您能直观、简便地使用图形工具定制所需的报告、查询和图表。用户可深入分析开发现状 8) ... http://blog.bugols.com/topic/7.html 某甲问道：「测试做太多的话，会不会使得bug解不完？」某乙回答：「还不简单。只要不做测试，就没有bug。」上述对话，反应出许多软件工作人员对于测试的想法。对多数软件开发人员而言，测试大概是仅次于维护之外，最令人讨厌的工作。对软件研发主管来说，测试是必要之恶：做得不够后患无穷，做得过多又增加成本，延误商机。因此，如何能够规画与执行一个最经济有效的测试工作，当是软件研发主管们须研究的一个课题。 软件测试的困难，在于它不仅是产品的测试，更是产品设计程序的检验。由于关乎设计的测试，准则不易寻找，经验未必得以再用，他山之石也有应用的局限性，因此难度颇高。欲提高测试的效益，有赖全盘的规画，确实的执行，与事后的检讨改进动作。许多小型软件研发单位，对于软件测试并不重视，但从许多稍具规模的软件公司均配置常设测试人员，乃至于测试品保部门来看，测试工作显然有其学问与价值的。 测试工作没有最佳方法可依循，是因为不同的软件所需的测试手段不同。譬如小型软件与大型系统的做法不同；订制软件与软件包的要求不同；系统软件的测试往往无法采用应用软件所使用的技巧；游戏软件与库存系统有其各自需面对的测试标的。因此，测试人员必须因应软件的特性与资源的限制，加上过去相关的经验，规画最适合的测试方式。并随着经验的累积，不断改进作法，才能找出最佳的测试方法。 由此可知，要做好有效的测试，不只是埋头苦干而已，它需要良好的管理，使整件工作获致最佳的成果。关于测试的管理工作，可从组织、规画、执行与检讨几个角度来探讨。以下谨就笔者粗浅的经验野人献曝一番，希望提供读者基本的协助。 测试组织之设计 由于人性总自认为自己的最好最正确，完全由软件开发人员兼任测试人员，并不值得推荐。实务上往往因软件开发单位的经济规模不够，使得开发人员经常兼任测试人员。但若可行，研发单位应尽可能配置专任的测试人员，尤其是独立于开发小组之外的测试负责人员。尽管是否应设置独立测试小组业界仍有争议，许多人甚至以为保障软件品质唯有从改进软件开发的程序做起，但大部份美国的软件公司均设有独立测试或品保人员乃至于部门，这说明了独立测试仍有其不可摇撼的地位。 许多的软件研发单位将测试视为次等的工作，从而配置次等人员负责相关工作。如此一来，优秀人员无从参与，也缺乏意愿参与测试工作。结果软件品质不易度量，研发的成果常常被不佳的品质抵销，实为令软件开发人员泄气之事。主管是否能体认到软件测试的重要性，通常是成功的关键。软件测试固然是支持性工作，仍应配置合理的资源，以获取整体之成效。在当前的环境下，给予测试人员较多的关注，毋宁是必要的作法。 测试工作规画 测试工作的规画，至少包含两项要点：测试目标的订定与测试资源的配置。攻击需要目标，测试亦然。测试的目的在于找出软件的问题，提供改进之参考。目标若不明，测试人员即不知如何着手。 测试目标的订定，最重要的在于软件通过的准则，亦即测试何时方可结束。常见的情形是：软件开发的进度不断落后，最后剩余的时间仅有两个星期，于是测试人员的目标就是把最后两周用完，尽人事听天命。究竟测试多完整，隐藏的多少错误，测试工作的生产力如何？皆一概不知。反正产品卖出去或上线后有的是时间改进。然而产品销售后再改进，成本往往大幅增高，甚至原有开发人员离职他调，连亡羊补牢都倍感困难。经验一再显示，事前的测试除错绝对比事后维护省时省钱，唯有卖不出去或不能用的软件例外。 对于测试的要求可简单区分为二：一种是通过目标所订之软件品质；一种是在既定资源内达到最佳成效。前者要求山头一定要攻下，不达目的绝不停止。譬如目标为单位测试时间的错误发现率须低于某数字，若超过了就得延长测试。此种方式适用于品质要求较高的软件。至于后者则是上市时间已宣布，无法更改者，其目标着重于铲除最严重的错误。此种测试较着重测试的准备、经常对测试执行与除错设定时限与数量要求，其中最容易遵循的准则即为：重要功能永远先测。这两类测试的需求不同，足以影响到测试的计划、测试的顺序与关心的重点。读者不可不察。 至于测试资源配置适当性，则是评估测试目标能否达成的重要参考指标。测试人员需要合理的测试资源，譬如要求总研发人力的20%以上。总时程的1/3以上。人力不足，测试流于形式，时程过短，找到错误也来不及除错，均不可取。除了测试在研发的比重，也需注意测试工作本身在规画管理、规格个案订定、测试执行、回归测试、训练准备工作的人力分配。人员的训练与设备的安排尤其容易轻忽，需加以注意。不同阶段测试的资源配置，也必须加以考量，如此可避免测试集中于功能测试，忽略系统测试。这些工作的适切安排，有助于协助测试工作时时都执行最重要，也最有效的测试。 测试执行与管理 测试工作执行在管理上，首先需使测试与开发人员了解轻重缓急。测试人员常常不考虑测试的效果，而只依照测试的方便性来进行测试。譬如软件有十大模块，每一模块有50个测试个案，于是他从第一个模块的第一个个案开始测，测完一整个模块，再进行第二个模块的测试，执行全部完成或无法进行为止。事实上，测试应从重要且常用的项目测起。 开发人员的除错，则往往从好改的改起。于是100个错误改了90个，系统主要的缺陷仍为克服。测试管理人员需特别注意此事，确保测试工作的效率。 进行测试管理的好处在于随时可掌握状况，并因应需求及时调整测试策略。譬如测试一段时间后，发现某子系统的问题特别多，即可调整人力，增强该部份的测试。或是某些人的测试绩效较差，则可调整工作之分配，以求整体效果。当然，这些数据的取得有赖相关信息的搜集，包括数量与时间之信息。如果可行，可记录不同测试工作耗用的人力时数，计算耗用成本，以便未来进行测试规划时拥有更精确的参考数据。 进行相关资料的统计与分析，最好运用工具来帮忙，以节省人力并增进效果。如果市面已有的测试管理工具符合需求，也可径行采用。测试结果的统计资料，不妨公布在大家的眼前，使得测试成果可为大家了解，亦能促进工作同仁求取更佳的成绩。附图所显示为一简单的统计图表，显示每周的测试成果、除错成果，与产品残存的问题量，可协助主管决定测试终止及发行产品的时间。 测试结果分析与改进 当(阶段)测试结束后，测试管理人员可以进行测试成果的分析。有关预定目标与实际执行结果的差异，可作为下一版软件测试检讨改进的依据。譬如预定开立的测试个案数是否达成目标，执行与通过数是否可接受？投入的测试甚至除错人力是否足够？均可视状况计算依标准工作量，作为未来执行测试工作之预估标准。经由分析软件错误的生命周期，可以研究缩短的方法，例如加速除错与重测周期，或在分析设计阶段减少错误发生的机率，以缩短测试时程。 由测试结果可分析出不同测试的效益，与应改进之处。以下表为例。单元测试耗用大部份的人力，可能使整合与系统测试不完全。再以发现的错误数观之，整合测试发现一个错误的成本远低于另两项。由此可见在有限的人力时间下测试，单元测试做得太多，整合测试又太少。此意谓着对于单元测试所需耗用的人力资源过度乐观，或是在测试工作的配置不尽理想，应予改进。  测试人力时数 测试人力分布比率 错误个数 错误分布比率 平均时数/错误数 单元测试 227.104 58.6% 49 39.51% 4.635 整合测试 87.212 23.3%  54 43.55%  1.615  系统测试 70.184 18.1% 21 16.94% 3.342 合计 384.5 100% 124 100% 3.2 除了以上的测试成效分析。如行有余力时应再对错误发生的原因加以分析，力求从问题的根源加以解决。这包含测试工作的改进与开发工作的流程改进。以前者而言，可考虑对测试人员施以较充分的训练，避免测试工作因准备不周浪费宝贵的人力与时间。测试标准程序的建立，也有助于测试工作效率的提升。至于后者，可由错误发生的原因研究预防之道。例如对需求变更未确实记载，导致设计错误的问题发生，或是软件的设计未加充分的考虑再撰写程序，导致设计不良造成的大量错误，均应加以预防，如此可望从根本解决软件的问题。 结语 欲提升软件品质与生产力，得先掌握现况。测试工作既是必要之恶，就需拟定最好的方法来面对。有关软件测试方法论的书籍文章为数固然不少，在应用上仍须因应自身的情形加以调整。品管大师戴明认为：获得好品质不能靠检验，而是来自改善工作流程。因此，测试工作只是一项起步。如何藉由测试工作，了解改善软件品质与生产力之道，才是我们追求的目标。愿祝各位软件品质的捍卫者，在工作岗位顺利前进，为测试工作赢得荣耀，更为你们的成功产品喝采。 转自：http://www.cnblogs.com/jackei/archive/2005/04/08/134105.html http://blog.bugols.com/topic/6.html 软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。     错误跟踪管理系统     为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。     目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、 Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。     作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。     正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。     软件错误的状态     新信息(New)：测试中新报告的软件缺陷；     打开 (Open)：被确认并分配给相关开发人员处理；     修正(Fixed)：开发人员已完成修正，等待测试人员验证；     拒绝(Declined):拒绝修改缺陷；     延期(Deferred): 不在当前版本修复的错误，下一版修复     关闭(Closed)：错误已被修复；     Bug管理的一般流程 　　测试人员提交新的Bug入库，错误状态为New。 　　高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。     开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。     对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。     测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为 Closed，如没有解决置状态为Reopen。     软件错误流程管理要点     为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。     每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。     拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。     错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。     加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。 http://blog.bugols.com/topic/5.html  一、概述 测试质量和效率是软件测试的重要内容，其中对软件测试过程发现的软件缺陷（Bug）的管理具有重要作用。 软件测试缺陷管理数据库是管理软件测试缺陷的专用数据库系统，可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。 实际测试项目实施之前，客户都提供通过因特网访问的项目公共数据库。由于通过因特网访问速度比较慢，客户只给项目中的少数人登录权限，所以，不能满足测试组每个成员都可以方便地访问数据库。更重要的，如果每个测试工程师都各自直接向项目公共数据库报告和修改软件测试发现的缺陷，由于每个人软件测试的经验背景不同，很难控制报告的缺陷质量，也不利于保持软件缺陷报告的一致性。所以，为了保证报告软件缺陷的质量和格式的一致性，需要测试小组内部指定具有测试经验的人员验证和审查小组内部报告的软件缺陷，然后再通过因特网，统一报到项目公共数据库中。 据调查，很多从事多年软件测试的公司，都有内部的软件测试缺陷管理数据库。这些内部数据库大部分是公司内部开发的，也有一些是直接从市场上购买的。公司内部开发的功能更符合实际要求、具有良好的扩展性。直接购买的数据库节约了开发成本，但是往往价格较高，很多功能根本用不上，造成经济上的浪费。 大型的软件测试项目，需要多人组成一个或多个测试小组，通过有效管理和内部交流才能保证测试项目的顺利实施。因此，如果再单纯采用内部电子邮件的方法管理测试的软件缺陷，将造成测试项目实施过程中，软件测试缺陷的交流效率低，缺陷的流程管理难以实时控制。 二、采用电子表格与电子邮件管理软件缺陷引起的问题 在没有引入公司内部软件缺陷管理数据库之前，对于测试发现的软件缺陷，测试小组内部采用发送内部电子邮件的方式。测试工程师发现的软件缺陷，先书写测试基本信息（软件名称、版本号、语言、测试环境、测试内部、缺陷类别，测试者姓名、测试日期），然后加入详细的测试步骤，和/或捕捉缺陷的图像。再发送给测试组内部的软件缺陷验证工程师，为了使内部其他测试工程师注意已经发现的缺陷，还要同时抄送邮件。负责向客户提供的项目数据库测试团对中的工程师，首先要检查测试工程师邮件中的软件缺陷是否正确和完整，包括格式、步骤，然后报告到客户提供的项目数据库。为了便于统计工作量、进度、缺陷类型和数量，通常创建电子表格文件，将缺陷类型、报告者、报告日期、缺陷状态等进行记录。 这种测试工作方式最大的不便之处在于： 1、测试效率不高 测试组每个成员在测试过程中要不断受到中断，需要随时阅读和回复这些邮件，工作效率很低。尤其当测试成员很多，测试的语言版本很多时，缺陷严重工程师的压力更大。内部缺陷验证工程师的工作量很大，不仅要验证缺陷的正确性，报告缺陷到客户的项目数据库，还要逐个向电子表格文件输入每个缺陷的处理情况。另外，如果报告的缺陷很多，很难分类查找某个或某种类型的缺陷。 2、测试质量难保证 由于个人的测试经验和习惯不同，每个人报告的软件缺陷的内容和格式很难保持一致，甚至往往遗漏关键内容。软件缺陷验证时，需要花费很多时间对其内容进行检查，对于检查中发现的问题还要发邮件或口头交流。如果缺陷被验证通过，再报告到客户提供的因特网测试缺陷管理数据库中，并且发送缺陷编号和标题等内容给测试工程师，并抄送给内部其他相关测试工程师，又一次造成测试中断和处理邮件。 3、实时管理难度大 测试过程中，经常需要迅速定位查找某个软件错误，由于没有内部数据库管理，只能从很多测试邮件和缺陷统计电子表格文件中寻找，或者从因特网的项目测试数据库查找，查找耗费大量的时间。另外，如果多个人同时测试不同语言的软件，由于发现的测试缺陷种类不同，缺陷验证工程师可能需要不断切换操作系统验证缺陷，效率很低。 三、引入软件测试缺陷管理内部数据库的重要性分析 以下从软件测试的流程管理的要求和大型多语言软件测试特征方面，论述引入内部软件测试缺陷管理系统的必要性。 1、提高软件缺陷的报告效率和质量 引入内部专用软件测试缺陷数据库具有以下优点： 第一、保持高效率的测试过程。由于测试缺陷数据库通过测试组内部局域网运行，因此打开和操作速度快。测试工程师随时向内部数据库添加新发现的缺陷，而且如果遗漏某项缺陷的内容，数据库系统将会及时给出提示，保证软件缺陷报告的完整性和一致性。软件缺陷验证工程师将主要精力验证数据库中新报告的缺陷，保证了效率。 第二、提高软件缺陷报告的质量。软件缺陷报告的一致性和正确性是衡量软件测试公司测试专业程度的指标之一。通过正确和完整填写软件缺陷数据库的各项内容，可以保证不同测试工程师的缺陷报告格式统一。为了提高报告的效率，缺陷数据库的很多字段内容可以直接选择，而不必每次都手工输入。 第三、实时管理，安全控制。软件缺陷查询、筛选、排序、添加、修改、保存、权限控制是数据库管理的基本功能和主要优势。通过方便的数据库查询和分类筛选，便于迅速定位缺陷和统计缺陷的类型。通过权限设置，保证只有适当权限的人才能修改或删除软件缺陷，保证了测试的质量。 2、满足大型多语言软件测试的需要 软件测试缺陷数据库可以满足大型软件测试项目的需要。大型多语言软件测试的具有以下特征： （1）测试周期较长 通常要测试多个版本(Builds)，跨度达三至六个月或更长。 （2）存在较多软件缺陷 由于软件功能丰富，软件设计结构复杂，规模庞大，需要本地化的资源文件数量多，类型复杂，可能存在数百甚至上千个软件缺陷(Bug)。 （3）测试范围广 从测试内容看，包括功能测试，性能测试，安装/卸载测试，用户界面测试，语言质量测试等。从测试方法看，包括手工测试和自动脚本测试。 （4）对测试质量要求较高 要求发现重要的缺陷，方便的跟踪和及时处理测试发现的缺陷。 （5）多语言软件同时测试 可能需要同时测试多种语言的软件。　 满足如此高质量要求的软件测试，如果项目测试组内部没有高效的软件缺陷管理和控制方式，是很难保证测试质量和测试进度的。测试实践证明，在测试组织不完善的新型测试机构的测试初期，引入内部软件缺陷数据库是很有必要的。 另外，测试人员的不确定性，难以保证新加入的测试成员，能够尽快适应实际测试项目的需要。为了保证测试软件缺陷报告的质量，引入内部测试缺陷数据库，可以从测试工具和测试流程上，保证不同测试技术背景的测试成员书写结构一致的测试报告。 引入内部软件测试缺陷数据库属于软件公司创建测试组织的基础性工作，可以满足现在和今后软件测试业务不断发展的需要。这种基础工作做好了，可以使初期的测试项目顺利实施，也为今后大型测试项目的实施打下良好的基础。 四、结论 引入内部的软件测试缺陷管理数据库可以提高软件测试过程效率，提高软件缺陷报告的质量，编译有效实施软件测试管理，可以满足同时测试多个语言的大型软件测试项目，尤其适合刚刚从事软件测试服务的测试公司的实际软件测试项目的需要。  原文地址：http://www.51testing.com/html/34/1107.html http://blog.bugols.com/topic/4.html 初到现场发现原有的bug跟踪很不方便，则在空闲之余搭建了一个bug跟踪工具。在谈论bug管理的问题中，大家列举了很多bug跟踪软件。但我觉得工具只是一个部分，主要的还是在bug管理的流程上。在这些bug管理工具中，bug的极重要属性就是“状态”。一般可分为“新增（New&Active）”，“处理中（in progress）”，“已修正（Fixed）”，“重新打开（reopened）”，“关闭（Close）”等。 就这几个状态而言，明眼人一看就清楚一个bug从发现到排除要走哪些流程： 1、测试人员发现bug，提交。bug状态为New&Acitve 2、开发人员接收bug。bug状态为in progress 3、开发人员修改完毕并提交。bug状态为Fixed 4、测试人员针对开发人员的解决方案再次对bug进行验证测试。如果bug依然存在，则把bug状态设置为reopened，流程返回至第二步。如果问题已经解决，就直接设置为close。 经过以上四个步骤，整个bug的流程就基本走完了。 看似流程非常简，可是在实际使用中还是会发现一些问题： 1、bug信息不全。       有的信息如项目，模块，指定处理人等。依据这些信息会用来作统计分析，哪个项目，哪个模块，谁的bug多，谁发现的bug多，谁改的bug多等等，则可以大致看出一个人的工作量和工作质量。所以测试人员在填写bug问题单时，不要嫌麻烦。应该把涉及bug相关的信息完全写出来。 2、提供的信息不准确。       有的bug描述一带而过，表述含糊不清。只是说出了错误并没有清楚的描述错误的现象是什么，提示信息是什么，怎么操作才可以出现等。这样的bug交给开发人员，只会给开发人员增加负担。因为当开发人员拿到bug后，发现不明之处还需要再做测试才可发现更多的信息去解决bug。或者与相关测试人员讨论并询问详情，有时要多次在反馈信息当中才能明确bug的目的。这无疑造成了研发周期的无限延长。 3、开发人员关闭bug      只有bug的提交人（也就是发现人）才能关闭bug，开发人员只能使用两种状态，即“处理中”和“已修正”。 4、bug的重要性      这个重要性是在bug管理软件中无法体现和度量的，这个任务主要体现在测试这边。如果当测试人员发现了一个bug，及时与开发人员沟通时无法重现bug，此时连测试人员都不知道这个bug是怎样操作才出现的。对于这样不能重现的bug几乎就不能算是bug，也是最让人头疼的问题。那么作为测试人员，其任务就是要尽可能的找出bug出现的规律。尝试各种可能，即使不能重现也起码要让开发人员知道测试人员是怎么做的，而减少开发人员的再操作的时间。 原文地址：http://www.cnblogs.com/Sayiod/archive/2007/06/13/781592.html http://blog.bugols.com/topic/3.html