ISTQB學習筆記

學習ISTQB大綱
此文記錄初次閱讀時不夠明確的地方

第一章：軟件測試基礎
1. 引起軟件缺陷的原因
人都會犯錯誤（error,mistake），因此人設計的代碼或文檔中會引入缺陷（defect, fault, bug）；當存在缺陷的代碼被執行時，系統可能無法實現期望功能或實現了未期望的功能，引起軟件失效（failure）。

產生缺陷的原因：人們本身容易犯錯誤、時間壓力、復雜的代碼、復雜的系統架構、技術的革新、以及/或者許多系統之間的交互等。
失效也可能是由環境條件引起的：如：輻射、電磁場和污染等都有可能引起固件中的故障，或者由於硬件環境的改變而影響軟件的執行。

2. 進行軟件測試的原因：
可以減少軟件系統在運行環境中的風險，
提高軟件的質量，
為了滿足合同或法律法規的要求，
為了滿足行業標准的要求。

3. 軟件質量特性：
功能、可靠性、可用性、可移植性、可維護性、效率

4. 測試和質量
通過測試發現的缺陷評估質量；
測試發現缺陷很少或沒有，測試可以幫助樹立對質量的信心；
合理的測試順利通過，可降低系統存在的風險；
修改了缺陷則提升了質量；
分析缺陷及其原因可改進軟件開放過程，反過來可提升以后產品質量。

測試是質量保證工作不可或缺的一部分。

5. 質量保證包括：
開發標准、培訓和缺陷分析

6. 測試活動包括：
計划和控制，
選擇測試條件、設計和執行測試用例，
檢查測試結果，
評估出口准則，
報告測試過程及被測系統，
在一個測試階段完成后要進行測試結束和總結工作，
同時也包括文檔/代碼的評審、執行靜態分析。

7. 測試的目標：
發現缺陷，
增加對質量的信心，
為決策提供信息，
預防缺陷。

8. 不同的測試階段考慮不同的測試目標：
軟件生命周期早起的測試設計的思維過程和活動：可以避免將缺陷引入代碼；
對文檔的評審，並識別和解決問題：有助於防止代碼中出現缺陷；
開發測試（組件測試、集成測試和系統測試）：盡可能多的發現失效，從而識別和修正盡可能多的缺陷；
驗收測試：確認系統是否按照預期工作，建立滿足了需求的信心；
維護測試：驗證開發過程中的變更是否引入新的缺陷；
運行測試：評估系統的特征，如可靠性或可用性等。

9.殺蟲劑悖論
采用同樣的測試用例多次重復進行測試，最后將不在能夠發現新的缺陷。為了克服殺蟲劑悖論，測試用例需要進行定期評審和修改，同時需要不斷增加新的不同的測試用例來測試系統的不同部分，從而發現潛在的更多的缺陷。

10. 測試的7個原則：
測試顯示存在缺陷（但不能證明系統不存在缺陷）；
窮盡測試是不可行的；
測試盡早介入；
缺陷集群性；
殺蟲劑悖論；
測試活動依賴於測試背景（如對安全關鍵的軟件進行測試，跟對一般軟件的測試是不一樣的）；
不存在缺陷（就是有用系統）的謬論（如果系統無法使用，或不能完成客戶的需求和期望，發現和修改缺陷是沒有任何意義的）。

11. 基本的測試過程：
測試計划和控制；
測試分析和設計；
測試實現和執行；
評估出口准則和報告；
測試結束活動。
以上活動邏輯上連續，但實際可能會重疊或同時進行；可適當剪裁。

12. 測試計划的主要活動是：
識別測試任務，
定義測試目標，
為了實現目標和任務確定必要的測試活動。

13. 測試控制是持續進行的活動（整個生命周期）：
報告測試的狀態，包括與計划的偏差；
采取必要措施以滿足測試任務和目標。

14. 測試分析和設計階段的主要任務：
評審測試依據（如需求、軟件完整性級別（風險等級）、風險分析報告、系統架構、設計和接口說明）；
評估測試依據和測試對象的可測性；
通過對測試項、規格說明、測試對象行為和結構的分析，識別測試條件並確定其優先級；
設計測試用例並確定優先級；
確定測試條件和測試用例所需要的測試數據；
規划測試環境的搭建和確定測試需要的基礎設施和工具；
創建測試依據和測試用例間的雙向可追蹤性。

15. 測試實現和執行階段的任務：
通過特定的順序組織測試用例來完成測試規程和腳本的設計，並且包括測試執行所需的其他任何信息，以及測試環境的搭建和運行測試。

16. 評估出口准則和報告
主要任務：
按照測試計划中定義的測試出口准則檢查測試日志；
評估是否需要進行更多的測試，或是否需要更改測試的出口准則；
為利益相關者提供一個測試總結報告。

17. 測試結束活動
進行測試結束活動的情況：
軟件系統正式發布、
一個測試項目完成（或取消）、
達到一個里程碑或一個維護版本完成。

18. 測試結束活動的主要任務：
檢查提交了哪些計划的可交付產品；
事件報告是否關閉、或對未關閉的時間報告提交變更需求；
記錄系統的驗收；
記錄和歸檔測試件、測試環境和測試基礎設備，以便以后的重復使用；
移交測試件到維護部門；
分析和記錄所獲得的經驗教訓，用於以后的項目和測試成熟度改進；
使用為測試成熟度的提高所收集的信息。

19. 從低到高定義不同級別的測試獨立：
測試由軟件本身的編寫人員來執行；
測試由一個其他開發人員來執行（可能來自同一個開發小組）；
測試由組織內的一個或多個其他小組成員（如獨立的測試小組）或測試專家（如可用性和測試專家）來執行；
測試由來自其他組織或其他公司的成員來執行（如測試外包或其他外部組織的鑒定）。

20. 發現失效需要測試員具有：
好奇心，
專業的懷疑態度，
一雙挑剔的眼睛，
對細節的關注，
與開發人員良好的溝通能力，
對常見的錯誤進行判斷的經驗。

21. 職業道德：
公共：測試工程師應當以公眾利益為目標；
客戶和雇主：在保持與公正利益一致的情況下，應注意滿足客戶和雇主的最高利益；
產品：產品發布版本符合最高的專業標准；
判斷：維護職業判斷的完整性和獨立性；
管理：對軟件測試合乎道德規范的管理；
專業：推進其專業的完整性和聲譽；
同事：對同事持平等、互助、支持的態度，促進與開發人員的合作；
自我：參與終生職業實踐的學習，並促進合乎道德的職業實踐方法。

第二章：軟件生命周期中的測試
1. 軟件開發模型：
V模型（順序開發模型）；
迭代-增量開發模型：原型開發、快速應用開發、統一軟件開發過程、敏捷開發模型等；

2. 每個測試級別都需要明確的內容：
測試的總體目標，
測試用例設置需要參考的產品（即測試的依據），
測試的對象，
發現的典型缺陷和失效，
對測試用具的需要，
測試工具的支持，
專門的方法和職責等。

3. 組件測試/單元測試
依據：組件需求說明、詳細設計文檔、代碼。
典型測試對象：組件、程序、數據轉換/移植程序、數據庫模型。

樁、驅動器和模擬器：底層打樁，中間驅動，上層行為模擬

可能包括：功能測試、特定的非功能特征測試，如資源行為測試（如內存泄漏）、健壯性測試和結構測試（如分支覆蓋）

4. 集成測試
依據：軟件和系統設計文檔、系統架構、工作流、用例；
典型測試對象：子系統、數據庫實現、基礎結構、接口、系統配置和配置數據。

5. 集成級別不同：
組件集成測試對不同的軟件組織之間的相互作用進行測試，一般在組件測試之后進行；
系統集成測試對不同系統或軟硬件之間的相互作用進行測試，一般在系統測試之后進行。

6. 系統測試：
依據：系統和軟件需求規格說明、用例、功能規格說明、風險分析報告；
典型測試對象：系統、用戶手冊和操作手冊，系統配置和配置數據。

通常由獨立的團隊進行。

7. 驗收測試
依據：用戶需求、系統需求、用例、業務流程、風險分析報告；
典型測試對象：基於完全集成系統的業務流程、操作與維護流程、用戶處理過程、結構、報告、配置數據。

通常由使用系統的用戶或客戶來進行。

8. 驗收測試的典型類型：
用戶驗收測試：由商業用戶驗證系統可用性；
操作（驗收）測試：由系統管理員來進行，包括：系統備份/恢復測試、災難恢復測試、用戶管理測試、維護任務測試、數據加載和移植活動、安全漏洞階段性檢查；
合同和法規性驗收測試：根據合同規定、根據必須遵守的法律法規進行測試；
Alpha和Beta測試：
    alpha測試在開發組織現場進行，但由潛在用戶測試；
    beta測試或實地測試，在客戶現場又客戶執行；
    也可稱為工廠驗收測試和現場驗收測試。
    
9. 從測試的級別划分：
組件測試/單元測試、
集成測試、
系統測試、
驗收測試

10. 根據特定的目標或測試原因：
功能測試：主要考慮軟件的外部表現行為（黑盒）；可以包括：
    安全性測試：系統和數據是否能抵御外部惡意威脅；
    互操作性測試：與其他組件或系統交互能力的測試；
非功能測試：測試系統運行的表現如何；
    包括但不限於：
    性能測試
    負載測試
    壓力測試
    可用性測試
    可維護性測試
    可靠性測試
    可移植性測試

11. 軟件結構/架構測試（結構測試）：可以在任何測試級別使用；最好在進行基於規格說明測試之后使用，以便通過評估結構類型的覆蓋來測量測試的完整性；

12. 確認：
當發現和修改了一個缺陷后，應進行再測試以確定已經成功的修改了原來的缺陷，稱之為確認。

13. 維護測試
在現有的運行系統上進行，且一旦對軟件或系統進行修改（功能增加、修正和應急變更、環境的變化（如升級、漏洞））、移植（平台遷移）或退役處理（數據移植、存檔測試）時，就需要進行維護測試。
維護測試的范圍取決於變更的風險、現有系統的規模和變更的大小。

第三章 靜態技術
1. 靜態測試技術：
通過手工檢查（評審）或自動化分析（靜態分析）的方式對代碼或者其他的項目文檔進行檢查而不需要執行代碼。

2. 評審：
更容易發現：與標准之間的偏差、需求內的錯誤（需求遺漏）、設計錯誤、可維護性不足和錯誤的接口規格說明等等。

3. 評審過程：
評審過程的正式性和以下因素有關：開發過程的成熟度、法律法規方面的要求或審核跟蹤的需要。
評審的目標：發現缺陷、增加理解、培訓測試員和團隊新成員或對討論和決定達成共識等。

4. 正式評審的階段：
1）計划階段：
定義評審標准，
選擇人員，
分配角色，
為更加正式的評審類型（比如審查）制定入口和出口准則，
選擇需要進行評審的文檔內容，
核對入口准則（針對更正式的評審類型）。
2）預備會階段：
分發文檔，
向評審參與者解釋評審的目標、過程和文檔。
3）個人准備階段：
先行評審文檔，為評審會議做准備；
標注可能的缺陷、問題和建議。
4）檢查/評價/記錄結果（評審會議階段）：
討論和記錄，並留下文檔化的結果或會議紀要（針對更正式的評審類型）；
標注缺陷、提出處理缺陷的建議、對缺陷做出決策；
在任何形式的會議期間或跟蹤任何類型的電子通信期間檢查/評價和記錄問題。
5）返工階段：
修改發現的缺陷（通常由作者進行）；
記錄缺陷跟蹤的狀態（在正式評審中）；
6）跟蹤結果階段：
檢查缺陷是否已得到解決；
收集度量數據；
核對出口准則（針對更正式的評審類型）。

5. 角色和職責
經理（管理者）；
主持人；
作者；
評審員；
記錄員。

從不同的角度評審軟件和其相關工作產品並使用檢查表可以提高評審的效果和效率。

6. 評審類型：
非正式評審；informal review；
走查；walkthrough；
技術評審；technical review;
審查；inspection；通常是同行檢查：peer review；

7. 靜態分析的工具支持
靜態分析通常發現的是缺陷而不是失效，靜態分析工具分析程序代碼（控制流和數據流），以及產生如HTML和XML的輸出。

8. 通過靜態分析發現的典型缺陷如下：
引用一個沒有定義值的變量；
模塊和組件之間接口不一致；
從未使用的變量；
不可達代碼或死代碼；
邏輯上的遺漏與錯誤（潛在的無限循環）；
過於復雜的結構；
違背編程規則；
安全漏洞；
代碼和軟件模型的語法錯誤。

第四章 測試設計技術
1. 測試用例由：
一組輸入值、
執行的前置條件、
預期結果、
執行的后置條件

測試條件：
能通過一個或多個測試用例進行驗證的一個條目或事件（比如功能、事務處理、質量特征或結構元素等）

2. 測試規格說明書
包含：測試用例的開發、實現、確定優先級和組織（執行的順序，如果是自動化用例，應該體現在測試腳本中）

3. 黑盒測試技術：
基於規格說明的方法，
特點：
使用正式或非正式的模型來描述需要解決的問題、軟件或其組件等；
根據這些模型，可以系統地導出測試用例。

4. 白盒測試技術：
基於結構的方法，
特點：
根據軟件的結構信息設計測試用例，比如軟件代碼和詳細設計信息；
可以通過已有的測試用例測量軟件的測試覆蓋率，並通過系統化的導出設計用例來提高覆蓋率。

5. 基於經驗的方法：
特點：
用例根據參與人員的經驗和知識來編寫；
測試人員、開發人員、用戶和其他的利益相關者對軟件、軟件使用和環境等方面所掌握的知識作為信息來源之一；
對可能存在的缺陷及其分布情況的了解作為另一個信息來源。

6. 等價類技術：
輸入覆蓋和輸出覆蓋

7. 邊界值分析：
輸入、時間段的范圍、表的邊界等

8. 決策表測試：
識別系統的條件和動作；
優點：生成測試條件的各種組合。
適用於：軟件的行為由一些邏輯決策所決定的情況。

9. 狀態轉換：
通過狀態轉換圖來表示系統的特征。
設計的測試可以覆蓋：一個典型的狀態序列，或覆蓋每個狀態，或執行每個狀態轉換，或執行特定順序的狀態轉換或測試無效的狀態轉換。
適用於：嵌入式和自動化行業，和有特定狀態的業務對象的建模或測試對話框狀態轉換流的系統。

10. 用例測試（Use Case）
用例基於系統最可能使用的情況描述了過程流；
有助於設計用戶/客戶參與的驗收測試。

11. 基於結構的或白盒技術（structure-based testing）
代碼覆蓋：code coverage
判定覆蓋：decision coverage
語句覆蓋：statement coverage

12. 基於結構的測試/白盒測試是根據識別軟件或系統的結構：
組件級別：軟件組件的結構，比如：語句、判定、分支或每個不同的路徑；
集成級別：結構可能是調用樹（模塊調用關系圖）；
系統級別：結構可能是菜單結構、業務過程或web頁面結構。

13. 語句覆蓋和覆蓋率：
評價一個測試用例套件中已經執行的可執行語句的百分比；

14. 判定覆蓋和覆蓋率：
評價在一個測試用例套中已經執行的判定輸出的百分比。

15. 其他的基於結構的技術：
程度更高的基於結構的覆蓋：條件覆蓋和多重條件覆蓋；
覆蓋的概念可以應用於其他的測試級別：在一個測試用例套件中被執行的模塊、組件或類覆蓋的百分比可以分別稱為：模塊覆蓋、組件覆蓋或類的覆蓋。

16. 基於經驗的技術
錯誤推測法：
    缺陷攻擊：列舉可能的錯誤，並設計測試來攻擊這些錯誤；
探索性測試：指依據包含測試目標的測試章程來同時進行測試設計、測試執行、測試記錄和學習，並且在規定時間內進行。

17. 選擇測試技術
測試技術的選擇基於：系統類型、法律法規標准、客戶或合同的需求、風險的級別、風險的類型、測試目標、文檔的可用性、測試員的技能水平、時間和成本預算、開發生命周期、用例模型和以前發現各類缺陷的經驗等。

測試技術可能運用於特定的環境和測試級別，有些可能適用於所有級別。

第五章：測試管理
1. 測試計划受到以下因素影響:
組織的測試方針、測試范圍、測試目標、風險、約束、關鍵程度、可測試性和資源的可用性等。

2. 測試計划是持續性活動，需要在整個生命周期過程和活動中進行。從測試得到的反饋信息可以識別變化的風險，從而對計划做出調整。

3. 入口准則：
測試環境已經准備就緒並可用；
測試工具在測試環境中已經准備就緒；
可測的代碼可用；
測試數據可用。

4. 出口准則：
完整性測量：比如代碼、功能或風險的覆蓋率；
對缺陷密度或可靠性度量的估算；
成本；
遺留風險：如沒有被修改的缺陷或在某些部分測試覆蓋不足；
進度表：如基於交付到市場的時間。

5. 測試估算
基於度量的方法：根據以前或相似項目的度量值或典型的數據進行估算；
基於專家的方法：由任務責任人或專家進行工作量估算。

6. 測試的工作量取決於多種因素：
產品的特點：規格說明或用於測試模型的其他信息（測試依據）的質量、產品的規模、問題域的復雜度、可靠性和安全性的需求和文檔的需求；
開發過程的特點：組織的穩定性、使用的工具、測試過程、參與者的技能水平和時間緊迫程度等；
測試的輸出：缺陷的數量和需要返工的工作量。

7. 測試方法的選擇取決於：
風險、危害和安全、可用資源和人員技能、技術、系統類型、測試對象和相關法規。

8. 典型的測試方法：
分析的方法：如風險測試；
基於模型的方法：如隨機測試利用失效率（如可靠性增長模型）或使用率（允許情況）的統計信息；
系統的方法：如基於失效的方法（錯誤推測和故障攻擊），基於檢查表的方法和基於質量特征的方法；
基於與過程或符合標准的方法：如行業標准規定的方法或各類敏捷的方法；
動態的啟發式的方法：類似探索性測試；
咨詢式的方法：如測試覆蓋率主要根據小組以外的業務領域和/或技術領域專家的建議和指導來推動的；
可重用的方法：如重用已有的測試材料、廣泛的功能回歸測試自動化、標准測試套件等。

9. 測試過程的監控
提供測試活動的反饋信息：
測試用例准備工作完成的百分比；
測試環境准備工作完成的百分比；
測試用例執行情況：執行/未執行的測試用例數、通過/失敗的測試用例數；
缺陷信息：如缺陷密度、發現並修改的缺陷、失效率、回歸結果；
需求、風險或代碼的測試覆蓋率；
測試員對產品的主觀信心；
測試里程碑的日期；
測試成本，包括尋找下一個缺陷或執行下一輪測試所需成本與收益的比較。

10. 測試報告：
內容：
測試周期內發生了什么？比如：達到出口准則的日期；
通過分析和度量為下一步活動提供建議或做出決策：如：對遺留缺陷的評估、是否繼續測試的經濟效益、未解決的風險以及被測試軟件的置信度等。

11. 在測試級別的過程中和完成時度量信息用來評估：
該測試級別的測試目標實現的充分性；
采用的測試方法的適當性；
針對測試目標的測試的有效性。

12. 測試控制措施：
如：
基於監控信息來做出決策；
如果一個已識別的風險發生，重新確定測試優先級；
根據測試環境可用性，改變測試的時間進度表；
設定入口准則：如規定缺陷修復后需開放在測試后才能發布新版本。

13. 配置管理可以確保：
測試件的所有相關項都已經被識別，版本受控，相互之間有關聯以及和開發項（被測對象）之間有關聯的變更可跟蹤；
在測試文檔中，所有被標識的文檔和軟件能被清晰明確的引用。

14. 風險級別
風險級別取決於發生不確定事件的可能性和產生的影響。

15. 項目風險
圍繞項目按目標交付的能力的一系列風險。如：
組織因素：技能、培訓和人員的不足；個人問題；政策因素等；
技術因素：需求定義錯誤、環境沒有准備好、工具造成的延遲、低質量的設計、編碼、配置、測試等；
供應商因素：第三方、合同問題等。

16. 產品風險
在軟件或系統中的潛在失效部分（即將來可能發生不利事件或危險），對產品質量的風險。如：
故障頻發、沒有實現既定的功能、劣質的軟件特性等。

17. 事件管理
實際結果和預期結果之間的差異需要作為一個事件被記錄，必須進行調查以確定是否是缺陷。

第六章：軟件測試工具
1. 測試工具的類型
配置管理工具configuration management tool
覆蓋率工具coverage tool
調試工具debugging tool
動態分析工具dynamic analyzsis tool
時間管理工具incident management tool
負載測試工具load testing tool
建模工具modeling tool
監控工具monitoring tool
性能測試工具performance tool
需求管理工具requiement management tool
評審工具review tool
安全性工具security tool
壓力測試工具stress testing tool
測試比較器test comparator
測試數據准備工具test data preparation tool
測試設計工具test design tool
測試用具test harness
測試執行工具test execution tool
測試管理工具test management tool
單元測試框架工具unit test framework tool

2. 測試工具的作用：
直接用於測試的工具：如測試執行、測試數據生成、結果比對等；
測試過程管理工具：如測試管理、缺陷管理、配置管理；
用於觀測的工具或探索：如監控應用程序文件活動的工具；
任何對測試有幫助的工具。

3. 測試管理的工具支持：
測試管理工具：QC、禪道；
需求管理工具：QC；
事件管理工具（缺陷跟蹤工具）：QC、bugzilla、Jira；
配置管理工具：CC。

4. 靜態測試的工具支持：
評審工具：taskfree；
靜態分析工具：？
建模工具：ERWin、UML；

5. 測試規格說明的工具支持：
測試設計工具：正交用例設計工具、PICT（組合測試）;
測試數據准備工具：？

6. 測試執行和記錄工具：
測試執行工具：RobotFramework、QTP;
測試用具/單元測試框架工具：JUnit、TestNG；
測試比較器：Notepad++-Compare、diff；
覆蓋率測量工具:EclEmma：
安全性測試工具：？

7. 性能和監控工具：
動態分析工具：？
性能測試/負載測試/壓力測試工具：JMeter、LoadRunner；
監控工具：IPtraf；sysstat；

8. 特定應用領域的測試工具：
數據質量評估；？
可用性工具：？

9. 有效使用工具：
潛在收益：
    減少重復性工作：如自動化回歸測試；
    更好的一致性和可重復性：如工具按相同的順序和頻率執行測試；
    客觀的評估：如靜態測量、覆蓋率；
存在的風險：
    對工具抱有不切實際的希望；
    低估首次引入工具的成本、時間、工作量；
    低估從工具中獲得較大和持續性收益需要付出的時間和工作量；
    低估對工具生成的結果進行維護的工作量；
    對工具過分依賴；
    忽視了多個重要工具之間的關聯和互操作性：如：需求管理、時間管理、版本控制和其他從不同供應商獲得的工具；
    工具供應商：停止工具維護、支持、升級和缺陷修復不力；
    開源/免費工具項目終止的風險；
    其他不可預知的：如不能支持新平台。
    
10. 一些工具類型的特殊考慮
測試執行工具：
    錄制：並不穩定；
    數據驅動：測試輸入與測試用例分離；隨機數；
    關鍵字驅動：關鍵字和測試數據；
    需要腳本開發；
    需要儲存預期結果進行比較。
靜態分析工具：
    產生大量警告信息需要過濾。
測試管理工具：
    需要與其他工具和表格有接口，以便產生符合組織所需格式的有用信息。
    
11. 組織內引入工具考慮的關鍵點：
評價組織的成熟度、引入工具的優缺點、認識引入工具能改善過程的可能性；
根據清晰的需求和客觀的准則進行評估；
概念驗證，在評估階段確認在現有情況下使用工具對被測軟件是否有足夠效果，或使用工具現有的基礎設施需要怎樣改變；
評估供應商；
收集內部需求，評估需求時考慮自動化測試技能；
估算成本-收益比。

12. 引入工具從試點項目開始：
對工具有更多的認識；
評估工具與現有過程和實踐的配合程度，確定哪些方面需要修改；
定義一套標准的方法來使用、管理、儲存和維護工具及測試資產；
評估在付出合理的成本后能否得到預期收益。

13. 成功的因素：
逐步推廣；
調整並改進過程來配合工具的使用；
為新使用者提供培訓；
定義使用指南；
收集工具使用情況；
監控工具的使用和收益情況；
為測試團隊使用工具提供支持；
在所有團隊內收集經驗和教訓。