问答 有个问题需要和各位探讨,应对如今的前后端分离,测试这边如果想分开前端、后端的测试团队,如何实施?或者说,完全分开质量、效率会提高吗?

李家晴 · June 12, 2019 · Last by 飘摇.py replied at June 29, 2019 · 2391 hits

背景:
1、后端服务会支持多个前端应用(Androd、web、mobile)
2、apk存在多个版本,若不分离,可能每次后端发版都需要验证N个版本的前端

想法:
使用前后端测试完全分离的测试策略。
1、后端仅做接口及其他后端逻辑验证,保证各业务场景的接口返回与协议的一致;使用接口自动化测试保证低级版本没有受到影响;
2、前端仅做界面上的测试;根据接口协议使用mock调试/改包的策略,验证各场景的输出对界面显示的影响;保证操作时,接口的传参正确

共收到 16 条回复 时间 点赞

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

Author only

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

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

目前面临的问题是,后端测完接口,前端进行End to End的测试,由于中台和业务前端组织结构分离,导致前端测试时后端的配合度不够,沟通成本很大,再加上前端测试人员对后端的业务逻辑不了解,所以从某一个层面来说,效率反而更低。

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

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

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

李家晴 回复

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

槽神 回复

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

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

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

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

李家晴 #14 · June 12, 2019 作者
黑山老妖 回复

嗯嗯,谢谢分享;
你的意思是指:类似于中台服务的(如:支付),可以后端独立进行测试;而其余的业务功能,不建议分离吗?

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

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

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up