QC使用流程定制及操作規(guī)范

1、時間狀態(tài)修訂人2009-11-2初稿張彥彬必聯(lián)（北京）電子商務信息技術有限公司2021年12月以及操作說明QC使用流程定制目 錄第一章 管理員定義11. 自定義項目列表11.1 針對QC中的“需求”模塊11.2 針對QC中的“測試計劃”模塊21.3 針對QC中的“缺陷”模塊22. 自定義項目實體32.1 “缺陷”實體修改32.2 “TEST”實體修改43. 設置組63.1 設置測試工作者組63.2 設置開發(fā)人員組84. 設置項目用戶95. 設置工作流105.1 添加缺陷字段自定義105.2 缺陷詳細信息字段自定義115.3 腳本編輯器11第二章 需求模塊141. 新建需求141.1 新建需求1

2、41.2 需求編寫要求142. 轉換測試15第三章 業(yè)務組件模塊171. 業(yè)務組件介紹172. 具體體現(xiàn)173. 工作流程184. 測試使用？18第四章 計劃模塊191. 用例編寫191.1 導入用例編寫191.2 新建用例編寫191.3 用例編寫要求192. 鏈接缺陷20第五章 實驗室模塊21第六章 缺陷模塊221. 新增缺陷222. 缺陷編寫要求223. 缺陷范例234. 界面顯示235. 缺陷狀態(tài)控制245.1 測試人員控制缺陷狀態(tài)245.2 測試負責人控制缺陷狀態(tài)255.3 開發(fā)人員控制缺陷狀態(tài)25第七章 QC綜述261. 流程綜述262. 指導意見26iii第一章 管理員定義1. 自

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

4、列表“審閱狀態(tài)”：列表項為“未審閱”和“已審閱”，默認為“未審閱”1.2 針對QC中的“測試計劃”模塊增加兩個列表，用于新建測試用例。1新增“用例審查“列表列表項為兩項：“未審查”和“已審查”。默認為“未審查”2新增“用例優(yōu)先級”列表列表項為三項：“低”“一般”“高”，默認為“一般”1.3 針對QC中的“缺陷”模塊QC中自定義的缺陷狀態(tài)有可能一些狀態(tài)值不符合測試整體過程的要求，以及對缺陷流程進行控制，所以，自定義一個“bug狀態(tài)”的列表，具體如圖所示：列表項中包括測試過程中缺陷的所有狀態(tài)：新建，打開，已修改，非BUG，已復測，已關閉，重新打開，暫不處理，建議。2. 自定義項目實體2.1 “缺陷

5、”實體修改1. 在“系統(tǒng)字段”中，點擊“狀態(tài)”進入字段設置，把“必填”，“驗證值”的勾選去掉！以后項目測試過程中的缺陷的狀態(tài)，都不再使用該QC提供的該字段。2. 新增“用戶字段”缺陷狀態(tài)字段名記錄為“BG_USER_01”，字段類型為“查找列表”，選中“必填”查找列表選擇在自定義項目列表時新建的“bug狀態(tài)”列表以后項目測試過程中的缺陷的狀態(tài)變化都用此字段中的值來表示！2.2 “TEST”實體修改新增用戶字段為“* 用例審查”，“* 用例優(yōu)先級”如下兩圖所示：其中：“* 用例審查”字段名稱“TS_USER_02”，“查找列表”使用之前在“自定義項目列表”中新增的“用例審查”；“* 用例優(yōu)先級”

6、字段名稱“TS_USER_01”，“查找列表”使用之前在“自定義項目列表”中新增的“用例優(yōu)先級”；3. 設置組不使用QC自帶的測試組劃分，新增兩個基于QC原有組的新組，分別為：admin_tester 和 “開發(fā)人員”3.1 設置測試工作者組設置如下：Admin_tester的設置基于“TDAdmin”組下，權限設置為：只對“缺陷”分頁下進行設置：在“缺陷”頁面下，添加缺陷下，取消勾選“狀態(tài)”，因為我們的缺陷狀態(tài)將使用針對項目測試所設置的“缺陷狀態(tài)”字段，不再使用“狀態(tài)”字段！設置結果如上圖所示。點擊上圖中的“缺陷數(shù)據(jù)隱藏篩選器”：在“可見字段”下，取消勾選“狀態(tài)”字段。表示該字段在QC添加缺

7、陷時，該字段不再顯示！如上圖所示。在“缺陷”分頁下，“修改缺陷”欄下，取消勾選“狀態(tài)”，因為我們的缺陷狀態(tài)將使用針對項目測試所設置的“缺陷狀態(tài)”字段。設置結果如上圖所示。同時，在“缺陷數(shù)據(jù)隱藏篩選器”下，在“可見字段”中，取消勾選“狀態(tài)”字段。3.2 設置開發(fā)人員組設置如下：“開發(fā)人員”的設置基于“Developer”組下，權限設置為：只對“缺陷”分頁下進行設置：1 取消勾選“添加缺陷”。開發(fā)人員不可以添加缺陷，如果是自身調試過程中的缺陷，直接在開發(fā)過程中修改，如果是測試過程中，開發(fā)人員發(fā)現(xiàn)缺陷，可以直接告知項目測試人員，由測試人員將缺陷提交至QC。2 在“修改缺陷”欄下，取消勾選“狀態(tài)”，表

8、示不再使用該字段，同時，在“缺陷數(shù)據(jù)隱藏篩選器”下，取消勾選“狀態(tài)”字段，如下圖設置：3 在“修改缺陷”欄下，進入“缺陷狀態(tài)”設置，開發(fā)人員的具體設置如下：開發(fā)人員可以對“打開”，“重新打開”，“建議”三種狀態(tài)的BUG進行狀態(tài)修改，修改后的值為圖中“到”的值。4. 設置項目用戶添加參與該項目的所有用戶到“項目用戶”欄內， 然后，給每個用戶定義新的組，QC的管理員只使用TDAdmin即可。測試人員使用“admin_tester”組開發(fā)人員使用“開發(fā)人員”組項目經理使用“PM”組其他人員可以使用“Viewer”組。使用到具體組的用戶，不再添加并列的其他組，避免造成實際操作使用QC開展工作時的混亂。

9、5. 設置工作流5.1 添加缺陷字段自定義1用戶組admin_tester下，設置為：主要是確定沒有勾選“狀態(tài)”字段！2用戶組“開發(fā)人員”下，設置為：同樣，主要是確定沒有勾選“狀態(tài)”字段。5.2 缺陷詳細信息字段自定義設置同5.1“添加缺陷字段自定義”，確定“admin_tester”和“開發(fā)人員”兩個用戶組下的可見字段中，都沒有勾選“狀態(tài)”字段。5.3 腳本編輯器5.3.1 需求模板腳本在新建需求Requirements_Req_New腳本下，加入代碼為：Sub Requirements_Req_New On Error Resume Next Req_Fields("RQ_REQ

10、_REVIEWED").Value="未審閱" Req_Fields("RQ_REQ_COMMENT").Value="一:測試需求概述"& vbCrLf & _ space(1)& "1."& vbCrLf & _ space(1)& "2."& vbCrLf & _ vbCrLf &"二:測試要點分析"& vbCrLf & _ space(1)& "1.&q

11、uot;& vbCrLf & _ space(1)& "2." On Error GoTo 0End Sub實現(xiàn)內容：1， 在新建需求時，審閱狀態(tài)默認值為“未審閱”，表示該新建的需求需要測試負責人等相關人員進行需求評審，評審后，才能將狀態(tài)置為“已審閱”2， 新建需求下，在需求描述中，自動加入描述內容大綱，格式為：一:測試需求概述1.2.二:測試要點分析1.2.5.3.2 測試計劃模板腳本在新建測試用例“TestPlan_Test_New”腳本下，加入代碼為：Sub TestPlan_Test_New On Error Resume Next Test

12、_Fields("TS_USER_02").Value ="未審查" Test_Fields("TS_USER_01").Value ="一般" On Error GoTo 0End Sub實現(xiàn)內容：1 主要是對新增的兩個字段“用例審查”和“用例優(yōu)先級”賦默認值。用例審查的默認值為“未審查”，表示該用例未經過評審，由測試相關負責人進行用例審查后，置為“已審查”，則該用例通過，可以進行下一步的測試工作。“優(yōu)先級”默認為一般，如果用例需要優(yōu)先安排進行測試，則將該用例的優(yōu)級級設置為“高”。5.3.3 缺陷模板腳本在新建缺

13、陷“Defects_Bug_New”腳本下，加和代碼為：Sub Defects_Bug_New WizardFieldCust_Add ' 由向導添加 Bug_Fields("BG_DEV_COMMENTS").Value ="1.錯誤分析:"& vbCrLf & _ "2:解決方式:" Bug_Fields("BG_USER_01").Value="新建"Bug_Fields("BG_PROJECT").Value= Req_Fields("

14、;RQ_REQ_PRODUCT").ValueEnd Sub實現(xiàn)內容：1 確定新建缺陷時，缺陷的狀態(tài)為“新建”。2 對新建缺陷時，“注釋”中，需要修改缺陷的相關開發(fā)人員加入兩個內容，一是缺陷錯誤分析，二是解決方式。便于進行缺陷的回歸測試，便于開發(fā)，測試技術交流。3 新建缺陷的“項目”值繼承從新建需求時選擇的“產品”字段值。第二章 需求模塊1. 新建需求1.1 新建需求名稱：是必填項，輸入測試需求的名稱。產品：選擇在“自定義項目列表”中，設置的“所有項目”列表中的列表值。已審閱：默認已為“未審閱”。描述：按默認的題綱（需求概述，要點分析）進行編寫。1.2 需求編寫要求1 需求名稱：要求

15、和產品需求說明或技術需求說明文檔基本一致，轉化為測試認為顯著的需求名稱。2 描述內容：Ø 測試需求概述：基于業(yè)務需求說明書和技術需求說明書，轉化為測試需求信息，寫入新建需求中。Ø 測試要點分析：列出基于該測試需求概述下，測試關注點，指導測試用例的設計，防止測試點遺漏，完善測試用例覆蓋度Ø 需求的描述內容編寫，每行文字達到QC默認的該需求頁面寬度時，編者應該主動回車換行，便于以后需求的查看瀏覽。Ø 描述語句簡潔，精練，內容易讀。避免長語句。Ø 測試要點需要特殊注意的部分，可以使用“藍色”顏色進行標志。4 需求樹格式：格式參考為圖所示，每個需求繼承

16、上一級需求特征，并且從“_1”進行編號，同級的號從“_1”開始累加，下一級以“_1_1”開始，或者“新內容_1_內容”開始，保證同級需求的格式前面字符串是一致，并以編號排序。5 需求編寫：根據(jù)項目功能點復雜度，自主確定測試需求樹層次，一般需求樹為四層，第四層自動轉化后為“測試用例”。所以，測試需求編寫時，一定要進行必要細化，方便最后一層的子需求轉化為“測試用例”。注： 之所以把編號后置，是因為編號到最后一級需求時，可能編號會很長，而我們關注的是需求的內容，所以，內容置前，編號置后。2. 轉換測試轉換測試使用“需求”菜單下“轉換測試”進行操作。自動轉換操作中，轉換方法選取“將最底層的子需求轉換為

17、測試”第三章 業(yè)務組件模塊1. 業(yè)務組件介紹這是一個利用QTP與QC的完美結合組成的一個體系架構。它可以輕易實現(xiàn)目前比較流行的三層測試架構：腳本層，業(yè)務層，數(shù)據(jù)層相分離，為開展功能自動化測試提供一個高效、穩(wěn)定、測試實現(xiàn)平臺2. 具體體現(xiàn)Ø 相關業(yè)務人員可以在沒有腳本的環(huán)境下組合業(yè)務組件，實現(xiàn)業(yè)務流程Ø 對業(yè)務人員的編程能力沒有要求，業(yè)務人員只需了解系統(tǒng)的業(yè)務流程，不用關心具體的腳本實現(xiàn)。這一點也實現(xiàn)了業(yè)務層和腳本層的分離。Ø 一旦某個組件開發(fā)完畢，即可在不同的流程中使用該組件，實現(xiàn)高可復用性，從而加快業(yè)務流程測試的速度。Ø 明確的角色分工，業(yè)務人員負責流

18、程的開發(fā)、組織；QTP工程師負責腳本的開發(fā)、維護以及相應函數(shù)庫的開發(fā)、維護。Ø 因為實現(xiàn)了腳本的復用，提高了自動化開發(fā)的效率，無形中就降低了測試過程中維護的時間和成本。3. 工作流程4. 測試使用？因為現(xiàn)在的公司QC版本為9，現(xiàn)在測試人員學習并逐步使用于測試的QTP的版本在9.5以上。所以，不能創(chuàng)建QTP的應用域到QC。另外，QTP自動化框架中的業(yè)務，腳本，數(shù)據(jù)分開實現(xiàn)也可以在公司原有的框架下進一步實現(xiàn)，所以，QC中的“業(yè)務組件”模塊可以暫時不考慮使用。第四章 計劃模塊1. 用例編寫1.1 導入用例編寫從測試需求中，導入的用例編寫：Ø 在用例“詳細信息”分頁下，設置“用例審

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

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

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

22、工作一般由測試用例編寫人員進行。并非要指定測試員去執(zhí)行用例，所以，對實驗室可以不作使用。節(jié)約時間成本，人力成本。同時，從實驗室導出的缺陷描述，本身有很多冗長的沒用信息，缺陷查看也不方便，所以也不建議從實驗室導出生成缺陷。而直接從相關測試用例直接去生成，關聯(lián)缺陷！第六章 缺陷模塊1. 新增缺陷新增缺陷入口為QC“計劃”模塊下的測試用例（鏈接的缺陷分頁面下）這樣新增缺陷目的在于：1 便于缺陷和需求，用例的鏈接。方便查找缺陷出處2 避免測試人員測試交叉功能用例，造成的缺陷提交重復的問題，因為更方便通過用例查看原有鏈接缺陷3 其他部門查看缺陷產生原因更易明白。2. 缺陷編寫要求結合公司原有的缺陷流程管

23、理規(guī)范以及項目測試實際應用， 在缺陷編寫方面做以下要求：Ø 缺陷“摘要”書寫：用例文件夾名-測試用例名-編號如：節(jié)點-上傳競爭性談判文件_1_單個上傳-001，其中，“節(jié)點”是該用例所在的文件夾的名稱，“上傳競爭性談判文件_1_單個上傳”是測試用例名，“001”是該用例下的缺陷編號，表示這是該用例的第一個缺陷。Ø 缺陷“嚴重程度”，缺陷“優(yōu)先級”，按QC原有設置，在新建缺陷時，測試人員根據(jù)個人經驗選擇不同級別，最終完成缺陷提交，測試負責人進行缺陷審查時，再進一步確定缺陷級別是否合理，并把缺陷狀態(tài)從“新建”狀態(tài)轉為“打開”狀態(tài)。Ø 缺陷“描述”，第一行：測試 用例名

24、-問題描述關鍵字其中，“測試 用例名”是新增缺陷時，從用例自動關聯(lián)過來的字符串，后面的“問題描述關鍵字”則要測試人員根據(jù)這個缺陷內容書寫如：“測試 上傳競爭性談判文件_1_單個上傳上傳失敗”表示用例“上傳競爭性談判文件_1_單個上傳”中，存在上傳失敗的缺陷！Ø 缺陷“描述”1第二行往下，具體描述缺陷產生步驟，按1，2，3如此步驟分行進行描述，每行文字達到缺陷頁面默認寬度時，缺陷創(chuàng)建人員主動回車換車；2描述要求文字精練，避免使用過長語句，缺陷出處描述清晰；3實際結果（實際缺陷問題）可以用“紅色”顏色字體標志。Ø 缺陷“注釋”，測試人員新建缺陷時，不關注“注釋”，開發(fā)人員修改后

25、，需要根據(jù)注釋要求，填寫注釋并提交，測試人員在進行缺陷驗證時，需關注“注釋”內容并進行總結。3. 缺陷范例摘要：狀態(tài)節(jié)點-廢棄專家-001測試: 狀態(tài)節(jié)點-廢棄專家-缺少“廢棄專家”節(jié)點1 執(zhí)行"抽取談判專家"提交，查看節(jié)點展現(xiàn)情況2錯誤描述：節(jié)點"抽取談判專家"提交后節(jié)點"廢棄專家"未出現(xiàn)。摘要：評標-抽取談判專家-001測試: 抽取談判專家-視圖頁面報錯1 節(jié)點"抽取談判專家"完成，檢查視圖頁面數(shù)據(jù)2視圖-評標頁簽頁面報錯。提示"VelocityViewServlet： Error processing the template"（參見項目編號:0703-095