1.要提高質(zhì)量的bug：
——》多次重現(xiàn)之后，確定為bug
——》用專業(yè)的屬于描述bug
——》標(biāo)題簡潔清晰，概括準(zhǔn)確（因為bug不只是在卡法在看，主管和做bug統(tǒng)計時都要關(guān)注，所以標(biāo)題很重要。例如：在XX情景下，發(fā)生了OO狀況，注意場景描述與操作步驟描述的區(qū)別）
2. 如何判斷bug是不是小bug？
——》從“用戶體驗”上看對用戶的影響，來判斷是否為小bug。在提交bug時，應(yīng)在bug描述中寫明“影響”
3.提交bug中的附件
——》1.測試數(shù)據(jù)（excel,sql語句）
——》2.如果是自己上傳的圖片，要注意文件的命名規(guī)范 ： 圖序列/含義
——》3.日志信息：截取關(guān)鍵部分
4.bug的嚴(yán)重程度和優(yōu)先級如何判定？
——》嚴(yán)重程度是從 “用戶角度”來說的。
——》優(yōu)先級是從“
測試人員角度”來說的。 優(yōu)先級高的bug可能并不嚴(yán)重，但是阻礙了測試人員接下來的測試，則提高優(yōu)先級，讓開發(fā)先fixed掉這些bug
5.bug的深度如何判斷？bug深度有什么作用？
——》bug深度 是為了解決某些開發(fā)人員代碼質(zhì)量差的問題。每隔一段時間統(tǒng)計一下“很容易發(fā)現(xiàn)” 的bug數(shù)量，可以看出一個開發(fā)人員在這段時間的代碼質(zhì)量和
工作狀態(tài)，便于管理人員協(xié)助調(diào)整。“很容易發(fā)現(xiàn)”的bug多為功能邏輯上的問題，是一般的開發(fā)人員不會犯的菜鳥級問題。而對于建議性bug來說，一般都判定為“很難發(fā)現(xiàn)”，因為此類bug含有測試人員的主觀因素在。
6.如何通過分析bug了解項目質(zhì)量：
1。根據(jù)活動bug趨勢圖 。（活動bug：沒有進入最終狀態(tài)之前的bug都是活動bug）
2.每日新增bug趨勢圖
3.開發(fā)未關(guān)閉的bug個數(shù)
7.開發(fā)fixed掉一個bug，但是在修改過程中引入了另外的bug，這種情況下是應(yīng)該重新提bug還是在原來bug上reopen?
——》重新提bug， 要保證bug的單一性。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters