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