ISTQB學(xué)習(xí)大綱（2）
第二章：軟件生命周期中的測(cè)試1. 軟件開發(fā)模型：
V模型（順序開發(fā)模型）；
迭代-增量開發(fā)模型：原型開發(fā)、快速應(yīng)用開發(fā)、統(tǒng)一軟件開發(fā)過(guò)程、敏捷開發(fā)模型等；
2. 每個(gè)測(cè)試級(jí)別都需要明確的內(nèi)容：
測(cè)試的總體目標(biāo)，
測(cè)試用例設(shè)置需要參考的產(chǎn)品（即測(cè)試的依據(jù)），
測(cè)試的對(duì)象，
發(fā)現(xiàn)的典型缺陷和失效，
對(duì)測(cè)試用具的需要，
測(cè)試工具的支持，
專門的方法和職責(zé)等。
3. 組件測(cè)試/單元測(cè)試
依據(jù)：組件需求說(shuō)明、詳細(xì)設(shè)計(jì)文檔、代碼。
典型測(cè)試對(duì)象：組件、程序、數(shù)據(jù)轉(zhuǎn)換/移植程序、數(shù)據(jù)庫(kù)模型。
樁、驅(qū)動(dòng)器和模擬器：底層打樁，中間驅(qū)動(dòng)，上層行為模擬
可能包括：功能測(cè)試、特定的非功能特征測(cè)試，如資源行為測(cè)試（如內(nèi)存泄漏）、健壯性測(cè)試和結(jié)構(gòu)測(cè)試（如分支覆蓋）
4. 集成測(cè)試
依據(jù)：軟件和系統(tǒng)設(shè)計(jì)文檔、系統(tǒng)架構(gòu)、工作流、用例；
典型測(cè)試對(duì)象：子系統(tǒng)、數(shù)據(jù)庫(kù)實(shí)現(xiàn)、基礎(chǔ)結(jié)構(gòu)、接口、系統(tǒng)配置和配置數(shù)據(jù)。
5. 集成級(jí)別不同：
組件集成測(cè)試對(duì)不同的軟件組織之間的相互作用進(jìn)行測(cè)試，一般在組件測(cè)試之后進(jìn)行；
系統(tǒng)集成測(cè)試對(duì)不同系統(tǒng)或軟硬件之間的相互作用進(jìn)行測(cè)試，一般在系統(tǒng)測(cè)試之后進(jìn)行。
6. 系統(tǒng)測(cè)試：
依據(jù)：系統(tǒng)和軟件需求規(guī)格說(shuō)明、用例、功能規(guī)格說(shuō)明、風(fēng)險(xiǎn)分析報(bào)告；
典型測(cè)試對(duì)象：系統(tǒng)、用戶手冊(cè)和操作手冊(cè)，系統(tǒng)配置和配置數(shù)據(jù)。
通常由獨(dú)立的團(tuán)隊(duì)進(jìn)行。
7. 驗(yàn)收測(cè)試
依據(jù)：用戶需求、系統(tǒng)需求、用例、業(yè)務(wù)流程、風(fēng)險(xiǎn)分析報(bào)告；
典型測(cè)試對(duì)象：基于完全集成系統(tǒng)的業(yè)務(wù)流程、操作與維護(hù)流程、用戶處理過(guò)程、結(jié)構(gòu)、報(bào)告、配置數(shù)據(jù)。
通常由使用系統(tǒng)的用戶或客戶來(lái)進(jìn)行。
8. 驗(yàn)收測(cè)試的典型類型：
用戶驗(yàn)收測(cè)試：由商業(yè)用戶驗(yàn)證系統(tǒng)可用性；
操作（驗(yàn)收）測(cè)試：由系統(tǒng)管理員來(lái)進(jìn)行，包括：系統(tǒng)備份/恢復(fù)測(cè)試、災(zāi)難恢復(fù)測(cè)試、用戶管理測(cè)試、維護(hù)任務(wù)測(cè)試、數(shù)據(jù)加載和移植活動(dòng)、安全漏洞階段性檢查；
合同和法規(guī)性驗(yàn)收測(cè)試：根據(jù)合同規(guī)定、根據(jù)必須遵守的法律法規(guī)進(jìn)行測(cè)試；
Alpha和Beta測(cè)試：
alpha測(cè)試在開發(fā)組織現(xiàn)場(chǎng)進(jìn)行，但由潛在用戶測(cè)試；
beta測(cè)試或?qū)嵉販y(cè)試，在客戶現(xiàn)場(chǎng)又客戶執(zhí)行；
也可稱為工廠驗(yàn)收測(cè)試和現(xiàn)場(chǎng)驗(yàn)收測(cè)試。
9. 從測(cè)試的級(jí)別劃分：
組件測(cè)試/單元測(cè)試、
集成測(cè)試、
系統(tǒng)測(cè)試、
驗(yàn)收測(cè)試
10. 根據(jù)特定的目標(biāo)或測(cè)試原因：
功能測(cè)試：主要考慮軟件的外部表現(xiàn)行為（黑盒）；可以包括：
安全性測(cè)試：系統(tǒng)和數(shù)據(jù)是否能抵御外部惡意威脅；
互操作性測(cè)試：與其他組件或系統(tǒng)交互能力的測(cè)試；
非功能測(cè)試：測(cè)試系統(tǒng)運(yùn)行的表現(xiàn)如何；
包括但不限于：
性能測(cè)試
負(fù)載測(cè)試
壓力測(cè)試
可用性測(cè)試
可維護(hù)性測(cè)試
可靠性測(cè)試
可移植性測(cè)試
11. 軟件結(jié)構(gòu)/架構(gòu)測(cè)試（結(jié)構(gòu)測(cè)試）：可以在任何測(cè)試級(jí)別使用；最好在進(jìn)行基于規(guī)格說(shuō)明測(cè)試之后使用，以便通過(guò)評(píng)估結(jié)構(gòu)類型的覆蓋來(lái)測(cè)量測(cè)試的完整性；
12. 確認(rèn)：
當(dāng)發(fā)現(xiàn)和修改了一個(gè)缺陷后，應(yīng)進(jìn)行再測(cè)試以確定已經(jīng)成功的修改了原來(lái)的缺陷，稱之為確認(rèn)。
13. 維護(hù)測(cè)試
在現(xiàn)有的運(yùn)行系統(tǒng)上進(jìn)行，且一旦對(duì)軟件或系統(tǒng)進(jìn)行修改（功能增加、修正和應(yīng)急變更、環(huán)境的變化（如升級(jí)、漏洞））、移植（平臺(tái)遷移）或退役處理（數(shù)據(jù)移植、存檔測(cè)試）時(shí)，就需要進(jìn)行維護(hù)測(cè)試。
維護(hù)測(cè)試的范圍取決于變更的風(fēng)險(xiǎn)、現(xiàn)有系統(tǒng)的規(guī)模和變更的大小。
第三章 靜態(tài)技術(shù)
1. 靜態(tài)測(cè)試技術(shù)：
通過(guò)手工檢查（評(píng)審）或自動(dòng)化分析（靜態(tài)分析）的方式對(duì)代碼或者其他的項(xiàng)目文檔進(jìn)行檢查而不需要執(zhí)行代碼。
2. 評(píng)審：
更容易發(fā)現(xiàn)：與標(biāo)準(zhǔn)之間的偏差、需求內(nèi)的錯(cuò)誤（需求遺漏）、設(shè)計(jì)錯(cuò)誤、可維護(hù)性不足和錯(cuò)誤的接口規(guī)格說(shuō)明等等。
3. 評(píng)審過(guò)程：
評(píng)審過(guò)程的正式性和以下因素有關(guān)：開發(fā)過(guò)程的成熟度、法律法規(guī)方面的要求或?qū)徍烁櫟男枰?br /> 評(píng)審的目標(biāo)：發(fā)現(xiàn)缺陷、增加理解、培訓(xùn)測(cè)試員和團(tuán)隊(duì)新成員或?qū)τ懻摵蜎Q定達(dá)成共識(shí)等。
4. 正式評(píng)審的階段：
1）計(jì)劃階段：
定義評(píng)審標(biāo)準(zhǔn)，
選擇人員，
分配角色，
為更加正式的評(píng)審類型（比如審查）制定入口和出口準(zhǔn)則，
選擇需要進(jìn)行評(píng)審的文檔內(nèi)容，
核對(duì)入口準(zhǔn)則（針對(duì)更正式的評(píng)審類型）。
2）預(yù)備會(huì)階段：
分發(fā)文檔，
向評(píng)審參與者解釋評(píng)審的目標(biāo)、過(guò)程和文檔。
3）個(gè)人準(zhǔn)備階段：
先行評(píng)審文檔，為評(píng)審會(huì)議做準(zhǔn)備；
標(biāo)注可能的缺陷、問(wèn)題和建議。
4）檢查/評(píng)價(jià)/記錄結(jié)果（評(píng)審會(huì)議階段）：
討論和記錄，并留下文檔化的結(jié)果或會(huì)議紀(jì)要（針對(duì)更正式的評(píng)審類型）；
標(biāo)注缺陷、提出處理缺陷的建議、對(duì)缺陷做出決策；
在任何形式的會(huì)議期間或跟蹤任何類型的電子通信期間檢查/評(píng)價(jià)和記錄問(wèn)題。
5）返工階段：
修改發(fā)現(xiàn)的缺陷（通常由作者進(jìn)行）；
記錄缺陷跟蹤的狀態(tài)（在正式評(píng)審中）；
6）跟蹤結(jié)果階段：
檢查缺陷是否已得到解決；
收集度量數(shù)據(jù)；
核對(duì)出口準(zhǔn)則（針對(duì)更正式的評(píng)審）
頁(yè):
[1]