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