app 开发说是后端返回数据的问题,让测试找后端推进。
如果要提一个问题,这个问题该提给谁?
1
liut2016 2020-04-02 10:08:54 +08:00
谁的锅提给谁
|
2
Vegetable 2020-04-02 10:09:33 +08:00
App 当然找前端,前端说接口问题,那就再测一遍接口呗.
|
3
HongJay 2020-04-02 10:09:52 +08:00
测试不会抓包先看看么。。数据问题就是数据提供者的问题
|
4
also24 2020-04-02 10:10:25 +08:00 via Android
提给 APP,如果 APP 认为是后端的问题,由 APP 转给后端。
|
5
also24 2020-04-02 10:11:04 +08:00 via Android
当然,测试也要尽量提高自身的姿势水平,尽量做到自己来判断问题的真正原因。
|
6
nvkou 2020-04-02 10:11:06 +08:00 via Android
根据接口文档来,和设计预期不符合的就后端,否则前端自己处理
|
7
a719114136 2020-04-02 10:11:47 +08:00 via Android
不能确定谁的问题就先找 app,如果你能拿到接口的返回,那就能直接定位是谁的问题,找对应的人
|
8
fancy111 2020-04-02 10:12:02 +08:00
这么简单的问题,还推。 抓包一看就知道
|
9
ISSSSSSS 2020-04-02 10:16:04 +08:00 2
如果只是功能测试,直接提给前端,由前端推进处理,测试只负责最终结果就行。
如果是白盒有一点开发能力的测试,那么建议做个抓包处理,对照接口文档和数据库。分析问题可能的原因,尽可能的跟踪数据流转过程,这样的话无论前端和测试都会信服你。 |
10
loveuqian 2020-04-02 10:18:13 +08:00
这个问题是我之前面测试也会问的问题。。。看 ta 会不会定位问题
|
11
wsseo OP 有时候测试不能定位这个问题,就很难办
|
12
sadfQED2 2020-04-02 10:29:38 +08:00 via Android
|
13
wangkun025 2020-04-02 10:32:14 +08:00
我选择离职。
|
14
payatpump 2020-04-02 10:36:57 +08:00 3
假如是在面试:当然自己通过自己的尝试定位问题,减少开发的复现成本,提升公司效率
假如是现实: 找 APP 开发,我才不管你是不是数据问题,现在我测前面测的不对,你就得给我修。 |
15
wsseo OP @sadfQED2 这里的“抓包“”是指什么?数据交互式加密的,数据本身也是加密的,只能靠前端打印日志。web 测试可以依靠 F12.
|
16
cece0417 2020-04-02 10:42:06 +08:00
我都是,先看到底是谁的问题,然后去找对应的人
我都是先抓包,看接口有没有错,有错的话看日志,看看是 php 的错还是底层的错,然后转对应的人 当然也存在我看不明白的东西,我就先给客户端描述一下,让客户端的开发看一下是谁的 bug,然后转对应的人 |
17
sfz97308 2020-04-02 10:46:29 +08:00 4
这就是前端的无奈。开发时依赖最多,往往最后一个才能完成。出问题第一个接锅,不管到底问题出在哪。
回到原问题,测试人员有能力就找到根源,没能力就找前端协助排查呗... |
18
kooze 2020-04-02 10:54:56 +08:00 2
初级测试只关注自己看到的,大概率会找前端,高级测试有定位问题的能力。
|
19
randyo 2020-04-02 10:59:14 +08:00 via Android
测试要学会自己定位问题,不然前端都成了接口测试员了
|
20
zisway 2020-04-02 12:57:29 +08:00 via Android
客户端说接口有问题,那就抓接口看返回数据对不对,不对就找后端排查
|
21
Bijiabo 2020-04-02 13:00:36 +08:00
就算是前端甩锅,也需要告诉你定位到的原因,为什么是后端问题
|
22
Chenamy2017 2020-04-02 13:05:07 +08:00
这么说吧,谁让你测的功能就提给谁,至于功能内部的实现接口让他们自己去协调。如果后端给你提了个测试任务,让你测后端的接口,那么这就可以提给后端了。
作为测试你不可能像开发一样去定位到问题到底出在那个模块,是前端的还是后端的。 当然测试也要提高自己做到问题定位能尽量准确。 |
23
Aixtuz 2020-04-02 14:10:49 +08:00
最遗憾的一点就是:
开发为避免所有 bug 堆积在一处效率低,也为了避免反复被打断工作,努力提供便于判断问题的日志之类。 希望在集中到某个判断点之前,有一个简单的初筛分流过程,类似招聘中的 HR ~ 但是遇到只测”是否正常“,不想管“哪里异常、如何复现、根据现有表现和提示能不能初步判断归属之类问题”的测试,就会觉得心累了。如果测试在问题堆积的时候,不管你的节奏,反复打断让你立刻查原因,催你怎么还没改好,那可就不止是心累了... 始终觉得把 “初步判断” 和 “详细核查” 分摊到不同人身上,会比较高效吧? |
24
learnshare 2020-04-02 14:14:41 +08:00
第一负责人肯定是 App 端,定位问题并记录详情,再转交给后端处理
测试为何要帮程序员定位 API 数据问题? |
25
cpsony 2020-04-02 14:32:06 +08:00
先抓包看能不能看出来是谁的错误,如果看不出来,就建个涉及这个的前后端的小群,丢群里,看大家表演甩锅的正确姿势,必要时候把产品也拉进来
|
26
lneoi 2020-04-02 15:00:09 +08:00
前端如果是确认后说是后端问题,那当然把问题指给后端,看他这意思只是不想追踪跟进
|
27
cece0417 2020-04-02 15:39:20 +08:00
@learnshare 测试前期要做接口测试呀,除非是个初级的点点点功能测试吧。
|
28
stardust21 2020-04-02 17:01:08 +08:00
@learnshare 举个例子,如果产品需求是标题下发的,标题错了还去找前端或者 APP 么,了解需求和大致工作原理,不是可以一步到位去找后端或者运营么
|
29
strongcoder 2020-04-02 17:06:48 +08:00
看到上面这么多的发言 我总算知道我司的测试为啥这样了 原来测试都一个样子啊 被我们天天骂 哈哈哈
|
30
myEzekiel 2020-04-02 17:09:48 +08:00
很明确啊,接口问题找后端,页面问题找前端
|
31
learnshare 2020-04-02 17:18:46 +08:00
|
32
JerryCha 2020-04-02 17:18:54 +08:00
找代码写错的哪个人
|
33
souths 2020-04-02 18:28:12 +08:00
你测的是 APP 你说找谁
|
34
Thiece 2020-04-02 18:58:30 +08:00
找小组负责人
|
35
a62527776a 2020-04-02 20:18:15 +08:00
不抓包天天来找客户端?
|
36
MissThee 2020-04-02 21:50:09 +08:00 via iPhone
看交互数据呗。app 给后端的数据有问题,找 app,没问题找后端。后端给 app 的数据有问题,找后端,没问题找 app
|
37
dioxide 2020-04-02 22:48:23 +08:00
1. 按接口文档来, 这里就体现了文档在团队内部的契约作用.
2. 如果本次无法按照文档界清责任, 那就各摊派 50%. 但重点是要借此机会完善文档以杜绝下次类似问题. |
38
lonelymarried 2020-04-02 22:52:15 +08:00
当然都是找 app 端了,因为要背锅。app 要是反映后端出问题,就得罪了后端老大了。所以,即使发现了问题,也要私下找后端解决。
|
39
xcstream 2020-04-02 22:58:50 +08:00
找产品经理 项目经理
|
40
douxc 2020-04-03 09:25:51 +08:00
看了这么多回复,你找谁都不好使,自己修了吧,谁让你发现的 /doge
|