“对被测系统及其支持系统（如CI/CD）的全面理解使我能够有效地测试系统，因为我对其内部运作了如指掌。凭借这种知识，我能够理解应用程序的运行机制，识别出问题所在，并且最重要的是，能够思考测试策略。”
你可能已经是一个系统思考者了！
日常生活中的活动要求你思考系统，无论这些活动是否涉及“技术”。一旦你意识到自己已经在进行系统思考，你可以更深入地理解你在工作中测试的系统。
在你的日常生活中，是否：
- 规划餐食、购物买食物、制定预算，并按时准备好晚餐？
- 送孩子上学，然后准时上班？
- 修理家里的东西，或者学习如何指导他人解决复杂问题？
面对一个“故障”的系统：了解我的车库门
作为丈夫和父亲，我经常发现自己在解决家庭问题，比如修理家里的东西或为孩子组装新玩具。但正是处理一个故障的遥控车库门的经历促使我写下了这篇文章。我意识到在了解这个问题的方法与作为测试人员时的学习方式有很多重叠之处。在寻求帮助或解决问题之前，我希望了解事物的工作原理。
当车库门无法通过遥控器打开时，我首先上网搜索其机制以及如何修复。但我也担心任何行动可能会使问题变得更糟。所以我寻求了帮助，但由于缺乏理解，我无法有效地与服务专业人员沟通。他用我不懂的术语问我问题，这让我们双方都感到沮丧。
因此，我继续寻找有关遥控车库门的信息。我发现门是通过连接到房屋电源的机械电机来操作的。门沿着连接到电机的三条铁轨上下滚动。虽然最终还是需要维修人员来修理门，但我对它的运作有了宝贵的见解，并且我现在处于一个可以与维修人员深入讨论问题的位置。我对处理未来可能出现的问题也少了很多担忧。
系统思考的持续改进：当车库门再次坏掉
果然，几个月后，车库门又停止工作了。这次它发出了巨大的噪音，让我以为它已经无法修复。就像在生产环境中代码修复失败时一样，我在第一次事件中获得的信心也随之消失了。
我又一次联系了维修人员，他们通过调整其中一条铁轨进行了“临时修复”。在维修过程中，我询问了关于问题的原因、它是如何发生的，并观察维修人员的操作以了解他们是如何修复的。
第二天，当我从学校接回儿子回家时，我开始担心每天多次使用车库门是否会成为故障的原因。然后我意识到我已经完全理解了它的运作原理。我已经看到了内部部件，并理解了它们是如何协同工作的。如果将来再出现问题，我想我应该能够处理或理解维修人员是如何处理的。
同样的逻辑也适用于我对待软件测试的方式。
在软件测试中建立系统思考实践
有时，工作要求我们更深入地进行系统思考，不管我们是否认为自己已经准备好了。
良好的开端：全面的产品知识
几年前，我在一家初创公司担任测试（Beat，原名Taxibeat，现属于FreeNow）。随着工程部门的扩展，团队开始负责特定领域以有效扩展。
当我加入公司时，我负责测试公司的移动应用程序，包括回归测试，当计划推出新功能时，以及在五个国家/地区的移动应用程序上执行回归测试周期。后来，我专注于乘客和司机移动应用程序的激励功能。
在我作为测试的早期，我主要进行用户验收测试和功能测试。我使用Postman进行API测试，使用Selenium和Appium进行Web和移动UI自动化测试。我的最大优势是对所负责测试的产品区域有深入的理解。
深入了解系统
整理系统配置的细节
我和经理讨论了我的担忧，我们一致认为仅仅负责测试还不足以保障质量。我们决定还应该“拥有”管理面板和微服务配置区域，以便我能从内到外了解它们的工作原理。
我花了很多天时间学习管理面板设置，阅读所有可用文档，并绘制每个服务的API端点。我研究了数据科学团队如何通过Kafka事件向微服务发送信息，并设置了一个连接到暂存环境的本地Kafka代理，以了解消息流。
然后我将管理面板中的每个设置映射到移动应用程序使用的端点。这是最困难的部分，因为没有当前的管理面板API文档。我获得了管理面板、后端和微服务的GitHub存储库访问权限，克隆了每个仓库并在本地运行，以了解每个设置背后的逻辑。
创建学习路径：探索产品代码
起初，我并不觉得自己是一名软件工程师，但一步步地，这种情况改变了。我开始学习git和版本控制，在笔记本电脑上安装了第一个IDE，并使用Sublime等文本编辑器打开仓库并搜索代码。我学习了设计模式、事件驱动架构和微服务。我还探索了用PHP、JavaScript和Go语言开发的代码仓库，而我们的测试是用Java编写的，从而接触到了不同的编程语言和概念。
我养成了实验心态。如果有什么我不明白的，我会在网上搜索并与团队中的开发人员咨询。我订阅了多个新闻通讯和博客，关注测试领域的专家，并开始每日学习工程概念。深入研究工程世界和系统的工作原理已成为我的常态。我现在知道，对于测试员和工程师来说，每天投入时间和精力进行持续学习和研究是必不可少的。
建立定期的系统思考测试实践
如今，我定期深入研究我工作的系统。我获取所有仓库、架构图、API文档、C4图和业务逻辑文档的访问权限。我努力理解持续集成和交付（CI/CD）过程以及测试环境的部署。对被测系统和支持系统的全面理解使我能够有效地测试系统，因为我了解它们的内部运作。凭借这些知识，我能够理解应用程序的操作，识别bug所在的位置，并最重要的是，思考测试策略。
我的系统思考实践促使我采取以下行动：
- 我确保自己理解风险。我知道当特定代码发生变化时应该覆盖哪些区域，哪些层进行了测试，哪些层没有。
- 我评估低级别的测试覆盖率，如应用程序代码中的集成测试。
- 我了解我们在部署过程中是否包含任何端到端测试。根据定义，端到端测试描述了一个业务流程或用户流，这意味着我们需要整个系统部署在某个地方。
- 我将验收标准和需求映射到测试场景。
正如唐奈拉·梅多斯在《系统思考》一书中精彩描述的那样：
“一个系统的行为是其随时间的表现——增长、停滞、衰退、振荡、随机性或演变。如果新闻能更好地将事件置于历史背景中，我们将对行为层面有更好的理解，这比事件层面的理解更为深刻。当系统思考者遇到问题时，他们做的第一件事就是寻找数据、时间图表和系统的历史。这是因为长期行为提供了底层系统结构的线索。而结构是理解不仅发生了什么，而且为什么发生的关键。”
无论测试还是工程师？所有角色都需要良好的系统思考实践
阅读业务需求和验收标准对于理解客户需求至关重要，但这对于有效的测试来说是不够的。如果不充分了解系统，你会面临许多未知因素，从而拖慢团队进度。例如，关于质量问题的有效沟通需要对系统的详细知识，以便准确指出问题。
曾经有几次，我在测试过程中发现了问题，将其视为缺陷，后来才意识到这是由于不会在真实世界中出现的测试设置造成的。这种对系统的深入理解使我成为一名更好的工程师。重要的是要认识到，作为软件测试领域的专业人士，无论你的正式角色是什么，你都是负责系统质量的软件工程师。你必须了解系统从前端到后端的工作原理，才能为客户提供最佳质量。
我目前担任Orfium首席软件测试工程师的职位，我强烈倡导结合测试和工程思维的角色。这种方法反映在我们的招聘流程、职位发布、入职程序和我们制定的指南中。公司内的测试员角色应紧密集成到开发团队中，并成为工程部门的一部分。测试必须彻底了解被测系统，使其符合我们旨在服务的指南和使命。
良好的测试自动化依赖于严格的系统思考
沉浸在产品的各个组件如何交互的过程中，可以显著提升你的测试自动化工作。以系统思考的心态进行自动化测试可以增强你在测试规划和设计方面的信心，从而产生有意义的测试。每次这些测试运行时，它们都会让你收集到有价值的反馈，这些反馈反映了你的软件的业务逻辑和实际用户流程，使你能够在发布前后自信地传达系统的质量状态。最终，这有助于提高你的软件的整体质量。
随着软件的发展，持续维护你的测试自动化项目至关重要，以确保它们继续为你的团队提供有意义的反馈。采用系统思维方式为你提供了实施、维护和扩展测试代码所需的能力。你会发现探索诸如为什么要测试、测试什么、如何测试以及在团队的CI/CD过程中何时运行测试等关键问题会带来满足感。
培养系统思考的心态不仅提高了测试自动化的效率，还激励你的团队工程师接受这种方法，从而显著提高你的组织开发软件的整体质量。
