當一名測試員遇到線上事故怎麼辦？2步學會快速定位

作為一名合格的測試，我們不僅要具備縝密、仔細的測試能力，在定位分析問題的方面，尤其是一些線上問題，也應該能做到得心應手。那一些線上事故我們該如何去定位呢？ 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

首先，一般線上事故都會提一個事件單，由公司業務或者運營指定給對應的負責人。我們要看清楚是什麼場景下的什麼操作導致的，事件的嚴重等級及影響範圍。

另外，遇到事件也不用慌，畢竟還沒搞清楚是業務的問題還是程式碼的問題。

比如，最近運營提出一個問題“產品xxx關聯的配置xx沒有在前端展示，請排查原因，相關訂單號xxxx”。

首先，我們可以根據訂單號在訂單後臺中，檢視到當時的下單時，付款的金額是否包含所得資源。

最主要的就是分析問題的產生原因。

首先，去日誌記錄平臺查詢當時的請求記錄。檢視當時日誌中返回的資料是什麼，確定是不是因為使用者的配置原因導致的資料被過濾掉了。

其次，我們可以抓取當時的報文，進行二次請求，檢視是否能否重現。來判斷是偶現還是必現的問題。

最後，我們可以在測試環境配置相同的資料，進行測試請求。通過debug來定位最終問題。

接著上一個例子，我們可以通過訂單號，在日誌中去查詢當時的請求報文，檢視日誌過濾資源的原因，確定是否存在業務配置錯誤的問題，一般我們都是通過當時的報文請求，來模擬使用者的操作。

總結與成長

一般問題確認之後，如果是使用者配置問題，我們要和使用者溝通如何去修改配置，如果確實是漏洞問題，我們首先要抓緊時間去修復問題及確定影響返回，是否需要回退版本等。

等問題修復完成之後，總結和分析才是最重要的一步。

一般嚴重等級比較高的，我們會寫事件分析的報告，確定是什麼原因造成的，如何才能防止下次的迭代中不出現這個問題。

比如，每次上線前我們都會去觀察日誌，但由於日誌記錄的東西太多，沒有觀察到一個偶現的空指標，那麼我就會在每次看日誌的時候會拉長日誌搜尋時間並且仔細觀察每個報錯資訊，確定是不是這個發版造成的。

又比如，由於開發新增欄位的時候沒有做判斷欄位為空處理，在新老版本切換的時候，導致新程式碼請求了舊資料出現空指標異常，那麼我會在後面的測試過程中，優先考慮多版本切換的問題。

遇到線上事故確實是挺慌張的，生怕是不是自己漏測了哪個點，其實不用慌，很有可能是開發或者使用者的原因。

但是我們要記住：定位分析問題原因，並從中得到總結，在後面的測試工作中得到成長和提高，才是最重要的！

最後：

可以我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的視訊學習教程免費分享！，其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。