天測試工程師成功之路指導手冊.doc

《天測試工程師成功之路指導手冊.doc》由會員分享，可在線閱讀，更多相關《天測試工程師成功之路指導手冊.doc（176頁珍藏版）》請在裝配圖網上搜索。

ThinkBank International Software R 非法 錯誤 不正確和垃圾數(shù)據 2 2 3 狀態(tài)測試技術 軟件可能進入的每一種獨立狀態(tài) 從一種狀態(tài)轉入另一種狀態(tài)所需的輸入和條件 進入或退出某種狀態(tài)時的設置條件及輸入結果 具體測試方法可以參考如下 每種狀態(tài)至少訪問一次 測試看起來最常見最普遍的狀態(tài)轉換 測試狀態(tài)之間最不常用的分支 測試所有錯誤狀態(tài)及其返回值 測試隨機狀態(tài)轉換 2 2 4 競爭條件測試技術 競爭條件典型情形參考如下 兩個不同的程序同時保存或打開同一個文檔 共享同一臺打印機 通信端口或者其他外圍設備 當軟件處于讀取或者修改狀態(tài)時按鍵或者單擊鼠標 同時關閉或者啟動軟件的多個實例 同時使用不同的程序訪問一個共同數(shù)據庫 3 負載 壓力測試 StressTest 在這里的負載 壓力和功能測試中的不同 他是系統(tǒng)測試的內容 是基本功能已經通過后進行 的 可以在集成測試階段 亦可以在系統(tǒng)測試階段進行 使用負載測試工具進行 虛擬一定數(shù)量的用戶看一看系統(tǒng)的表現(xiàn) 是否滿足定義中的指標 負載測試一般使用工具完成 loadrunner webload was ewl e test 等 主要的內容都是 編寫出測試腳本 腳本中一般包括用戶一般常用的功能 然后運行 得出報告 所以負載測試 包括的主要內容就不介紹了 負載測試技術在各種極限情況下對產品進行測試 如很多人同時使用該軟件 或者反復運 行該軟件 以檢查產品的長期穩(wěn)定性 例如 使用壓力測試工具對 web 服務器進行壓力測試 本項測試可以幫助找到一些大型的問題 如死機 崩損 內存泄漏等 因為有些存在內存泄漏 問題的程序 在運行一兩次時可能不會出現(xiàn)問題 但是如果運行了成千上萬次 內存泄漏得越 來越多 就會導致系統(tǒng)崩滑 用 J2EE 實現(xiàn)的系統(tǒng)很少但是并不是沒有內存問題 無論什么工具基本的技術都是利用線程技術模仿和虛擬用戶 在這里主要的難點在與測試 腳本的編寫 每種工具使用的腳本都不一樣 但是大多數(shù)工具都提供錄制功能就算是不會編碼 的測試人員同樣可以測試 對負載工具的延伸使用可以進行系統(tǒng)穩(wěn)定性測試 系統(tǒng)極限測試 如使用 100 的 Load Size 連續(xù)使用 24 小時 微軟定義的通過準則是通過 72 小時測試的程序一般不會出現(xiàn)穩(wěn)定性的 問題 4 回歸測試 Regression Test 過一段時間以后 再回過頭來對以前修復過的 Bug 重新進行測試 看該 Bug 是否會重新 出現(xiàn) 回歸測試技術可以在測試的各個階段出現(xiàn) 無論是單元測試還是集成測試還是系統(tǒng)測試 是對以前問題進行驗證的過程 回歸測試的目的就是保證以前已經修復的 Bug 不會再出現(xiàn) 實際上 許多 Bug 都是在回 歸測試時發(fā)現(xiàn)的 在此階段 我們首先要檢查以前找到的 Bug 是否已經更正了 值得注意的 是 已經更正的 Bug 也可能又回來了 有的 Bug 經過修改之后可能又產生了新的 Bug 所以 回歸測試可保證已更正的 Bug 不再重現(xiàn) 不產生新的 Bug 5 Alpha 和 Beta 測試 Alpha and Beta Test 在正式發(fā)布產品之前往往要先發(fā)布一些測試版 讓用戶能夠反饋出相關信息 或者找到存 在的 Bug 以便在正式版中得到解決 特別是在有客戶參加的情況下 對系統(tǒng)進行測試可能會出現(xiàn)一些我們沒有考慮的情況 還 可以解決一些客戶實際關心的問題 6 不同的測試技術區(qū)分 6 1 覆蓋測試技術 說明 測試覆蓋率可以看出測試的完成度 在測試分析報告中可以作為量化指標的依據 測 試覆蓋率越高效果越好 覆蓋測試可以是程序代碼的執(zhí)行路徑覆蓋 亦可以是功能實現(xiàn)的步驟覆蓋 可以理解成流 程圖的路徑覆蓋 該技術可以用在任何測試階段 包括單元測壞死 集成測試 系統(tǒng)測試 使用該技術時可以使用以上的任何測試方法和測試技術 6 2 白盒測試和黑盒測試技術 白盒測試技術 White Box Testing 該技術主要的特征是測試對象進入了代碼內部 根據開發(fā) 人員對代碼和對程序的熟悉程度 對有需要的部分進行在軟件編碼階段 開發(fā)人員根據自己對 代碼的理解和接觸所進行的軟件測試叫做白盒測試 這一階段測試以軟件開發(fā)人員為主 使用 Xunit 系列工具進行測試 可以包括很多方面如功能性能等 黑盒測試 Black Box Testing 測試的主體部分黑盒測試的內容主要有以下幾個方面 但是 主要還是功能部分 主要是覆蓋全部的功能 可以結合兼容 性能測試等方面進行 包括的不 同測試類型請參考以上內容 6 3 手工測試和自動化測試 手工測試 Manual Testing 即依靠人力來查找 Bug 方法可以參考上邊的測試 也可 以根據對實現(xiàn)技術及經驗等進行不同的測試 自動測試 Automation Testing 使用有針對工具實行 可以作出自動化測試的計劃 對可 以進行自動化測試的部分編寫或者錄制相應的腳本 可以加入功能 容錯 表單提交等 可以參考 MI Rational 或者其他類測試工具說明 根據權威的軟件測試經驗 手工測試還是主要的測試方法 自動測試不夠靈活 在這里不 再詳述 微軟的測試過程 80 還是手工完成 自動測試永遠也代替不了手工測試 但是手工測試的工作量很大是不爭的事實 6 4 根據 RUP 標準按階段區(qū)分測試 單元測試在上邊有詳細的敘述 還有針對單元測試和集成測試的論述 請參考 集成測試分為功能集成測試和系統(tǒng)集成測試 相互有調用的功能集成 在系統(tǒng)環(huán)境下功能 相互調用的影響等 使用方法可以任意選用上面的內容 注重功能方面 系統(tǒng)測試在功能實現(xiàn)的基礎上 可以加入兼容性 易用性 性能等等 驗收測試可以包括 Alpha 和 Beta 測試 在這里就不再詳述 7 存在風險及解決方法 說明 測試不能找出所有的問題 只是盡量將問題在開發(fā)階段解決大多數(shù)的問題而已 測試風險如下 軟硬件的測試環(huán)境提供上也對測試結果有很大的影響 測試團隊的水平 經驗 合作效果等 整個開發(fā)流程對測試的重視程度 測試的進入時間等 由于測試環(huán)境操作系統(tǒng) 網絡環(huán)境 帶寬等情況可能產生的測試結果可能不同這是就需要 經驗以及對測試環(huán)境的保護等方面下一些功夫 8 軟件缺陷的原則 軟件缺陷區(qū)別于軟件 bug 它是在測試過程中出現(xiàn)的對系統(tǒng)有影響的 但是在設計中沒有的 或者對修改后的 bug 測試和開發(fā)人員有不同意見等 軟件未達到產品說明書標明的功能 軟件出現(xiàn)了產品說明書指明不會出現(xiàn)的錯誤 軟件功能超出產品說明書指明范圍 軟件未達到產品說明書雖未指出但應達到的目標 軟件測試員認為軟件難以理解 不易使用 運行速度緩慢 或者最終用戶認為不好 9 文檔測試 產品說明書屬性檢查清單 完整 是否有遺漏和丟失 完全嗎 單獨使用是否包含全部內容 準確 既定解決方案正確嗎 目標明確嗎 有沒有錯誤 精確 不含糊 清晰 描述是否一清二楚 還是自說自話 容易看懂和理解嗎 一致 產品功能能描述是否自相矛盾 與其他功能有沒有沖突 貼切 描述功能的陳述是否必要 有沒有多余信息 功能是否原來的客戶要求 合理 在特定的預算和進度下 以現(xiàn)有人力 物力和資源能否實現(xiàn) 代碼無關 是否堅持定義產品 而不是定義其所信賴的軟件設計 架構和代碼 可測試性 特性能否測試 測試員建立驗證操作的測試程序是否提供足夠的信息 產品說明書用語檢查清單 說明對問題的描述通常表現(xiàn)為粉飾沒有仔細考慮的功能 可歸結于前文所述的屬性 從產 品說明書上找出這樣的用語 仔細審視它們在文中是怎樣使用的 產品說明書可能會為其掩飾和 開脫 也可能含糊其詞 無論是哪一種情況都可視為軟件缺陷 總是 每一種 所有 沒有 從不 如果看到此類絕對或肯定的 切實認定的敘述 軟件測試員就可 以著手設計針鋒相對的案例 當然 因此 明顯 顯然 必然 這些話意圖誘使接受假定情況 不要中了圈套 某些 有時 常常 通常 慣常 經常 大多 幾乎 這些話太過模糊 有時 發(fā)生作用的功能無法測試 等等 諸如此類 依此類推 以這樣的詞結束的功能清單無法測試 功能清單要絕對或者解釋明 確 以免讓人迷惑 不知如何推論 良好 迅速 廉價 高效 小 穩(wěn)定 這些是不確定的說法 不可測試 如果在產品說明書中出現(xiàn) 就 必須進一步指明含義 已處理 已拒絕 已忽略 已消除 這些廉潔可能會隱藏大量需要說明的功能 如果 那么 沒有否則 找出有 如果 那么 而缺少配套的 否則 結構的陳述 想一想 如 果 沒有發(fā)生會怎樣 五 系統(tǒng)測試 系統(tǒng)測試 System Test ST 是將經過測試的子系統(tǒng)裝配成一個完整系統(tǒng) 來測試 它是檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法 系統(tǒng)測試的目的是對最終軟件系統(tǒng)進行全面的測試 確保最終軟件系統(tǒng)滿足 產品需求并且遵循系統(tǒng)設計 系統(tǒng)測試過程域是 SPP 模型的重要組成部分 本規(guī)范闡述了系統(tǒng)測試的規(guī)程 該規(guī)程的 目標 角色與職責 啟動準則 輸入 主要步驟 輸出 完 成準則 和 度量 均已定義 1 介紹 系統(tǒng)測試流程如圖 1 所示 由于系統(tǒng)測試的目的是驗證最終軟件系統(tǒng)滿足產品需求并且遵 循系統(tǒng)設計 所以當產品需求和系統(tǒng)設計文檔完成之后 系統(tǒng)測試小組就可以提前開始制定測 試計劃和設計測試用例 而不必等到 實現(xiàn)與測試 階段結束 這樣可以提高系統(tǒng)測試的效率 系統(tǒng)測試過程中發(fā)現(xiàn)的所有缺陷必須用統(tǒng)一的缺陷管理工具來管理 開發(fā)人員應當及時消 除缺陷 改錯 圖 1 系統(tǒng)測試流程圖 項目經理設法組建富有成效的系統(tǒng)測試小組 系統(tǒng)測試小組的成員主要來源于 機構獨立的測試小組 如果存在的話 邀請其它項目的開發(fā)人員參與系統(tǒng)測試 本項目的部分開發(fā)人員 機構的質量保證人員 系統(tǒng)測試小組應當根據項目的特征確定測試內容 一般地 系統(tǒng)測試的主要內容包括 功能測試 即測試軟件系統(tǒng)的功能是否正確 其依據是需求文檔 如 產品需求規(guī)格說明 書 由于正確性是軟件最重要的質量因素 所以功能測試必不可少 健壯性測試 即測試軟件系統(tǒng)在異常情況下能否正常運行的能力 健壯性有兩層含義 一 是容錯能力 二是恢復能力 性能測試 即測試軟件系統(tǒng)處理事務的速度 一是為了檢驗性能是否符合需求 二是為了 得到某些性能數(shù)據供人們參考 例如用于宣傳 用戶界面測試 重點是測試軟件系統(tǒng)的易用性和視覺效果等 安全性 security 測試 是指測試軟件系統(tǒng)防止非法入侵的能力 安全 是相對而言的 一般地 如果黑客為非法入侵花費的代價 考慮時間 費用 危險等因素 高于得到的好處 那么這樣的系統(tǒng)可以認為是安全的 安裝與反安裝測試 系統(tǒng)測試過程域產生的主要文檔有 系統(tǒng)測試計劃 模板見 SPP TEMP ST PLAN 系統(tǒng)測試用例 模板見 SPP TEMP TEST CASE 系統(tǒng)測試報告 模板見 SPP TEMP TEST REPORT 缺陷管理報告 由缺陷管理工具自動生成 2 系統(tǒng)測試規(guī)程 1 目的 對最終軟件系統(tǒng)進行全面的測試 確保最終軟件系統(tǒng)滿足產品需求并且遵循系統(tǒng)設計 2 角色與職責 項目經理組建系統(tǒng)測試小組 并指定一名成員任測試組長 系統(tǒng)測試小組各成員共同制定測試計劃 設計測試用例 執(zhí)行測試 并撰寫相應的文檔 測試組長管理上述事務 開發(fā)人員及時消除測試人員發(fā)現(xiàn)的缺陷 3 啟動準則 產品需求和系統(tǒng)設計文檔完成之后 4 輸入 產品需求和系統(tǒng)設計文檔 5 主要步驟 Step1 制定系統(tǒng)測試計劃 系統(tǒng)測試小組各成員共同協(xié)商測試計劃 測試組長按照指定的模板起草 系統(tǒng)測試計劃 該計劃主要包括 測試范圍 內容 測試方法 測試環(huán)境與輔助工具 測試完成準則 人員與任務表 項目經理審批 系統(tǒng)測試計劃 該計劃被批準后 轉向 Step2 Step2 設計系統(tǒng)測試用例 系統(tǒng)測試小組各成員依據 系統(tǒng)測試計劃 和指定的模板 設計 撰寫 系統(tǒng)測試用例 測試組長邀請開發(fā)人員和同行專家 對 系統(tǒng)測試用例 進行技術評審 該測試用例通過 技術評審后 轉向 Step3 Step3 執(zhí)行系統(tǒng)測試 系統(tǒng)測試小組各成員依據 系統(tǒng)測試計劃 和 系統(tǒng)測試用例 執(zhí)行系統(tǒng)測試 將測試結果記錄在 系統(tǒng)測試報告 中 用 缺陷管理工具 來管理所發(fā)現(xiàn)的缺陷 并及時 通報給開發(fā)人員 Step4 缺陷管理與改錯 從 Step1 至 Step3 任何人發(fā)現(xiàn)軟件系統(tǒng)中的缺陷時都必須使用指定的 缺陷管理工具 該工具將記錄所有缺陷的狀態(tài)信息 并可以自動產生 缺陷管理報告 開發(fā)人員及時消除已經發(fā)現(xiàn)的缺陷 開發(fā)人員消除缺陷之后應當馬上進行回歸測試 以確保不會引入新的缺陷 6 輸出 消除了缺陷的最終軟件系統(tǒng) 系統(tǒng)測試用例 系統(tǒng)測試報告 缺陷管理報告 7 結束準則 對于非嚴格系統(tǒng)可以采用 基于測試用例 的準則 功能性測試用例通過率達到 100 非功能性測試用例通過率達到 80 時 對于嚴格系統(tǒng) 應當補充 基于缺陷密度 的規(guī)則 相鄰 n 個 CPU 小時內 測試期缺陷密度 全部低于某個值 m 例如 n 大于 10 m 小于等于 1 本規(guī)程所有文檔已經完成 8 度量 測試人員和開發(fā)人員統(tǒng)計測試和改錯的工作量 文檔的規(guī)模 以及缺陷的個數(shù)與類型 并 將此度量數(shù)據匯報給項目經理 3 實施建議 對系統(tǒng)測試人員進行必要的培訓 提高他們的測試效率 項目經理和測試小組根據項目的資源 時間等限制因素 設法合理地減少測試的工作量 例如減少 冗余或無效 的測試 系統(tǒng)測試小組根據產品的特征 可以適當?shù)匦薷谋疽?guī)范的各種文檔模板 對系統(tǒng)測試過程中產生的所有代碼和有價值的文檔進行配置管理 為了調動測試者的積極性 建議企業(yè)或項目設立獎勵機制 例如 根據缺陷的危害程度把 獎金分等級 每個新缺陷對應一份獎金 把獎金發(fā)給第一個發(fā)現(xiàn)該缺陷的人 4 系統(tǒng)測試的目標 1 確保系統(tǒng)測試的活動是按計劃進行的 2 驗證軟件產品是否與系統(tǒng)需求用例不相符合或與之矛盾 3 建立完善的系統(tǒng)測試缺陷記錄跟蹤庫 4 確保軟件系統(tǒng)測試活動及其結果及時通知相關小組和個人 5 系統(tǒng)測試的方針 1 為項目指定一個測試工程師負責貫徹和執(zhí)行系統(tǒng)測試活動 2 測試組向各事業(yè)部總經理 項目經理報告系統(tǒng)測試的執(zhí)行狀況 3 系統(tǒng)測試活動遵循文檔化的標準和過程 4 向外部用戶提供經系統(tǒng)測試驗收通過的預部署及技術支持 5 建立相應項目的 BUG 缺陷庫 用于系統(tǒng)測試階段項目不同生命周期的缺陷記錄和 缺陷狀態(tài)跟蹤 6 定期的對系統(tǒng)測試活動及結果進行評估 向各事業(yè)部經理 項目辦總監(jiān) 項目經理匯報 提 供項目的產品質量信息及數(shù)據 6 系統(tǒng)測試的過程 1 軟件項目立項 軟件項目負責人將項目啟動情況通報給測試組長 測試組長指定測試 工程師對該項目進行系統(tǒng)測試跟進和執(zhí)行 2 測試工程師首先參與前期的需求分析活動 前景評審 業(yè)務培訓 SRS 評審 目的是 了解系統(tǒng)業(yè)務及范圍 了解軟件需求及范圍 驗證需求可測性 并將所有收集到的測試需求匯 總并輸出到 測試需求管理表 中 3 測試工程師根據測試需求定義測試策略 并進行工作量估計 4 測試工程師根據測試需求制定測試策略和方法 系統(tǒng)測試工程師參與項目計劃和 SDP 評審 依據項目計劃 或周計劃 編制 系統(tǒng)測試計劃 5 測試組長周期性地根據事業(yè)部項目的測試情況 進行總體測試工作量估計并進行測試 任務分派 6 測試工程師組織 系統(tǒng)測試計劃 評審 測試組長根據評審意見審批 系統(tǒng)測試計劃 7 測試工程師根據 系統(tǒng)測試計劃 中的測試環(huán)境要求搭建測試環(huán)境 特別技術要求的 需要項目組及其它相關職能部門的配合 8 測試工程師檢查測試設計入口條件 根據 用例規(guī)約 補充規(guī)約 界面原型 詞匯表 進行測試用例設計 9 測試工程師組織 系統(tǒng)測試用例 評審 測試組長根據評審意見審批 系統(tǒng)測試用例 10 測試工程師定義系統(tǒng)測試用例執(zhí)行過程 并更新 系統(tǒng)測試用例 11 測試工程師檢查測試執(zhí)行入口條件 從受控庫獲取測試版本 執(zhí)行系統(tǒng)測試并記錄 測試結果 12 系統(tǒng)測試進入產品穩(wěn)定期 由測試工程師召開缺陷評審會議 測試工程師對整個系統(tǒng) 測試過程進行總結和評價 形成 軟件缺陷清單 系統(tǒng)測試評估摘要 系統(tǒng)測試總結報告 并將系統(tǒng)測試過程的文檔報送給項目組和測試組長 測試組長每月初或 事件驅動 匯總 整 編上月的 產品質量簡報 報送給事業(yè)部總經理和項目辦 13 如果根據系統(tǒng)測試結果 產品得以批準通過 系統(tǒng)測試工程師卸載被測軟件 進行環(huán) 境初始化 系統(tǒng)測試結束 轉入驗收測試階段 否則視批示意見進行 六 Test Director 7 6 1 概述 Introduction TestDirector 是 Mercury Interactive 公司推出的基于 WEB 的測試管理工具 無論是通過 Internet 還是通過 Intranet 你都可以以基于 Web 的方式來訪問 TestDirector 應用程序測試是非常復雜的 它需要開發(fā)和執(zhí)行數(shù) 0 以千計的測試用例 通常情況下 測試需要多樣式的硬件平臺 多重的配置 計算機 操作系統(tǒng) 瀏覽器 和多種的應用程序版 本 管理整個測試過程中的各個部分是非常耗時和困難的 TestDirector能夠讓你系統(tǒng)地控制整個測試過程 并創(chuàng)建整個測試工作流的框架和基礎 使整個測試管理過程變得更為簡單和有組織 1 1 測試管理過程 The Test Management Process TestDirector 的測試管理包括如下四個階段 需求定義 Specify Requirements 分析應用程序并確定測試需求 測試計劃 Plan Tests 基于測試需求 建立測試計劃 測試執(zhí)行 Execute Tests 創(chuàng)建測試集 Test Set 并執(zhí)行測試 缺陷跟蹤 Track Defects 報告程序中產生的缺陷并跟蹤缺陷修復的全過程 貫穿測試的每一個階段 你能夠通過產生詳細的報告和圖標對數(shù)據進行分析 1 2 需求定義 Specify Requirements 分析應用程序并確定測試需求 定義測試范圍 Define Testing Scope 檢查應用程序文檔 并確定測試范圍 測試目的 目標和策略 創(chuàng)建需求 Create Requirements 創(chuàng)建需求樹 Requirements Tree 并確定它涵蓋所有的測試需求 描述需求 Detail Requirements 為 需求樹 中的每一個需求主題建立了一個詳細的目錄 并描述每一個需求 給它分 配一個優(yōu)先級 如有必要的話還可以加上附件 分析需求 Analyze Requirements 產生報告和圖表來幫助你分析測試需求 并檢查需求以確保它們在你的測試范圍內 1 3 測試計劃 Planning Tests 基于已定義的測試需求 創(chuàng)建相應的測試計劃 定義測試策略 Define Testing Strategy 檢查應用程序 系統(tǒng)環(huán)境和測試資源 并確認測試目標 定義測試主題 Define Test Subject 將應用程序基于模塊和功能進行劃分 并對應到各個測試單元或主題 構建測試計劃樹 Test Plan Tree 定義測試 Define Tests 定義每個模塊的測試類型 并為每一個測試添加基本的說明 創(chuàng)建需求覆蓋 Create Requirements Coverage 將每一個測試與測試需求進行連接 設計測試步驟 Design Test Steps 對于每一個測試 先決定其要進行的測試類型 手動測試和自動測試 若準備進行手動 測試 需要為其在測試計劃樹上添加相應的測試步驟 Test Steps 測試步驟描述測試的詳細 操作 檢查點和每個測試的預期結果 自動測試 Automate Tests 對于要進行自動測試的部分 應該利用MI 自己或第三方的測試工具來創(chuàng)建測試腳本 分析測試計劃 Analyze Test Plan 產生報告和圖表來幫助你分析測試計劃數(shù)據 并檢查所有測試以確保它們滿足你的測試 目標 1 4 測試執(zhí)行 Running Tests 創(chuàng)建測試集 Test Set 并執(zhí)行測試 創(chuàng)建測試集 Create Test Sets 在你的工程中定義不同的測試組來達到各種不同的測試目標 他們可能包括 舉個例子 在一個應用程序中測試一個新的應用版本或是一個特殊的功能 并確定每個測試集都包括了哪 些測試 確定進度表 Schedule Runs 為測試執(zhí)行制定時間表 并為測試員分配任務 運行測試 Run Tests 自動或手動執(zhí)行每一個測試集 分析測試結果 Analyze Test Results 查看測試結果并確保應用程序缺陷已經被發(fā)現(xiàn) 生成的報告和圖表可以幫助你分析這些 結果 1 5 缺陷跟蹤 Tracking Defects 報告程序中產生的缺陷并跟蹤缺陷修復的全過程 添加缺陷 Add Defects 報告程序測試中發(fā)現(xiàn)的新的缺陷 在測試過程中的任何階段 質量保證人員 開發(fā)者 項目經理和最終用戶都能添加缺陷 檢查新缺陷 Review New Defects 檢查新的缺陷 并確定哪些缺陷應該被修復 修復打開的缺陷 Repair Open Defects 修復那些你決定要修復的缺陷 測試新構建 Test New Build 測試應用程序的新構建 重復上面的過程 直到缺陷被修復 分析缺陷數(shù)據 Analyze Defect Data 產生報告和圖表來幫助你分析缺陷修復過程 并幫助你決定什么時候發(fā)布該產品 1 6 用戶權限 User Privileges TestDirector允許你管理用戶訪問工程的權限 它會創(chuàng)建一個有權用戶的列表和為一個組 或者是一個用戶分配一個口令 你可以控制每個用戶能夠對項目進行怎樣的添加和修改 在 TestDirector中用戶所擁有的權利是由該用戶所在的用戶組決定的 TestDirector 允許你為工程中 指定的目錄創(chuàng)建包含特權和許可機制的規(guī)則 一些有用的信息可能在TestDirector的用戶組中被 用到 關于 TestDirector 中的用戶組 口令分配和權限的更詳細的信息 請參考 TestDirector 管理員 手冊 TestDirector Administrator s Guide 2 開始 Getting Started 2 1 啟動 TestDirector Starting TestDirector 1 打開 Web 瀏覽器并輸入 TestDirector 所在的 URL http Server name virtual Directory name default htm TestDirector 的首頁將被打開 2 點擊 TestDirector 鏈接 在你第一次運行TestDirector時候 軟件將會被下載到你的計算機上 隨后 TestDirector會自動進行版本檢查 若發(fā)現(xiàn)存在新的版本 它將會幫你下載新的版本 一旦TestDirector進行完版本檢查和更新 假如需要的話 TestDirector的登陸頁 面將被顯示 3 在域列表中選擇你想進入的域 Domain 選擇名為 DEFAULT 的默認域 在 project 工程列表中選擇一個工程 若 TestDirector 的示例工程已經被安裝在 TestDirector 的服務端 你則可以選擇名為 TestDirector Demo 的工程 確信你在 Domain 列表中已經選擇了 DEFAULT 域 此工程會為你介紹 TestDirector 包括需求 測試 測試集 Test Runs 以及缺陷 4 在 User ID 框中 選擇或輸入你的用戶名稱 注意 User ID 列表信息是與客戶端本身所在的機器有關的 故你在 某臺機器上 第一 次登陸 TestDirector 時 應該輸入你的用戶名 5 在 Password 框中 輸入管理員指派給你的密碼 若是第一次以 Admin 的身份登陸 你不 需要輸入密碼 此時密碼為空 6 點擊 按鈕 TestDirector 會打開在你上一次運行 TestDirector 任務時所用過 的那些模塊 需求 測試計劃 測試實驗室和缺陷 7 對于退出和返回到 TestDirector 登陸窗口 請點擊在右上角的 按鈕 2 2 TestDirector 窗口 The TestDirector Window 當你打開一個工程時 TestDirector 的主窗口會打開你上次工作時使用過的模塊 在標題 欄 TestDirector 會顯示工程名稱和你的用戶名 TestDirector 包含如下幾個模塊 需求 Requirements 定義測試需求 包括定義你正在測試的內容 定義需求的主題和條目并分析這 些需求 測試計劃 Test Plan 開發(fā)一個測試計劃 包括定義測試目標和策略 將測試計劃分為不同的類別 對測 試進行定義和開發(fā) 定義哪些需要自動化測試 將測試與需求 進行連接和分析測試計劃 測試實驗室 Test Lab 運行測試并分析測試結果 缺陷 Defects 增加新缺陷 確定缺陷修復屬性 修復打開的缺陷和分析缺陷數(shù)據 技巧 你可以在兩個模塊間利用快捷鍵進行切換 用 Ctrl Shift 1 來訪問需求模塊 用 Ctrl Shift 2 來訪問測試計劃模塊 如此類推 所有的 TestDirector 模塊都包括如下內容 TestDirector 工具欄 TestDirector Toolbar 位于 TestDirector 工程名的緊上面 假如此工具欄不可見 請點擊 Show Toolbar 按鈕 關于 TestDirector 工具欄的更多信息 請查看第 18 頁的 TestDirector 工具欄 菜單欄 Menu Bar 位于 TestDirector 工程名的緊下面 菜單名稱隨你選擇的模塊名稱不同而改變 模塊工具欄 Module Toolbar 位于菜單欄下面 包括當前所使用 TestDirector 模塊中經常使用到的命令 工具按鈕 Tools Button 位于窗口的右上角 能夠讓你改變用戶密碼和另外的一些用戶屬性 change the language direction for a user in a project from left to right or right to left 清楚歷史數(shù)據 查看每一個 TestDirector 客戶端組件的版本 信息或打開文檔引擎 關于文檔引擎的更進一步信息 請查看第 28 章 產生工程文檔 Generating Project Documents 關于定制工具菜單請查看 TestDirector 安裝手冊 TestDirector Installation Guide 幫助按鈕 Help Button 位于窗口的右上角 能夠通過它訪問 TestDirector 的在線資源 關于定制幫助菜單 請查看 TestDirector 安裝手冊 TestDirector Installation Guide 2 3 TestDirector 工具欄 The TestDirector Toolbar 公用的 TestDirector 工具欄對所有的 TestDirector 模塊都是適用的 包含如下的一些按鈕 返回 Back 返回到先前 TestDirector 所在的位置 前進 Forward 假如你已經使用了返回的導航按鈕 你可以使 用前進按鈕返回回來 導航按鈕 首頁 Home 登出并且進入 TestDirector 登陸窗口 拼寫檢查 Check Spelling 為所選中的單詞或文本框作拼寫檢查 假如不存在錯誤 一個確認的消息將被彈出 假如錯誤被發(fā)現(xiàn) 將會彈出對話框顯示相應的 提示信息 拼寫選項 Spelling Options 打開拼寫選項對話框 并能夠讓你對 TestDirector 的拼寫檢查執(zhí)行方式進行配置 拼寫按鈕 辭典 Thesaurus 打開辭典對話框 并顯示所選中單詞的同義 近義或反義詞 你能夠替換掉所選擇的詞或查 找新的詞 缺陷按鈕 增加缺陷 Add Defect 打開增加缺陷對話框 并能夠讓你增加一個新 的缺陷 關于更進一步的信息 請查看第 25 章 增加 和跟蹤缺陷 Adding and Tracking Defects 幫助按鈕 幫助按鈕 Help Button 打開在線幫助并為當前的內容顯示幫助主題 2 4 修改密碼 Changing Passwords 1 在窗口右上角 點擊 Tools 按鈕并選擇 Change Password 菜單項 或者在工程定制窗口點 擊 Change Password 鏈接 修改用戶密碼的對話框將被彈出 2 在 Old Password 框中輸入你的舊密碼 3 在 New Password 框中輸入你的新密碼 4 在 Retype New Password 框中重新輸入你的新密碼 5 點擊 OK 關閉修改密碼對話框 2 5 修改用戶屬性 Changing User Properties 你能夠修改你的用戶屬性信息 包括全名 Email 地址 電話號碼和描述信息 注意 Email 地址信息是非常重要的 因為能夠直接通過你的郵箱 讓你接收到缺陷 需求和測試集 的信息 1 在窗口右上角 點擊 Tools 按鈕并選擇 Change User Properties 菜單項 或者在工程定制 窗口點擊 Change User Properties 鏈接 用戶屬性對話框將被彈出 2 編輯如下的用戶屬性 Full Name Email Phone Description 3 點擊 OK 按鈕 保存你的修改 2 6 清除歷史記錄 Clearing History 在自定義 TestDirector 工程時 你可以要求 TestDirector 來保存系統(tǒng)中的日志信息 以及在 需求 測試和缺陷實體中的用戶字段 產生的歷史記錄數(shù)據會被顯示在需求 測試計劃和缺陷 模塊的歷史記錄屬性頁上面 對于更多關于為 TestDirector 域設置歷史記錄的信息 請查看 TestDirector 管理員手冊 TestDirector Administrator s Guide 一旦你不想存儲歷史數(shù)據 TestDirector 允許你將這些歷史數(shù)據從 TestDirector 工程中刪除 舉個例子 假如你已經成功地運行了你創(chuàng)建的測試集 你可能想從 TestDirector 工程中清除這 些歷史記錄 你能夠清除所有的歷史記錄 或指定實體或域的歷史記錄 另外 你能夠讓 TestDirector 僅刪除直到某一天 包括這一天 的歷史記錄 TestDirector 所清除的歷史記錄顯示在各自模 塊的 History 屬性頁下 注意 默認狀態(tài)下 只要具有管理員權限的用戶才能夠清除歷史記錄 用戶權限是能夠被定制 的 清除歷史記錄 1 在窗口右上角 點擊 Tools 按鈕并選擇 Clear History 菜單項 清除歷史記錄對話框將被彈 出 2 在 Entity 框中 選擇你準備刪除歷史記錄所屬的實體 若你準備刪除需求 測試和缺陷實 體的歷史記錄 請選擇 All 3 在 Field 框中 選擇你準備刪除的歷史記錄所在的字段 若想刪除歷史記錄的所有字段 請選擇 All 4 在 Until Date 框中 選擇一個日期 TestDirector 所刪除直到所選擇日期的歷史記錄 包括 所選擇日期當天 5 點擊 OK 3 需求定義工作流 你應該通過定義測試需求來開始整個應用程序的測試過程 需求詳細地描述了在你的應用 程序中哪些需要被測試 并為測試組提供了整個測試過程的基礎 通過定義這些需求 你能夠更好地聚焦于商業(yè)需要對測試進行計劃和管理 需求與測試和 缺陷關聯(lián) 從而確保整個過程可追溯并幫助整個過程的決策 本章描述了怎樣使用 TestDirector 需求模塊來定義測試需求 以下是需求定義工作流的流 程圖 在使用 TestDirector 之前 首先確保你已經有一個存放測試數(shù)據的工程 3 1 定義測試范圍 Defining the Testing Scope 測試組在基于測試的測試應用的基礎上 收集所有可以利用的文檔信息 開始測試處理過 程 例如收集市場和商務需求文檔 系統(tǒng)需求說明書和設計文檔等 使用這些文檔您可以對應用程序的測試方面作一個全面徹底的了解 并以此為基礎來確定 你的測試范圍 測試目的 目標和策略 Goal Objective Strategy 在確定您的測試范圍之前你應該先問一下自己 以下的幾個問題 應用程序的主要目的和反向是什么 應用程序有哪些主要特點 哪些功能在這個產品中是相對重要的 在應用程序中 哪些功能是危急的或高風險的 你的測試優(yōu)先級是什么 你的客戶或最終用戶是否同意你的測試優(yōu)先級 你總的質量目標是什么 3 2 創(chuàng)建測試需求大綱 Creat Requirements 質量保證的管理人員用測試范圍為應用程序的測試定義所有的測試需求 他們先定義測試 主題 并將各個測試主題指派給測試組內的各個 QA 測試人員 然后每一個 QA 測試人員將自 己所負責的測試主題記錄到 TestDirector 工程上 需求主題是通過創(chuàng)建需求樹記錄在需求模塊里 此需求樹是以圖表的方式形象地描述了你 的需求說明書 并顯示了不同級別需求的等級關系 舉個例子 假設一個航班預定軟件 它能夠讓你去管理航班調動 旅客登記和機票銷售 QA 管理人員可能會定義他主要的測試需求為 登陸操作 數(shù)據庫操作 傳真發(fā)送操作 安全 性能力檢查 圖形和報表操作 UI 檢查操作和幫助 對于完整的例子 請查看 TestDirector Demo 工程 3 3 定義需求 Detail Requirements 對于每一個需求主題 QA 測試員均應該創(chuàng)建相應的詳細測試需求列表 例如 Application Security 需求主題可能會被分解為如下的需求 在需求樹中的每一個需求均要求被詳細描述 并且應該包括所有與需求相關的附件 QA 測試人員分配每個需求一個優(yōu)先級 此優(yōu)先級會作為測試組創(chuàng)建測試計劃的一個考慮因素 3 4 分析需求定義 Analyz Requirements QA 管理人員復查這些需求 并確定測試范圍被更早的定義 他們還應該將需求的狀 態(tài)改為 Reviewed 假如這個需求被評審通過的話 你應該產生 TestDirector 報告和圖表來幫助你評審需求 對于更多信息 請查看 26 章 產生報告 Generating Reports 和 27 章 產生圖表 Generating Graphs 在隨后的測試計劃中 你應該使用這些需求作為基礎 你在測試計劃階段所創(chuàng)建的測 試也應該覆蓋這些需求 關于需求和測試覆蓋的更多信息 請查看第 12 章 連接測試到需求 Linking Tests to Requirements 這些測試也能夠被缺陷進行關聯(lián) 從而在整個測試過程形成 完整的回溯 4 需求模塊一覽 4 1 需求模塊 The Requirements Module 你可以在 TestDirector 中點擊 Requirements 標簽頁來定義你的需求 你可以用 Document View 或 Coverage View 兩種方式來顯示需求樹 注意 你可以從 Microsoft Word Excel 或第三方的需求管理工具中導入需求到你的 TestDirector 工程 對于導入需求 你必須首先安裝相應的 TestDirector 插件 對于更詳細信息 請查看 TestDirector 安裝手冊 TestDirector Installation Guide 默認情況下 需求模塊是以文檔視圖方式顯示需求樹 你也可以以覆蓋視圖方式顯示需求樹 這種方式能夠讓你更容易地為需求增加或修改測試 覆蓋 對于測試覆蓋的更多信息 請看第 12 章 連接測試到需求 Linking Test to Requirements 需求模塊包括如下的核心元素 Requirements Menu Bar 需求菜單欄 具有需求模塊命令的下拉菜單 Requirements Toolbar 需求工具欄 具有創(chuàng)建或修改需求樹的常用命令按鈕 View Box 視圖選擇框 能夠讓你去選擇需求樹的顯示方式 文檔視圖或覆蓋視圖 Requirements Tree 需求樹 你的測試需求的一種圖形表達 更詳細信息請看 60 頁的需 求樹 The Requirements Tree Description Tab 描述標簽頁 顯示當前所選擇需求的注釋 僅在文檔視圖中有效 點 擊 Show 箭頭去顯示描述面板 History Tab 歷史標簽頁 顯示當前所選擇需求的歷史操作列表 Tests Coverage Tab 測試覆蓋標簽頁 顯示了在需求樹上 當前所選擇的需求的測試列 表 僅適用于覆蓋視圖 Details Tab 細節(jié)標簽頁 顯示了在需求樹上當前樹選擇需求的詳細描述 僅適用于覆 蓋視圖 4 2 需求菜單欄 The Requirements Menu Bar 需求菜單欄包括如下的菜單 Requirements 菜單 包括命令 在需求樹上修改需求 從一個需求產生一個測試 Mail 一個需求 View 菜單 包括命令 設置需求樹的顯示 查找一個需求 瀏覽測試覆蓋 關聯(lián)缺陷 附件 Tools 菜單 包括命令 轉換需求到測試 Analysis 菜單 包括命令 產生需求報告和圖表 關于需求報告的更詳細信息 請看第 26 章 產生報告 Generating Reports 關于需求圖表的更詳細信息 請看第 27 章 產 生圖表 Generating Graphs 4 3 需求工具欄 The Requirements Toolbar 需求工具欄包括如下的按鈕 New Requirements 新建需求 增加一個新的需求到需求樹 TestDirector 將增加此 需求到當前所選擇的需求下面 并處于相同等級 New Child Requirements 新建子需求 增加一個新的需求到需求樹 TestDirector 將 增加此子需求到當前所選擇的需求下面 并處于低一級的級別 Cut 剪切 移動所選擇的需求到需求樹的新位置 要與 Paste 按鈕聯(lián)合使用 Copy 拷貝 拷貝所選擇的需求到需求樹的另外位置或另外的 TestDirector 工程 需 要與 Paste 按鈕聯(lián)合使用 Paste 粘貼 粘貼一個剪切或拷貝的需求到需求樹的另外位置 點擊 Paste 箭頭并選擇 Paste 去粘貼需要到當前所選擇的需求下面 以相同的級別 點擊 Paste 箭頭并選擇 Paste as Child 去粘貼需要到當前所選擇的需求下面 以低一級的 級別 Delete 刪除 從需求樹中刪除所選擇的需求 Refresh Selected 刷新 刷新在需求模塊中的數(shù)據 點擊 Refresh Selected 按鈕 去刷新當前所選擇的需求 所有子需求也會被同時刷新 點擊 Refresh Selected 箭頭并選擇 Refresh All 去刷新所有的需求 Select Columns 選擇列 打開選擇列對話框 你可以決定哪些字段顯示在需求樹中 并決定它們的顯示順序 Zoom in 展開 改變需求樹的細節(jié)等級 點擊 Zoom In 按鈕去展開需求樹的指定分支 點擊 Zoom In 箭頭并選擇 Zoom Out One Level 去取消預先展開的命令 點擊 Zoom In 箭頭并選擇 Zoom Out To Root 去收縮 并顯示整個需求樹的根結點 Find 查找 打開查找需求對話框 能夠讓你在需求樹中查找你想要的需求 Mail Requirement Mail 需求 打開發(fā)送郵件對話框 你可以從郵件列表中選擇收件 人 或輸入其它的郵件地址 發(fā)送需求郵件 Attachments 附件 打開附件對話框 能夠讓你為所選擇的需求添加附件 對于更 多信息 請看第 4 章 增加附件 Adding Attachments Test Coverage 測試覆蓋 打開測試覆蓋對話框 能夠讓你為選定的測試需求增加測 試覆蓋 注意 你也能夠右鍵點擊一個需求 并選擇 Associated Defects 去瀏覽有測試覆 蓋需求的所有缺陷關聯(lián) 4 4 需求樹 Requirements Tree TestDirector 在需求樹中有機的組織并顯示數(shù)據 需求樹中每一行都顯示了一條獨立的需 求 需求樹中可以顯示如下細節(jié)信息 選項 描述 附件 Attachment 指示本需求是否包含附件 此字段值可以為 Y 或 N 作者 Author 創(chuàng)建此需求的用戶名 默認情況 TestDirector 插入登陸用戶名到此字段 覆蓋狀態(tài) Cover Status 需求當前的狀態(tài) 默認情況下 狀態(tài)為 Not Covered 一個需求的狀態(tài)能夠是如下幾種 Not Covered 這個需求沒有被鏈接到測試 Failed 覆蓋此需求的一個或多個測試被執(zhí)行 且狀態(tài)為 Failed Not Completed 覆蓋此需求的一個或多個測試被執(zhí)行 且狀態(tài) 為 Not Completed Passed 覆蓋此需求的所有測試均有同樣狀態(tài) Passed No Run 覆蓋此需求的所有測試均有同樣狀態(tài) No Run 你能夠點擊一下 State 去打開你所選擇需求的測試覆蓋對話框 關 于覆蓋的更詳細信息 請看第 12 章的 連接測試到需求 Linking Tests to Requirements 創(chuàng)建日期 Creation Date 需求被創(chuàng)建的日期 默認情況下 創(chuàng)建日期被設置為當前服務器日 期 你也可以點擊下拉箭頭去顯示一個日歷 并選擇一個不同的創(chuàng) 建日期 創(chuàng)建時間 Creation Time 需求被創(chuàng)建的時間 默認情況下 創(chuàng)建時間被設置為當前服務器的 時間 修改 Modified 標識此需求被最后修改的時間 名稱 Name 需求名 優(yōu)先級 Priority 需求的優(yōu)先級 范圍從最低級別 Level 1 到最緊急級別 Level 5 產品 Product 需求所基于的應用程序組件 需求 ID Req ID 需求的唯一數(shù)字 ID 右 TestDirector 自動分配 注意 需求 ID 是只讀的 復查 Reviewed 標識此需求是否被復查 并且被責任人批準通過 類型 Type 需求的類型 可以是 Hardware 或 Software 注意 你可以改變需求樹中任何字段的標簽 也可以增加最多 24 個用戶自定義的域到需 求樹中 更進一步信息 請看 TestDirector 管理員手冊 TestDirector Administrator s Guide 5 開發(fā)需求樹 Developing Requirements Tree 5 1 創(chuàng)建需求樹 Creating a Requirements Tree 你可以通過創(chuàng)建需求樹來定義你的需求 創(chuàng)建需求樹 1 在需求模塊的工具欄上點擊 New Requirement 按鈕 或者選擇 Requirements New Requirement 注意 假如需求字段已經在工程自定義窗口中定義 則 New Requirement 對話框將被打 開 為不要的字段選擇值 并點擊 OK TestDirector 將增加一個默認名稱為 New Requirement 的新需求到需求樹中 2 為新的需求輸入一個名稱 并按 Enter 注意 需求名稱中不能夠包括字符 3 為需求添加需求細節(jié) 關于在需求樹中的有效字段的更詳細信息 請看第 7 章 需求模塊 一覽 The Requirements Module at a Glance 4 在 Description 面板中 輸入新需求的描述信息 5 點擊 Attachments 按鈕或選擇 View Attachments 為新需求添加附件 附件可以是文件 URL 應用程序的快照 剪貼板中的圖像或系統(tǒng)信息 TestDirector 會在需求樹中 緊挨 著需求名放置一個可點擊的附件圖標 對于更多信息 請查看第 4 章 添加附件 Adding Attachments 6 點擊 Tests Coverage 按鈕 或選擇 View Tests Coverage 為需求添加測試覆蓋 測試覆蓋定義了測試計劃樹中的測試并能夠讓你連接測試需求到測試 你僅僅只有當在測 試計劃期間創(chuàng)建測試后 才能夠定義測試覆蓋 關于測試覆蓋的更詳細信息 請看第 12 章 連接測試到需求 Linking Tests to Requirements 7 添加另外的需求到需求樹 點擊 New Requirement 按鈕 在當前需求下面添加同等級需求 點擊 New Child Requirement 按鈕 在當前需求下面添加低一級的需求 5 2 查看關聯(lián)缺陷 Viewing Associated Defects 選擇 View Associated Defected 或右鍵點擊一個需求 并選擇 Associated Defected 關 聯(lián)缺陷對話框將被彈出 5 3 從需求創(chuàng)建測試 Creating Tests from Requirements 一旦你創(chuàng)建了需求樹 你可以用這些需求作為基礎 在測試計劃樹中定義測試 并在測試 集中運行測試 從需求創(chuàng)建測試有如下兩種方法 轉換需求到測試 Convert Requirement to Tests 轉換需求到測試計劃樹中指定主 題的測試 你可以轉換需求樹中的所選定的需求或所有需求 這種方法使用轉換到測試向導 幫 助你設計測試計劃樹 詳見第 77 頁的轉換需求到測試 Convert Requirement to Tests 從需求產生測試 Generate a Test from Requirements 轉換需求到測試計劃樹中 指定主題的測試 并添加到測試實驗室模塊指定的測試集中 這種方法使用產生測試對話框 在你分析需求時 能夠幫你迅速運行測試 詳見第 81 頁的從需求產生測試 Generate a Test from Requirements 轉換需求到測試 使用轉換到測試向導 轉換需求到測試計劃樹中指定主題的測試 1 你可以轉換需求樹中指定的需求或全部需求 轉換所有需求 選擇 Tools Convert to Test Convert All 轉換指定的需求 在需求樹中選擇所要轉換的需求 并選擇 Tools Convert to Tests Convert Selected Step 1 對話框將被打開 2 選擇一種自動轉換方法 選擇 Convert lowest child requirements to design steps 將所有最低級別的子需求轉 換為設計步驟 高一級別的轉換為測試 所有更高級別的轉換為主題 選擇 Convert lowest child requirements to tests 將所有最低級別的子需求轉換為測 試 所有高級別的轉換為主題 選擇 Convert all requirements to subjects 將所有選擇的需求轉換為主題 3 點擊 Next 去開始轉換需求 若想取消轉換并返回到步驟 1 點擊進度條上的 Stop 按鈕 當轉換過程完成 轉換結果將被顯示在 Step 2 對話框中 注意 假如你僅僅只轉換單個需求 向導將會跳過此對話框 4 查看向導圖例 點擊 Legend 鏈接 5 對每一個轉換項 你能夠做如下操作 選擇一個項 并點擊 Exclude 按鈕 或右鍵點擊該項 并選擇 Exclude 將此項從 測試計劃樹中刪除 選擇一個項 并點擊 Subject 按鈕 或右鍵點擊該項 并選擇 Subject 將選擇的 項改變?yōu)橐粋€主題 子項將變?yōu)橹黝}或測試 注意 主題名稱必須唯一 現(xiàn)在一個項 并點擊 Test 按鈕 或右鍵點擊該項 并選擇 Test 將選擇的項改變 為一個測試 子項將被轉換為測試步驟 注意 測試名稱必須唯一 選擇一個項 并點擊 Step 按鈕 或右鍵點擊該項 并選擇 Step 將所選擇的項改 變?yōu)闇y試步驟 子項將被轉換為步驟的描述 選擇一個項 并點擊 Desc 按鈕 或右鍵點擊該項 并選擇 Desc 將所選擇的項改 變?yōu)椴襟E描述 子項將被轉換為縮進的描述文本 6 當你作修改時 若不希望使用向導 將默認選中的 Auto Complete Children 選擇項取消 假如此項被選中 你在改變父級別時 如從主題改變?yōu)闇y試 向導會自動轉換所有子項的 級別 如從測試到測試步驟 7 點擊 Next 步驟 3 的對話框將