第10章測試過程管理高等學(xué)校計算機(jī)類系列教材軟件測試實用教程——方法與實踐01軟件測試過程模型V模型PaulRook在20世紀(jì)80年代后期提出V模型，該模型是最具有代表意義的測試模型。V模型是軟件開發(fā)瀑布模型的變種，反映測試活動與系統(tǒng)分析和設(shè)計的關(guān)系，體現(xiàn)了動態(tài)測試的過程。V模型的基本思想如圖10.1所示，圖中箭頭表示時間方向。從該圖可以看出，左半部分的開發(fā)過程自頂向下，嚴(yán)格分為不同的開發(fā)階段，右半部分的測試過程則自底向上，也嚴(yán)格區(qū)分不同階段，且測試活動的展開次序正好與開發(fā)的次序相反。V模型

V模型的策略：動態(tài)測試行為應(yīng)與開發(fā)行為對應(yīng)，每個測試階段的基礎(chǔ)是對應(yīng)開發(fā)階段的提交物，并通過低層測試確保源代碼正確，通過高層測試保證整個系統(tǒng)滿足用戶需求。V模型的局限性主要在于：(1)測試滯后。測試是編碼完成后的階段，無法快速發(fā)現(xiàn)開發(fā)早期引入的缺陷，大大增加缺陷修復(fù)成本，且當(dāng)前期開發(fā)進(jìn)度拖延時將導(dǎo)致測試大大縮水。(2)測試與開發(fā)文檔難以—一對應(yīng)。測試與開發(fā)文檔之間很少有完美的一對一關(guān)系。例如，需求分析文檔往往需利用設(shè)計文檔中的部分內(nèi)容來為系統(tǒng)測試提供足夠的信息。(3)缺少靜態(tài)測試。缺少需求評審、代碼審查等靜態(tài)測試，容易降低測試效率。W模型為解決V模型的不足，PaulHerzlich提出了W模型，其基本思想是在V模型基礎(chǔ)上增加與開發(fā)階段同步進(jìn)行的測試部分，即開發(fā)和伴隨的測試過程分別是兩個完整的“V”，如圖10.2所示。其中，開發(fā)的V字左側(cè)對應(yīng)需求定義和設(shè)計，伴隨的測試行為是對開發(fā)文檔的靜態(tài)測試，以及對應(yīng)測試階段的測試計劃、設(shè)計和實施的過程；開發(fā)的V字右側(cè)對應(yīng)軟件實現(xiàn)，伴隨的測試行為是對這些實現(xiàn)的動態(tài)測試，即測試執(zhí)行和評估的過程。W模型W模型的測試策略：靜態(tài)測試和動態(tài)測試行為伴隨整個開發(fā)階段，并與開發(fā)行為對應(yīng)，有助于早期發(fā)現(xiàn)缺陷、了解項目難度、評估測試風(fēng)險，并加快項目進(jìn)度，降低項目成本。W模型的局限性主要在于：(1)將軟件開發(fā)看成需求分析、設(shè)計和編碼等一系列串行的活動。(2)開發(fā)、測試之間保持著線性的前后關(guān)系，無法支持迭代的開發(fā)模型，無法支持變更調(diào)整。(3)未體現(xiàn)測試流程的完整性。H模型V模型和W模型都把軟件開發(fā)看做需求→設(shè)計→編碼的串行活動，具有嚴(yán)格的階段劃分，無法支持迭代和增量開發(fā)，且未體現(xiàn)每個測試階段的完整流程。為此，人們提出了H模型，其基本思想是將測試活動獨立出來，形成兩個階段的獨立的測試流程：(1)測試準(zhǔn)備階段：包括測試計劃、測試設(shè)計和測試實施。(2)測試執(zhí)行階段：包括測試執(zhí)行和測試評估。H模型的原理如圖10.3所示，該圖說明了軟件開發(fā)某個階段對應(yīng)的測試活動，圖中實線表示的為測試流程所包含的活動，虛線則表示其他流程所包含的活動，如設(shè)計、編碼活動，甚至是軟件質(zhì)量保證這類非開發(fā)流程。H模型由該圖看出，在測試就緒點之前要做兩方面準(zhǔn)備工作：一方面是開發(fā)準(zhǔn)備，即提供被測對象和測試依據(jù)，屬于主要開發(fā)流程所提供的工件；另一方面是測試準(zhǔn)備，即提供測試工件(包括測試計劃、測試需求、測試用例、測試腳本、測試環(huán)境等)，對應(yīng)測試計劃、設(shè)計和實施的過程。V模型基于一套必須按照一定次序嚴(yán)格排列的開發(fā)步驟，而實際的實踐過程往往并非如此，例如，實際的項目往往缺乏足夠的需求，而V模型必須從需求處理開始。為此，Marick提出了X模型，其基本思想是：針對每個單獨的程序片段，進(jìn)行編碼和測試工作，不同程序片段之間的編碼和測試相互獨立，最終的可執(zhí)行程序通過各程序片段的交接和集成來獲取。X模型圖10.4給出了X模型示意圖。圖中左半部分是針對每個單獨的程序片段進(jìn)行的單獨的編碼和測試過程，強(qiáng)調(diào)測試先行，即對編寫完成的程序代碼片段先進(jìn)行測試設(shè)計和工具配置，再開始測試執(zhí)行，這與敏捷開發(fā)的思想十分類似。對某個程序片段測試執(zhí)行完成后，認(rèn)為該程序的編碼完成(注意，圖中的“編碼完成”不等于“代碼編寫完成”，而是指經(jīng)過了一定單元測試后質(zhì)量具有一定保障的程序片段)。多個這樣的程序片段需進(jìn)行多次交接和集成，并需對集成的程序再次進(jìn)行更高級別的測試設(shè)計和執(zhí)行(見圖的右半部分)，最終通過測試的成品作為更大規(guī)模內(nèi)集成的一部分，或直接封版提交給用戶。X模型綜合策略綜合上述測試過程模型，建議采用的綜合策略：宏觀上以W模型為基本框架，將軟件開發(fā)和測試作為兩個并行的過程，測試伴隨整個開發(fā)過程；而微觀上對每個測試階段則以H模型為指導(dǎo)，進(jìn)行獨立測試，即只要滿足測試執(zhí)行條件就可以進(jìn)行獨立的測試，并反復(fù)迭代測試，直至達(dá)到預(yù)定目標(biāo)；當(dāng)項目小組的開發(fā)過程中存在諸多不確定因素時(如需求的變更、對缺陷的修復(fù)等)，則可利用X模型，針對每個相對獨立的系統(tǒng)組成部分，進(jìn)行相互分離的編碼和測試，經(jīng)多次交接后集成為最終的版本。當(dāng)然，對于軟件企業(yè)而言，則應(yīng)以軟件測試成熟度模型(TMM)為指導(dǎo)，努力建立規(guī)范的軟件測試過程，有關(guān)TMM的內(nèi)容，本書不再詳細(xì)描述。02測試用例的管理測試用例的核心屬性包括ID、輸入和預(yù)期輸出，為了便于其管理，測試用例報告中還應(yīng)包含更多內(nèi)容。測試用例報告實際就是要詳細(xì)回答如下問題：誰、在何時、針對哪個軟件項目、針對哪個程序版本、針對哪個功能模塊、針對哪個測試需求、依據(jù)什么參考文檔、設(shè)計了哪些測試用例、這些測試用例規(guī)定軟件在怎樣的測試環(huán)境下、以何種方式執(zhí)行之后應(yīng)得到怎樣的預(yù)期結(jié)果、這些用例的優(yōu)先級如何、測試用例之間的約束關(guān)系是怎樣的。測試用例報告的撰寫受成本限制，公司或項目組將根據(jù)實際情況對上面的測試用例報告進(jìn)行瘦身，例如將若干測試用例之間相同的部分集中予以表達(dá)，將用例間不同的內(nèi)容(主要涉及測試用例的ID、輸入、操作步驟和輸出等)以列表或大綱形式給出。表10.1給出了某項目的設(shè)備管理模塊中轄區(qū)移交子功能(功能編號：Q3.13)的部分功能測試用例，對應(yīng)測試需求(編號：Q3.13.2，優(yōu)先級：中):正二級用戶登錄，移交的設(shè)備樹轄區(qū)節(jié)點中有設(shè)備，指定要移交的二級單位無轄區(qū)設(shè)備，但有正二級用戶，轄區(qū)節(jié)點可成功移交。表中各測試用例的操作步驟為：選中轄區(qū)節(jié)點1處，選擇“轄區(qū)移交”菜單項，然后在轄區(qū)屬性對話框中選擇2處，單擊“確定”按鈕。在表中不再——給出。測試用例報告的撰寫測試用例報告的撰寫測試用例的組織和跟蹤測試用例的組織和跟蹤可分7個步驟來完成。(1)整理模塊需求產(chǎn)品的需求往往不是一次就搞定的，一開始經(jīng)常會存在很多遺漏、錯誤理解、不一致、無法測試等各種缺陷，而交到測試小組手中的很可能就是這樣的文檔。(2)撰寫測試計劃撰寫測試計劃是后續(xù)測試設(shè)計、執(zhí)行和評估的基礎(chǔ)，所有工作都應(yīng)在良好的計劃指導(dǎo)下完成。(3)設(shè)計測試思路通過分析測試計劃中的測試特性，應(yīng)設(shè)計測試的思路，即對測試需求進(jìn)一步做細(xì)化工作。(4)編寫測試用例根據(jù)測試設(shè)計，分別設(shè)計具體的測試用例，應(yīng)靈活使用本書第二部分所介紹的測試方法，并遵循第三部分的測試階段策略。(5)評審測試用例測試用例在設(shè)計編寫過程中應(yīng)組織同級互查，編寫完成后則應(yīng)組織專家進(jìn)行評審，獲得通過才可以使用。測試用例的組織和跟蹤若時間緊迫可提前啟動測試，等評審?fù)瓿珊笤傩薷臏y試用例。外部評審?fù)ǔＪ窃跍y試用例編寫完成之后進(jìn)行。典型的測試用例評審檢查單見表10.2。(6)修改更新測試用例測試用例經(jīng)評審之后需根據(jù)評審意見進(jìn)行修改。(7)執(zhí)行測試用例測試用例經(jīng)修改之后，可從版本控制庫中取出測試用例，并在測試用例中記錄測試的結(jié)果，使用后送入版本控制庫，進(jìn)行版本管理。典型的測試用例生命周期見圖10.5。測試用例的組織和跟蹤(8)分析評估測試用例質(zhì)量測試用例全部執(zhí)行后，需對測試用例的質(zhì)量進(jìn)行分析和評估。一方面，從測試用例對代碼及對缺陷的覆蓋率來衡量測試用例的設(shè)計質(zhì)量。測試用例的組織和跟蹤每百行代碼的測試用例數(shù)目越多，測試用例密度越高，對代碼的覆蓋程度越高，但太高的覆蓋率反而有可能帶來成本的激增，效果卻不一定很好。所有缺陷中，被測試用例所發(fā)現(xiàn)的缺陷率越高，證明測試用例的漏洞越小，當(dāng)測試用例對缺陷的覆蓋率低到一定程度的時候，說明亟需提高測試人員的技術(shù)水平了。另一方面，從每輪測試中測試用例的執(zhí)行率、通過率、平均每天執(zhí)行測試用例的數(shù)目、平均每天執(zhí)行測試用例的通過率、不同模塊的測試用例通過率等指標(biāo)來衡量測試用例的執(zhí)行情況。03軟件缺陷的管理1.嚴(yán)重性嚴(yán)重性(Severity)是指缺陷對被測系統(tǒng)造成的破壞程度的大小，它可能是即時的破壞，也可能是一段時間之后對系統(tǒng)帶來的毀壞。嚴(yán)重性是對缺陷的客觀評價，反映了缺陷自身對軟件系統(tǒng)和對用戶使用造成的絕對影響。嚴(yán)重性由測試人員設(shè)定，但一經(jīng)設(shè)定，不可隨意改動。缺陷的屬性(1)嚴(yán)重的(Critical):重要功能喪失，致命錯誤造成系統(tǒng)崩潰、死機(jī)、系統(tǒng)懸掛、甚至危及人身安全，用戶數(shù)據(jù)丟失或破壞而容易引起用戶財產(chǎn)損失或法律糾紛，業(yè)務(wù)流程錯誤、數(shù)值計算錯誤等，其中法律法規(guī)、具高頻使用率的功能的缺陷是最嚴(yán)重的。(2)一般的(Major):不影響系統(tǒng)的基本使用，能滿足商業(yè)要求，但用戶不常用的功能實現(xiàn)未達(dá)到預(yù)期效果，可能導(dǎo)致用戶使用不方便，可能對公司品牌形象有直接影響等。(3)次要的(Minor):對功能幾乎沒有影響，產(chǎn)品及屬性仍可使用。典型缺陷包括：個別錯別字，文字排列不整齊，非常小的標(biāo)點符號錯誤，不可行路徑等。2.優(yōu)先級優(yōu)先級(Priority)是指缺陷必須被修復(fù)的緊急程度。優(yōu)先級是對缺陷的主觀評價，反映了項目小組對缺陷風(fēng)險的評估結(jié)論，若認(rèn)為缺陷帶來的風(fēng)險不大，則設(shè)定該缺陷的優(yōu)先級別較低，反之，則定級較高。優(yōu)先級由項目經(jīng)理負(fù)責(zé)設(shè)置，一經(jīng)確定，也不能隨意改動。缺陷的屬性一般地，可將優(yōu)先級劃分為如下三個等級：(1)高(High):缺陷完全阻礙或部分阻礙進(jìn)一步開發(fā)或測試工作，需立刻修復(fù)(一般為48小時內(nèi))或在下一個里程碑之前必須修復(fù)。(2)中(Middle):缺陷需正常排隊等待修復(fù)，但在產(chǎn)品發(fā)布之前必須修復(fù)。(3)低(Low):缺陷對系統(tǒng)影響不大，當(dāng)時間允許時可考慮修復(fù)，有時甚至不修復(fù)也能發(fā)布產(chǎn)品。缺陷的屬性可重現(xiàn)性(Reappearance)指缺陷應(yīng)在同樣的條件下可反復(fù)出現(xiàn)，且每次出現(xiàn)的形式完全一樣。無法重現(xiàn)的缺陷對開發(fā)人員是無意義的，因為無法對缺陷進(jìn)行定位，意味著無法修復(fù)該缺陷，測試人員在測試中應(yīng)確保缺陷可多次重現(xiàn)，并在缺陷報告中準(zhǔn)確地描述出來。為確保缺陷可重現(xiàn)，應(yīng)采用如下的措施：(1)在測試過程中隨時記錄操作步驟和被測系統(tǒng)的響應(yīng)，一旦出現(xiàn)缺陷，可以快速寫出執(zhí)行步驟及出錯現(xiàn)象，降低操作導(dǎo)致的不可靠因素，必要時采用屏幕錄制工具(如Wink)協(xié)助完成這一過程；(2)重復(fù)測試至少三次，確保每次執(zhí)行同樣的步驟可得到相同表現(xiàn)的缺陷，同時在缺陷報告中注明重復(fù)測試的次數(shù)，以提高缺陷報告的可信度；(3)對于隨機(jī)性出現(xiàn)的缺陷(即出現(xiàn)率并非百分之百)，則應(yīng)嘗試使用不同的測試數(shù)據(jù)、改變測試環(huán)境等，試圖找到影響缺陷出現(xiàn)的根本原因。缺陷報告的撰寫1.概述缺陷報告就是記錄缺陷各方面信息的文檔，一份缺陷報告實際就是要回答如下問題：(1)誰，何時，在何處，發(fā)現(xiàn)了什么缺陷?(2)誰，何時，提出怎樣的處理意見?(3)誰，何時，如何修復(fù)該缺陷?(如果需要修復(fù)缺陷的話)(4)誰，何時，如何驗證該缺陷?測試結(jié)果如何?缺陷報告的撰寫2.完整的缺陷報告表10.3是一個典型的缺陷報告模板。3.第二日問題的缺陷報告以第二日問題為例，若管理員(充當(dāng)測試人員角色，來自微軟“人人均可測試”的理念)發(fā)現(xiàn)了isLeapYear函數(shù)中的一個缺陷，登錄BugFree(一款開源缺陷管理工具)后填寫的缺陷報告見圖10.6。缺陷報告的撰寫缺陷報告的撰寫接著，程序員登錄后看到有一個缺陷報告發(fā)給自己待解決，項目經(jīng)理和管理員對該缺陷進(jìn)行了詳細(xì)的說明，如圖10.7所示，程序員對缺陷修復(fù)后回復(fù)的內(nèi)容如圖10.8所示。缺陷報告的撰寫管理員回復(fù)后的缺陷報告如圖10.9所示，單擊“關(guān)閉它”按鈕即可關(guān)閉該缺陷。缺陷報告的撰寫4.缺陷報告的裁剪為了節(jié)省時間，公司或項目組往往會根據(jù)實際情況對完整的缺陷報告進(jìn)行裁剪，僅保留缺陷報告的主要信息，如表10.4所示，缺陷067對應(yīng)的界面如圖10.10～圖10.12所示。從中可以看出，該缺陷報告僅保留了核心內(nèi)容，從而可保證缺陷可跟蹤，并避免了大量的文檔編寫工作。缺陷報告的撰寫缺陷報告的撰寫5.缺陷報告撰寫的技巧缺陷報告采用什么模板并不重要，最重要的是缺陷描述應(yīng)準(zhǔn)確、完整、無歧義。缺陷010的描述較清楚，但與其對應(yīng)的缺陷界面圖卻難以看懂，不清楚缺陷到底在哪里。而表10.4中的缺陷067不僅描述簡明清晰，對應(yīng)的三個界面圖也一目了然，可惜其修改過程卻讓人看不懂：“沒有問題”是什么意思?相比之下，缺陷103的描述則非常清楚。關(guān)于缺陷報告的技巧可用一句話來概括，任何人看到該缺陷描述和相關(guān)附件，都能準(zhǔn)確無誤地了解系統(tǒng)究竟怎樣與預(yù)期不一致，經(jīng)過怎樣的修復(fù)后可關(guān)閉該缺陷，這就是一個合格的缺陷報告。缺陷的跟蹤和管理1.缺陷處理的流程缺陷需要密切跟蹤，測試人員發(fā)現(xiàn)并提交缺陷報告后，缺陷報告就在測試員、項目經(jīng)理、開發(fā)人員等不同角色之間流轉(zhuǎn)，進(jìn)入不同的狀態(tài)。典型的缺陷處理流程如圖10.14所示。缺陷的跟蹤和管理2.缺陷跟蹤流程中的角色與權(quán)限缺陷的跟蹤并非僅為測試人員的任務(wù)，在整個軟件開發(fā)過程中涉及的不同人員均將接觸到缺陷，如何劃分不同人員的職責(zé)，應(yīng)回答以下問題：(1)誰負(fù)責(zé)上報缺陷?誰控制缺陷的分類、嚴(yán)重性和優(yōu)先級?誰決定缺陷的處理方式?(2)誰負(fù)責(zé)分配缺陷?誰負(fù)責(zé)修復(fù)缺陷?(3)當(dāng)處理意見不一致時，誰負(fù)責(zé)進(jìn)行仲裁?是否允許申訴?(4)誰有權(quán)查詢?nèi)毕輸?shù)據(jù)?誰有權(quán)統(tǒng)計缺陷數(shù)據(jù)?缺陷的跟蹤和管理有關(guān)各種角色的權(quán)限如圖10.15所示。缺陷的跟蹤和管理從該圖中可以清楚地看到：(1)測試員負(fù)責(zé)上報缺陷，并對缺陷進(jìn)行分類，確定缺陷的嚴(yán)重等級；(2)項目經(jīng)理負(fù)責(zé)對缺陷的優(yōu)先級進(jìn)行劃定，將缺陷分配給程序員；(3)程序員對缺陷報告審核之后決定針對缺陷應(yīng)采取的處理方式，負(fù)責(zé)修復(fù)缺陷；(4)當(dāng)程序員與測試員對缺陷的處理意見不一致時，仲裁委員會負(fù)責(zé)進(jìn)行仲裁，避免程序員與測試員的“踢皮球”現(xiàn)象；(5)項目經(jīng)理需了解整個項目的進(jìn)度和質(zhì)量，因此，需要通過對缺陷數(shù)據(jù)的查詢分析來了解當(dāng)前被測軟件的質(zhì)量，進(jìn)而決策是否可以停止測試，準(zhǔn)備產(chǎn)品交付。04測試團(tuán)隊的管理測試團(tuán)隊的責(zé)任測試團(tuán)隊的主要責(zé)任包括：(1)盡早并盡可能多地發(fā)現(xiàn)軟件產(chǎn)品中的嚴(yán)重缺陷；(2)督促開發(fā)人員盡快修復(fù)程序中已發(fā)現(xiàn)的軟件缺陷；(3)幫助項目管理人員制訂合理的開發(fā)計劃；(4)分析、總結(jié)和跟蹤發(fā)現(xiàn)的缺陷，便于讓項目管理者和項目負(fù)責(zé)人能清楚地了解軟件系統(tǒng)當(dāng)前的質(zhì)量情況：(5)幫助改善開發(fā)流程，提高產(chǎn)品的開發(fā)效率；(6)督促開發(fā)人員遵循良好的編碼習(xí)慣，提高代碼的規(guī)范性、可讀性和可維護(hù)性。其中，前兩項是測試人員的基本職責(zé)，其余工作則主要是從過程度量和管理、質(zhì)量保證及缺陷預(yù)防等角度所做的工作。測試團(tuán)隊組織架構(gòu)一個測試團(tuán)隊不僅包含測試實施人員，還包括其他相關(guān)人員，典型的測試團(tuán)隊包括如下人員：(1)技術(shù)支持組：包括系統(tǒng)架構(gòu)師和業(yè)務(wù)分析師；(2)質(zhì)量保障組：包括質(zhì)量保障人員和配置管理人員；(3)測試實施組：包括功能測試工程師和性能測試工程師；(4)測試開發(fā)組：包括軟件架構(gòu)師和研發(fā)工程師。測試團(tuán)隊各角色職責(zé)在一個測試團(tuán)隊中，不同角色的崗位職責(zé)如下。(1)項目經(jīng)理項目經(jīng)理對整個項目負(fù)責(zé)，其職責(zé)包括：①對項目進(jìn)行管理，對最終的產(chǎn)品質(zhì)量負(fù)責(zé)；②與用戶或客戶相關(guān)部門的溝通，以及與研發(fā)團(tuán)隊的溝通，保證項目順利進(jìn)行；③協(xié)調(diào)測試資源，對各種資源進(jìn)行計劃、分工和管理；④制訂項目測試計劃和測試方案；⑤組織項目各階段的評審和驗收；⑥對團(tuán)隊成員進(jìn)行管理，保證團(tuán)隊高效地協(xié)同工作。測試團(tuán)隊各角色職責(zé)(2)測試組長測試組長對整個測試項目的管理負(fù)責(zé)，偏重技術(shù)，因此，測試組長的綜合能力和技術(shù)應(yīng)為小組內(nèi)最強(qiáng)的，其職責(zé)包括：①對所負(fù)責(zé)小組的工作負(fù)責(zé)，包括制訂成員工作計劃、檢查工作完成情況；②輔助編寫測試計劃、測試結(jié)果分析和報告，幫助測試工程師完成工作；③服從項目經(jīng)理的管理，保質(zhì)、保量地完成本小組負(fù)責(zé)的測試任務(wù)；④與小組其他成員一起，分析測試需求，設(shè)計測試用例，并保證對需求的覆蓋；⑤提交軟件缺陷報告，并跟蹤缺陷處理流程，對本小組提出的缺陷報告負(fù)責(zé)；⑥協(xié)助項目經(jīng)理進(jìn)行項目管理工作；⑦與研發(fā)團(tuán)隊有效溝通，并協(xié)同研發(fā)、質(zhì)量控制及配置管理小組的工作，提供必要的技術(shù)支持。測試團(tuán)隊各角色職責(zé)(3)測試工程師測試工程師主要負(fù)責(zé)開發(fā)文檔的審查、測試的設(shè)計、實施和執(zhí)行，其職責(zé)包括：①服從項目經(jīng)理和組長的日常管理，保質(zhì)、保量、按時完成測試任務(wù)；②根據(jù)軟件需求來分析測試需求，設(shè)計測試用例，并保證足夠的覆蓋率；③執(zhí)行測試用例，提交缺陷報告，并跟蹤缺陷的處理；④有義務(wù)對項目工作提出建設(shè)性建議；⑤與研發(fā)等相關(guān)部門進(jìn)行有效溝通。測試團(tuán)隊各角色職責(zé)(4)實驗室管理員實驗室管理員主要負(fù)責(zé)配置和維護(hù)實驗室測試環(huán)境，以保證穩(wěn)定的測試環(huán)境，具體職責(zé)包括：①對測試環(huán)境所需的網(wǎng)絡(luò)進(jìn)行規(guī)劃和建設(shè)，維護(hù)網(wǎng)絡(luò)正常運行；②建立和維護(hù)測試環(huán)境所需的服務(wù)器或軟件平臺；③對測試實驗室的軟件和硬件資源進(jìn)行登記、分配和管理；④對測試實驗室資源的使用權(quán)限進(jìn)行分配，確保安全、合理地使用；⑤對測試環(huán)境進(jìn)行優(yōu)化，提高網(wǎng)絡(luò)、服務(wù)器和其他設(shè)備的運行性能；⑥協(xié)助有關(guān)部門，對申請的新資源進(jìn)行采購和驗收。測試團(tuán)隊各角色職責(zé)(5)內(nèi)審員內(nèi)審員與質(zhì)量保障人員和配置管理人員的工作有些相似，但側(cè)重點不同，其職責(zé)包括：①對流程進(jìn)行審查，并提出流程改進(jìn)的建議；②建立測試文檔所需的各種模板；③根據(jù)已建立的標(biāo)準(zhǔn)和規(guī)范，對測試過程中產(chǎn)生的文檔進(jìn)行質(zhì)量檢查。(6)配置管理人員配置管理人員的職責(zé)包括：①對被測系統(tǒng)進(jìn)行配置管理和版本控制；②有效管理業(yè)務(wù)和研發(fā)提供的需求和設(shè)計文檔；③對測試過程中產(chǎn)生的文檔進(jìn)行管理和版本控制；④與客戶和研發(fā)團(tuán)隊配置管理員進(jìn)行有效溝通；⑤輔助質(zhì)量保障人員進(jìn)行質(zhì)量控制。測試團(tuán)隊各角色職責(zé)(7)質(zhì)量保障人員質(zhì)量保障人員的