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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16、性能測試的目的： 為了驗證系統是否達到用戶提出的性能指標，同時發現系統中存在的性能瓶頸，起到優化系統的目的 。 性能測試指標的來源： 用戶對各項指標提出的明確需求；如果用戶沒有提出性能指標則根據用戶需求、測試設計人員的經驗來設 計各項測試指標。 （需求 +經驗）主要的性能指標： 服務器的各項指標（ CPU、內存占用率等） 、后臺數據庫的各項指標、網絡流量、響應時間（2）壓力測試（累積效應） 壓力測試是在一種需要反常數量、頻率或資源的方式下，執行可重復的負載測試，以檢查程序對異常情況的抵抗能力，找出性能瓶頸。 壓力測試總是迫使系統在異常的資源配置下運行。（ 4） 容量測試 容量測試目的是通過測試

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

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

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

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

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

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

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

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

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

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

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

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

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

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