敏捷测试生命周期 – 你需要知道的一切
你熟悉敏捷测试生命周期（ATLC）吗？它是软件开发团队用来确保他们的应用程序被适当和有效地测试的过程。
本文将带你了解关于ATLC的一切，包括它的好处、涉及的步骤、制定实际测试策略的规划、根据需求收集和漏洞追踪执行测试、用户验收测试（UAT）以及测试的持续集成和自动化。
阅读完本指南后，你将更好地了解如何将敏捷测试作为你软件开发生命周期的一部分！
如果你是一个敏捷开发者、测试人员或产品经理，正在寻找一种更好的产品交付方式，那么本文将解释涉及的阶段以及所需的行动。
敏捷测试生命周期概述
众所周知，在敏捷开发领域，测试非常重要。但尽管如此，它在敏捷交付中往往被低估。原因当然是与投产交付所需的时间和金钱有关。
但是，如果没有详细的测试，你的团队开发的任何产品都无法保证质量或可靠性。这就是为什么了解敏捷测试生命周期至关重要-从识别工作项到了解每个阶段应该使用哪种类型的测试。
敏捷测试周期要求开发人员和测试人员参与每个迭代。做得好可以在每个阶段都进行测试自动化，从而有助于更早和更频繁地检测到错误，减少以后的疑难解答时间。
敏捷测试还有助于早期验证需求，并作为一个副作用，通过交付优质产品提高客户满意度。
什么是敏捷测试及其好处
敏捷测试是一种创新的软件测试方法论，利用自动化来创建一个迭代测试过程。这种以自动化为中心的方法可以帮助团队快速分析代码中的任何不一致或问题，然后根据这些反馈进行测试修改。
所以这个过程的主要好处似乎是显而易见的：
- 确保测试具有必要的影响，
- 它导致更高效的开发时间，
- 开发的系统具有更快的错误解决速率，
- 并且改进了客户满意度。
质量和速度在这里是关键因素，因为迭代被定义为一个较短的时间段（通常为2到4周）。团队越是依赖包含在迭代测试中的质量，团队就越能产生出更高的信心和更快的开发进展。
注重自动化应该是任何敏捷团队的主要目标。这使得团队可以降低昂贵故障的风险，并更多地将时间用于新内容的创建，而不是修复已经存在于产品中的问题。
另一个附带好处是更好的质量保证和时间规划。由于产品更加成熟和可预测，团队在迭代中不再被迫处理之前未经计算的意外问题的情况更少。
敏捷测试生命周期步骤
敏捷测试生命周期由四个不同的阶段组成。
单元测试
这些是开发人员在代码从开发角度准备好后执行的测试。它在开发环境中独立执行，不涉及系统的其他部分。
单元测试是为了测试代码，可以手动和自动执行。
如果手动执行，开发者会对代码运行其测试用例。这很容易找出问题，但会从开发的时间中占用更多时间，特别是从长期的角度来看。
相比之下，另一种选择是创建一个自动化的单元测试代码，通过执行代码来验证功能。这意味着开发者不仅要花时间开发新功能，还要开发测试该功能的代码。
虽然从短期来看这可能需要更多的努力，但从整个项目来看，它能够节省时间，因为这些单元测试很容易在后期的迭代测试中重复使用。它们甚至可以被包含在常规回归测试用例中，从而进一步节省时间。
最后，自动化单元测试的代码覆盖率越高，就能向客户展示更好的代码可靠性指标。
功能测试
功能测试旨在确定应用程序的某个功能的工作情况。这种类型的测试用于确保代码的正确功能，而不是技术方面的问题（这些主要是单元测试的一部分），以及评估它是否满足用户的需求和期望。
换句话说，功能测试用于验证所开发的内容是否符合业务用户的要求。
提前收集重要的测试用例，并从相关利益相关者（无论是产品负责人还是最终用户）那里获得，然后列出在当前迭代中所需的所有这些测试用例，这是一种良好的实践。
自动化功能测试涉及到测试开发方面的更多工作，因为这些是复杂的验证过程，涉及到系统的多个部分。在这种情况下，最佳策略是建立一个专门的团队，专门开发功能测试，与主要开发团队一同开发新功能。
当然，对于项目来说，这意味着增加了维护一个独立团队的成本，但从长远来看，这也有潜力为项目节省资金。只有项目经理能够解释并具体计算出益处和节省的好处，才能在商业用户面前提出这种增加项目成本的合理论证。
另一方面，如果手动执行，这项工作可以由一个非常小的团队来完成（在某些情况下，甚至只需一个人）。然而，每个迭代都需要进行持续的手动和重复的工作。随着系统功能集的不断扩展，逐个迭代地进行可靠的功能测试可能会更加困难。
回归测试
回归测试的目的是确保在下一个发布版本中之前的所有功能都能正常工作。回归测试需要进行以确保不同模块之间没有兼容性问题。
对于回归测试来说，最好定期维护和复查测试用例，并在每次发布之前进行更新。根据具体的项目要求，最好保持测试用例简单，但覆盖核心功能和重要的端到端流程。
通常，每个系统都有涉及多个不同领域的流程，这些流程是回归测试的最佳候选。
如果已经存在自动化的单元测试和功能测试，将这些测试用例整合到回归测试中是一项非常容易的任务。只需重用系统中最重要部分（例如，生产中使用的流程）的已有测试用例即可。
用户验收测试（UAT）
最后但同样重要的是，UAT验证应用程序是否满足发布生产所需的要求。当频繁对软件进行短期和密集的测试时，这种方法效果最佳。
UAT test应该由敏捷团队之外的人员专门在一个尽可能接近未来生产环境的环境中执行，最好是由业务用户执行。或者，产品负责人可以替代最终用户执行。
无论如何，这应该是从最终用户的角度进行的一个干净、功能性的测试，与开发团队没有任何关联。这些测试的结果将对是否发布生产做出重要的决策。
制定有效的测试策略
规划是敏捷测试的重要组成部分，因为它将整个策略联系在一起。它还需要在冲刺的背景下设定清晰的时间线预期。
通过有效管理敏捷测试规划，团队可以创建一个明确的方向，以在冲刺中高效利用资源。显然，测试人员和开发人员之间的合作应更加密切。
还应制定一个全面的计划，明确说明每个开发冲刺中何时进行单元测试、功能测试或用户验收测试。因此，每个人都清楚地知道他们在成功启动敏捷项目中需要参与的具体时间。
如何制定计划可以进一步讨论和协商。然而，最重要的是要使其成为一个过程并坚持下去。创建一个可靠和可预测的周期性。
不要偏离这个过程。否则，直接相反的情况将成为现实-混乱和无法预测的发布到生产环境。
根据需求执行测试
必须根据每个阶段的需求执行测试。当发现错误或问题时，将打开票据并分配给开发团队，他们将能够确定需要修复或更改的代码。一旦所有错误都得到修复，敏捷测试执行就可以继续，直到所有测试都通过。
结果审查和错误追踪
对结果进行有效审查和完善的错误追踪过程至关重要。该过程应涉及所有相关利益相关者，包括项目经理、测试人员、开发人员以及最终的支持团队，还有顾客进行反馈收集。
这应该是一个足够全面的活动，以便能够快速识别问题并在预定的发布日期受到威胁之前进行修复。
选择的工具再次由团队决定。但一旦选择，任何测试活动都必须包括可靠的错误追踪过程，以监控问题，根据依赖关系对其进行优先排序，从开发人员那里报告解决方案的状态更新或转移进行进一步调查，然后一旦解决问题就关闭票据。
审查帮助敏捷测试人员了解其系统的行为，以便在每个步骤中识别错误，而不是在流程的后期。定期审查还允许敏捷团队识别趋势和需要改进的领域，使他们能够持续更新他们的测试框架，并更快地构建更高质量的产品。
通过生产烟雾测试完成产品发布
为了最大化发布的成功，可以在发布之后立即对生产环境进行烟雾测试，以增加信心。
此测试由生产系统内的一组只读活动组成，不会创建任何新的随机数据，但仍会从最终用户的角度验证系统的基本功能。
将正确的利益相关者纳入流程有助于确保一致性和责任，并增强达成目标的信心。最终，这些测试确保了成功的发布。
持续集成和自动化测试以提高效率
Continuous integration和测试的自动化越来越多地被公司采用，将敏捷过程推向更高水平。
如果团队能够按照上述描述，将自动化实施到几个阶段，那么这些阶段可以组合和连接到一个专用的测试流水线中，该流水线基本上是一个完全自动化的批处理过程，能够独立进行大部分测试活动，而不需要其他团队成员的参与。
随着时间的推移，这样一个全面的测试流水线将缩短所有测试阶段所需的总时间。最终，它可以在每个冲刺结束后实现一个真正快速的增量生产发布。虽然这是一个理想情况，但在现实中，很难实现所有涉及的测试步骤。自动化是唯一的方法。
敏捷测试和瀑布测试的区别
敏捷测试策略与传统的瀑布测试策略在多个方面有所不同，如周期性、并行性或每个活动的专用时间。
但最显著的区别是每种方法的重点：
- 敏捷测试侧重于开发的持续、快速迭代和反馈循环，以识别问题并快速改进产品。这是一个侧重于客户协作、持续集成和自适应规划的迭代过程。
- 另一方面，传统的瀑布测试强调线性过程，每个阶段都单独解决，并按顺序进行，只在项目的最后阶段和接近最终生产发布日期时才获得整个解决方案的反馈。
显然，主要利益相关者越早发现问题，项目的情况就越好。在这方面，敏捷方法肯定有更好的成功机会。
结论
尽管敏捷测试生命周期可能看起来比瀑布测试短，但实际上并非如此。整个过程是连续的，并持续到产品发布日期。根据每个冲刺可用的预算和时间，您将不得不优先考虑在该特定冲刺期间执行哪些测试。
一个精心计划的测试策略可以帮助您选择哪些特性或模块需要比其他更多的关注。自动化将使多个测试阶段包含在同一个冲刺中，从一个冲刺到另一个冲刺增加系统的整体可靠性。
您现在可以查看一些 best practices in scrum testing。
