所寫即所思｜一个阿里质量人对测试的所感所悟。

服务输入：接收请求（如用户操作、其他服务调用）；处理：执行业务逻辑（如数据验证、状态更新）；输出：返回处理结果（成功/失败响应）。在微服务中，API是服务间通信的“契约”，定义了数据传输规则与交互逻辑。数据正确性：验证服务间传输的数据格式（如JSON/Protobuf）、类型是否符合契约；响应可靠性正向场景：正确请求返回200 OK及预期数据；异常处理：错误请求返回400/500等状态码，且不引发系统崩溃；边界测试：验证极值输入（如最大字符串长度、空值）时的稳定性；安全性。

前篇文章介绍了自动化用例并非“，而是需要不断维护的原因。并且介绍了提升自动化用例稳定有效的策略，提出测试数据多样化、测试模块化、动态断言以及定期进行测试review的观点。本文分享作者近段时间总结的一些用例治理经验，本文主要探讨和的治理手段。

被遗漏的软件缺陷可能会造成数百万美元的损失，更糟糕的是，它会破坏用户的信任。许多质量保证（QA）工程师，无论从事手动测试还是自动化测试，都会在不知不觉中犯下影响软件质量和测试可靠性的错误。你是否也在犯这些错误呢？QA工程师可能会遇到在用户故事或验收标准中未明确界定的意外行为。拿不准的时候，一定要记录并报告问题。清晰的报告能开启讨论之门，帮助利益相关者确定这究竟是缺陷、缺失的需求，还是预期行为。若问题复杂或不明确，应立即与上级安排会议。这可能是个真正的问题、已知问题，或是计划未来修复的问题。现在标记出来，总比

前几日，我与一位相识的测试老朋友闲聊，交谈过后，我思索起在参与过的一些项目中，与指标相关的流程是如何构建的：在其中一个项目里，大多只有开发人员会收到生产环境中严重 bug 的通知，而且必须紧急修复该 bug。结果是 bug 修复了，但测试人员甚至都不会知晓这个 bug 的存在。这样的流程使得收集与 bug 相关的指标变得不太准确。在另一个项目中，并非所有任务都由测试人员进行测试。例如，一些看似微不足道的变更，甚至在未通知测试人员的情况下就被部署到发布版本中，然而实际上这些变更可能会引发一些回归 bug。

测试是一项极具分析性的工作，需要对被测系统有深入的了解。测试自动化不仅需要这些，还需要对测试内容进行分析，以便确定哪些部分需要拆分，从而以最优方式运行测试。很多时候，优化过程就像解数学方程一样，你可以去掉冗余的部分。手动测试用例的方法中存在很多这样的冗余部分，而做出有效的测试自动化决策的关键就在于识别出这些冗余部分。

随着时间的推移，我的角色变得非常接近首席幕僚。我很快就意识到他们很少告诉我该做什么，而是他们会给我指明一个方向，但随着我花时间与他们建立牢固的关系，他们开始信任我（并依赖我）来识别出组织需要解决的最重要的技术问题，并且通过自己的工作或与他人合作来解决这些问题。我不期望团队因为我说了什么就与我合作或按我说的做——我希望他们能与我一起工作，共同解决问题，因为他们想这样做。我发现通过与更广泛的圈子建立联系，我对问题有了比以前更多的视角，最终我依靠自己的判断力和直觉来决定应该在哪里投入时间，而且它确实奏效了。

想象一下，我们已经计划好周末去野餐。但天气预报说有5%的降雨概率，我们可以选择租帐篷，甚至重新安排野餐时间，但是考虑到这么低的降雨概率以及带来的不便似乎并不值得。风险很小，但为了降低风险所付出的代价远远超过了其潜在影响。再考虑另一个场景，我们正在组织一个线上活动。使用Teams视频会议平台有很大的概率会出现故障，但我可以通过切换到另一个视频会议平台轻松解决这个问题。在这种情况下，发生的可能性较高，但影响很容易被降低。尽管这些例子看起来很明显，但我们经常会看到团队在评估风险时没有同时考虑这两个因素。

自动化测试或许是一把双刃剑。今天聊聊大规模自动化测试的话题，对于大厂而言，单个应用就有成千上万的自动化用例（至少我当前所在团队而言是这样），那么每次执行一次测试计划大概1小时。测试用例的难点其实并不在于写用例，而在于测试的维护，测试时间的投入也符合2/8原则。对很多测试人员来说，自动化测试只是由一些手动生成的、用来执行特定测试场景或一部分产品功能的测试代码组成。大部分测试人员对于自动化测试可以节省时间这样的说法很熟悉。然而，在很多情况下，自动化测试实际上并没有节省测试人员和他们的管理团队所期望的时间。

测试本质上是一种降低不确定性的反馈，通过将测试分类为“已知-未知组合四象限”，团队可以更好地理解系统行为，并解决知识上的空白。测试通常被简化为二元分类——手动测试与自动化测试、通过与失败。然而，这些局限性忽略了测试的一个更深层次的目的：减少我们对系统行为的不确定性。从这种二元视角转向将测试视为反馈，会改变我们对软件系统中质量和风险的看法。那么，我们如何将测试视为反馈来减少对系统行为的不确定性呢？

我得到各种各样的答案，比如1和1，2和2，大数字和负数，这些都是很好的用例，通常会找出5至15个合适的用例。这一次，可能会有比原来代码多得多的其他代码导致测试失败，也可能是因为配置问题导致失败。比如，如果服务器没有运行，那么测试就会失败，但这与代码无关。API测试不仅会运行我们的代码，还会运行大量Spring代码。如果我们在编写测试之前没有考虑这一点，我们就会编写一些没用的测试，并在它们上面浪费大量宝贵的时间。在进行测试时，我们需要了解我们正在测试的内容、什么会使测试通过以及什么会使测试失败。

软件质量保障所寫即所思｜一个阿里质量人对测试的所感所悟。软件在当今社会变得极其重要。尽管有许多质量倡议，IT行业仍然远远不能承诺零缺陷的软件。近年来，大多数世界各地的软件开发方式发生了巨大变化。除了软件开发的快速和动态变化外，创新、新技术的增长以及IT在大多数行业的扩展也在加剧。采取了敏捷和/DevOps的工作方式已经有很大的转变。敏捷的优点包括更好地管理变更优先级、提高项目状态的可见性、增加团队生产力和更好的交付可预测性。然而，许多组织都在努力应对敏捷和扩展敏捷，并且很明显，向敏捷的转变并

所寫即所思｜一个阿里质量人对测试的所感所悟。公众号当我们想到自动化测试时，许多积极的方面可能会浮现在脑海中，比如缺陷检测，但实际上，良好的测试与良好设计同等重要，即通过可变代码来降低成本。可变性需要三个相关能力：重构灵活的设计有效的测试但是，自动化测试是如何实现可变性的呢？没有测试，任何更改都可能是一个潜在的缺陷。自动化测试提供了一张安全网，使得开发者在修改或重构代码时更有信心。

重复性是自动化的核心，Postman Flow支持重复性的任务执行。例如垃圾邮件删除，我们经常需要从多个系统中删除电子邮件。登录、搜索并从多个位置删除电子邮件可能非常耗时。本文介绍如何创建一个Flow，每次运行该Flow时，它都会删除一封电子邮件。同样，我们将使用Stripe.com、Brevo.com以及一个作为假设的内部系统的Postman mock服务器。

所寫即所思｜一个阿里质量人对测试的所感所悟。最常见的方式就是异步消息通信。使用消息机制时，服务之间的通信采用异步交换消息的方式完成。基于消息机制的应 用程序通常使用消息代理，它充当服务之间的中介。另一种选择是使用无代理架构，通过直 接向服务发送消息来执行服务请求。服务客户端通过向服务发送消息来发出请求。如果希望 服务实例回复，服务将通过向客户端发送单独的消息的方式来实现。由于通信是异步的，因 此客户端不会堵塞和等待回复。相反 ，客户端都假定回复不会马上就收到。

理想的情况是，编写程序的开发人员在编写代码的同时编写单元测试。GitHub Copilot 是由 GitHub、OpenAI 和微软共同开发的基于生成式AI模型的工具，它基于所有出现在公共存储库中的自然语言进行训练。单元测试（Unit Testing）是软件开发的一种测试方法，它主要针对程序中的最小可测试单元——通常是函数、类的方法或模块等进行检查和验证。隔离性：每个单元测试都是独立的，测试时会将被测试单元与其他代码隔离，以确保只测试该单元的功能，不受外部因素影响。还需要手动完成生成的测试用例。

Postman Flows是一种接口测试可视化工具，可以使用流的形式在Postman工作台将请求接口、数据处理和创建实际流程整合到一起。如下图所示Postman Flows是以API为中心的可视化应用程序开发界面。它提供了一个无限的画布用于编排和串连API，数据可视化来显示你的流的最终输出。

与之前的版本相比，对单元测试的定义也有所改变。你不再需要在函数前缀上使用` test `，而是可以将` @Test `函数附加到任何你想让其成为测试的函数上。

（这里的“产品”可能是正在运行的软件，或者是它的一部分。如果我们相信这种幻想，就不必去寻找那些深层的、隐藏的、罕见的、微妙的、间歇性的问题；与项目中的其他人不同，测试员专注于揭示尚未解决的问题，或是我们提出的解决方案所引入的问题。在测试的早期阶段，特别是放松或暂停我们对发现问题的关注，更多地关注建立我们对产品的心理模型可能非常重要。测试必须被视为一种社会（且社会上有挑战性）、认知、风险聚焦、批判性（在多个意义上）、分析性、调查性、熟练、技术性、探索性、体验性、实验性、科学性、启示性、光荣的手工艺。

事务的隔离级别决定了一个事务可以看到其他事务修改数据的程度，从最低级的读未提交（Read Uncommitted）到最高的串行化（Serializable），隔离级别越高，并发性能越低，但数据一致性越好。分布式事务：微服务架构下，原子服务（拥有自己的部署容器和数据存储容器）部署在不同的服务器上，服务间调用就会出现跨越多个数据库或服务的事务，需要特殊的协调机制（如两阶段提交）来确保所有参与方的一致性。最近出了一个bug，比较神奇的是，竟然一年前的变更引起的。反之，则直接return，不做什么操作。

所寫即所思｜一个阿里质量人对测试的所感所悟。中断测试有助于移动测试人员识别与系统或用户行为相关的潜在风险，以便在发生流量干扰时能够识别出可能导致意想不到或不期望结果的问题。让我们深入探讨中断测试的细节及其手动或程序化实现方式。本文还介绍了用于自动化测试过程、加快测试执行速度并向用户提供高质量应用的移动工具，例如 Appium WebDriver。

正如你所看到的，尽管为达到代码覆盖率而构建的测试集会通过代码执行类似的路径，但变异测试指标允许对测试应执行的验证进行更具体的描述。这是杀死的变异体与变异体总数的比率。在多数软件测试方法中，很难预判能否在测试过程中发现缺陷，往往直到这些缺陷在后续的测试环节被发现，甚至是更糟的情况下，在生产环境中出现时才会被注意到。随着工程师越来越多地采用更自动化的软件验证方法，以及在不断缩短的发布周期中对更高品质的软件输出的需求日益增长，变异测试帮助我们退一步评估，我们是否真的应该对我们的测试充满如此信心。

在缺乏有效的测试用例的情况下，你可能无法为团队提供有价值的质量反馈，而这正是QA人员所期望的得到的。因此，测试不仅对于深入了解产品至关重要，而且对于确保交付的软件符合业务方的期望至关重要。作为一名QA，如果不了解用户的痛点，就无法确保这些变更是否真正为用户解决了问题。通过明确受影响的模块，你可以设计出全面覆盖这些变更的测试用例。我会向产品负责人询问有关需求变更如何为我们的用户解决问题，这让我了解了用户所面临的问题。我的测试方法总是向参与项目过程的不同人提问，这让我更深入地了解变更的背景知识。

当下，随着产品的迭代速度越来越快，测试人员必须在更短的时间内测试更多的软件。这使得每个代码变更都执行整个测试集变得不可行。而通过手工测试覆盖所有变更更变得不切实际。为了应对这一挑战，我们提出了基于变更驱动的测试(Change-Driven Testing)的方法论。变更驱动测试使用测试影响分析来自动查找给定代码变更的相关测试集，大大增加了早期捕获缺陷的概率。此外，基于变更驱动测试使用测试缺口分析来自动识别测试缺口（即缺乏测试用例覆盖的代码变更）。这使我们能够有意识地决定将我们有限测试资源用于提高我们的测试有

持有固定型思维模式的人认为自己的能力（或所做的事情）是固定不变的、与生俱来的。同样，DevOps文化的兴起也催生了专注于“平台工程”或“开发者体验”的中央团队，他们构建工具和自动化基础架构，并在必要时提供专业知识，使开发团队能够更轻松地运行基于云的服务和应用程序。如果数据表明拥有更多软件测试和运维方面技能的开发者是有益的，而你的回答却是“这不是我的工作”，那么你的成长将受到限制，而且你的职业生涯也会受到影响。有时候，开发人员不想学习如何测试或了解服务交付，因为他们认为自己高人一等，这是“别人的工作”。

自动化测试在软件质量保障手段中愈显重要。但是随着自动化测试代码的规模和复杂性不断扩大，它也很容易出现测试代码重复、紧耦合等问题。而SOLID原则可以解决这一问题，作为自动化用例开发的指导原则。

例如灵活性、团队合作、适应性在QA中是至关重要的，使工程师能够与团队成员和客户有效地协作。通过磨练这些技能，QA专业人员可以促进他们的职业发展，并在他们的领域产生真正的影响。从本质上讲，软技能使QA工程师能够有效地协作，有效地解决问题，并确保项目的整体成功。在质量保证工作中，软技能是至关重要的，因为它们使得技术专长得到更好的发挥。对于QA工程师来说，注意和处理任务中经常被忽视的小细节是很重要的。积极地注意别人在说什么，理解他们的观点和担心是至关重要的。反思以前的成功和失败，以提高未来的表现是非常有价值的。

对我来说，一个概念的良好定义应当具备这样的作用：当你拥有这样一个定义时，它不仅能够作为理解该概念的核心方式，而且还能引导你探索这一概念的方向，并指导你全面把握对该概念探索的所有含义。丢掉“尽管有分歧也要坚决执行”的说法，转向“提出有意义的问题，获取有用的答案，并根据所学付诸行动”。综上所述，我们探讨了控制理论中对可观测性的定义，认知系统工程中的可观测性定义，以及我提出的可观测性定义：可观测性是一个过程，通过这个过程，个体或组织能够发展出提出有意义的问题、获取有用答案并基于所学采取有效行动的能力。

此后，也启发各个语言的 Property-Based Testing framework，例如：Python 的 Hypothesis、Erlang 的 PropEr、Rust 的 quickcheck、JS/TS 的 fast-check 等等。这样的优点是，我们已经可以通过产生出的阵列来测试，并打乱它后再确认是否已经排序，但是，这样我们还是只有测了「长度为 3 且内容物为 1 到 3 的阵列」、「长度为 5 且内容物为 1 到 5 的阵列」以及「长度为 10 且内容物为 1 到 10 的阵列」。

最近这段时间，随着OpenAi发布Sora，关注AI的同学估计都知道上面这张图，中美两大AI巨头(笑cry了）。当然本文不是聊这个段子，主要聊下AI在软件测试行业的应用与现状。不可否认，借助于AI辅助测试工程师做自动化测试是质量保证手段的趋势。由于AI、机器学习和神经网络是当前最热门的话题，大家似乎有一种“有了AI一切都会变得更好”的错误认知。但事实真的如此吗？

如果你观察计算机的整个内部，你会发现一排排的组件，组件之间有电线连接，当时选择电线是非常关键的设计决策。随着你执行的每个实验，你都会对软件的行为有更多的了解。你提前为会话设定一个焦点，在会话期间，你可以灵活地探索，设计和执行测试，从一个测试到下一个测试，没有停顿。在这一部分中，你将了解如何制定章程来指导你的探索，如何观察真正发生的事情，如何识别有趣的变化，以及如何确定在以前从未考虑过的软件使用方式中应该预期什么行为。当你发现潜在的风险时，你会进行更深入的测试，利用你的观察和分析能力来调整你的测试。

我清楚地记得第一份工作初次接触到大型软件项目时的情景，依然记的当时是在一家大型英国电子公司暑期实习。我刚入职就被质量团队的测试经理带着参观公司，他带着我进入了一个巨大的、令人沮丧的、没有窗户的仓库，里面的小隔间挤满正在工作的人，经理告诉我这些程序员同事已经为项目（一个大型软件产品）持续开发了几年的代码， 当他们完成编程时，他们各自的单元（功能）模块正在被集成在一起，而且已经集成了几个月。经理告诉我，没有人真正知道这需要多长时间才能完成集成。

状态机约束： 在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机(状态变更图)，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。原因：应用B会将首次请求失败的数据落DB，幂等请求时候，如果requestId不变，且amount不变，则会捞起首次请求落DB的refundDetial，组装对下游的请求报文，因此不会报错。

而数据源可以来源于POSTMAN导出的JSON文件、SWAGGER文档，Charles的Har文件，甚至JMeter的JMX文件，当然我们需要写解析这些文件的脚本才能获取到需要的数据。此外，如果所测接口存在上下接口调用的依赖，则还需要进行全链路联调测试（不部分接口不是独立存在的，都是和其他接口相互调用的），联调测试是为了保证上下联路接口之间契约的准确性。需要特别说明的是，这里的无代码不是说没有测试代码，而是测试人员不用自己开发测试代码，使用Codeless测试工具可以帮助我们生成可以执行的测试用例集。

为了兼容迁移过程中的存在的一部分特殊交易数据（正向[支付]交易在站点A，但逆向[退款]操作在站点B操作），因此需要做站点A和站点B数据的关联，形如下图，在目前迁移站点落的单据拼接站点A的交易单号。一方认为站点B当初设计表结构时候，字段长度的取值是经过业务发展评估的，请求过来的字段长度就应该不能超出定义的长度，，于是乎在落幂等表（一般是xx_unique表）时出现insert异常，但是这个异常并未直接阻断后续的业务流程，而如果以相同的内容（交易单据）再此发起接口请求，就可能会。针对这个缺陷，可以举一反三。

探索性测试是一种动态测试方法，它在时间限制的测试阶段利用测试人员的专业知识和结构化方法。它涉及到并发的测试用例设计和执行，允许测试人员积极地探索在测试中的应用程序或系统，以寻找潜在的缺陷和漏洞。在这里，测试人员的工作不是基于先前编写的测试用例。他们盲目地测试系统，寻找消费者在没有明确目标或方向的情况下访问网站或应用程序时可能遇到的缺陷。从本质上讲，探索性测试试图复制最终用户的个人自由和偏好。这一切都是关于学习、研究和好奇。在现代的方法中，测试人员主动利用程序来衡量它提供的用户体验水平。

Postman是一个可扩展的 API 测试工具，可以快速集成到 CI/CD 管道中。它于 2012 年作为 Abhinav Asthana 的一个副项目启动，旨在简化测试和开发中的 API 工作流程。API 代表应用程序编程接口，它允许软件应用程序通过 API 调用相互通信。

Postman支持以下变量类型：Global、Collection、Environment、Data、Local。

技术人做了几年专业工作之后，会来到一个重要的“分岔路口”，一边是专业的技术路线，一边是技术团队的管理路线。不少人就开始犯难：究竟该往哪里走呢？

质量保证指标可以通过测试覆盖率来度量功能和非功能测试的覆盖率，同时也可以根据测试发现的缺陷的状态、优先级和关键程度来度量质量，最终目的是提高用户的满意度。通常使用实时监控和跟踪工具。通过主动监控和优化这些指标，可以改善服务和应用程序的健康状况、可用性和可靠性。建立和使用 SLA、SLI 和 SLO 等工具也很常见，以确保达到既定的质量标准和服务水平、设定明确的目标并专注于持续质量改进。服务级别协议 (SLA)：这是一份合同，用于确定将要提供的服务和必须满足的质量标准，在服务提供商和客户之间设定明确的期望。

集群中的数据被分片和副本存储在不同的节点上，从而实现数据的分布式存储和处理。每个分片可以有多个副本，副本可以被分配到不同的节点上，从而实现数据的冗余存储。1. 分布式架构：Elasticsearch 是一个分布式系统，可以在多个节点上运行，每个节点都可以处理数据的读取和写入请求。每个节点都可以存储数据的一部分，数据在节点之间自动分配和复制，以提高可靠性和性能。4. 主节点：Elasticsearch 集群中的一个节点被选为主节点，它负责管理集群的元数据，例如索引和分片的分配和复制。