最近公司发生好几次，前端开发在某个需求改了/优化了全局组件，导致某些不常用的页面出现问题。
例如：某个需求中改了购物车的价格显示，开发做需求时改了价格显示的全局组件，开发认为只是一个显示，在简单自测后就提测了，也没有说明价格显示是全局共用的。结果导致在一个不是常用的流程中（不在回归用例范围），价格显示错误了。
想问一下大家，作为测试如何低成本的避免/识别到这类型的问题呢？
占个楼，看有没有大佬知道
结果导致在一个非常用的流程中（不在回归用例范围）细品
最简单直接的方法就是提前要求前端把用到这个公共组件的地方全部告知。
- 研发：改了哪里就要说清楚这个是基本点，要求上是研发能从代码实现角度评估出影响范围（当然事实上经常做不到，一个研发不可能了解整个项目）。这种全局组件想改就改，要不就是研发自己没有质量意识，要不就是全局组件抽象得不好和业务有耦合需要经常变更，无论哪种问题都要要求研发改正（和研发 leader 聊清楚，理论上研发 leader 也不可能不管）
- 测试：在这个场景下，如果回归测试用例先前就已经和研发团队对齐过达成共识，那在所难免，但不是说测试就没有责任的。可以从几个方向去考虑：
- 一是能否引入工具量化回归测试的覆盖，比如回归测试时加上覆盖率，看看是否能在合理范围内覆盖变更代码，如果不是那回归测试用例是需要再优化的；
- 二是做好技术梳理（要研发配合做），比如全局组件对应哪些用例，以后有人改了全局组件就要测这些用例，这些用例中有哪些是研发拿去自测的（不是研发自己随便测一下就算合格的自测）……
- 三当然就是自动化，如果成本可以接受的话
比较简单的做法：
提测时，测试对研发代码 diff 进行 review，发现全局组件变更的话（一般会放在某个固定的目录下），要求/和研发一起梳理全局组件的使用范围，进而更准确地进行相关逻辑的回归，避免遗漏。
如果 diff 成本高，也可以做一个简单的脚本，自动判定全局组件相关目录在本次提测的变更中有没有变更记录，有的话发个通知告知测试，测试再针对性找研发沟通。
不过个人倾向于，去推动提高研发对于这部分全局组件修改的影响范围评估能力。正常修改全局组件前，是必须要评估影响范围，进而确认使用何种修改方式的。这应该是修改前的一个基本操作。而且有些关键组件，是必须要求由对项目足够熟悉的人进行评审确认的，避免关键组件变更失控，影响整体架构。
从楼主描述看，研发这块没有做到位，自己都没意识到要评估和做相关的自测，更别说告知测试了。
吃个教训吧，记住这个功能，下次遇到就都回归一遍。同时以后遇到类似可能其他地方也有的功能，找开发问清楚影响范围，是不是公用组件