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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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