【正文】 維護企業(yè)的軟件及測試程序資產(chǎn)、維護軟件項目的“經(jīng)驗教訓(xùn)” 數(shù)據(jù)庫、維護測試工具評估結(jié)果及自動測試代碼庫。 167。 1測試組的組織結(jié)構(gòu) 六、測試組小結(jié) （一） 測試組的比較 ? 測試組的結(jié)構(gòu)依賴于幾個條件，其中包括企業(yè)的文化氛圍。 ? 測試組組織最重要的結(jié)果是過程成熟度及軟件測試能力持續(xù)改進的可能性。 ? 項目結(jié)束后，測試組織結(jié)構(gòu)的意義在于能否將測試過程、程序、工具知識等保留在企業(yè)，并可將這些知識帶入到新項目中。 167。 1測試組的組織結(jié)構(gòu) 六、測試組小結(jié) （二） 成功測試組的 10大因素 1．業(yè)務(wù)知識 測試工程師需要具備業(yè)務(wù)知識并與系統(tǒng)的用戶及客戶緊密接觸。 2．技木知識 應(yīng)用是非常復(fù)雜的，而且為了更好地理解應(yīng)用中的復(fù)雜技術(shù)，還必須掌握自動測試工具及技術(shù)背景。 3．任務(wù)劃分 將業(yè)務(wù)任務(wù)與技術(shù)任務(wù)相互獨立。 167。 1測試組的組織結(jié)構(gòu) 六、測試組小結(jié) 4．資源管理 業(yè)務(wù)資源及技術(shù)資源可以相互結(jié)合。 5．與開發(fā)組的關(guān)系 測試工程師與開發(fā)人員協(xié)同工作。 6．生存周期早期介入 測試組在開發(fā)生存周期的早期介入。 7．確定測試方法 方法、標準及過程必須按照需要就位、執(zhí)行、修改。 167。 1測試組的組織結(jié)構(gòu) 五、測試組小結(jié) 8．靈活性／適應(yīng)性 每個應(yīng)用都是不相同的。在一個項目中成功的測試策略在另一個項目中可能失敗。 9．度量 測試組需要掌握收集哪些度量，并利用這些度量改進測試程序。度量需要在整個開發(fā)生存周期中收集。 10．過程改進 測試組致力于所確定的測試方法的不斷改進。 167。 1測試組的組織結(jié)構(gòu) 七、企業(yè)如何組織測試人員 企業(yè)如何組織測試人員應(yīng)當視企業(yè)的人力資源而定（我國目前企業(yè)） – 條件特別好的公司 ， 可以按照集中測試組及更高的要求組織測試團隊 。 甚至可以為每 12個開發(fā)人員分配一名獨立的測試人員 。 這樣的測試人員職業(yè)化程度很高 ， 可以完成單元測試 、 集成測試和系統(tǒng)測試工作 ， 能夠?qū)崿F(xiàn)開發(fā)與測試同步進行 。 – 條件比較好的公司 ， 可以設(shè)置一個 獨立的測試小組 ，該測試小組輪流參加各個項目的系統(tǒng)測試 。 而單元測試 、 集成測試工作由項目的開發(fā)小組承擔 。 167。 1測試組的組織結(jié)構(gòu) 七、企業(yè)如何組織測試人員 – 條件一般的公司 ， 養(yǎng)不起獨立的測試小組 。 單元測試 、 集成測試工作由項目開發(fā)小組承擔 。 當項目進展到系統(tǒng)測試階段 ， 可以從項目外抽調(diào)一些人員 ，加上開發(fā)人員 ， 臨時組織系統(tǒng)測試小組 。 – 條件比較差的公司 ， 也許只有一個項目和為數(shù)不多的一些開發(fā)人員 。 那么就讓開發(fā)人員一直兼任測試人員的角色 ， 相互測試對方的程序 。 如果人員實在太少了 ， 只好讓開發(fā)者測試自己的程序 ， 有測試總比沒有測試好吧 ！ 167。 2 測試任務(wù) 測試工作分解結(jié)構(gòu)表 描述了可被執(zhí)行的測試任務(wù)的不同類型。 測試工作結(jié)構(gòu)分解表分成 11個大類， 95個子類。11個大類為： 項目啟動、早期項目支持、自動測試決策、測試工具的選擇及評估、測試工具引入、測試計劃、測試設(shè)計、測試開發(fā)、測試執(zhí)行、測試管理及支持、測試過程改進。 1 項目啟動 1． 1 過程改進 。 評審從以往的相似項目中獲取的經(jīng)驗教訓(xùn) ， 以便建議的改進活動 。 確定需要執(zhí)行的改進活動 1． 2 過程 。 掌握自動測試生存周期方法學(xué) (ATLM)的所有內(nèi)容 1． 3 范圍 。 概述初步的測試目標和目的 1． 4 規(guī)模 。 測試工作的規(guī)模 1． 5 測試組組成 。 承擔測試組的組成分析和撰寫測試工程師任務(wù)描述 1． 6 招聘 。 編寫測試工程師招聘廣告和執(zhí)行面試 2 早期項目支持 2． 1 目標／目的 。 進一步確定測試目標和目的 ， 并同項目管理 、 開發(fā)組和測試工程師一起評審目標／目的 ， 以建立便于理解的 、 可以接受的測試目標和目的 2． 2 約束評審 。 評審項目的約束條件 ， 例如短期內(nèi)投放市場及資源限制等 2． 3 可測試性評審 。 確保應(yīng)用中考慮了可測試性 2． 4 需求評審 。 確保需求是按可測試性的術(shù)語規(guī)定的 2． 5 標準評審 。 確定并熟悉可應(yīng)用的標準 。 確定標準是否需要根據(jù)以往的經(jīng)驗進行調(diào)整對缺少的標準進行定義 2． 6 測試過程分析 。 分析企業(yè)當前的測試過程 2． 7 客戶參與 。 保證客戶在測試生存周期中自始至終參與 3 自動測試決策 3． 1 測試目的策略 。 細化測試目的的定義并制定測試策略 3． 2 測試工具價值 。 概述使用自動測試工具所帶來的價值／利益 3． 3 測試工具使用建議 。 就測試工具的使用提出建議， 獲得管理人員的支持 4 測試工具的選擇及評估 4． 1 系統(tǒng)工程環(huán)境 。 評審企業(yè)的系統(tǒng)工程環(huán)境 4． 2 可得到的測試工具 。 評審可得到的測試工具的類型 4． 3 候選測試工具 。 研究 、 評估候選測試工具并打分 4． 4 定義評估范圍 4． 5 親自評估工具 4． 6 測試工具評估報告 。 報告工具選擇及評估結(jié)果， 并形成文檔 4． 7 測試工具采購 。 與采購部門一起制定采購訂單 167。 2 測試任務(wù) 測試組可能希望將表中的元素 8． 7和 9． 3進行細分，以便按照不同的測試子類型描述測試程序 /腳本的開發(fā)及執(zhí)行情況。 可能的測試子類型包括功能需求測試、服務(wù)器性能測試、 用戶界面測試、性能測試、程序模塊復(fù)雜性分析、程序代碼覆蓋測試、系統(tǒng)裝載性能測試、 邊界測試、安全性測試、內(nèi)存泄漏測試以及響應(yīng)時間性能測試等等。 167。 2 測試任務(wù) 表中描述的工作分解結(jié)構(gòu) (WBS)可與可與完成該項工作實際用時對應(yīng)起來，以開發(fā)一個記錄完成項目不同活動所需工作量的歷史記錄。維護這個歷史記錄對于測試規(guī)模的計算是很有價值的，它可用于評估新項目的測試工作量。 167。 3 測試工作規(guī)模 影響一個給定項目測試工作的因素有很多，例如企業(yè)的文化氛圍或成熟程度、項目所定義的測試需求的范圍、測試人員的測試技術(shù)水平以及測試組的組織類型。 測試成熟度模型 (TMM)根據(jù)企業(yè)的測試成熟程度來確定一個項目的測試工作等級 。 人力資源的耗費也會由于企業(yè)測試成熟程度的不同而不同 。 167。 3 測試工作規(guī)模 一、測試成熟度模型 (TMM)簡介 ? 測試成熟度級別 1。 在測試成熟度級別 l中 ， 測試工作僅限于調(diào)試 。 程序員對書寫的軟件進行調(diào)試 ， 直到能夠正常工作為止 。 因為只有程序員參與該工作 ， 因而費用往往隱藏在開發(fā)費用中 。 同樣 ，良好測試所帶來的潛在好處也隱藏在現(xiàn)場支持及產(chǎn)品升級的費用中 。 測試成熟度級別 l的真實測試費用是很難計算的 。 167。 3 測試工作規(guī)模 一、測試成熟度模型 (TMM)簡介 ? 測試成熟度級別 2。 處于測試成熟度級別 2的軟件測試是一項獨立的工作。測試計劃及腳本通常是由有經(jīng)驗的產(chǎn)品用戶或支持人員來開發(fā)的。這些人員也許具備，也許不具備自動 (編程 )測試經(jīng)驗。不論屬于何種情況，測試人員都必須徹底了解軟件需求和設(shè)計說明，以便制定便于理解的測試計劃，并開發(fā)與之關(guān)聯(lián)的腳本。如果測試腳本存在，就應(yīng)該提交給運行腳本并記錄結(jié)果的測試工程師。 167。 3 測試工作規(guī)模 一、測試成熟度模型 (TMM)簡介 ? 在級別 2中，測試組可能包括一些新手，他們是缺乏相關(guān)經(jīng)驗的最終用戶或者具備相關(guān)功能知識的人員。這些人員的工作是就是設(shè)法使系統(tǒng)中斷，實際上也是為了保證系統(tǒng)能夠正常工作。 ? 在級別 2中，測試工作可能需要一個或多個高級支持人員的服務(wù)，他協(xié)調(diào)測試文檔的編寫、對測試工程師進行管理并對結(jié)果進行編輯。雖然，一次性的啟動費用便可實現(xiàn)捕獲／回放工具，但如果測試周期數(shù)量增多，就會需要投入更多的資金。在后面的測試周期中，測試腳本可以重用，還可以自動回放，這樣在腳本的開發(fā)及執(zhí)行方面節(jié)省了大量的勞動力。 167。 3 測試工作規(guī)模 一、測試成熟度模型 (TMM)簡介 ? 測試成熟度級別 3～ 5。 在高級別的測試成熟度中，負責制定測試計劃的測試工程師應(yīng)當參與設(shè)計工程師的產(chǎn)品開發(fā)會議，幫助在產(chǎn)品中建立可測試性。測試工程師的編程背景與他或她對產(chǎn)品的熟悉程度將有助于提高后續(xù)建立的測試的有效性，以便找出產(chǎn)品最薄弱的環(huán)節(jié)。如果測試工具具有白盒測試能力，那么測試工程師可以利用他或她在系統(tǒng)內(nèi)部工作的有關(guān)知識確定不能手工進行測試的功能。測試計劃有助于將測試設(shè)計的結(jié)果形成文檔。測試設(shè)計為測試工程師開發(fā)測試腳本程序提供指南。 167。 3 測試工作規(guī)模 一、測試成熟度模型 (TMM)簡介 ? 測試腳本的開發(fā)工作是由測試工程師或應(yīng)用程序員完成的。編程所需的經(jīng)驗級別依賴于所使用的工具以及測試的復(fù)雜程度。一般情況下，最具通用性的工具，它使用通用的腳本編程語言，例如 C。而其他工具則可能使用簡單的編程語言。不論是何種情況，測試組中至少要有一名成員必須在編寫結(jié)構(gòu)化程序方面有經(jīng)驗。自動工具用于自動生成測試日志、缺陷文檔以及生成測試狀念輸出。這些工具在測試的執(zhí)行及管理方面節(jié)省了大量的勞動力。 167。 3 測試工作規(guī)模 二、測試組規(guī)模確定方法 ? 概述 根據(jù)測試工作量確定測試組規(guī)模的方法有好幾種 。 （ 傳統(tǒng)方法 、 商業(yè)評估工具法 ） （ 1） 傳統(tǒng)的方法是 ， 軟件開發(fā)程序已重點對開發(fā)工作量及整個項目的工作量做了估計 。 產(chǎn)品質(zhì)量保證所需的工作量 ， 例如軟件測試 ， 可根據(jù)預(yù)期的開發(fā)工作量和全部的項目工作量確定 。 167。 3 測試工作規(guī)模 二、測試組規(guī)模確定方法 （ 2） 商業(yè)評估工具 ， 例如 COCOMO、 Prices和 SLIM， 他們需要輸入與開發(fā)規(guī)模 、 生產(chǎn)能力和項目管理活動范圍相關(guān)的不同參數(shù)來確定測試工作量 。 這些工具所產(chǎn)生輸出的精確性反映了輸入數(shù)據(jù)的質(zhì)量 。 只有極少數(shù)工具能夠解決與產(chǎn)品質(zhì)量保證規(guī)范 (例如 ， 軟件測試 )有關(guān)的日益增長的重要性及復(fù)雜性問題 ， 這些問題是通過將它們與用來生成資源與費用估算的一組輸入因素結(jié)合起來而解決的 。 167。 3 測試工作規(guī)模 二、測試組規(guī)模確定方法 特定項目的測試工作量級別依賴于一些不確定因素 ， 而這些因素是測試組進行資源估算所使用的復(fù)雜估算模型的輸入條件 。 如果缺乏一些