ISTQB知識點總結：

註釋：
K1：表示一般理解 K2：表示一般掌握 K3：表示重點掌握並能夠應用

1.導致軟體缺陷的原因（K2）
缺陷是錯誤的結果，更精確地說，缺陷是錯誤的表現。當缺陷被執行時會導致失效的發生。

2.軟體測試在軟體開發、維護和使用中的角色（K2）
軟體測試是軟體開發過程中關鍵的質量保證活動，是軟體質量保證的一個環節。在軟體開發過程中實施嚴格規範的測試有助於發現軟體開發過程中不同階段的缺陷，儘可能的將缺陷發現於本階段並予以糾正，避免將缺陷帶入下一個開發階段，因為缺陷具有擴充套件的特點。所以在軟體開發過程中，對文件和程式碼的測試會對軟體的質量起到關鍵作用。
在軟體的維護階段，由於軟體可能發生修改和功能增強，所以軟體測試能發現由於修改和功能增強可能導致軟體系統出現的問題，包括對文件和軟體系統的測試。
軟體在使用過程中可能由於硬體、環境及軟體等原因出現各種問題，那麼這些問題只有通過測試才能找到問題所在，或者通過軟體測試模擬可能出現的問題。

3.什麼是軟體測試（K2）
“軟體測試”的經典定義是在規定條件下對程式進行操作，以發現錯誤，對軟體質量進行評估。

4.什麼是軟體質量
“軟體質量”是：軟體滿足規定或潛在使用者需求特性的總和。

5.軟體測試和軟體質量保證的區別
區別如下：
質量保證：質量保證的重要工作通過預防、檢查與改進來保證軟體質量。QA採用“全面質量管理”和“過程改進”的原理開展質量保證工作，所關注的是軟體質量的檢查與測量，主要著眼於軟體開發活動中的過程、步驟和產物，而不是對軟體進行剖析找出問題或評估。

軟體測試：測試雖然也與開發過程緊密相關，大關心的不是過程的活動，而是對過程的產物以及開發出的軟體產品進行剖析。測試人員要“執行”軟體，對過程中的產物——開發文件和原始碼進行走查，執行軟體，以找出問題，報告質量。

6.軟體測試的目的和一般原則（K2）
測試是程式的執行過程，目的在於發現錯誤；
一個好的測試用例在於能發現至今未發現的錯誤；
一個成功的測試是發現了至今未發現的錯誤的測試。

測試原則如下幾點：
1） 所有的軟體測試都應追溯到使用者需求；
2） 應當把“儘早的和不斷地進行軟體測試”作為軟體測試者的座右銘。
3） 完全測試是不可能的，測試需要終止；
4） 測試無法顯示軟體潛在的缺陷；
5） 充分注意測試中的群集現象；
6） 程式設計師應該避免檢查自己的程式；
7） 儘量避免測試的隨意性。

7.基本的軟體測試過程（K2）
軟體測試過程包括：
軟體測試計劃和控制
測試分析和設計
測試實施和執行
退出測試的標準
測試報告
測試結束活動等方面

8.V模型（K2）

1）單元測試：與詳細設計對應的是單元測試。單元測試檢測程式碼的開發是否符合詳細設計的要求。它主要是對詳細設計中的每個功能單元（通常是函式或過程）進行邏輯覆蓋測試，因此這種測試偏重於白盒測試。

2） 整合測試：與概要設計對應的是整合測試。因為概要設計的工作主要是根據功能把大的系統進行模組分解，所以整合測試的工作主要是，把各模組逐步整合在一起，來測試資料是否能夠在各模組間正確流動，以及各模組能否正確同步。因為這種測試依賴於軟體的架構但又不關心每個函式的實現細節，所以該測試關注的是模組之間的介面。

3）系統測試: 與需求分析對應的是系統測試。因為系統的需求分析的工作是分解使用者的功能和效能需求並規格化，並對應到系統中。所以系統測試的工作主要就是測試這些功能和效能指標是否都在軟體中正確實現。系統測試檢測已整合在一起的產品是否符合系統規格說明書的要求。該測試把軟體作為一個黑盒，針對每個需求規格組織各種輸入並根據軟體輸出來判斷該需求規格是否正確實現，因此係統測試偏重於黑盒測試。

4）驗收測試：與使用者需求對應的是驗收測試。是針對系統是否滿足使用者需求、業務流程等的驗收。當技術部門完成了所有測試工作後，由業務專家或使用者進行驗收測試，以確保產品能真正符合使用者業務上的需要。

9.軟體測試級別（K3）
1）單元測試：
單元測試或者模組測試是針對各個程式碼單元或者模組進行的測試。測試僅圍繞著具體的程式模組進行。

單元測試中常見的問題就是如何劃分單元以及獨立地對其進行測試。

傳統的單元測試術語（unit testing terminology） 包括了驅動模組（driver） 和 樁模組（stub）。driver的目的很單純，就是為了訪問類庫的屬性和方法，來檢測類庫的功能是否正確；stub的目的同樣單純，就是提供需要和測試類庫互動的那些類的實現。

單元測試必須將程式碼單元或模組與系統其他部分隔離，進行獨立的測試。

2）整合測試：
整合測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴充套件。它的最簡單的形式是：兩個已經測試過的單元組合成一個元件，並且測試它們之間的介面。整合測試的工作主要是，把單元測試過的各模組逐步整合在一起，來測試資料是否能夠在各模組間正確流動，以及各模組能否正確同步。

整合測試基本可以概括為以下兩種：
- 非漸增式測試模式：先分別測試每個模組，再把所有模組按設計要求一次全部組裝起來所要的系統，然後進行整體測試。
- 漸增式測試模式：把下一個要測試的模組同已經測試好的模組結合起來進行測試，測試完以後再把下一個模組結合進來測試。

整合測試可以分為兩種：手工黑盒和程式碼灰盒。手工黑盒與後續的系統測試的測試用例存在重用，程式碼灰盒是指標對元件的介面採用程式碼呼叫的方式來測試，一般不會涉及白盒測試，即不關心元件內部是如何實現，只關心元件的介面。

3）系統測試：
系統全部組裝完畢以後的測試是系統測試。系統測試的工作主要就是測試使用者的功能和效能需求指標是否都在軟體中正確實現。系統測試檢測已整合在一起的產品是否符合系統規格說明書的要求。該測試把軟體作為一個黑盒，針對每個需求規格組織各種輸入並根據軟體輸出來判斷該需求規格是否正確實現，因此係統測試偏重於黑盒測試。

系統測試人員負責制定測試計劃並依照測試計劃進行測試。這些測試包括功能性的測試（黑盒測試）和非功能性的測試（如，壓力測試等）。測試人員需要良好的測試工具來輔助完成測試任務，自動化的測試工具將大幅度提高測試人員的工作效率和質量。

4）驗收測試：
驗收測試也叫做確認測試是軟體開發結束後，驗證軟體的功能和效能及其它特性是否與使用者的要求一致。驗收測試包括使用者驗收測試、系統管理員的驗收測試（包括測試備份和恢復、災難恢復、使用者管理、任務維護、定期的安全漏洞檢查等）、基於合同的驗收測試，α和β測試。驗收測試是對軟體質量評價的一個重要標準。

使用者驗收測試可以分為幾個大的部分：確認測試的標準，軟體配置稽核（軟體配置內容：可執行程式、源程式、配置指令碼、測試程式或指令碼。），可執行程式測試，α、β測試。其大致順序可分為：文件稽核、原始碼稽核、配置指令碼稽核、測試程式或指令碼稽核、可執行程式測試，α、β測試。

α測試是指軟體開發公司組織內部人員模擬各類使用者對即將面市軟體產品（稱為α版本）進行測試，試圖發現錯誤並修正。α測試的關鍵在於儘可能逼真地模擬實際執行環境和使用者對軟體產品的操作並盡最大努力涵蓋所有可能的使用者操作方式。經過α測試調整的軟體產品稱為β版本。緊隨其後的β測試是指軟體開發公司組織各方面的典型使用者在日常工作中實際使用β版本，並要求使用者報告異常情況、提出批評意見。然後軟體開發公司再對β版本進行改錯和完善。

確認測試的測試內容：

（1）安裝測試
（2）功能測試
（3）可靠性測試
（4）安全性測試
（5）時間及空間效能測試
（6）易用性測試
（7）可移植性測試
（8）可維護性測試
（9）文件測試

10.軟體測試型別（K3）
功能性測試和非功能性測試。
功能需求指明軟體必須執行的功能，定義系統的行為——即軟體在某種輸入條件下要給出確定的輸出必須做的處理或轉換。功能需求通常是軟體功能的“硬指標”——如“支援分散式環境中訊息的可靠傳輸”；
非功能需求不描述軟體做什麼，描述軟體如何做。非功能需求通常作為軟體設計的“軟指標”——如“系統具有可伸縮性”。為此，我們可以把功能需求對應的功能稱為“功能性特徵”，把非功能需求對應的功能稱為“非功能性特徵”。

1） 功能性測試（黑盒測試（Black-box Testing）又稱為功能測試或資料驅動測試）
把測試物件看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。
採用黑盒技術設計測試用例的方法有：
等價類劃分、邊界值分析、決策表法、正交實驗法，場景法等。

黑盒測試試圖發現以下型別的錯誤：1）功能錯誤或遺漏；2）介面錯誤；3）資料結構或外部資料庫訪問錯誤；4）效能錯誤；5）初始化和終止錯誤。

2） 非功能性測試：
非功能性測試主要是基於產品的效能、負載、可用性、互動性、可維護性、可靠性及可移植性等方面的測試。還應該包括測試產品是否遵從指定的標準、規範和約束，以及操作介面的具體細節和構造上的限制。

3） 白盒測試：(White-box Testing，又稱邏輯驅動測試,結構測試)
把測試物件看作一個開啟的盒子。利用白盒測試法進行動態測試時，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。白盒測試法的覆蓋標準有邏輯覆蓋、迴圈覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判（斷）定覆蓋、條件覆蓋、判（斷）定/條件覆蓋、條件組合覆蓋和路徑覆蓋。這六種覆蓋標準發現錯誤的能力呈由弱至強的變化。

“白盒”法全面瞭解程式內部邏輯結構、對所有邏輯路徑進行測試。“白盒”法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程式的內部結構，從檢查程式的邏輯著手，得出測試資料。

4） 再測試迴歸測試
當一個缺陷被發現並被改正之後，軟體應該重新進行測試（再測試）以確保原來的缺陷成功地被消除。當軟體相關模組（元件）修改以後或軟體增加了相關模組（元件），為了確保軟體的正確性，也必須對相關模組進行迴歸測試。

5） 維護性測試：
維護測試通常始於客戶對系統變化或釋出下一個版本需求的確認。軟體測試管理人員也會以這些確認文件為基礎設計維護測試計劃。有了明確的測試目標後，測試員應該設計並執行新的測試用例、修改過的測試用例以及迴歸測試。在維護測試結束後，這些測試及結果也應該保留起來。

6） 靜態測試技術：
軟體工作產品可以通過不同的靜態技術進行檢查以評估工作產品的質量，而這種靜態技術不同於軟體的動態測試技術。靜態測試是相對於動態測試而言的，即不要求在計算機上實際執行所測程式所進行的測試。靜態測試主要以一些人工的模擬技術對軟體進行分析和測試，是白盒測試方法的一種，包括程式碼檢查、靜態結構分析等。

靜態測試可以分為評審和工具支援的靜態測試技術。相對於動態測試而言，靜態測試成本更低，效率較高，更重要的是可以在軟體開發生命週期早期就發現缺陷和問題。

11.評審相關
1）評審定義
評審是指由軟體工作產品生產者的同行遵循已定義的規程對產品所做的評審，目的在於識別出缺陷和需改進之處。
評審是一個總體的概念，在實際執行時有不同的組織形式，由嚴格的，也有鬆散的。根據具體情況的不同，可以把評審分為非正式評審和正式評審。
- 非正式是指工作產品沒有完成，正在開發中不需要遵循明確定義的過程等情形。
- 正式是指作者已經確認工作產品已經完成，評審會議遵循一個已經明確定義的過程，參與人員有明確的職責與檢查表. 不同的角色明確定義的進入與完成準則。

其中正式評審根據評審物件，關注內容等不同，又分為走查，技術評審和正規檢視。

2）評審過程
評審過程一般包括：計劃階段、準備階段、自評審階段、評審會階段、重新修改階段和分析總結階段。

A.計劃階段
定義評審標準
選擇人員
分配角色
為更加正式的評審型別（比如審查）制定入口和出口準則；
選擇需要進行評審的文件的內容
核對入口準則（針對更正式的評審型別）

B.預備會階段
分發文件
向評審參與者解釋評審的目標、過程和文件

C.個人準備階段（自評審）
先行評審文件，為評審會議做準備
標註可能的缺陷、問題和建議

3）責任和角色
在正式的評審中一般包括如下角色：協調負責人、作者、記錄員、評審者。他們在正式的評審中承擔不同的責任。不同的評審形式可能包括更多種角色。

12.走查相關
1）定義：
走查是評審的一種基本形式，但評審物件主要是軟體程式碼，通過對源程式程式碼進行分析、檢驗，並補充相關的文件，發現程式中的錯誤。

一般由作者和一個以上其他評審人員組成。

2）目的：
進行走查的方式，主要對以下內容進行檢查：
- 檢查程式碼和設計的一致性
- 程式碼對標準的遵循、可讀性
- 程式碼邏輯表達的正確性
- 程式碼結構的合理性
- 程式編寫與編寫標準的符合性
- 程式中不安全、不明確和模糊的部分
- 程式設計風格問題等
3）走查過程：
計劃走讀會議；
評審產品；
進行走讀；
解決缺陷；
記錄走讀；
返工產品。

13.測試設計技術的分類（K2）
軟體測試技術主要包括：黑盒（功能性）測試技術（以規約為基礎的測試技術）、白盒（結構性）測試技術（以程式結構為基礎的測試技術）及經驗為基礎的測試。經驗為基礎的測試主要是根據測試人員的技術、經驗及知識來設計測試用例，這是一種測試用例設計的補充。

1） 結構性測試
結構性測試是另一種用於設計測試用例的基本方法。為了與功能性測試形成對比，結構性測試有時叫做白盒(或甚至叫做透明盒)測試

2） 功能性測試（黑盒測試）與結構性測試（白盒測試）的區別
功能性測試只利用規格說明設計測試用例，而結構性測試使用程式原始碼(實現)作為測試用例設計的基礎。

13.功能性測試（黑盒測試）：
包括等價類劃分，邊界值分析，決策表、正交實驗、use-case以及特殊值法等。
1）等價類劃分（K3）
等價類劃分的辦法是把程式的輸入域劃分成若干部分，然後從每個部分中選取少數代表性資料作為測試用例。

有效等價類：指對於程式的規格說明來說是合理的、有意義的輸入資料構成的集合。利用有效等價類可檢驗程式是否實現了規格說明中所規定的功能和效能。

無效等價類：與有效等價類的定義恰巧相反。

2）邊界值分析（K3）
邊界值分析是一種補充等價劃分的測試用例設計技術，它不是選擇等價類的任意元素，而是選擇等價類邊界的測試用例。
對邊界值設計測試用例，應遵循以下幾條原則：
(1)如果輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界的值，以及剛剛超越這個範圍邊界的值作為測試輸入資料。
(2)如果輸入條件規定了值的個數，則用最大個數、最小個數、比最小個數少1、比最大個數多1的數作為測試資料。
(3)根據規格說明的每個輸出條件，使用前面的原則(1)。
(4)根據規格說明的每個輸出條件，應用前面的原則(2)。
(5)如果程式的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最後一個元素作為測試用例。
(6)如果程式中使用了一個內部資料結構，則應當選擇這個內部資料結構邊界上的值作為測試用例。

3） 決策表法（K3）
4） 正交試驗法 （K2）
5） Use-Case法（場景法）（K3）
6） 基於經驗的特殊值測試（K2）
7） 黑盒測試方法的選擇（K3）
在任何情況下都必須使用邊界值分析方法。經驗表明，用這種方法設計出的測試用例發現程式錯誤的能力最強。

14.結構性測試（白盒測試）：
白盒測試主要是檢查程式的內部結構、邏輯、迴圈和路徑。白盒測試的常用測試用例設計方法有：邏輯覆蓋和基本路徑測試。
根據覆蓋測試的目標不同，邏輯覆蓋又可分為：語句覆蓋、判定覆蓋、判定-條件覆蓋、條件組合覆蓋及路徑覆蓋。

1） 語句覆蓋：語句覆蓋就是設計若干個測試用例，執行所測程式，使得每一條可執行語句至少執行一次。語句覆蓋是最弱的邏輯覆蓋準則。
2） 條件覆蓋：條件覆蓋就是設計若干個測試用例，執行所測程式，使得程式中每個判斷的每個條件的可能取值至少執行一次。
3） 判定覆蓋：判定覆蓋就是設計若干個測試用例，執行所測程式，使得程式中每個判斷的取TRUE分支和取FALSE分支至少經歷一次。判定覆蓋又稱分支覆蓋。
4） 判定-條件覆蓋：判定-條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的所有可能取值至少執行一次，同時每個判斷的所有可能判斷結果至少執行一次。
5） 條件組合覆蓋：條件組合覆蓋就是設計足夠的測試用例，執行所測程式，使得每個判斷的所有可能的條件取值組合至少執行一次。
6） McCabe覆蓋

15.測試技術的選擇（K2）
邊界值測試方法是一種機械的設計用例方法，容易產生冗餘的測試用例，因為本方法沒有考慮程式變數之間的關係；等價類方法可能存在用例設計的漏洞，因為測試的好壞依賴於等價類的劃分的粒度；決策表方法用例的設計花費的時間多等等。所以在具體的軟體測試過程中可以使用不同的測試方法來設計一組合理的測試用例集。
另外，結構性的測試方法和功能性的測試方法在測試過程中也可以進行交叉設計，達到互相補充的目的。如，在滿足語句覆蓋的同時，滿足Use-case法的覆蓋。

16.傳統結構化軟體測試（K3）
1）結構化單元測試概念
單元測試是對軟體基本組成的單元進行的測試，這裡的基本單元不一定是指一個具體的函式(Function或Procedure)或一個類的方法(Method)，“單元”具有一些基本屬性，如：
明確的功能、規格定義、與其他部分的明確的介面定義等，可清晰地與同一程式的其他單元劃分開來。在具體實現時，也可能對應的是多個程式檔案中的一組函式。

單元測試過程分為計劃、設計、實現、執行、評估等幾個步驟，各步驟的任務如下：
(1)計劃單元測試。確定測試需求，制定測試策略，確定測試所用資源(包括人力資源和裝置資源)，建立測試任務的時間表等。
(2)分析和設計單元測試。設計單元測試模型，制定測試方案，確認並結構化測試過程。
(3)實現單元測試。參考測試模型和測試方案，制定具體的測試用例，建立可重用的測試指令碼。
(4)執行單元測試。根據單元測試的方案、用例對單元進行測試，驗證測試的結果並記錄測試過程中出現的缺陷。
(5)評估單元測試。對單元測試的結果進行評估，主要從需求覆蓋和程式碼覆蓋的角度，進行測試完備性的評估。

2）單元測試的設計模型
因為單元本身不是一個獨立的程式，一個完整的、可執行的軟體系統並沒有形成，所以在測試模型設計中必須為每個單元測試開發驅動模組(Driver)和樁模組(Stub)。在絕大多數應用中，驅動模組只是一個接收測試資料並把資料傳送給(要測試的)模組，然後列印相關結果的“主程式”。“樁模組”的功能是替代那些隸屬於本模組(被呼叫)的模組，樁模組要使用子模組的介面，做少量的資料操作，並驗證列印入口處的資訊，然後返回。

17.測試用例設計原則
(1)為系統執行起來而設計用例
(2)為正向測試而設計用例
(3)為逆向測試而設計用例
(4)為滿足特殊需求而設計用例
(5)為程式碼覆蓋而設計用例

18.面向物件的動態測試
1．樁（stub）是代替那些還沒實現的或還沒有經過測試的部分，在樁內只實現要替代部分的一些基本功能。採用由底向上的方式進行開發，底層的程式碼先開發並先測試，可以避免編寫大量的樁程式碼。
2．測試驅動器（driver）是一個執行測試用例並收集執行結果的程式。它的主要任務是初始化被測試程式，使被測類處於一個特定的開始狀態，然後測試驅動器按照測試用例所定義的輸入引數去執行相應的方法（Methods）。在執行過程中要檢查被測試部分的狀態並做好記錄，通過比較期望的結果和實際的結果最終確定是否有錯，而期望的結果可以從規範書（specification）內獲得，任何偏離規範書（specification）的行為都視為錯誤。

19.GUI測試概述
圖形使用者介面的測試（GUI testing）主要包括兩項內容：介面顯示測試和介面功能測試。

為了更好地進行GUI測試，提倡介面與功能的設計分離。一般可以把 GUI 系統分為3個層次：介面層、介面與功能的介面層、功能層。這樣GUI的測試可以把重點放在介面層和介面與功能的介面層上，並可使用黑盒測試原理來進行功能測試（black box testing）。
在設計GUI測試用例時，可以按4個步驟進行思考：
劃分介面元素，並根據介面的複雜性進行分級
根據不同的介面級別確定不同的測試策略
進行測試資料的分析，提取測試用例
使用自動測試工具

20.測試經理和測試成員的角色
測試團隊中測試經理任務主要有：負責整改測試專案，包括制定測試計劃、協調和管理監督測試過程，和其他小組的溝通、協調等。

測試成員負責測試計劃中具體事項的執行，記錄並報告測試結果等。

21.測試文件 （K2）
每個軟體測試專案有5類基本測試文件：
- 測試計劃文件
- 測試方案文件
- 測試用例文件
- 測試報告文件

22.測試計劃和估算 （K2）
1）在需求分析階段，要完成驗收測試計劃，並與需求規格說明一起提交評審。
2）在概要設計階段，要完成和評審系統測試計劃。
3）在詳細設計階段，要完成和評審整合測試計劃。
4）在編碼實現階段，要完成和評審單元測試計劃。
5）對於測試計劃的修訂部分，需求進行重新評審。

測試計劃中包含的主要內容有：明確要完成的測試活動，評估完成活動所需時間和資源，設計測試組織和崗位職權，進行活動安排和資源分配，安排跟蹤和控制測試過程的活動，制定測試策略，確定測試範圍、測試目的、測試方法、迴歸測試的技術要求、測試通過/失敗的標準、測試終止準則，進行測試結果分析和度量以及測試風險評估，對測試過程的質量保證和配置管理工作進行明確規定，應交付的測試工作產品。

23．軟體配置管理
配置管理是通過對在軟體生命週期的不同的時間點上的軟體配置進行標識，並對這些被標識的軟體配置項的更改進行系統控制，從而達到保證軟體產品的完整性和可溯性的過程。

24.專案風險相關
1）專案風險
專案風險是指關於專案按目標交付的能力方面的風險。
如使用者需求不明確，專案組未正確理解客戶需求，缺乏專案管理經驗，資源衝突，進度延誤等。
2）產品風險
在軟體或系統中的潛在失效的區域（即將來可能發生的不利事件或危險）稱之為產品風險，因為它們對產品質量而言是一個風險。
交付後的產品存在問題而導致的風險。
缺陷導致人員的傷害、企業的財政損失、功能失效、效能不良等。
產品風險對於專案的成功來講是一種特殊型別的風險。
作為一種風險控制活動，測試通過評估修正嚴重缺陷的能力和應急計劃的有效性來提供關於殘留風險的反饋資訊。

25.測試工具型別
型別
測試管理工具（管理測試用例、指令碼、資源、計劃、缺陷）
測試控制工具（控制測試執行並收集測試結果）
測試執行（回放）工具（執行指令碼並返回測試結果）
測試輔助工具（輔助進行管理、控制、執行、分析、設計等的工具）

常見的測試工具軟體
MercuryInteractive - WinRunner, QuickTestProfessional
Segue - Slik Test
IBM Rational – Robot, Functional Tester
Compuware - QARun

一些選擇題會出現的知識點總結：

1.關於缺陷錯誤失效：

當存在缺陷的程式碼被執行時，可能引發的是軟體失效，不是錯誤；
（人為）錯誤，（內在）缺陷，（外部）失效。失效是缺陷在外部的反映；
靜態測試，不執行程式，發現的是缺陷；
動態測試，執行程式，發現的是失效；
程式期望結果和實際結果有所偏差稱為失效；
失效也可能是外部環境造成的，如電磁場輻射的影響；
缺陷有可能會導致失效，但不是必然的。如果程式不被執行的話，失效也就不會發生。

2.關於測試不同階段的目標：
早期測試（靜態測試）的目標：預防缺陷。
開發階段的測試（元件測試，整合測試，系統測試）目標：發現缺陷。
驗收測試的目標：建立信心。
執行階段的測試（維護測試）目標：提供資訊。

3.關於測試原則：
1） 所有的軟體測試都應追溯到使用者需求；
2） 應當把“儘早的和不斷地進行軟體測試”作為軟體測試者的座右銘。
3） 完全測試是不可能的，測試需要終止；
4） 測試無法顯示軟體潛在的缺陷；
5） 充分注意測試中的群集現象；
6） 程式設計師應該避免檢查自己的程式；
7） 儘量避免測試的隨意性；
8） 測試應儘早介入。

4.關於獨立測試：
測試人員具有專業測試知識背景，獨立測試可以更高效地發現軟體缺陷和軟體存在的失效；
軟體測試與軟體開發的思維方式不同。由於思維定勢，開發人員難於發現自己的錯誤；
測試通常被認為是破壞性的活動，而軟體開發通常被認為是建設性的活動；
獨立測試可以應用在任何級別的測試活動中。

5.關於殺蟲劑悖論和缺陷叢集性：
定期對TC進行Review並持續改善更新，體現了殺蟲劑悖論原則。
很多缺陷會集中在某一模組上，體現了缺陷叢集性原則。

6.關於測試型別：
結構性測試又稱邏輯驅動測試，功能測試又稱資料驅動測試。
與變更相關的測試包括確認測試和迴歸測試。
可移植性測試屬於非功能測試。
非功能測試包括效能，負載，可用性，互動性，可維護性，可靠性及可移植性等方面的測試。
功能測試不考慮程式的具體執行路徑，僅關注功能是否實現。
安全性測試和互操作性測試屬於功能測試的一種。
互動性測試屬於非功能測試。

7.各個型別測試的目的：
整合測試的目的是發現介面和整合後元件間協同工作的缺陷。
系統測試的目的是驗證系統是否符合使用者需求。
驗收測試的目的是對系統或子系統建立信心。
元件測試的目的是檢查程式碼是否符合設計和規範。確認所有的錯誤處理路徑屬於元件測試的目的。

8. 關於迭代-增量開發模型：
驗證和確認可以在每個增量模組中進行。
在完成第一次迭代後，對所有的迭代進行迴歸測試會變得越來越重要。
在每次迭代過程中，對迭代產生的系統可能需要在不同的測試級別上進行測試。
迭代開發是先開發大體的框架，後開發具體的詳細內容。
增量開發是先開發一個詳細的模組，再開發另一個詳細的模組，形成一個逐漸增大的系統。

9. 系統測試的測試依據：
系統測試的測試依據：1. 系統和軟體需求規格說明 2. 用例 3. 功能規格說明 4. 風險分析報告
整合測試的測試依據：1. 軟體和系統設計文件 2. 系統架構 3. 工作流 4. 用例

10. 樁模組與驅動模組相關：
樁模組：對頂層或上層模組進行測試時所編寫的替代下層模組的程式。
驅動模組：對底層或子層模組進行測試所編寫的呼叫這些模組的程式。

漸增式測試模式自頂向下整合時，前期完成的模組將是後期模組的驅動程式。
漸增式測試模式自底向上整合時，前期完成的模組將是後期模組的樁程式。

非漸增式測試模式：先分別測試每個模組，再把所有模組按設計要求一次全部組裝起來所要的系統，然後進行整體測試。非漸增式整合測試是不科學的整合測試方式。
漸增式測試模式：把下一個要測試的模組同已經測試好的模組結合起來進行測試，測試完以後再把下一個模組結合進來測試。

Alpha測試：潛在客戶/使用者在開發現場進行的測試。
Beta測試：潛在客戶/使用者在自己的環境下測試。

11.關於評審相關：
1）正式評審:1. 走查 2. 技術評審 3. 審查。
2）工具支援的靜態測試（靜態分析）: 1. 詞法和語法分析 2. 靜態錯誤分析（控制流分析和資料流分析）。
3）
非正式評審沒有正式的過程。
走查由作者主持開會。
技術評審可能是沒有管理者參與的同行評審。
審查由專門培訓的主持人來領導。根據入口、出口準則的檢查列表和規則定義正式的評審過程。

12. 3個測試術語相關：
測試條件—-》能通過1個或多個測試用例進行驗證的一個條目或事件（比如功能，事物處理，質量特徵或結構元素等。）
測試用例—-》一組輸入值，執行的前提條件，預期結果和執行的後置條件等元素組成，以覆蓋一定的產生目標或測試條件。
測試規程—-》描述測試用例的執行順序

補充：
測試條件：元件或系統中能被一個或多個測試用例驗證的條目或事件。例如：功能、事物、特性、質量屬性或者結構化元素。
測試用例：為特定目標或測試條件而制定的一組輸入值，執行入口條件，預期結果和執行出口條件。
測試規程：描述測試用例的執行順序。
測試設計規格說明：為一個測試條目指定測試條件，具體測試方法，並識別相關高層測試用例的文件。
測試用例規格說明：為測試項指定一套測試用例的文件。
測試規程規格說明：規定了執行測試一系列行為的文件，也稱為測試指令碼或手工測試指令碼。

13. 軟體測試設計技術相關：
基於規格說明或黑盒測試技術：等價類，邊界值，因果圖與決策表，狀態轉換，用例。
基於結構的或白盒測試技術：語句覆蓋，判定覆蓋等。
基於經驗的測試技術：探索性測試，錯誤推測法。

14. 使用模型來描述需要解決的問題，軟體或其元件的是哪種測試技術？
使用正式或非正式的模型來描述需要解決的問題、軟體或其元件，是基於規格說明的測試技術特點。

補充：
基於規格說明的測試技術特點：
使用正式或非正式的模型來描述需要解決的問題、軟體或其元件等。
根據這些模型，可以系統地匯出測試用例。

基於結構的測試技術特點：
根據軟體的結構資訊設計測試用例，比如軟體程式碼和軟體設計規格說明文件。
可以通過已有的測試用例測量軟體的測試覆蓋率，並通過系統化的匯出設計用例來提高覆蓋率。

基於經驗的測試技術特點：
測試用例根據參與人員的經驗和知識來編寫。
測試人員、開發人員、使用者和其他的利益相關者對軟體、軟體使用和環境等方面所掌握的知識作為資訊來源之一。
對可能存在的缺陷及其分佈情況的瞭解作為另一個資訊來源。

黑盒測試是基於規格說明的測試技術。
基於經驗的測試技術指的是探索性測試和錯誤推測法。

15.關於語句覆蓋：
100%的判定覆蓋可以保證100%的語句覆蓋，反之則不行。
邏輯覆蓋由弱到強的排列是：語句覆蓋，判定覆蓋，條件覆蓋，判定條件覆蓋，條件組合覆蓋，路徑覆蓋。

16.測試員測試經理職責:
測試經理（測試組長）的職責：主要負責測試計劃、監視與控制、協調等。
測試員的職責：主要負責測試分析、設計與執行等。

17.測試方法的選擇：
典型的測試方法：
分析的方法，比如基於風險的測試，直接針對風險最高的部分進行測試；
基於模型的方法，比如隨機測試利用失效率（如：可靠性增長模型）或使用率（如：執行概況）的統計資訊；

系統的方法，比如基於失效的方法（包括錯誤推測和故障攻擊），基於檢查表的方法和基於質量特徵的方法；

基於過程或符合標準的方法，比如在行業標準中規定的方法或各類敏捷的方法；
動態和啟發式的方法，類似於探索性測試，測試很大程度上依賴於事件而非提前計劃，而且執行和評估幾乎是同時進行的；

諮詢式的方法，比如測試覆蓋率主要是根據測試小組以外的業務領域和技術領域專家的建議和指導來推動的；

可重用的方法，比如重用已有的測試材料，廣泛的功能迴歸測試的自動化，標準測試套件等。

18.關於專案風險和產品風險：
專案風險的因素：組織方面、技術方面、供應商方面。

產品風險的因素和表現：
易錯的軟體交付使用。
軟體、硬體對個人或公司造成傷害的可能性。
劣質的軟體特徵（比如功能性、可靠性、可用性和效能等）。
低劣的資料完整性和質量（例如：資料遷移問題、資料轉換問題、資料傳輸問題、違反資料標準問題）。
軟體沒有實現既定的功能。

19.入口、出口準則：
測試入口準則：
測試環境已經準備就緒並可用
測試環境中的測試工具已經準備就緒
可測的物件可用
測試資料可用

測試出口準則：
完整性測量，比如程式碼、功能或風險的覆蓋率。
對缺陷密度或可靠性度量的估計。
成本。
遺留風險，比如沒有被修改的缺陷或在某些區域缺少測試覆蓋等。
進度表，如基於交付到市場的時間。

20.測試管理工具：
測試管理工具的功能：
管理軟體需求
管理測試計劃
管理測試用例
缺陷跟蹤與管理
測試過程中各類資料的統計和彙總
測試管理工具不負責對測試人員進行績效管理

21.測試執行工具：
1）測試執行工具使用自動化的測試指令碼執行測試物件。
2）通過記錄測試員手動操作的捕捉過程往往開始看起來似乎很吸引人，但是這種方法不適合大量的自動化測試。捕獲的指令碼知識用特定資料和動作來線性表示每個指令碼的一部分。當發生意外時間時，這類指令碼是不穩定的。　
3）資料驅動的方法是將測試輸入（資料）與測試用例分離，並將測試輸入存放在一個電子表格中，這樣可以使用不同的資料進行相同的測試。
4）關鍵字驅動的測試方法中，電子表格含有描述系統要採取的行為的關鍵字（也稱為行為字）和測試資料。測試員（即使不熟悉指令碼語言）也能針對被測應用，使用這些關鍵字來定義測試。

22.商業區娛樂區：
商業區：指南、賣點、地標、極限、快遞、深夜、遍歷。
娛樂區：配角、深巷、通宵。

23.幾種測試方法總結：
1）快遞測試法：執行操作後，後臺資料有相應的變化，操作過程中的所有資料變化都能正常顯示。
2）上一版測試法：思考新版本的更新內容，是否對老版本的功能有影響（Side Effect）。
3）深夜測試法：當我們不對測試物件操作時，測試物件能否會自動完成各種維護任務，將資料歸檔，自動記錄發生的異常情況等。如：周排行榜，每日任務的Reset（重置）功能。
4）通宵測試法：程式一直保持執行，而不去關閉它。如：長時間掛機，長時間後臺放置。

關於評審選擇題會出現的知識點總結：

1.評審的說明
1）評審是靜態測試技術
2）軟體開發的所有作業成果物是都可以評審的
3）比動態測試更簡單地找到需求規定說明、功能或處理的遺漏
4）評審比動態測試技術不容易發現的錯誤是記憶體洩漏，容易發現的是否遵守程式碼規則、需求規則的遺漏以及設計遺漏。

2．不同評審型別的說明
1）評審沒有固定過程（非正式評審）
2）根據相關材料按方案實行（走查）
3）目的是：學習和理解軟體設計，傳播知識，瞭解情況，查詢錯誤（走查）
4）對錯誤指出，可以技術專家參加，評審的過程是按規範的步驟，並且文件化。（技術評審）
5）以過程本身改進為目的，引入了度量，並且有宣讀員（審查）
6）目的是：討論，作決策，評估候選方案，指出錯誤，解決技術問題，驗證技術問題，驗證軟體符合它的需求規格 （技術評審）
7）比如二人一組，對軟體程式，由技術的負責人來評審設計或程式碼（非正式審查）
8）有正式的跟蹤過過程 （審查）

3.正式評審的階段定義
1）對於人選，分配任務，決定評審文件的哪些部分，正式程度高的評審，比如審查要定義。
——-計劃階段

2）討論評審物件的文件，記錄討論的結果，正式的評審中要在議事錄中保留開會討論事項的結果或議事的內容，評審的參加者指出缺陷，表達對缺陷的處理方法的意見，關於缺陷要作出決定
——-評審會階段

3）要確認是否處理了缺陷，收集指標，正式程度高的評審要確認結束條件
——-跟蹤階段

4）配布文件，對參加者說明目的，過程，文件的說明了，正式程度高的評審要確認開始條件
——-預備會階段

補充：
確認是否處理了缺陷
收集指標
確認結束條件 ——-問題跟蹤

4.評審中的不同角色定義
1）決定實施評審，建立實行的計劃表，判斷評審的目的是否恰當
——-經理

2）對某種技術很瞭解，擁有很好的業務背景，也叫檢查員或審查員，對評審物件，要指出有注意到的地方。比如說缺陷
——-評審員

3）調解文件的評審，評審的目的，計劃，評審的展開，還包含跟蹤，有必要的情況，還要從不同的視點來考慮事物，評審成功與不成功多取決於這個人。
——-主持人

4）記錄在評審時受理的所有課題，問題點，沒有解決的事項
——-記錄員

5.靜態測試技術與評審說明
早期檢出缺陷並修正可以縮短開發期間。
所有的靜態測試都是停靠人力來實施地。
靜態測試適用於程式碼的規則違反或找出軟體的設計上的缺陷。

6. 關於靜態測試和動態測試的關係
靜態測試在動態測試實施前實施，期待大的效果

7.關於靜態分析工具
1）初期能指出程式碼缺陷，預期得到的回報率
2）能計策複雜度，表示維護性的困難度
3）能指出變數的初期値的錯誤，結構上的欠缺

8.關於主持人職責
進行不同觀點之間的協調

9.不參加技術評審的是 經理

10.關於評審的特徵的是：
審查：由主持人或評審負責人支援；使用入口和出口準則
通行評審：沒有參與管理
非正式評審：不需要檔案證明
走查：有作者負責主持

                       待續......