这是一个创建于 2020 天前的主题，其中的信息可能已经有所发展或是发生改变。
app 开发说是后端返回数据的问题，让测试找后端推进。
如果要提一个问题，这个问题该提给谁？
 | 1 showmethetalk 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