天測(cè)試工程師成功之路指導(dǎo)手冊(cè).doc

《天測(cè)試工程師成功之路指導(dǎo)手冊(cè).doc》由會(huì)員分享，可在線閱讀，更多相關(guān)《天測(cè)試工程師成功之路指導(dǎo)手冊(cè).doc（176頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

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