集成測(cè)試

　　某設(shè)計(jì)人員習(xí)慣于把所有模塊按設(shè)計(jì)要求一次全部組裝起來(lái)，然后進(jìn)行整體測(cè)試，這稱為非增量式集成。這種方法容易出現(xiàn)混亂。因?yàn)闇y(cè)試時(shí)可能發(fā)現(xiàn)一大堆錯(cuò)誤，為每個(gè)錯(cuò)誤定位和糾正非常困難，并且在改正一個(gè)錯(cuò)誤的同時(shí)又可能引入新的錯(cuò)誤，新舊錯(cuò)誤混雜，更難斷定出錯(cuò)的原因和位置。與之相反的是增量式集成方法，程序一段一段地?cái)U(kuò)展，測(cè)試的范圍一步一步地增大，錯(cuò)誤易于定位和糾正，界面的測(cè)試亦可做到完全徹底。下面討論兩種增量式集成方法。
　　概述
　　集成測(cè)試，也叫組裝測(cè)試或聯(lián)合測(cè)試。在單元測(cè)試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求）如根據(jù)結(jié)構(gòu)圖〕組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測(cè)試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來(lái)也能正常的工作。程序在某些局部反映不出來(lái)的問(wèn)題，在全局上很可能暴露出來(lái)，影響功能的實(shí)現(xiàn)。
　　集成測(cè)試方法
　　集成測(cè)試應(yīng)該考慮以下問(wèn)題：
　　1、在把各個(gè)模塊連接起來(lái)的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失；
　　2、各個(gè)子功能組合起來(lái)，能否達(dá)到預(yù)期要求的父功能；
　　3、一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響；
　　4、全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問(wèn)題；
　　5、單個(gè)模塊的誤差積累起來(lái)，是否會(huì)放大，從而達(dá)到不可接受的程度。
　　因此，單元測(cè)試后，有必要進(jìn)行集成測(cè)試，發(fā)現(xiàn)并排除在模塊連接中可能發(fā)生的上述問(wèn)題，最終構(gòu)成要求的軟件子系統(tǒng)或系統(tǒng)。對(duì)子系統(tǒng)，集成測(cè)試也叫部件測(cè)試。
　　任何合理地組織集成測(cè)試，即選擇什么方式把模塊組裝起來(lái)形成一個(gè)可運(yùn)行的系統(tǒng),直接影響到模塊測(cè)試用例的形式、所用測(cè)試工具的類型、模塊編號(hào)和測(cè)試的次序、生成測(cè)試用例和調(diào)試的費(fèi)用。通常，有兩種不同的組裝方式：一次性組裝方式和增值式組裝方式。
　　集成測(cè)試的實(shí)施
　　集成測(cè)試是一種正規(guī)測(cè)試過(guò)程，必須精心計(jì)劃，并與單元測(cè)試的完成時(shí)間協(xié)調(diào)起來(lái)。在制定測(cè)試計(jì)劃時(shí)，應(yīng)考慮如下因素：
　　1、是采用何種系統(tǒng)組裝方法來(lái)進(jìn)行組裝測(cè)試；
　　2、組裝測(cè)試過(guò)程中連接各個(gè)模塊的順序；
　　3、模塊代碼編制和測(cè)試進(jìn)度是否與組裝測(cè)試的順序一致
　　4、測(cè)試過(guò)程中是否需要專門的硬件設(shè)備；
　　解決了上述問(wèn)題之后，就可以列出各個(gè)模塊的編制、測(cè)試計(jì)劃表，標(biāo)明每個(gè)模塊單元測(cè)試完成的日期、首次集成測(cè)試的日期、集成測(cè)試全部完成的日期、以及需要的測(cè)試用例和所期望的測(cè)試結(jié)果。
　　在缺少軟件測(cè)試所需要的硬件設(shè)備時(shí)，應(yīng)檢查該硬件的交付日期是否與集成測(cè)試計(jì)劃一致。例如，若測(cè)試需要數(shù)字化儀和繪圖儀，則相應(yīng)測(cè)試應(yīng)安排在這些設(shè)備能夠投入使用之時(shí)，并需要為硬件的安裝和交付使用保留一段時(shí)間，以留下時(shí)間余量。此外，在測(cè)試計(jì)劃中需要考慮測(cè)試所需軟件（驅(qū)動(dòng)模塊、樁模塊、測(cè)試用例生成程序等）的準(zhǔn)備情況。
　　集成測(cè)試完成標(biāo)準(zhǔn)
　　怎樣判定集成測(cè)試過(guò)程完成了, 可按以下幾個(gè)方面檢查:
　　1、成功地執(zhí)行了測(cè)試計(jì)劃中規(guī)定的所有集成測(cè)試；
　　2、修正了所發(fā)現(xiàn)的錯(cuò)誤；
　　3、測(cè)試結(jié)果通過(guò)了專門小組的評(píng)審。
　　集成測(cè)試應(yīng)由專門的測(cè)試小組來(lái)進(jìn)行，測(cè)試小組由有經(jīng)驗(yàn)的系統(tǒng)設(shè)計(jì)人員和程序員組成。整個(gè)測(cè)試活動(dòng)要在評(píng)審人員出席的情況下進(jìn)行。
　　在完成預(yù)定的組裝測(cè)試工作之后，測(cè)試小組應(yīng)負(fù)責(zé)對(duì)測(cè)試結(jié)果進(jìn)行整理、分析，形成測(cè)試報(bào)告。測(cè)試報(bào)告中要記錄實(shí)際的測(cè)試結(jié)果、在測(cè)試中發(fā)現(xiàn)的問(wèn)題、解決這些問(wèn)題的方法以及解決之后再次測(cè)試的結(jié)果。此外還應(yīng)提出目前不能解決、還需要管理人員和開(kāi)發(fā)人員注意的一些問(wèn)題，提供測(cè)試評(píng)審和最終決策，以提出處理意見(jiàn)。
　　集成測(cè)試
　　集成測(cè)試（也叫組裝測(cè)試，聯(lián)合測(cè)試）是單元測(cè)試的邏輯擴(kuò)展。它的最簡(jiǎn)單的形式是：兩個(gè)已經(jīng)測(cè)試過(guò)的單元組合成一個(gè)組件，并且測(cè)試它們之間的接口。從這一層意義上講，組件是指多個(gè)單元的集成聚合。在現(xiàn)實(shí)方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測(cè)試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起測(cè)試。最后，將構(gòu)成進(jìn)程的所有模塊一起測(cè)試。此外，如果程序由多個(gè)進(jìn)程組成，應(yīng)該成對(duì)測(cè)試它們，而不是同時(shí)測(cè)試所有進(jìn)程。
　　集成測(cè)試識(shí)別組合單元時(shí)出現(xiàn)的問(wèn)題。通過(guò)使用要求在組合單元前測(cè)試每個(gè)單元并確保每個(gè)單元的生存能力的測(cè)試計(jì)劃，可以知道在組合單元時(shí)所發(fā)現(xiàn)的任何錯(cuò)誤很可能與單元之間的接口有關(guān)。這種方法將可能發(fā)生的情況數(shù)量減少到更簡(jiǎn)單的分析級(jí)別。
　　集成測(cè)試是在單元測(cè)試的基礎(chǔ)上，測(cè)試在將所有的軟件單元按照概要設(shè)計(jì)規(guī)格說(shuō)明的要求組裝成模塊、子系統(tǒng)或系統(tǒng)的過(guò)程中各部分工作是否達(dá)到或?qū)崿F(xiàn)相應(yīng)技術(shù)指標(biāo)及要求的活動(dòng)。也就是說(shuō)，在集成測(cè)試之前，單元測(cè)試應(yīng)該已經(jīng)完成，集成測(cè)試中所使用的對(duì)象應(yīng)該是已經(jīng)經(jīng)過(guò)單元測(cè)試的軟件單元。這一點(diǎn)很重要，因?yàn)槿绻�不�?jīng)過(guò)單元測(cè)試，那么集成測(cè)試的效果將會(huì)受到很大影響，并且會(huì)大幅增加軟件單元代碼糾錯(cuò)的代價(jià)。
　　集成測(cè)試是單元測(cè)試的邏輯擴(kuò)展。在現(xiàn)實(shí)方案中，集成是指多個(gè)單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程序的更大部分，如分系統(tǒng)或系統(tǒng)。集成測(cè)試采用的方法是測(cè)試軟件單元的組合能否正常工作，以及與其他組的模塊能否集成起來(lái)工作。最后，還要測(cè)試構(gòu)成系統(tǒng)的所有模塊組合能否正常工作。集成測(cè)試所持的主要標(biāo)準(zhǔn)是《軟件概要設(shè)計(jì)規(guī)格說(shuō)明》，任何不符合該說(shuō)明的程序模塊行為都應(yīng)該加以記載并上報(bào)。
　　所有的軟件項(xiàng)目都不能擺脫系統(tǒng)集成這個(gè)階段。不管采用什么開(kāi)發(fā)模式，具體的開(kāi)發(fā)工作總得從一個(gè)一個(gè)的軟件單元做起，軟件單元只有經(jīng)過(guò)集成才能形成一個(gè)有機(jī)的整體。具體的集成過(guò)程可能是顯性的也可能是隱性的。只要有集成，總是會(huì)出現(xiàn)一些常見(jiàn)問(wèn)題，工程實(shí)踐中，幾乎不存在軟件單元組裝過(guò)程中不出任何問(wèn)題的情況。從圖1可以看出，集成測(cè)試需要花費(fèi)的時(shí)間遠(yuǎn)遠(yuǎn)超過(guò)單元測(cè)試，直接從單元測(cè)試過(guò)渡到系統(tǒng)測(cè)試是極不妥當(dāng)?shù)淖龇ā?
　　集成測(cè)試的必要性還在于一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來(lái)也能正常工作。程序在某些局部反映不出來(lái)的問(wèn)題，有可能在全局上會(huì)暴露出來(lái)，影響功能的實(shí)現(xiàn)。此外，在某些開(kāi)發(fā)模式中，如迭代式開(kāi)發(fā)，設(shè)計(jì)和實(shí)現(xiàn)是迭代進(jìn)行的。在這種情況下，集成測(cè)試的意義還在于它能間接地驗(yàn)證概要設(shè)計(jì)是否具有可行性。
　　集成測(cè)試的目的是確保各單元組合在一起后能夠按既定意圖協(xié)作運(yùn)行，并確保增量的行為正確。它所測(cè)試的內(nèi)容包括單元間的接口以及集成后的功能。使用黑盒測(cè)試方法測(cè)試集成的功能。并且對(duì)以前的集成進(jìn)行回歸測(cè)試。
　　一、集成測(cè)試過(guò)程
　　二、單元測(cè)試工作內(nèi)容及其流程
　　三、集成測(cè)試需求獲取
　　集成測(cè)試需求所確定的是對(duì)某一集成工作版本的測(cè)試的內(nèi)容，即測(cè)試的具體對(duì)象。集成測(cè)試需求主要來(lái)源于設(shè)計(jì)模型（Design Model）和集成構(gòu)件計(jì)劃（Integration Build Plan）。集成測(cè)試著重于集成版本的外部接口的行為。因此，測(cè)試需求須具有可觀測(cè)、可測(cè)評(píng)性。
　　1． 集成工作版本應(yīng)分析其類協(xié)作與消息序列，從而找出該工作版本的外部接口。
　　2． 由集成工作版本的外部接口確定集成測(cè)試用例。
　　3． 測(cè)試用例應(yīng)覆蓋工作版本每一外部接口的所有消息流序列。
　　注意：一個(gè)外部接口和測(cè)試用例的關(guān)系是多對(duì)多，部分集成工作版本的測(cè)試需求可映射到系統(tǒng)測(cè)試需求，因此對(duì)這些集成測(cè)試用例可采用重用系統(tǒng)測(cè)試用例技術(shù)。
　　四、集成測(cè)試工作機(jī)制
　　軟件集成測(cè)試工作由產(chǎn)品評(píng)測(cè)部擔(dān)任。需要項(xiàng)目組相關(guān)角色配合完成。如圖示：
　　軟件評(píng)測(cè)部：
　　軟件項(xiàng)目組：
　　集成測(cè)試工作內(nèi)容及其流程工作流程：
　　五、集成測(cè)試產(chǎn)生的工件清單
　　1、 軟件集成測(cè)試計(jì)劃
　　2、 集成測(cè)試用例
　　3、 測(cè)試過(guò)程
　　4、 測(cè)試腳本
　　5、 測(cè)試日志
　　6、 測(cè)試評(píng)估摘要
　　六、集成測(cè)試常用方案選型
　　集成測(cè)試的實(shí)施方案有很多種，如自底向上集成測(cè)試、自頂向下集成測(cè)試、Big-Bang集成測(cè)試、三明治集成測(cè)試、核心集成測(cè)試、分層集成測(cè)試、基于使用的集成測(cè)試等。在此，筆者將重點(diǎn)討論其中一些經(jīng)實(shí)踐檢驗(yàn)和一些證實(shí)有效的集成測(cè)試方案。
　　&＃8226;自底向上集成測(cè)試
　　自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地繼承、吸收了這種集成方式的思想。自底向上集成方式從程序模塊結(jié)構(gòu)中最底層的模塊開(kāi)始組裝和測(cè)試。因?yàn)槟�塊是自底向上進(jìn)行組裝的，對(duì)于一個(gè)給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）事前已經(jīng)完成組裝并經(jīng)過(guò)測(cè)試，所以不再需要編制樁模塊（一種能模擬真實(shí)模塊，給待測(cè)模塊提供調(diào)用接口或數(shù)據(jù)的測(cè)試用軟件模塊）。自底向上集成測(cè)試的步驟大致如下:
　　步驟一: 按照概要設(shè)計(jì)規(guī)格說(shuō)明，明確有哪些被測(cè)模塊。在熟悉被測(cè)模塊性質(zhì)的基礎(chǔ)上對(duì)被測(cè)模塊進(jìn)行分層，在同一層次上的測(cè)試可以并行進(jìn)行，然后排出測(cè)試活動(dòng)的先后關(guān)系，制定測(cè)試進(jìn)度計(jì)劃。圖2給出了自底向上的集成測(cè)試過(guò)程中各測(cè)試活動(dòng)的拓?fù)潢P(guān)系。利用圖論的相關(guān)知識(shí)，可以排出各活動(dòng)之間的時(shí)間序列關(guān)系，處于同一層次的測(cè)試活動(dòng)可以同時(shí)進(jìn)行，而不會(huì)相互影響。
　　步驟二: 在步驟一的基礎(chǔ)上，按時(shí)間線序關(guān)系，將軟件單元集成為模塊，并測(cè)試在集成過(guò)程中出現(xiàn)的問(wèn)題。這里，可能需要測(cè)試人員開(kāi)發(fā)一些驅(qū)動(dòng)模塊來(lái)驅(qū)動(dòng)集成活動(dòng)中形成的被測(cè)模塊。對(duì)于比較大的模塊，可以先將其中的某幾個(gè)軟件單元集成為子模塊，然后再集成為一個(gè)較大的模塊。
　　步驟三: 將各軟件模塊集成為子系統(tǒng)（或分系統(tǒng)）。檢測(cè)各自子系統(tǒng)是否能正常工作。同樣，可能需要測(cè)試人員開(kāi)發(fā)少量的驅(qū)動(dòng)模塊來(lái)驅(qū)動(dòng)被測(cè)子系統(tǒng)。
　　步驟四: 將各子系統(tǒng)集成為最終用戶系統(tǒng)，測(cè)試是否存在各分系統(tǒng)能否在最終用戶系統(tǒng)中正常工作。
　　方案點(diǎn)評(píng): 自底向上的集成測(cè)試方案是工程實(shí)踐中最常用的測(cè)試方法。相關(guān)技術(shù)也較為成熟。它的優(yōu)點(diǎn)很明顯: 管理方便、測(cè)試人員能較好地鎖定軟件故障所在位置。但它對(duì)于某些開(kāi)發(fā)模式不適用，如使用XP開(kāi)發(fā)方法，它會(huì)要求測(cè)試人員在全部軟件單元實(shí)現(xiàn)之前完成核心軟件部件的集成測(cè)試。盡管如此，自底向上的集成測(cè)試方法仍不失為一個(gè)可供參考的集成測(cè)試方案。
　　&＃8226;核心系統(tǒng)先行集成測(cè)試
　　核心系統(tǒng)先行集成測(cè)試法的思想是先對(duì)核心軟件部件進(jìn)行集成測(cè)試，在測(cè)試通過(guò)的基礎(chǔ)上再按各外圍軟件部件的重要程度逐個(gè)集成到核心系統(tǒng)中。每次加入一個(gè)外圍軟件部件都產(chǎn)生一個(gè)產(chǎn)品基線，直至最后形成穩(wěn)定的軟件產(chǎn)品。核心系統(tǒng)先行集成測(cè)試法對(duì)應(yīng)的集成過(guò)程是一個(gè)逐漸趨于閉合的螺旋形曲線，代表產(chǎn)品逐步定型的過(guò)程。其步驟如下:
　　步驟一: 對(duì)核心系統(tǒng)中的每個(gè)模塊進(jìn)行單獨(dú)的、充分的測(cè)試，必要時(shí)使用驅(qū)動(dòng)模塊和樁模塊;
　　步驟二: 對(duì)于核心系統(tǒng)中的所有模塊一次性集合到被測(cè)系統(tǒng)中，解決集成中出現(xiàn)的各類問(wèn)題。在核心系統(tǒng)規(guī)模相對(duì)較大的情況下，也可以按照自底向上的步驟，集成核心系統(tǒng)的各組成模塊。
　　步驟三: 按照各外圍軟件部件的重要程度以及模塊間的相互制約關(guān)系，擬定外圍軟件部件集成到核心系統(tǒng)中的順序方案。方案經(jīng)評(píng)審以后，即可進(jìn)行外圍軟件部件的集成。
　　步驟四: 在外圍軟件部件添加到核心系統(tǒng)以前，外圍軟件部件應(yīng)先完成內(nèi)部的模塊級(jí)集成測(cè)試。
　　步驟五: 按順序不斷加入外圍軟件部件，排除外圍軟件部件集成中出現(xiàn)的問(wèn)題，形成最終的用戶系統(tǒng)。
　　方案點(diǎn)評(píng): 該集成測(cè)試方法對(duì)于快速軟件開(kāi)發(fā)很有效果，適合較復(fù)雜系統(tǒng)的集成測(cè)試，能保證一些重要的功能和服務(wù)的實(shí)現(xiàn)。缺點(diǎn)是采用此法的系統(tǒng)一般應(yīng)能明確區(qū)分核心軟件部件和外圍軟件部件，核心軟件部件應(yīng)具有較高的耦合度，外圍軟件部件內(nèi)部也應(yīng)具有較高的耦合度，但各外圍軟件部件之間應(yīng)具有較低的耦合度。
　　&＃8226;高頻集成測(cè)試
　　高頻集成測(cè)試是指同步于軟件開(kāi)發(fā)過(guò)程，每隔一段時(shí)間對(duì)開(kāi)發(fā)團(tuán)隊(duì)的現(xiàn)有代碼進(jìn)行一次集成測(cè)試。如某些自動(dòng)化集成測(cè)試工具能實(shí)現(xiàn)每日深夜對(duì)開(kāi)發(fā)團(tuán)隊(duì)的現(xiàn)有代碼進(jìn)行一次集成測(cè)試，然后將測(cè)試結(jié)果發(fā)到各開(kāi)發(fā)人員的電子郵箱中。該集成測(cè)試方法頻繁地將新代碼加入到一個(gè)已經(jīng)穩(wěn)定的基線中，以免集成故障難以發(fā)現(xiàn)，同時(shí)控制可能出現(xiàn)的基線偏差。使用高頻集成測(cè)試需要具備一定的條件: 可以持續(xù)獲得一個(gè)穩(wěn)定的增量，并且該增量?jī)?nèi)部已被驗(yàn)證沒(méi)有問(wèn)題; 大部分有意義的功能增加可以在一個(gè)相對(duì)穩(wěn)定的時(shí)間間隔（如每個(gè)工作日）內(nèi)獲得; 測(cè)試包和代碼的開(kāi)發(fā)工作必須是并行進(jìn)行的，并且需要版本控制工具來(lái)保證始終維護(hù)的是測(cè)試腳本和代碼的最新版本; 必須借助于使用自動(dòng)化工具來(lái)完成。高頻集成一個(gè)顯著的特點(diǎn)就是集成次數(shù)頻繁，顯然，人工的方法是不勝任的。
　　高頻集成測(cè)試一般采用如下步驟來(lái)完成:
　　步驟一: 選擇集成測(cè)試自動(dòng)化工具。如很多Java項(xiàng)目采用Junit+Ant方案來(lái)實(shí)現(xiàn)集成測(cè)試的自動(dòng)化，也有一些商業(yè)集成測(cè)試工具可供選擇。
　　步驟二: 設(shè)置版本控制工具，以確保集成測(cè)試自動(dòng)化工具所獲得的版本是最新版本。如使用CVS進(jìn)行版本控制。
　　步驟三: 測(cè)試人員和開(kāi)發(fā)人員負(fù)責(zé)編寫對(duì)應(yīng)程序代碼的測(cè)試腳本。
　　步驟四: 設(shè)置自動(dòng)化集成測(cè)試工具，每隔一段時(shí)間對(duì)配置管理庫(kù)的新添加的代碼進(jìn)行自動(dòng)化的集成測(cè)試，并將測(cè)試報(bào)告匯報(bào)給開(kāi)發(fā)人員和測(cè)試人員。
　　步驟五: 測(cè)試人員監(jiān)督代碼開(kāi)發(fā)人員及時(shí)關(guān)閉不合格項(xiàng)。
　　按照步驟三至步驟五不斷循環(huán)，直至形成最終軟件產(chǎn)品。
　　方案點(diǎn)評(píng): 該測(cè)試方案能在開(kāi)發(fā)過(guò)程中及時(shí)發(fā)現(xiàn)代碼錯(cuò)誤，能直觀地看到開(kāi)發(fā)團(tuán)隊(duì)的有效工程進(jìn)度。在此方案中，開(kāi)發(fā)維護(hù)源代碼與開(kāi)發(fā)維護(hù)軟件測(cè)試包被賦予了同等的重要性，這對(duì)有效防止錯(cuò)誤、及時(shí)糾正錯(cuò)誤都很有幫助。該方案的缺點(diǎn)在于測(cè)試包有時(shí)候可能不能暴露深層次的編碼錯(cuò)誤和圖形界面錯(cuò)誤。
　　以上我們介紹了幾種常見(jiàn)的集成測(cè)試方案，一般來(lái)講，在現(xiàn)代復(fù)雜軟件項(xiàng)目集成測(cè)試過(guò)程中，通常采用核心系統(tǒng)先行集成測(cè)試和高頻集成測(cè)試相結(jié)合的方式進(jìn)行，自底向上的集成測(cè)試方案在采用傳統(tǒng)瀑布式開(kāi)發(fā)模式的軟件項(xiàng)目集成過(guò)程中較為常見(jiàn)。讀者應(yīng)該結(jié)合項(xiàng)目的實(shí)際工程環(huán)境及各測(cè)試方案適用的范圍進(jìn)行合理的選型。
　　附：集成測(cè)試計(jì)劃書 模版
　　原創(chuàng)作者：jerry
　　轉(zhuǎn)載請(qǐng)注明：來(lái)自Sawin系統(tǒng)分析之窗
　　最后修改時(shí)間：2005-4-27
　　1引言
　　1.1編寫目的
　　本文是描述****集成測(cè)試的大綱文章，主要描述如何進(jìn)行集成測(cè)試活動(dòng)？如何控制集成測(cè)試活動(dòng)？集成測(cè)試活動(dòng)的流程以及集成測(cè)試活動(dòng)的工作安排。本文主要的讀者對(duì)象是項(xiàng)目負(fù)責(zé)人，集成部門經(jīng)理，集成測(cè)試設(shè)計(jì)師。
　　1.2背景
　　項(xiàng)目名稱：***集成測(cè)試
　　項(xiàng)目相關(guān)對(duì)象：******************
　　1.3定義
　　**********：********************
　　1.4參考資料
　　《*********》
　　2測(cè)試項(xiàng)目
　　本測(cè)試主要為***系統(tǒng)的集成測(cè)試，目前***的版本為2.0,測(cè)試是***的最終集成測(cè)試，是建立在開(kāi)發(fā)組程序員開(kāi)發(fā)完畢自己的測(cè)試以及開(kāi)發(fā)組測(cè)試的基礎(chǔ)之上
　　3 被測(cè)特性
　　3.1操作性測(cè)試
　　主要測(cè)試操作是否正確，有無(wú)誤差？分為兩部分：
　　3.1.1返回測(cè)試
　　由主界面逐級(jí)進(jìn)入最終界面，按EXIT鍵逐級(jí)返回，檢查返回時(shí)候屏幕聚焦是否正確
　　比如：
　　1. 進(jìn)入“系統(tǒng)設(shè)置”
　　2. 進(jìn)入“頻道搜索”
　　3. 進(jìn)入“自動(dòng)頻道搜索”
　　4. 按EXIT鍵返回，檢查當(dāng)前聚焦是否為“頻道搜索”
　　5. 按EXIT鍵返回，檢查當(dāng)前聚焦是否為“系統(tǒng)設(shè)置”
　　3.1.2進(jìn)入測(cè)試
　　由主界面逐級(jí)進(jìn)入最終界面，按MENU鍵返回主界面，再次進(jìn)入，檢查是否聚焦正確
　　比如：
　　1. 進(jìn)入“系統(tǒng)設(shè)置”
　　2. 進(jìn)入“頻道搜索”
　　3. 進(jìn)入“自動(dòng)頻道搜索”
　　4. 按MENU鍵返回主界面
　　5. 當(dāng)前聚焦是否為“系統(tǒng)設(shè)置”
　　6. 進(jìn)入“系統(tǒng)設(shè)置”，當(dāng)前聚焦是否為“頻道搜索”
　　3.2功能測(cè)試
　　測(cè)試機(jī)頂盒中每個(gè)應(yīng)用的功能是否正確
　　3.3性能測(cè)試
　　3.3.1疲勞性測(cè)試
　　測(cè)試連續(xù)開(kāi)機(jī)1個(gè)月不關(guān)機(jī)器，每3天去運(yùn)行一次應(yīng)用�？聪到y(tǒng)的穩(wěn)定性
　　3.3.2大容量數(shù)據(jù)測(cè)試
　　前段***數(shù)據(jù)庫(kù)表中含有大量數(shù)據(jù)，測(cè)試***功能
　　4 不被測(cè)特性
　　5 測(cè)試方法
　　1. 書寫測(cè)試計(jì)劃
　　2. 審核測(cè)試計(jì)劃，未通過(guò)返回第一步
　　3. 書寫測(cè)試用例；
　　4. 審核測(cè)試用例，未通過(guò)返回第三步
　　5. 測(cè)試人員按照測(cè)試用例逐項(xiàng)進(jìn)行測(cè)試活動(dòng),并且將測(cè)試結(jié)果填寫在測(cè)試報(bào)告上；（測(cè)試報(bào)告必須覆蓋所有測(cè)試用例）
　　6. 測(cè)試過(guò)程中發(fā)現(xiàn)bug，將bug填寫在bugzilla上發(fā)給集成部經(jīng)理；（bug狀態(tài)NEW）
　　7. 集成部經(jīng)理接到bugzilla發(fā)過(guò)來(lái)的bug
　　7.1 對(duì)于明顯的并且可以立刻解決的bug，將bug發(fā)給開(kāi)發(fā)人員；（bug狀態(tài)ASSIGNED）;
　　7.2 對(duì)于不是bug的提交，集成部經(jīng)理通知測(cè)試設(shè)計(jì)人員和測(cè)試人員，對(duì)相應(yīng)文檔進(jìn)行修改; （bug狀態(tài)RESOLVED，決定設(shè)置為INVALID）;
　　7.3 對(duì)于目前無(wú)法修改的,將這個(gè)bug放到下一輪次進(jìn)行修改；（bug狀態(tài)RESOLVED，決定設(shè)置為REMIND）
　　8. 開(kāi)發(fā)人員接到發(fā)過(guò)來(lái)的bug立刻修改;（bug狀態(tài)RESOLVED，決定設(shè)置為FIXED）
　　9. 測(cè)試人員接到bugzilla發(fā)過(guò)來(lái)的錯(cuò)誤更改信息，應(yīng)該逐項(xiàng)復(fù)測(cè)，填寫新的測(cè)試報(bào)告（測(cè)試報(bào)告必須覆蓋上一次中所有REOPENED的測(cè)試用例）；
　　10. 如果復(fù)測(cè)有問(wèn)題返回第六步（bug狀態(tài)REOPENED）
　　11. 否則關(guān)閉這項(xiàng)BUG（bug狀態(tài)CLOSED）
　　12. 本輪測(cè)試中測(cè)試用例中有95%一次性通過(guò)測(cè)試,結(jié)束測(cè)試任務(wù)；
　　13. 本輪測(cè)試中發(fā)現(xiàn)的錯(cuò)誤有98%經(jīng)過(guò)修改并且通過(guò)再次測(cè)試（即bug狀態(tài)CLOSED），返回第五步進(jìn)行新的一輪測(cè)試；
　　14. 測(cè)試任務(wù)結(jié)束后書寫測(cè)試總結(jié)報(bào)告；
　　15. 正規(guī)測(cè)試結(jié)束進(jìn)入非正規(guī)測(cè)試，首先是ALPHA測(cè)試，請(qǐng)公司里其他非技術(shù)人員以用戶角色使用系統(tǒng)。發(fā)現(xiàn)bug通知測(cè)試人員，測(cè)試人員以正規(guī)流程處理bug事件；
　　16. 然后是BETA測(cè)試，請(qǐng)用戶代表進(jìn)行測(cè)試。發(fā)現(xiàn)bug通知測(cè)試人員，測(cè)試人員以正規(guī)流程處理bug事件。
　　幾點(diǎn)說(shuō)明：
　　O 測(cè)試回歸計(jì)劃為三次；
　　O 測(cè)試用例應(yīng)該寫得比較詳盡，步驟一定要標(biāo)明清楚（應(yīng)該包括：編號(hào)，測(cè)試描述，前置條件，測(cè)試步驟以及測(cè)試希望結(jié)果）；
　　O 對(duì)于測(cè)試人員覺(jué)得應(yīng)該進(jìn)行的測(cè)試項(xiàng)目，測(cè)試人員應(yīng)該報(bào)告測(cè)試設(shè)計(jì)人員，完善和健全測(cè)試用例；
　　O 測(cè)試報(bào)告與測(cè)試用例分開(kāi)，測(cè)試報(bào)告標(biāo)明測(cè)試用例序號(hào)以及是否通過(guò)Y/N；
　　O 對(duì)于集成部經(jīng)理無(wú)法決定的上交項(xiàng)目負(fù)責(zé)人決定；
　　O 性能測(cè)試中的疲勞性測(cè)試可以結(jié)合在功能測(cè)試部分，即測(cè)試期間不關(guān)閉機(jī)器；
　　O 性能測(cè)試中的大容量數(shù)據(jù)測(cè)試放在測(cè)試后部分輪次（第二步，只需要進(jìn)行一次）
　　6 測(cè)試通過(guò)標(biāo)準(zhǔn)
　　測(cè)試結(jié)果與測(cè)試用例中期望的結(jié)果一致，測(cè)試通過(guò)，否則標(biāo)明測(cè)試未通過(guò)。
　　6.1測(cè)試結(jié)果審批過(guò)程
　　6.1.1測(cè)試回歸申請(qǐng)結(jié)束
　　測(cè)試人員提出申請(qǐng)這輪測(cè)試結(jié)束，提交集成部經(jīng)理；
　　集成部經(jīng)理召集本組人員開(kāi)會(huì)討論；
　　討論通過(guò)，進(jìn)行下一輪測(cè)試，并且部署下一輪測(cè)試的注意事項(xiàng)，流程等內(nèi)容；
　　如果發(fā)現(xiàn)這輪測(cè)試目前還存在問(wèn)題沒(méi)有解決，延期下一輪測(cè)試時(shí)間，討論下一步工作應(yīng)該如何進(jìn)行。
　　6.1.2測(cè)試結(jié)果申請(qǐng)結(jié)束
　　測(cè)試人員提出申請(qǐng)測(cè)試結(jié)束，提交集成部經(jīng)理；
　　集成部經(jīng)理召集本組人員開(kāi)會(huì)討論；
　　1. 討論通過(guò)，結(jié)束測(cè)試任務(wù)；
　　2. 如果發(fā)現(xiàn)目前測(cè)試還存在問(wèn)題沒(méi)有解決，延期測(cè)試結(jié)束時(shí)間，并且討論下一步工作應(yīng)該如何進(jìn)行。
　　7 測(cè)試掛起和恢復(fù)條件
　　7.1掛起條件
　　O 進(jìn)入第一輪測(cè)試，測(cè)試人員大體了解一下產(chǎn)品情況，如果在一小時(shí)之內(nèi)發(fā)現(xiàn)５個(gè)以上（含５個(gè)）操作性錯(cuò)誤，或者３個(gè)以上（含３個(gè)）功能性錯(cuò)誤，退回測(cè)試組測(cè)試；
　　O 遇到有項(xiàng)目?jī)?yōu)先級(jí)更高的集成測(cè)試任務(wù)；
　　O 遇到有項(xiàng)目?jī)?yōu)先級(jí)更高的集成任務(wù)；
　　O 在測(cè)試復(fù)測(cè)過(guò)程中發(fā)現(xiàn)產(chǎn)品無(wú)法運(yùn)行下去；
　　O 人員，設(shè)備不足。
　　7.2恢復(fù)條件
　　O 符合進(jìn)入集成測(cè)試條件（一小時(shí)之內(nèi)發(fā)現(xiàn)５個(gè)以下（不含５個(gè)）操作性錯(cuò)誤，或者３個(gè)以下（不含３個(gè)）功能性錯(cuò)誤）；
　　O 項(xiàng)目?jī)?yōu)先級(jí)更高的集成測(cè)試任務(wù)暫告完成；
　　O 項(xiàng)目?jī)?yōu)先級(jí)更高的集成任務(wù)暫告完成；
　　O 復(fù)測(cè)過(guò)程中產(chǎn)品可以運(yùn)行下去；
　　O 人員，設(shè)備到位。
　　8應(yīng)提供的測(cè)試文件
　　O 測(cè)試計(jì)劃書
　　O 測(cè)試用例
　　O 測(cè)試報(bào)告
　　O 測(cè)試總結(jié)
　　9測(cè)試任務(wù)
　　O 制定審核測(cè)試計(jì)劃
　　O 制定和審核測(cè)試用例
　　O 進(jìn)行測(cè)試活動(dòng)
　　O 書寫測(cè)試報(bào)告
　　10測(cè)試環(huán)境需求
　　10.1硬件需求
　　***********
　　10.2軟件需求
　　************
　　10.3測(cè)試工具
　　*************
　　10.4測(cè)試需要的條件
　　**************
　　10.4.1 需要的文檔
　　O 用戶手冊(cè)
　　O 應(yīng)用手冊(cè)
　　O 安裝說(shuō)明
　　10.4.2需要完成的任務(wù)
　　O 程序員本人測(cè)試
　　O 測(cè)試組完成測(cè)試
　　11角色和職責(zé)
　　O 集成（測(cè)試）經(jīng)理：控制并完成測(cè)試任務(wù)和測(cè)試過(guò)程，決定測(cè)試人員提交上來(lái)的bug是否需要修改；
　　O 測(cè)試設(shè)計(jì)人員：書寫集成測(cè)試用例；
　　O 測(cè)試人員：按照測(cè)試用例進(jìn)行測(cè)試活動(dòng)；
　　O 開(kāi)發(fā)人員：MHP程序bug修改；
　　O 用戶代表：進(jìn)行BETA測(cè)試。
　　12 人員和培訓(xùn)
　　O 集成測(cè)試經(jīng)理有責(zé)任對(duì)測(cè)試相關(guān)人員進(jìn)行測(cè)試流程，規(guī)章制度培訓(xùn)；
　　O 測(cè)試設(shè)計(jì)人員有責(zé)任對(duì)測(cè)試人員進(jìn)行測(cè)試操作培訓(xùn)
　　13 測(cè)試進(jìn)度
　　測(cè)試工作 進(jìn)度(人＊工作日)
　　測(cè)試計(jì)劃 ８
　　測(cè)試設(shè)計(jì) 60
　　測(cè)試執(zhí)行總共進(jìn)度 30
　　每次回歸進(jìn)度 10
　　測(cè)試報(bào)告 ２
　　14風(fēng)險(xiǎn)及應(yīng)急計(jì)劃
　　設(shè)備不到位:加緊設(shè)備購(gòu)買;
　　人員不到位
　　人員請(qǐng)假：請(qǐng)假人員回來(lái)加班或趕緊測(cè)試進(jìn)度／申請(qǐng)調(diào)配新的人員；
　　人員離職：調(diào)配新的人員；
　　人員調(diào)配到其他部門或項(xiàng)目：調(diào)配新的人員；
　　開(kāi)發(fā)人員開(kāi)發(fā)頻頻出錯(cuò)：通知開(kāi)發(fā)部門，商量策略；
　　其他原因的測(cè)試工作頻頻被掛起或者掛起后遲遲恢復(fù)不了：加班或延期
　　15審批
　　集成部經(jīng)理 技術(shù)部經(jīng)理
　　姓名： 姓名：
　　日期： 日期：

• 通信詞典解釋