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

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

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

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

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

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

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

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

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

9、5. 設(shè)置工作流5.1 添加缺陷字段自定義1用戶組admin_tester下，設(shè)置為：主要是確定沒有勾選“狀態(tài)”字段！2用戶組“開發(fā)人員”下，設(shè)置為：同樣，主要是確定沒有勾選“狀態(tài)”字段。5.2 缺陷詳細(xì)信息字段自定義設(shè)置同5.1“添加缺陷字段自定義”，確定“admin_tester”和“開發(fā)人員”兩個(gè)用戶組下的可見字段中，都沒有勾選“狀態(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 &"二:測試要點(diǎn)分析"& vbCrLf & _ space(1)& "1.&q

11、uot;& vbCrLf & _ space(1)& "2." On Error GoTo 0End Sub實(shí)現(xiàn)內(nèi)容：1， 在新建需求時(shí)，審閱狀態(tài)默認(rèn)值為“未審閱”，表示該新建的需求需要測試負(fù)責(zé)人等相關(guān)人員進(jìn)行需求評(píng)審，評(píng)審后，才能將狀態(tài)置為“已審閱”2， 新建需求下，在需求描述中，自動(dòng)加入描述內(nèi)容大綱，格式為：一:測試需求概述1.2.二:測試要點(diǎn)分析1.2.5.3.2 測試計(jì)劃模板腳本在新建測試用例“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實(shí)現(xiàn)內(nèi)容：1 主要是對(duì)新增的兩個(gè)字段“用例審查”和“用例優(yōu)先級(jí)”賦默認(rèn)值。用例審查的默認(rèn)值為“未審查”，表示該用例未經(jīng)過評(píng)審，由測試相關(guān)負(fù)責(zé)人進(jìn)行用例審查后，置為“已審查”，則該用例通過，可以進(jìn)行下一步的測試工作。“優(yōu)先級(jí)”默認(rèn)為一般，如果用例需要優(yōu)先安排進(jìn)行測試，則將該用例的優(yōu)級(jí)級(jí)設(shè)置為“高”。5.3.3 缺陷模板腳本在新建缺

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

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

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

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

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

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

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

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

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

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

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

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

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