XXXXXX沏目測試缺陷管理&ALM#用手冊文件狀態(tài)：【】草 稿【】修改稿【］正式發(fā)布文檔編號保密等級作者最后完成日期2018-3-12審核人員最后審核日期批準人最后批準日期1登錄到ALM的缺陷管理系統(tǒng)打開IE8、IE9瀏覽器或者 HPALM，在地址欄輸入訪問，如果是IE10瀏覽器，請打開瀏覽器然后按 F12,打開開發(fā)人員工具，然后選擇IE8兼容模式，然后在輸入訪問，。2、如果之前沒有安裝過相關(guān)插件，瀏覽器會提示是否安裝插件，但是在安裝插件前一定要將上述站點加到可信站點和本地 intranet站點上才能自動下載并安裝瀏覽器插件。如下圖：A.增加到可信站點：IE8?Internet選項》安全》可信站點B.增加到Intranet站點：IE8》Internet選項》安全》本地Intranet配置好A和B之后，點擊刷新，瀏覽器就會自動下載并安裝插件。備注：如果使用IE不行，可以直接使用 ALM12自帶的瀏覽器，自帶瀏覽器可以在登錄界面時進行下載。操作步驟如下：3、安裝完插件后會自動跳轉(zhuǎn)到登錄頁面，如圖 2所示。在“用戶名”輸入框輸入您姓名的拼音，密碼默認為空，點擊【身份驗證】按鈕。通過驗證后“項目”下拉列表會列出你有權(quán)訪問的項目，如圖3所示。選擇你要登錄的頁面，點擊【登錄】按鈕。說明：域：Default項目：項目列表只列出你有訪問權(quán)限的項目。大型項目類測試模板登錄后的初始頁面。登錄成功后，點擊“缺陷”，出現(xiàn)如圖4所示頁面。進入缺陷列表。點擊圖4所示頁面左邊列表中的項，將看到如圖5所示的缺陷新增界面。更改項目。如果你同時擁有多個項目的權(quán)限，那么登錄到其中一個項目后可以不需要退出而直接更改到另一個項目。點擊頁面左上角的【工具】，選擇【更改項目】，再點擊你所想要的項目即可，如三峽付項目 UAT。如果你擁有其他項目的權(quán)限，但“更改項目”列表中并沒有列出那些項目，你可以點擊【選擇…】按鈕，轉(zhuǎn)到登錄頁面，選擇需要登錄的項目，登錄一次后該項目名稱就會出現(xiàn)在這個列表中了。注銷。點擊右上角的即可注銷，退出到登錄頁面。2ALM缺陷管理系統(tǒng)的使用缺陷常用字段說明缺陷名稱對缺陷的簡單描述。摘要包括該缺陷所屬的模塊名稱 -子模塊名稱，以及簡單說明缺陷情況。描述詳細描述重現(xiàn)該缺陷的步驟，錯誤現(xiàn)象和期待結(jié)果。必要時可以上傳附件輔助說明。狀態(tài)缺陷狀態(tài)描述如下表：序號缺陷狀態(tài)缺陷狀態(tài)描述備注11-新建測試人員在測試過程中發(fā)現(xiàn)缺陷， 提交新的缺陷給開發(fā)組長進行審核22-打開開發(fā)組長進行判定認定為有效缺陷，并將缺陷分配給具體的開發(fā)人員進行修改33-已修正開發(fā)人員已完成修正，等待測試人員進行回歸測試44-已關(guān)閉缺陷通過測試人員回歸測試，缺陷已被修復(fù)55-已審核測試組長確認測試者提交的缺陷有效5A-回歸失敗缺陷未通過測試人員回歸測試，缺陷未被修復(fù)6B-拒絕拒絕修改缺陷，該缺陷可能由于測試人員理解錯誤或?qū)儆谥貜?fù)提交的缺陷，開發(fā)組長和開發(fā)人員都可以拒絕，拒絕的缺陷需要由仲裁者（一般為項目經(jīng)理和測試經(jīng)理）判定后才能認定為偽缺陷。7C-掛起項目經(jīng)理判定該缺陷不在當前版本進行修復(fù)， 而在未來

版本進行修復(fù)8D-重新打開C-掛起的缺陷在條件允許后可重新打開供開發(fā)人員進行修復(fù)9E-偽缺陷仲裁者（一般為項目經(jīng)理和測試經(jīng)理）對 B-拒絕的缺陷進行判定后，認定該缺陷確實是由于測試人員理解問題或者重復(fù)缺陷等原因?qū)е碌臒o效缺陷（偽缺陷）10F-無效由于測試人員提出的缺陷，測試組長確認無效后，提交缺陷，缺陷狀態(tài)就會修改為“無效”2.1.4分配給2.1.4.1不同角色之間缺陷狀態(tài)的變化:缺陷狀態(tài)的變化事件描述操作者前狀態(tài)后狀態(tài)分配給測試人員新建缺陷測試人員1-新建測試組長（字段測試組長判定缺陷無效測試組長i-新建F-無效無需修改測試組長判定缺陷有效測試組長i-新建5-已審核開發(fā)組長（字段測試組長新建缺陷測試組長5-已審核開發(fā)組長（字段開發(fā)組長確認缺陷有效開發(fā)組長5-已審核2-打開分配給（修復(fù)人開發(fā)組長確認缺陷無效開發(fā)組長5-已審核B-拒絕仲裁人員開發(fā)人員-暫時無法修改缺陷開發(fā)人員2-打開B-拒絕仲裁人員開發(fā)人員-此時修改缺陷開發(fā)人員2-打開2-打開無需修改開發(fā)人員已經(jīng)修復(fù)缺陷開發(fā)人員2-打開3-已修正測試者開發(fā)人員修改延期缺陷開發(fā)人員D-重新打開3-已修正測試者開發(fā)人員修改回歸失敗缺陷開發(fā)人員A-回歸失敗3-已修正測試者（默認測試人員回歸測試-通過測試人員3-已修正4-已關(guān)閉無需修改測試人員回歸測試-不通過測試人員3-已修正A-回歸失敗開發(fā)人員（默認判定是偽缺陷（仲裁人員B-拒絕E-偽缺陷無需修改判定不是偽缺陷，立即修改（仲裁B-拒絕2-打開開發(fā)組長判定不是偽缺陷，延期修改B-拒絕C-掛起無需修改延期缺陷重新打開進行修改C-掛起D-重新打開具體開發(fā)人員2.1.5嚴重程度和優(yōu)先級在填寫缺陷選擇這兩項時,可先參缺陷嚴重級程度與優(yōu)先級別原則上是有一一對應(yīng)的關(guān)系,在填寫缺陷選擇這兩項時,可先參照該對照表：注：測試組w,開發(fā)組的響應(yīng)時間規(guī)定緊急：2-3小時（需測試組長跟開發(fā)組長做口頭提醒 /電話）非常高：1天內(nèi)（需測試組長跟開發(fā)組長做口頭提醒 /電話,Mail）高：3天內(nèi)中：5天內(nèi)低：5天以上嚴重程度缺陷嚴重程度描述優(yōu)先級缺陷優(yōu)先級描述A-致命阻礙流程、系統(tǒng)崩潰導(dǎo)致重大任務(wù)不能正常進行的缺陷，例如：由于程序所引起的死機 ，非法退出死循環(huán)數(shù)據(jù)庫發(fā)生死鎖錯誤操作導(dǎo)致的程序中斷嚴重的計算錯誤與數(shù)據(jù)庫連接錯誤數(shù)據(jù)通訊錯誤等1-緊急.當缺陷所引發(fā)的問題沒有達到緊急的級別，但當該缺陷出現(xiàn)后，影響到了后續(xù)的測試工作進行.客戶無法容忍的貝囿，如貝囿上顯示其他公司名稱.當前操作方式與客戶使用習慣背道而馳。.嚴重/、合理，核心功能完全違反軟件規(guī)范或業(yè)務(wù)規(guī)范，可能導(dǎo)致用戶強烈的反感.系統(tǒng)響應(yīng)時間過長（例如WEB響應(yīng)時間超過10s）.模塊提供的數(shù)據(jù)/、合理， 例如（查詢“錄入人”的下拉項提示為非用戶名字段）.負載測試、壓力測試結(jié)果和用戶需求不符B-嚴重缺陷導(dǎo)致失去系統(tǒng)主要功能，基本功能不能完整使用例如：功能不符程序接口錯誤數(shù)據(jù)流錯誤輕微數(shù)據(jù)計算錯誤等2-非常局.快捷方式不正確，如能夠回車直接進入下一步的設(shè)計成了空格直接進入下一步.嚴重的邏輯錯誤.常用操作平臺不能正常使用功能（WINXP/WIN2000/WINVISTA）.常用瀏覽器不能正常使用（FireFox）.超時限制的時間設(shè)置不合理.未登錄即可瀏覽頁面

7.給客戶演示等過程中客戶重點指出的，嚴重級別卻不是很高的缺陷，建議級別定義至少是非常高C-一般操作性錯誤、錯誤結(jié)果、遺漏功能等影響系統(tǒng)要求或基本功能的實現(xiàn)，例如：界面錯誤（附詳細說明）打印內(nèi)容、格式錯誤簡單的輸入限制未放在前臺進行控制刪除操作未給出提示數(shù)據(jù)輸入沒有邊界值限定或不合理3-高.提不信息不明確，并且非常容易誤導(dǎo)用戶做出錯誤操作或判斷。.軟件功能的實現(xiàn)過程中彈出未控制的系統(tǒng)錯誤提示，導(dǎo)致流程中斷.Cookies沒啟止常保存.服務(wù)器和客戶端的腳本修改未被記錄和.非法操作等Urgent程度的缺陷，如果不具后普遍性而是在極端環(huán)境下出現(xiàn)，例如特定的操作環(huán)境。建議級別定義為High。D-微小錯別字、罕見故障等不影響執(zhí)行工作或功能實現(xiàn)，例如：輔助說明描述不清楚系統(tǒng)處理未優(yōu)化提示窗口文字未采用行業(yè)術(shù)語4-中.提示信息不明確,不止確或不合理.界囿設(shè)計存在缺陷、凌亂或不友好.整體風格不統(tǒng)一E-建議建議，不影響使用的瑕疵或更好的實現(xiàn)等對軟件各方面提出的更好的改進性的意見。5-低.雖后不盡人意之處，但不影響用戶操作或用戶使用頻率較低，并且不會造成錯誤.局部界面不夠美觀2.1.6缺陷類型記錄測試人員判斷該缺陷的類型。分類具體描述1-功能類;A.重復(fù)的功能B.多余的功能C.功能實現(xiàn)與設(shè)計要求不相符D.功能使用性、方便性、易用性不夠2-界回英;A.界面不美觀B.控件排列、格式不統(tǒng)一

C.焦點控制不合理或不全面3-流程類；A.流程控制不符和要求B.流程實現(xiàn)不完整4-提示信息類；A.提示信息重復(fù)或出現(xiàn)時機不合理B.提示信息格式不符和要求C.提示框返回后焦點停留位置不合理5-建議類；A.功能性建議B.操作建議C.檢校建議D.說明建議6-性能類；A.并發(fā)里B.數(shù)據(jù)量C.壓縮率D.響應(yīng)時間7-其他類；A.1-6以外的情況2.1.7缺陷原因記錄開發(fā)人員判斷該缺陷發(fā)生的原因。分類具體描述1-式樣遺漏/錯誤；需求文檔中，沒有相關(guān)的說明設(shè)計文檔中，沒有相關(guān)的說明需求文檔中，相關(guān)的說明與實際現(xiàn)象不一致設(shè)計文檔中，相關(guān)的說明與實際現(xiàn)象不一致2-編程遺漏/錯誤；編碼中沒有包含必要的功能編碼結(jié)果與實際現(xiàn)象不一致3-測試不止；測試時使用的數(shù)據(jù)不止確測試或確認使用的不是測試目標版本測試時使用的操作過程不止確4-環(huán)境不備；測試環(huán)境配置不止確。比如沒有導(dǎo)入必要的基礎(chǔ)數(shù)據(jù)?；蛘弑匾南?nèi)容不存在應(yīng)用程序在發(fā)布，部署時出現(xiàn)錯誤導(dǎo)致的錯誤5-外聯(lián)系統(tǒng)；A.因為其他系統(tǒng)的原因?qū)е碌腻e誤6-重復(fù)；A.同樣缺陷的已經(jīng)指摘過的錯誤7-其他；A.1-6以外的情況主題記錄該缺陷屬于哪個模塊中。主題字段設(shè)置對應(yīng)為測試計劃中的測試主題（功能模塊） ，方便將來統(tǒng)計各個模塊的缺陷密度。測試者記錄該缺陷的登記者，系統(tǒng)會自動獲取當前用戶的用戶號，不需要手工錄入。測試日期記錄該缺陷的登記日期，通常系統(tǒng)會自動獲取當前時間，不需要手工錄入。檢測于發(fā)布記錄發(fā)現(xiàn)該缺陷基線版本（Tags）,測試組長在每次獲取到新的基線版本程序包時，發(fā)布到測試環(huán)境之后，按照程序包上的版本標簽號（一般為 BL_YYYYMMDD_SVN：號），在ALM中“管理”模塊中的“發(fā)布”中增加對應(yīng)的版本號（注：ALM中增加的版本號需與程序包的版本號一致）。如下圖，在管理》發(fā)布》三峽付項目 ST下》點擊新增“周期”?？芍噩F(xiàn)記錄缺陷是否可重現(xiàn)。根據(jù)缺陷描述操作，是否可以發(fā)現(xiàn)缺陷所描述的問題， Y表示可以重現(xiàn)，N表示無法重現(xiàn)。例如有些問題是在特定條件下才出現(xiàn)的， 當條件改變后問題隨之消失，根據(jù)所描述的步驟操作，不會再出現(xiàn)缺陷所描述的問題，這類就是屬于無法重現(xiàn)的缺陷。子系統(tǒng)記錄缺陷所屬的子系統(tǒng)。包含以下內(nèi)容：子系統(tǒng)名稱開發(fā)組長APP-AndroidAPP-iPhoneAPP-iPad電子賬戶反欺詐基礎(chǔ)服務(wù)門戶網(wǎng)絡(luò)預(yù)填單業(yè)務(wù)子系統(tǒng)管理臺報表文檔性能問題修復(fù)日期記錄開發(fā)人員修正該缺陷的修復(fù)日期，系統(tǒng)會自動獲取當前時間，不需要手工錄入。關(guān)閉日期記錄測試人員關(guān)閉該缺陷的關(guān)閉日期，系統(tǒng)會自動獲取當前時間，不需要手工錄入。關(guān)閉于發(fā)布記錄關(guān)閉該缺陷基線版本（ Tags），測試組長在每次獲取到新的基線版本程序包時，發(fā)布到測試環(huán)境之后，按照程序包上的版本標簽號（一般為 BL_YYYYMMDD_SVN：號），在ALM中“管理”模塊中的“發(fā)布”中增加對應(yīng)的版本號（注：ALM中增加的版本號需與程序包的版本號一致）。如下圖，在管理》發(fā)布》三峽付項目ST下》點擊新增“周期”。修改次數(shù)記錄開發(fā)人員因修改本缺陷修改代碼的次數(shù)，用來衡量開發(fā)人員修改缺陷的效率，即測試人員每回歸測試一次發(fā)現(xiàn)回歸失敗，系統(tǒng)會自動將修改次數(shù)加 1，不需要手工錄入。SVIW本號記錄開發(fā)人員修復(fù)缺陷后， SV郵交代碼后，由SVN自動生成的小版本號，方便測試人員根據(jù)該小版本號和基線版本的Tags進行對比，用來獲取本基線版本是否包含本缺陷修改的情報信息。開發(fā)人員在將缺陷狀態(tài)由 2-打開修改為3-已修正時，SVN^本號必填。修改時間記錄本缺陷單最近一次更改的時間戳，系統(tǒng)自動記錄，無需手工錄入注釋開發(fā)人員在修復(fù)缺陷后，需要在注釋欄記錄 SVN版本庫中修改的文件名和文件路徑以及修改的主要內(nèi)容，以方便 CM或者測試人員進行配置管理和回歸測試。另外該欄也可作為各方人員交流的留言窗口，類似論壇的留言功能。注釋欄的填寫方法見下圖：系統(tǒng)新增字段說明變更編號測試組長測試人員在新建缺陷時會有一個字段“測試組長”,這個字段分配到的人員就是這個缺陷的審核人。測試人員新建的缺陷經(jīng)過測試組長審核，缺陷狀態(tài)修改為“已審核“。打開時間開發(fā)人員在確認缺陷有效后，缺陷狀態(tài)由：已審核 -->打開，仲裁人員在缺陷狀態(tài)：拒絕-->打開以及：掛起— >重新打開，打開時間默認是時間當時時間，不需要手動填寫?；貧w測試狀態(tài)測試人員在對“已修正”缺陷進行回歸測試時使用此字段，進行確認回歸是否通過，如果選擇“是“，則回歸通過，缺陷狀態(tài)：已修正 --->已關(guān)閉，如果回歸測試不通過缺陷狀態(tài)：已修正-->回歸失敗。開發(fā)組長測試組長在確認缺陷有效后，就必須使用“開發(fā)組長”字段為缺陷指定一個開發(fā)組長，進一步確認缺陷是否有效。缺陷有效性此字段是測試組長對于缺陷狀態(tài)為“新建“的缺陷，進行確認缺陷是否有效：選擇”無效“，則缺陷狀態(tài)由：新建 --->無效，選擇“有效“缺陷狀態(tài)由：新建— >已審核。是否掛起此字段是針對仲裁人員對于缺陷狀態(tài)為拒絕的缺陷，“仲裁是否缺陷”選擇“是“時，會出現(xiàn)一個”是否掛起“字段，來進行確認是否要此缺陷掛起，留在以后版本處理。選擇”“是“缺陷狀態(tài)由：拒絕—>掛起，選擇否缺陷狀態(tài)由：拒絕 -->打開。是否進行回歸測試測試者針對缺陷狀態(tài)為“已修正”的缺陷，打開界面時會呈現(xiàn)“是否回歸測試字段“進行判斷當前是否要進行回歸測試，如果選擇”是“，表示當前進行回歸測試，則會跳出一個“回歸測試狀態(tài)“的字段，如果選擇”否“則會跳出“未回歸原因“字段。是否已修復(fù)此字段表示開發(fā)人員對于缺陷狀態(tài)為“打開”，“重新打開”和“回歸失敗“的缺陷判斷是否已經(jīng)修復(fù)的操作，如果選擇“是“，則缺陷狀態(tài)會由：打開— >已修正，如果選擇”否“則狀態(tài)不變。是否重新打開此字段是仲裁人員對于缺陷狀態(tài)為“掛起“的缺陷，判斷是否要重新打開，如果選擇”是“則缺陷狀態(tài)由：掛起 --->重新打開，選擇“否“缺陷狀態(tài)不變。未回歸原因此字段針對缺陷狀態(tài)為“已修正”的缺陷測試者的，”是否回歸測試“選擇的是否就會出現(xiàn)讓測試者填寫，不進行回歸測試的原因。驗證缺陷有效性此字段是開發(fā)組長針對缺陷狀態(tài)為“已審核“的缺陷再次確認缺陷是否有效，選擇”有效“表示缺陷是有效的，選擇”無效“表示缺陷是無效的。預(yù)計回歸工時測試者選擇“是否進行回歸測試“字段，選擇”是“的時候進行判斷大概回歸測試需要耗時多少。暫無法修改開發(fā)人員針對缺陷狀態(tài)為”打開“的缺陷是否由于此缺陷，本版本無法解決，要留在以后版本解決的操作字段 ,選擇” 是“表示此缺陷當前版本下， 可以進行修改，選擇“否“表示此版本下，當前缺陷可以進行修復(fù)。仲裁人員仲裁人員一般是項目經(jīng)理，仲裁人員主要是針對缺陷狀態(tài)為“拒絕”和“掛起“的缺陷進行操作，對于拒絕的缺陷是最終確認缺陷的有效性，如果無效就是偽缺陷，如果有效則進行下一步操作。針對掛起的缺陷主要是判斷當前版本下，此缺陷是否要重新打開。仲裁是否缺陷仲裁人員使用此字段進行最終缺陷有效性的判斷，如果選擇“是”,表示此缺陷是有效的，可以進行下一步操作，如果選擇“否“則表示此缺陷是無效的，是偽缺陷。缺陷管理流程圖1、不論是簡單還是復(fù)雜的缺陷，開發(fā)人員都要在修改了代碼并確保代碼提交到服務(wù)器后，再將缺陷狀態(tài)由“ 2-打開”置為“3-已修正”，并填寫SVN版本號。對于非常簡單明了的缺陷（例如界面上的一個錯別字），可以在注釋中加簡單的注釋說明：（如：已修改）但對于復(fù)雜的缺陷，開發(fā)人員在填寫注釋的時候需包含以下幾點：配置庫修改代碼對應(yīng)文件名和文件路徑。缺陷解決的方法：（該項描述主要是方便以后遇到同類問題的同事，可以查看當時的解決辦法，如果該缺陷的修改引發(fā)了其他的缺陷產(chǎn)生，則開發(fā)人員可以查看一下當時的修改情況）這個改動引起了哪些變動：（方便測試人員在進行回歸測試時，確定回歸范圍）如果缺陷是由于測試人員理解錯誤導(dǎo)致，或者開發(fā)人員認為不需要修改的，開發(fā)人員可以將缺陷狀態(tài)設(shè)置為“B-拒絕”，但是必須在【注釋】欄中填寫拒絕修改的原因。如果目前不具備修改本缺陷的條件（環(huán)境原因、涉獵面太廣、難度系數(shù)很大），開發(fā)人員可將缺陷狀態(tài)設(shè)置為 “C-掛起”進行延遲修改，但是必須在【注釋】欄中填寫延遲修改的原因。4、如果開發(fā)人員認為該缺陷與其他缺陷重復(fù)，也需要在【注釋】欄中填寫與之重復(fù)的缺陷ID,例如注釋內(nèi)容可以填寫：與缺陷10重復(fù)。目的是讓開發(fā)人員再確認一下這兩個缺陷是否真的描述同一個問題。小提示：在新增注釋說明時，可以直接點擊頁面右下方的按鈕， ALM可以直接添加你的登錄帳號在“注釋”中，省去自己填寫的麻煩！如圖12.請大家在填寫時養(yǎng)成加入自己信息的習慣，方便測試人員在回歸測試時可以看到是誰回復(fù)的，有問題方便直接溝通！缺陷管理崗位職責項目經(jīng)理：對整個項目負責，對產(chǎn)品質(zhì)量負責，判定缺陷是否應(yīng)修復(fù)，作為仲裁小組成員判定缺陷是否偽缺陷，是否可進行延期修改，嚴格控制缺陷的生命周期，跟蹤缺陷修復(fù)情況，直至缺陷關(guān)閉；開發(fā)組長：判定缺陷是否可修復(fù)，進行缺陷定位，提供修復(fù)方案、設(shè)計給開發(fā)人員，按照計劃跟蹤編碼、缺陷修復(fù)任務(wù)；測試組長：按照缺陷管理規(guī)范進行跟蹤處理，協(xié)助開發(fā)人員進行缺陷定位，作為仲裁小組成員判定缺陷是否偽缺陷，是否可進行延期修改，嚴格控制缺陷生命周期，跟蹤缺陷修復(fù)情況，直至缺陷關(guān)閉；測試人員：執(zhí)行測試的人員，發(fā)現(xiàn)缺陷、提交缺陷，待修復(fù)后進行回歸測試；開發(fā)人員：執(zhí)行開發(fā)任務(wù)的人員，按照計劃完成設(shè)計、編碼、缺陷修復(fù)的任務(wù)；仲裁小組決定偽缺陷和延期修改缺陷的職責1、仲裁小組的成員包括：項目經(jīng)理和測試組長，仲裁方式采取項目經(jīng)理和測試組長定期共同對被拒絕缺陷和掛起缺陷進行逐個分析的方式，并且商議得出最終的處理意見，最終由測試組長在ALM上進行意見反饋和缺陷狀態(tài)的流轉(zhuǎn)。2、仲裁小組需要對“B-拒絕”的缺陷進行判定，以決定該缺陷是否偽缺陷，若是，需將缺陷狀態(tài)置為“E-偽缺陷”，并在注釋欄填寫確定為偽缺陷的原因；若不是，可以將缺陷置為“2-打開”（立即修改），或者置為“C-掛起”（延遲修改）。仲裁小組若決定延遲修改缺陷，需在注釋中寫明延遲修改的原因，再將缺陷狀態(tài)置為“C-掛起”。4、仲裁小組在對缺陷進行延遲修改后，需在合適的時間將缺陷重新打開，將缺陷狀態(tài)置為“D-重新打開”讓開發(fā)人員繼續(xù)修改缺陷填寫規(guī)范缺陷的填寫原則測試人員填寫測試缺陷記錄時的原則：單一：一個測試案例執(zhí)行后可能發(fā)現(xiàn)多個缺陷，但一條缺陷記錄建議記錄一個缺陷；準確：對問題的描述準確，按照步驟操作，可以重現(xiàn)問題；同時也指對操作和對象的描述準確，不會出現(xiàn)歧義；最好是能夠找到錯誤的直接原因；完整：對問題現(xiàn)象的描述完整，包括環(huán)境（不同的環(huán)境），數(shù)據(jù)，結(jié)果（正確和錯誤部分）等；延伸：能夠舉一反三，由發(fā)現(xiàn)的問題，對其它可能的情況進行測試，并列出錯誤或正確的情況；不要重復(fù)提報告：測試人員在提交自己的缺陷之前，先要快速查找缺陷庫中是否已經(jīng)有相似或相關(guān)的缺陷。一個缺陷庫中，重復(fù)的缺陷越少越好；再小的缺陷也要報告并提交缺陷跟蹤系統(tǒng)；測試人員提交合理的建議，同時對于存在的問題提出自己的建議及表現(xiàn)方法；以前系統(tǒng)存在的缺陷，作為本項目缺陷提交到缺陷庫。缺陷填寫的相關(guān)支持文檔測試人員應(yīng)該在自己的缺陷記錄中加入很好的支持文檔，或者至少是供參考的文檔。有用的支持文檔包括：屏幕截圖；重現(xiàn)缺陷的測試案例；測試腳本；用來創(chuàng)建某個狀態(tài)的特定數(shù)據(jù)（前置條件）；使用的數(shù)據(jù)庫連接串（環(huán)境說明）?？偟膩碇v，有效的缺陷記錄應(yīng)包含許多信息，在提交報告時通過多種方式準確地描述每項內(nèi)容。不同角色操作缺陷測試者新建缺陷.填寫賬號，用戶名：ceshi密碼：123456域名：Default項目：大型測試項目類模板點擊“新建缺陷”打開新建缺陷頁面：按實際缺陷信息填寫缺陷注意：填寫的過程中標紅的字段是必填的，灰色字段的是不能操作，也不用操作的字段。填寫完信息后，點擊按鈕。注意：1.如果填寫的信息正確直接提交如果不想提交缺陷了，可以直接點擊或者按鈕。選擇測試組長時，必須是在測試組長組內(nèi)的人員，否則或有提示：選擇測試組長時，可以按組選擇：4.1.2驗證缺陷（已修正）選擇缺陷狀態(tài)是“已修正”的缺陷，測試者是當前用戶的。通過篩選條件篩選：設(shè)置篩選條件：缺陷狀態(tài)為：已修正，測試者：當前用戶點擊缺陷ID，打開缺陷進入缺陷頁面注意：1.必填“是否進行回歸測試”a選擇“是”會有“回歸測試狀態(tài)”字段彈出必填“回歸測試狀態(tài)”字段：（1）選擇“通過”會有“關(guān)閉于版本”和“關(guān)閉于發(fā)布”字段彈出。（2）選擇“不通過”，沒有新字段彈出b.“是否進行回歸測試”選擇“否”，會有“未回歸原因”字段彈出：22.點擊“缺陷ID”打開“已審核”缺陷頁面4.2測試組長缺陷審核（新建）填寫賬號：czuhzang，密碼：空，域名：Default項目：大型項目類模板.設(shè)置篩選條件“缺陷狀態(tài)”為“新建”，測試組長為：當前用戶.點擊“缺陷ID”，進入頁面：注意：測試組長進入“新建”缺陷頁面，可以操作三個字段：“優(yōu)先級” ，“嚴重程度”和“缺陷有效性”其中，“優(yōu)先級”，“嚴重程度”是針對測試者可能理解不夠準確，此時測試組長可以重新選擇。必填“優(yōu)先級”字段是測試組長審核缺陷有效性的操作字段（1）選擇“有效”，會跳出“開發(fā)組長”字段。（2）選擇“無效”沒有字段彈出，但是“注釋”必須填寫。4.2.2測試組長新建缺陷點擊按鈕，進入新建缺陷頁面：注意：測試組長新建的缺陷和測試者新建的缺陷有兩處區(qū)別1）缺陷狀態(tài)是“已審核”的狀態(tài)。2）此時不是選擇測試組長，而是選擇開發(fā)組長4.3開發(fā)組長填寫賬號：kzuzhang，密碼：為空，域名：Default，項目：大型測試項目類模板審核“已審核”缺陷.設(shè)置篩選條件，缺陷狀態(tài)“已審核”，開發(fā)組長：當前用戶注意：必填字段“驗證缺陷有效性”（1）選擇“有效”會彈出“缺陷修復(fù)人”和“估計修復(fù)時間”其中在填寫的時候，估計修復(fù)時間是一定的天數(shù)，缺陷修復(fù)人就是開發(fā)人員。(2)選擇“無效”，會彈出“仲裁人員”仲裁人員就是項目經(jīng)理或者測試組長組成的。對于“拒絕”的缺陷進行最終確認。4.4開發(fā)人員賬號kaifa，密碼：為空，域名：Default，項目：大型項目測試類模板.設(shè)置篩選條件，缺陷狀態(tài)：“打開”or‘回歸失敗’or“重新打開”，缺陷修復(fù)人：當前用戶4.4.1修復(fù)“打開”缺陷點擊“缺陷ID”進入缺陷頁面:、，、.一、、一注意：(1)“暫無法修改”必填字段，“是”和“否”(a)選擇“是”表示，此版本無法修改此缺陷暫時拒絕，會跳出“仲裁人員”必填字段且“注釋”必須填寫。(2)選擇“否”，表示此缺陷現(xiàn)在可以修復(fù)，會跳出“是否已修復(fù)”必填字段，“是”和“否”(a)選擇“是"，表示缺陷以及修復(fù)，會跳出“實際修復(fù)時間” ，“缺陷原因”和“SVN版本號”其中的“實際修復(fù)時間”是測試時間和修復(fù)時間之間的天數(shù)差，不是實際點。(b)選擇“否”表示此缺陷，暫時還沒修復(fù)，不會跳出字段。4.4.2修復(fù)“回歸失敗”缺陷1.點擊“缺陷 ID”進入缺陷界面、，、.一、、一注意：“是”和“否”“是否已修復(fù)”必填字段，“是”和“否”（a）選擇“是”，表示缺陷以及修復(fù)，會跳出“實際修復(fù)時間” ，“缺陷原因” 和“SVN版本號”其中的“實際修復(fù)時間”是測試時間和修復(fù)時間之間的天數(shù)差，不是實際點。（b）選擇“否”表示此缺陷，暫時還沒修復(fù)，不會跳出字段。4.4.3修復(fù)“重新打開”缺陷點擊“缺陷ID”進入缺陷界面、，、.一、、一注意：“是否已修復(fù)”必填字段，“是”和“否”（a）選擇“是”，表示缺陷以及修復(fù)，會跳出“實際修復(fù)時間” ，“缺陷原因” 和“SVN版本號”其中的“實際修復(fù)時間”是測試時間和修復(fù)時間之間的天數(shù)差，不是實際點。（b）選擇“否”表示此缺陷，暫時還沒修復(fù)，不會跳出字段。4.5仲裁人員賬號：zhongcai，密碼：為空，域名：Default，項目：大型項目類測試模板設(shè)置篩選條件：缺陷狀態(tài)：“拒絕”or“掛起”，仲裁人員：當前使用者仲裁“拒絕”缺陷點擊“缺陷ID”，進入缺陷界面：、，、.一、、一注意：“是”和“否”,選擇“是”表示最終確認缺陷是有效（1）必填字段“仲裁是否缺陷”“是”和“否”,選擇“是”表示最終確認缺陷是有效的，會跳出“是否掛起”必填字段(a)“是否掛起”必填字段，“是”和“否”。選擇“是”表示當前缺陷此版本無法解決,延期解決，會跳出“計劃關(guān)閉版本”必填字段。(b)選擇“否"，表示此版本可以解決，不跳出字段，指定開發(fā)組長。(2)選擇“否”，表示最終仲裁此缺陷不是游戲缺陷，是偽缺陷，不跳出字段，但是“注釋”字段必填。仲裁“掛起”缺陷.點擊“缺陷ID”，進入缺陷頁面。、，、.一、、一汪思：.“是否重新打開”必填字段， “是”和“否”，選擇“是”，表示掛起的缺陷此版本下要進行修改，跳出“缺陷修復(fù)人”必填字段，并且指定缺陷修復(fù)人。.選擇“否”，表示掛起的缺陷，仍為掛起狀態(tài)。5發(fā)布和周期發(fā)布和周期簡介發(fā)布：指項目計劃周期：指項目計劃內(nèi)各個功能模塊的開發(fā)或者測試周期。創(chuàng)建發(fā)布點擊導(dǎo)航欄的管理-發(fā)布，選中發(fā)布文件夾-新建發(fā)布，在彈出的對話框輸入新建發(fā)布的名稱，如“訂票系統(tǒng)發(fā)布"，選擇適當?shù)拈_始時間和結(jié)束時間，并點擊確認。創(chuàng)建周期選中訂票系統(tǒng)發(fā)布，點擊新建周期，在彈出的對話框中填寫名稱日期等相關(guān)信息，確認后點擊確定。查看發(fā)布和周期中的狀態(tài)選中相應(yīng)發(fā)布，并點擊“狀態(tài)”選擇卡，則可以查看關(guān)聯(lián)到此發(fā)布的需求、測試的相關(guān)信息。6制定需求新建需求文件夾在導(dǎo)航欄中選擇需求，對應(yīng)的頁面中選中需求文件夾，點擊工具欄中的新建按鈕，并在彈出的對話框中填寫相關(guān)信息，確認。然后會提示選擇相應(yīng)的優(yōu)先級，選擇即可，到此新建需求文件夾結(jié)束。新建需求選擇相應(yīng)的訂票系統(tǒng)文件夾，點擊新建需求按鈕，在彈出的對話框中填入相關(guān)信息（有紅色標注的為必填項），確認無誤后點擊提交按鈕，完成新建需求的提交。查看需求詳情（1）.選擇需要產(chǎn)看的需求條目，在工具欄選擇“需求”-“查看需求詳情”（2）.則可以看到此條需求的詳細信息，如需對需求信息進行修改則在彈出的詳細信息頁面中直接修改并點擊“確定”即可。將需求分配給周期（1）.選中指定需求條目，點擊工具欄中的“需求”-“分配至周期”如圖：（2）.在彈出的對話框中打開發(fā)布樹，勾選指定的周期，并點擊“確定”即可把需求條目分配至周期。將需求轉(zhuǎn)換到測試在創(chuàng)建需求樹后，可將需求用作在“測試計劃”模塊中定義測試計劃樹的基礎(chǔ)。設(shè)計測試計劃樹時，可以使用“轉(zhuǎn)換到測試”向?qū)椭瓿上嚓P(guān)操作。該向?qū)Э捎糜趯⑿枨髽渲羞x定的需求或所有需求轉(zhuǎn)換到測試計劃樹中的主題或測試。. 選中需求樹中的需求條目或者文件夾，我們這里選擇“訂票系統(tǒng)”文件夾，點擊工具欄中的“需求”-“轉(zhuǎn)換到測試”則彈出如下向?qū)υ捒颉? 選中需求樹中的需求條目或者文件夾，我們這里選擇“訂票系統(tǒng)”文件夾，點擊工具欄中的“需求”-“轉(zhuǎn)換到測試”則彈出如下向?qū)υ捒?。我們一般選擇下面三種情況當選擇“將最低子需求轉(zhuǎn)換到測試”時，測試計劃樹中將生成與選中需求相同的目錄結(jié)構(gòu)，并將最低級的需求轉(zhuǎn)換為相對應(yīng)的測試條目。當選擇“將所有需求轉(zhuǎn)換為主題”時，測試計劃樹中將生成與選中需求相同的目錄結(jié)構(gòu)，并將最低一級的需求條目轉(zhuǎn)換為相對應(yīng)的主題即文件夾， 我們可在相對應(yīng)的主題下新建多個測試。當選擇“生成單個測試時”，測試計劃中選定的需求條目轉(zhuǎn)換為測試條目。.這里我們選擇“將最低子需求轉(zhuǎn)換到測試”點擊“下一步”生成預(yù)覽。.確認勾選“自動完成子項”，則會生成與需求樹中相同的目錄結(jié)構(gòu)，點擊“下一步” 。. 點擊“主題”的下拉框，則會加載出測試計劃樹，我們選中根目錄“Subject”點擊確定(在此過程中也可以新建文件夾) ，則會在根目錄下生成“訂票系統(tǒng)”的測試計劃樹。點擊“確定”再點擊“完成”， 則開始轉(zhuǎn)換過程，在此過程中會提示輸入測試計劃的必填項，輸入確定即可完成轉(zhuǎn)換。.打開導(dǎo)航欄的“測試”-“測試計劃”則能看到從需求轉(zhuǎn)換過來的測試。.點擊打開對應(yīng)測試計劃的“需求覆蓋率”選擇卡，則能看到已經(jīng)關(guān)聯(lián)到需求中的訂票系統(tǒng)登錄條目，此后這條測試計劃的執(zhí)行狀態(tài)將自動關(guān)聯(lián)到需求樹中測試覆蓋率。6.6批量導(dǎo)入需求如果需要批量導(dǎo)入需求則需要已安裝 Excel導(dǎo)入插件，可以到ALM開始界面的“快速開始”對應(yīng)頁面下載。安裝成功后打開 Excel會出現(xiàn)如下“加載項”選擇卡。特別提醒：如下圖“需求目錄”的字段說明，當我們需要導(dǎo)入文件目錄結(jié)構(gòu)時必須保證需求條目的父節(jié)點已經(jīng)存在，或者在同一次導(dǎo)入中，在低 ID先創(chuàng)建文件夾類型的目錄，以保證高ID數(shù)據(jù)導(dǎo)入時父目錄已經(jīng)存在。.選中需要導(dǎo)入的數(shù)據(jù)，點擊“ExportToHPALM“。.在彈出的向?qū)е刑钊敕?wù)器的Url地址，然后點擊“Next”。.在向?qū)е刑顚懹脩舻牡卿浢兔艽a(密碼要在英文輸入法下才能輸入)，點擊“Next”。.像平時登錄一樣選擇域和項目，并點擊“ Next”。.選擇“Requirements”即導(dǎo)入需求，點擊“Next”。同理，如果導(dǎo)入的是測試集或者缺陷要選中相應(yīng)條目。.創(chuàng)建映射關(guān)系集(這一步只創(chuàng)建映射名稱) ，即要將Excel指定列對應(yīng)到相應(yīng)的 ALM字段中，如果以前已經(jīng)存在映射關(guān)系則可以直接選中，這里我們選擇已存在的映射，如果不合我們的要求可以在后幾步中進行修改，我們也可以新建一組映射關(guān)系。下次再導(dǎo)入時就能夠直接用這條映射關(guān)系。.選擇是導(dǎo)入單一類型還是導(dǎo)入在Excel中擁有列定義的類型，這里我們選擇已在 Excel擁有列定義的類型，填入Excel中相應(yīng)列的編號，點擊“Next”。特別注意：如果選擇用Excel對應(yīng)列去映射需求類型，則在下一步具體字段映射時只會顯示所有需求類型擁有的共有字段，如果你需要導(dǎo)入的需求中擁有指定類型的專有字段信息則必須使用單一類型映射。.設(shè)置Excel和ALM的字段映射關(guān)系，選擇ALM的字段如“名稱”，點擊右向箭頭，在彈出的對話框中填寫Excel中對應(yīng)列的英文字母，點擊OK則完成此字段的映射，同樣方法建立其他字段的映射關(guān)系(紅色為必須映射的字段)。.全部映射完成后點擊 “Export”，如果系統(tǒng)校驗成功，則執(zhí)行需求的導(dǎo)入。成功后會顯示如下對話框。點擊“Finish”。.回到系統(tǒng)的需求模塊，點擊“刷新”則能看到我們導(dǎo)入的文件夾和需求條目。7制定測試計劃在確定測試目標后，應(yīng)構(gòu)建測試計劃樹，此樹以層次結(jié)構(gòu)的方式將應(yīng)用程序劃分為測試單元或主題。對于測試計劃樹中的每個主題，可定義包含步驟的測試。對于每個測試步驟，可以指定要對應(yīng)用程序執(zhí)行的操作和預(yù)期結(jié)果。.新建測試計劃.在測試計劃中選中“訂票系統(tǒng)”文件夾，點擊工具欄中的“新建測試”按鈕，在彈出的對話框中填寫相關(guān)信息，點“確定”進行提交。則會在“訂票系統(tǒng)”目錄下多一項相應(yīng)的測試計劃。.將測試添加到測試計劃樹并定義基本測試信息后，可定義測試步驟，即指定如何執(zhí)行測試的詳細分步說明。步驟包括要對應(yīng)用程序執(zhí)行的操作和預(yù)期結(jié)果。選中相應(yīng)的測試計劃條目，點擊“設(shè)計步驟”選擇卡，點擊“新建步驟”按鈕，在彈出的對話框輸入相應(yīng)的操作及輸入輸出操作并點擊“確定”進行提交。設(shè)計測試步驟提交完成后，設(shè)計步驟頁面多出一條步驟，同樣方法添加覆蓋一個測試計劃的多條步驟，效果如下:定義測試參數(shù).選中制定測試計劃，點擊“參數(shù)”選擇卡，點擊“新建參數(shù)”按鈕，在彈出的對話框中填寫參數(shù)名稱，默認值等項，點擊“確定”提交。.可以填寫多個參數(shù)值，效果如下：將參數(shù)分配給測試步驟.選中對應(yīng)測試計劃，點擊“設(shè)計步驟”選擇卡，將光標定位到輸入姓名之后，點擊“插入?yún)?shù)”按鈕，在彈出的對話框中選擇“姓名”行，點擊“確定”提交。.提交成功后會出現(xiàn)如家參數(shù)標志，證明分配參數(shù)成功。同理可分配日期和航班號。創(chuàng)建覆蓋率測試計劃中的測試必須符合您的需求。 為幫助確保在整個應(yīng)用程序生命周期管理過程中的合規(guī)性，可添加測試和需求之間的覆蓋率。如果您的測試計劃條目是由需求轉(zhuǎn)化過來的， 則需求覆蓋率以創(chuàng)建好了。如果測試計劃條目是后來創(chuàng)建的，則需要手工創(chuàng)建覆蓋率。我們先在需求樹中加入一條“訂單提交”的需求，此處步驟省略，詳見第三部分-定制需求。選中相應(yīng)的測試計劃，點擊打開“需求覆蓋率”選擇卡，點擊“選擇需求”按鈕，右邊會加載出需求樹，選擇我們提前建好的“訂單提交”條目，點擊“添加到覆蓋率”即左向箭頭，則完成需求到測試的關(guān)聯(lián)，即添加完成需求覆蓋率。添加成功后，如圖：查看覆蓋率.從導(dǎo)航欄選擇需求，在頁面中點擊“查看” -“覆蓋率分析”。.則會加載出覆蓋率分析視圖， 我們會看到添加的兩條需求的狀態(tài)為 “NoRun,即測試已經(jīng)覆蓋到了需求，但是測試還未運行。.雙擊條目時可看到詳細的覆蓋率分析8案例的批量導(dǎo)入導(dǎo)入前須知注意：導(dǎo)入案例前須安裝工具，安裝完成后EXCE葉會增加“加載項”一欄。導(dǎo)入選擇：測試名稱即測試編號A;測試要點即步驟J;類型即手動測試S;描述即步驟內(nèi)容K;主題即主題G;測試概述即測試概述H;預(yù)期結(jié)果即預(yù)期結(jié)果M.注意：以上選項為必選項目，同時案例集末模板如果不同，對應(yīng)的列需要進行調(diào)整。案例批量導(dǎo)入步驟.在EXECL中選中需導(dǎo)入的案