举个例子，比如我一个业务逻辑，链路是A->B-C-D，ABCD里面各有一堆逻辑要测试，时间紧急的情况下怎么测比较高效。
我的思路：
方案1，分批测试，把A逻辑测好，再测B，因为如果A不对B就无法进行，所以先测A，而且开发也可以更快更准的去定位到问题原因，但是可能会出现的问题就是，你测试了很久，结果因为Bug比较多，整个链路都不通，领导觉得你几天啥也没干，这么严重问题都没发现。
方案2，可以随便拿个数据试验一下整个链路通不通，不通就提阻塞性Bug给开发，让他改，但是我觉得这样的话，开发排查起来比较困难，因为链路长，不太好发现问题在哪里，耗时比较久。而且我感觉这样测会打乱我的测试节奏。
就这个问题困扰我很久了，没有更好的解决方案，想问问做过开发或者测试的人，你们怎么想的，你的看法是什么，给我建议，感谢
如有帮助，请采纳，十分感谢！
既然链路这么长，比如直接有接口，明确了接口定义和相互交换信息的规则，其实每个步骤都应该能单独测试，这也就是业务链路上一种解耦处理。
这种情况下是比较理想的，
因为测试可以单独进行，对每个ABCD中任何一个来说，都可以完整测试（从其入口到出口），因为接口部分是可以模拟输入、输出来测试的。
这时，单独模块开发也更细粒化（规模小了更好排查问题）。
最好联调也可以分段进行，任何衔接两个都分别完成了独立的测试，都可以进行局部联调。
而且因为各自都已经完成独立测试，联调出问题的概率也越低。
先粗走一遍看看通不通，不通的话看看哪一步不通，提阻塞性Bug给开发，通了再对各个步骤进行详细测试
其实你可以换个角色来考虑这个问题，把自己当做项目的负责人，考虑下哪种测试方式最能保证项目进度可控，延期的风险最小？
我以为可以先按照业务正常逻辑测整体，保证在正常逻辑下整体功能通的情况下，再逐步细的测试，各种异常情况的测试，如果整体测试出现问题则请开发及时改，测试在整体功能无法测试的情况下可以测单体的功能，这样开发和测试都不会空闲着。
至于测试问题的定位则完全不用担心，对于开发来说链路的长短不太会影响的。而领导其实也更关心项目的实际进度，整个功能可控度有没有提升。
这就是个整体和局部先后的问题，你要结合你自己的特点，如果项目很大，建议先局部后整体，如果比较小的话可以链路一起测