1、PAGE 時間狀態修訂人2009-11-2初稿張彥彬必聯（北京）電子商務信息技術有限公司 DATE yyyy年M月 * MERGEFORMAT 2022年8月以及操作說明QC使用流程定制PAGE iii目 錄TOC o 1-3 h z HYPERLINK l _Toc245175428 第一章 管理員定義 PAGEREF _Toc245175428 h 1 HYPERLINK l _Toc245175429 1. 自定義項目列表表 PAGEREF _Toc245175429 h 1 HYPERLINK l _Toc245175430 1.1 針對QC中的的“需求”模塊 PAGEREF _Toc

2、245175430 h 1 HYPERLINK l _Toc245175431 1.2 針對QC中的的“測試計劃”模塊 PAGEREF _Toc245175431 h 2 HYPERLINK l _Toc245175432 1.3 針對QC中的的“缺陷”模塊 PAGEREF _Toc245175432 h 2 HYPERLINK l _Toc245175433 2. 自定義項目實體體 PAGEREF _Toc245175433 h 3 HYPERLINK l _Toc245175434 2.1 “缺陷”實體體修改 PAGEREF _Toc245175434 h 3 HYPERLINK l _T

3、oc245175435 2.2 “TEST”實體修改 PAGEREF _Toc245175435 h 4 HYPERLINK l _Toc245175436 3. 設置組 PAGEREF _Toc245175436 h 6 HYPERLINK l _Toc245175437 3.1 設置測試工作作者組 PAGEREF _Toc245175437 h 6 HYPERLINK l _Toc245175438 3.2 設置開發人員員組 PAGEREF _Toc245175438 h 8 HYPERLINK l _Toc245175439 4. 設置項目用戶 PAGEREF _Toc245175439

4、 h 9 HYPERLINK l _Toc245175440 5. 設置工作流流 PAGEREF _Toc245175440 h 10 HYPERLINK l _Toc245175441 5.1 添加缺陷字段段自定義 PAGEREF _Toc245175441 h 10 HYPERLINK l _Toc245175442 5.2 缺陷詳細信息息字段自定義 PAGEREF _Toc245175442 h 11 HYPERLINK l _Toc245175443 5.3 腳本本編輯器 PAGEREF _Toc245175443 h 11 HYPERLINK l _Toc245175444 第二章

5、需求模塊 PAGEREF _Toc245175444 h 14 HYPERLINK l _Toc245175445 1. 新建需求 PAGEREF _Toc245175445 h 14 HYPERLINK l _Toc245175446 1.1 新建需求 PAGEREF _Toc245175446 h 14 HYPERLINK l _Toc245175447 1.2 需求編寫要求求 PAGEREF _Toc245175447 h 14 HYPERLINK l _Toc245175448 2. 轉換測試 PAGEREF _Toc245175448 h 15 HYPERLINK l _Toc245

6、175449 第三章 業務組件模塊塊 PAGEREF _Toc245175449 h 17 HYPERLINK l _Toc245175450 1. 業務組件介紹 PAGEREF _Toc245175450 h 17 HYPERLINK l _Toc245175451 2. 具體體現 PAGEREF _Toc245175451 h 17 HYPERLINK l _Toc245175452 3. 工作流程 PAGEREF _Toc245175452 h 18 HYPERLINK l _Toc245175453 4. 測試使用？ PAGEREF _Toc245175453 h 18 HYPERLI

7、NK l _Toc245175454 第四章 計劃模塊 PAGEREF _Toc245175454 h 19 HYPERLINK l _Toc245175455 1. 用例編寫 PAGEREF _Toc245175455 h 19 HYPERLINK l _Toc245175456 1.1 導入用例編寫寫 PAGEREF _Toc245175456 h 19 HYPERLINK l _Toc245175457 1.2 新建用例編寫寫 PAGEREF _Toc245175457 h 19 HYPERLINK l _Toc245175458 1.3 用例編寫要求求 PAGEREF _Toc2451

8、75458 h 19 HYPERLINK l _Toc245175459 2. 鏈接缺陷 PAGEREF _Toc245175459 h 20 HYPERLINK l _Toc245175460 第五章 實驗室模塊 PAGEREF _Toc245175460 h 21 HYPERLINK l _Toc245175461 第六章 缺陷模塊 PAGEREF _Toc245175461 h 22 HYPERLINK l _Toc245175462 1. 新增缺陷 PAGEREF _Toc245175462 h 22 HYPERLINK l _Toc245175463 2. 缺陷編寫要求 PAGERE

9、F _Toc245175463 h 22 HYPERLINK l _Toc245175464 3. 缺陷范例 PAGEREF _Toc245175464 h 23 HYPERLINK l _Toc245175465 4. 界面顯示 PAGEREF _Toc245175465 h 23 HYPERLINK l _Toc245175466 5. 缺陷狀態控制 PAGEREF _Toc245175466 h 24 HYPERLINK l _Toc245175467 5.1 測試人員控制制缺陷狀態 PAGEREF _Toc245175467 h 24 HYPERLINK l _Toc245175468

10、 5.2 測試負責人控控制缺陷狀態 PAGEREF _Toc245175468 h 25 HYPERLINK l _Toc245175469 5.3 開發人員控制制缺陷狀態 PAGEREF _Toc245175469 h 25 HYPERLINK l _Toc245175470 第七章 QC綜述 PAGEREF _Toc245175470 h 26 HYPERLINK l _Toc245175471 1. 流程綜述 PAGEREF _Toc245175471 h 26 HYPERLINK l _Toc245175472 2. 指導意見 PAGEREF _Toc245175472 h 26PAG

11、E 26管理員定義自定義項目列表針對QC中的“需求”模塊新建需求時，使用的“產品”的字段，進行如如下修改：進入自定義項目列表：1這個“所有項目”列表對應QC需需求中的“產品”字段，我們公司以項目為為產品，開展測試試，每個開發的項目下，可可以細分具體的測測試子產品，所以以，需要把這個“產品”細化一下，用于對對新建的“測試需求”的一個屬性描述述，圖中的“列表項”中，主要列出測測試需求所屬的子子產品的分類。以以公司開始的“競爭性談判”這個項目實體為為例，在新建測試試需求時，可能會會分到“節點”，“視圖”，“流程”等各子產品下，所所以，在QC建測測試項目之初，需需要在“所有項目”下的列表項中，加加入圖

12、中的一些新新的列表，便于在在QC新建測試需需求時選用。2列表“審閱狀態”：列表項為“未審閱”和“已審閱”，默認為“未審閱”針對QC中的“測試計計劃”模塊增加兩個列表，用于新新建測試用例。1新增“用例審查“列表列表項為兩項：“未審審查”和“已審查”。默認為“未審查”2新增“用例優先級級”列表列表項為三項：“低”“一般”“高”，默認為“一般”針對QC中的“缺陷”模塊QC中自定義的缺陷狀狀態有可能一些狀狀態值不符合測試試整體過程的要求求，以及對缺陷流流程進行控制，所所以，自定義一個個“bug狀態”的列表，具體如如圖所示：列表項中包括測試過程程中缺陷的所有狀狀態：新建，打開開，已修改，非BUG，已已復

13、測，已關閉，重重新打開，暫不處處理，建議。自定義項目實體“缺陷”實體修改1. 在“系統字段”中，點擊“狀態”進入字段設置，把把“必填”，“驗證值”的勾選去掉！以后后項目測試過程中中的缺陷的狀態，都都不再使用該QC提提供的該字段。2. 新增“用戶字段段”缺陷狀態字段名記錄為“BG_USER_01”，字段類型為“查找列表”，選中“必填”查找列表選擇在自定義義項目列表時新建建的“bug狀態”列表以后項目測試過程中的的缺陷的狀態變化化都用此字段中的的值來表示！“TEST”實體修改新增用戶字段為“* 用例審查”，“* 用例優先級級”如下兩圖所示：其中：“* 用例審查查”字段名稱“TS_USER_02”，

14、“查找列表”使用之前在“自定義項目列表表”中新增的“用例審查”；“* 用例優先級”字段段名稱“TS_USER_01”，“查找列表”使用之前在“自定義項目列表表”中新增的“用例優先級”；設置組不使用QC自帶的測試試組劃分，新增兩兩個基于QC原有有組的新組，分別別為：admin_tester 和 “開發人員”設置測試工作者組設置如下：Admin_tester的的設置基于“TDAdmin”組下，權限設置置為：只對“缺陷”分頁下進進行設置：在“缺陷”頁面下，添加缺缺陷下，取消勾選選“狀態”，因為我們的缺缺陷狀態將使用針針對項目測試所設設置的“缺陷狀態”字段，不再使用“狀態”字段！設置結果如如上圖所示。

15、點擊上圖中的“缺陷數數據隱藏篩選器”：在“可見字段”下，取消勾勾選“狀態”字段。表示該字字段在QC添加缺缺陷時，該字段不不再顯示！如上圖圖所示。在“缺陷”分頁下，“修改改缺陷”欄下，取消勾選“狀態”，因為我們的缺缺陷狀態將使用針針對項目測試所設設置的“缺陷狀態”字段。設置結果果如上圖所示。同同時，在“缺陷數據隱藏篩篩選器”下，在“可見字段”中，取消勾選“狀態”字段。設置開發人員組設置如下：“開發人員”的設置基于于“Developer”組下，權限設置為：只對“缺陷”分頁下進進行設置：取消勾選“添加缺陷”。開發人員不可可以添加缺陷，如果是是自身調試過程中中的缺陷，直接在在開發過程中修改改，如果是測

16、試過過程中，開發人員員發現缺陷，可以以直接告知項目測測試人員，由測試試人員將缺陷提交交至QC。在“修改缺陷”欄下，取消消勾選“狀態”，表示不再使用用該字段，同時，在在“缺陷數據隱藏篩篩選器”下，取消勾選“狀態”字段，如下圖設設置：在“修改缺陷”欄下，進入入“缺陷狀態”設置，開發人員員的具體設置如下下：開發人員可以對“打開開”，“重新打開”，“建議”三種狀態的BUG進進行狀態修改，修修改后的值為圖中中“到”的值。設置項目用戶添加參與該項目的所有有用戶到“項目用戶”欄內， 然后，給給每個用戶定義新新的組，QC的管管理員只使用TDAdmin即即可。測試人員使用“admin_tester”組開發人員使

17、用“開發人人員”組項目經理使用“PM”組其他人員可以使用“Viewer”組。使用到具體組的用戶，不不再添加并列的其其他組，避免造成成實際操作使用QC開展工作作時的混亂。設置工作流添加缺陷字段自定義1用戶組admin_tester下下，設置為：主要是確定沒有勾選“狀態”字段！2用戶組“開發人員員”下，設置為：同樣，主要是確定沒有有勾選“狀態”字段。缺陷詳細信息字段自定定義設置同5.1“添加缺缺陷字段自定義”，確定“admin_tester”和“開發人員”兩個用戶組下的可見字段中，都沒有勾選“狀態”字段。腳本編輯器需求模板腳本在新建需求Requirements_Req_New腳本下，加入代碼為：S

18、ub Requirements_Req_New On Error Resume Next Req_Fields(RQ_REQ_REVIEWED).Value=未審閱 Req_Fields(RQ_REQ_COMMENT).Value=一:測試需求求概述& vbCrLf & _ space(1)& 1.& vbCrLf & _ space(1)& 2.& vbCrLf & _ vbCrLf &二:測試要點分分析& vbCrLf & _ space(1)& 1.& vbCrLf & _ space(1)& 2. On Error GoTo 0End Sub實現內容：在新建需求時，審閱狀狀態默認值為“

19、未審閱”，表示該新建的的需求需要測試負負責人等相關人員員進行需求評審，評評審后，才能將狀狀態置為“已審閱”新建需求下，在需求描描述中，自動加入入描述內容大綱，格格式為：一:測試需求概述1.2.二:測試要點分析1.2.測試計劃模板腳本在新建測試用例“TestPlan_Test_New”腳本下，加入代碼為：Sub TestPlan_Test_New On Error Resume Next Test_Fields(TS_USER_02).Value =未審查 Test_Fields(TS_USER_01).Value =一般 On Error GoTo 0End Sub實現內容：主要是對新增的兩個

20、字字段“用例審查”和“用例優先級”賦默認值。用例例審查的默認值為為“未審查”，表示該用例未未經過評審，由測測試相關負責人進進行用例審查后，置置為“已審查”，則該用例通過過，可以進行下一一步的測試工作?！皟炏燃墶蹦J為一般，如果用例需要優先安排進行測試，則將該用例的優級級設置為“高”。缺陷模板腳本在新建缺陷“Defects_Bug_New”腳本下，加和代碼為：Sub Defects_Bug_New WizardFieldCust_Add 由由向導添加 Bug_Fields(BG_DEV_COMMENTS).Value =1.錯誤分分析:& vbCrLf & _ 2:解決方式: Bug_Field

21、s(BG_USER_01).Value=新建Bug_Fields(BG_PROJECT).Value= Req_Fields(RQ_REQ_PRODUCT).ValueEnd Sub實現內容：確定新建缺陷時，缺陷陷的狀態為“新建”。對新建缺陷時，“注釋釋”中，需要修改缺缺陷的相關開發人人員加入兩個內容容，一是缺陷錯誤誤分析，二是解決決方式。便于進行行缺陷的回歸測試試，便于開發，測測試技術交流。新建缺陷的“項目”值值繼承從新建需求求時選擇的“產品”字段值。需求模塊新建需求新建需求名稱：是必填項，輸入入測試需求的名稱稱。產品：選擇在“自定義義項目列表”中，設置的“所有項目”列表中的列表值值。已審閱

22、：默認已為“未未審閱”。描述：按默認的題綱（需需求概述，要點分分析）進行編寫。需求編寫要求1 需求名稱：要求求和產品需求說明明或技術需求說明明文檔基本一致，轉轉化為測試認為顯顯著的需求名稱。2 描述內容：測試需求概述：基于業業務需求說明書和和技術需求說明書書，轉化為測試需需求信息，寫入新新建需求中。測試要點分析：列出基基于該測試需求概概述下，測試關注注點，指導測試用用例的設計，防止止測試點遺漏，完完善測試用例覆蓋蓋度需求的描述內容編寫，每行文字達到QC默默認的該需求頁面面寬度時，編者應該主動回車換行，便于以以后需求的查看瀏瀏覽。描述語句簡潔，精練，內內容易讀。避免長長語句。測試要點需要特殊注意

23、意的部分，可以使使用“藍色”顏色進行標志。需求樹格式：格式參考為圖所示，每每個需求繼承上一一級需求特征，并并且從“_1”進行編號，同級級的號從“_1”開始累加，下一一級以“_1_1”開始，或者“新內容_1_內內容”開始，保證同級級需求的格式前面面字符串是一致，并并以編號排序。需求編寫：根據項目功功能點復雜度，自自主確定測試需求求樹層次，一般需需求樹為四層，第第四層自動轉化后后為“測試用例”。所以，測試需需求編寫時，一定定要進行必要細化化，方便最后一層層的子需求轉化為為“測試用例”。注： 之所以把編號后后置，是因為編號號到最后一級需求求時，可能編號會會很長，而我們關關注的是需求的內內容，所以，內

24、容容置前，編號置后后。轉換測試轉換測試使用“需求”菜單下“轉換測試”進行操作。自動轉換操作中，轉換換方法選取“將最底層的子需需求轉換為測試”業務組件模塊業務組件介紹這是一個利用QTP與與QC的完美結合合組成的一個體系系架構。它可以輕輕易實現目前比較較流行的三層測試試架構：腳本層，業業務層，數據層相相分離，為開展功功能自動化測試提提供一個高效、穩穩定、測試實現平臺具體體現相關業務人員可以在沒沒有腳本的環境下下組合業務組件，實實現業務流程對業務人員的編程能力力沒有要求，業務務人員只需了解系系統的業務流程，不不用關心具體的腳腳本實現。這一點點也實現了業務層層和腳本層的分離離。一旦某個組件開發完畢畢，

25、即可在不同的的流程中使用該組組件，實現高可復復用性，從而加快快業務流程測試的的速度。明確的角色分工，業務務人員負責流程的的開發、組織；QTP工工程師負責腳本的的開發、維護以及及相應函數庫的開開發、維護。因為實現了腳本的復用用，提高了自動化化開發的效率，無無形中就降低了測測試過程中維護的的時間和成本。工作流程測試使用？因為現在的公司QC版版本為9，現在測測試人員學習并逐逐步使用于測試的的QTP的版本在在9.5以上。所所以，不能創建QTP的的應用域到QC。另外，QTP自動化框框架中的業務，腳腳本，數據分開實實現也可以在公司司原有的框架下進進一步實現，所以以，QC中的“業務組件”模塊可以暫時不不考慮

26、使用。計劃模塊用例編寫導入用例編寫從測試需求中，導入的的用例編寫：在用例“詳細信息”分分頁下，設置“用例審查”為“未審查”，并對“用例優先級”進行設置在用例“設計步驟”分分頁下，添加測試試步驟，步驟中的的描述和預期結果果編寫方式規范，到到頁面寬度時，設設計用例者主動回回車換行上傳用例需要的附件新建用例編寫如果從“測試計劃”模模塊下新建用例，編編寫：測試名稱：應該繼承“文件夾”的名稱，或者和和同級的其他從需需求導入的用例名名稱保持結構一致致！在用例“詳細信息”分分頁下，設置“用例審查”為“未審查”，并對“用例優先級”進行設置（默認認應該已經設置）在用例“設計步驟”分分頁下，添加測試試步驟，步驟中

27、的的描述和預期結果果編寫方式規范，到到頁面寬度時，設設計用例者主動回回車換行上傳用例需要的附件在用例“需求覆蓋”分分頁下，選擇需求求，手動把用例關關聯到相應的需求求。用例編寫要求每一個文件夾下的用例例格式是一致的，按按編號+內容進行行排序。如下圖：用例設計“步驟名稱”簡短，“描述”和“預期結果”編寫到達頁面寬寬度，主動回車換換行，描述和預期期結果對應，有參參數輸入就必須有有輸出結果一種描述或輸入，有多多種測試期望結果果，應該把測試步步驟分開設計編寫寫一種描述或輸入，影響響到多個業務或功功能模塊，則設計計另外測試用例進進行測試步驟設計計。執行測試用例時，按“用例優先級”進行。鏈接缺陷QC中的每個

28、測試缺陷陷都有它的源，源源在測試需求，經經過測試計劃中的的用例，測試實驗驗室對測試用例的的執行，最終會產產生一個新的缺陷陷。因為測試需求自動轉化化為測試計劃和用用例，測試實驗室室執行測試浪費人人力和時間，且自自動生成的缺陷內內容中，有很多冗冗長的無用信息，使使缺陷看似“寵大”，易讀性差所以，我們公司的缺陷陷出處，即“源”應該設置在測試試用例中。具體操操作：在每個測試用例中的“鏈接的缺陷”分頁下，點擊“添加和鏈接缺陷陷”，進行缺陷添加加操作。注：QC中所有的缺陷陷新增，都應該是是以測試用例為源源進行新增！實驗室模塊注：測試實驗室模塊主主要控制測試執行行，包括手工測試試用例以及其他測測試用例，如自

29、動動化用例等。因為為現階段公司的測測試執行工作一般般由測試用例編寫寫人員進行。并非非要指定測試員去去執行用例，所以以，對實驗室可以以不作使用。節約約時間成本，人力力成本。同時，從實驗室導出的的缺陷描述，本身身有很多冗長的沒沒用信息，缺陷查查看也不方便，所所以也不建議從實實驗室導出生成缺缺陷。而直接從相相關測試用例直接接去生成，關聯缺缺陷！缺陷模塊新增缺陷新增缺陷入口為QC“計劃”模塊下的測試用用例（鏈接的缺陷陷分頁面下）這樣新增缺陷目的在于于：便于缺陷和需求，用例例的鏈接。方便查查找缺陷出處避免測試人員測試交叉叉功能用例，造成成的缺陷提交重復復的問題，因為更更方便通過用例查查看原有鏈接缺陷陷其

30、他部門查看缺陷產生生原因更易明白。缺陷編寫要求結合公司原有的缺陷流流程管理規范以及及項目測試實際應應用， 在缺陷編編寫方面做以下要要求：缺陷“摘要”書寫：用例文件夾名-測試試用例名-編號如：節點-上傳競爭爭性談判文件_1_單個上傳-001，其中中，“節點”是該用例所在的的文件夾的名稱，“上傳競爭性談判文件_1_單個上傳”是測試用例名，“001”是該用例下的缺陷編號，表示這是該用例的第一個缺陷。缺陷“嚴重程度”，缺缺陷“優先級”，按QC原有設設置，在新建缺陷陷時，測試人員根根據個人經驗選擇擇不同級別，最終終完成缺陷提交，測測試負責人進行缺缺陷審查時，再進一步確確定缺陷級別是否否合理，并把缺陷陷狀

31、態從“新建”狀態轉為“打開”狀態。缺陷“描述”，第一行：測試 用例名問題描述關鍵字字其中，“測試 用例名”是新增缺陷時，從從用例自動關聯過過來的字符串，后后面的“問題描述關鍵字字”則要測試人員根根據這個缺陷內容容書寫如：“測試 上上傳競爭性談判文文件_1_單個上傳上傳失敗”表示用例“上傳競爭性性談判文件_1_單個上傳”中，存在上傳失失敗的缺陷！缺陷“描述”1第二行往下，具體體描述缺陷產生步步驟，按1，2，3如如此步驟分行進行行描述，每行文字字達到缺陷頁面默默認寬度時，缺陷陷創建人員主動回回車換車；2描述要求文字精練練，避免使用過長長語句，缺陷出處處描述清晰；3實際結果（實際缺缺陷問題）可以用用“紅色”顏色字體標志。缺陷“注釋”，測試人人員新建缺陷時，不不關注“注釋”，開發人員修改改后，需要根據注注釋要求，填寫注注釋并提交，測試試人員在進行缺陷陷驗證時，需關注注“注釋”內容并進行總結結。缺陷范例摘要：狀態節點-廢廢棄專家-001測試: 狀態節點-廢棄專家-