巧破软件测试缺陷管理之痛[2] 软件测试
一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升，而发现缺陷数曲线应总体趋于下降。同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。项目经理可通过持续观察这张图表，确保项目开发健康发展。同时，通过分析预测项目测试缺陷趋于零的时间，以制定产品质量验收和发布的时间。
实际上，BUG分析图表会告诉我们很多有价值的信息。比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，却到了某个点发现的故障数反而呈上升趋势，那么意味着往往有一些特殊事件的发生。通过对测试缺陷分析，能够给予我们很多改进研发和测试工作的信息。
(3)发布BUG分析经验,提高团队成员能力
分析得出来的BUG实践经验应该被记录并发布，这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库，这将使得新的知识在项目内流动并被相关的开发人员所学习。
BUG分析带来了很多的好处。第一个好处就是帮助产生BUG的开发人员总结经验，并使他在将来避免类似的BUG。有时只修正一个具体的BUG而不去分析它产生的原因并不会帮助开发人员在日后得到提高，只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。
从这个角度来看，BUG分析的价值不仅仅是缺陷的预防，更大的好处是通过记录和分析BUG，项目内的其他开发人员知道如何发现类似的错误。所以，我们可以通过某个开发人员产生的一个BUG提高整个项目团队的实践经验，而不仅仅是尽快修正它。这样，因为一个缺陷所浪费的时间也可以转化为收益：确保类似的错误不会再发生。除了分享项目内的测试知识和经验，BUG分析过程还可以促进开发更好的测试技术和工具，从而帮助发现类似的BUG。
如何高效地进行缺陷管理
(1)清晰缺陷分类，明确处理责任
首先要改变以前那种凡是BUG就是由开发人员负责的观念。跟据缺陷内容可分为需求BUG与程序BUG。对于程序BUG是由相关开发人员进行处理，需求BUG则要交由需求人员进行处理，对于这种分法的好处就是明确了BUG处理的责任人。
测试人员从本质上来说与程序员还是对立的，如果为了一个不是软件程序本身的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况。测试人员协调好与开发人员的关系，可让他们更高效的关注软件本身的缺陷。
(2)建立缺陷处理流程，减少无效运作
建立缺陷处理流程，这对测试人员和开发人员来说都是很有帮助的。BUG处理流程其实就是定义BUG处理过程的职责和权限，用明确的流程去指导如何对BUG进行日常管理，提高运作效率。
(3)使用缺陷管理工具:BUG管理库
为了跟踪和控制测试质量，便于管理测试发现的BUG，我们需要为项目配置一个专用的缺陷跟踪数据库，以便报告、查询、分类、跟踪、处理和验证缺陷。因此，开发过程中使用一套BUG管理工具是非常必要。
缺陷管理工具应便于项目组和管理人员获取正确、足够的信息，以简化信息共享流程，最大限度减少重复工作。BUG管理库就是记录、评估缺陷，并执行及维护系统配置，创造一个高效管理环境的最好工具。例如使用缺陷管理库可以很方便制作各种缺陷分析图表，从而预测项目风险或解释测试结果。整个开发过程是BUG数从少到多，再到少的过程。从BUG数量的变化，也可以推断软件产品的成熟性，推断产品的发布期。
(4)把管理制度和配置策略相结合
有了先进的缺陷管理工具，还需要有相应的管理制度与之相配套，否则BUG管理就只是一个摆设。目前BUG管理制度方面主要的问题是不重视测试，认为测试人员无关大局，随便测测就行了，再或者就是虽然认识到测试的重要性，但却走向了极端，制定了极其严格的规章制度。
例如无数琐碎、难用的测试工单，非常严密的层级权力控制等。把一个需要灵活变化的工作变成了工业制造车间流水线的一个工种，让测试人员陷入制度的泥潭，不能把主要精力投入测试工作本身。再或者就是项目负责人也没有制订明确的BUG处理流程及相关指导原则，让测试人员在黑暗中摸索，走到哪儿算哪儿，不能给他们以切实有效的指导和帮助，把软件的质量保证责任一股脑推到测试人员身上，任何问题都去指责测试人员。
最后，BUG管理制度还有一种常见的错误考核制度，就是项目主管用BUG个数去衡量测试人员的工作成绩，谁发现的BUG多谁的工作就做的好。这是一个十分危险的倾向，将直接导致测试人员去重视BUG个数这个数字本身、而不是产品的真正质量。最后重申强调一点：BUG不仅仅是被修正，更重要的是根据BUG管理来提高软件产品质量。
文章来源于领测软件测试网 https://www.ltesting.net/
