大家好,我又來了,今天和大家聊一聊如何定位缺陷與報告缺陷.
高質量Bug Report的10條屬性
1 Structure組織：
測試人員應該采用深思熟慮的，小心謹慎的方法執行測試，并且做詳盡的記錄。這樣可以促使他們對測試下的系統有很好的認識。當錯誤發生的時候，一個有組織的測試人員能夠知道最早出現問題在哪。
2 Reproduce重現：
測試人員在編寫bug report之前必須在檢查問題是否可重現。如果錯誤不可再重現，仍然應該寫下來，但是必須說明問題的偶然性。一個好的處理原則就是在編寫bug report之前反復嘗試3次。
3 Isolate隔離：
在嘗試編寫bug report之前，必須試著隔離錯誤。可以采用改變一些變量的方法，如系統的配置，它可能可以改變錯誤的癥狀。這些信息可以為開發人員著手調試提供思路。
4 Generalize歸納：
在測試人員發現了一個已隔離的，可重現的問題后，應該對問題進行歸納。同一個問題是否出現在其他的模塊或其他的地方？同一個故障是否有更加嚴重的問題？
5 Compare對比：
如果測試人員以前曾經驗證過現在出錯的測試用例，那么他就應該檢查以前的測試結果以檢查相同的條件是否通過以前的測試。如果是的話，那么這個問題就象是一個回歸的錯誤。注意由于同一測試條件有可能出現在多個測試用例中，這個步驟就不僅僅只是檢查一個測試用例在以前的多個結果。
6 Summarize總結：
在bug report的第一行寫上錯誤的總結是非常關鍵的。測試人員要花些時間思考已發現的錯誤對客戶有何影響。這不僅僅要求測試人員編寫的報告要能夠吸引讀者，使和管理層的溝通清晰，還要能夠幫助設置錯誤修復的優先級別。
7 Condense精簡：
在bug report的初稿完成后，測試人員應該反復閱讀它，集中剔除那些沒有關系的步驟或詞語。隱含的或模糊的說明和那些由于對沒有任何關系的細節或者那些在重現錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標。
8 Disambiguate消除歧義：
測試人員在精簡空話的同時或其之后隨即應該再仔細檢查報告是否有會產生誤解的地方。測試人員應該盡量避免使用模糊的，會產生歧義的和主觀的詞語。目標是使用能夠表述事實，清楚的，不會產生爭執的詞語。
9 Neutralize中立：
如文中所述，作為壞消息的傳遞人，和善地提交消息是一個挑戰。如同所有的錯誤總結一樣，獨立的bug report在措辭方面應該保持公正。攻擊開發人員，指責潛在的錯誤，企圖詼諧或使用挖苦將引起開發人員的憎惡，并且使注意力從“提高產品質量”這個大的目標上轉移開了。謹慎的測試人員只用Bug report來描述事實。
10 Review檢查：
一旦測試人員感覺bug report是他能夠編寫的最好版本，他應該將報告再給一個或多個同行進行檢查。他的同事們也應該給出一些建議，為了澄清問題不斷地提問，如果適當的話，甚至可以挑戰“錯誤成災”的結論。在允許的時間里，測試小組應該盡可能提交最好的bug report。
缺陷報告與缺陷定位的一般框架
其實本圖,是一種系統測試,也就是偏后期的測試情景下來發散出來的.這種偏后期的測試情景也是大多數公司所面臨的測試過程階段.
該圖基本是按照
目前流行的B/S 和C/S 三層結構,來逐漸排查定位的.
目前無論是互聯網應用還是web網站,還是各類APP 都無外乎要么是B/S 要么是C/S.
B/S 和C/S共有的,三層結構就是 :
1 前端 Broswer&Clinet (包含傳統的web 和 各種PC客戶端 和各種安卓 蘋果APP) ;
2 服務端Server(傳統的web服務 如面向業務處理的 tomcat 等 )
3 數據庫DB (各種數據庫 Oracle Mysql等)
那么后期的系統業務測試階段,其實排查缺陷和定位缺陷,主要就是往以上三層上來推理,最終斷定是哪一層結構的問題,那么這就涉及到缺陷類型了,那么常見的缺陷類型如上圖有,
我們按照它出自的不同層可以這么劃分:
1 前端 Broswer&Clinet問題: 頁面腳本數據計算 頁面腳本數據校驗攔截過濾 頁面數據顯示 圖形樣式 瀏覽器參數配置 前端處理性能 前端安全問題
2 服務端Server問題: 服務接口 接口數據計算 接口數據校驗攔截過濾 服務參數配置 服務處理性能 服務安全問題
3 數據庫DB問題: 落地數據錯誤
業務功能 業務流程 需求歧義 建議意見 這四個比較寬泛,就是這4個其實屬于偏業務層面的問題,非技術實現層面的問題.缺陷分類從大的角度面向開發測試生產流程來看,其實就是
業務問題和技術實現問題兩大類.
那么實際各層面向的開發角色是不同的,面向各層使用的開發技術棧也是不一樣的.如在該篇 功能性測試用例設計方法深入理解 以人為綱小節提到的,有前端開發 服務接口開發 和 DBA數據庫開發. 那么面向不同的層的開發實現技術,我們遇到大致猜到是該層的問題了就需要用到相應技術棧的調試或分析工具來進一步定位問題.
能盡量定位到代碼級別的對開發是最有益處的.
另外就是要注意上圖中,"實際結果"的描述, 這個實際結果,一定要將 三層的問題 ,比如 前端的firebug 接口請求響應截圖 , console控制臺js調試信息, 或其他前端瀏覽器或app前端相關等, 服務tomcat業務處理日志,你的數據庫查詢SQL和查詢所得內容 一并盡量齊全的寫進實際結果. 你缺少任何一層的信息,都將影響到BUG的修復速度. 這樣具體的Bug Report 只要你缺陷類型判斷準確,準確投遞給相應開發,那基本沒跑了,我們做測試的就像警察和法官 , 警察講究證據 (實際結果),法官判案也要講(實際結果),這樣開發就沒跑拉,也避免了前端開發和服務接口開發互相扯皮推諉.
再說一個,大家看上圖"缺陷分析定位",實際按上下順序是排了序了,為什么要先查數據庫呢? 這里邊其實提到的體現了排查定位缺陷的效率問題, 也體現了一種排查問題的思路,殺豬焉用宰牛刀, "夾板思路" 先夾大黑盒,再夾小黑盒,逐漸縮小問題發生范圍, 也就是三層 前端 服務 數據來夾. 就是大夾板是最大的黑盒 也就是 只管前端 和 數據庫落地 的輸入和輸出,如果這個大夾板沒問題,輸入也對,落地數據也對,那就基本說明,整個處理鏈路是通的.
大早上,先碼這么多,希望幫助到大家.如果您覺的有道理,就給個贊,收藏一下,關注下專欄.
上文首發于TesterHome.
TesterHome 為用戶提供「保留所有權利，禁止轉載」的選項。 除非獲得原作者的單獨授權，任何第三方不得轉載標注了「原創聲明：保留所有權利，禁止轉載」的內容，否則均視為侵權。 具體請參見TesterHome 知識產權保護協議。
