软件测试笔记（二）软件开发，测试，BUG的生命周期

生命周期

无论是产品的开发，软件的测试，还是BUG都会有属于自己的生命周期，了解了这些生命周期和它们之间的内在联系，可以让我们更好的理解软件，测试和缺陷管理，同时可以帮助梳理我们平时工作中的一些任务和其在不同生命周期的定位。

软件的开发生命周期（SDLC）

什么是软件开发的生命周期？

软件项目中遵循的流程，以系统的方式开发产品并交付高质量的产品。通过遵循正确的软件开发流程，软件公司可以很好地应对市场压力并发布高质量的软件。

从需求阶段到部署和维护阶段，每个阶段都会产生生命周期下一个阶段所需的可交付成果。需求被转化为设计。根据设计生成代码。应根据要求对已开发的产品进行测试。测试完成后应立即进行部署。它的目的是创建一种高质量的系统，该系统可以满足或超出客户的期望，可以在当前和计划中的信息技术基础架构中有效且高效地工作，维护成本低廉，并且可以提高成本效益。下面就是一个标准的软件开发的生命周期图。

软件开发的生命周期的意义？

可能有同学会有疑问了，即使没有这样一整套完整的软件开发的生命周期，我们也可以同样开发产品？

其原因有下面几点：

• 它给产品的相关利益者提供了项目计划的可见性
• 同样可以帮助我们避免项目中会出现的一些风险
• 同第一点类似，它使我们能够跟踪和控制项目
• 因为每一个过程都会有可交付成果，所以我们可以保证每一个环节都是正确的，最终保证产品的顺利交付

软件开发的生命周期的每一个环节

• 需求收集阶段
  需求收集和分析是软件开发生命周期中最重要的阶段。业务分析师根据客户的业务需求从客户/客户那里收集需求，并按照规范记录需求（文档名称因公司的定义而有所差异。例如，客户需求规范文档（CRS），业务规范文档（BS），等，并提供给开发团队。
• 需求定义阶段
  需求收集和分析完成后，下一步就是定义和记录产品需求，并获和客户沟通并且得到认可。这是通过SRS（软件需求规范文档）完成的。 文档中会包括在项目生命周期中要设计和开发的所有产品要求。此阶段涉及的关键人员是项目经理，业务分析师和团队的核心成员。此阶段的结果是软件需求规范。
• 产品设计阶段
  它有两层设计。第一层是产品的框架设计，它提供了要开发的软件产品的体系结构，由架构师和高级开发人员完成。第二层是定义产品中的每个功能应如何工作以及每个组件应如何工作，通常是接口设计。这些设计文档将作为下一个环节的输入。
• 产品研发阶段
  此阶段涉及所有开发人员。这是我们开始构建软件并开始为产品编写代码的阶段。此阶段的结果是源代码文档（SCD）和开发的产品。
• 产品测试阶段
  软件准备完成后，将其发送到测试部门，由测试团队针对各种缺陷对其进行全面测试。他们要么手动测试软件，要么使用自动测试工具，取决于STLC（软件测试生命周期）中定义的各个过程，并确保软件的每个组件都能正常运行，并且符合产品的需求文档。质量保证一旦确定软件没有错误，就进入下一阶段部署。这个阶段测试会对产品有个完整的质量评估。
• 产品研发阶段
  在成功测试之后，该产品将交付/部署给客户。部署由部署/实施工程师完成。一旦客户开始使用开发的系统，实际问题就会浮出水面，需要不时解决。解决客户发现的问题是在维护阶段。无法进行100％的测试-因为测试人员测试产品的方式与客户使用产品的方式不同。针对于这些问题，产品研发团队会通过补丁包或者更新版本来解决客户遇到的问题。

软件开发生命周期模型的类型：

软件开发的生命周期的每一个环节和活动是固定的，针对于这些环节我们有不同的软件开发生命周期模型。比如说经典的瀑布模型和比较火热的敏捷开发流程，下面简单聊一下这两个模型。

• 瀑布模型
  瀑布模型是传统和经典的模型。这是一种顺序设计过程，通常在SDLC中使用，在该过程中，进度被视为像瀑布一样自上而下的流动，经过需求收集，可行性研究/分析，设计，编码，测试，安装和维护等不同阶段。每个下一个阶段仅在完成上一个阶段的目标后才开始，并且相对独立。在与进度或成本相比质量更重要的项目中，首选此方法。这种方法最适合要求不变的短期项目。
• 敏捷模型
  敏捷开发方法是非常流行开发方法之一。当然还有一些其他的敏捷开发方法，但广泛使用的常用方法是Scrum方法。Scrum方法是增量模型和迭代模型的组合，通常适用于项目需求经常变化的项目，和互联网项目。

什么是软件测试生命周期（STLC）

软件测试生命周期（STLC）确定要执行的测试活动以及何时可以完成这些测试活动。尽管不同组织之间的测试有所不同，但都会存在一个测试生命周期。具体可以分为下面几个过程：

• 需求分析阶段
  此阶段的进行依据是BRS（业务需求规范）文档。在此阶段，测试团队从测试的角度研究和分析产品的需求。此阶段有助于确定需求是否可测试。如果任何需求是不可测试的，测试团队可以在这个阶段与不同的部门（客户、业务分析师、技术主管、系统架构师等）进行沟通，以便可以规划缓解策略。

  可交付成果：所有可测试需求清单、自动化可行性报告，等

• 测试计划阶段
  这是真正测试过程的第一步。在这个阶段，测试经理/测试负责人通常需要确定整个项目的测试的工作量和成本估算。根据需求分析制定测试计划。在此阶段进行的活动，如资源统筹和规划、确定不同的测试角色和职责、工具选择（如果需要自动化）、测试的培训等。

  可交付成果：测试策略、测试计划和测试工作量估算文档。

• 测试设计阶段
  测试团队准备测试用例、测试脚本（如果需要自动化）和测试数据。一旦测试用例准备好，那么这些测试用例将由团队成员或团队领导进行设计用例评审。另外，测试团队准备需求跟踪矩阵（RTM）来保证测试用例可以覆盖需求并且验证是否满足需求。

  可交付成果：测试用例、测试脚本（如果需要自动化）、测试数据。

• 测试环境搭建阶段
  此阶段可以与测试设计阶段并行启动。根据硬件和软件需求表建立测试环境。在有些案例测试团队可能不参与这个阶段，开发团队或者由客户提供测试环境，当然取决于不同产品的性质和特点来定。同时，测试小组应准备冒烟测试用例，以检查给定测试环境的是否符合标准。

  可交付成果：可用的测试环境。冒烟测试结果符合预期。

• 测试环境搭建阶段
  测试团队开始基于计划的测试用例执行测试用例。如果测试用例的结果是通过/失败，那么应该在测试用例中记录相应的结果。为失败的测试用例准备缺陷报告，并应通过bug跟踪工具（如Jira）向开发团队报告缺陷。缺陷修复后将重新测试。

  可交付成果：测试用例执行报告、缺陷报告。

• 测试结果分析和产品评价阶段
  在此阶段我们将会准备测试最终报告，测试结果矩阵。测试团队召开会议，根据测试覆盖率、质量、时间、成本、软件、业务目标评估测试完成度。测试团队分析测试结果（如测试用例、缺陷报告等），以确定将来必须实施的策略，这将有助于消除即将到来的项目中的流程瓶颈。将根据上述标准编制测试度量和测试结束报告。

  可交付成果：测试最终报告、测试结果矩阵

什么是产品缺陷的生命周期（BLC,DLC）

缺陷生命周期是在软件开发过程中，bug也会有一个完整的生命周期。Bug应该经过什么样的生命周期才能关闭。 Bug生命周期的变化取决于所使用的工具（qc、jira等）和组织中遵循的缺陷管理过程。

什么是一个BUG?

软件缺陷可以定义为软件的异常行为。怎么样定义异常行为，它可能是不符合我们的需求文档，软件本身的异常，比如产品的崩溃，性能差等问题。缺陷的生命周期是从发现缺陷时开始，在确保缺陷不被重现后，在缺陷关闭时结束。

产品缺陷的生命周期的环节

• 创建缺陷
  当测试人员发现新的缺陷时。他应该向开发团队提供一份适当的缺陷文档，来帮助重现和修复缺陷。在此状态下，测试人员发布的缺陷状态为“创建”。
• 分配缺陷
  处于创建状态的缺陷将通常由测试负责人/项目负责人分配给开发团队。一旦分配了缺陷，缺陷的状态就变为“已分配”。
• 确认(打开)缺陷
  开发团队开始分析确认缺陷并开始修复工作。
• 解决缺陷
  当开发人员进行必要的代码更改并验证更改通过时，缺陷的状态将更改为“已修复”，缺陷将传递给测试团队。
• 待测试缺陷
  如果状态为“待测试”，则表示缺陷已修复并已经准备好测试是否已修复。需要开发提供必要的对应的产品版本信息或者是补丁。
• 验证缺陷
  在开发人员修复错误后，测试人员将重新验证该缺陷。如果在软件中没有检测到缺陷，将更改其状态为“已验证”。
• 关闭缺陷
  在验证通过后，那么bug的状态将被更改为“关闭”。
• 重新打开缺陷
  如果缺陷在重新测试后，发现并没有修复，那么测试人员需要将缺陷状态更改为“重新打开”，需要再一次经过“修复”。
• 重复缺陷
  如果缺陷重复了两或者多次，或者缺陷与缺陷的概念或者深层次的起因相同，开发团队将状态更改为“重复”。
• 延迟修复缺陷
  在某些情况下，项目经理/测试或者开发主管可能会将缺陷的状态设置为延迟。如果在发布结束时发现缺陷，并且该错误很小或不重要，通常会被建议到下一个版本中修复。或者客户有新的需求变更，通常也会将缺陷状态更改为“延迟修复”，并将在下一版本中修复。
• 拒绝修复缺陷
  如果系统是按照需求文档实现的，而缺陷仅仅是由于一些误解（例如使用了旧的需求或未定义的特性）造成的，那么团队领导或开发人员可以将这些错误标记为“拒绝修复”。

当然这里还有一些其他的环节比如说：

• 无法解决的缺陷：
  技术无法支持，产品架构设计的缺陷，解决缺陷的成本过高。
• 无法重现的缺陷：
  测试环境不匹配、错误的缺陷文档、数据的不匹配、软件版本不匹配，等原因引起的缺陷
• 需要更多信息的缺陷：
  如果开发人员无法按照测试人员提供的步骤来重现缺陷，那么开发人员可以将状态更改为“需要更多信息”。在这种情况下，测试人员需要添加详细的重现步骤，并将bug再次分配给开发团队进行修复。如果测试人员编写了一个好的缺陷文档，通常就不会发生这种情况。

总结

这里大概的介绍了产品研发，软件测试和缺陷的生命周期。这里有助于我们理解测试在整个产品研发生命周期的定位，同时也可以帮助理解测试生命周期的每一个环节，来定义我们每一测试环节的需要和输出，帮助我们更好的进行测试，来提高产品的质量。