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