軟件測試過程-單元、集成、系統(tǒng)、驗(yàn)收測試-pub

軟件測試過程：單元、集成、系統(tǒng)、驗(yàn)收測試和一個(gè)項(xiàng)目案例xxxxxxxxxxxxxx過程（Process）是一種手段，通過該手段可以把人、規(guī)程、方法、設(shè)備以及工具進(jìn)行集成，以產(chǎn)生一種所期望的結(jié)果

--網(wǎng)絡(luò)

議程測試過程回顧單元測試集成測試系統(tǒng)測試驗(yàn)收測試一個(gè)軟件測試項(xiàng)目過程分析回顧：軟件測試過程模型非常明確地表明了測試的不同級(jí)別，清晰地展示了軟件測試與開發(fā)之間的關(guān)系ValidationVerification詳細(xì)設(shè)計(jì)構(gòu)架設(shè)計(jì)系統(tǒng)測試計(jì)劃集成測試計(jì)劃單元測試計(jì)劃單元測試集成測試系統(tǒng)測試編碼產(chǎn)品交付產(chǎn)品維護(hù)和回歸測試業(yè)務(wù)需求驗(yàn)收測試計(jì)劃系統(tǒng)需求用戶驗(yàn)收測試AcceptanceTesting保證良好的客戶感知保證業(yè)務(wù)完整性保證業(yè)務(wù)的設(shè)計(jì)架構(gòu)可靠性保證業(yè)務(wù)功能可用性保證系統(tǒng)在運(yùn)維時(shí)的穩(wěn)定性議程測試過程回顧單元測試集成測試系統(tǒng)測試驗(yàn)收測試一個(gè)軟件測試項(xiàng)目過程分析軟件單元是什么？(IEEE)軟件單元指軟件設(shè)計(jì)說明中一個(gè)可獨(dú)立測試的元素，是程序中一個(gè)邏輯上獨(dú)立的部分，它不能再分解為其他軟件成分。

(實(shí)踐中)軟件單元指軟件源代碼中單個(gè)的函數(shù)，源文件或類。單元測試是什么？單元測試，對(duì)單個(gè)的軟件單元或者一組相關(guān)的軟件單元所進(jìn)行的測試，是代碼級(jí)的測試。Unit：函數(shù)，源代碼文件，類把測試比作是清洗一臺(tái)機(jī)器：系統(tǒng)測試就是清除機(jī)器外面的塵土。集成測試就是保證機(jī)器各個(gè)部件的接頭處干凈。單元測試就是清洗各個(gè)零件的內(nèi)部。單元測試應(yīng)用輸入潛在錯(cuò)誤對(duì)象單元測試測試一個(gè)類Thatiseasy!單元測試原則應(yīng)該盡早地進(jìn)行軟件單元測試。應(yīng)該保證單元測試的可重復(fù)性。盡可能地采用測試自動(dòng)化的手段來支持單元測試活動(dòng)。單元測試內(nèi)容單元功能測試單元接口測試單元局部數(shù)據(jù)結(jié)構(gòu)測試單元中重要的執(zhí)行路徑測試單元的各類錯(cuò)誤處理路徑測試單元邊界條件測試單元測試內(nèi)容開發(fā)測試設(shè)計(jì)評(píng)審代碼走查單元測試集成測試面向單元的白盒測試（單元覆蓋率測試）狹義的單元測試內(nèi)容面向單元的黑盒測試（單元功能測試）內(nèi)存和運(yùn)行錯(cuò)誤分析（內(nèi)存泄漏、越界，異常）代碼運(yùn)行性能profile（函數(shù)效率和瓶頸分析）單元測試（who）單元測試可以是開發(fā)者本人執(zhí)行，也可以是獨(dú)立的專業(yè)測試人員執(zhí)行。兩者各有優(yōu)勢。建議開發(fā)人員必須完整地做單元測試，同時(shí)測試人員針對(duì)重點(diǎn)模塊實(shí)施獨(dú)立的單元測試。單元測試過程單元測試過程包括8個(gè)活動(dòng)：確定單元測試計(jì)劃確定待測特性制訂單元測試規(guī)程設(shè)計(jì)測試套件構(gòu)建測試套件執(zhí)行測試套件檢查終止條件評(píng)估測試結(jié)果確定單元測試計(jì)劃

確定單元測試范圍盡可能爭取完全地覆蓋（原則上應(yīng)該做到完全覆蓋）參考：通常以下情況必須安排單元測試：a）新模塊b）新增代碼比例超過20％c）核心模塊確定單元測試計(jì)劃

單元測試充分性要求例如：語句行覆蓋率=100%；分支覆蓋率〉85%測試覆蓋率要求是測試充分性的一個(gè)方面，除此之外，在單元測試中還應(yīng)考慮每個(gè)軟件特性的測試覆蓋，如函數(shù)性能。確定單元測試計(jì)劃

確定終止條件確定單元測試過程的正常終止條件。該終止條件應(yīng)該包括了對(duì)測試充分性要求的滿足。（100%代碼行覆蓋，85%分支覆蓋）識(shí)別可能造成單元測試過程異常終止的條件（如發(fā)現(xiàn)重大的設(shè)計(jì)錯(cuò)誤、到達(dá)進(jìn)度期限等）。確定單元測試計(jì)劃確定單元測試資源估算進(jìn)行測試活動(dòng)所需的資源。應(yīng)考慮測試人員、硬件、通信或系統(tǒng)軟件、測試工具和其它資源。識(shí)別需要進(jìn)行準(zhǔn)備或申請(qǐng)的資源（如定制的測試工具），并做出相應(yīng)的安排。指明總體進(jìn)度計(jì)劃基于資源和項(xiàng)目計(jì)劃等方面的要求，確定單元測試活動(dòng)的總體進(jìn)度計(jì)劃。確定待測特性

研究待測特性要從研究單元的需求開始功能需求、非功能需求（如性能或設(shè)計(jì)約束等）、與待測單元相關(guān)的任何使用或操作過程單元的狀態(tài)識(shí)別針對(duì)狀態(tài)機(jī)測試單元的數(shù)據(jù)特性識(shí)別單元的輸入輸出數(shù)據(jù)分析以上研究分析對(duì)于制定單元測試方案和指導(dǎo)測試用例的設(shè)計(jì)很重要待測特性分析過程中還有可能發(fā)現(xiàn)單元需求上的缺陷。制定單元測試規(guī)程

輸入單元測試計(jì)劃、待測特性分析結(jié)果、項(xiàng)目總體進(jìn)度計(jì)劃識(shí)別可重用技術(shù)（待查）通過待測特性分析，可從用例庫中識(shí)別出可以重用的測試用例和測試規(guī)程，以減少重復(fù)工作。資源詳細(xì)列舉單元測試所需資源，包括人員、設(shè)備、工具、環(huán)境等，進(jìn)度計(jì)劃詳細(xì)的進(jìn)度計(jì)劃，包括風(fēng)險(xiǎn)分析和應(yīng)對(duì)措施規(guī)程評(píng)審設(shè)計(jì)測試套件

測試套件測試用例、腳本、驅(qū)動(dòng)、樁、測試數(shù)據(jù)測試規(guī)程和測試用例的開發(fā)目前測試規(guī)程和測試用例是合一的。開發(fā)過程中在重用的基礎(chǔ)上新增和修改。結(jié)合待測單元特性分析，充分考慮測試用例的覆蓋率。測試工具的設(shè)計(jì)自研測試工具的設(shè)計(jì)要充分考慮可重用性，不同項(xiàng)目間通用性一般較小，統(tǒng)一項(xiàng)目不同版本間一定要具備通用性。測試規(guī)程/用例的評(píng)審單元測試數(shù)據(jù)單元測試設(shè)計(jì)中，測試數(shù)據(jù)的設(shè)計(jì)是很關(guān)鍵的，同樣的測試規(guī)程，不同的測試數(shù)據(jù)，可能會(huì)達(dá)到不同的測試結(jié)果。a)正常數(shù)據(jù)：在測試中所用的正常數(shù)據(jù)的量是最大的，而且也是最關(guān)鍵的。少量的測試數(shù)據(jù)不能完全覆蓋需求，但我們要從中提取出一些具有高度代表性的數(shù)據(jù)作為測試數(shù)據(jù)，以減少測試時(shí)間。b)邊緣數(shù)據(jù)：邊緣測試是界于正常數(shù)據(jù)和錯(cuò)誤數(shù)據(jù)之間的一種數(shù)據(jù)。它可以針對(duì)某一種編程語言、編程環(huán)境或特定的數(shù)據(jù)庫而專門設(shè)定。邊緣數(shù)據(jù)要靠測試人員的豐富經(jīng)驗(yàn)來制定。c)錯(cuò)誤數(shù)據(jù)：顯而易見，錯(cuò)誤數(shù)據(jù)就是編寫與程序輸入規(guī)范不符的數(shù)據(jù)從而檢測輸入篩選、錯(cuò)誤處理等程序的分支。構(gòu)建測試套件測試數(shù)據(jù)的準(zhǔn)備測試工具的開發(fā)/調(diào)試構(gòu)建測試環(huán)境執(zhí)行測試套件運(yùn)行測試確定測試結(jié)果，處理測試過程中的異常對(duì)每個(gè)測試用例，確定單元是否通過測試。對(duì)異常進(jìn)行分析，并根據(jù)情況處理：情況1：測試用例或測試數(shù)據(jù)的問題。修正并重新運(yùn)行。情況2：測試規(guī)程執(zhí)行的問題。重新運(yùn)行。情況3：測試環(huán)境的問題。糾正測試環(huán)境并重新運(yùn)行；或者異常終止測試，并匯報(bào)記錄異常終止原因。情況4：單元實(shí)現(xiàn)中的故障。糾正單元的故障，并運(yùn)行所有的測試；或者異常終止測試，并匯報(bào)記錄異常終止原因。情況5：單元設(shè)計(jì)中的故障。糾正單元設(shè)計(jì)和實(shí)現(xiàn)中的故障，必要時(shí)修改測試設(shè)計(jì)和測試數(shù)據(jù)，并重新運(yùn)行所有的測試。檢查終止條件測試充分性檢查檢查是否達(dá)到覆蓋率要求，包括測試用例執(zhí)行/通過覆蓋率和被測單元代碼/分支覆蓋率。以及其它測試充分性要求。異常終止條件檢查補(bǔ)充測試套件以上條件不滿足時(shí)，則需要補(bǔ)充測試套件，繼續(xù)進(jìn)行測試。評(píng)估測試結(jié)果按照單元測試報(bào)告模塊出具單元測試報(bào)告如有必要對(duì)單元測試報(bào)告進(jìn)行評(píng)審將所有測試相關(guān)工作產(chǎn)品納入配置管理常見的單元測試的難點(diǎn)沒有時(shí)間做單元測試單元測試責(zé)任人不清楚測試代碼難以管理覆蓋率難以手工統(tǒng)計(jì)故障報(bào)告形式驅(qū)動(dòng)和樁編寫困難（可測試性）對(duì)策：沒有時(shí)間做單元測試單元測試計(jì)劃在項(xiàng)目計(jì)劃應(yīng)該有體現(xiàn)。編寫代碼之前或同時(shí)，先設(shè)計(jì)測試用例。每個(gè)軟件單元應(yīng)該有什么功能？是否每個(gè)功能都有測試用例來驗(yàn)證它？對(duì)策：單元測試責(zé)任人不清楚強(qiáng)調(diào)單元測試必須由類包的設(shè)計(jì)者負(fù)責(zé)編寫，因?yàn)橹挥羞@樣，測試才能保證對(duì)象的運(yùn)行時(shí)態(tài)行為符合需求。讓測試人員或第三方人員編寫測試用例，將花費(fèi)更多的工作量。（20>>1）執(zhí)行測試用例可以讓測試人員或自動(dòng)構(gòu)造系統(tǒng)。對(duì)策：測試代碼難以管理采用測試工具管理測試代碼如XUnit、C++Test、RTRT配置管理中建立配置項(xiàng)如，不同模塊的一組代碼，建立相應(yīng)測試代碼目錄和配置項(xiàng)對(duì)策：覆蓋率難以手工統(tǒng)計(jì)利用各種工具PureCoverage(C/C++/Java/.Net,Windows/UNIX)RTRT(C/C++/Java/Ada,嵌入式系統(tǒng))C++Test(C/C++,Windows/UNIX)Discover(Delphi,Windows)對(duì)策：故障報(bào)告形式各種工具一般都會(huì)生成測試報(bào)告XUnit測試用例執(zhí)行報(bào)告RTRT、C++Test各種綜合報(bào)告（測試用例執(zhí)行結(jié)果、測試用例覆蓋率、內(nèi)存檢查和性能）對(duì)策：驅(qū)動(dòng)和樁編寫困難通常情形下，測試驅(qū)動(dòng)難以編寫，測試難以進(jìn)行由以下幾方面原因?qū)е拢?、被測試對(duì)象需要傳入的參數(shù)過多。2、內(nèi)部的邏輯判斷過多（內(nèi)部牽扯復(fù)雜）。3、和界面顯示部分交互過于頻繁（耦合性太強(qiáng)）。4、被測對(duì)象過多的調(diào)用了其他類或方法。5、需要構(gòu)造的作為參數(shù)的對(duì)象本身過于復(fù)雜解決：提高可測試性1、首先最重要的是堅(jiān)持測試驅(qū)動(dòng)設(shè)計(jì)（測試先于設(shè)計(jì)）的方法。優(yōu)先編寫測試代碼。這是標(biāo)準(zhǔn)的XP方法。這不是說您應(yīng)該一次性編寫全部測試代碼后，再一次性全部實(shí)現(xiàn)。對(duì)一些單元接口，編寫一些測試代碼，實(shí)現(xiàn)它們，再編寫一些測試代碼，再實(shí)現(xiàn)它們等等是個(gè)更好的辦法。設(shè)計(jì)以這種方式得以進(jìn)展；在實(shí)現(xiàn)階段捕捉錯(cuò)誤并在下一組測試中改正它。2、功能分解類：把功能分解到細(xì)粒度，提倡小類。方法：盡量做到每個(gè)操作對(duì)應(yīng)一個(gè)方法，使方法小型化。功能分解促進(jìn)：提高重用性，降低耦合度3、分層原則。對(duì)于顯示部分（GUI），盡量做到顯示與控制分離。把代碼移到GUI視圖的外面。然后各種GUI動(dòng)作就能成了模型上的簡單方法調(diào)用。這樣，對(duì)GUI測試者來說，通過方法調(diào)用測試功能比間接地測試功能容易的多。另一個(gè)好處是它使修改程序功能而不影響視圖變的更容易。解決：提高可測試性4、抽象我們可以想出各種各樣的辦法來降低耦合程度，但是歸納起來，不外乎增加抽象的層次來隔離不同的類，這個(gè)抽象層次可以是具體的類，也可以是接口。GOF的23種設(shè)計(jì)模式，沒有一種模式的思路不是從增加抽象層次入手來解決問題的5、對(duì)于可能要作為參數(shù)的復(fù)雜類，可以做一個(gè)接口，用接口說明外部程序組件使得我們可以容易地在測試案例中模擬這些組件。當(dāng)需要時(shí)可以實(shí)現(xiàn)按接口生成一個(gè)模擬類作為參數(shù)傳入。特別是當(dāng)該類還沒有完全實(shí)現(xiàn)時(shí)，這種方法最為行之有效。解決：提高可測試性6、如果自己不負(fù)責(zé)測試工作，作為開發(fā)員在設(shè)計(jì)過程中要時(shí)刻提醒自己“我如何才能測試這些代碼？我如何才能以可測試方式編寫這些代碼”。7、重構(gòu)是提高可測試性的主要手段單元測試經(jīng)驗(yàn)測試驅(qū)動(dòng)開發(fā)，開發(fā)以測試為導(dǎo)向?qū)懖怀鰷y試用例，就談不上編寫單元代碼開發(fā)一個(gè)單元的代碼的步驟：1.設(shè)計(jì)和編寫測試它的用例代碼2.運(yùn)行自動(dòng)測試，檢查是否發(fā)生錯(cuò)誤3.編寫單元的代碼4.使用前面的用例回歸測試它單元測試是編碼的一部分！單元測試經(jīng)驗(yàn)測試驅(qū)動(dòng)開發(fā)編寫單元測試用例促進(jìn)解除模塊之間的耦合。先編寫測試用例，強(qiáng)迫自己從利于調(diào)用者的角度來設(shè)計(jì)單元，關(guān)注單元的接口。為了便于調(diào)用和獨(dú)立測試，必須降低單元和周邊環(huán)境的耦合程度，單元的可測試性得到加強(qiáng)，模塊化程度得到提高。這樣單元的可重用性也容易被考慮和提高。單元測試經(jīng)驗(yàn)重構(gòu)測試用例數(shù)量是逐步增加的，軟件功能也在此過程中得到增強(qiáng)、更新和優(yōu)化。當(dāng)新的需求變化到來時(shí)，測試用例被增加或修改，難以適應(yīng)測試用例的軟件單元被重構(gòu)。經(jīng)常發(fā)生變化的測試用例和軟件模塊被重視和分離出來，進(jìn)行重構(gòu)和優(yōu)化，使它們更加容易應(yīng)付需求的變化。單元測試經(jīng)驗(yàn)單元測試的執(zhí)行要自動(dòng)化。單元測試的工作產(chǎn)品納入配置管理。議程測試過程回顧單元測試集成測試系統(tǒng)測試驗(yàn)收測試一個(gè)軟件測試項(xiàng)目過程分析集成測試定義

定義集成測試又稱“組裝測試”、“聯(lián)合測試”。集成測試遵循特定的策略和步驟將已經(jīng)通過單元測試的各個(gè)軟件單元（或模塊）逐步組合在一起進(jìn)行測試，以期望通過測試發(fā)現(xiàn)各軟件單元接口之間存在的問題。集成測試對(duì)象理論上凡是兩個(gè)單元（如函數(shù)單元）的組合測試都可以叫做集成測試。實(shí)際操作中，通常集成測試的對(duì)象為模塊級(jí)的集成和子系統(tǒng)間的集成，其中子系統(tǒng)集成測試稱為組件測試。集成測試在單元測試和系統(tǒng)測試間起到承上啟下的作用既能發(fā)現(xiàn)大量單元測試階段不易發(fā)現(xiàn)的接口類錯(cuò)誤，又可以保證在進(jìn)入系統(tǒng)測試前及早發(fā)現(xiàn)錯(cuò)誤，減少損失。對(duì)系統(tǒng)而言，接口錯(cuò)誤是最常見的錯(cuò)誤單元測試通常是單人執(zhí)行，而集成測試通常是多人執(zhí)行或第三方執(zhí)行。集成測試通過模塊間的交互作用和不同人的理解和交流，更容易發(fā)現(xiàn)實(shí)現(xiàn)上、理解上的不一致和差錯(cuò)。集成測試（when)在開始體系結(jié)構(gòu)設(shè)計(jì)的時(shí)候開始制定測試方案；在進(jìn)入詳細(xì)設(shè)計(jì)之前完成集成測試方案；在進(jìn)入系統(tǒng)測試之前結(jié)束集成測試。集成測試（who)集成測試可以在開發(fā)部進(jìn)行，也可以由獨(dú)立的測試部執(zhí)行。開發(fā)部盡量進(jìn)行集成測試，測試部有選擇地進(jìn)行集成測試。集成測試原則集成測試是產(chǎn)品研發(fā)中的重要工作，需要為其分配足夠的資源和時(shí)間。集成測試需要經(jīng)過嚴(yán)密的計(jì)劃，并嚴(yán)格按計(jì)劃執(zhí)行。應(yīng)采取增量式的分步集成方式，逐步進(jìn)行軟件部件的集成和測試。應(yīng)重視測試自動(dòng)化技術(shù)的引入與應(yīng)用，不斷提高集成測試效率。應(yīng)該注意測試用例的積累和管理，方便進(jìn)行回歸并進(jìn)行測試用例補(bǔ)充。集成測試內(nèi)容集成測試需要關(guān)注以下問題：穿越接口的數(shù)據(jù)是否會(huì)丟失一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利影響實(shí)現(xiàn)子功能的模塊組合起來是否能夠達(dá)到預(yù)期的總體功能全局?jǐn)?shù)據(jù)結(jié)構(gòu)的測試共享資源訪問的測試單個(gè)模塊的誤差經(jīng)過集成的累加效應(yīng)集成測試內(nèi)容集成功能測試接口測試全局?jǐn)?shù)據(jù)結(jié)構(gòu)測試資源測試任務(wù)優(yōu)先級(jí)沖突測試性能和穩(wěn)定性測試集成功能測試集成單元實(shí)現(xiàn)的功能，集成后的功能（合一），考察多個(gè)模塊間的協(xié)作，既要滿足集成后實(shí)現(xiàn)的復(fù)雜功能，也不能衍生出不需要的多余功能（錯(cuò)誤功能）。主要關(guān)注：被測對(duì)象的各項(xiàng)功能是否實(shí)現(xiàn)；異常情況是否有相關(guān)的錯(cuò)誤處理；模塊間的協(xié)作是否高效合理。接口測試模塊間的接口包括函數(shù)接口和消息接口:對(duì)函數(shù)接口的測試，應(yīng)關(guān)注函數(shù)接口參數(shù)的類型和個(gè)數(shù)的一致性、輸入/輸出屬性的一致性、范圍的一致性。對(duì)消息接口的測試，應(yīng)關(guān)注收發(fā)雙方對(duì)消息參數(shù)的定義是否一致、消息和消息隊(duì)列長度是否滿足設(shè)計(jì)要求、消息的完整性如何、消息的內(nèi)存是否在發(fā)送過程中被非法釋放、有無對(duì)消息隊(duì)列阻塞進(jìn)行處理等。全局?jǐn)?shù)據(jù)結(jié)構(gòu)測試全局?jǐn)?shù)據(jù)結(jié)構(gòu)往往存在被非法修改的隱患，因此對(duì)全局?jǐn)?shù)據(jù)結(jié)構(gòu)的測試主要關(guān)注以下幾個(gè)角度：

全局?jǐn)?shù)據(jù)結(jié)構(gòu)的值在兩次被訪問的間隔是可預(yù)知的；全局?jǐn)?shù)據(jù)結(jié)構(gòu)的各個(gè)數(shù)據(jù)段的內(nèi)存不應(yīng)被錯(cuò)誤釋放；多個(gè)全局?jǐn)?shù)據(jù)結(jié)構(gòu)間是否存在緩存越界；多個(gè)軟件單元對(duì)全局?jǐn)?shù)據(jù)結(jié)構(gòu)的訪問應(yīng)采用鎖保護(hù)機(jī)制。資源測試資源測試包括共享資源測試和資源極限測試。共享資源測試常應(yīng)用于數(shù)據(jù)庫測試和支撐的測試。共享資源測試需關(guān)注：是否存在死鎖現(xiàn)象；是否存在過度利用情況；是否存在對(duì)共享資源的破壞性操作；公共資源訪問鎖機(jī)制是否完善。資源極限測試關(guān)注系統(tǒng)資源的極限使用情況以及軟件對(duì)資源耗盡時(shí)的處理，保證軟件系統(tǒng)在資源耗盡的情況下不會(huì)出現(xiàn)系統(tǒng)崩潰。性能測試某個(gè)部件的性能指標(biāo)，及時(shí)發(fā)現(xiàn)性能瓶頸。多任務(wù)環(huán)境中，還需測試任務(wù)優(yōu)先級(jí)的合理性，需考慮以下因素：實(shí)時(shí)性要求高的功能是否在高優(yōu)先級(jí)任務(wù)中完成；任務(wù)優(yōu)先級(jí)設(shè)計(jì)是否滿足用戶操作相應(yīng)時(shí)間要求。穩(wěn)定性測試穩(wěn)定性關(guān)注是否存在內(nèi)存泄漏而導(dǎo)致長期運(yùn)行資源耗竭；長期運(yùn)行后是否出現(xiàn)性能的明顯下降；長期運(yùn)行是否出現(xiàn)任務(wù)掛起集成測試方法非遞增式集成測試所有軟件模塊單元測試后一次集成。優(yōu)點(diǎn)：測試過程中基本不需要設(shè)計(jì)開發(fā)測試工具。不足：對(duì)于復(fù)雜系統(tǒng)，當(dāng)出現(xiàn)問題時(shí)故障定位困難，和系統(tǒng)測試接近，難以體現(xiàn)和發(fā)揮集成測試的優(yōu)勢。遞增式集成測試逐漸集成，由小到大，邊集成邊測試，測完一部分，再連接一部分。在復(fù)雜系統(tǒng)中，劃分的軟件單元較多，通常是不會(huì)一次集成的。軟件集成的精細(xì)度取決于集成策略。通常的做法是先模塊間的集成，再部件間的集成。優(yōu)點(diǎn)：測試層次清晰，出現(xiàn)問題能夠快速定位。缺點(diǎn)：需要開發(fā)測試驅(qū)動(dòng)和樁。集成測試過程集成測試計(jì)劃（策略、方案、進(jìn)度計(jì)劃）集成測試設(shè)計(jì)和開發(fā)（測試規(guī)程、測試工具開發(fā)）集成測試執(zhí)行（構(gòu)造環(huán)境、運(yùn)行）集成測試評(píng)估集成測試計(jì)劃集成測試策略制定集成方法、內(nèi)容、范圍、通過準(zhǔn)則；工具考慮，復(fù)用分析；基于項(xiàng)目人力、設(shè)備、技術(shù)、市場要求等各方面決策。集成測試進(jìn)度計(jì)劃工作量估算、資源需求、進(jìn)度安排、風(fēng)險(xiǎn)分析和應(yīng)對(duì)措施。集成測試方案編制接口分析、測試項(xiàng)、測試特性分析。體現(xiàn)測試策略。如何確定集成的內(nèi)容？考慮集成的層次考慮軟件的層次考慮軟件的復(fù)雜度和重要性權(quán)衡投入和產(chǎn)出集成測試設(shè)計(jì)和開發(fā)測試規(guī)程/測試用例的設(shè)計(jì)和開發(fā)確定的測試步驟、測試數(shù)據(jù)設(shè)計(jì)。測試工具、測試驅(qū)動(dòng)和樁的開發(fā)集成測試執(zhí)行搭建測試環(huán)境運(yùn)行測試確定測試結(jié)果，處理測試過程中的異常執(zhí)行階段的度量集成測試對(duì)象的數(shù)量運(yùn)行的用例數(shù)量通過/失敗的用例數(shù)量發(fā)現(xiàn)的缺陷數(shù)量遺留的缺陷數(shù)量集成測試執(zhí)行的工作量評(píng)估測試結(jié)果按照集成測試報(bào)告模塊出具集成測試報(bào)告如有必要對(duì)集成測試報(bào)告進(jìn)行評(píng)審將所有測試相關(guān)工作產(chǎn)品納入配置管理集成測試經(jīng)驗(yàn)集成測試活動(dòng)必須納入項(xiàng)目計(jì)劃，并安排相應(yīng)工作量；集成測試之前必須先做單元測試，而且單元測試對(duì)覆蓋率應(yīng)該有較高的要求；做好集成測試，良好的組織非常重要，需要指定一個(gè)好的集成測試組織者；集成測試需要及早考慮自動(dòng)測試工具的開發(fā)。集成測試經(jīng)驗(yàn)—每日構(gòu)造NT的每日構(gòu)造1994年的NT系統(tǒng)40，000個(gè)源文件5，600，000行代碼多臺(tái)機(jī)器上編譯9個(gè)小時(shí)如果微軟只能宣傳它開發(fā)過程中的一種思想，那就是每日構(gòu)造和冒煙測試。

-JimMcCarthy每日構(gòu)造每日構(gòu)造的意義使平行編碼的眾多程序員定期同步到產(chǎn)品發(fā)布的主線上來是開發(fā)過程健康狀況的脈搏，是進(jìn)度監(jiān)控的基礎(chǔ)是連接開發(fā)、測試和程序經(jīng)理的重要紐帶將彼此依賴的產(chǎn)品組件和部門連接到產(chǎn)品發(fā)布的主線上來提供理論上隨時(shí)可以發(fā)布的版本，為重大產(chǎn)品決策提供寶貴的靈活性每日構(gòu)造每日構(gòu)造對(duì)于特大型項(xiàng)目是極大的挑戰(zhàn)如果今天不可能裝配成功，那么我們可能永遠(yuǎn)也無法裝配成功Windows產(chǎn)品部門由一位副總裁級(jí)的工程師親自指導(dǎo)一個(gè)小組構(gòu)建每日構(gòu)造環(huán)境程序員一次不小心的Check-in就可能導(dǎo)致每日裝配的失敗構(gòu)造失敗作為絕對(duì)最高優(yōu)先級(jí)任務(wù)，必須立即予以修復(fù)對(duì)于百萬行代碼的中型項(xiàng)目，每日構(gòu)造很容易操作每個(gè)程序員在Check-in之前保證編譯成功在Check-in之前保證本機(jī)代碼與代碼庫嚴(yán)格同步在生成代碼集裝配快照（snapshot）時(shí)保證沒有Check-in發(fā)生每日構(gòu)造的關(guān)鍵每天進(jìn)行創(chuàng)建每天進(jìn)行冒煙測試冒煙測試隨著產(chǎn)品的增長而增長每日構(gòu)造發(fā)現(xiàn)的問題作為最高優(yōu)先級(jí)的任務(wù)在壓力下不要放棄這個(gè)過程每日構(gòu)造的過程開發(fā)人員提交代碼編碼規(guī)范檢查自動(dòng)編譯和鏈接冒煙測試Break!系統(tǒng)泛指由一群有關(guān)連的個(gè)體組成，根據(jù)預(yù)先編排好的規(guī)則工作，能完成個(gè)別元件不能單獨(dú)完成的工作的群體。

--源于網(wǎng)絡(luò)議程測試過程回顧單元測試集成測試系統(tǒng)測試驗(yàn)收測試一個(gè)軟件測試項(xiàng)目過程分析系統(tǒng)測試——驗(yàn)證還是確認(rèn)？系統(tǒng)測試使用人工或自動(dòng)手段來運(yùn)行或測定某個(gè)系統(tǒng)的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的系統(tǒng)需求或是弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。驗(yàn)證（Verification）驗(yàn)證確定工作產(chǎn)品正確反映了它們的規(guī)定需求。換言之，驗(yàn)證保證“你正確地構(gòu)建了它”。確認(rèn)（Validation）確認(rèn)確定提供的產(chǎn)品將滿足其預(yù)期使用。換言之，確認(rèn)保證“你構(gòu)建了正確的產(chǎn)品”。

——CMMI模型第3章系統(tǒng)測試主要內(nèi)容功能測試恢復(fù)性測試（災(zāi)難測試、容錯(cuò)測試）敏感性測試安全性測試接口測試用戶界面測試安裝/升級(jí)測試配置測試/兼容性測試國際化（語言）測試用戶文檔測試性能測試強(qiáng)度測試容量測試可靠性測試邊界測試冒煙測試回歸測試隨機(jī)測試硬件系統(tǒng)專有測試可靠性試驗(yàn)可生產(chǎn)性測試可維護(hù)性測試壓力測試常稱為強(qiáng)度測試，通常還包括極限性測試和敏感性測試等，用于測試系統(tǒng)對(duì)異常工作強(qiáng)度（包括過大的工作量、不充足的內(nèi)存、不可用的服務(wù)/硬件或過低的共享資源等）情況下的處理能力。極限測試側(cè)重于測試系統(tǒng)在內(nèi)部和外部達(dá)到最大額定指標(biāo)時(shí)能否正常工作敏感性測試側(cè)重于測試系統(tǒng)在一些臨界點(diǎn)條件下功能結(jié)果和性能表現(xiàn)是否產(chǎn)生突變。壓力測試常用工具SmartBits等數(shù)據(jù)流量模擬發(fā)生器RationalTestManager、LoadRunner的VU(VirtualUsers)模擬測試腳本工具話音模擬呼叫器，等。常見故障在異常資源配置下容易產(chǎn)生系統(tǒng)崩潰或處理能力急劇下降、出錯(cuò)率急劇上升的現(xiàn)象達(dá)不到需求所要求的最高容量指標(biāo)在允許的資源配置范圍內(nèi)存在某些臨界點(diǎn)（特定輸入或配置），在這些臨界點(diǎn)系統(tǒng)的功能性能表現(xiàn)產(chǎn)生突變甚至系統(tǒng)發(fā)生崩潰。配置（兼容性）測試主要包括組網(wǎng)測試和軟硬件平臺(tái)配置測試組網(wǎng)測試的目的是測試系統(tǒng)是否滿足其需求中所支持的所有組網(wǎng)類型和組網(wǎng)規(guī)模軟硬件平臺(tái)配置測試的目的是測試系統(tǒng)是否滿足其需求中所支持的不同軟硬件平臺(tái)配置。兼容性測試是指系統(tǒng)的適應(yīng)能力測試，可分為環(huán)境兼容測試和版本兼容測試。常見故障系統(tǒng)在采用需求中支持的某些組網(wǎng)方式時(shí)的功能或性能出現(xiàn)問題；系統(tǒng)在采用需求中支持的某些平臺(tái)、軟件配置方式時(shí)的功能或性能出現(xiàn)問題。安全測試安全測試就是檢查系統(tǒng)對(duì)于外部的非法侵入的抵御能力。系統(tǒng)安全測試的準(zhǔn)則是，測試非法侵入的代價(jià)是否超過被保護(hù)信息的價(jià)值。信息安全與保密（Security）不同于人身安全和重大財(cái)產(chǎn)損失（Safety）。在公司的產(chǎn)品研發(fā)中，需要重點(diǎn)考慮的是信息安全方面隨著ISO14000/18000的實(shí)施，Safety方面的內(nèi)容會(huì)增多主要方法：想方設(shè)法截取或破譯口令；專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制；故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息，等。主要工具：協(xié)議分析儀、系統(tǒng)漏洞掃描軟件，黑客工具等。常見故障系統(tǒng)緩沖區(qū)溢出、堆棧溢出錯(cuò)誤。系統(tǒng)存在密碼安全、權(quán)限管理、數(shù)據(jù)安全方面的漏洞，可被輕易的進(jìn)入并進(jìn)行非法獲取和破壞。安全測試恢復(fù)性測試檢查系統(tǒng)的容錯(cuò)能力，測試系統(tǒng)在遇到系統(tǒng)崩潰、硬件損壞或其他災(zāi)難性問題后能否很好地恢復(fù)，測試的具體內(nèi)容包括創(chuàng)建各種可能的災(zāi)難狀況，測試系統(tǒng)從異常狀態(tài)恢復(fù)到正常狀態(tài)所需的時(shí)間、花費(fèi)的代價(jià)、對(duì)周邊設(shè)備和系統(tǒng)造成的影響，系統(tǒng)恢復(fù)的完整性和一致性等。常用工具：主要是制造系統(tǒng)異常，按系統(tǒng)恢復(fù)功能進(jìn)行恢復(fù)操作，直至系統(tǒng)繼續(xù)正常運(yùn)行為了測試系統(tǒng)恢復(fù)之后是否運(yùn)行正常，也可以采用一些自化測試工具進(jìn)行回歸測試，以提高測試的效率。常見故障系統(tǒng)發(fā)生異常后無法恢復(fù)，造成系統(tǒng)數(shù)據(jù)被破壞，即重啟系統(tǒng)、恢復(fù)備份數(shù)據(jù)也不可行，嚴(yán)重的可能造成系統(tǒng)硬件故障；系統(tǒng)恢復(fù)時(shí)間過長、代價(jià)過高；系統(tǒng)不能完全恢復(fù)到原來的正常狀態(tài)，造成一定損失；系統(tǒng)恢復(fù)過程對(duì)周邊設(shè)備和環(huán)境造成較大影響，無法消除，等。恢復(fù)性測試用戶界面測試以用戶的角度來對(duì)軟件界面的易用性、風(fēng)格、合理性等面進(jìn)行評(píng)估和測試。通常包括軟件的“界面顯示測試”和“界面功能測試”，而界面功能測試主要結(jié)合系統(tǒng)功能進(jìn)行測試。常用工具：Winrunner、Robot等錄制回放工具測試要點(diǎn)和常見故障：易用性與合理性：步驟繁瑣的操作，比例不協(xié)調(diào)、擺放凌亂的窗口和控件，層次過多的子窗口和菜單規(guī)范性：不符合Windows規(guī)范的控件設(shè)計(jì)，與常規(guī)Windows操作不符的流程與操作等容錯(cuò)性：編輯控件對(duì)非法字符、超出邊界值的輸入處理不當(dāng)或沒有提示，容易造成系統(tǒng)重啟、數(shù)據(jù)刪除丟失等的操作沒有提示等幫助：無幫助信息提供，或者不提供獲取幫助的快捷操作美觀與風(fēng)格：界面顏色不協(xié)調(diào)、界面風(fēng)格與公司相關(guān)產(chǎn)品風(fēng)格不符、與業(yè)界通用風(fēng)格不符，圖片、圖標(biāo)等不符合公司CI規(guī)范。資源：界面長時(shí)間運(yùn)行操作造成系統(tǒng)內(nèi)存耗盡、界面對(duì)系統(tǒng)資源獨(dú)占使用等用戶界面測試安裝升級(jí)測試安裝升級(jí)測試是以最終用戶的角度測試系統(tǒng)的可安裝性以及系統(tǒng)是否具有升級(jí)或卸載功能。安裝升級(jí)測試，需要重點(diǎn)測試系統(tǒng)的軟硬件平臺(tái)的兼容性。主要內(nèi)容：安裝升級(jí)基本功能測試卸載測試(可選)平臺(tái)兼容性易用性與合理性測試健壯性測試常用工具：通常手工進(jìn)行?？山柚浿苹胤殴ぞ哌M(jìn)行反復(fù)的軟件安裝測試。常見故障：系統(tǒng)的軟硬件不能兼容。系統(tǒng)軟件在不同的平臺(tái)下安裝后不能正常工作。系統(tǒng)版本升級(jí)后，無法正常工作，系統(tǒng)無法回退到升級(jí)前的版本。系統(tǒng)的硬件安裝不符合用戶習(xí)慣。系統(tǒng)的軟硬件安裝升級(jí)過程和用戶文檔上的敘述不一致，甚至錯(cuò)誤，誤導(dǎo)最終用戶。安裝升級(jí)測試文檔/幫助測試各種用戶文檔和聯(lián)機(jī)幫助系統(tǒng)是軟件產(chǎn)品的重要組成部分，保證其正確性也是軟件測試工程師的職責(zé)。文檔/幫助測試的目的在于：提高易用性，使軟件用戶更容易地學(xué)習(xí)和使用軟件產(chǎn)品。提高可靠性，如果用戶閱讀文檔，然后使用軟件，最終得不到預(yù)期結(jié)果，這就是可靠性差。降低支持費(fèi)用，好的文檔/幫助通過恰當(dāng)?shù)慕忉尯鸵龑?dǎo)可以在用戶有麻煩或者遇到意外情況時(shí)減少請(qǐng)求公司幫助。從用戶的角度來測試軟件文檔是非常有效的方法。仔細(xì)閱讀，跟隨每個(gè)步驟，檢查每個(gè)圖形，嘗試每個(gè)示例。利用這個(gè)現(xiàn)實(shí)的簡單方法，可以找出軟件和文檔中的缺陷。常用的方法有：評(píng)審和審查，檢查文檔的編輯清晰性。動(dòng)態(tài)測試，結(jié)合實(shí)際程序的使用而使用文檔。讓獨(dú)立的第三方（如用戶）或其他人員(如以前沒有接觸或使用過本系統(tǒng)的新手)在程序的使用語境測試文檔也是十分有效的方法。文檔/幫助測試文檔/幫助測試的檢查單示例文檔是否精確描述了各種使用模式？每個(gè)交互順序的描述是否精確？例子是否精確？術(shù)語、菜單描述和系統(tǒng)響應(yīng)是否與實(shí)際應(yīng)用程序一致？是否能夠很方便地使用文檔定位和排除錯(cuò)誤？文檔的內(nèi)容和索引是否精確完整？文檔的設(shè)計(jì)（布局、縮入和圖形）是否便于信息的理解？顯示給用戶的錯(cuò)誤信息是否有更詳細(xì)的文檔解釋？如果使用超級(jí)鏈接，超級(jí)鏈接是否精確完整？如果使用超級(jí)鏈接，導(dǎo)航設(shè)計(jì)是否適合于所需要的信息？冒煙測試也稱為構(gòu)建驗(yàn)證測試（BVT，BuildVerificationTest）測試被測系統(tǒng)是否具有基本運(yùn)行功能，如啟動(dòng)、加載、執(zhí)行基本操作等。常與每日構(gòu)建相結(jié)合，作為集成測試的一個(gè)重要部分在系統(tǒng)測試中用作入口檢查通常需要自動(dòng)化工具常見故障被測系統(tǒng)無法啟動(dòng)和加載；基本功能出現(xiàn)故障；自動(dòng)化測試無法正確執(zhí)行。回歸（Regressive）測試對(duì)系統(tǒng)的新增功能和以前測試中已經(jīng)測試過無故障的相關(guān)功能進(jìn)行驗(yàn)證，以保證新增功能和/或?qū)εf有故障的修改不會(huì)在被測系統(tǒng)中引入新的故障，其測試范圍和規(guī)模介于完整測試和簡單的故障驗(yàn)證測試之間。需要根據(jù)新增/修改功能的波及范圍精心選擇和設(shè)計(jì)測試范圍與測試用例盡量采用自動(dòng)化測試工具隨機(jī)（Ad-hoc）測試俗稱“猴子”測試最好由用戶代表進(jìn)行公司內(nèi)部可結(jié)合新員工/工程/客服人員培訓(xùn)進(jìn)行應(yīng)該有適當(dāng)?shù)慕M織和計(jì)劃項(xiàng)目周期中的系統(tǒng)測試階段系統(tǒng)測試計(jì)劃階段系統(tǒng)測試設(shè)計(jì)和開發(fā)階段系統(tǒng)測試執(zhí)行和評(píng)估階段系統(tǒng)測試計(jì)劃階段主要活動(dòng)制定系統(tǒng)測試總體計(jì)劃簡述項(xiàng)目，明確測試的范圍定義測試策略（階段、類型、技術(shù)、標(biāo)準(zhǔn)等）編制測試需求工作分解和估算資源分配進(jìn)度表風(fēng)險(xiǎn)識(shí)別與應(yīng)對(duì)系統(tǒng)測試總體計(jì)劃評(píng)審批準(zhǔn)系統(tǒng)測試總體計(jì)劃系統(tǒng)測試總體計(jì)劃納入配置管理系統(tǒng)測試設(shè)計(jì)和開發(fā)階段系統(tǒng)測試方案設(shè)計(jì)測試方案評(píng)審系統(tǒng)測試規(guī)程設(shè)計(jì)建立需求跟蹤矩陣系統(tǒng)測試規(guī)程評(píng)審系統(tǒng)測試用例細(xì)化和再開發(fā)系統(tǒng)測試用例評(píng)審測試工具的設(shè)計(jì)和研制系統(tǒng)測試設(shè)計(jì)和開發(fā)階段常見風(fēng)險(xiǎn)不做測試設(shè)計(jì)，或測試過程并未系統(tǒng)測試總體計(jì)劃的要求來做。測試設(shè)計(jì)不詳細(xì)，不是基于可量度的測試策略，例如測試計(jì)劃覆蓋一個(gè)集合或者測試需求的一個(gè)子集。測試過程沒有檢驗(yàn)測試需求。測試開發(fā)沒有依據(jù)，測試規(guī)程和用例與測試方案或系統(tǒng)測試總體計(jì)劃中測試策略沒有對(duì)應(yīng)性。測試過程不可重復(fù)或不可重用。系統(tǒng)測試設(shè)計(jì)和開發(fā)階段常用度量需求覆蓋率（百分比）＝測試覆蓋的需求/所有的需求×100%；測試用例的數(shù)量（條）；自動(dòng)化測試在系統(tǒng)測試中的比例（百分比）＝采用自動(dòng)化測試的系統(tǒng)測試用例數(shù)目/全部的測試用例總數(shù)×100%；測試用例設(shè)計(jì)和開發(fā)的工作量（人時(shí)）；測試工具研制的工作量（人時(shí)）；系統(tǒng)測試文檔評(píng)審的工作量（人時(shí)）；系統(tǒng)測試執(zhí)行和評(píng)估階段系統(tǒng)測試申請(qǐng)系統(tǒng)測試申請(qǐng)審批制定系統(tǒng)測試詳細(xì)計(jì)劃執(zhí)行系統(tǒng)測試準(zhǔn)備系統(tǒng)測試執(zhí)行系統(tǒng)測試總結(jié)和評(píng)估系統(tǒng)測試執(zhí)行和評(píng)估階段常見風(fēng)險(xiǎn)沒有制定系統(tǒng)測試詳細(xì)計(jì)劃，測試開始之前測試人員不能明確本次系統(tǒng)測試活動(dòng)應(yīng)測試的測試用例。測試執(zhí)行不按照系統(tǒng)測試詳細(xì)計(jì)劃的要求來做，不能確保計(jì)劃要求的測試用例都能得到執(zhí)行。未對(duì)測試的原始數(shù)據(jù)進(jìn)行紀(jì)錄。本次系統(tǒng)測試新的有效測試規(guī)程和測試用例并未及時(shí)給予紀(jì)錄并管理。項(xiàng)目組和產(chǎn)品線的壓力有可能導(dǎo)致測試人員的測試評(píng)估不夠客觀準(zhǔn)確。沒有有效利用各種自動(dòng)化測試手段，手工測試太多。系統(tǒng)測試執(zhí)行和評(píng)估階段常用度量測試用例通過率（百分比）＝本次測試中通過的用例數(shù)/實(shí)際執(zhí)行的用例數(shù)；測試用例覆蓋率（百分比）＝本次測試中實(shí)際執(zhí)行的用例數(shù)/計(jì)劃執(zhí)行的用例數(shù)；本次測試中測試通過的系統(tǒng)測試用例數(shù)目（條）；本次測試中測試不通過的系統(tǒng)測試用例數(shù)目（條）；發(fā)現(xiàn)的缺陷數(shù)目及缺陷等級(jí)（個(gè)數(shù)、級(jí)別）；已經(jīng)解決的缺陷數(shù)目及缺陷等級(jí)（個(gè)數(shù)、級(jí)別）；遺留的缺陷數(shù)目及缺陷等級(jí)（個(gè)數(shù)、級(jí)別）；缺陷密度（分布圖）；測試的工時(shí)（人時(shí)）；系統(tǒng)測試的需求覆蓋率；系統(tǒng)測試經(jīng)驗(yàn)應(yīng)盡早地開始系統(tǒng)測試工作。充分注意測試中的缺陷密集現(xiàn)象，即對(duì)缺陷比較密集的部分進(jìn)行重點(diǎn)測試；嚴(yán)格執(zhí)行測試計(jì)劃，排除測試的隨意性。對(duì)測試過程和測試結(jié)果應(yīng)進(jìn)行評(píng)價(jià)，確保測試過程的有效性。妥善保存測試計(jì)劃、測試用例、故障統(tǒng)計(jì)和最終分析報(bào)告，為維護(hù)提供方便。對(duì)于被測試系統(tǒng)要進(jìn)行正常和異常兩方面的測試。在系統(tǒng)測試計(jì)劃中，要按照資源和項(xiàng)目的要求清晰地定義一個(gè)完整的退出準(zhǔn)則，這是一