Bug 的生命流程从新增的 opened 状态开始，到 closed 状态结束，简单而言， Bug 核心跟踪管理流程应该包括：

1、  Bug 新增：测试人员发现 Bug 之后新增一个 Bug ，并将 Bug 指定给对应的开发负责人， Bug 状态为 待 DEV 处理 。 Bug 新增成功后，只有开发负责人才有权限回复这个 Bug ，其它人只能查看或追加回复。

2、  Bug 审核：测试人员提交 bug 之后，应该由测试经理和项目经理对 bug 进行审核，审核 Bug 的优先度、哪些 Bug 可以等到下个里程碑或版本中解决、对问题有何修改建议。这一步非常重要，避免由于测试人员的素质参差不齐而导致的软件质量问题。

3、  Bug 回复：开发人员修改问题之后，将 Bug 回复给对应的测试负责人， Bug 回复后，只有测试负责人才有权限跟踪回复或关闭这个 Bug ， Bug 状态为 待 QA 确认 。开发人员回复 Bug 之后，测试人员会进行验证，如果问题还没解决，则将这个 Bug 重新回复给开发人员，并且在回复中进行详细的问题描述。测试人员回复此 bug 给开发人员之后， Bug 状态又转为 待 DEV 处理 。

4、  Bug 回复审核：开发人员修改问题之后，应该由测试经理对 bug 进行审核，检查 bug 的修改处理方法是否正确。

5、  追加回复：一个 Bug 的记录不能删除或修改，只能够新增，如果测试人员或其它开发人员或项目经理想对 Bug 增加说明，可以通过追加回复进行。

6、  Bug 关闭：开发回复 Bug 之后，测试负责人验证该 Bug ，如果问题得到解决则关闭（否则回复给开发负责人，让其继续追踪）， Bug 状态为 问题解决 。

7、  Bug 查询：输入查询条件，查询对应的 Bug 。

8、  Bug 删除：删除 Bug ，但这个记录不会被删除，也就是说只是做一个特殊的标志，没有真正删除。

9、  Bug reopen ：在后续测试中又出现了相同或类似的问题，重新打开此 Bug 。

10、              Bug 统计：输入统计条件，统计对应的 Bug 。

     结合实际测试的步骤，完整的 Bug 的流程如下图所示：

二、             Bug 跟踪管理系统

Bug 跟踪管理系统用于帮助公司和团队跟踪工作中的问题，管理和记录这些问题的处理过程，并为用户提供事务分配和自动通知的平台。 Bug 跟踪管理系统对于一个团队的 Bug 管理非常有效，可以确保每个出现的问题都可以得到记录和跟踪，为团队提供有效的交互平台，提高团队效率和增强团队工作氛围。同时，作为问题记录的数据库，可以积累处理问题的经验，也可以轻松吸取他人经验，对以后维护也很有帮助。

对于比较大型的公司或开发团队，比较倾向于自己开发符合自己需求的 Bug 跟踪管理系统，除了缺陷跟踪外，还可以对工程需求、分析设计、任务管理、工程故障等进行管理；而对于一个小型团队，可以使用现成的 Bug 跟踪管理工具，有些工具也是开源的，可以自己很方便的修改，对于小团队来说它所提供的功能也已经够用了。常见的缺陷跟踪工具有 Rational ClearQuest 、 Bugzilla 、 Testtrack pro 、 source forge 、 teamshare 、 PVCS Tracker 、 TestDirector 、 Track+ 和 Wicresoft BMS 。我个人偏向使用 Testtrack pro ，比较友善简单。不管是自己开发的管理跟踪系统还是 bug 管理工具，都只是工具而已，真正要做的是流程上的管理。

                                  Written by smilings in GuangZhou,May 26th

1、  功能测试：根据系统需求文档和设计文档，检查产品是否正确实现了功能。

2、  边界测试：边界值测试顾名思义也就是选择边界数据进行测试。边界值往往更加容易出现问题，特别是在条件判断情况下，边界值必须要测试。选择边界测试用例的原则：

（1）  如果输入条件规定了值的范围，则应该取未达到这个范围的边界值、刚达到这个范围的边界值、以及刚刚超过这个范围边界的值作为测试数据；

（2）  如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多 1 个、比最小个数少 1 个的数作为测试数据；

（3）  如果输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例；

（4）  如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例。例如：一条短信内容最大长度为 140 个字节，边界值测试可以分别发送短信内容长度为 0 字节、 139 个字节、 140 个字节、 141 个字节的短信，检查系统是否处理正常。

3、  异常测试：除了基本功能测试外，测试人员在测试的时候应该考虑系统可能出现的异常，以及异常出现时系统处理情况。

（1）  频繁启停某接口，检查与该接口相连接的模块能否正常退出与连接。

（2）  系统资源到达极限（比如线程池满），检查系统能否正确处理。

（3）  连接出现异常（比如与数据库的连接失败），检查系统能否正确处理。

（4）  登录失败（比如登录智能网预扣费系统失败），检查系统能否正确处理。

（5）  对方接口没响应，检查系统能否正确处理。

（6）  对方接口不返回状态报告，检查系统能否正确处理。

（7）  软件产品处理能力到达极限，检查系统是否做了保障处理。

（8）  输入特殊符号或内容，检查系统能否正确处理。

4、  性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。经常和压力测试一起做。

5、  压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力。通过大压力测试，检查程序是否稳定（也就是是否出现 coredump ），是否出现内存泄露，是否出现 CPU 暴涨，业务流程是否顺畅，是否导致异常出现等等。

6、  易用性测试：从用户的角度考虑问题，如果这样的一个系统给用户使用，用户是否觉得操作方便？用户可能犯的错误系统是否已经做了处理？测试除了基本的功能、满足基本需求外，还需要站在用户使用的角度上去审核产品，毕竟，产品做出来就是给人使用的。以人为本，我们才能够有更长远的发展。这一点，无论是开发人员还是测试人员，都应该有一个强烈的意识。

7、  界面测试：检查界面是否美观、是否符合系统需求、操作是否方便等。界面的测试也相当重要，测试的时候应该从整体的角度考虑这样的界面是否是客户所需要的。

8、  安装测试：在测试环境中安装一个新的软件产品，检查新安装的系统能否正常运行，核心功能是否正确。

9、  升级测试：在测试环境当前版本升级到软件最新版本的测试，检查新安装系统能否正常运行，核心功能是否正确。同时，记录升级步骤，提供升级参考依据。

10、              恢复测试：测试一个系统从如下灾难中能否很好地恢复以及恢复所需要花费的时间和步骤等，如遇到系统崩溃、硬件损坏或其他灾难性问题。

11、              停止 / 启动测试：检查程序能否正常启动、停止，使用异常方法停止之后能否正常启动。比如：现有 smfilter 这个模块，使用异常的方法停止 smfilter （如 fuser –k smfilter ），然后再重新启动 smfilter （如 smfilter start ），看看模块能否正常启动。

12、              配置测试：主要是针对配置文件进行的测试，通常检查点包括：

（1）  检查不同配置项的值能否实现该配置所对应的功能。

（2）  检查边界配置能否实现对应的功能。

（3）  考虑异常情况，如果配置在非正常值之内，系统能否正常处理或者是否有足够的提示。

（4）  如果配置项涉及到性能，还需要测试怎样配置能够达到最优化配置，提供配置参考方案和原理。

13、              兼容测试：测试软件在一个特定的硬件 / 软件 / 操作系统 / 网络等环境下系统功能运行情况、性能数据。

14、              文档测试：检查文档是否完整、内容描述清晰性和准确性。对外部文档而言，还必须考虑文档的简单明了，相关的技术术语是否解释清晰等方面的检查。

15、              接口测试：接口测试包括内部接口测试和外部接口测试，内部接口测试一般在集成测试中进行，通过模块之间的联调发现内部接口的问题。外部接口测试一般在系统测试中进行，检查软件产品与其它应用系统的接口是否正常。比如：检查软件产品接口与银行计费接口是否联接正常、功能能否实现等。

16、              安全测试：测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。

17、              确认测试：在产品发布前，对照 feature list 进行基本需求的确认。确认产品是否正确实现了功能。

18、              系统测试： : 基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。

1、  需求调研

在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

2、  制定测试计划

进行每一种测试之前，测试负责人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施。

3、  需求Review

开发在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，对需求分析文档进行Review，检查文档是否满足了需求，是否与需求一致等等。

4、  设计Review

在软件分析设计阶段，测试人员参与设计讨论，了解系统的实现方式和原理，并对概要设计和详细设计提出自己的见解。设计结束之后，开发提交概要设计文档和详细设计文档，测试人员对设计进行Review，检查设计规划和实现方案是否合理，如果不合理，存在的问题是什么、如何改进等等。

5、  测试设计

在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试， 将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。 然后以 功能点分析文档作为依据 进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。每个测试用例必须包括以下几个部分：

（1）       标题和编号

（2）       测试的目标和目的

（3）       输入和使用的数据和操作过程

（4）       期望的输出结果

（5）       其他特殊的环境要求、次序要求、时间要求等

6、开发测试工具和准备测试数据

   在软件测试中，为了提高测试工作的效益和质量，只要条件许可，应尽可能采用计算机自动或半自动测试的方法，利用软件工具本身的优势来提高工作效率。

7、测试

当所有必需的测试准备工作都已完成，并且产品已经开发完毕并提交测试，则可以按照预定的测试计划和测试方案逐项进行测试。在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录。为了能准确的找出问题产生的原因，及时的解决问题，保证测试工作的顺利进行，一般来说所发现的问题必须是能够重视的。

8、回归测试

   在测试中发现的任何问题和错误都必须有一个明确的解决方法。一般来说，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试。另一方面，对于版本更新后的软件也必须进行同样的测试过程。

9、测试分析报告

   测试结束后要及时地进行总结，对测试结果进行分析，由测试负责人提交“测试分析报告”。

10、产品发布

   测试完毕，整理产品发布包和相关文档并发布。对于新产品来说，必要的文档必须包括：

（1）       安装操作手册

（2）       产品白皮书

（3）       管理维护手册

（4）       用户操作手册

（5）       测试报告

11、版本控制

新版本软件发布之后，马上对代码进行质量控制。

（1）  Build Master 给新版本的 源 代码打一个 cvs tag ，方便代码回滚 check out 。比如，发布版本为 p2p3.3.2 ，则给该软件 源 代码也打一个与发布版本相同名字的 tag p2p3.3.2 。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要 check out 某个版本的 源 代码，则可以通过这个版本的 tag 来 check out ，代码的修改可以在该版本上进行。

（2）  Build Master 对新发布的软件 源 代码进行 cvs lock ，不允许开发人员在软件发布之后 commit 源代码，直到有新版本需求修改再给开发人员开放 commit 权限。这样做的好处是避免开发人员随意修改和 commit 源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。

二、 工程维护管理流程

1、  收集新需求：新功能和不紧急的故障，其代码的修改操作不必马上进行，取而代之的是做好新需求与故障统计；对已经确认的故障也可以先在 bug 管理系统报 bug ，但只是记录，不需求马上修改。当然了，对于紧急的工程故障，需要马上修改和测试。

2、  确认新需求：与工程人员或客户或产品经理确认新需求，确保需求被理解正确。

3、  需求讨论：当需求与故障积累到一定数量或者工程有新版本需求，进行一次发布测试，在新版本开始修改之前把近期积累的需求与故障整理，与相关开发人员、测试人员、项目经理和测试经理讨论，确认哪些新功能可以实现、新功能的实现方法与业务流程、新功能开发修改时间、测试版本、测试时间与发布时间。

4、  在 bug 跟踪管理系统报 bug ：确认所有需要修改的新功能和需求录入 bug 跟踪管理系统，并在 bug 跟踪管理系统中详细描述新功能需求和解决方法，同时整理相关 bug 列表，交付开发修改。

5、  制定测试计划：

A、 根据用户需求，定义并完善测试需求，作为测试的标准

B、 确定重点测试事项，哪些功能需要重点测试

C、 测试时间计划，并详细计划具体测试任务与时间

D、  风险说明

E、 测试准备，提前对测试环境和测试资源进行准备

F、 发布具体时间

G、  资源需求：包括测试人员、硬件需求、软件需求和培训计划

6、  编写测试案例：根据功能需求编写测试案例

7、  测试开发：开发自动测试脚本，补充自动测试案例

8、  测试实施：按照测试计划进行测试，发现并申报 bug

9、  测试评估：

A、 哪些需求通过了测试

B、 有哪些遗留问题

C、 测试效率评估

D、  开发质量度量和评估

E、 并根据评估编写测试报告

10、              发布新版本：

A、 编写新功能文档，给工程提供新功能说明

B、 编写升级文档，给工程提供升级参考方案

C、 软件发布，包括新版本软件、新功能文档、升级文档和测试报告

11、              代码版本控制：新版本软件发布之后，马上对代码进行质量控制。