作者语：初来阿里实习的时分，我对测验人员的责任知之甚少，在校时更是从未触摸过测验工作。一头雾水之际，主管说：“做项目吧，在实战中快速生长”。从学生到校招生，我在思想和心态完结了一次实在意义上的改变，也期望未来可以开启一段新的旅程。在主管、师兄师姐和搭档们的协助下，我从一个懵懂的小白努力学习生长为可以独立完结需求的测验同学，也期望未来自己可以不断进步单独owner项目。特地写下此文，针对试用期内自己关于事务的感悟和沉积整理出的测验相关的知识做个总结。

思想形成-测验流程总结

针对每一个需求，测验人员都应该从需求规划阶段就开端参加，经过测验左移尽早地介入需求、发现问题。”第一时间发现缺点，第一时间解决”。下面是我在测验进程中依据事务特性整理出的测验人员在项目各个阶段应该保证的行为规范。

需求规划阶段 – 测验计划与需求评价

在需求评定阶段，测验人员需求了解需求、事务目标和完结逻辑，为测验规划做准备。可以在这个阶段识别出产品规划的危险，同开发人员一起整理出事务的危险点和监控点，归入危险防控的考虑规模内。在此阶段还应依据测验资源、事务要求的角度清晰测验规模、测验目标、测验要点和难点、如何安排测验节奏等。

除此之外，咱们还应该考虑需求中是否涉及到用户体会、公关、资金危险、财政等等一系列躲藏问题，这些都可以经过需求阶段发掘出来。提早识别到其间的危险并提出，可以有用避免由于需求规划计划变化带来的额定开发和测验成本。

开发规划阶段 – 剖析与规划

在此阶段，作为测验人员应该熟悉技能完结计划，评价该计划是否满意事务的需求以及是否存在潜在危险，以便愈加准确地写好测验用例。依据需求、质量特性、稳定性、资损防控等特性写好测验用例，并在提测之前邀请开发、事务等关联方进行测验用例评定。

在测验用例评定的进程中也有助于将团队各方成员的了解拉到共同。这个阶段的中心便是咱们需求了解需求中躲藏的逻辑、是否有相关的前史逻辑影响需求的完结或是关于用户来说有矛盾的当地，以及是否涉及到上下流接口逻辑的处理等等。

此刻和需求规划阶段的区别便是需求规划阶段是倾向于白盒的，而在开发规划阶段的代码规划细节倾向于黑盒。

测验阶段 – 测验履行与战略施行

首要可以对主流程进行冒烟测验或是让提测方履行，保证提测是满意约定的标准和内容的。在测验履行的进程中，需求对缺点修复进行验证、经过手艺或自动化的方式进行回归测验、进行非功用性的验证（如页面的功用、适配、监控、资损对账等）。可以安排事务验收测验成果，看看项目是否契合事务预期的功用和价值。

发布前后

1. 灰度验证：灰度验证是发布的有必要进程，在发布上线前测验人员需求对改变和或许影响的功用在安全出产环境进行验证，并坚持一段时间的调查，让问题有机会暴露出来，避免上线呈现问题。
2. 发布履行配合：测验人员要和开发人员整理对齐发布上线的计划，重视发布的全体进程，检查相关装备项的参数是否正确、装备项是否收效以及需求验证日志、监控的成果是否契合事务预期。
3. 线上回归：发布后需求进行一段时间的监控调查，以及在外网4G的状况下进行线上的回归验证。
4. 问题盯梢：经过对线上问题的盯梢可以协助测验人员反思测验遗漏该点的原因，评价自己测验计划的缺乏并吸取经验教训再进行改善，形成稳定性建造的良好循环。

行之有道-测验用例的规划

作为新人，如何写好测验用例是一门需求下功夫的学识。测验用例写好了，可以保证后边的测验工作高效有序进行。回想起刚入职时写的第一份测验用例，可以说便是需求PRD的一份简要“翻译”。但其实测验用例的规划是需求结合测验办法理论和有自己关于事务特性的考虑的。那么作为一个测验开发新人来说，怎样样才能进步所写的测验用例的质量呢？下面我会结合事务场景，讲讲我是如何规划测验用例的。

这里我给出一个详细的需求：

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

第一步：剖析需求

从接到一个需求开端，咱们首要要做的是剖析这个需求的内容，确定需求影响的规模，影响到了哪些页面，这个需求是修改了原有的接口还是新增了接口，需求获取的数据是从哪儿读取的等等，这些都可以在技能计划评定之前有所考虑和清晰。而不是看到需求上有什么，就怎样写怎样做，在这中间最重要的便是自己的考虑与见地。

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

用例描述	前提条件	用例步骤	预期成果
没有进行实名身份认证的用户无法进行抽奖	用户没有进行实名身份认证	1、用户A进入活动页2、用户A履行抽奖	1、提示用户需求首要进行实名认证2、没有恳求抽奖接口
归于A规矩的用户A发放a奖品	用户A契合A规矩	1、用户A进入活动页2、用户A履行抽奖	1、用户A取得了a奖品2、用户A没有取得b奖品
归于B规矩的用户发放b奖品	用户B契合B规矩	1、用户B进入活动页2、用户B履行抽奖	1、用户B取得了b奖品2、用户B没有取得a奖品

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

1. A规矩和B规矩是互斥的吗？一个用户有没有或许即在A规矩中又在B规矩中？
2. 用户是否可以重复进行抽奖？其间的幂等性是否可以保证？
3. 用户本来契合A规矩，抽奖取得了a奖品后变成了契合B规矩，是否还可以持续抽奖取得b奖品呢？
4. 用户在抽奖的进程中恳求接口反常了，页面该如何展现呢？

所以咱们在接到需求的时分，需求深化考虑其间的逻辑和用户或许存在的场景，发掘潜在的需求，才能把一个测验用例写全面。

第二步：剖析技能计划

参加开发的技能计划评定的时分，可以站在整个事务的层面进行考虑，计划不只在技能上要合理，还要对用户友爱。咱们规划开发的功用最终运用者是客户，咱们要把自己当作客户来进行测验。例如我曾经参加过的积分抽奖需求，用户在活动页中奖后，服务端会依据用户中奖的消息写入数据库中，页面依据它再展现用户已中奖。在技能层面这是没有问题的，但若是写入数据库反常或是延迟了，在用户看来自己就像没有中奖，体会很差不说或许还会引起客诉。所以最终咱们的规划计划在用户中奖后也写了一份缓存数据，保证用户能及时看到自己的中奖信息。这样一个小小的改动就能让咱们收成客户更高的满意度，提供更优的运用体会。一起也要考虑当时的技能计划是否可以支撑后续事务增长、事务多样化的需求。避免一次需求一个技能计划，重复造轮子。

在这个需求例子中，咱们要针对技能计划剖析什么呢？在完结了上一阶段对需求的全面考虑后，咱们应该可以剖分出，咱们需求特别重视技能计划中如何保证规矩的互斥、抽奖的幂等性、用户在不同规矩改变的状况以及反常case的代码逻辑。在这个阶段及时提出其间或许存在的危险和反常提早告知开发和产品经理，可以有用削减后续代码改动的成本，并提升用户的体会。

第三步：规划测验用例

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

等价类+鸿沟值区别

关于各种输入和输出，有必要要考虑等价类区别和进行鸿沟值的测验，以及进行反常值、特别值的测验。在规矩了输入数据有必要恪守的规矩后，可以承认一个契合规矩的有用等价类和若干个从不同角度违背规矩的无效等价类。

例1：进展条的文案会依据抽奖预算池的耗费程度展现不同的文案。

输出条件	有用等价类	预期成果
奖池预算耗费进展为0%-100%	1.progress=0%2.progress=50%3.progress=100.0%	1.xx大奖等你来抽2.疯抢中3.活动结束咧

场景法

现在的事务需求一般都是事件来触发操控流程的，触发的不搭档件便形成了场景。关于包含逻辑进程、复杂场景、状态机等的事务推荐运用场景法，测验用例的规划应尽或许贴近用户的实在运用场景，围绕场景进行更多的探索。详细来说是从活动参加者的角度依据不同的场景来规划用例，一般有以下3种场景：

1. 一般场景：从输入和输出都彻底满意事务的要求，比方用户进入活动页，在抽奖所需资源满足、奖池库存满足的状况下进行了一次抽奖，并成功收取到了奖品的场景。
2. 特别场景：用户在一般场景的履行进程中发生了不契合预期规矩的场景，如用户抽奖时的余额缺乏、奖池库存缺乏等，需求充沛考虑并验证该类特别场景下的体现是否契合预期，避免资损。
3. 反常场景：依据整理出的中心链路和强弱依靠，在所有结点上考虑反常或注入过错即可得到反常场景用例。

前史经验

当利用场景法规划出测验用例，并充沛验证了等价类和鸿沟值条件后，可以利用测验人员积累的经验和前史缺点、毛病等手法补充测验用例。例如我负责的会员相关事务，其实是很重运营的装备的。可是活动的数量多、需求装备的信息繁杂、运营手头的活动又有许多，很简单形成装备出错的状况。关于这类场景，咱们在体系完结阶段就要考虑人工装备过错的场景下体系的健壮性以及在测验进程中验证即使在装备过错的场景下咱们的活动页也要坚持用户感知不到的正常体现。

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

依据前史经验可以添加测验用例：假如运营同学在奖品资料上装备了该字段且不为特定的字段时，前台应该过滤这个权益，不透出给用户。而且应该添加对应的监控报警，第一时间发现装备上的过错，避免资损。

稳定性相关剖析规划

当功用性的测验用例规划完结之后，可以补充一些非功用性的稳定性相关的测验用例，比方功用、并发、可用性、兼容性限流验证等相关的用例。
例4：整理并验证活动中心接口在限流后的体现是否契合事务预期，以及是否装备了限流、限流是否能收效等，以及对应预案的履行和康复状况。
例5：发布兼容性测验，代码和数据有兼容性时需添加对应的测验用例。

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

更进一步-项目质量计划

在充沛地了解需求和较为全面地规划好测验用例后，测验人员应该对项目的质量保证有更高寻求。例如我所在的会员事务是淘宝内用户数量较多的事务，在各个大促期间更是会有比往常高不少的QPS，假如保证项目的稳定性，是咱们在完结功用性验证后更需求重视的要点。下面我将从中心链路整理、强弱依靠整理、限流兜底和资损防控四方面来介绍。

稳定性管理：中心链路整理

每一个事务动作背面都是多个体系之间的调用，而这些体系之间的调用组成了一条条的链路，整理并清晰这些链路的调用联系关于稳定性保证具有重要的意义。针对技能计划，测验人员需求在脑海中形成整个事务的流程和清晰其间的数据流转。经过整理事务场景下的中心链路不只可以协助测验人员提早发现技能计划的危险点，也可以让咱们清晰哪些链路是需求要点保证的，在测验时更有侧要点。

稳定性管理：强弱依靠整理

强弱依靠管理便是经过科学的手法持续稳定地得到运用间依靠联系、流量、强弱等数据，提早发现由于依靠问题或许导致的毛病，避免依靠毛病影响用户体会。在测验前提早整理强弱依靠，在测验进程中验证下流依靠反常时，活动页的体现是否契合预期，避免页面空窗、白屏等。

针对示例需求的强弱依靠整理如下，一般我会运用混沌工程东西实在地注入各个强弱依靠的毛病以此来验证事务表的现是否契合预期，关于难以实在注入毛病的场景可以考虑经过debug抛出反常来完结。

稳定性管理：限流兜底

经过限流，咱们可以较好地操控体系的QPS，然后到达维护体系或许接口服务器稳定的目的。一方面，限流可以避免接口被刷，形成不必要的服务层压力；另一方面，是为了避免接口被乱用。完整整理并针对本次活动涉及到的所有接口并装备限流以此来维护体系接口和下流接口。并在上线前验证了限流后的体现和康复限流的体现是否契合预期、是否对用户友爱。

所以在本需求中，咱们还需求重视抽奖接口在到达了设置的限流恳求时页面的体现。

用例描述	前提条件	用例步骤	预期成果
抽奖接口在限流时需求提示用户	抽奖接口的QPS超过了设定的限流阈值N	1、一起有超过N个的用户履行抽奖	1、没有被限流的用户可以正常抽奖2、被限流的用户，活动页面提示“活动太火爆啦，稍等一下再试试吧”

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

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

解决计划：校验事务的数据是否正确，保证数据是干净契合预期的，特别是涉及资金的需求，经过自动的对账发现需求中的漏洞。对账便是稳定性中的要害环节。咱们需求整理出或许呈现资损的场景，并经过离线小时级的SQL对账和接收消息的实时对账，对奖品的限领规矩、奖品发放的量级和兑换奖品用户的身份进行对账，以便及时发现潜在问题，及时止血，在用户的舆情到来之前发现问题。

关于产品规划和体系完结环节，在测验保证层面经过对事务流程和技能计划中心链路及强弱依靠的整理，保证正常和反常的事务场景都能被充沛覆盖。此外，从预发环境至线上多环境对测验回归，也是保证问题充沛暴露的重要环节。在测验环节中，整理并验证了奖品兑换时的各类特别和反常场景，保证只有契合事务规矩的场景下可以收取到对应的奖品权益。

特别和反常场景整理	预期成果
用户非目标用户	1、前端提示：兑换失利，前端提示：请刷新后重试，奖品详情页进行刷新操作 2、奖品不发放，且积分不扣减3、如条件满意可再次进行兑换
用户未授权
用户已授权 但未认证
用户未满18周岁
用户积分缺乏
奖品库存缺乏
用户已经收取过奖品
操作兑换后，奖品发放失利
兑换操作时，回来未知过错
操作兑换后，接口回来超时

质量底线-安全出产

安全出产关于体系稳定性来说是至关重要的，有必要要严格恪守，也是咱们测验人员有必要要遵照的质量底线。关于改变流程环节，除了在预发环境中做好充沛的测验，关于发布上线的环节要严格恪守改变窗口期、改变规范、改变管控。线上收效后，需对要害事务大盘的监控核对进行要点调查，保证事务契合预期。

写在最终

未来期望自己能愈加了解部分的事务特性、提升自己的测验思想和代码技能、把学习成果落地在事务中，快速生长。也期望各位校招生可以在工作中快速生长，保卫技能质量！