ISTQB學(xué)習(xí)大綱（3）
第三章 靜態(tài)技術(shù)1. 靜態(tài)測(cè)試技術(shù)：
通過手工檢查（評(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ī)格說明等等。
3. 評(píng)審過程：
評(píng)審過程的正式性和以下因素有關(guān)：開發(fā)過程的成熟度、法律法規(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)、過程和文檔。
3）個(gè)人準(zhǔn)備階段：
先行評(píng)審文檔，為評(píng)審會(huì)議做準(zhǔn)備；
標(biāo)注可能的缺陷、問題和建議。
4）檢查/評(píng)價(jià)/記錄結(jié)果（評(píng)審會(huì)議階段）：
討論和記錄，并留下文檔化的結(jié)果或會(huì)議紀(jì)要（針對(duì)更正式的評(píng)審類型）；
標(biāo)注缺陷、提出處理缺陷的建議、對(duì)缺陷做出決策；
在任何形式的會(huì)議期間或跟蹤任何類型的電子通信期間檢查/評(píng)價(jià)和記錄問題。
5）返工階段：
修改發(fā)現(xiàn)的缺陷（通常由作者進(jìn)行）；
記錄缺陷跟蹤的狀態(tài)（在正式評(píng)審中）；
6）跟蹤結(jié)果階段：
檢查缺陷是否已得到解決；
收集度量數(shù)據(jù)；
核對(duì)出口準(zhǔn)則（針對(duì)更正式的評(píng)審類型）。
5. 角色和職責(zé)
經(jīng)理（管理者）；
主持人；
作者；
評(píng)審員；
記錄員。
從不同的角度評(píng)審軟件和其相關(guān)工作產(chǎn)品并使用檢查表可以提高評(píng)審的效果和效率。
6. 評(píng)審類型：
非正式評(píng)審；informal review；
走查；walkthrough；
技術(shù)評(píng)審；technical review;
審查；inspection；通常是同行檢查：peer review；
7. 靜態(tài)分析的工具支持
靜態(tài)分析通常發(fā)現(xiàn)的是缺陷而不是失效，靜態(tài)分析工具分析程序代碼（控制流和數(shù)據(jù)流），以及產(chǎn)生如HTML和XML的輸出。
8. 通過靜態(tài)分析發(fā)現(xiàn)的典型缺陷如下：
引用一個(gè)沒有定義值的變量；
模塊和組件之間接口不一致；
從未使用的變量；
不可達(dá)代碼或死代碼；
邏輯上的遺漏與錯(cuò)誤（潛在的無限循環(huán)）；
過于復(fù)雜的結(jié)構(gòu)；
違背編程規(guī)則；
安全漏洞；
代碼和軟件模型的語法錯(cuò)誤。
頁:
[1]