这是一个创建于 1690 天前的主题，其中的信息可能已经有所发展或是发生改变。
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
|
Select Language