淺談如何作好Bug迴歸驗證？

做爲測試人員，咱們都知道Bug的生命週期是：

 

　　咱們都但願本身不只有敏銳的洞察力可以全面的找出隱藏在軟件中的bug，還但願本身有系統的分析能力可以準確的分析出每一個bug的緣由以致於能正確、全面的解決修復bug。這也是一個優秀的測試工程師應該具有的基本能力。那麼對於迴歸驗證bug這個環節就是對前面兩項工做是否合格的體現及驗證。bug迴歸到不到位, 關係到發現bug自己有沒有修復正確, ?一樣也關係到bug修復過程當中可能引發新的bug。接下來咱們就講講如何作好bug的迴歸驗證：

　　1、確認好bug的復現前說起操做步驟。

　　通常狀況下對於必現bug，咱們在提交bug的時候會寫上必現前說起操做步驟。對於本人提的bug及操做步驟描述清楚的狀況下，迴歸時復現操做出現誤差的可能性不大。可是遇到要回歸別人的bug且描述不夠清楚或理解可能存在歧義的時候，咱們必定要先跟發現bug的同事確認清楚bug的復現方法。不然極可能就出現了bug驗證步驟的誤差，從而沒法確保bug是否真正修復。這裏咱們先要在源頭解決這個事，因此在提bug時就必定描述清楚，下面給出一個咱們平時寫的比較詳細的bug作爲參考：

　　【版本V1.1.0】【ANDROID】【銀行卡】【功能問題】綁定銀行卡時提示通聯驗證碼驗證失敗，或驗證碼發送失敗，或網絡超時【復現率80%】

　　【測試機型】HTC M10U/6.0.1

　　【測試環境】MA

　　【測試版本】0929

　　【步長】1

　　【復現步驟】

　　一、登陸花生理財

　　二、銀行卡管理-添加銀行卡，輸入交易密碼，身份信息，選擇華夏銀行，輸入卡號爲623020xxxxxxxxx2及開戶城市信息

　　三、驗證手機頁面輸入手機 號點擊獲取驗證碼。輸入校驗碼點擊肯定 ，觀察頁面顯示

　　【預期結果】

　　點擊肯定後若是驗證碼正確提示綁上成功

　　【實際問題】

　　點擊確認後提示通聯驗證碼驗證失敗，或驗證碼發送失敗，或網絡超時

　　【備註】

　　詳情見附件圖

　　2、確認清楚bug產生的緣由及修復方法。

　　在本身不能準肯定位bug產生緣由的時候，必定找開發確認產生bug的具體緣由。是業務邏輯錯誤仍是代碼實現方法錯誤等等。這個不只有助於測試分析, 從bug產生的緣由能夠舉一反三。其餘的功能模塊是否是也可能存在這種問題,或者這種問題是否是典型易犯錯的類型,還能夠從bug中得出一些經驗積累, 對缺陷預防的工做有積極做用。在瞭解清楚bug產生的緣由後,進一步瞭解清楚開發是如何修復bug的。修復當前的bug每每很簡單,有些開發只是針對當前的問題現象進行修改而不是從問題產生緣由進行修復。還有可能修改的代碼會影響到其餘模塊。好比說，修改的是一些公共的函數或算法,這是一個"很是危險"的信號。頗有可能就會影響到其餘功能。

　　好比bug#43213：【版本V1.4.0】【RN】【電子簽名約定】小白用戶簽約時走綁卡未走完返回，再點擊贊成簽約肯定時會彈出密碼輸入框【必現】。

　　這個bug的緣由是：只在進入簽約頁面時判斷了綁卡與否，而RN界面沒法獲取從其它頁面返回的狀態，因此返回時沒法從新獲取。

　　解決辦法是：點擊保存時再次判斷用戶綁卡與否，如未綁卡再次提示。

　　這個bug自己的影響只有當前簽名業務頁面，但從bug出現的緣由看，是由於RN界面沒法獲取從其它頁面返回時的狀態，那咱們就能夠深刻考慮咱們有哪些業務是用的RN，而後業務中存在須要獲取返回狀態的業務又有哪些，而這些業務是否也存在這個問題呢？

　　3、確認bug的迴歸範圍及用例。

　　在瞭解清楚bug產生的緣由及修復方法基礎上，再根據業務關聯、功能模塊關聯確認迴歸範圍及用例，確保bug修復全面且沒有引發新的bug。這裏須要測試人員很是熟悉業務邏輯及功能模塊的關聯關係，可以準確全面的分析出每一個業務功能點所影響的範圍。好比說，bug緣由是某個函數或算法錯誤，那修改這個函數或算法後咱們就要回歸全部會用到這個函數或算法的業務及功能模塊。例如，購買理財時預計利息計算錯誤。

　　【測試機型】iPhone5s/8.3;oppoR7/4.4.4

　　【測試環境】測試環境

　　【測試版本】Android:20322,ios20847

　　【步長】2

　　【測試步驟】

　　1.登陸高門帳號後進入振惠存

　　2.在存入金額輸入頁輸入100

　　3.查看存入金額輸入框下方利息

　　【預期】利息的值=最高年化收益率*本金，即1.95

　　【實際】實際展現的值是9.75

　　迴歸這類問題時咱們要考慮哪些地方會涉及利息計算？如：理財計算器，利息預計算等。他們是否用的同一個公式?迴歸的時候就要覆蓋全部存在利息計算的場景。

　　4、非必現bug的迴歸驗證。

　　有些bug並非有必定的必現的操做，或者說咱們找不到比較好的必現步驟。對於這種非必現的bug，能夠視bug的重現機率而定。好比說一個操做，操做10次確定會出現一次，這種bug基本上能夠說是能夠重現。這種機率較高的,迴歸的時候，能夠經過屢次操做來完成。好比說，執行必現的操做30次以上，均未出現問題。這個時候基本能夠認爲bug修復啦。

　　還有一種當出現的機率較小並且很難掌握重現方法的時候，怎麼迴歸呢?首先這種可能開發也不能100%肯定是什麼緣由形成的，只不過發現了一些可疑的代碼。猜想是這些可疑代碼形成的，進行了修復提交給測試人員迴歸。這種狀況下，能夠跟開發確認代碼修改的影響範圍及邏輯後對代碼的改動部分進行部分的驗證。

　　bug的狀態能夠先不要關閉。能夠在後續的測試中持續關注。當這個bug在通過幾輪的測試後未出現過,那麼能夠認爲bug修復了。雖然這種不能100%保證bug的真正緣由修復,可是起碼能夠認爲就算有問題也是機率較小的。

　　還能夠就是根據bug的等級，肯定採用自動化的方式進行bug復現驗證。根據發現bug所在的模塊，生成自動化測試用例，進行自動化測試，經過重複觸發去復現bug。另外還能夠嘗試經過給出現bug的模塊功能所涉及的參數賦值爲非法值，看是否能復現bug。這裏也要再次提到咱們在測試的時候要養成隨時錄製log的習慣，這樣對於非發現bug來講及時錄製的日誌就是bug發生的證據也是開發解決bug的重要依據。

　　5、Bug迴歸規範化。

　　從開發解決修復完這個bug後就進入了bug迴歸過程當中。爲了確保測試人員可以且有全面準確的迴歸驗證bug是否真的被修復。咱們能夠制定一些規範來確保bug迴歸的效率及正確性。好比，開發在提測bug時附加上bug產生的緣由，修復方法，修復影響範圍，開發自測的用例，bug可驗證版本號等。測試在迴歸時備註好驗證的版本號，驗證結果，迴歸用例等，這樣若是bug修復不完整，這些信息都有助於開發及測試人員跟蹤bug。對於後續bug分析總結也提供了更有效的數據。