作者：京东零售 吴聪
目前京东实行 BigBoss 机制以及积木型组织，同时现阶段再次强调了 “经营” 理念，以上均是比较大的组织层面的纲领和引导，核心是为了激发大家 owner 意识可以更好更快为公司产出价值和贡献。落到具体执行层面，与测试岗位息息相关的那便是 “测试 1 号位” 职责。
借用 Paul 总在开年战略会上的话：“职责有边界、思考无边界、担当无边界”
测试 1 号位一般由大型项目中拆分出来的角色（产品 1 号位、研发 1 号位、测试 1 号位等），也叫主测试，是该项目的质量架构师，负责把控整体的资源协调、测试计划、用例评审，风险预判以及问题解决等，保障项目高质量交付。
1. 自身想象成一个枢纽，可以连接多个测试个体、模块、业务线甚至团队机构，是一个化零为整、力出一孔的角色定位，凝聚大家的力量协作并完成目标，需要在测试内横向拉通，有较强的协调组织能力。
2. 是该角色的代言人，本身携带了半个项目经理的属性。需要与其他角色（业产研设项）有横向沟通，协商，甚至谈判等能力，能主动去前置思考，遇到事情有担当，能发言，逻辑思维能力强。
3. 职能上具有向上汇报和向下管理的能力。可以快速总结抽象进展进行汇报和复盘，或抛出问题、申请资源等。当有下属时学会管理整体工作安排，或继续拆解多个分 1 号位协助管理等，将自身的思想和价值观感染他人，需要有纵向沟通和管理能力。
总而言之，测试 1 号位是一个虚拟岗位，通常伴随项目而生，是变化的。但是在某个项目中，1 号位承担的责任和权利也是非常重要和关键，是实实在在的实体，是不变的。上述三点重点围绕 “沟通” 展开，可见身为 1 号位沟通是相当的关键。同样一名测试 1 号位的培养也离不开价值观的加持，比如拼搏、协作、担当、诚信、感恩、客户为先都是身为 1 号位应体现出的人格魅力。
从接到一个项目开始，测试 1 号位就开始了相关工作，以下 9 条工作指导可按序进行。
身处项目之中，当明确了自己 1 号位的职责后，第一反应不是马上扎入其中 “拆解” 而是应该先了解 “背景与环境”，比如为什么要做这个项目，带来哪些收益，涉及哪些团队，涉及哪些业务系统，有哪些关键角色和其他 1 号位，里程碑节奏和交付时间等等，总而言之是 “情报”，打好一场仗先要将情报工作做到位。用一个全盘视角去系统性的看待事情，这就是系统论的思想。了解这些信息有了整体认识便于更好的去做各类沟通，制定策略和战术，把控风险，所谓 “磨刀不误砍柴工”。
项目三要素告诉了我们 “时间、成本、范围”，在项目中范围是非常重要的概念，项目不能一直往里塞东西，需要有始有终有边界有范围。而在资源有限，时间节点不可更改的情况下，范围就显的更为重要。与业产研明确范围后，开始进行相应的资源预估和排期评估，在这个过程中通常已进行了 prd 和 brd 评审，建议 1 号位尽量多参与 brd 评审，更前置的了解业务思路和逻辑。遇到排期和资源紧张和风险时，学会提前协调和布局，或者上升申请而不是等到后面或者进入测试了再考虑，那样就会比较被动。
我们通常在一些小项目或者内部项目时，涉及几个模块系统都是比较清晰的，链路也较短大家也容易忽略。而一旦涉及到大型项目，跨多个团队项目，会涉及到几十个系统。此时业务之间的交互逻辑，系统之间的交互逻辑，必须要严格梳理出来。这就是 1 号位存在的枢纽价值，各个单位节点难以看到的全局需要你来看，难以识别的风险需要你来识别，难以想到的上下游问题需要你来提问。此时可以组织各个系统节点首先画出自身的逻辑，然后进行串联输出一个完整的系统链路，并且需要细化些可以到接口级别，其次到应用级别，最粗颗粒度到系统级别，越细致越能挖掘的透彻越能把控住风险。基于该链路图测试可以与研发一起评审，参与系统设计，同样基于该链路才可以制定下一步的测试策略和计划。
上述得到的链路逻辑图仍然只是个研发语言，我们需要将其转化成测试语言，即测试计划（也就是测试需要做的事情）。其中包括
a. 大型项目时链路过长，可以拆解成多个子链路跟进，但需要确认每个子链路的耦合性。小型项目直接拆解到具体模块负责人跟进即可。
b. 每个子链路/模块①确定好接口人或负责人，②确定内部的主要测试工作范围和内容，相关干系人，③确定可测性（测试环境或预发环境，测试物料的逻辑，上下游依赖逻辑），④确定高可用性（相关质量保障的举措的进一步明确），⑤确定自动化特性（主要用于测试执行的提效，灵活运用，平台和工具的使用）
c. 在上述的计划中进一步识别一些核心攻坚或业务特殊专项，比如测试物料专项、压测专项、兼容性测试专项、体验保障专项、安全专项等等。
把上述要做的事情基于现有资源，合理的安排进整体项目的排期中，从而制定出测试的里程碑计划。该点通常需要和项目经理保持强沟通，并将结果同步。
总之测试计划是拆解的产物，需要细化成一项项每个执行单元（个人、模块、团队）可执行的语言，同时给出时间计划，最好的方式是利用清单思维，输出一张清单表格，接下来就是按计划执行打钩即可。
下面就进入到了测试阶段了，这里单独把测试物料的事情提了出来。就目前营销平台域的项目为例，测试物料的诉求具有便捷性、可塑性、时效性、多维性、安全性的特性。便捷性需要更方便快捷的构造，而目前我们许多造数流程很冗长，成本和时间极高（需要用自动化或回放解决）；可塑性是需要能构造满足测试场景的物料，面对不同的业务大家的测试物料诉求是不一样的，也决定了这块的物料需求多而且杂（需要有自主的造数工具解决）；时效性和多维性是从时空的角度解读，营销的属性带来很多物料会失效（促销、预约、预售），因此对时效要求较高。而从物料分层来看，大家需要单一型测试物料（商品、券、账号、内容等），更需要复杂型测试物料（在单一型基础上叠加了用户行为或业务逻辑的场景化产物，如设促、策略、订单等），面对不同的维度需要有不同的解决办法。最后的安全性，更需要我们把控好各类权限和合规，避免影响到线上或者造成事故。
因此我们需要分析不同业务的特性，根据不同的特性情况有针对性的提出解决方案和长期的能力建设。然而最初还是需要设计好相关逻辑和表格，能前置收集整理好大家的测试物料诉求，避免到了最后再提出。这里梳理完毕也方便研发自测，和业务的走查，有必要时也可以组织物料评审。
用例评审是非常核心的内容，也是大家执行的标准和质量的标准。特别在大型项目中，不同系统之间的联调用例评审更是一种渠道，帮助大家识别是否有遗漏的地方。这里务必需要业务、产品、研发多角色都要参与，因为这是一个难得的信息汇总点，如果这里遗漏的信息，或者不对齐，将会直接导致后续的质量下降。测试 1 号位在这个环节也是一个把控质量的核心节点，1 号位应充分理解全链路逻辑图，在评审会上大胆发言和质疑，尽量排除每一个不确定因素。
评审后需要将会议的结果通过邮件的形式输出，明确每一个待办项都需要得到结论。另外评审会并不是结束，由此引发大家的思考会提出更多的风险点，这里需要测试 1 号位持续收集大家提出的可能的问题和风险，列出风险表并一一跟进结论。只有我们提前识别越多的问题和风险，项目后续的质量才能有所保证。一个项目最大的风险就是没有风险，或没人提问。
在执行过程我们使用现有公司内统一的测试工具，自动化工具和平台进行帮助规范操作和提效。这里重点梳理下大项目过程中 1 号位需要关注的一些信息和机制。其实这里最核心还是把控风险进一步识别和解决，如果我们前置的分析和预判到位，这里会轻松很多。
日例会机制：配合项目进行，每日将测试执行阶段的风险项及时抛出并寻求解决办法，和项目保持强沟通。这里要明确好风险的内容、影响是什么、需要谁协助，要清晰明确。
风险升级或者跨系统沟通：当项目日例会难以解决的问题或者内部无法解决时，需要及时升级解决，让更多的角色以及老板参与进来进行决策提高解决效率，千万不能藏在自己手里。
BUG 日清机制：面对系统复杂，问题众多而又临近交付节点，需要各角色加强协同而且提高要求，达到 BUG 日清，便于保障在规定时间内高质量交付。
测试记录收集：过程中的测试记录留痕，需要汇总做好记录便于追踪、复盘、归档或者赋能给其他项目。这里包括了物料的评审记录，风险评审记录，用例评审记录，各系统测试报告，大联调记录或者全链路回归等。如果是要求比较高的项目，测试 1 号位也需要发出每日的测试进度报告，这里需要收集各个系统的进展、风险、卡点等（有的跟随项目日报可以 cover）。
紧急需求与变更把控：项目中难免会遇到各类变更，其中最大的风险就是紧急需求的插入，需要与项目制定准入机制，对 ROI 高的紧急需求进行评估按照现有资源合理安排，同时当有大量紧急需求，已经严重影响到交付质量时，需要进行多轮 review 或其他方式保障交付质量。“变更” 是引入问题的根源。
与业产设协同：与前链路角色进行协同，及时邀请进入 UAT 走查或者验收，提前发现问题。如果使用预发环境或测试环境，需提前准备好相关物料和使用手册说明。
小型项目时各个模块各司其职，容易忽略全链路视角的回归或者演练，当然因为涉及模块少因此质量容易把控。但是 “全链路” 思想是一名测试 1 号位必须要具备的，我们举个军演压测的例子，每年大促的军演其实也是一个基于流量的项目，卷入了公司内的所有系统，因此我们的军演一定是全链路的，只有全链路才能模拟线上真实的流量情况。大型项目同理，即使我们每个系统、模块完成了自己的测试工作，并不意味着整体链路就没问题了，我们需要模拟线上用户和业务最真实的场景和习惯，进行全链路演练或回归。
具体的操作离不开全链路联调用例，这里建议从上述的评审用例中挑选 P0 级涉及到核心主干的用例作为剧本用例，在一个规定的时间范围内，组织各个角色一同参与剧本演练，及时发现问题，如果能邀请业务、用户等种子选手参与更好，此时很有可能提出我们意想不到的场景和问题，而这样的问题就是我们剧本演练最大的价值。
上线切量与监控：与项目经理、产品 1 号位、研发 1 号位等核心角色一同确认好研发的上线顺序和机器灰度策略，避免出现上线顺序问题，发现问题后及时回滚，准备好降级开关和预案。确定好业务的灰度策略，或者使用时间点，做好及时响应和解决。另外上线后的巡检和监控必不可少，需要第一时间加入至巡检体系，巡检是我们的眼睛，可以代替我们发现很多问题。同时用表格记录线上发现的各类问题，及时跟进问题修复进展。
总结与复盘：对新业务需要基于全链路逻辑图以及各个节点的业务知识点进行汇总，进行知识库的沉淀；对项目好的测试实践进行沉淀并形成通用能力进行赋能；对项目中的测试卡点进行分析，避免犯同样的问题。大部分 1 号位容易忘记复盘，每一个项目都是一个宝贵的经历，如何让经历变成自己的财富，需要进行反思和复盘，并且进行输出。
百亿补贴项目是 2023 年初零售最核心的项目，涉及系统范围之广，相关人员之多，上线交付时间之急，也是前所未有的。各个团队牺牲了较多的春节和假期时间，测试同学们在这个项目中也收获了良多，分拆了多链路和专项 1 号位，一起携手最终保障的交付。
百补的测试 1 号位细分了 6 大子链路（创促链路、导购链路、交易链路、资金链路、申诉链路、渠道屏蔽）基本覆盖了全部项目范围并设立各链路测试 1 号位，而这些链路几乎也涵盖了京东 APP 的核心业务，每个子链路 1 号位下继续对接各系统接口人。同时设立了 7 大专项（物料统筹、频道性能、B 端体验、版本保障、风控保障、压测保障、众测保障）测试 1 号位，后期也引入了安全团队介入，从测试链路的每个阶段，从 B 到 C 各个系统，各个维度加强质量保障举措。
随着时代的进步，我们面临的业务会越来越复杂，面临的技术也会越来越进化，对测试 1 号位的要求同样也会越来越高，职责边界越来越扩大，更需要有思考，有担当，有 owner 意识扛起整体项目的质量与交付。最后这里再列举一些 tips 分享。
1. 与项目经理的协作：测试 1 号位需要与项目经理紧密协作，上述也提到了多次，之所以说本身带有半个项目经理属性，是因为测试和项目都对 “质量” 关注，这是相通点。由该点引发的各类举措，大家是可以互相理解互相帮助的。
2. 与主测试的协作：在目前的团队中会并行多个项目，同时存在多个项目的测试 1 号位，同时这些项目又卷入了多个系统测试（模块测试）的主测。这里就形成了项目的测试 1 号位与系统主测之前的关系协同与矛盾点。其实还是经营理念的差异，系统主测或者产品线主测关注的是长期，而项目测试 1 号位关注的是该项目本身。一个项目测试 1 号位会协同多个系统主测，共同交付这个项目。而一个系统主测可能会承接多个项目，需要合理安排好自己模块的资源和时间，与多个测试 1 号位沟通协调，保障每个项目的交付。这里是 “多对多” 的关系，因此更需要大家齐心协力，遇到排期资源上的问题时，多沟通多协调；遇到项目统筹层面的问题时，需要参考项目测试 1 号位的意见；遇到具体执行实施时，要多深入了解系统主测的情况和现状。这里我建议从系统主测的角度需要立版本，定节奏，帮助长期的迭代和质量把控；从项目测试 1 号位角度需要立机制，定规范，帮助项目敏捷高质量交付。
3. 1 号位的并行策略：每个测试 1 号位类似大家长角色，需要看到项目里所有和测试相关的事情，任何问题都要去管理，一定会存在大量并行的事务，这里非常考验大家对并行的处理。建议大家把事情“写下来”，同时排好优先级，自己不要乱，确保自己能聚焦精力集中处理一件事。
4. 重点把握结果，解决核心问题：多数 1 号位同学在跟进项目时，有着测试人员的特性会很细心，有时对执行过程很细致。这不是坏事，但是会大量浪费精力，特别面临大型项目时，测试 1 号位要学会设卡点，看结果，轻过程，这样才能把精力用在刀刃上。另外项目中一定会发生多数问题，有业务层面有资源层面等，要学会优先解决核心问题，抓大放小。
5. 与担当相对应的解压：1 号位是有责任感的，是有担当的，必然肩膀上会承担很多压力。特别是第一次做 1 号位的同学，或多或少会不适应感觉压力巨大，一定要学会解压释放，好的方法包括与上级沟通倾诉，与小伙伴吐槽，寻求他人帮助与援助，吃吃吃等。但是请相信，每一次 1 号位经历都是很好的成长机会，勇敢挑战，希望大家都能借此收获自己的感悟与改变。
