軟件測試知識總結(jié)

1、1、測試驅(qū)動開發(fā)（ TDD）測試在先，編碼在后的開發(fā)方法（詳見書本12 頁）2、軟件質(zhì)量：功能、性能、可靠性（書本15 頁）3、軟件測試的工作范疇：測試的組織與管理（PDCA）、測試計劃、測試用例、測試的實施、測試結(jié)果分析、測試評審與報告（書本 29 頁小結(jié)中）第三章4、白盒測試（設(shè)計測試用例看書說明）（又稱邏輯驅(qū)動測試 ,結(jié)構(gòu)測試 ）的意思是把程序看成裝在一個透明的白盒子里，測試人員知道程序的結(jié)構(gòu) 和處理算法 ,按照程序內(nèi)部的邏輯進行測試， 檢測程序中的主要執(zhí)行通路是否都能按預(yù)定要求正確工作， 利 用白盒測試法進行動態(tài)測試時， 不需測試軟件產(chǎn)品的功能。 白盒測試主要用于單元測試。 （詳見書本

2、 31 頁） （ 1） 語句覆蓋設(shè)計若干測試用例，運行被測試用例，使程序中的每個可執(zhí)行語句至少被執(zhí)行一次。（2）判定覆蓋： 設(shè)計若干測試用例， 運行被測試用例， 使程序中每個判斷的取真分支和取假分支至少經(jīng)歷一 次。（針對每次判斷，又稱分支覆蓋）（3）條件覆蓋： 設(shè)計若干測試用例， 運行被測試用例， 使程序中每個判斷中每個條件的可能取值至少滿足一 次。（針對每次判斷中的每一個條件）（4）判定 -條件覆蓋（5）條件組合覆蓋：每個判定結(jié)果至少出現(xiàn)一次，每個條件的所有可能至少出現(xiàn)一次。（6）路徑覆蓋：設(shè)計所有的測試用例，來覆蓋程序中的所有可能的執(zhí)行路徑。（7）基本路徑測試法： （根據(jù)流程圖判斷） 獨立

3、路徑：所謂獨立路徑，是指至少包含一條新邊的路徑，也就是包含一些前面的路徑未包含的語句， 當(dāng)所有的語句都包含了，基路徑集就夠了。5、黑盒測試（設(shè)計測試用例案例）（又稱功能測試或者數(shù)據(jù)驅(qū)動測試）黑盒測試法把程序看作一個黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和處 理過程。也就是說，黑盒測試是在程序接口進行的測試，它只檢查程序功能是否能按照規(guī)格說明書的規(guī)定 正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)并產(chǎn)生正確的輸出信息，程序運行過程中能否保持外部信息的 完整性。（ 1） 等價劃分（見書本 40 頁） 有效等價類和無效等價類 輸入條件規(guī)定了取值范圍或者個數(shù)的情況下，則可以確立一個有效等價類和兩個無效等價類。 在輸

4、入條件規(guī)定了輸入值的集合或者規(guī)定了 “必須如何 ”的條件的情況下，可確立一個有效等價類和 一個無效等價類。在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下， 可確立一個有效等價類 （符合規(guī)則 ）和若干個無效等價類 （從不同角度違反規(guī)則 ）。（參考 40 頁實例）（ 2） 邊界值分析 如果輸入條件規(guī)定了值的范圍， 則應(yīng)取剛達到這個范圍的邊界的值以及剛剛超越這個范圍邊界的 值作為測試輸入數(shù)據(jù)。如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最小個數(shù)少一、比最大個數(shù)多一的 數(shù)作為測試數(shù)據(jù)。如果程序規(guī)格說明中提到的輸入或輸出是個有序的集合， 應(yīng)該注意選取有序集的第一個和最后一 個作為測試用例。（ 3） 正

5、交試驗 正交表具有兩條性質(zhì)： （1）每一列中各數(shù)字出現(xiàn)的次數(shù)都一樣多。（2） 任何兩列所構(gòu)成的各有序數(shù)對出現(xiàn)的次數(shù)都一樣多。所以稱之謂正交表。 （見書本 48 頁）（ 4） 錯誤推測表 基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤 , 從而有針對性的設(shè)計測試用例的方法。6、主動測試與被動測試主動測試：測試人員主動向被測試對象發(fā)送請求， 驗證被測試對象的反應(yīng)和輸出結(jié)果。一般在測試環(huán)境下 進行，測試人員需要設(shè)計若干測試用例，設(shè)法輸入各種數(shù)據(jù)。被動測試：為了解決產(chǎn)品在線測試問題。在被動測試方法中，軟件產(chǎn)品運行在實際環(huán)境中，測試人員不干 預(yù)產(chǎn)品的運行，而是被動地監(jiān)控產(chǎn)品的運行，通過一定的被動機制來獲

6、取系統(tǒng)運行的數(shù)據(jù)，測試人員不需要設(shè) 計測試用例。7、基于風(fēng)險的測試 指評估測試的優(yōu)先級，先做高優(yōu)先的測試，如果時間或者精力不足，低優(yōu)先級的測試可以暫時先不做。影響測 試優(yōu)先級主要因素：對用戶的影響、出錯的概率第四章8、V模型（ RAD模型 快速應(yīng)用開發(fā)模型）書本 66頁V 模型大體可以劃分為以下幾個不同的階段步驟: 需求分析、概要設(shè)計、詳細設(shè)計、軟件編碼、單元測試、集成測試、系統(tǒng)測試、驗收測試。原理：在瀑布模型的基礎(chǔ)上，通過開發(fā)和測試同時進行的方式來縮短開發(fā)周期，提高開發(fā)效率 適用條件：明確需求、需求變化不大V 模式是一種傳統(tǒng)軟件開發(fā)模型， 一般適用于一些傳統(tǒng)信息系統(tǒng)應(yīng)用的開發(fā)， 而一些高性能

7、高風(fēng)險的系統(tǒng)、 互聯(lián)網(wǎng)軟件， 或一個系統(tǒng)難以被具體模塊化的時候， 就比較難做成 V 模式所需的各種構(gòu)件， 需要更強調(diào)迭代的 開發(fā)模型或者敏捷開發(fā)模型。優(yōu)缺點：（詳見瀑布模型的優(yōu)缺點）V 模型僅僅把測試過程作為在需求分析、系統(tǒng)設(shè)計及編碼之后的一個階段，忽視了測試對需求分析,系統(tǒng)設(shè)計的驗證，需求的滿足情況一直到后期的驗收測試才被驗證。9、軟件質(zhì)量體系標(biāo)準(zhǔn)（1）CMM 針對軟件產(chǎn)品的質(zhì)量管理和質(zhì)量保證標(biāo)準(zhǔn)CMM 全稱為 （Capability Maturity Model）, 中文名稱為能力成熟度模型CMM 劃分為五級 :級別越高表明該企業(yè)在提供合格軟件產(chǎn)品方面的能力越強（2） CMMI 為了整合不

8、同模型的最佳實踐 ,建議統(tǒng)一模型 ,覆蓋不同領(lǐng)域 ,供企業(yè)進行整個組織的全面過程改進,并于 20XX年正式發(fā)布了能力成熟度集成模型 （CMMI） 。（3） ISO 9000 原本是硬件標(biāo)準(zhǔn)（見書本 83 頁） ISO9000不是指一個標(biāo)準(zhǔn)，而是一類標(biāo)準(zhǔn)的統(tǒng)稱。 ISO 9000族標(biāo)準(zhǔn)是用來提供一個通用的質(zhì)量體系標(biāo)準(zhǔn) 的核心，適用于廣泛的工業(yè)行業(yè)和經(jīng)濟部門。測試分類：單元測試、集成測試、系統(tǒng)測試、驗收測試第五章 單元測試10 、單元測試（見書本 97 頁）：單元測試是對軟件基本組成單元進行的測試 為什么要進行單元測試？盡早發(fā)現(xiàn)錯誤錯誤發(fā)現(xiàn)越早 ,成本越低 .開發(fā)人員過于自信 ,后期復(fù)雜度高 ,發(fā)

9、現(xiàn)解決 BUG困難 . 檢查代碼是否符合設(shè)計和規(guī)范 目標(biāo)：（1）主要目標(biāo)：確保各單元模塊被正確地編碼（2）確保代碼在結(jié)構(gòu)上可靠且健全，能夠在各種條件下給予正確的響應(yīng) 概括起來，單元測試是對代碼對單元的代碼規(guī)范性、正確性、安全性和性能等進行驗證。內(nèi)容（任務(wù)） ：單元中所有獨立執(zhí)行路徑、數(shù)據(jù)結(jié)構(gòu)、接口、邊界條件、容錯性等測試。 （詳見 ppt 單元測試）10 、走查和審查（見 104 頁表 5-1）靜態(tài)測試三部曲：走查、審查、評審（1）走查 采用講解、討論和模擬運行的方式進行的查找錯誤的活動。引導(dǎo)小組成員在走查前通讀設(shè)計和編碼。限時，避免跑題。發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場修改。 檢查要點是代碼是否符

10、合標(biāo)準(zhǔn)和規(guī)范，是否有邏輯錯誤。2）審查采用講解、提問方式進行，一般有正式的計劃、流程和結(jié)果。主要方法采用缺陷檢查表。以會議形式，制定會議目標(biāo)、流程和規(guī)則，結(jié)束后要編寫報告。按缺陷檢查表逐項檢查。發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場修改。發(fā)現(xiàn)重大缺陷，改正后會議需要重開。檢查要點是缺陷檢查表，所以該表要根據(jù)項目不同不斷積累完善。走查審查準(zhǔn)備通讀設(shè)計和編碼應(yīng)準(zhǔn)備好需求描述文檔、程序設(shè)計文檔、程序的源代碼清單、代碼編碼標(biāo)準(zhǔn)和代碼缺陷檢查表形式非正式會議正式會議參加人員開發(fā)人員為主項目組成員包括測試人員主要技術(shù)方法無缺陷檢查表注意事項限時、不要現(xiàn)場修改代碼限時、不要現(xiàn)場修改代碼生成文檔會議記錄靜態(tài)分析錯誤報告目

11、標(biāo)代碼標(biāo)準(zhǔn)規(guī)范， 無邏 輯錯誤代碼標(biāo)準(zhǔn)規(guī)范，無邏輯錯誤12、驅(qū)動程序與樁程序（在黑盒測試中） 驅(qū)動程序：也稱驅(qū)動模塊，用以模擬被測模塊的上級模塊，能夠調(diào)用被測模塊。在測試過程中，驅(qū)動模塊接受測試 數(shù)據(jù)，調(diào)用被測模塊并把相關(guān)數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印出相應(yīng)的結(jié)果。樁程序：也稱樁模塊，用以模擬被測模型工作過程中所調(diào)用的下級模塊。樁模塊由被測模塊調(diào)用，它們一般只進行 很少的數(shù)據(jù)處理。第六章 集成測試與系統(tǒng)測試13、集成測試模式（1）非漸增式測試模式 先分別測試每個模塊。再把所有模塊按設(shè)計要求放在一起結(jié)合成所要的程序。如：大棒模式概括地說，非增量式測試就是采用一步到位的方法構(gòu)造測試，即對

12、所有模塊進行單元測試后，按照程序結(jié) 構(gòu)圖將所有模塊連接起來，進行整體測試 .其明顯缺點是容易出現(xiàn)混亂，判斷出錯的原因和位置比較困難，因為測試時可能出現(xiàn)很多錯誤，并且在修 正一個錯誤的同時，可能會引入新的錯誤。（2）漸增式測試模式 把下一個要測試的模塊同已經(jīng)測試好的模塊結(jié)合起來進行測試， 測試完以后再把下一個應(yīng)該測試的模塊結(jié) 合進來測試。具體優(yōu)缺點詳見書本 126 頁14、自頂向下與自底向上集成方法（ 1）自頂向下：從主程序開始，沿著軟件的控制層次向下移動，從而逐漸把各個模塊結(jié)合起來。在組裝過程中， 可以使用深度優(yōu)先或者寬度優(yōu)先的策略。逐步集成和逐步測試是按照結(jié)構(gòu)圖自上而下進行 深度優(yōu)先的集成是

13、先集成一個主控路徑下的所有模塊，主控路徑的選擇是任意的； 廣度優(yōu)先的集成首先是沿著水平方向，把每一層中所有直接屬于上一層的模塊集中起來，直到最底 層。集成測試的整個過程主要由 3 個步驟完成：1）主控模塊作為測試驅(qū)動器；2）根據(jù)集成方式，下層的樁模塊依次被替換為真正模塊； 3）每個模塊集成時，進行單元測試。（2）自底向上：從原子模塊開始集成以進行測試。（ 3）改進的自頂向下：基本使用 “自頂向下 ”，但在早期，使用自底向上測試少數(shù)關(guān)鍵模塊。 混合法：對軟件結(jié)構(gòu)中較上層，使用的是“自頂向下”法；對軟件結(jié)構(gòu)中較下層，使用的是“自底向上”法，兩者 相結(jié)合15、改進的三明治集成方法 三明治方法：采用三

14、明治方法的優(yōu)點是： 它將自頂向下和自底向上的集成方法有機地結(jié)合起來， 不需要寫樁程序因為在測試 初自底向上集成已經(jīng)驗證了底層模塊的正確性。 采用這種方法的主要缺點是： 在真正集成之前每一個獨立的模 塊沒有完全測試過。改進的三明治集成方法： 不僅自兩頭向中間集成，還保證了每個模塊得到單獨的測試，使測試進行的比較徹底。16、持續(xù)集成（ 1）持續(xù)集成（ Continuous Integration， CI）是持續(xù)地編譯、測試、檢查和部署源代碼的過程。（ 2）優(yōu)點：持續(xù)集成可以減少集成階段"Bug"消耗的時間，從而最終提高軟件開發(fā)的質(zhì)量和效率。（3）持續(xù)集成測試的原理 持續(xù)集成，是

15、一種軟件開發(fā)實踐，即團隊開發(fā)成員經(jīng)常集成它們的工作，通常每個成員每天至少集成一次，也 就意味著每天可能會發(fā)生多次集成。每次集成都通過自動化的構(gòu)建（包括編譯，發(fā)布，自動化測試） 來驗證，從而盡快地發(fā)現(xiàn)集成錯誤。17、回歸測試（ 1）概念： 指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或?qū)е缕渌a產(chǎn)生錯誤。（2） 方法: 再測試全部用例、基于風(fēng)險選擇測試、基于操作剖面選擇測試、再測試修改的部分。（ 3） 目的： 所做的修改達到了預(yù)定的目的，如錯誤得到了改正，新功能得到了實現(xiàn)，能夠適應(yīng)新的運行環(huán)境等； 不影響軟件原有功能的正確性。18、非功能測試（設(shè)計測試用例主要看課件）（1）性能測試

16、性能測試的目的： 為了驗證系統(tǒng)是否達到用戶提出的性能指標(biāo)，同時發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，起到優(yōu)化系統(tǒng)的目的 。 性能測試指標(biāo)的來源： 用戶對各項指標(biāo)提出的明確需求；如果用戶沒有提出性能指標(biāo)則根據(jù)用戶需求、測試設(shè)計人員的經(jīng)驗來設(shè) 計各項測試指標(biāo)。 （需求 +經(jīng)驗）主要的性能指標(biāo)： 服務(wù)器的各項指標(biāo)（ CPU、內(nèi)存占用率等） 、后臺數(shù)據(jù)庫的各項指標(biāo)、網(wǎng)絡(luò)流量、響應(yīng)時間（2）壓力測試（累積效應(yīng)） 壓力測試是在一種需要反常數(shù)量、頻率或資源的方式下，執(zhí)行可重復(fù)的負載測試，以檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力，找出性能瓶頸。 壓力測試總是迫使系統(tǒng)在異常的資源配置下運行。（ 4） 容量測試 容量測試目的是通過測試

17、預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù) 據(jù)庫記錄數(shù)等） ，系統(tǒng)在其極限值狀態(tài)下還能保持主要功能正常運行。 容量測試還將確定測試對象在給定時 間內(nèi)能夠持續(xù)處理的最大負載或工作量。（ 5） 安全性測試 安全性測試是檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法 試圖突破防線。（ 6） 可靠性測試 可靠性（ Reliability）是產(chǎn)品在規(guī)定的條件下和規(guī)定的時間內(nèi)完成規(guī)定功能的能力，它的概率度量稱為可靠 度。軟件可靠性是軟件系統(tǒng)的固有特性之一，它表明了一個軟件系統(tǒng)按照用戶的要求和設(shè)計的目標(biāo)，執(zhí)行 其功能的可靠程度。軟件可靠性與軟件缺

18、陷有關(guān)，也與系統(tǒng)輸入和系統(tǒng)使用有關(guān)。理論上說，可靠的軟件 系統(tǒng)應(yīng)該是正確、完整、一致和健壯的。（ 7） 容錯性測試 容錯性測試是檢查軟件在異常條件下自身是否具有防護性的措施或者某種災(zāi)難性恢復(fù)的手段。如當(dāng)系統(tǒng)出 錯時，能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)壓力測試、容量測試和性能測試的測試目的雖然有所不同，但其手段和方法在一定程度上比較相似， 通常會使 用特定的測試工具，來模擬超常的數(shù)據(jù)量、負載等，監(jiān)測系統(tǒng)的各項性能指標(biāo)，如 CPU 和內(nèi)存的使用情況、 響應(yīng)時間、數(shù)據(jù)傳輸量等。19、（ 1）測試. 測試 測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對即將面市軟件產(chǎn)品 （稱為 版本）進行測試

19、， 試圖發(fā)現(xiàn)錯誤并修正。經(jīng)過 測試調(diào)整的軟件產(chǎn)品稱為 版本。緊隨其后的 測試是指軟件開發(fā)公司組織各方面的典型用 戶在日常工作中實際使用 版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對版本進行改錯和完善。（2）文檔測試： 非代碼的文檔測試主要檢查文檔的正確性、完備性和可理解性。驗證正確性驗證完備性 驗證可理解性 軟件驅(qū)動的文檔還得像程序一樣運行起來測試。第八章 面向?qū)ο筌浖y試20、分層與增量原理（ 160 頁）類 C 和其派生類 D 間的增量變化能夠用來幫助確定需要在 D 中測試什么。由于 D 是 C 的子類，那么所有的用 于 C 的基于規(guī)范的測試用例也都適用于 D 。引入術(shù)

20、語“繼承的測試用例”來代表從父類測試用例中選取出來的、用 于子類的測試用例。 可以通過簡單的分析來確定繼承的測試用例中哪些適用于測試子類、 哪些在測試子類時不必執(zhí) 行。21、分類測試要點（泛化）與組裝結(jié)構(gòu)（聚合） 分類測試：體現(xiàn)了問題空間實例中的一般與特殊的關(guān)系 組裝結(jié)構(gòu)：體現(xiàn)了問題空間實例中整體與局部的關(guān)系第九章 基于應(yīng)用服務(wù)器的測試21、解釋下列故障名稱及原理 數(shù)據(jù)庫并發(fā)能力 : 多個應(yīng)用請求的并發(fā)處理過程 并發(fā)主要考慮的幾個方面 :（詳見書本 196 頁） （1）數(shù)據(jù)丟失（解釋）（2）不可重復(fù)數(shù)據(jù)（解釋）（3）讀臟數(shù)據(jù)（解釋）（4）數(shù)據(jù)庫的鎖第十章 軟件本地化測試22、翻譯錯誤測試方法翻

21、譯錯誤：(1)產(chǎn)生原因：1)翻譯人員不熟悉翻譯要求。2)翻譯人員工作疏漏。3)用戶界面的翻譯與標(biāo)準(zhǔn)詞匯表不一致。(2)表現(xiàn)特征：1)應(yīng)該翻譯而沒有翻譯的英文字符。2)不應(yīng)該翻譯而翻譯的中文字詞。3)錯誤翻譯的字詞。4)只在本地化版本中存在該類型錯誤。5)較多隱含在對話框各控件以及幫助文檔中。(3)測試要求：1)明確需要翻譯和不需要翻譯的內(nèi)容。2)明確正確的翻譯方式。3)根據(jù)術(shù)語表，確認術(shù)語翻譯的正確性與一致性。(4)測試方法：1)主要同時打開中英文版本，執(zhí)行相同的操作。2)結(jié)合標(biāo)準(zhǔn)界面詞匯翻譯表，參照對比。（5） 說 明1） 對于對話框，如果含有下拉列表框，要打開列表框查看全部項。23、布局錯

22、誤測試方法原因：(1)產(chǎn)生1） 軟件本地化后，由于源語言和本地化語言的表達方式不同，本地化后的字符數(shù)與源語言不同，每個字符所占空間尺寸不同，使得在英文版本正確顯示的控件字符，可能在本地化版本顯示不正確。2)本地化人員調(diào)整程序資源不當(dāng)引起，例如，對話框及其控件高度或?qū)挾鹊牟徽_調(diào)整。(2)表現(xiàn)特征：1)控件相互重疊或排列不均勻。2)控件中字符顯示不完整。3） 主要出現(xiàn)在本地化版本的對話框中。(3)測試要求：1)對話框中控件布局均勻，字符顯示完整正確。2)對話框中控件數(shù)量相等，沒有多余或丟失的控件(4)測試方法：1)執(zhí)行將要打開對話框的菜單或工具欄按鈕，觀察打開對話框中的控件布局。2)對比檢查源語

23、言軟件和本地化軟件對應(yīng)的對話框中控件的數(shù)量（5） 說 明1） 可能在執(zhí)行不同的操作后，如選擇了不同單選或復(fù)選按鈕后，編輯框顯示重疊等。第十一章 軟件測試自動化24、測試自動化（1）概念：自動化測試是把以人為驅(qū)動的測試行為轉(zhuǎn)化為機器執(zhí)行的一種過程。（2）與手工測試的辯證關(guān)系 測試自動化能：顯著降低重復(fù)手工測試的時間建立可靠、重復(fù)的測試，減少人為錯誤增強測試質(zhì)量和覆蓋率測試自動化不能：完全替代手工測試和手工測試工程師保證 100%的測試覆蓋率軟件測試自動化 （TA）雖然具有很多優(yōu)點，但只是對手工測試的一種補充，TA絕不能代替手工測試，有各自的特點：在系統(tǒng)功能邏輯測試、驗收測試等多采用黑盒測試的手工

24、測試方法； 系統(tǒng)性能、穩(wěn)定性、可靠性測試等比較適合采用TA；對那種不穩(wěn)定軟件的測試、開發(fā)周期很短的軟件、一次性的軟件等不適合測試自動化 工具本身并沒有想象力和靈活性，根據(jù)經(jīng)驗報道，自動測試只能發(fā)現(xiàn)15%的缺陷，而手工測試可以發(fā)現(xiàn)85%的缺陷； TA工具在進行功能測試時，其準(zhǔn)確的含義是回歸測試工具，因為工具不能發(fā)現(xiàn)更多的新問題， 但可以保證對已經(jīng)測試過部分進行測試的準(zhǔn)確性和客觀性3）黑盒測試的主要步驟（自動化測試有哪些主要步驟？） 錄制測試過程成為自動化測試腳本 增強和改進錄制的自動化測試腳本 執(zhí)行自動化測試腳本完成自動化測試（4）性能測試測什么？ 各種操作的響應(yīng)速度、最大并發(fā)用戶數(shù) 最大數(shù)據(jù)容

25、量（5）單元測試、集成測試、系統(tǒng)測試的區(qū)別與聯(lián)系 單元測試 單元測試是對軟件基本組成單元（軟件設(shè)計的最小單位）進行正確性檢驗的測試工作，如 函 數(shù) 、 過 程 （function,procedure） 或 一 個 類 的 方 法 （method） 集成測試 集成測試是在單元測試的基礎(chǔ)上，將所有模塊按照概要設(shè)計要求組裝成為子系統(tǒng)或系統(tǒng)， 驗證組裝后功能以及模塊間接口是否正確的測試工作。集成測試也叫組裝測試、聯(lián)合測試、 子系統(tǒng)測試或部件測試 系統(tǒng)測試 系統(tǒng)測試是將已經(jīng)集成好的軟件系統(tǒng)，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬 件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際使

26、用環(huán)境下， 對計算機系統(tǒng)進行一系列的組裝測試和確認測試的工作單元測試 白盒測試 集成測試 灰盒測試單元內(nèi)部的數(shù)據(jù)結(jié)構(gòu)，邏輯控制，異常處理等邏輯覆蓋率模塊間接口以及模塊組合后的整體功能接口覆蓋率系統(tǒng)測試 黑盒測試整個系統(tǒng)對需求的符合度測試用例對需求的覆蓋率詳設(shè)概設(shè)需求第十三章 部署測試環(huán)境（設(shè)計測試環(huán)境）25、測試環(huán)境重要性（詳見書本 289 頁） 使用錯誤的測試環(huán)境，可能引起下列一系列問題： 得出錯誤結(jié)果 與實際誤差很大 忽略了實際使用可能出現(xiàn)的嚴(yán)重錯誤 導(dǎo)致項目返工，成本加大 導(dǎo)致項目延期26、（ 1）測試環(huán)境 5 要素硬件軟件數(shù)據(jù)準(zhǔn)備網(wǎng)絡(luò)環(huán)境測試工具（2）數(shù)據(jù)準(zhǔn)備（需要理解透徹） 數(shù)據(jù)準(zhǔn)備

27、包括數(shù)據(jù)量和真實性兩個方法。 （詳見書本 294 頁） 第十五章 報告所發(fā)現(xiàn)的缺陷27、（1）軟件缺陷 軟件缺陷指的是系統(tǒng)或系統(tǒng)部件中那些導(dǎo)致系統(tǒng)或部件不能實現(xiàn)其功能的缺陷。如 果在執(zhí)行中遇到一個缺陷，可能引起系統(tǒng)的失效。那么準(zhǔn)確有效的定義和描述軟件缺陷， 可以使軟件缺陷得以快速修復(fù)，節(jié)約了軟件測試項目的成本和資源，提高產(chǎn)品質(zhì)量。（2）軟件缺陷描述的基本要求 軟件缺陷的描述是軟件缺陷報告中測試人員對問題的陳述的一部分并且是軟件缺陷 報告的基礎(chǔ)部分。同時，軟件缺陷的描述也是測試人員就一個軟件問題與開發(fā)小組交流的 最初且最好的機會。一個好的描述，需要使用簡單的、準(zhǔn)確的、專業(yè)的語言來抓住缺陷的 本質(zhì)

28、。單一準(zhǔn)確可以再現(xiàn)完整統(tǒng)一短小簡練特定條件補充完善不做評價28、分離和再現(xiàn)缺陷原理 開發(fā)人員有時可以根據(jù)相對簡單的錯誤信息就能找出問題所在。因為開發(fā)人員熟悉代 碼，因此看到癥狀、測試用例步驟和分離問題的過程時，可能得到查找軟件缺陷的線索。一個軟件缺陷的分離和再現(xiàn)問題有時需要小組的共同努力。如果軟件測試人員盡最大努力 分離軟件缺陷，也無法表達準(zhǔn)確的再現(xiàn)步驟，那么仍然需要記錄和報告軟件缺陷。29、缺陷描述的主要內(nèi)容軟件缺陷的詳細描述，由三部分組成：操作/ 重現(xiàn)步驟、期望結(jié)果、實際結(jié)果，有必要再做進一步的討論：“步驟 ”提供了如何重復(fù)當(dāng)前缺陷的準(zhǔn)確描述，應(yīng)簡明而完備、清楚而準(zhǔn)確。這些信息對開發(fā)人員是

29、關(guān)鍵的， 視為修復(fù)缺陷的向?qū)В?開發(fā)人員有時抱怨糟糕的缺陷報告， 往往集中在這里；“期望結(jié)果 ”與測試用例標(biāo)準(zhǔn)或設(shè)計規(guī)格說明書或用戶需求等一致，達到軟件預(yù)期的 功能。測試人員站在用戶的角度要對它進行描述，它提供了驗證缺陷的依據(jù)?！皩嶋H結(jié)果 ”測試人員收集的結(jié)果和信息，以確認缺陷確實是一個問題，并標(biāo)識那些 影響到缺陷表現(xiàn)的要素。優(yōu)秀的缺陷報告重現(xiàn)步驟 :a） 打開一個編輯文字的軟件并且創(chuàng)建一個新的文檔（這個文件可以錄入文字）b） 在這個文件里隨意錄入一兩行文字c） 選中一兩行文字，通過選擇 Font 菜單然后選擇 Arial 字體格式d） 一兩行文字變成了無意義的亂字符期望結(jié)果：當(dāng)用戶選擇已錄入

30、的文字并改變文字格式的時候，文本應(yīng)該顯示正確的文字格 式不會出現(xiàn)亂字符顯示。實際結(jié)果 :它是字體格式的問題，如果改變文字格式成Arial 之前，你保存文件，缺陷不會出現(xiàn)。缺陷僅僅發(fā)生在 Windows98 并且改變文字格式成其它的字體格式， 文字是顯示正常的第十七章 軟件測試項目管理30、測試目標(biāo)與準(zhǔn)則（詳見書本 359 頁） （1）目標(biāo)（為什么要進行軟件測試）（2）準(zhǔn)則（3）測試范圍優(yōu)先級最高的需求功能新功能和編碼改動較大 （提高性能表現(xiàn) ）的舊功能 運用有效的測試技術(shù)去提高測試效果 經(jīng)常容易出現(xiàn)問題部分的功能 一些經(jīng)常被用戶使用的功能和配置31、測試計劃內(nèi)容（詳見書本 360 頁）測試計劃制定的第一步就是將軟件分解較小而且相對獨立的功能模塊，寫成測試需求。 測試需求有很多分類方法，最普通的一種就是按照功能分類：測試需求是測試設(shè)計和開發(fā)測試用例