互联网测试少，测试研发比大概在1:5，再加上产品再使足了劲上需求，导致了测试需求量大，测试准备时间短，从而降低了上线质量。那么如何解决呢？测试是质量负责人，要对平台质量负责，于是就需要做一些取舍，挑重点测。因此，在时间不充裕的前提下，质量负责人要有能力评估需求的风险等级，给出一个令人信服的不测理由。具体来说要做两件事情，第一梳理平台链路，第二梳理线上问题。
测试是质量负责人，要对平台质量负责
互联网测试少可太常见了，测试研发比大概在1:5，再加上产品再使足了劲上需求，导致每天晚上都有测试唉声叹气，今天加班测呗，但加班真的能保证质量吗？
我看未必！种种因素致使测试需求量大，测试准备时间短，从而降低了上线质量。可以从沟通少和技术原理不理解二个层面来分析，第一沟通时间少会对需求理解偏差，如果连需求都不了解，测试范围必然不会很全，测试内容也不会正确。第二没时间了解技术原理，导致测试浮于表面，坦白了讲，很多测试人员还不如用户或者运营测的全面。那么该如何解决“测试需求量大、测试准备时间短”的问题呢？
解铃还须系铃人，测试要做一些取舍，挑重点测。什么什么？你说“产品认为，所有需求很重要，必须全部要测”，什么什么？你又说“研发认为，所有变更都是重点，必须全部要测”，如果出现了这种想法，说明测试被产品/研发牵着走啦！提出这种问题的测试同学，是在被动接收产品/研发的命令，大概率无法回答“哪些应用存在问题多？哪些应用存在问题少？哪些应用是核心链路？”。不了解平台质量情况就相当于一只无头苍蝇，产品认为此次需求重要就飞到产品那，研发认为此次变更重要就飞到研发那，这种信息差导致双方（测试和其他人）无法平等沟通。
无法平等沟通的根因是测试对自身定位不清晰。测试又称质量负责人，要对平台质量负责，用一套粗糙标准来解释“平台质量好说明测试能力强，平台质量差说明测试能力弱”，因此，在时间不充裕的前提下，质量负责人要有能力评估需求的风险等级，给出一个令人信服的不测理由。具体来说要做两件事情，第一梳理平台链路，第二梳理线上问题。
梳理平台链路，提出专业建议
什么是平台链路呢？拿支付宝app举例，其内功能包括理财、支付、客服等等。现在有一个新需求“更新了我的客服问题识别模型”，相信一些人接到需求后会先打开「我的客服对话框」，然后输入模糊问题“啊要你？”来测试模型的正确性。
如果将「我的客服」进行链路拆解，能分析出下面这样的结构，代码逻辑会先识别用户情绪“判断你是生气状态还是高兴状态”，如果是生气状态可能直接转人工（生气的人很容易投诉，让人工处理会更好），如果是高兴状态才会进行问题识别。如果你清楚这个链路就能有针对地进行测试，比如输入问题时会使用高兴状态+模糊问题，某些特殊情况下，甚至直接对「模糊问答模型」进行接口测试。
如果没有梳理平台链路，测试只能被动接受信息，无法给出专业的测试建议。但是当梳理清平台链路后，测试就能够给出比较专业的意见。假设本次需求更新了「情绪识别模型」，能精准地识别用户情绪，从整个链路角度来看，如果情绪识别出现了问题，最差情况下是“把生气的用户识别成高兴”，后续会进行问题识别来解答用户问题（而非转人工），其实影响面不算特别大。
梳理线上问题，给出质量数字
梳理平台链路了就可以给出比较专业的测试建议，但若想进一步了解平台的质量状况还少了些数字分析，而基于梳理出的链路分析线上问题就能给出质量数字。下表从两个维度“线上问题数和故障影响面”给出质量数字。可以看出，标准问题不仅线上问题多而且故障影响面非常严重，有关标准问题的需求一定要重点参与，反观情绪识别的质量情况就比较正常，如果测试时间不充足，有关情绪识别的需求可以有选择地参与。
一般要先梳理平台链路，再基于梳理出的链路分析线上问题，因为“粒度更细”问题定位才能定位的更精准，才能更好的评估需求的质量状况。比如下表是我的客服（粗粒度）的质量数字，若两个需求分别是“更新了我的客服问题识别模型”和“更新了我的客服情绪识别模型”，不难看出，这两个需求都属于我的客服，根据下表很难对两个需求进行取舍。
