软件测试过程中对bug的处理流程
⼜属于⼀篇普及⽂，希望⾃⼰在被各种技术吸引的同时，能时常来整理和总结最基本的知识。
  从刚时接触的第⼀个⼯具禅道，到redmine、JIRA、bugzilla ，再到现在的QC，当然还有其它种的开源的或商业的缺陷管理⼯具，它们的本质是⼀样的，就是来管理缺陷的⽣命周期。
  其实，你理解任意的⼀款⼯具，其它的⼯具也⼀定能⽆师⾃通。这不谈某款⼯具，单把它本质的⼀些东西抽离出来与⼤家分享。
  的属性
  Bug重现环境
  这个应该是我们重现bug的⼀个前提，如果没有这个前提，我们可能会⽆法重现问题，或者跟本就⽆从下⼿。
  这个是⼀般软件运⾏的⼀⼤前提，基本上所有的软件都依赖于操作系统之上的，对于⼀个软件来说，要想在某个操作系统上运⾏，必须要对这个操作系统⽀持，这就需要有真对性的设计与开发。对于不同的操作系统，其可能存在差异（如：win xp 与 win 7）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的⼀个重要前提。
  浏览器
  对于B/S系统，或⾯向⼤众的产品（⽹站，邮箱等），浏览器的兼容性也是必须测试的⼀个重点，对于现在的浏览器市场，各式的浏览器都有其⽤户，要想使产品⼤众化，必须考虑这些产品的兼容性问题。
  不同的浏览器之间（IE、 firefox、chrome、opera 等），甚⾄同⼀系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应⽤，浏览器环境重现bug前提条件之⼀。
  其它（这个“其它”⾮常重要）
  对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现⽹环境，⽽且还要附带⼀重现问题的帐号等。
  对于c/s软件，可能还要考虑与其它常⽤软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使⽤造成影响。这些都是重现问题的必须描述的环境。
  问题类型
  根据JIRA的管理系统的划分，bug 只是问题的⼀种，它可以⽤于跟踪多种不同类型的问题（其实，他只是将bug做为⼀⼦类⽽已）。
  JIRA系统缺省提供的问题类型（⼤部分的系统都可以⾃定义类型的，这样就增加了灵活性。）
  ● Bug ：测试过程、维护过程发现影响系统运⾏的缺陷。（这就是⼀般测试⼈员所提交的bug）
  ● New Feature ：对系统提出的新功能。（单个的⼩需求可以，如果⼤的话，就相当于⼀个需求，放到这⾥是不合理的。）
  ● Task ：需要完成的⼀任务。（开发或测试任务指派。）
  ● Improvement ：对现有系统功能的改进。（⼀般产品经理或产品体验师做的事）
  当然，不同的公司，他们的⼈员定位与职责是不太相同的，按照上⾯的分类，JIRA就不是简单的缺陷管理系统了，它涵盖⼀项⽬（或产品）所需要处理的任务、需求与缺陷。
　Bug 类型：
  这⾥缩⼩范围，单指我们测试⼈员在测试过程中发现的缺陷，发现产品缺陷其实就是测试⼈员⼯作的主要⽬的。当然，你要确定⼀个问题的类型，也需要对项⽬（或产品）有⽐较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分，当然，这个划分，对于开发定位问题影响很⼩，但对于问题类型的统计就⽐较重要了。
  下⾯看⼀些常见的分类：
  划分⽅式⼀：
  代码错误
  设计缺陷
  界⾯优化
  配置相关
  安装部署
  性能问题
  标准规范
  测试代码
  其它
  划分⽅式⼆：
  功能类（function）
  性能类（performance）
  界⾯类（UI）
  易⽤性类（usability）
  兼容性类（compatibility）
  其它（else）
  这个分类当然是可以⾃定义的，具我接触的缺陷管理都是可以⾃定义的，既然是对问题的管理，那么你当然可以拿来做特定环境下的系统来使⽤，或我就想⽤这个系统来指派任务，那么我的⾃定义类型为前端任务、后端任务、测试任务、配置部署...
  缺陷等级
  缺陷等级，这个划分也⽐较灵活，有分三级或四级，也有分五级的。
  致命
  ⼀招毙命的缺陷，使你的系统⽆法运⾏，有造成数据泄漏的安全性问题。
  严重
  可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观难以接受的缺陷。
  ⼀般
  指不影响产品的运转和运⾏、不会成为故障起因，但对产品外观和下道⼯序影响较⼤的缺陷
  轻微
  轻微缺陷是指对产品外观和下道⼯序可能会有轻微影响的缺陷
  建议
  增加⽤户使⽤体验的建议性问题。（⼀般情况下，建议也为做为缺陷的⼀种。这个跟系统的类型与需求有关）
  缺陷优先级（priority）
  当问题处理⼈员在⾯对许多问题需要处理进，就需要问题进⾏优先级排序。我们做事情的安排，操作系统有处理进程等都在使⽤着优先级。
  优先级的划分：
  低——>中——>⾼——>紧急
  延迟处理——>正常排队——>优先处理——>紧急处理
  Bug 的严重程度和优先级是含义不同但相互联系密切的两个概念，它们从不同的侧⾯描述了软件缺陷对软件质量和最终⽤户的影响程序和处理⽅式。
  ⼀般地，严重程序⾼的软件缺陷具有较⾼的优先级。严重程度⾼说明缺陷对软件造成的危害性⼤，需要优先处理，⽽来严重程序低的缺陷可能只是软件不太尽善尽美，可以稍后处理。
  严重程度⾼优先级不⼀定⾼：
  如果某个严重的软件缺陷只在⾮常极端的条件下产⽣，则没有必要马上处理。
  如果某⼀个软件缺陷，需要重新修改软件的整体架构，可能会产⽣更多的潜在缺陷，⽽且软件由于市场的压⼒必须尽快发布，此时即使缺陷的严重性很⾼，是否需要修正，需要全盘考虑。
  严重程度优先级不⼀定低
  如果是软件名称或公司名称的拼写错误，虽然说其属于界⾯错误，严重程度不⾼，但其关系到软件和公司的市场开解，必须尽快修正。
  缺陷状态
  对于⼀个问题，其处理过程是⼀个周期，周期的不同阶段，其所处的状态也是不⼀样的。不同状态所对应的处理⼈也是不⼀样的。
  打开：表⽰问题被提交等待有⼈处理。
  重新指派：问题被重新指派给某⼈处理。
  处理：问题在处理中，尚未完成。
  固定：确认此问题存在，但暂时不进⾏处理。
  回归：对已经修复的问题进⾏回归确认。Reopened ：
  关闭：问题的最后⼀个状态。
  Bug处理流程
  下⾯通过⼀个⽐较完整的bug的处理流程图，更深刻的理解bug的状态以⼀个bug的⽣命周期。
  提交（打开）缺陷
  在提交⼀个缺陷的缺陷，⾸先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
  当然，我们在提交⼀个问题之前⾸先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。
  如果是回归不通过的缺陷，其状态⼜会变为打开状态。
　分配（转交）缺陷
  这⼀步不是必须的，跟项⽬模式有关，有些公司测试部门与开发部门独⽴，那么测试⼈员就不确定⾃⼰测试的模块是由哪位开发⼈员负责的，在这种情况下，测试⼈员统⼀把问题指派给项⽬组长或经理，由项⽬组长（或经理）对问题进⾏确认后再次分配给相应的开发⼈员。
  有些测试⼈员是穿插到不同研发团队中的，所以对不同的开⼈发员负责的开发模块⾮常清楚，这个时候就可以将问题直接指派给相应的开发⼈员。
  也有⼀种情况，本来此问题应该由A开发⼈员负责，但由于A开发⼈员的调离或辞职，些问题为转交给其它⼈员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
  确认缺陷
  当开发⼈员接到⼀个缺陷时，⾸先是对其进⾏分析与重现，如果对其进⾏分析发现不是缺陷（可能由于测试⼈员不了解需求）或⽆法对此问题进⾏重现，那么就需要将此问题反回给测试⼈员，并注明原因。如果确认为缺陷则需要对其进⾏处理。
  推迟处理
  在处理问题之后，还需要进⾏⼀次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进⾏改动，或其优先级⾮常低，所以暂时不需要对此问题进⾏处理（或到下个版本进再进⾏修复）。
  固定
  对于推迟处理的问题可以暂时进⾏固定（“固定”为QC中的叫法。）⼀般固定的问题需要经过项⽬经理与测试经理协商后才能固定。
  处理缺陷
  开发⼈员在确认完⼀个问题需要处理时，那么就对其进⾏处理⼯作。（例如，redmine 是⽀持处理⼈时时更新问题处理进度的，如已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
  回归缺陷
  回归缺陷对于测试⼈员来说是⾮常重要的⼯作，其有三个⼊⼝两个出⼝。
  确认⾮缺陷问题：对于提交的⼀个缺陷，开⼈员处理为⾮问题或⽆法重现，然后直接转交给测试⼈员回归。测试⼈员再次确认，如果真如开发⼈员所说，则将问题关闭。如果⾮开发⼈员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发⼈员。
  确认修复问题：对开发⼈员修复的问题再次进⾏确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发⼈员。
  确认固定问题：有计划的对固定问题进⾏确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发⼈员处理。
  关闭缺陷
  对于已经修复的缺陷进⾏关闭，这也是⼀个缺陷的最后⼀个状态。
  --------------------------------------------------------------------------------
  注1：⽂中提到了产品与项⽬，好多⼈分不清项⽬与产品，各⾃有各⾃的理解。我个⼈从⽤户上来划分。如果⾯向的是特定客户的需求，那么称其为项⽬，如某医院的医疗系统，某公司的管理系统。⾯向⼤众⽤户且长期运营的需求，称为产品，如，某⽹站，某⽹络游戏。
  如果⼩A让我给他做⼀个⽹站呢？对于我来说，⼩A是我的客户，这个⽹站对我来说就是⼀个项⽬，对于⼩A来说，他的⽹站是⾯向⼤众⽤户的，那么对于⼩A来说，⽹站就是⾃⼰的产品。
  富⼠康带⼯苹果⼿机是⼀样的道理，富⼠康接到苹果的订单，那么对富⼠康来说是个项⽬，完成项⽬，拿到钱就算项⽬结束。苹果⼿机对苹果公司来说是⼀个产品，它长期持有这个产品的所有权，并且不段的更新⾃⼰的产品。
  注2：本⽂中⽤到了 bug、缺陷、问题等三个词语，⽤词⽐较模糊，本⽂中表⽰为⼀个事物。
　分配（转交）缺陷
  这⼀步不是必须的，跟项⽬模式有关，有些公司测试部门与开发部门独⽴，那么测试⼈员就不确定⾃
⼰测试的模块是由哪位开发⼈员负责的，在这种情况下，测试⼈员统⼀把问题指派给项⽬组长或经理，由项⽬组长（或经理）对问题进⾏确认后再次分配给相应的开发⼈员。
  有些测试⼈员是穿插到不同研发团队中的，所以对不同的开⼈发员负责的开发模块⾮常清楚，这个时候就可以将问题直接指派给相应的开发⼈员。
  也有⼀种情况，本来此问题应该由A开发⼈员负责，但由于A开发⼈员的调离或辞职，些问题为转交给其它⼈员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
  确认缺陷
  当开发⼈员接到⼀个缺陷时，⾸先是对其进⾏分析与重现，如果对其进⾏分析发现不是缺陷（可能由于测试⼈员不了解需求）或⽆法对此问题进⾏重现，那么就需要将此问题反回给测试⼈员，并注明原因。如果确认为缺陷则需要对其进⾏处理。
  推迟处理
  在处理问题之后，还需要进⾏⼀次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进⾏改动，或其优先级⾮常低，所以暂时不需要对此问题进⾏处理（或到下个版本进再进⾏修复）。
  固定
  对于推迟处理的问题可以暂时进⾏固定（“固定”为QC中的叫法。）⼀般固定的问题需要经过项⽬经理与测试经理协商后才能固定。
  处理缺陷
  开发⼈员在确认完⼀个问题需要处理时，那么就对其进⾏处理⼯作。（例如，redmine 是⽀持处理⼈时时更新问题处理进度的，如已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
  回归缺陷
  回归缺陷对于测试⼈员来说是⾮常重要的⼯作，其有三个⼊⼝两个出⼝。
  确认⾮缺陷问题：对于提交的⼀个缺陷，开⼈员处理为⾮问题或⽆法重现，然后直接转交给测试⼈员回归。测试⼈员再次确认，如果真如开发⼈员所说，则将问题关闭。如果⾮开发⼈员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发⼈员。
  确认修复问题：对开发⼈员修复的问题再次进⾏确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发⼈员。
  确认固定问题：有计划的对固定问题进⾏确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发⼈员处理。
  关闭缺陷
  对于已经修复的缺陷进⾏关闭，这也是⼀个缺陷的最后⼀个状态。
  --------------------------------------------------------------------------------
前端测试和后端测试的区别  注1：⽂中提到了产品与项⽬，好多⼈分不清项⽬与产品，各⾃有各⾃的理解。我个⼈从⽤户上来划分。如果⾯向的是特定客户的需求，那么称其为项⽬，如某医院的医疗系统，某公司的管理系统。⾯向⼤众⽤户且长期运营的需求，称为产品，如，某⽹站，某⽹络游戏。
  如果⼩A让我给他做⼀个⽹站呢？对于我来说，⼩A是我的客户，这个⽹站对我来说就是⼀个项⽬，对于⼩A来说，他的⽹站是⾯向⼤众⽤户的，那么对于⼩A来说，⽹站就是⾃⼰的产品。
  富⼠康带⼯苹果⼿机是⼀样的道理，富⼠康接到苹果的订单，那么对富⼠康来说是个项⽬，完成项⽬，拿到钱就算项⽬结束。苹果⼿机对苹果公司来说是⼀个产品，它长期持有这个产品的所有权，并且不段的更新⾃⼰的产品。
  注2：本⽂中⽤到了 bug、缺陷、问题等三个词语，⽤词⽐较模糊，本⽂中表⽰为⼀个事物。
====================================分割线================================

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。