这是一篇来自 DZone 的 2023 DevOps 趋势报告的文章。
更多信息：
阅读报告
软件开发生命周期 (SLDC) 被打破了。事实上，在第一个项目使用Winston Royce的实施步骤之前，实施步骤就存在缺陷。
图 1：Winston Royce 软件实现步骤（瀑布模型）
Winston Royce 博士在 1970 年展示这个例子的同一个讲义中指出“上述实施是有风险的并且会导致失败”。不幸的是，同样的缺陷也转移到迭代开发框架（如敏捷）中。
问题集中在何时以及如何处理质量验证方面。在图 1 中，假设这项工作在周期的测试阶段进行处理。质量团队基本上闲置（从项目的角度来看），直到完成所有先前的工作。然后，同一个团队拥有大量源代码，必须对其进行测试和验证——使该计划处于一个难以成功而没有任何问题的境地。
如果可以提取过去 50 多年软件开发经验教训的前 10 名列表，我确信将质量验证置于开发生命周期后期的结果排在首位。这种不幸的情况对客户满意度产生了巨大影响——更不用说产品、服务或整个业务实体的生计了。
显然，我们已经远远超过了方向的“转变”。
左移如何改变游戏规则
左移是一种将开发生命周期的测试阶段移到流程早期的方法，而且实际上是分散的。事实上，Larry Smith 在 2001 年 Dr. Dobb's Journal 的一篇文章中首次提到了“尽早且经常测试”的方法。为了演示左移如何改变游戏规则，请考虑图 2 中所示的基本DevOps 工具链，该工具链如今已变得非常流行：
图 2：DevOps 工具链
左移采用在生命周期的每个阶段引入了测试工作，如图 3 所示：
图 3：左移采用的 DevOps 工具链
当质量方面被引入生命周期时，采用左移方法重新分配：
- 计划——通过利用和验证 OpenAPI 等规范来更快地暴露基本缺陷。
- 创建——在创建第一个 PR之前建立单元和集成测试。
- 验证——在授予第一个消费者访问权限之前包括回归和性能/负载测试。
- 包等——确保 CI/CD 管道执行自动化测试执行作为生命周期的一部分。这包括旨在验证流程后期阶段引入的更改的端到端测试和完整性测试。
因此，左移会产生以下好处：
- 需求、架构和设计中的缺陷在一开始就被捕获——节省了不必要的工作。
- 左移中固有的“尽早且经常测试”方法避免了尝试理解和组织广泛的用例以进行验证的困难。
- 了解性能预期和现实情况，这可能会推动设计变更。
- 确定解决方案中的断点——在第一个生产请求发出之前。
- 避免必须在生命周期后期进行设计更新，这通常与计划外成本相关。
- 通过指定较小级别的人员参与整个开发生命周期，可以避免在开发结束时需要更高级别的人员进行全面测试。
左移行动
通常与左移相关联的“尽早且经常测试”方法可直接导致给定解决方案的质量更高。以下是将左移付诸实施时需要注意的几个关键点。
质量工程师的新职业道路
人们可能会期望左移的纯粹重点是分配给该计划的质量工程师。事实并非如此。相反，此更改成为与项目相关的每个工程师的角色。事实上，如今越来越多的组织正在合并通常与质量工程师相关的任务，并将它们分配给软件工程师或 DevOps 工程师。具有前瞻性的质量工程师在考虑他们在左移驱动型组织中的角色时，应该评估哪些工程角色最适合他们的短期和长期目标。
测试覆盖率
在“尽早且经常测试”的方法中，实际测试本身对过程至关重要。重要的方面是测试是功能性的——这意味着它们是用某种类型的程序代码编写的，而不是由人手动执行的。下面列出了一些可以遵守左移合规性的功能测试示例：
- 作为 API 优先设计方法或类似设计模式的结果创建的API测试
- 引入单元测试以验证隔离和集中的代码段
- 添加集成测试以确认不同组件或服务之间的交互
- 编写回归测试以充分执行解决方案并捕获任何遗漏的集成
- 性能测试旨在确定解决方案将如何执行并建立基准
存在的测试覆盖率越多，解决方案就越好。根据经验，API 和单元测试应争取 100% 的代码覆盖率，其余测试应争取 90% 的覆盖率，因为达到完全覆盖通常不值得所需的额外成本。
管道配置
采用左移方法也可能需要更新管道配置。除了确保上面建立的测试是管道的一部分之外，还应该包括完整性和端到端功能测试。这些健全性测试通常是短期运行的测试，用于验证解决方案的每个入口点是否按预期运行。端到端功能测试预计将处理应用程序的行为方面——验证解决方案的所有核心用例是否在预期基准内得到执行和完成。
释放信心
左移行动的最终结果是对版本将成功交付的高度信心——最大限度地减少客户发现意外错误或遗漏需求的可能性。这与之前的理念形成鲜明对比，后者将所有测试都集中在生命周期的末尾——希望所有的事情都经过考虑、测试和验证。
太理想化？
与任何生命周期或框架一样，在组织采用左移以避免“过于理想化”的结论之前，必须解决和接受一些关键挑战。
必须是自上而下的决定
左移必须是自上而下的决定，因为引入的核心理念变化超出了参与该计划的团队。这意味着质量工程人员的管理人员会发现他们长期致力于项目，而不是在开发完成后处理所有验证工作。从更大的角度来看，这些质量工程师可能会发现自己正在调整自己的角色，成为一名软件或 DevOps 工程师——向不同的管理结构报告。
水平集期望
左移方法还需要尽早建立和澄清预期。这是建立在最后一个挑战之上的，因为生命周期的每个步骤都可能需要更多时间才能完成。但是，完成项目的总体时间应与在生命周期结束时实现完整且成功测试的项目相同。
重要的是要记住，左移采用发现的缺陷对解决的影响较小。这是因为测试在给定阶段内完成，从而减少了解决必须在生命周期的先前阶段中解决的其他问题的可能性。
牺牲质量不再是一种选择
对于被迫在规定期限内完成任务的计划，通常采用的一种冒险方法是缩短为生命周期的质量和验证阶段预留的时间。当采用左移时，这不再是一个有效的选项，因为专用的测试阶段不再存在。虽然这种方法从来都不应该考虑，但激进的决策者通常会掷骰子并牺牲给质量工程师的时间来验证该计划，以期获得积极的结果。
结论
在我的一生中，我一直是大片的粉丝。你知道那些用大量预算制作的电影和包括一些受欢迎演员的演员阵容。我在想 1992 年的迪斯尼电影阿拉丁，它以中东民间故事为基础，以已故罗宾威廉姆斯的喜剧天才为主角。我记得有一个场景，精灵给阿拉丁一些关于神灯的信息。在精灵能够提供阿拉丁真正需要知道的一切之前，受到启发的主角立即飞奔而去。事实证明这是一个代价高昂的错误。
我觉得温斯顿·罗伊斯博士是个精灵，而我们其他人则像阿拉丁一样，在整个生命周期中奔波而不想听故事的其余部分。几十年和大量的成本/时间支出之后，一种新的思维方式终于出现了，它建立在罗伊斯最初的想法之上。
无论您的团队的解决方案命运如何，都应该强烈考虑左移，因为这是我们一直应该做的事情。采用这种方法提供了积极的副作用，将专门的质量工程师转变为可以参与所使用生命周期的每个步骤的软件工程师。最大的好处是在生命周期的早期发现缺陷，与在生命周期后期发现和修复缺陷相比，这应该总是转化为显着的成本节约。
要取得成功，实施左移必须是一个自上而下的决定——由组织范围内的思维方式转变驱动并得到每个人的支持。永远不应该考虑减少质量或性能测试来缩短发布新功能、服务或框架所需的时间。
祝你有美好的一天！
参考：
- “向左移动”，Devopedia
- “ 成功实施 TDD/BDD 以实现左移测试方法”，作者：Pavan Rayaprolu
- “ 管理大型软件系统的开发”，Winston W. Royce 博士
- 拉里史密斯的“ 左移测试”
这是一篇来自 DZone 的 2023 DevOps 趋势报告的文章。
更多信息：
阅读报告