1：充分理解需求規則、原型圖，知道預期結果，操作時判斷是否為bug
解析：預期結果不等於實際結果的時候為：bug

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

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

2：提交bug之前排查是否人為引起
解析：這裡有可能會問你一個其他的面試題；例如：如果前端報錯404，你是如何排查這個問題的？

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

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

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

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

4：定位問題，精準描述問題產生的原因和分配相關開發人員
解析：定位問題是軟體測試當中的一個難點，這個問題是屬於誰的？前端、後端、資料庫？介面？後臺程式？還是第三方平臺？所以在這裡也要強調一點的是，身為一個測試工程師不僅是點點點，你如果僅認識這一點的話，不好意思，你還沒入門