前言
复杂的需求通常需要多个团队配合开发，那么问题来了，多个测试团队如何划分测试边界？哪个测试团队负责总体牵头比较合适呢？牵头的团队又要干些什么额外的工作呢？
谁的代码谁测试
- 要设计出好而全的测试用例，了解技术实现是必须的。
- 别人团队的代码你看不到，用例设计这块你很难想周全。
- 别人的周边/历史逻辑你不熟悉，很容易踩坑、漏测。
- 别人的业务链路、测试工具，测试数据，你不熟悉，都要现学效率太低。
- 如果上边都讲了，还是一定要你来测，那就是准备让你背锅了。你要注意，不要把对方的那堆事儿想简单了。
- 接之前，都告诉你很简单的事儿，接了以后全是坑。因为没有哪个团队是简单的，否则这个团队不需要存在了，别人顺手就做了。
谁离用户近谁牵头
- 怎么判断远近？出了线上问题第一个通知谁，谁离用户就最近
- 第一个通知你，你就得熟悉整条路，至少你得知道下一步拉群该拉谁
- 客户端/前端测试比服务端测试离用户近
- 业务测试比功能组件测试离用户近
- 功能组件测试比基础框架测试离用户近
牵头都干嘛
- 设计验收用例，别人的代码不用你测，但是你得验收。别到他那，断了或者体验特别差，你都不知道。
- 熟悉人头，别人的代码不用你测，但是整条路出了问题，你要能判断出来大概问题出在哪个节点，这个节点的测试是谁，排查问题时候拉群先把测试拉进来，别人的开发你是推不动的。
- 带节奏，大项目通常有项目经理带不用你带，但是由于你离用户最近，其他测试的进度延期，也会导致你的用例被阻塞，所以最好提前盘出来和项目经理说（尤其是非业务团队的事儿比较杂，不一定有业务团队的时间感那么强）。
如何划分测试边界