缺陷管理作为软件质量管理的重要组成部分,正在成为软件开发管理过程的又一亮点，因为国内外越来越多的公司进行相关管理工具的开发到人们对缺陷管理工具的需求逐渐增多而且更加明确,同时渴望能够得到物美价廉的可用版本(当然大多数都有免费的试用板)。缺陷管理的重要性和被人们所给予的重视程度可见一斑。下面先让我们看看国际、国内比较知名的缺陷管理软件各有何特点。

continue reading "国内外流行缺陷管理工具比较"

某甲问道：「测试做太多的话，会不会使得bug解不完？」某乙回答：「还不简单。只要不做测试，就没有bug。」上述对话，反应出许多软件工作人员对于测试的想法。对多数软件开发人员而言，测试大概是仅次于维护之外，最令人讨厌的工作。对软件研发主管来说，测试是必要之恶：做得不够后患无穷，做得过多又增加成本，延误商机。因此，如何能够规画与执行一个最经济有效的测试工作，当是软件研发主管们须研究的一个课题。

软件测试的困难，在于它不仅是产品的测试，更是产品设计程序的检验。由于关乎设计的测试，准则不易寻找，经验未必得以再用，他山之石也有应用的局限性，因此难度颇高。欲提高测试的效益，有赖全盘的规画，确实的执行，与事后的检讨改进动作。许多小型软件研发单位，对于软件测试并不重视，但从许多稍具规模的软件公司均配置常设测试人员，乃至于测试品保部门来看，测试工作显然有其学问与价值的。

continue reading "软件测试管理经验谈 (转)"

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。

    错误跟踪管理系统

    为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。
    目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、
Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。
    作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。
    正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。

continue reading "软件测试的重要环节：Bug管理的一般流程"

 一、概述

测试质量和效率是软件测试的重要内容，其中对软件测试过程发现的软件缺陷（Bug）的管理具有重要作用。

软件测试缺陷管理数据库是管理软件测试缺陷的专用数据库系统，可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

实际测试项目实施之前，客户都提供通过因特网访问的项目公共数据库。由于通过因特网访问速度比较慢，客户只给项目中的少数人登录权限，所以，不能满足测试组每个成员都可以方便地访问数据库。更重要的，如果每个测试工程师都各自直接向项目公共数据库报告和修改软件测试发现的缺陷，由于每个人软件测试的经验背景不同，很难控制报告的缺陷质量，也不利于保持软件缺陷报告的一致性。所以，为了保证报告软件缺陷的质量和格式的一致性，需要测试小组内部指定具有测试经验的人员验证和审查小组内部报告的软件缺陷，然后再通过因特网，统一报到项目公共数据库中。

据调查，很多从事多年软件测试的公司，都有内部的软件测试缺陷管理数据库。这些内部数据库大部分是公司内部开发的，也有一些是直接从市场上购买的。公司内部开发的功能更符合实际要求、具有良好的扩展性。直接购买的数据库节约了开发成本，但是往往价格较高，很多功能根本用不上，造成经济上的浪费。

大型的软件测试项目，需要多人组成一个或多个测试小组，通过有效管理和内部交流才能保证测试项目的顺利实施。因此，如果再单纯采用内部电子邮件的方法管理测试的软件缺陷，将造成测试项目实施过程中，软件测试缺陷的交流效率低，缺陷的流程管理难以实时控制。

continue reading "试论软件缺陷内部数据库的重要性"

初到现场发现原有的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