3 . 填表注意:
FIXED 描述的問題已經(jīng)修改
INVALID 描述的問題不是一個bug (輸入錯誤后,通過此項來取消)
WONTFIX 描述的問題將永遠不會被修復。
LATER 描述的問題將不會在產(chǎn)品的這個版本中解決.
DUPLICATE 描述的問題是一個存在的bug的復件。
WORKSFORME 所有要重新產(chǎn)生這個bug的企圖是無效的。如果有更多的信息出現(xiàn),請重新分配這個bug,而現(xiàn)在只把它歸檔。
2.2.2 項目組長或開發(fā)者重新指定Bug的屬主。(owner)
1. 為此bug不屬于自己的范圍,可置為 Assigned,等待測試人員重新指定。
2. 為此bug不屬于自己的范圍,但知道誰應該負責,直接輸入被指定人的Email, 進行Ressigned。
3. 操作:(可選項如下)
* Aclearcase/" target="_blank" >ccept bug (change status to ASSIGNED)
* Reassign bug to
* Reassign bug to owner and QA contact of selected component
4. 操作結果:此時bug狀態(tài)又變?yōu)镹ew,此bug的owner變?yōu)楸恢付ǖ娜恕?/p>
2.2.3測試人員驗證已修改的 Bug.
1. 測試人員查詢開發(fā)者已修改的bug,即Status為"Resolved",Resolution為"Fixed".進行重新測試。(可創(chuàng)建test case附件)
2. 經(jīng)驗證無誤后,修改Resolution為VERIFIED。待整個產(chǎn)品發(fā)布后,修改為CLOSED。
若還有問題,REOPENED,狀態(tài)重新變?yōu)?ldquo;New",并發(fā)郵件通知。
3. 具體操作(可選擇項)
1. Leave as RESOLVED FIXED
2. Reopen bug
3. Mark bug as VERIFIED
4. Mark bug as CLOSED
2.2.4 Bug報告者(reporter)或其他有權限的用戶修改及補充Bug
1. 可以修改Bug的各項內(nèi)容。
2. 可以增加建立附件,增加了相關性, 并加一些評論來解釋你正在做些什么和你為什么做。
3. 操作結果:每當一些人修改了bug報告或加了一個評論,他們將會被加到CC列表中,bug報告中的改變會顯在要發(fā)給屬主、寫報告者和CC列表中的人的電子郵件中。
2.2.5測試人員確認開發(fā)人員報告的Bug是否存在.
1. 查詢狀態(tài)為“Unconfirmed"的Bug,
2. 測試人員對開發(fā)人員提交的Bug進行確認,確認Bug存在。
3. 具體操作:選中“Confirm bug(change status to New)"后,進行commit.
4. 操作結果:狀態(tài)變?yōu)?ldquo;New".
2.3、查詢Bug
1.直接輸入Bug Id,點擊find 查詢。可以查看Bug的活動紀錄。
2.點擊Query,輸入條件進行查詢。
3.查詢Bug活動的歷史
4.產(chǎn)生報表。
5.幫助:點擊Clue.
3、關于權限的說明
1. 組內(nèi)成員對bug具有查詢的權利,但不能進行修改。
2. Bug的owner 和 reporter 具有修改的權利。
3. 具有特殊權限的用戶具有修改的權利。