软件错误跟踪处理流程

guanyufeng · 发表于 2006-4-6 14:28:39

我也是初学者，说得不好前辈不要见怪。一直在论坛潜水学习，总觉得很对不住大家，发点资料给比我更新的新人吧，但愿对他们有帮助。
测试最重要的感觉就是BUG提交的流程了，我们小组现在就使用的一个开源的BUG管理软件来管理BUG的，我也是修改了很多次才修改成现在的样子，无私的奉献给大家吧。
让我郁闷的是公司新来了一个号称有5年工作经验的管理测试的人，前些天出了一份类似于我这个流程的管理流程，公司副总还把我叫过去告诉我要快点向他学习-_-,但是~~~不说了，我这个流程是完全按照我们产品研发现有资源制定出来的，也参照了一些其他的资料，完全符合于我们现行的工作模式，肯定有很多不足之处，并不是通用版哦~望前辈们海涵。

软件错误跟踪处理流程
　　为了跟踪和控制测试质量，便于管理测试发现的Bug，现已经配置好一个专用缺陷跟踪数据库（http://192.168.0.81/bugtracker/），以便报告、查询、分类、跟踪、处理和验证错误。
　　为了保证发现和报告的错误质量，需要首先由测试经理（暂由吕洪强）在缺陷跟踪数据库中对新发现的错误进行确认，如果确实属于错误，再由错误修复工程师进行修复处理。　
1. 软件错误的状态
• 新错误(New)：测试中新报告的软件缺陷。（测试人员）
• 更多新信息（New More Info）：软件工程师认为报告的错误信息不完整，要求错误报告者添加更准确的错误信息。（开发经理、软件工程师）
• 打开 (Open)：错误被确认并分配给相关软件工程师处理。（开发经理）
• 拒绝(Declined)：拒绝修改缺陷。包括两种情况：
o 拒绝-不是错误（Declined-Not Bug）：报告的错误不是错误。（开发经理、软件工程师）
o 拒绝-重复（Declined-Duplicated）：以前已经报告过这个错误，测试经理或者软件工程师需要指出已经报告过的错误标识编号。（开发经理、软件工程师）
• 已修正(Fixed)：软件工程师已完成修正，等待测试人员验证。（开发经理）
• 重新打开（Reopen）：没有正确修复的错误，需要进一步修复。（测试人员）
• 延期(Deferred)：不在当前版本修复的错误，以后的版本修复。包括两种情况：
o 延期-下个版本（Deferred –Next Build）：下一个新版本修复。（开发经理、软件工程师）
o 延期-指定日期（Deferred –Next Date）：可能错误比较复杂，没有好的思路，并且不影响其他研发，可根据研发时间确定其他日期进行修复，软件工程师需要确定XX日期之前修复。（开发经理、软件工程师）
• 关闭(Closed)：错误已被修复。（测试人员）
2. 软件错误类型：（灵活掌握）
• 界面错误：
      A.界面、控件、焦点、格式等不美观、不合理、不统一、不全面。
      B.提示信息不准确、不够全面
      C.文字性的错误
• 　性能错误
A.多出现在服务器端达不到一般性能指标。
B.客户端主要表现在内存、CPU等占用率过高，引起系或其它应用软件不稳定或冲突等。
• 功能错误
A.重复的、多余的功能
B.软件功能没有达到设计要求
C.流程不正确
• 建议类
A.无论哪方面建议，总之就是建议啦
3. Bug管理的一般流程
　　测试人员提交新的错误入库，错误状态为新错误（New）。
　　测试经理验证错误，如果是重复报告的错误，则设置为拒绝-重复（Declined-Duplicated）状态，并指出与哪个已经报个错误重复（注明标识编号ID#）。否则，如果确认是错误，分配给相应的软件工程师，设置状态为打开（Open）。如果不是错误，则拒绝，设置为拒绝-不是错误（Declined-Not Bug）状态。
　　软件工程师查询状态为打开（Open）的错误，如果因为错误的信息不完全，没法重现错误，则设置状态为更多新信息（New More Info）；如果不是错误，则设置状态为拒绝-不是错误（Declined-Not Bug）；如果是错误则修复，设置状态为已修正（Fixed）。对于当前版本不能解决，准备下一个新版本处理的错误，要留下处理注释，设置错误为延期-下个版本（Deferred –Next Build）状态。如果错误比较复杂或者没有好的思路，要留下处理注释，设置错误为延期-指定日期（Deferred –Next Date）状态。
　　对于不能解决和延期解决的错误，不能由软件工程师自己决定，一般要通过某种会议（评审会，至少测试经理与研发经理）通过才能认可。
　　测试人员查询状态为已修正（Fixed）的错误，然后验证错误是否已修复，如果已经修复，设置错误的状态为关闭（Closed），如没有解决置状态为重新打开（Reopen）。
4. 软件错误流程管理要点
• 为了保证错误的正确性，需要有丰富经验的人员验证和确认发现的错误是否是真正的错误，测试步骤是否准确、简洁、可以重复。
• 软件错误的确认并不总是轻而易举的事情。由于对软件设计具体要求的不了解，对测试报告的个别软件错误，可能无法确认是否属于真正的软件错误，测试经理与开发经理需要沟通并确认。
• 每次对错误的处理都要保留处理信息，包括处理者姓名，时间，处理方法，处理步骤，错误状态，处理注释等。
• 对错误的拒绝不能由软件工程师单方面决定，应该由研发经理，测试经理共同决定。
• 对错误延期处理不能由软件工程师自行决定，应该由研发经理决定。
• 错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。
5. 优先级别的解释
1) 低：一般建议或者不影响产品继续使用的BUG。
2) 中：产品次要功能出现错误，或者影响产品主要技术指标的重要建议。
3) 高：主要功能模块出现错误，影响产品主要技术指标。或者主要功能丧失，或者导致系统出现严重问题或致命错误，以及因软件原因导致系统死机、数据丢失等。

下面以一个错误的处理过程为例，给出一般的处理流程图。

[ 本帖最后由 guanyufeng 于 2006-4-6 15:55 编辑 ]