好多测试团队都是前后端分离的。但是这个怎么个分离，是否是前端只需要关注页面，不关注接口？我觉得前后端分离，指的是业务逻辑复杂的，公用的后端业务独立出来，比如支付类似的。

嗯嗯，谢谢分享；
你的意思是指：类似于中台服务的（如：支付），可以后端独立进行测试；而其余的业务功能，不建议分离吗？

对的，我们公司就是这样，中台系统建议分离出来，业务逻辑多，复杂度高，其他的简单的接口没有必要分离

我猜可以，不过你要多招一倍的人，多给至少一半的时间周期，在前端测试、后端测试都做完了之后再来一遍大集成或者大回归的测试
大集成或者大回归的测试发现的 BUG 依旧会占到 50%+

我们现在是服务端接口开发好，后端测试先介入接口测试。再交给前端测试同学，等他们在页面上测试的时候也相当于回归了一遍流程。我现在测试的话基本上就按照接口文档的输出格式来，保证服务端逻辑的同时再确保给前端返回的内容和接口文档一致，至于数据怎么展示和使用就不去关心了。

我司是前后端分离，服务端比前端人多，但是前端测试任然发现很多服务端的 bug，我有一次问，得到的答复是，服务端没办法覆盖这么多场景

恩，我和 3 楼说的一个意思。后端测试的优势，就是能把复杂的业务逻辑理清楚，各种情况测一遍。那种简单的业务，后端测试和前端测试没区别啊，毕竟前端测试时就是去请求接口，工作都重复了。还不如全给前端测试

跟着产品团队走，面向交付，不要面向技术解耦。测试关心的应该是一个完整的特性，包括前后端。
当然如果你的测试标的就是前端或者后端的交付是另一说

跟着产品项目走，如果一个团队里面 分专门测接口，专门有人测页面，到时候会造成测页面 简单重复的事情没人愿意干了，很难管理

必然是都干啊，不然岂不越走路越窄，把自己玩死了么

我们都要求能达到一种 QA 的层面，所以基本属于都做，分开的话，会容易造成业务逻辑不熟悉，导致测试方式方法都不正确。会走一些弯路~

这个必须有完善的接口定义，确保后端接口测试完成后，前端介入的成本低，并且只要集成的业务验证。

如果需要分层，那需要大家都在理解这个业务场景的情况下进行分工或者分层，否则后端只管逻辑对不对不管上层能不能用，前端只管关注可见的功能不管边界的场景，会出现很多测试漏洞的。日常的发布改了后端，前端要不要跟着回归也是一个很蛋疼的事情，出了事容易扯皮

主要是现在大多数公司，前后端分离测试，都是喊喊口号。
项目进行中却是存在前后端进度不一致的情况，这个时候前后端可以分开介入，也可能会一定程度缩短项目周期。
但有一个前提：前后端必须按照之前约定的接口进行 coding，如有改动，前后端就要重新测试。
还有就是即便前后端分开测了，都提交后还是要都测一遍，何苦来哉

我觉得前后端分离测试，应该指的是后端开发和测试先行，后端交付之后，前端根据后端的稳定版本，进行开发和测试。前端测试可以使用 mock，来模拟各种异常场景，也可以直接对接后端稳定版本来进行测试。
如果前端仅根据接口协议使用 mock 调试/改包的策略，做界面上的测试，确实会存在几个问题。1。后端最终交付接口实现和约定不一致。2.前端入参传错了，访问 mock 正常，但访问实际服务是不正常的。3.因为使用假数据，一些交互问题引起后端的异常可能忽略掉了。
（前后端联调测试确实是很重要的环节）