业务平台为测试带来的挑战

“业务平台”是指 中间平台，其上游有底层系统支撑，其下游有客户群体。因为平台下游承接大量客户群体，客户对应用的行为极其敏感，一些小故障比如闪屏、按钮失灵，落数失败会有很大概率引起客诉。

客诉对公司整体的影响

从公司层面讲，客诉会带来非常恶劣的影响，下面列举四种情况：

客诉过多或者客诉影响很大，会影响企业在行业内部的声誉，间接会影响销售量。
客诉过多，直接的原因就是企业内部质量控制和生产运营系统问题及漏洞多，不解决直接影响生产经营。
客诉是客户直接的抱怨，直接影响该客户和企业的合作关系，轻微的只是抱怨，严重的可能会导致退货、索赔等。
客诉直接影响客户满意度，如果不改进，逐渐会被客户减少采购量，直到被踢出供应系统。

为避免客户投诉，公司会为员工制定严格的定责标准，定责标准会影响相关人员的工资绩效，从而约束相关人员的重视，所谓从根儿上治老毛病！

业务平台为测试带来的挑战

客诉对公司内的影响

为避免客户投诉，公司会为员工制定严格的定责标准，需要相关开发“1分钟发现故障，5分钟定位原因，10分钟恢复”，根据故障影响大小也会制定追责标准，诸如“500 客诉半年差绩效，1000客诉全年差绩效，2000客诉团队差绩效”。我前段时间负责一起 P级故障的复盘，复盘过程之严格另人头皮发麻，当故障影响到线上用户时，GOC部门要考查每一个时间点每个人在做的事情，下面列一下“复盘清单”：

10:30 A 同学开始发布变更。
10:34 触发线上预警。
10:35 B 同学响应预警，启动作战群。

随后，GOC 部门会根据故障影响层面、操作过程、止血时间对相关人员进行综合定责。从个人层面来讲，负责业务平台的开发、产品和运营每天都要紧拉着一根弦，时刻预防线上事故。

测试人员是否能“有效”减少线上事故？

很遗憾，测试人员不能“有效”减少故障的发生！即使研发人员不接新需求不启动迭代变更，测试人员不停做测试，线上事故还是会发生，它就像一位幽灵，下面是一些常见原因：

1、陈旧代码存在隐藏 BUG，测试人员不会对所有功能进行回归，这些BUG就是隐藏的炸弹。

2、测试环境与线上环境存在差异，测试环境没问题，但一上线就会出现故障。比如预发环境流量较少，不使用集群缓存，而线上环境流量较大，使用集群缓存。

3、上下游系统变更与本业务平台不兼容，测试人员一般只负责本平台，对于其它平台的变更很难考虑进去。

4、调用量突增导致接口调用超时，该问题在日常测试中没问题，是因为线下与线上流量存在差异。

既然说的这么在理，线上事故不能被有效预防，那么测试人员对于业务平台的价值是什么？

如果把项目分层次，越靠近业务端说明其职责偏向客户，越靠近技术端说明其职责偏向开发，则测试的位置如下图所示。测试比研发更懂业务，比如运营/产品更懂技术，处于技术和业务的中间平衡点。

业务平台为测试带来的挑战

处于中间平衡点的优势是能全面的看待问题。举个例子，前端想展示/存储某数据会向后端发送读数据的请求，后端再从DB读写数据。

业务平台为测试带来的挑战

为了加速访问，一般会在DB和服务器中间设有集群缓存，经常用到的数据会存储到集群缓存中，以加速前端展示。某次迭代突然发现前端数据展示异常，复盘整个测试流程，发现产品和运营在前端测试过数据展示，测试的时候没问题，一上线怎么就出了问题呢？

业务平台为测试带来的挑战

其问题是开发读写集群缓存的代码不一致，读出来的数据结构和写进去的数据结构不匹配。产品和运营在测试的时候，所执行的操作（展开、点击下一页）并不会触发缓存刷新，也就是说，集群缓存中的数据没有被刷新，缓存中仍然是旧数据，在前端可以正常展示。但发布到了线上，某天的操作（编辑，删除）触发了缓存刷新，向缓存中写入了新数据，由于写入数据的代码和读取数据的代码不一致，导致了前端显示异常。产品和运营同学由于对技术的不了解，在测试阶段只测试了“展开”并没有测试“编辑和删除”，而开发同学自测时，也没到前端进行操作，只查看了接口调用信息。

而一名测试人员，在需求评审阶段与产品充分沟通，在系分评审阶段与开发充分沟通，其测试用例也会综合产品视角和开发视角进行设计，会很容易发现上述问题。测试虽然不能“有效”减少故障的发生，但却可以在开发和产品/运营之间找到平衡点，这个平衡点是综合了业务视角和技术视角，能更全面地发现问题。明眼人可能看出来了：“真有这么简单？测试人员在需求评审阶段和系分阶段聊聊天就行了？”，不不不，这个过程可不仅仅是聊天哦，对于测试人员的各项能力都有要求，是一个不小的挑战。

测试人员带来的挑战

在研发流程中，测试主要参与的阶段有需求评审和系分评审，前者是产品主导后者是研发主导。测试人员既要参与到需求评审阶段，也要参与到系分评审阶段，下面就分别展开讲讲。

需求评审阶段

该阶段由产品主导，在此阶段，产品会讲述“新需求是什么和为什么要做”。测试需要参加需求评审，因为一方面要了解新需求以便设计测试用例；另一方面要把控迭代与需求的关联关系。看到这，应该有小伙伴的心里有个大大的问号“迭代和需求的关联关系为什么要测试参与？让研发和产品确定就好啦！”，小伙伴们忽略了一个情况：测试开发比严重失衡，公司的测试开发比大约是1:5，1名测试服务5名开发，测试资源严重不足，我举个例子方便大家理解，现在产品有十个需求，哪些需求要上本次迭代哪些需求不上本次迭代是谁说了算？

1、产品说了算：产品希望本次迭代 10 个需求全上，需求量太大了，测试人员就算天天加班也很难对这么多需求进行测试。

2、开发说了算：若开发人力不足，会将需求分散到多个迭代中，10 个需求恨不得拉5个迭代，测试人员看到如此多的迭代，真是头皮发麻：本次迭代上哪些需求，要测什么？下次迭代上哪些需求？下下次迭代又上哪些需求？

所以迭代和需求的关联关系既不能让开发说了算，也不能让产品说了算，测试要参与迭代与需求的关联关系的讨论，由于测试人员对新需求的了解程度远不如产品和开发，在讨论过程中难免要占下风，如果想掌握掌握话语权，就势必要对需求的重要性、优先级、可测性进行充分理解，并且能够根据有限的测试资源给出合理排期，在此过程中会激发人的项目管理能力和需求理解能力。

系分评审阶段

该阶段由研发主导，主要讲解做了什么需求和哪些没做。测试在此阶段介入，一方面可以从研发角度了解哪些功能重要（涉及全链路，涉及数据读写）哪些功能不重要，从而完善设计测试用例；另一方面要把控提测时间和上线时间。对于测试来说，提测时间和上线时间尤为重要，这决定着有多少时间能留给测试发挥，测试要保障研发能预留充足的测试时间。很多新项目团队，其系分评审可能根本不涉及提测时间，什么时候可以提测完全随缘，最终项目上线压力全部留给测试，若项目再复杂些，在有限的时间内测试很难保障项目质量，出了线上事故研发又反过来质问测试：“为什么A没测？为什么B没测？”。

所以测试在系分评审中不仅要了解重点技术，还要对提测时间和上线时间进行严控把控，在此过程中会激发人的技术理解能力和项目管理能力

小结

“业务平台”是指中间平台，其上游有底层系统支撑，其下游有客户群体。其重要性不言而喻，测试人员可以在开发和产品/运营之间找到平衡点，这个平衡点是综合了业务视角和技术视角，能更全面地发现问题；业务平台给测试同学带来了前所未有的挑战，包括如何把控研发流程，在需求评审和系分评审中如何掌握迭代与需求关联关系。