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

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

第3個(gè)工作薄為“決策表”，提供基于決策表的測(cè)試用例的測(cè)試結(jié)果，內(nèi)容見(jiàn)圖11.3。自動(dòng)化測(cè)試設(shè)計(jì)

第4個(gè)工作薄為“無(wú)效等價(jià)類(lèi)”，存儲(chǔ)針對(duì)無(wú)效等價(jià)類(lèi)的用例測(cè)試結(jié)果，部分內(nèi)容見(jiàn)圖11.4。JUnit概述1.JUnit自動(dòng)化測(cè)試框架JUnit采用Composite設(shè)計(jì)模式構(gòu)建自動(dòng)化測(cè)試框架，如圖11.5所示。該模式下，TestSuite(測(cè)試包類(lèi))可以容納任何派生自Test(測(cè)試類(lèi))的對(duì)象，當(dāng)調(diào)用TestSuite對(duì)象的run()方法時(shí)，將遍歷自己所容納的所有對(duì)象，分別調(diào)用它們的run方法，并分析返回的結(jié)果。JUnit概述2.JUnit主要的包和類(lèi)的說(shuō)明JUnit共有7個(gè)包，核心包是JUnit.framework和JUnitrunner，分別負(fù)責(zé)整個(gè)測(cè)試對(duì)象的構(gòu)建和測(cè)試驅(qū)動(dòng)。JUnit框架的骨干可表示為：TestCase+TestSuite+BaseTestRunner=TestResult。JUnit包含7個(gè)核心類(lèi)，簡(jiǎn)要說(shuō)明如下：(1)Test(測(cè)試)類(lèi)是一個(gè)接口類(lèi)，用來(lái)測(cè)試和收集測(cè)試結(jié)果，通過(guò)Test接口建立TestCase與TestSuite之間的關(guān)聯(lián)。(2)TestCase(測(cè)試用例)類(lèi)是Test接口的抽象實(shí)現(xiàn)，通過(guò)對(duì)該類(lèi)繼承來(lái)開(kāi)發(fā)自己的測(cè)試驅(qū)動(dòng)。一般地，一個(gè)TestCase的派生類(lèi)實(shí)現(xiàn)對(duì)一個(gè)類(lèi)的測(cè)試，可包含若干測(cè)試用例。也可以根據(jù)本項(xiàng)目和團(tuán)隊(duì)需要來(lái)開(kāi)發(fā)自己的TestCase測(cè)試驅(qū)動(dòng)基類(lèi)，以便于代碼重用。JUnit概述(3)TestSuite(測(cè)試包)類(lèi)用于聚合多個(gè)測(cè)試用例。(4)TestRunner(測(cè)試運(yùn)行)類(lèi)是用于啟動(dòng)測(cè)試的用戶界面，從而執(zhí)行測(cè)試。(5)TestResult(測(cè)試結(jié)果)類(lèi)用于收集TestCase的執(zhí)行結(jié)果，將結(jié)果分為Failure和Errors兩種異常，并轉(zhuǎn)發(fā)給TestListener處理，其中由Assert觸發(fā)的Failures是由測(cè)試用例拋出的可預(yù)測(cè)異常，當(dāng)用例執(zhí)行結(jié)果不同于期望值時(shí)拋出，表示用例失敗；Errors是因測(cè)試驅(qū)動(dòng)程序本身存在語(yǔ)法等缺陷而拋出的不可預(yù)測(cè)異常，與測(cè)試用例無(wú)關(guān)。我們可開(kāi)發(fā)自己的TestResult類(lèi)。(6)Assert(斷言)類(lèi)用于比較實(shí)際值與預(yù)期值，判斷二者是否一致，進(jìn)而確定用例是否通過(guò)。Assert類(lèi)可對(duì)普通數(shù)據(jù)類(lèi)型、字符串等多種情況實(shí)現(xiàn)自動(dòng)檢驗(yàn)。(7)TestListener(測(cè)試監(jiān)聽(tīng))類(lèi)用于處理測(cè)試結(jié)果和提取測(cè)試驅(qū)動(dòng)過(guò)程的工作特征，當(dāng)測(cè)試中產(chǎn)生事件(開(kāi)始、結(jié)束、錯(cuò)誤、失敗)時(shí)，會(huì)通知TestListener。JUnit概述3.JUnit3與JUnit4的區(qū)別目前JUnit已經(jīng)發(fā)展到JUnit4.9版本，JUnit4是配合JDK1.5版本的，因此，JUnit4以上版本較JUni3.x改動(dòng)較大。JUnit3強(qiáng)制繼承TestCase類(lèi)，以函數(shù)命名規(guī)則(規(guī)定函數(shù)名應(yīng)形如“testXX”)來(lái)判斷是否是測(cè)試方法；而JUnit4使用元數(shù)據(jù)。JUnit3和JUnit4的簡(jiǎn)單對(duì)比如下：(1)定位測(cè)試JUnit3使用命名約定和反射來(lái)定位測(cè)試。JUnit4中的測(cè)試是由@Test注釋來(lái)識(shí)別的。(2)SetUp和TearDown方法JUnit3在運(yùn)行(testrunner)每個(gè)測(cè)試之前自動(dòng)調(diào)用setUp()方法，完成初始化字段、打開(kāi)日志記錄、重置環(huán)境變量等任務(wù)：JUnit4中不需強(qiáng)制使用setUp()方法，只需用@Before注釋指示即可，甚至可用其注釋多個(gè)方法，使之均在每個(gè)測(cè)試之前運(yùn)行。類(lèi)似地，tearDown方法替換為用@After注釋指示即可。JUnit4不需要在超類(lèi)中顯式調(diào)用初始化和清除方法，只要它們不被覆蓋即可，測(cè)試運(yùn)行程序根據(jù)需要自動(dòng)調(diào)用這些方法，其中，超類(lèi)中的@Before方法在子類(lèi)中的@Before方法之前被調(diào)用，而@After方法則以反方向執(zhí)行。JUnit概述4.基于JUnit4的測(cè)試程序編寫(xiě)采用JUnit4編寫(xiě)測(cè)試程序的基本步驟如下：(1)添加測(cè)試初始化和環(huán)境清理方法，完成初始化和清理資源工作在每個(gè)測(cè)試之前/之后執(zhí)行的方法：@Before和@After;在整套測(cè)試之前/之后執(zhí)行的方法：@BeforeClass和@AfterClass;測(cè)試時(shí)跳過(guò)該方法：@Ignore.(2)編寫(xiě)測(cè)試類(lèi)通過(guò)添加@Test注釋?zhuān)瑢㈩?lèi)的方法標(biāo)記為一個(gè)單元測(cè)試方法，方法名可自定義。(3)使用assertEquals()方法進(jìn)行比較判斷。(4)使用測(cè)試集來(lái)構(gòu)建測(cè)試包，并將測(cè)試用例加入測(cè)試包。(5)使用參數(shù)化測(cè)試通過(guò)@Parameters注釋的方法返回包含一組參數(shù)的集合，JUnit4自動(dòng)將每組參數(shù)傳入測(cè)試方法進(jìn)行測(cè)試。基于Eclipse的JUnit4測(cè)試開(kāi)發(fā)作為Java單元測(cè)試的事實(shí)標(biāo)準(zhǔn)，JUnit得到了各種開(kāi)發(fā)工具廣泛的支持，如Eclipse中集成了JUni3和JUnit4，NetBeans中可使用JUnit。下面簡(jiǎn)要說(shuō)明如何在Eclipse中使用JUnit4。(1)新建Java項(xiàng)目時(shí)，添加testsrc源文件夾，以存放測(cè)試類(lèi)的源文件，如圖11.6所示。基于Eclipse的JUnit4測(cè)試開(kāi)發(fā)(2)添加JUnit庫(kù)并選擇JUnit4版本，在Java設(shè)置中選擇“庫(kù)”頁(yè)簽并單擊“添加庫(kù)”按鈕，在彈出的對(duì)話框中選擇“JUnit”，如圖11.7所示。基于Eclipse的JUnit4測(cè)試開(kāi)發(fā)(3)將其他可能用到的庫(kù)放入項(xiàng)目的lib文件夾，在此分別添加poi庫(kù)用來(lái)讀寫(xiě)Excel文件，dom4j庫(kù)用來(lái)讀取XML文件，jaxen庫(kù)用于在dom4j中使用Xpath查詢語(yǔ)句，如圖11.8所示。基于Eclipse的JUnit4測(cè)試開(kāi)發(fā)(4)在src目錄下寫(xiě)好被測(cè)試的類(lèi)后，在testsrc下創(chuàng)建一個(gè)同名的包，并新建JUnit測(cè)試用例，如圖11.9所示。基于Eclipse的JUnit4測(cè)試開(kāi)發(fā)在彈出的新建JUnit測(cè)試用例對(duì)話框(見(jiàn)圖11.10)中應(yīng)注意，填寫(xiě)的包名應(yīng)與被測(cè)試的類(lèi)保持一致。當(dāng)勾選方法存根中的方法后，系統(tǒng)將自動(dòng)生成對(duì)應(yīng)的由@BeforeClass、@AfterClass、@Before、@After注釋的方法。(5)寫(xiě)好測(cè)試驅(qū)動(dòng)類(lèi)后，運(yùn)行結(jié)果如圖11.11所示，圖中的進(jìn)度條表示存在測(cè)試失敗的情況，且目前選擇了“只顯示失敗”的顯示模式。1.Ant的安裝配置Ant安裝配置的步驟如下：(1)下載安裝包并解壓。從下載安裝包apache-ant-1.8.4-binzip，解壓到計(jì)算機(jī)上的某個(gè)適當(dāng)?shù)哪夸洠鏑:Nava，解壓縮時(shí)會(huì)自動(dòng)在該目錄下創(chuàng)建所下載的Ant分發(fā)包的子目錄結(jié)構(gòu)，如C:Nava\apache-ant-1.8.4。(2)配置環(huán)境變量。在桌面用鼠標(biāo)右擊“我的電腦”，選擇“屬性”，在打開(kāi)的系統(tǒng)屬性對(duì)話框中選擇“高級(jí)”頁(yè)簽，并單擊“環(huán)境變量”按鈕，可設(shè)置JAVAHOME、ANTHOME和PATH，如圖11.12所示。Ant概述2.Ant的構(gòu)建文件編寫(xiě)要定義某個(gè)項(xiàng)目中Ant要執(zhí)行的目標(biāo)，需編寫(xiě)基于XML的配置文件，通常為build.xml，用于描述想應(yīng)用在項(xiàng)目中的每個(gè)任務(wù)(Task)，通過(guò)調(diào)用目標(biāo)樹(shù)就可執(zhí)行各種任務(wù)。配置文件可包含若干目標(biāo)，或稱(chēng)進(jìn)入點(diǎn)(Entrypoint)，目標(biāo)的depends屬性定義目標(biāo)間的依賴關(guān)系，即某目標(biāo)完成后才執(zhí)行此目標(biāo)。每個(gè)目標(biāo)下包含若干任務(wù)，每個(gè)任務(wù)由實(shí)現(xiàn)了特定接口的對(duì)象來(lái)運(yùn)行。Ant概述Ant內(nèi)置了很多任務(wù)，包括與JUnit相關(guān)的兩個(gè)任務(wù)junit和junitreport，分別用于執(zhí)行JUnit單元測(cè)試和生成測(cè)試結(jié)果報(bào)告。Ant還支持一些可選任務(wù)，但一般需要額外的庫(kù)才能工作，且可選任務(wù)與內(nèi)置任務(wù)是分開(kāi)單獨(dú)打包的。基于Eclipse的Ant使用在Eclipse平臺(tái)下要使用Ant，可遵循如下的步驟：(1)在項(xiàng)目根目錄下新建XML文件，并以Ant編輯器的方式打開(kāi)，如圖11.13所示。(2)編寫(xiě)好build.xml文件后，選擇“窗口”→“顯示視圖”→“Ant”菜單項(xiàng)，添加構(gòu)建文件buildxml，查看各個(gè)目標(biāo)，并選擇執(zhí)行某個(gè)目標(biāo)，如圖11.14所示。基于Eclipse的Ant使用(3)為執(zhí)行Ant的JUnittask，需將junitjar和orghamcrestcore.jar也添加到lib文件夾下，以方便在Ant的執(zhí)行中去引用。完整的目錄結(jié)構(gòu)如圖11.15所示，其中class、testclass和report文件夾是由于build.xml中有相關(guān)任務(wù)，運(yùn)行一次后會(huì)自動(dòng)生成。(4)選擇buildxml運(yùn)行默認(rèn)目標(biāo)，或在Ant視圖中選擇運(yùn)行特定目標(biāo)，在控制臺(tái)顯示運(yùn)行結(jié)果，如圖11.16所示。測(cè)試小結(jié)保險(xiǎn)金問(wèn)題是一個(gè)函數(shù)級(jí)別的測(cè)試問(wèn)題，即使如此，設(shè)計(jì)的測(cè)試用例也可能非常多。當(dāng)在Eclipse平臺(tái)下基于Java進(jìn)行開(kāi)發(fā)時(shí)，應(yīng)基于JUnit提供的測(cè)試框架，編寫(xiě)測(cè)試腳本，自動(dòng)完成測(cè)試用例的執(zhí)行，以提高效率。當(dāng)然，如果對(duì)JUnit不熟悉，則可能需要花費(fèi)巨大的精力來(lái)編寫(xiě)測(cè)試腳本，且得到的測(cè)試腳本可能質(zhì)量也不高，這是需要在制訂測(cè)試計(jì)劃時(shí)就注意到的。02信息采集系統(tǒng)案例實(shí)踐信息采集系統(tǒng)的主要功能是對(duì)給定的信息文件和照片文件進(jìn)行格式及內(nèi)容的校驗(yàn)，并在信息文件和照片文件正確的情況下對(duì)多個(gè)文件進(jìn)行統(tǒng)一匯總導(dǎo)出，其測(cè)試重點(diǎn)在于如何考慮到盡可能多的格式及內(nèi)容無(wú)效的情況。自動(dòng)化測(cè)試設(shè)計(jì)對(duì)應(yīng)地，其測(cè)試用例的設(shè)計(jì)就是設(shè)計(jì)典型缺陷表的過(guò)程，通過(guò)構(gòu)建一批典型數(shù)據(jù)文件，將多種缺陷植入這些數(shù)據(jù)文件(含信息文件和照片文件)，判斷系統(tǒng)能否發(fā)現(xiàn)這些數(shù)據(jù)文件中植入已知的缺陷。因此，不需要額外開(kāi)發(fā)自動(dòng)化測(cè)試腳本，而僅需構(gòu)建測(cè)試數(shù)據(jù)，測(cè)試用例執(zhí)行的過(guò)程實(shí)際上就是導(dǎo)入包含典型缺陷的數(shù)據(jù)文件并運(yùn)行系統(tǒng)來(lái)對(duì)這些數(shù)據(jù)文件進(jìn)行校驗(yàn)的過(guò)程。表11.1給出了一個(gè)典型的包含多種缺陷的信息文件數(shù)據(jù)表。其中，身份證號(hào)省略了。備注列是為了說(shuō)明設(shè)計(jì)該數(shù)據(jù)的原因，在實(shí)際的信息文件中不包含備注列。自動(dòng)化測(cè)試設(shè)計(jì)部分缺陷分析盡量信息采集系統(tǒng)功能不多，但要考慮的無(wú)效情況太多，所以經(jīng)測(cè)試后還是發(fā)現(xiàn)了一些缺陷，部分缺陷如表11.2所示。信息采集系統(tǒng)是一個(gè)系統(tǒng)級(jí)別的案例，但由于該系統(tǒng)的主要功能是對(duì)文件進(jìn)行查錯(cuò)，因此，其測(cè)試腳本的開(kāi)發(fā)主要在于測(cè)試數(shù)據(jù)文件的設(shè)計(jì)，而測(cè)試數(shù)據(jù)文件對(duì)于該系統(tǒng)而言，其實(shí)就是被校驗(yàn)的數(shù)據(jù)對(duì)象，所以該系統(tǒng)的測(cè)試不需要額外開(kāi)發(fā)自動(dòng)化測(cè)試腳本。測(cè)試小結(jié)03網(wǎng)絡(luò)教學(xué)平臺(tái)案例實(shí)踐網(wǎng)絡(luò)教學(xué)平臺(tái)案例來(lái)源于課程教學(xué)建設(shè)的需要，服務(wù)于某課程教學(xué)。該網(wǎng)絡(luò)教學(xué)平臺(tái)是一個(gè)課程網(wǎng)站，主要功能：通過(guò)網(wǎng)絡(luò)教學(xué)平臺(tái)主要為教師和學(xué)生用戶提供服務(wù)，教師通過(guò)教學(xué)平臺(tái)提供課程相關(guān)資源、作業(yè)的布置及相關(guān)自測(cè)題。案例說(shuō)明學(xué)生通過(guò)該平臺(tái)可隨時(shí)訪問(wèn)課堂內(nèi)外與課程相關(guān)的教案、課件、案例、實(shí)驗(yàn)、軟件、閱讀材料等資源，可方便地提交課程作業(yè)，隨時(shí)就課程內(nèi)容進(jìn)行自測(cè)自評(píng)，并可在課后與教師就課程相關(guān)專(zhuān)題和疑問(wèn)等展開(kāi)交流。該網(wǎng)絡(luò)教學(xué)平臺(tái)的最終目標(biāo)是使之成為師生之間資源共享、提供實(shí)踐和增進(jìn)交流的平臺(tái)。該網(wǎng)絡(luò)教學(xué)平臺(tái)以VisualStudio2005為開(kāi)發(fā)平臺(tái)，采用ASPNET和C#語(yǔ)言為開(kāi)發(fā)語(yǔ)言，后臺(tái)數(shù)據(jù)庫(kù)采用SQLServer2005開(kāi)發(fā)實(shí)現(xiàn)。1.系統(tǒng)用戶及用例系統(tǒng)用戶主要分為如下4類(lèi)：(1)管理員：負(fù)責(zé)管理用戶和設(shè)置用戶使用期限。對(duì)應(yīng)系統(tǒng)后臺(tái)功能。(2)匿名用戶：所有訪問(wèn)網(wǎng)站的未登錄的用戶都是匿名用戶。對(duì)應(yīng)系統(tǒng)前臺(tái)功能。(3)教師用戶：本課程的任課教師。對(duì)應(yīng)系統(tǒng)前臺(tái)功能。(4)學(xué)生用戶：當(dāng)前學(xué)期學(xué)習(xí)該門(mén)課程的學(xué)生。對(duì)應(yīng)系統(tǒng)前臺(tái)功能。案例說(shuō)明案例說(shuō)明受篇幅所限，在此僅分析管理員用戶的用例，如圖11.17所示。案例說(shuō)明2.軟件需求跟蹤矩陣根據(jù)管理員用戶的用例，可以得到其對(duì)應(yīng)軟件需求跟蹤矩陣如表11.3所示。該表僅列出需求標(biāo)題和功能簡(jiǎn)述，其他有關(guān)需求狀態(tài)、變更等內(nèi)容不再給出。案例說(shuō)明3.系統(tǒng)需求規(guī)格說(shuō)明受篇幅所限，僅列出添加用戶和刪除用戶的功能需求說(shuō)明，分別如表11.4和表11.5所示。案例說(shuō)明測(cè)試需求分析對(duì)應(yīng)上述功能需求，得到測(cè)試項(xiàng)如表11.6所示：添加用戶的測(cè)試需求如表11.7所示：測(cè)試需求分析刪除用戶的測(cè)試需求如表11.8所示：1.添加用戶的部分測(cè)試用例對(duì)添加用戶功能，僅針對(duì)測(cè)試需求A1.1.1、A1.1.2給出部分測(cè)試用例，見(jiàn)表11.9、表11.10。測(cè)試用例設(shè)計(jì)2.刪除用戶的部分測(cè)試用例對(duì)刪除用戶功能，僅針對(duì)測(cè)試需求A1.2.1、A1.2.4給出測(cè)試用例，見(jiàn)表11.11、表11.12。測(cè)試用例設(shè)計(jì)自動(dòng)化測(cè)試設(shè)計(jì)使用QTP進(jìn)行功能測(cè)試時(shí)，應(yīng)時(shí)刻注意，使用工具的最終目的不是為了給領(lǐng)導(dǎo)展示實(shí)施自動(dòng)化測(cè)試的過(guò)程，而是為了切實(shí)提高測(cè)試效率，因此，關(guān)鍵仍然在于測(cè)試的設(shè)計(jì)。1.測(cè)試設(shè)計(jì)原則該教學(xué)平臺(tái)已進(jìn)行過(guò)較為詳細(xì)的手動(dòng)測(cè)試，為了提高后續(xù)版本的回歸測(cè)試效率，將部分功能的測(cè)試改為自動(dòng)化方式執(zhí)行。基本原則如下：(1)針對(duì)大量的重復(fù)性手動(dòng)測(cè)試，盡量改為自動(dòng)化方式，即只要能夠通過(guò)系統(tǒng)自動(dòng)讀入的方式執(zhí)行的測(cè)試，均改為自動(dòng)化方式進(jìn)行，且注意每個(gè)測(cè)試腳本包含的流程不要太復(fù)雜。(2)對(duì)于某些無(wú)法用自動(dòng)化方式實(shí)現(xiàn)的測(cè)試，仍采用手動(dòng)測(cè)試。(3)對(duì)于交叉功能的測(cè)試，仍采用手動(dòng)方式執(zhí)行，例如涉及多類(lèi)用戶頻繁登錄和退出系統(tǒng)的流程，自動(dòng)化測(cè)試腳本的開(kāi)發(fā)和維護(hù)將十分繁瑣和困難。自動(dòng)化測(cè)試設(shè)計(jì)2.測(cè)試重點(diǎn)對(duì)于管理員用戶的功能測(cè)試，最重要的功能模塊是添加用戶，即測(cè)試的重點(diǎn)。對(duì)各用戶之間的交叉功能測(cè)試，重點(diǎn)應(yīng)放在用戶超過(guò)使用期限后無(wú)法登錄、用戶被刪除后無(wú)法登錄等內(nèi)容。3.測(cè)試難點(diǎn)基于QTP進(jìn)行自動(dòng)化功能測(cè)試的難點(diǎn)在于：(1)預(yù)置條件的設(shè)置。例如，測(cè)試添加教師用戶時(shí)，如何設(shè)置預(yù)置條件以保證每次添加用戶時(shí)，系統(tǒng)環(huán)境一致。(2)參數(shù)的設(shè)置。例如，設(shè)計(jì)3組輸入數(shù)據(jù)，如何將這3組數(shù)據(jù)寫(xiě)入測(cè)試腳本。(3)檢查點(diǎn)的插入。例如，添加用戶后，如何添加檢查點(diǎn)來(lái)驗(yàn)證添加的用戶是否成功，以及如何驗(yàn)證添加的用戶是否按順序添加。QTP概述QTP(QuickTestProfessional)采用關(guān)鍵詞驅(qū)動(dòng)測(cè)試的理念執(zhí)行測(cè)試，用于執(zhí)行重復(fù)的手動(dòng)測(cè)試，簡(jiǎn)化測(cè)試創(chuàng)建和維護(hù)工作，主要用在回歸測(cè)試中，或測(cè)試同一軟件的新版本。(1)QTP測(cè)試的3個(gè)階段使用QTP測(cè)試包括3個(gè)階段：創(chuàng)建測(cè)試或組件、運(yùn)行測(cè)試或組件以及分析結(jié)果。(2)QTP測(cè)試的注意事項(xiàng)①使用QTP進(jìn)行測(cè)試時(shí)，應(yīng)了解QTP的加載項(xiàng)。②了解QTP對(duì)瀏覽器的要求。③QTP的3種錄制模式。QTP有3種錄制模式：正常錄制模式，模擬錄制模式和低級(jí)錄制模式。QTP概述④QTP的對(duì)象庫(kù)。腳本中用到的對(duì)象都必須存在對(duì)象庫(kù)中，若在腳本中使用了某個(gè)對(duì)象而對(duì)象庫(kù)中并不存在，運(yùn)行腳本時(shí)就會(huì)出現(xiàn)找不到相應(yīng)對(duì)象的錯(cuò)誤。⑤設(shè)置Action的執(zhí)行次數(shù)。若執(zhí)行數(shù)據(jù)列表中的多組測(cè)試數(shù)據(jù)，應(yīng)設(shè)置Action的執(zhí)行次數(shù)，在QTP的“當(dāng)前Action”→“ActionCallProperties”中勾選“Runonallrows”，或勾選“Runfromrow()torow()”，僅選擇其中指定的幾行參數(shù)來(lái)執(zhí)行。⑥預(yù)置條件的設(shè)置。QTP腳本在運(yùn)行前均有預(yù)置條件。QTP概述(3)QTP的合理應(yīng)用QTP測(cè)試的重點(diǎn)不是實(shí)現(xiàn)測(cè)試的自動(dòng)化，而是提高測(cè)試效率。在實(shí)際的測(cè)試過(guò)程中，如何合理地應(yīng)用QTP是使用QTP的難點(diǎn)所在。軟件系統(tǒng)開(kāi)發(fā)的初期是不適合用QTP進(jìn)行測(cè)試的，此時(shí)，待測(cè)系統(tǒng)還不穩(wěn)定，如果這時(shí)就采用QTP進(jìn)行測(cè)試，將需要投入大量的成本，且一旦被測(cè)系統(tǒng)發(fā)生重大改變，將影響很多的自動(dòng)化測(cè)試和組件。總的來(lái)說(shuō)，QTP主要是用于回歸測(cè)試，它最大的好處是可以重用，在被測(cè)系統(tǒng)改動(dòng)不大的情況下，由QTP將之前的用例全部執(zhí)行一次，使用回歸的次數(shù)越多，使用率越高，就越能體現(xiàn)使用QTP的優(yōu)勢(shì)。基于QTP的功能測(cè)試1.測(cè)試環(huán)境該網(wǎng)絡(luò)教學(xué)平臺(tái)的測(cè)試環(huán)境如表11.13所示。基于QTP的功能測(cè)試2.測(cè)試腳本開(kāi)發(fā)(1)測(cè)試腳本編寫(xiě)的一般步驟測(cè)試腳本，也就是測(cè)試用例的實(shí)現(xiàn)過(guò)程，一般步驟為：①錄制，將用例中需要測(cè)試的具體步驟用QTP錄制下來(lái)；②腳本增強(qiáng)，修改腳本以滿足測(cè)試的需要，如添加檢查點(diǎn)等；③測(cè)試數(shù)據(jù)添加，如果腳本中進(jìn)行了參數(shù)化，將需要測(cè)試的數(shù)據(jù)添加到數(shù)據(jù)列表中；④對(duì)象庫(kù)管理，如果修改腳本時(shí)用到了新的對(duì)象，則將該對(duì)象添加到對(duì)象庫(kù)中便于識(shí)別。基于QTP的功能測(cè)試(2)測(cè)試腳本開(kāi)發(fā)(以成功添加教師用戶為例)以添加教師用戶的測(cè)試為例，針對(duì)有效用戶的測(cè)試見(jiàn)表11.9中測(cè)試需求A1.1.1對(duì)應(yīng)的測(cè)試用例。(3)測(cè)試腳本開(kāi)發(fā)(以添加教師用戶的有效性校驗(yàn)為例)仍以添加教師用戶為例，當(dāng)輸入數(shù)據(jù)無(wú)效時(shí)對(duì)應(yīng)的部分測(cè)試用例見(jiàn)表11.10，完整的用例應(yīng)為8個(gè)，此時(shí)，所有執(zhí)行步驟完全相同，可直接通過(guò)參數(shù)化輸入測(cè)試數(shù)據(jù)。基于QTP的功能測(cè)試3.測(cè)試執(zhí)行腳本編寫(xiě)完成后，即可執(zhí)行測(cè)試腳本。表11.10中測(cè)試用例腳本的執(zhí)行過(guò)程部分截圖如圖11.21-圖11.23所示。可以看到，當(dāng)用戶名末4位與身份證號(hào)不相同時(shí)，系統(tǒng)告警。基于QTP的功能測(cè)試在實(shí)際執(zhí)行過(guò)程中可能會(huì)碰到這樣的情況，運(yùn)行測(cè)試腳本時(shí)，一些隨機(jī)生成的驗(yàn)證碼無(wú)法用腳本來(lái)輸入，這時(shí)需要在腳本運(yùn)行的過(guò)程中手動(dòng)添加這些內(nèi)容，且手動(dòng)添加內(nèi)容時(shí)，時(shí)間不能過(guò)長(zhǎng)，否則腳本執(zhí)行將中斷，如圖11.24所示。基于QTP的功能測(cè)試4.測(cè)試結(jié)果分析測(cè)試腳本執(zhí)行完成后，QTP自動(dòng)生成測(cè)試報(bào)告，列表如圖11.25所示。圖中打勾的表示測(cè)試通過(guò)，未發(fā)現(xiàn)缺陷。測(cè)試結(jié)果中身份證驗(yàn)證的結(jié)果如圖11.26所示。基于QTP的功能測(cè)試驗(yàn)證輸入無(wú)效數(shù)據(jù)時(shí)系統(tǒng)是否告警的結(jié)果如圖11.27所示。當(dāng)測(cè)試腳本執(zhí)行后測(cè)試不通過(guò)，則將在測(cè)試報(bào)告相應(yīng)項(xiàng)的前面顯示叉號(hào)，圖11.28給出了測(cè)試腳本A1.1.4的執(zhí)行結(jié)果。基于QTP的功能測(cè)試從圖11.28可以看出，用戶名重復(fù)時(shí)存在Bug，詳細(xì)內(nèi)容見(jiàn)圖11.29，測(cè)試報(bào)告中指出錯(cuò)誤原因?yàn)椤坝脩裘貜?fù)系統(tǒng)沒(méi)有告警，出現(xiàn)功能錯(cuò)誤”，對(duì)應(yīng)的缺陷寫(xiě)入缺陷報(bào)告，不再給出示例。實(shí)際上，在詳細(xì)的手動(dòng)測(cè)試之后，基于QTP對(duì)該網(wǎng)絡(luò)教學(xué)平臺(tái)進(jìn)行自動(dòng)化測(cè)試后又發(fā)現(xiàn)了20個(gè)缺陷。測(cè)試小結(jié)網(wǎng)絡(luò)教學(xué)平臺(tái)是一個(gè)典型的Web應(yīng)用系統(tǒng)，包含多類(lèi)用戶、多個(gè)子系統(tǒng)、提供較多功能，在功能測(cè)試的層面上，當(dāng)流程、界面穩(wěn)定時(shí)，可采用QTP工具進(jìn)行自動(dòng)化功能測(cè)試。良好的測(cè)試效果關(guān)鍵取決于測(cè)試用例的設(shè)計(jì)，以及如何根據(jù)測(cè)試用例的要求來(lái)構(gòu)建測(cè)試腳本，通過(guò)原始的錄制、回放方式得到的腳本肯定是不滿足要求的，而設(shè)計(jì)得過(guò)于復(fù)雜，包含太多流程、操作和校驗(yàn)點(diǎn)的腳本也是不適用的。04分布式搜索系統(tǒng)案例實(shí)踐案例說(shuō)明分布式搜索系統(tǒng)是一個(gè)基于B/S模式的圖書(shū)館館藏文獻(xiàn)查找系統(tǒng)，系統(tǒng)核心功能是提供智能搜索服務(wù)，即授權(quán)用戶登錄系統(tǒng)后，通過(guò)輸入一些描述信息，如文獻(xiàn)題目、作者、書(shū)評(píng)、目錄、內(nèi)容簡(jiǎn)介等內(nèi)容，這些內(nèi)容可能是完整的，或者僅給出部分詞匯，也可能只是與文獻(xiàn)相關(guān)描述有一定關(guān)聯(lián)而已，系統(tǒng)需通過(guò)自動(dòng)對(duì)用戶輸入進(jìn)行理解，并在資料庫(kù)中進(jìn)行搜索匹配，然后將與用戶輸入最匹配的館藏文獻(xiàn)以一定的排序方式呈現(xiàn)給用戶，用戶通過(guò)瀏覽文獻(xiàn)來(lái)查閱各館藏文獻(xiàn)的具體描述信息，并判斷該文獻(xiàn)是否是自己所需要借閱的文獻(xiàn)。案例說(shuō)明該系統(tǒng)的核心特點(diǎn)是：(1)海量數(shù)據(jù)的分布式存儲(chǔ)。由于文獻(xiàn)數(shù)量眾多，每個(gè)館藏文獻(xiàn)不僅包含標(biāo)題、作者、出版社等基本信息，還可能包含多種格式的附件，且文獻(xiàn)數(shù)量將隨著時(shí)間的推移呈逐步上升趨勢(shì)。面對(duì)TB級(jí)的文獻(xiàn)存儲(chǔ)量，必須采用分布式存儲(chǔ)方式對(duì)其進(jìn)行存儲(chǔ)。(2)分布式搜索方式。系統(tǒng)用戶數(shù)量眾多，且分散在多個(gè)地點(diǎn)，用戶數(shù)也呈穩(wěn)步上升趨勢(shì)，為保證為用戶提供快速的搜索響應(yīng)，必須采用分布式搜索方式。(3)高穩(wěn)定、可靠的系統(tǒng)部署。對(duì)于一個(gè)龐大的系統(tǒng)而言，必須保證整個(gè)系統(tǒng)部署的穩(wěn)定、可靠，一旦系統(tǒng)停止服務(wù)，即使極短時(shí)間，也很可能導(dǎo)致投訴電話被打爆。(4)智能化的搜索。用戶在搜索文獻(xiàn)時(shí)并不知道系統(tǒng)中有哪些文獻(xiàn)，其輸入可能很不專(zhuān)業(yè)，系統(tǒng)需自動(dòng)對(duì)用戶輸入進(jìn)行詞法、語(yǔ)法甚至語(yǔ)義分析，然后基于專(zhuān)業(yè)特性計(jì)算文獻(xiàn)匹配度，同時(shí)為用戶推薦更多相關(guān)文獻(xiàn)。自動(dòng)化測(cè)試設(shè)計(jì)分布式搜索系統(tǒng)的本質(zhì)是基于分布式存儲(chǔ)和分布式搜索提供一個(gè)穩(wěn)定、可靠的T級(jí)海量數(shù)據(jù)智能搜索服務(wù)，其中，智能搜索的效果主要通過(guò)查全率、查準(zhǔn)率、用戶反饋等指標(biāo)加以衡量，不再詳述。在此主要考慮的是作為一個(gè)應(yīng)用系統(tǒng)而應(yīng)滿足的核心功能的性能要求，即面對(duì)T級(jí)海量數(shù)據(jù)，面對(duì)大量用戶的并發(fā)搜索請(qǐng)求，系統(tǒng)性能如何。然而，在系統(tǒng)上線之前，用戶不可能提供實(shí)際的數(shù)據(jù)，且一旦上線，不能允許系統(tǒng)頻繁出錯(cuò)，這樣的性能測(cè)試難點(diǎn)在于：(1)如何通過(guò)性能測(cè)試證明當(dāng)前方案的可行性；(2)如何通過(guò)性能測(cè)試預(yù)測(cè)實(shí)際上線后的性能；(3)如何通過(guò)性能測(cè)試來(lái)尋找系統(tǒng)進(jìn)一步優(yōu)化的方向。LoadRunner概述LoadRunner是惠普公司開(kāi)發(fā)的一款性能測(cè)試工具，主要用于C/S和B/S結(jié)構(gòu)的軟件系統(tǒng)測(cè)試。該產(chǎn)品通過(guò)模擬虛擬的并發(fā)用戶數(shù)來(lái)對(duì)系統(tǒng)進(jìn)行測(cè)試。與WinRunner不同，LoadRunner(簡(jiǎn)稱(chēng)LR)可以跨平臺(tái)使用，適用于Windows、Linux等多種操作系統(tǒng)下。LoadRunner是最好的企業(yè)級(jí)軟件性能測(cè)試工具之一。LR的運(yùn)行機(jī)制是通過(guò)用一臺(tái)或幾臺(tái)計(jì)算機(jī)產(chǎn)生成千上萬(wàn)虛擬用戶，模擬實(shí)際用戶行為，虛擬用戶(Vuser)通過(guò)執(zhí)行典型業(yè)務(wù)流程模擬設(shè)計(jì)用戶的操作，對(duì)于Vuser執(zhí)行的每個(gè)操作，LR向服務(wù)器或類(lèi)似的企業(yè)系統(tǒng)提交輸入信息，增加Vuser的數(shù)量可以增大系統(tǒng)上的負(fù)載。若要模擬較多用戶負(fù)載的情況，可通過(guò)Controller設(shè)定虛擬用戶數(shù)執(zhí)行一系列任務(wù)的Vuser，如觀察1000個(gè)Vuser同時(shí)登錄系統(tǒng)并進(jìn)行搜索時(shí)服務(wù)器的行為。通過(guò)使用LR將客戶端/服務(wù)器的性能測(cè)試需求劃分為多個(gè)場(chǎng)景，通過(guò)場(chǎng)景定義每個(gè)測(cè)試會(huì)話中發(fā)生的事件。LoadRunner概述LR提供多種Vuser類(lèi)型，適于各種特定負(fù)載測(cè)試環(huán)境。Vuser使用Vuser腳本進(jìn)行描述，腳本中包含在方案中獨(dú)立并錄制服務(wù)器性能的函數(shù)。LR由如下3部分構(gòu)成：(1)VuGen:腳本生成器，是LR用于開(kāi)發(fā)Vuser腳本的主要工具，可用于錄制和運(yùn)行腳本。(2)Controller:控制器，通過(guò)手動(dòng)和基于目標(biāo)的兩種方法來(lái)設(shè)計(jì)場(chǎng)景，并通過(guò)設(shè)置場(chǎng)景模擬用戶行為，在場(chǎng)景運(yùn)行期間自動(dòng)收集應(yīng)用服務(wù)器軟、硬件相關(guān)數(shù)據(jù)，存放到小型數(shù)據(jù)庫(kù)文件中，從而獨(dú)立監(jiān)控和分析系統(tǒng)性能和功能。(3)Analysis:分析器，當(dāng)運(yùn)行完成，數(shù)據(jù)收集工作完成后，通過(guò)該分析器對(duì)測(cè)試結(jié)果數(shù)據(jù)進(jìn)行分析，包括各種圖表，并可根據(jù)需要進(jìn)行合并，還可以比較兩次運(yùn)行結(jié)果之間的差異，利于系統(tǒng)的性能調(diào)優(yōu)，最終的輸出結(jié)果也可通過(guò)該分析器以Word或HTML格式輸出。基于LoadRunner的性能測(cè)試1.測(cè)試環(huán)境(1)硬件環(huán)境2臺(tái)主服務(wù)器，配置分別為：①AMDAthlon(tm)ⅡX4635Processor2.90GHz，內(nèi)存4.00GB②Intel(R)Core(TM)2DuoCPUT83002.40GHz，內(nèi)存2.00GB2臺(tái)從服務(wù)器，配置均為：AMDAthlon(tm)ⅡX2240Processor2.81GHz，內(nèi)存2.00GB1臺(tái)測(cè)試客戶端，配置為：CPU:Intel(R)Core(TM)i5-2410MCPU2.30GHz，內(nèi)存2.00GB(2)軟件環(huán)境操作系統(tǒng)：Ubuntu10.04，WindowsXP軟件配置：Jdk1.6.029，Tomcat6.0.35，Apache2.22，Solr3.5.0基于LoadRunner的性能測(cè)試(3)系統(tǒng)部署系統(tǒng)部署如圖11.30所示。基于LoadRunner的性能測(cè)試(4)網(wǎng)絡(luò)環(huán)境網(wǎng)絡(luò)環(huán)境如圖11.31所示。基于LoadRunner的性能測(cè)試2.測(cè)試數(shù)據(jù)測(cè)試所用原始數(shù)據(jù)見(jiàn)表11.14(在此僅截取2012年3月23日到3月26日之間的數(shù)據(jù)):基于LoadRunner的性能測(cè)試生成的索引數(shù)據(jù)見(jiàn)表11.15。搜索主要是針對(duì)索引數(shù)據(jù)展開(kāi)，而非針對(duì)原始數(shù)據(jù)進(jìn)行搜索，因此，需要重點(diǎn)關(guān)注的不是原始數(shù)據(jù)的規(guī)模，而是生成的索引數(shù)據(jù)的規(guī)模，以及原始數(shù)據(jù)與索引數(shù)據(jù)在規(guī)模上的關(guān)系。從數(shù)據(jù)對(duì)比看出，索引數(shù)據(jù)相比原始數(shù)據(jù)的規(guī)模級(jí)別相差較大，其存儲(chǔ)要求不高，且數(shù)據(jù)核心在數(shù)據(jù)庫(kù)數(shù)據(jù)而非附件文檔，為此，構(gòu)造原始數(shù)據(jù)時(shí)重點(diǎn)并非附件文檔，主要利用數(shù)據(jù)庫(kù)數(shù)據(jù)增大索引數(shù)據(jù)規(guī)模，這樣也可節(jié)省硬盤(pán)空間，便于展開(kāi)有限條件下的性能測(cè)試。基于LoadRunner的性能測(cè)試3.測(cè)試需求測(cè)試主要針對(duì)搜索模塊。性能要求：分別在250、500、1000、1500、2000的并發(fā)用戶數(shù)條件下，要求系統(tǒng)的平均響應(yīng)時(shí)間不大于3秒。4.測(cè)試風(fēng)險(xiǎn)本性能測(cè)試并非在實(shí)際用戶使用環(huán)境中進(jìn)行測(cè)試(即模擬的測(cè)試環(huán)境和客戶實(shí)際使用環(huán)境配置差別較大)，因此，測(cè)試結(jié)果與實(shí)際使用環(huán)境中的結(jié)果可能存在一定的出入。另外，測(cè)試環(huán)境中的數(shù)據(jù)量相比實(shí)際使用環(huán)境中數(shù)據(jù)量少得多，且系統(tǒng)上線后