CQ操作文檔和測管理平臺的應用

1、第一篇 測試管理平臺第二篇 ClearQuest的使用質量管理部 程寶紅測試管理平臺的使用 一、管理平臺的登陸 二、用例的導入與更新 三、測試計劃的查詢和管理登陸 1、登陸地址：http:/ 2、輸入賬號登錄，賬號密碼和OA一致；用例的導入與更新 1、導入用例 登陸進入平臺，點擊左邊框導入/更新用例（或上邊測試用例導入1、點擊選擇文件選擇需要導入的測試用例文件2、點擊提交任務（文件會顯示在任務查詢下） 注：成功導入用例的前提條件1、導入測試用例：批量生成TC，會產生新的CQ-ID，導入文件必須是03版excel，用例文檔必須按要求編寫（測試標識、所屬項目、子系統(tǒng)、設計人員有效）；2、更新執(zhí)行用

2、例：批量更新CTC，不會產生CTC，導入文件必須是03版excel，文檔必須包含這些字段“id、執(zhí)行人員、測試結果、結果說明、集成編號、測試數(shù)據(jù)、執(zhí)行日期”；3、查看導入結果在“任務信息”欄可以看到當前處理文檔的信息概況4、在“任務查詢”可以查詢導入文檔隊列狀況及處理狀態(tài)等信息，其中：查詢：查詢以及刷新隊列信息；任務類型：導入測試用例、更新執(zhí)行用例；當前狀態(tài)：說明文檔的處理狀態(tài)，有已提交待處理、處理中、處理成功、處理失敗；提交人：提交文檔的登錄用戶員工號；結果文件下載：導入后的文件，其中導入測試用例會將導入結果更新到文檔中；日志文件下載：查看詳細的導入日志；5、查看數(shù)據(jù)登錄CQ；根據(jù)導入的項目

3、新建查詢“測試用例”或者“執(zhí)行用例”即可；1、查詢測試計劃點擊側邊欄：測試計劃管理測試計劃查詢；通過查詢條件（項目、子系統(tǒng)）進行條件查詢，默認查詢全部；測試計劃的查詢2、新增測試計劃查詢結果頁面可進行的操作包括：全選/添加/刪除測試計劃；點擊“添加”可新增測試計劃表單；單個表單后有詳情和編輯按鈕3、測試計劃表單注意必填項輸入，其中“計劃概述”是可以不填寫的，“是否緊急”必填；4、新增測試任務測試計劃查詢結果頁面，點擊“詳情”進入測試計劃信息頁面，在“關聯(lián)測試任務欄”可進行：全選/批量添加/添加/刪除測試任務表單；批量添加：查詢所在子系統(tǒng)所有的測試用例集（TS），勾選所需要操作的TS，保存自動產

4、生測試任務；新增：彈出測試任務表單頁面，輸入信息后保存；5、測試任務表單 注意必填項的輸入； 測試用例集 測試用例關聯(lián)測試用例集 執(zhí)行用例 如何提交缺陷 如何驗證缺陷 遺留缺陷管理 Q&ACQ使用 1、測試用例集（TS），即Test Suit，測試用例集，指某一次測試版本（迭代版本）創(chuàng)建的測試用例集合，包含了所測試版本的執(zhí)行環(huán)境、集成版本等相關信息； 2、測試用例（TC），即Test Case，測試用例，指根據(jù)系統(tǒng)功能點而編寫的功能測試用例。行業(yè)內比較常用的定義是指對一項特定的軟件產品進行測試任務的描述，體現(xiàn)測試方案、方法、技術和策略。內容包括測試目標、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預

5、期結果、測試腳本等； 3、執(zhí)行用例（CTC），即Configured Test Case，執(zhí)行用例（配置的測試用例），指根據(jù)測試用例集所選取的測試用例而產生的測試用例，相比測試用例，執(zhí)行用例增加了執(zhí)行環(huán)境、執(zhí)行人員、執(zhí)行結果等內容； TC對應的是測試設計階段，由測試設計人員完成用例設計，新增的用例需要由測試負責人審核確認后才可以導入到CQ； TS對應的是測試計劃階段，根據(jù)項目計劃創(chuàng)建，串行模式下，一次上線版本對應一個迭代版本，對應一個TS；并行模式下，一次上線計劃可以對應多個迭代版本，一個迭代版本對應一個TS； 注：某些特殊項目（如移動應用），可以存在一次迭代版本對應多個TS； CTC對應的是

6、測試執(zhí)行階段，通過創(chuàng)建TS后，將TC關聯(lián)到TS，產生相應的CTC；測試執(zhí)行的結果在CTC表單中記錄，每一輪測試完成后都需要及時更新CTC；關聯(lián)關系說明角色：業(yè)務人員、測試人員等操作：新建缺陷。輸入：u 概要描述u 所屬項目u 子系統(tǒng)u 責任人(owner)：根據(jù)情況判定，明顯屬于某責任人的，直接提交到責任人本人，或相應的項目經理。u 嚴重性：缺陷的影響范圍，詳細定義請見附錄一。u 優(yōu)先級：解決缺陷時的先后順序，詳細定義請見附錄二。u 期望完成日期（默認第二天）u 根源：缺陷產生的主要原因，詳細定義請見附錄三u 發(fā)現(xiàn)階段：缺陷是在什么階段被發(fā)現(xiàn)的，詳細定義請參見附錄四u 測試類型：缺陷發(fā)現(xiàn)時所處

7、的測試類型，詳細定義請參見附錄五u 二次缺陷：關閉后又出現(xiàn)的缺陷。u 根源u 功能點u 測試用例編號（發(fā)現(xiàn)階段為系統(tǒng)測試、UAT、集成測試時必填）u 發(fā)現(xiàn)版本：缺陷發(fā)現(xiàn)時的程序版本u 缺陷內容的詳細描述（癥狀、發(fā)生環(huán)境、重現(xiàn)步驟、期望結果、實際結果）缺陷的提交條件：缺陷在Refused、Resolved狀態(tài)角色：測試人員（提交者）操作：驗證缺陷根源和缺陷的修正情況， （1）如果確認已經正確被修正，則執(zhí)行Validate操作。 （Refused/Resolved- Closed) 只有缺陷的提交者或項目的質量負責人才能夠關閉缺陷。 （2）如果缺陷未被修正或未完全被修正， 1） Resolved狀態(tài)，則執(zhí)行Reject操作，填寫Reject的原因， 并保存。（Resolved- Opened ） 2） Refused狀態(tài)，則執(zhí)行Resubmit操作，填寫相關原因， 并 保存。（Refused- Submitted ）缺陷的驗證（一）如何將缺陷標記為延遲狀態(tài)？ 條件：缺陷在Submitted或Opened狀態(tài)，且該缺陷一時無法解決角色：項目經理操作：執(zhí)行Postpone操作 輸入：根源 責任人（默認為系統(tǒng)當前的用戶） Notes（延遲的詳細原因描述）遺留缺陷（二）如何處理延遲狀態(tài)的缺陷？條件：缺陷在Postponed狀態(tài)角色：項目經理操作：對這些延遲狀態(tài)的缺陷定期進行評審。（1