所以會發現現在的面試題大部分問的都是工作中出現的場景了，而不是單純的背誦

1：充分理解需求規則、原型圖，知道預期結果，操作時判斷是否為bug

解析：預期結果不等於實際結果的時候為：bug

因此理解原型圖、需求、設計文檔、數據庫流程，是為了更好的判斷、知曉預期結果是什麽，這樣你才能在發現問題後確定是否是bug。

這就類似咱們考試的時候，老師要判卷子，得先要知道標準答案，才能發現你的對錯，所以預期結果準確得知，是測試工程師第一道難關，特別是銀行行業、後臺程序邏輯、計算結果，系統復雜，需要多學習業務

2：提交bug之前排查是否人為引起

解析：這裏有可能會問你一個其他的面試題；例如：如果前端報錯404，你是如何排查這個問題的？

這個問題在上課的第一節課的時候反復說了一句話：發現的問題不一定是bug。

這一點在公司要格外註意，因為有的問題可能是你人為造成的，這樣的問題你就不能提交至禪道（jira）了，否則很容易出現矛盾。所以發現問題後，不是第一時間的提交，而是再三確認是否是軟件本身的bug後再提交

PS：最後一句話也可能會加個面試題：如果你和研發有矛盾的話你是怎麽解決的？

3：詳細的操作步驟加截圖，讓開發人員能按照步驟重現bug

解析：操作步驟在講課的時候說過，步驟的書寫沒有標準的答案，你可以一句話描述、也可以分步驟去描述，但是要遵守一個原則就是：無論你怎麽去描述，最終是讓研發看的，所以要讓他們明白你描述的是什麽意思，其次要讓研發能按照你的步驟描述把這個bug復現出來，好讓他們定位並修改這個問題

4：定位問題，精準描述問題產生的原因和分配相關開發人員

解析：定位問題是軟件測試當中的一個難點，這個問題是屬於誰的？前端、後端、數據庫？接口？後臺程序？還是第三方平臺？所以在這裏也要強調一點的是，身為一個測試工程師不僅是點點點，你如果僅認識這一點的話，不好意思，你還沒入門

軟件測試面試-如何高質量提交缺陷bug？