TestDirector測試管理工具試用及評估報(bào)告-OPEN.doc

技 術(shù) 文 件 技術(shù)文件名稱：MI TestDirector測試管理工具試用及評估報(bào)告 技術(shù)文件編號： 版 本：V1.0 文件質(zhì)量等級： 共 26 頁（包括封面） 擬 制 鄧巨峰 程琳 張平 陸建濃 謝華 審 核 會 簽 標(biāo)準(zhǔn)化 批 準(zhǔn) 深圳市中興通訊股份有限公司目錄目錄21試點(diǎn)實(shí)施的背景32試點(diǎn)實(shí)施內(nèi)容和目標(biāo)33試點(diǎn)項(xiàng)目介紹44TestDirector工具簡介54.1TestDirector工作流圖54.2TestDirector主要組成部分65需求（Test Inputs）75.1現(xiàn)狀描述75.2TestDirector 需求管理76測試用例庫116.1測試用例設(shè)計(jì)現(xiàn)狀描述116.2測試用例（Test Case）管理116.3自動化測試腳本136.4測試規(guī)程文檔的生成147測試執(zhí)行(Test Set)157.1現(xiàn)狀描述157.2TD 測試執(zhí)行158故障跟蹤189測試評價189.1測試結(jié)果日志189.2測試覆蓋率189.3測試報(bào)告生成1810工具特性1811總體評價1812典型問題解決方案1913試點(diǎn)中存在的問題和解決方案221 試點(diǎn)實(shí)施的背景CMM3對測試組織提出了測試流程一致化、標(biāo)準(zhǔn)化、更高的過程管理的要求。目前我們的測試工作中有幾個方面需要提高：1) 測試人員對需求、測試計(jì)劃與測試設(shè)計(jì)、測試實(shí)施、測試評價這一完整測試生命周期的認(rèn)識尚不清晰，缺乏統(tǒng)一的測試過程管理平臺，導(dǎo)致測試具有一定的盲目性，測試工作開展地較被動；2) 測試效率和測試執(zhí)行質(zhì)量完全依賴于個人的技術(shù)水平和責(zé)任心，測試過程的可控性較差；3) 好的測試設(shè)計(jì)思想和技術(shù)沒有被集中地管理起來，測試過程中積累的方法和經(jīng)驗(yàn)沒有被有效地固化下來，不利于測試工作的長遠(yuǎn)發(fā)展。4) 研發(fā)流程中系統(tǒng)生命周期各階段是相互關(guān)聯(lián)的。而目前公司的情況是信息分散，主要以文檔的形式存在，使用不方便。有部分階段也使用了管理支撐工具，但采用的工具分散，不能達(dá)到信息的一致性和信息共享。5) 計(jì)劃安排，進(jìn)度安排，工作量考慮等沒有參考數(shù)據(jù)。系統(tǒng)質(zhì)量，系統(tǒng)交付使用時間安排沒有量化數(shù)據(jù)作為支撐。這些也需要有效的測試管理和信息統(tǒng)計(jì)功能。因此，測試過程管理勢在必行，我們引進(jìn)了業(yè)界著名的測試過程管理工具Rational TestManage和MI TestDirector，將它們分別在2個項(xiàng)目中進(jìn)行試用，期望通過評估的實(shí)踐，不僅對這兩個工具的試用情況做出客觀的評估，而且可以從它們中吸取先進(jìn)的測試過程管理思想，為部門的測試過程管理改進(jìn)工作提供依據(jù)。比較的結(jié)果見附件： 經(jīng)過對比和分析，我們選擇了TestDirector工具作為我們部門的測試流程管理工具，并在統(tǒng)一網(wǎng)管測試項(xiàng)目中全面采用。下面介紹我們對這個工具使用情況。文后還有TestDirector工具和TestManager工具的詳細(xì)比較結(jié)果供參考。2 試點(diǎn)實(shí)施內(nèi)容和目標(biāo)1) 描述在TestDirector中測試生命周期是如何體現(xiàn)的，以此作為測試過程管理規(guī)范化的理論依據(jù)，闡明TestDirector作為測試管理平臺工具的管理特性。2) 制訂需求，并建立需求和測試用例的跟蹤關(guān)系考察TD能否簡化建立測試用例矩陣工作、能否較方便地維護(hù)需求及追蹤關(guān)系。3) 實(shí)現(xiàn)測試用例的設(shè)計(jì)功能考察TD能否滿足不同類型系統(tǒng)對測試用例描述的要求。能否使用TD對測試規(guī)程和用例進(jìn)行評審和討論、能否指導(dǎo)實(shí)際的測試工作。4) 測試任務(wù)制定、分配和執(zhí)行考察TD能否符合實(shí)際測試活動的要求，靈活方便的安排測試活動。5) 測試規(guī)程等文檔的生成考察TD能否很方便的自動生成文檔管理過程所需的測試規(guī)程等文檔、并能根據(jù)公司的文檔模板進(jìn)行定制。6) 測試過程數(shù)據(jù)分析與統(tǒng)計(jì)功能考察能否使用TD對測試設(shè)計(jì)、執(zhí)行過程中的所有量化信息進(jìn)行分析統(tǒng)計(jì)，包括測試用例/需求覆蓋率統(tǒng)計(jì)、測試人員設(shè)計(jì)測試用例過程數(shù)據(jù)統(tǒng)計(jì)、測試人員執(zhí)行測試過程數(shù)據(jù)統(tǒng)計(jì)、被測對象的測試結(jié)果信息統(tǒng)計(jì)等。7) 通過TD和現(xiàn)有的需求關(guān)聯(lián)工具RP、故障管理工具CQ等進(jìn)行集成，考察TD是否能夠?qū)崿F(xiàn)測試部測試工作流程化、制度化，達(dá)到CMM3所要求的標(biāo)準(zhǔn)流程要求。3 試點(diǎn)項(xiàng)目介紹我們主要在統(tǒng)一網(wǎng)管測試組全面采用TD測試管理工具，涉及的項(xiàng)目為網(wǎng)絡(luò)層網(wǎng)管系統(tǒng)ZXUMS N100 V1.0.0/V1.0.1/V1.0.2和網(wǎng)元層網(wǎng)管系統(tǒng)ZXUMS E100 V1.1.4，后來，ZXA10和UAS5000等項(xiàng)目也開始使用TD V7.2版本創(chuàng)建了自己的測試管理流程和測試用例庫。4 TestDirector工具簡介該工具在一個整體WEB系統(tǒng)中提供并集成了需求管理、測試計(jì)劃、測試日程控制以及測試執(zhí)行和測試故障跟蹤等功能。加速測試流程。建立清晰統(tǒng)一的測試過程管理視圖。TestDirector消除組織間、地域間的障礙，讓測試人員、開發(fā)人員和其它人員通過統(tǒng)一的數(shù)據(jù)倉庫，互通測試信息，將測試過程流水作業(yè)，作為統(tǒng)一的界面完成。4.1 TestDirector工作流圖TestDirector工作流支持如下的測試活動： 需求管理 測試計(jì)劃制定； 測試用例設(shè)計(jì)； 測試部署和實(shí)施； 測試過程執(zhí)行； 測試過程評價。 測試故障跟蹤。以上的每一個活動都有輸入、輸出項(xiàng)，如下圖所示。上述的測試流程描述的一個單次迭代的測試生命周期如下圖所示：圖 測試生命周期4.2 TestDirector主要組成部分TestDirector 主要由幾部分組成n 需求管理：定義需求條目與范圍，定義測試主題與項(xiàng)目，分析需求。n 測試用例設(shè)計(jì)：設(shè)計(jì)測試計(jì)劃。定義測試目標(biāo)與測試策略，將測試計(jì)劃分組劃分為不同部分。設(shè)計(jì)測試用例，關(guān)聯(lián)自動化測試腳本，將測試用例與需求關(guān)聯(lián)。n 測試計(jì)劃和執(zhí)行：設(shè)計(jì)測試任務(wù)，分配和部署測試過程，執(zhí)行測試，分析測試結(jié)果。n 故障跟蹤；增加故障，設(shè)置修改級別，修改故障，分析故障數(shù)據(jù)。 目前我們采用研究所原有的CQ作為故障跟蹤管理工具，沒有采用TD本身自帶的故障管理流程。5 需求（Test Inputs）對于完整的系統(tǒng)測試，我們首先需要編制該系統(tǒng)所有待測項(xiàng)目的檢查單（checklist），也就是首先必須明確被測系統(tǒng)的功能，明確測試的需求。采用的的途徑主要包括：設(shè)計(jì)原型；軟件bulids；功能說明書；需求；虛擬模型；Microsoft excel 電子表單；源代碼文件；變更需求等。5.1 現(xiàn)狀描述目前公司對需求概念還比較模糊，沒有明確規(guī)范對需求工作的要求。目前研究所的項(xiàng)目采用RequisitePro作為需求管理工具。在Requsitepro中建立單獨(dú)的測試用例庫，內(nèi)容包括的是測試用例的簡單列表。也就是說在測試工作流程中還沒有關(guān)于需求的概念，而直接以開發(fā)部建立的需求庫作為需求來使用。采用RequisitePro工具的關(guān)聯(lián)功能，靠手工去維護(hù)測試用例和需求的關(guān)聯(lián)關(guān)系。從我們的實(shí)際使用情況看，RP對原始需求、用戶需求和系統(tǒng)需求的管理還是比較有效的，但是在RP工具中進(jìn)行測試用例的管理的效果并不理想。在TD中提出了需求的概念，并在TD中管理測試用例及其與需求的關(guān)聯(lián)關(guān)系。既體現(xiàn)了以需求為依據(jù)進(jìn)行測試用例設(shè)計(jì)、執(zhí)行和評估的思想，又便于測試用例在整個測試工作過程中的動態(tài)管理，這些優(yōu)點(diǎn)是RP中所無法實(shí)現(xiàn)的。5.2 TestDirector 需求管理在TestDirector 的工作流程中，將需求管理作為測試流程的起點(diǎn)。系統(tǒng)的需求驅(qū)動整個測試過程，指導(dǎo)之后的測試計(jì)劃的設(shè)計(jì)、測試用例的設(shè)計(jì)等等。另外測試人員還可以根據(jù)應(yīng)用需求自動生成測試用例。提供直觀的機(jī)制將需求與測試用例，測試結(jié)果和報(bào)告的錯誤聯(lián)系起來，確保完全的測試覆蓋率。下面分別從不同的方面闡述該工具的需求管理功能。5.2.1 需求管理工作流程a) 定義測試范圍：檢查應(yīng)用文檔，確定測試范圍測試目標(biāo)、目的和測試策略。b) 創(chuàng)建需求：建立一個覆蓋所有需求的需求樹（數(shù)據(jù)可以通過Word、Excel中導(dǎo)入，需要安裝相應(yīng)的宏）。c) 細(xì)化需求：對于需求樹上的每一個需求，進(jìn)行細(xì)化。描述每個需求，分配一個優(yōu)先級，并添加必要的附件。d) 分析需求：生成報(bào)告和圖表幫助分析你的需求。檢查你的需求確保他們滿足測試范圍。5.2.2 需求的屬性和內(nèi)容對需求內(nèi)容的描述項(xiàng)目大體有：需求內(nèi)容描述，需求類型，需求重要程度，需求風(fēng)險(xiǎn)描述，需求狀態(tài)跟蹤，需求所對應(yīng)測試用例執(zhí)行狀態(tài)，需求測試覆蓋率情況，需求內(nèi)容修改日志，使用人日志等描述。我們結(jié)合自身項(xiàng)目的情況，對TD提供的缺省模板進(jìn)行少量定制，完全可以達(dá)到上述要求。下面是自定義模板的需求內(nèi)容窗口：5.2.3 需求信息的管理需求可按照其父子包含關(guān)系層次劃分,形成需求樹。選擇需求樹上的需求，在窗口的右半部分中自動現(xiàn)實(shí)該需求的信息，包括該需求的詳細(xì)說明，與該需求關(guān)聯(lián)的測試用例，需求關(guān)聯(lián)的各種附件。5.2.4 需求內(nèi)容的來源n 手工輸入方式。直接輸入需求的名稱、內(nèi)容、優(yōu)先級等屬性。n 支持文檔導(dǎo)入，TD提供相應(yīng)的插件，可以從Word，Excel等需求文檔中導(dǎo)入需求內(nèi)容。n 支持RequisitePro 庫等第三方需求管理工具信息的集成導(dǎo)入。對于采用RP進(jìn)行用戶需求、系統(tǒng)需求管理的項(xiàng)目，可以采用這種方式將需求成批導(dǎo)入，再經(jīng)過分析、整理和補(bǔ)充之后，形成需求。n 需求文檔可以作為需求內(nèi)容的附件（Attachment），還可以將其它形式的需求內(nèi)容，例如File，URL，snapshot等形式內(nèi)容作為附件添加到需求內(nèi)容中。 5.2.5 需求與測試用例的關(guān)聯(lián)與跟蹤可將需求與測試用例進(jìn)行關(guān)聯(lián)操作。同時測試用例也和測試故障關(guān)聯(lián)。這樣的話，可在測試流程的各階段跟蹤需求。如果需求有改變，可以直接確定哪些測試用例和測試故障有影響，以及哪些人需要負(fù)責(zé)。操作方式：即可在需求管理模塊中，選擇測試用例與需求關(guān)聯(lián)。也可在測試計(jì)劃管理模塊中，選擇需求與測試計(jì)劃關(guān)聯(lián)。n 提供直觀的機(jī)制將需求和測試用例，測試結(jié)果和報(bào)告的測試錯誤聯(lián)系起來，確保完全的測試覆蓋率。n 根據(jù)需求自動生成測試用例。測試人員可根據(jù)需求自動生成測試用例。即可以根據(jù)需求列表自動生成測試計(jì)劃中測試用例列表，也可以單獨(dú)生成一個測試用例。5.2.6 需求狀態(tài)需求的覆蓋狀態(tài)（Cover status）共有5種狀態(tài)，這些狀態(tài)是通過是否與測試用例關(guān)聯(lián)，已經(jīng)所關(guān)聯(lián)的測試用例的狀態(tài)來自動決定的，設(shè)計(jì)人員一般不需要人工修改。n 未覆蓋狀態(tài)（no covered）：該需求未與任何測試用例關(guān)聯(lián)。n 未完成狀態(tài)（no completed）：與該需求關(guān)聯(lián)的測試用例尚未設(shè)計(jì)完畢。n 未運(yùn)行狀態(tài)（no run）：與該需求關(guān)聯(lián)的測試用例尚未運(yùn)行。n 通過狀態(tài)（passed）：與此需求關(guān)聯(lián)的測試用例執(zhí)行成功。n 失敗狀態(tài)（failed）：與此需求關(guān)聯(lián)的測試用例執(zhí)行失敗。下圖顯示的為對需求的當(dāng)前狀態(tài)進(jìn)行統(tǒng)計(jì)的圖表：需求當(dāng)前狀態(tài)的統(tǒng)計(jì)圖表（需求覆蓋率統(tǒng)計(jì)分析）在上圖中點(diǎn)擊其中某狀態(tài)區(qū)域，得出該需求關(guān)聯(lián)狀態(tài)的具體條目，如以下內(nèi)容是尚未和測試用例關(guān)聯(lián)的屬于某測試人員設(shè)計(jì)的所有需求，查看需求具體屬性，進(jìn)行分析：5.2.7 需求狀態(tài)變化與跟蹤可以統(tǒng)計(jì)需求狀態(tài)在某一時間段內(nèi)的變化情況。需求狀態(tài)隨時間變化圖6 測試用例庫如果需求是測試設(shè)計(jì)、執(zhí)行和評估的依據(jù)和輸入，那么測試用例庫及其中的測試用例就是我們測試工作的核心內(nèi)容。TD提供了對測試用例進(jìn)行管理的強(qiáng)大功能，實(shí)現(xiàn)了測試用例的設(shè)計(jì)、維護(hù)、跟蹤、統(tǒng)計(jì)和分析功能，并和前面的需求、后面的測試執(zhí)行與評估無縫地關(guān)聯(lián)在一起，充分體現(xiàn)了測試管理過程的連續(xù)性、整體性。6.1 測試用例設(shè)計(jì)現(xiàn)狀描述在需求中設(shè)計(jì)的是關(guān)于系統(tǒng)的所有待測項(xiàng)目的檢查單（checklist），只是對被測系統(tǒng)功能的簡單描述。需要對測試內(nèi)容作進(jìn)一步規(guī)劃，包括對測試進(jìn)度的安排，測試內(nèi)容與測試方法的設(shè)計(jì)，測試用例的設(shè)計(jì)等。這個階段的工作作為測試人員的工作，和系統(tǒng)的開發(fā)階段的概要分析階段可并行進(jìn)行。隨著系統(tǒng)開發(fā)和測試的深入，對這些內(nèi)容作逐步的調(diào)整和修改。測試用例是“為特定目標(biāo)而開發(fā)的一組測試輸入、執(zhí)行條件和預(yù)期結(jié)果，其目標(biāo)可以是測試某個程序路徑或核實(shí)是否滿足某個特定的需求。”通俗地說，測試設(shè)計(jì)階段的測試用例主要定義已經(jīng)明確化了的對應(yīng)需求的測試內(nèi)容，是對測試計(jì)劃內(nèi)容的細(xì)化，測試計(jì)劃回答了要測什么的問題，而測試用例回答了測什么和怎么測的問題。我們目前已經(jīng)有“測試計(jì)劃”這樣的概念。但是，在現(xiàn)有的工作流程中并沒有這樣的軟實(shí)體存在，目前在測試計(jì)劃階段中需要做的事情基本上為根據(jù)需求說明書，編制測試規(guī)程文檔，以word文檔方式保存。這樣存在的問題是測試用例查看不方便，測試用例層次不夠清晰，而且測試用例難以做到及時與需求同步更新。目前一部分項(xiàng)目開始在Requsitepro中建立單獨(dú)得測試用例庫，內(nèi)容包括的為測試用例的簡單列表。采用RequisitePro工具的關(guān)聯(lián)功能，靠手工去維護(hù)測試用例和需求的關(guān)聯(lián)關(guān)系。這樣存在的問題是，在Requsitepro中去維護(hù)這種關(guān)聯(lián)關(guān)系，操作非常繁瑣。其中最嚴(yán)重的問題是，它只是測試用例的列表，不能對測試用例進(jìn)行詳細(xì)設(shè)計(jì)。不能和測試執(zhí)行環(huán)境集成，指引真正的測試活動。可以說采用這種方式作測試規(guī)程設(shè)計(jì)只是文檔形式的測試規(guī)程的另一種存在方式，對于實(shí)際的測試活動毫無用處。設(shè)計(jì)一個清晰簡明的測試計(jì)劃是成功的項(xiàng)目測試的基本要求，設(shè)計(jì)完善合理的測試用例是成功的項(xiàng)目測試的保證。測試用例設(shè)計(jì)工作是測試人員的主要工作內(nèi)容之一。TD提供了很好的測試用例設(shè)計(jì)開發(fā)和管理流程。6.2 測試用例（Test Case）管理6.2.1 測試計(jì)劃管理工作流程a) 定義測試策略：檢查應(yīng)用程序、系統(tǒng)環(huán)境和測試資源，決定測試目標(biāo)。b) 定義測試主題：將程序劃分為多個要測試模塊。建立一個測試計(jì)劃樹，這樣可以建立分級的測試單元或主題。c) 定義測試：確定每個模塊需要的測試類型，為每個測試在測試計(jì)劃樹上增加一個基本定義。d) 創(chuàng)建需求覆蓋：將每一個測試用例與相應(yīng)的需求相鏈接。e) 設(shè)計(jì)測試步驟：對于手工測試測試用例，設(shè)計(jì)測試用例的步驟，測試步驟包括測試操作、檢查點(diǎn)和期望輸出值，并決定哪些測試可以自動化。f) 自動化測試：對于決定要進(jìn)行自動化的測試，使用WinRunner 、Visual API、定制或者使用第三方的測試工具生成測試腳本。g) 分析測試計(jì)劃：生成報(bào)告和圖并輔助分析測試計(jì)劃數(shù)據(jù)，檢查你的測試，決定對于你的測試目標(biāo)是否合適。6.2.2 測試用例內(nèi)容完備性由于測試計(jì)劃中的測試用例是參照需求中內(nèi)容項(xiàng)產(chǎn)生，設(shè)計(jì)目標(biāo)明確，不會有大的遺漏產(chǎn)生。指導(dǎo)測試人員設(shè)計(jì)出符合實(shí)際需求的優(yōu)秀的測試用例。6.2.3 測試用例的分級管理對于項(xiàng)目的測試，需要根據(jù)不同的測試目的，不同的測試內(nèi)容項(xiàng)，分組分類管理。在TestDirector中通過folder 將測試計(jì)劃劃分為不同的單元（subject）。測試用例分屬于subject。建立測試計(jì)劃樹來直觀描述測試安排。方便管理。測試用例分級管理6.2.4 測試用例與需求關(guān)聯(lián)關(guān)系可將需求與測試用例進(jìn)行關(guān)聯(lián)操作。同時測試用例也和測試故障關(guān)聯(lián)。這樣的話，可在測試流程的各階段跟蹤需求。如果需求有改變，可以直接確定哪些測試用例和測試故障有影響，以及哪些人需要負(fù)責(zé)。通過設(shè)置這種關(guān)聯(lián)關(guān)系，更容易追蹤出需求的變化導(dǎo)致的測試用例和測試用例實(shí)施方法的變化。還可以在測試執(zhí)行結(jié)束后，通過運(yùn)行報(bào)告識別出有測試用例和實(shí)施方法的需求，并且標(biāo)識出已經(jīng)被運(yùn)行的測試用例。測試用例與需求是多對多的關(guān)聯(lián)關(guān)系。操作方式：即可在需求管理模塊中，選擇測試用例與需求關(guān)聯(lián)。也可在測試計(jì)劃管理模塊中，選擇需求與測試計(jì)劃關(guān)聯(lián)。6.2.5 測試設(shè)計(jì)階段的測試用例狀態(tài)分析與統(tǒng)計(jì)根據(jù)測試用例的設(shè)計(jì)情況，測試用例的設(shè)計(jì)狀態(tài)共有：n 創(chuàng)建中：測試用例尚未設(shè)計(jì)完畢。n 未評審：測試用例設(shè)計(jì)完成，但是尚未評審。n 使用中：測試用例評審?fù)ㄟ^，可以分配和執(zhí)行。n 已停用：測試用例停用，處于失效狀態(tài)。對用例查詢統(tǒng)計(jì)的作用：n 在測試設(shè)計(jì)工作過程中可以隨時了解當(dāng)前測試人員的測試進(jìn)展情況，對測試設(shè)計(jì)工作及時作出調(diào)整；n 可作為對測試人員在測試用例設(shè)計(jì)階段的工作量考核的參考數(shù)據(jù)。n 還可以利用TD工具提供的靈活的查詢定制功能，對某項(xiàng)目或者產(chǎn)品當(dāng)前的所有測試用例進(jìn)行分類和統(tǒng)計(jì)。測試人員的用例設(shè)計(jì)一覽測試用例隨時間的狀態(tài)變化6.3 自動化測試腳本測試用例可以是手工的測試用例，也可以是自動執(zhí)行的測試用例，及以自動化測試腳本的形式體現(xiàn)。對TD用例庫中的自動化腳本可以分為下述幾種類型：n 使用MI公司的WinRunner、LoadRunner等測試工具的腳本，可以作為用例的屬性，直接在TD測試用例庫中進(jìn)行管理和直接調(diào)用。n 對于使用其它工具如Rational Robot、ProcommPlus、ScriptCenter等的腳本，我們目前的做法是這些腳本由相應(yīng)的工具自行管理，因?yàn)檫@些工具本身已經(jīng)有其自身的較適合的管理方式，在TD用例庫這里只把這些腳本的標(biāo)識(如腳本路徑名稱、腳本ID等)作為測試用例的屬性進(jìn)行管理。測試人員在執(zhí)行這些測試用例的時候，根據(jù)腳本的標(biāo)識，使用相應(yīng)的工具在其腳本庫中打開來運(yùn)行。n 手工的測試是可以逐步轉(zhuǎn)化為自動化測試腳本的。在手工腳本逐步完善之后，為了提高測試的效率和質(zhì)量，部分手工測試用例可以逐步用自動化腳本來實(shí)現(xiàn)。測試用例的屬性包括手工用例、自動化用例等等，測試管理人員可根據(jù)需要，逐步提高測試用例中自動化用例的比重，并可通過定制的查詢了解到當(dāng)前測試用例庫自動化程度的高低。6.4 測試規(guī)程文檔的生成目前公司要求測試規(guī)程文檔作為產(chǎn)品基線文檔之一，測試規(guī)程文檔就是覆蓋該產(chǎn)品的所有系統(tǒng)需求的測試用例集合的文檔化描述。從TD中可以根據(jù)所選擇的測試用例自動生成測試用例集合文檔，經(jīng)過改動之后就可以形成符合公司文檔模板要求的測試規(guī)程文檔。這種方式有如下好處：n 從TD測試用例庫自動生成測試規(guī)程文檔，解決了困擾我們很久的測試規(guī)程文檔與當(dāng)前測試用例不一致、更新慢的問題。n 原來的測試規(guī)程文檔中的測試用例是一個最全、最完整的集合，而我們在具體測試過程中，根據(jù)測試的需求與內(nèi)容不同，實(shí)際上每次執(zhí)行的測試用例內(nèi)容和數(shù)量都不一致，都是測試規(guī)程中所有用例的子集，導(dǎo)致我們拿著完整測試規(guī)程倒是失去了具體的工作指導(dǎo)。現(xiàn)在我們使用TD來管理所有測試用例，在制訂具體任務(wù)計(jì)劃的時候才選擇和明確需要執(zhí)行的測試用例（下面會介紹其工作過程），而在需要完整的測試規(guī)程文檔的時候自動生成文檔，就顯得十分方便、靈活和嚴(yán)謹(jǐn)。n 除了測試規(guī)程文檔，TD還提供了比較豐富的、可定制的模板，可以生成包括需求、用例、執(zhí)行、跟蹤在內(nèi)的許多類型的文檔。7 測試執(zhí)行(Test Set)7.1 現(xiàn)狀描述如上所述，目前我們的測試人員在接到一個測試任務(wù)的時候，會根據(jù)測試申請單中要求測試的功能需求，根據(jù)測試規(guī)程中的測試用例進(jìn)行測試。但是測試規(guī)程中的用例是對應(yīng)產(chǎn)品所有需求的所有測試用例的集合，而每個測試任務(wù)所執(zhí)行的測試用例內(nèi)容和數(shù)目均不相同，導(dǎo)致測試的覆蓋率和質(zhì)量難以保證，測試管理者如測試經(jīng)理也很難了解到測試的相關(guān)過程數(shù)據(jù)，比如本次測試計(jì)劃執(zhí)行的測試數(shù)目和具體內(nèi)容、本次測試實(shí)際執(zhí)行的測試用例情況、測試人員執(zhí)行的具體情況、測試用例執(zhí)行具體結(jié)果等等。7.2 TD 測試執(zhí)行7.2.1 TD的測試執(zhí)行管理功能對比上述的不足，使用TD的測試執(zhí)行管理功能，測試管理者很容易完成下述的工作：n 根據(jù)測試申請單中列出的需求內(nèi)容、并根據(jù)測試的風(fēng)險(xiǎn)、時間人員等資源因素，在測試用例庫中選擇相應(yīng)的測試用例，形成測試任務(wù)準(zhǔn)備進(jìn)行測試n 為每個具體的測試用例安排相應(yīng)的測試人員，把執(zhí)行測試用例的職責(zé)具體到人。TD允許多人合作完成一個測試用例的情況，可通過生成測試用例多個實(shí)例的方式來實(shí)現(xiàn)n 在測試任務(wù)制定時，根據(jù)測試用例的相互制約情況(如時間順序上的制約、資源的制約和沖突)，制訂測試用例的運(yùn)行時間，從而實(shí)現(xiàn)測試用例在執(zhí)行時間的安排和分布n 根據(jù)測試任務(wù)中包含測試用例的需求覆蓋情況，統(tǒng)計(jì)出這些測試用例對測試申請單中需求的覆蓋情況。n 在測試執(zhí)行過程中，測試人員只需打開IE的TD用例執(zhí)行界面，就可根據(jù)按時間順序安排好的測試用例進(jìn)行測試，也可根據(jù)實(shí)際工作情況的變化，靈活選擇測試用例進(jìn)行測試。測試時，由于測試用例的操作步驟、通過準(zhǔn)則都描述的十分詳細(xì)，測試人員可根據(jù)用例要求嚴(yán)格進(jìn)行測試，并記錄下測試執(zhí)行的結(jié)果。n 在測試過程中，測試人員可隨時新增測試步驟和測試數(shù)據(jù)，并保存在測試用例庫中，供評審后復(fù)用，解決了以前隨機(jī)想出來的測試方法和步驟不方便保存和復(fù)用的問題n 測試過程中，測試人員對某些測試用例可反復(fù)執(zhí)行多次，TD將如實(shí)記錄每次測試的過程數(shù)據(jù)和結(jié)果。n 測試過程中，TD會記錄每個測試用例執(zhí)行的實(shí)際執(zhí)行時間。測試管理者可對這些用例執(zhí)行時間進(jìn)行分析和統(tǒng)計(jì)，對一些執(zhí)行效率不高、容易給測試工作造成瓶頸的測試用例進(jìn)行改進(jìn)，比如轉(zhuǎn)化成自動化測試、通過環(huán)境的提前精心準(zhǔn)備，解決執(zhí)行該用例過程中進(jìn)行環(huán)境搭建花費(fèi)時間太多的問題等等。這個功能為我們改進(jìn)測試效率提供了很好的量化測量工具。我認(rèn)為這是TD的一個很好的功能。n 測試管理者在測試任務(wù)執(zhí)行過程中，可隨時查看各測試人員的測試工作執(zhí)行情況、查看所有測試用例完成情況，以便及時發(fā)現(xiàn)問題，及時調(diào)整測試工作計(jì)劃n 測試執(zhí)行結(jié)束之后，測試人員和管理者可以方便的統(tǒng)計(jì)所有用例的執(zhí)行結(jié)果、用例的故障發(fā)現(xiàn)率(即有些用例發(fā)現(xiàn)故障的比例比較高，今后測試多采用這些用例；而有的用例比較難發(fā)現(xiàn)故障，今后考慮風(fēng)險(xiǎn)因素之后可減少這些用例的使用)。n 測試執(zhí)行結(jié)束之后，管理者可以根據(jù)測試人員實(shí)際執(zhí)行測試用例的情況來衡量測試人員的實(shí)際工作量和工作效率。7.2.2 測試執(zhí)行工作流程測試執(zhí)行工作流程圖示：7.2.3 測試任務(wù)制定根據(jù)測試申請，測試管理者在TD中創(chuàng)建測試任務(wù)TestSet進(jìn)行用例的安排和人員的分配。包括本次測試任務(wù)包含的所有測試用例、測試用例分配給哪位測試人員來執(zhí)行、測試用例計(jì)劃執(zhí)行的時間等信息。Test Set中包含的測試用例在測試流視圖中，還可以設(shè)置測試執(zhí)行中測試用例執(zhí)行的流程，包括執(zhí)行的時間進(jìn)度安排，測試用例之間執(zhí)行的前后條件約束，執(zhí)行頻率等。下圖就是測試流視圖的內(nèi)容：Test Set中測試用例執(zhí)行的流程設(shè)置7.2.4 測試體執(zhí)行測試開始的時候，測試人員打開IE終端，通過測試任務(wù)的過濾器查看分配給自己執(zhí)行的測試用例，然后按照安排好的時間順序來執(zhí)行測試用例。手工測試用例執(zhí)行時，彈出人工測試運(yùn)行窗口，在窗口中顯示測試用例的測試步驟與預(yù)期結(jié)果，測試人員可以按照這些信息指示一步一步的測試。每一步測試完畢后，填寫測試的實(shí)際結(jié)果，并根據(jù)實(shí)際的測試結(jié)果設(shè)置是“pass”還是“fail”。在運(yùn)行階段發(fā)現(xiàn)測試用例的測試步驟有錯誤時也可直接作修改，這些修改也將存到測試計(jì)劃中去。測試用例還可以多次執(zhí)行。當(dāng) Test Set 運(yùn)行過程中添加可直接添加test defect，該測試故障直接和該測試用例test 關(guān)聯(lián)，并且可直接將運(yùn)行的故障狀態(tài)作為故障的描述信息提交到故障庫中去。這個功能我們目前不采用，測試過程中發(fā)現(xiàn)的故障直接通過現(xiàn)有的CQ流程提交上去。人工測試用例的執(zhí)行8 故障跟蹤目前公司和事業(yè)部都采用CQ作為故障管理工具，而且已經(jīng)比較成熟了，雖然TD也有很好的故障管理功能，但是我們就不再采用，所以也沒有做深入的研究。9 測試評價9.1 測試結(jié)果日志需求，測試用例和測試故障可相互關(guān)聯(lián)。每次測試執(zhí)行的結(jié)果有日志信息供查看。9.2 測試覆蓋率在每一階段，可分析數(shù)據(jù)并生成數(shù)據(jù)報(bào)表和圖形顯示。例如：分析需求各種狀態(tài)的分布，測試用例各狀態(tài)的分布，相對于不同人員的分布。9.3 測試報(bào)告生成 可以生成本次測試所有用例的執(zhí)行結(jié)果情況和統(tǒng)計(jì)分析數(shù)據(jù)。這個統(tǒng)計(jì)僅用來分析本次測試設(shè)計(jì)和執(zhí)行工作本身的質(zhì)量，以便于考核和今后工作改進(jìn)，而對被測對象的質(zhì)量評估，我們還是從CQ中提交的故障導(dǎo)出。 測試報(bào)告的文檔，我們還是根據(jù)公司模板要求來編寫，相關(guān)的測試故障還是從CQ中導(dǎo)出。10 工具特性 在每一階段，可分析數(shù)據(jù)并生成數(shù)據(jù)報(bào)表和圖形顯示。 可以定制要顯示的數(shù)據(jù)字段，可以定制查詢條件選擇顯示數(shù)據(jù)。 任何查看到的數(shù)據(jù)都可存取保存為Text ，Word ，excel ，html 格式的文件。 可以保存自己熟悉和喜愛的視圖，待下次打開是顯示同樣的使用視圖。Public 類型的favorite 全部人員都可使用，private 類型 只可創(chuàng)建他的用戶使用。 TestDirector 的擴(kuò)展性：提供開放架構(gòu)，提供開放COM_base API 開發(fā)接口，方便我們進(jìn)行更靈活的二次開發(fā)。 項(xiàng)目可以定制。工作流可以定制。不同角色工作界面、操作權(quán)限可以設(shè)計(jì)。 具有較好的安全管理功能，可設(shè)置用戶組和用戶權(quán)限，對用戶訪問的項(xiàng)目進(jìn)行限制、對用戶的讀寫操作權(quán)限進(jìn)行控制。 據(jù)代理商介紹，全新的TD V8.0版本提供了更為強(qiáng)大的安全管理和版本控制功能，對用戶所能操作的用例、需求的權(quán)限不僅在項(xiàng)目級別進(jìn)行控制，還可以控制到具體的用例和需求條目。另外，為測試工作產(chǎn)品的更為嚴(yán)格的版本控制需要，對流程中的用例、需求等工作產(chǎn)品進(jìn)行了Check in和Check out操作的限制。這些功能在V7.6中沒有提供。11 總體評價 數(shù)據(jù)統(tǒng)一，信息相互關(guān)聯(lián)，方便的跟蹤到信息的狀態(tài)變化，查看到各種覆蓋率情況。從中分析出系統(tǒng)的進(jìn)度情況。查看的方式包括報(bào)告形式與圖表形式。 作為指導(dǎo)計(jì)劃的參照數(shù)據(jù)，工作量分析的參照數(shù)據(jù) 數(shù)據(jù)統(tǒng)一，共享。工作成果統(tǒng)一保存。不同角色工作成果的輸出直接作為相關(guān)角色的工作輸入。 指導(dǎo)測試人員的測試活動。12 典型問題解決方案TD與TM工具實(shí)際問題回答列表問題TM回答TD回答1、測試用例的組合順序與TM中的用例如何對應(yīng)？工具本身并不提供用例設(shè)計(jì)的方法，測試用例可大可小，根據(jù)實(shí)際情況靈活處理。測試用例的執(zhí)行順序可以通過testsuite來對應(yīng)。Testmanager中的一個suite對應(yīng)做一個用例組合。不同的suite可以包含相同的用例，但是這些用例的執(zhí)行順序、運(yùn)行次數(shù)、運(yùn)行的計(jì)算機(jī)組都各不相同。所以實(shí)現(xiàn)了不同目的的用例。同TM。2、驗(yàn)證測試時提交功能清單，如何與工具聯(lián)系起來?需要定制。Testmanager與現(xiàn)在所內(nèi)的測試申請的管理工具cq是一個集成的產(chǎn)品，可能需要Rational的技術(shù)支持。需要定制。如果開發(fā)各部門全部使用統(tǒng)一的TD項(xiàng)目庫，整個流程全部采用TD，由于TD采用一個庫，所以保證在提測試申請時選擇相關(guān)需求，從而可使測試人員在得到測試申請時知道本次測試的全部內(nèi)容（通過需求的狀態(tài)改變來得到）?？赡苄枰赥D的需求管理定制類似CQ中的測試申請流程，3、CQ上的質(zhì)量評價考核單，測試申請等能否與TM關(guān)聯(lián)起來?同上同上4、測試用例中的測試數(shù)據(jù)如何實(shí)現(xiàn)?每個測試用例可以對應(yīng)一個datapool（testmanager中測試數(shù)據(jù)管理工具）數(shù)據(jù)庫。這個數(shù)據(jù)庫可以在生成腳本的時候由系統(tǒng)自動生成，也可以由測試設(shè)計(jì)人員手工編輯。數(shù)據(jù)庫中包括各個字段定義（一般一個字段對應(yīng)著一個測試數(shù)據(jù)）。數(shù)據(jù)庫中的一條記錄對應(yīng)著一套完整的測試數(shù)據(jù)。數(shù)據(jù)作為用例的一部分存在，以及在自動化腳本中采用DataPool的形式。5、對同一個測試內(nèi)容，如何保證前后兩次測試的可比性?每個用例的執(zhí)行都會在testmanager中生成一條用例的執(zhí)行日志。同一用例不同的執(zhí)行，可以通過比較日志來比較測試結(jié)果。TD中可保留每個測試用例的所有測試記錄，可以對不同測試進(jìn)行比較。6、由于工作中的疏漏引起的測試質(zhì)量問題是最大的問題，工具能夠保證測試質(zhì)量有很大的提高嗎？間接支持。Testmanager是一個測試管理工具，對應(yīng)測試中每一個環(huán)節(jié)都提供了細(xì)致全面的管理，同時自動將各個環(huán)節(jié)關(guān)連起來，相互之間提供一定的狀態(tài)標(biāo)識，提醒操作員各個環(huán)節(jié)當(dāng)前的狀態(tài)。對于一些完全不符合測試流程要求的操作進(jìn)行了必要的保護(hù)。這樣可以大大減少測試中的疏漏。間接支持。通過流程改進(jìn)，運(yùn)用工具設(shè)置一些必要的工作環(huán)節(jié)，在一定程度上可保證測試人員的責(zé)任心7、測試用例設(shè)計(jì)質(zhì)量不行，如何知道一個需求需要5個用例才能解決問題，但實(shí)際只有3個？而這點(diǎn)依靠工具同樣不能解決。工具本身不能保證，但是它可以提供非常清晰的數(shù)據(jù)作為決策參考。同TM。8、工具中能否體現(xiàn)工單的質(zhì)量問題?在測試用例是經(jīng)過評審，默認(rèn)正確、完善的情況下，測試執(zhí)行結(jié)果中顯示的用例覆蓋率、故障發(fā)現(xiàn)情況，可以作為評價工單質(zhì)量的重要依據(jù)。通過故障總數(shù)、個人的故障數(shù)、測試覆蓋率來表現(xiàn)9、引入工具，工作量會大大增加工具必須在測試團(tuán)隊(duì)中大范圍的使用，大家通過該工具實(shí)現(xiàn)工作成果的實(shí)時共享、可以大大減少工作上的重復(fù)的工作量、確保工作順利高效的執(zhí)行。作為工作流程中一個組成部分，在測試活動中隨時使用，由于可以資源共享，經(jīng)驗(yàn)共享，隨著推廣力度的加大，工作量應(yīng)是減少10、工具能否體現(xiàn)測試人員的責(zé)任心？工作內(nèi)容透明化，一定程度上可以顯現(xiàn)出測試人員的責(zé)任心。同TM。11、測試質(zhì)量不可控，同一個規(guī)程不同的人測，測出來的結(jié)論和故障都不一樣；完全相同的測試用例，在外界條件一樣的情況下，執(zhí)行的結(jié)果在工具中應(yīng)該是一樣的，可以消除人的差異性。同TM。12、規(guī)程修改缺乏實(shí)時性；需求變化規(guī)程也應(yīng)該發(fā)生變化。Testmanager與需求管理工具requisitepro相互關(guān)連，當(dāng)需求變化是自動修改用例中對于的需求標(biāo)識，提醒測試人員及時修改測試用例。這樣該用例下次執(zhí)行的時候就包含了新的測試內(nèi)容。Testmanget是測試人員可以方便快捷的實(shí)現(xiàn)測試規(guī)程、用例的實(shí)時更新。在庫里進(jìn)行即時修改，需求改變相應(yīng)規(guī)程即變化。13、測試人員的測試時間不可控，有人只要3天，有人要5天，測試經(jīng)理不好控制。用例確定的情況下，一個測試用例在一定配置測試設(shè)備上執(zhí)行測試的時間是一定的，從而整個測試過程的時間是可預(yù)期的。所有用例有測試歷史記錄，記載該用例以前的測試時間等等數(shù)據(jù)供測試經(jīng)理參考14、測試用例增加，但需求未增加的這種情況，該如何處理?直接手工增加新的測試用例，如果有可關(guān)聯(lián)的需求，則關(guān)聯(lián)原來的需求，如果沒有需求，則可以先補(bǔ)充再關(guān)聯(lián)。在TD中補(bǔ)充可關(guān)聯(lián)的需求，增加新的測試用例。15、分析過程中，測試報(bào)告中發(fā)現(xiàn)一個小故障現(xiàn)象，可能現(xiàn)象下面隱藏著更大的隱患，而我們卻沒有發(fā)現(xiàn)。開發(fā)人員比較關(guān)心的是執(zhí)行什么操作出現(xiàn)的錯誤，而不是錯誤本身的現(xiàn)象，流程和工具如果能做到這點(diǎn)就比較好。自動化測試，可以通過分析測試結(jié)果日志來查找原因。對于手工測試，工具難以支持。不支持。關(guān)于多版本情況的管理。間接支持，定制實(shí)現(xiàn)1:我們可以考慮用添加多個標(biāo)示字段的方式，也就是說有多少個版本，添加多少個標(biāo)示字段，通過相應(yīng)版本字段是否設(shè)置值來區(qū)別不同的版本。2:該方案適用的前提是版本的數(shù)目不要太多（版本太多的話，需添加較多的字段，不方便）。3:為了避免版本過多的情況：可以只考慮大版本號，對于研發(fā)過程中間的測試、調(diào)試版本等不作考慮。13 試點(diǎn)中存在的問題和解決方案從試點(diǎn)的情況看，問題主要存在于與RP需求庫的同步和一致性問題、文檔生成格式的定制問題、以及二次開發(fā)的擴(kuò)展靈活性問題。 用戶在使用客戶端進(jìn)行操作時，有時候會提示“RPC服務(wù)無法訪問”需要把IE升級到6.0，另外IE的代理去掉，發(fā)生的頻率會少一些。當(dāng)然如果還是發(fā)生了，重啟IE就可以。 RP和TD的需求庫難于實(shí)現(xiàn)完全的、隨時的同步，可能導(dǎo)致今后兩個庫的數(shù)據(jù)不一致，人工維護(hù)TD測試數(shù)據(jù)庫的工作量加大這的確是個問題?，F(xiàn)在用RP庫來創(chuàng)建測試用例以及建立用例與需求的關(guān)系，同樣需要人工來實(shí)時維護(hù)?？梢钥紤]在RP中增加查詢功能，能查詢某個時間段的新增或變化的需求，測試人員根據(jù)這些變化，及時地