标签：描述 研发 数据库 第一时间 银行 排查 截图 工程 报错
从实际工作中整理，如下；如有补充可以讨论！所以会发现现在的面试题大部分问的都是工作中出现的场景了，而不是单纯的背诵
1：充分理解需求规则、原型图，知道预期结果，操作时判断是否为bug
解析：预期结果不等于实际结果的时候为：bug
因此理解原型图、需求、设计文档、数据库流程，是为了更好的判断、知晓预期结果是什么，这样你才能在发现问题后确定是否是bug。
这就类似咱们考试的时候，老师要判卷子，得先要知道标准答案，才能发现你的对错，所以预期结果准确得知，是测试工程师第一道难关，特别是银行行业、后台程序逻辑、计算结果，系统复杂，需要多学习业务
2：提交bug之前排查是否人为引起
解析：这里有可能会问你一个其他的面试题；例如：如果前端报错404，你是如何排查这个问题的？
这个问题在上课的第一节课的时候反复说了一句话：发现的问题不一定是bug。
这一点在公司要格外注意，因为有的问题可能是你人为造成的，这样的问题你就不能提交至禅道（jira）了，否则很容易出现矛盾。所以发现问题后，不是第一时间的提交，而是再三确认是否是软件本身的bug后再提交
PS：最后一句话也可能会加个面试题：如果你和研发有矛盾的话你是怎么解决的？
3：详细的操作步骤加截图，让开发人员能按照步骤重现bug
解析：操作步骤在讲课的时候说过，步骤的书写没有标准的答案，你可以一句话描述、也可以分步骤去描述，但是要遵守一个原则就是：无论你怎么去描述，最终是让研发看的，所以要让他们明白你描述的是什么意思，其次要让研发能按照你的步骤描述把这个bug复现出来，好让他们定位并修改这个问题
4：定位问题，精准描述问题产生的原因和分配相关开发人员
解析：定位问题是软件测试当中的一个难点，这个问题是属于谁的？前端、后端、数据库？接口？后台程序？还是第三方平台？所以在这里也要强调一点的是，身为一个测试工程师不仅是点点点，你如果仅认识这一点的话，不好意思，你还没入门
标签：描述 研发 数据库 第一时间 银行 排查 截图 工程 报错
原文地址：https://blog.51cto.com/dotest/2374404
