我在阿里做测试，入职5个月的回顾与总结

思维形成-测试流程总结

针对每一个需求，测试人员都应该从需求设计阶段就开始参与，通过测试左移尽早地介入需求、发现问题。"第一时间发现缺陷，第一时间解决"。下面是我在测试过程中根据业务特性梳理出的测试人员在项目各个阶段应该保障的行为规范。

▐  需求设计阶段 - 测试计划与需求评估

在需求评审阶段，测试人员需要了解需求、业务目标和实现逻辑，为测试设计做准备。可以在这个阶段识别出产品设计的风险，同开发人员一起梳理出业务的风险点和监控点，纳入风险防控的考虑范围内。在此阶段还应根据测试资源、业务要求的角度明确测试范围、测试目标、测试重点和难点、如何安排测试节奏等。

除此之外，我们还应该思考需求中是否涉及到用户体验、公关、资金风险、财务等等一系列隐藏问题，这些都可以通过需求阶段挖掘出来。提前识别到其中的风险并提出，可以有效防止因为需求设计方案变化带来的额外开发和测试成本。

▐  开发设计阶段 - 分析与设计

在此阶段，作为测试人员应该熟悉技术实现方案，评估该方案是否满足业务的需求以及是否存在潜在风险，以便更加准确地写好测试用例。根据需求、质量特性、稳定性、资损防控等特性写好测试用例，并在提测之前邀请开发、业务等关联方进行测试用例评审。
在测试用例评审的过程中也有助于将团队各方成员的理解拉到一致。这个阶段的核心就是我们需要了解需求中隐藏的逻辑、是否有相关的历史逻辑影响需求的实现或是对于用户来说有矛盾的地方，以及是否涉及到上下游接口逻辑的处理等等。
此时和需求设计阶段的区别就是需求设计阶段是偏向于白盒的，而在开发设计阶段的代码设计细节偏向于黑盒。

▐  测试阶段 - 测试执行与策略实施

首先可以对主流程进行冒烟测试或是让提测方执行，确保提测是满足约定的标准和内容的。在测试执行的过程中，需要对缺陷修复进行验证、通过手工或自动化的方式进行回归测试、进行非功能性的验证（如页面的性能、适配、监控、资损对账等）。可以组织业务验收测试结果，看看项目是否符合业务预期的功能和价值。

▐  发布前后

1. 灰度验证：灰度验证是发布的必须过程，在发布上线前测试人员需要对变更和可能影响的功能在安全生产环境进行验证，并保持一段时间的观察，让问题有机会暴露出来，避免上线出现问题。
   
2. 发布执行配合：测试人员要和开发人员梳理对齐发布上线的方案，关注发布的整体过程，检查相关配置项的参数是否正确、配置项是否生效以及需要验证日志、监控的结果是否符合业务预期。
   
3. 线上回归：发布后需要进行一段时间的监控观察，以及在外网4G的情况下进行线上的回归验证。
   
4. 问题跟踪：通过对线上问题的跟踪可以帮助测试人员反思测试遗漏该点的原因，评估自己测试方案的不足并吸取经验教训再进行改进，形成稳定性建设的良好循环。
   

行之有道-测试用例的设计

作为新人，如何写好测试用例是一门需要下功夫的学问。测试用例写好了，可以保障后面的测试工作高效有序进行。回想起刚入职时写的第一份测试用例，可以说就是需求PRD的一份简要“翻译”。但其实测试用例的设计是需要结合测试方法理论和有自己对于业务特性的思考的。那么作为一个测试开发新人来说，怎么样才能提高所写的测试用例的质量呢？下面我会结合业务场景，讲讲我是如何设计测试用例的。

这里我给出一个具体的需求：

用户在活动页面可以看到抽奖的入口，在活动页面可以看到目前已发放奖品份额的进度条。用户点击抽奖按钮时，前端会针对两类不同规则的用户分别发放不同的奖品：即属于A规则的用户发放a奖品，属于B规则的用户发放b奖品。没有进行实名身份认证的用户无法进行抽奖。

▐  第一步：分析需求

从接到一个需求开始，我们首先要做的是分析这个需求的内容，确定需求影响的范围，影响到了哪些页面，这个需求是修改了原有的接口还是新增了接口，需要获取的数据是从哪儿读取的等等，这些都可以在技术方案评审之前有所思考和明确。而不是看到需求上有什么，就怎么写怎么做，在这中间最重要的就是自己的思考与见解。

举个例子，针对上述需求，我们是不是可以很快地编写出测试用例呢？

这样的用例乍看没有问题，是正常的功能验证，但是细想其实遗漏了一些场景。比如说：

1. A规则和B规则是互斥的吗？一个用户有没有可能即在A规则中又在B规则中？
   
2. 用户是否可以反复进行抽奖？其中的幂等性是否能够保障？
   
3. 用户原本符合A规则，抽奖获得了a奖品后变成了符合B规则，是否还能够继续抽奖获得b奖品呢？
   
4. 用户在抽奖的过程中请求接口异常了，页面该如何展示呢？
   

所以我们在接到需求的时候，需要深入思考其中的逻辑和用户可能存在的场景，挖掘潜在的需求，才能把一个测试用例写全面。

▐  第二步：分析技术方案

参与开发的技术方案评审的时候，可以站在整个业务的层面进行思考，方案不仅在技术上要合理，还要对用户友好。我们设计开发的功能最终使用者是客户，我们要把自己当作客户来进行测试。例如我曾经参与过的积分抽奖需求，用户在活动页中奖后，服务端会根据用户中奖的消息写入数据库中，页面根据它再展示用户已中奖。在技术层面这是没有问题的，但若是写入数据库异常或是延迟了，在用户看来自己就像没有中奖，体验很差不说可能还会引起客诉。所以最后我们的设计方案在用户中奖后也写了一份缓存数据，保证用户能及时看到自己的中奖信息。这样一个小小的改动就能让我们收获客户更高的满意度，提供更优的使用体验。同时也要思考当前的技术方案是否可以支持后续业务增长、业务多样化的需求。避免一次需求一个技术方案，重复造轮子。

在这个需求例子中，我们要针对技术方案分析什么呢？在完成了上一阶段对需求的全面思考后，我们应该可以分析出，我们需要特别关注技术方案中如何保证规则的互斥、抽奖的幂等性、用户在不同规则转变的情况以及异常case的代码逻辑。在这个阶段及时提出其中可能存在的风险和异常提前告知开发和产品经理，可以有效减少后续代码改动的成本，并提升用户的体验。

▐  第三步：设计测试用例

在真正动手编写测试用例之前，要对整个需求的逻辑了解清晰，有条件的话可以先画流程图，然后再对各个模块充分考虑各种入参和出参的组合情况。测试用例是为了验证功能需求而设计的，应避免过度设计，从需求本身出发。下面我简要介绍一下我常用常考虑的几种设计方法。

• 等价类+边界值划分
  

对于各种输入和输出，必须要考虑等价类划分和进行边界值的测试，以及进行异常值、特殊值的测试。在规定了输入数据必须遵守的规则后，可以确认一个符合规则的有效等价类和若干个从不同角度违反规则的无效等价类。

例1：进度条的文案会根据抽奖预算池的消耗程度展示不同的文案。

• 场景法
  

现在的业务需求通常都是事件来触发控制流程的，触发的不同事件便形成了场景。对于包含逻辑过程、复杂场景、状态机等的业务推荐使用场景法，测试用例的设计应尽可能贴近用户的真实使用场景，围绕场景进行更多的探索。具体来说是从活动参与者的角度根据不同的场景来设计用例，一般有以下3种场景：

1. 一般场景：从输入和输出都完全满足业务的要求，比如用户进入活动页，在抽奖所需资源足够、奖池库存足够的情况下进行了一次抽奖，并成功领取到了奖品的场景。
   
2. 特殊场景：用户在一般场景的执行过程中发生了不符合预期规则的场景，如用户抽奖时的余额不足、奖池库存不足等，需要充分考虑并验证该类特殊场景下的表现是否符合预期，避免资损。
   
3. 异常场景：根据梳理出的核心链路和强弱依赖，在所有结点上考虑异常或注入错误即可得到异常场景用例。
   

• 历史经验
  

当利用场景法设计出测试用例，并充分验证了等价类和边界值条件后，可以利用测试人员积累的经验和历史缺陷、故障等手段补充测试用例。例如我负责的会员相关业务，其实是很重运营的配置的。但是活动的数量多、需要配置的信息繁杂、运营手头的活动又有很多，很容易造成配置出错的情况。对于这类场景，我们在系统实现阶段就要考虑人工配置错误的场景下系统的健壮性以及在测试过程中验证即使在配置错误的场景下我们的活动页也要保持用户感知不到的正常表现。

例3：在这个抽奖需求中，抽奖可以限制参与的用户只能为某类特定的用户，这个信息需要运营同学配置在对应奖品权益的素材信息上，供服务端读取。

根据历史经验可以增加测试用例：如果运营同学在奖品素材上配置了该字段且不为特定的字段时，前台应该过滤这个权益，不透出给用户。并且应该增加对应的监控报警，第一时间发现配置上的错误，避免资损。

• 稳定性相关分析设计
  

当功能性的测试用例设计完成之后，可以补充一些非功能性的稳定性相关的测试用例，比如性能、并发、可用性、兼容性限流验证等相关的用例。
例4：梳理并验证活动核心接口在限流后的表现是否符合业务预期，以及是否配置了限流、限流是否能生效等，以及对应预案的执行和恢复情况。
例5：发布兼容性测试，代码和数据有兼容性时需增加对应的测试用例。

如我们本次示例需求中的活动页面还有灰度放量的新版和老版的区分，在完成了需求的功能测试之后，还应对代码和数据的兼容性进行分场景的测试与回归。

更进一步-项目质量方案

在充分地理解需求和较为全面地设计好测试用例后，测试人员应该对项目的质量保障有更高追求。例如我所在的会员业务是淘宝内用户数量较多的业务，在各个大促期间更是会有比平常高不少的QPS，如果保障项目的稳定性，是我们在完成功能性验证后更需要关注的重点。下面我将从核心链路梳理、强弱依赖梳理、限流兜底和资损防控四方面来介绍。

▐  稳定性治理：核心链路梳理

每一个业务动作背后都是多个系统之间的调用，而这些系统之间的调用组成了一条条的链路，梳理并明确这些链路的调用关系对于稳定性保障具有重要的意义。针对技术方案，测试人员需要在脑海中形成整个业务的流程和明确其中的数据流转。通过梳理业务场景下的核心链路不仅可以帮助测试人员提前发现技术方案的风险点，也可以让我们明确哪些链路是需要重点保障的，在测试时更有侧重点。

▐  稳定性治理：强弱依赖梳理

强弱依赖治理就是通过科学的手段持续稳定地得到应用间依赖关系、流量、强弱等数据，提前发现因为依赖问题可能导致的故障，避免依赖故障影响用户体验。在测试前提前梳理强弱依赖，在测试过程中验证下游依赖异常时，活动页的表现是否符合预期，避免页面空窗、白屏等。

针对示例需求的强弱依赖梳理如下，通常我会使用混沌工程工具真实地注入各个强弱依赖的故障以此来验证业务表的现是否符合预期，对于难以真实注入故障的场景可以考虑通过debug抛出异常来实现。

▐  稳定性治理：限流兜底

通过限流，我们可以较好地控制系统的QPS，从而达到保护系统或者接口服务器稳定的目的。一方面，限流可以防止接口被刷，造成不必要的服务层压力；另一方面，是为了防止接口被滥用。完整梳理并针对本次活动涉及到的所有接口并配置限流以此来保护系统接口和下游接口。并在上线前验证了限流后的表现和恢复限流的表现是否符合预期、是否对用户友好。

所以在本需求中，我们还需要关注抽奖接口在达到了设置的限流请求时页面的表现。

▐  资损防控：资金链路测试+对账监控

资损相关：活动发放的奖品有特定用户身份的限制、每人限兑一次的门槛，且每款奖品限量xxxx份，防止资损也是测试过程中必须严格保障的要求。

解决方案：校验业务的数据是否正确，保证数据是干净符合预期的，特别是涉及资金的需求，通过主动的对账发现需求中的漏洞。对账就是稳定性中的关键环节。我们需要梳理出可能出现资损的场景，并通过离线小时级的SQL对账和接收消息的实时对账，对奖品的限领规则、奖品发放的量级和兑换奖品用户的身份进行对账，以便及时发现潜在问题，及时止血，在用户的舆情到来之前发现问题。

对于产品设计和系统实现环节，在测试保障层面通过对业务流程和技术方案核心链路及强弱依赖的梳理，确保正常和异常的业务场景都能被充分覆盖。此外，从预发环境至线上多环境对测试回归，也是确保问题充分暴露的重要环节。在测试环节中，梳理并验证了奖品兑换时的各类特殊和异常场景，确保只有符合业务规则的场景下可以领取到对应的奖品权益。

质量底线-安全生产

安全生产对于系统稳定性来说是至关重要的，必须要严格遵守，也是我们测试人员必须要遵从的质量底线。对于变更流程环节，除了在预发环境中做好充分的测试，对于发布上线的环节要严格遵守变更窗口期、变更规范、变更管控。线上生效后，需对关键业务大盘的监控核对进行重点观察，确保业务符合预期。

写在最后

未来希望自己能更加了解部门的业务特性、提升自己的测试思维和代码技术、把学习成果落地在业务中，快速成长。也希望各位校招生能够在工作中快速成长，捍卫技术质量！