測試基礎(chǔ)靜態(tài)測試解析課件

1測試基礎(chǔ)–靜態(tài)測試1測試基礎(chǔ)–靜態(tài)測試測試基礎(chǔ)–靜態(tài)測試概述評審代碼檢查2測試基礎(chǔ)–靜態(tài)測試概述2測試基礎(chǔ)–靜態(tài)測試靜態(tài)測試該方法是指在不真正運行被測試程序的情況下檢查程序的運行情況，只對被測對象(設(shè)計或代碼)進(jìn)行特性分析。因此，靜態(tài)測試常稱為“分析”，靜態(tài)分析是對被測對象進(jìn)行特性分析的一些方法的總稱。主要特征不動態(tài)運行程序；充分發(fā)揮人的思維優(yōu)勢；易開展，不需特別條件，但可能非常耗時；對測試人員要求較高，要有編程經(jīng)驗，需要有知識和經(jīng)驗的積累，能發(fā)現(xiàn)問題本身而非征兆。3測試基礎(chǔ)–靜態(tài)測試靜態(tài)測試3測試基礎(chǔ)–靜態(tài)測試為什么要靜態(tài)測試因軟件的復(fù)雜性，可能導(dǎo)致軟件結(jié)構(gòu)不夠合理、混亂，代碼編寫不夠規(guī)范，內(nèi)部存在一些不易察覺的錯等，使軟件運行出錯，維護(hù)不便。靜態(tài)測試內(nèi)容主要包括：各階段的文檔評審、代碼檢查、代碼度量等。靜態(tài)測試可由人工進(jìn)行，也可借助軟件工具自動進(jìn)行。

可以做靜態(tài)分析的工具很多，出名的有LOGICSCOPE，C++

TEST，LDRA

TESTBED，PRQA

C/C++，MACABE

IQ，以及Rational的Purify、Quantify和PureCoverage等

4測試基礎(chǔ)–靜態(tài)測試為什么要靜態(tài)測試4測試基礎(chǔ)–靜態(tài)測試概述評審代碼檢查5測試基礎(chǔ)–靜態(tài)測試概述5靜態(tài)測試評審評審是對所有人工靜態(tài)分析和具體文檔檢查技術(shù)的通稱。評審對象：開發(fā)項目中所有文檔及項目外有價值的文檔。

如：合同、需求定義、設(shè)計規(guī)格說明、程序代碼、測試計劃和手冊等。評審是一種保證質(zhì)量的方法評審的積極作用可降低消除缺陷的成本可縮短開發(fā)時間可減少動態(tài)測試時間和成本可減少系統(tǒng)安裝后的變更申請降低系統(tǒng)運行故障率檢查團(tuán)對活動，改進(jìn)團(tuán)隊成員的工作方法6靜態(tài)測試評審6靜態(tài)測試評審潛在的問題注意不要使作者感到嚴(yán)格檢查是針對他人而非他提交的文檔。評審的成本和收益評審的成本大概占整個開發(fā)預(yù)算的10%~15%,包括評審過程、評審分析和過程改進(jìn)的工作量。估計節(jié)約的成本約為14%~25%。（參見：Bush

M.“SoftwareQuality:TheuseofformalinspectionsattheJetPropulsionLaboratory”，Proceedings

of

the

12th

ICSE,IEEE

1990,pp

196-199.）如評審有效，應(yīng)能發(fā)現(xiàn)70%以上的文檔缺陷。（參見：Gilb，T.，Graham,D.；Software

Inspections，Addison-wesley,1996）7靜態(tài)測試評審潛在的問題7靜態(tài)測試能促使評審成功的因素（[IEEE

1028]建議）每次評審都事先定于一個明確的目標(biāo)；根據(jù)每個人的知識和技能水平選擇合適的評審參與者。8靜態(tài)測試能促使評審成功的因素（[IEEE1028]建議）8靜態(tài)測試通用評審過程（參考：[IEEE

1028]）評審活動分6個步驟：計劃、概述、準(zhǔn)備、檢查（評審會議）、返工和跟蹤。計劃要評審的文檔；評審技術(shù)；估算評審工作量；評審檢查點；組建評審團(tuán)隊；確保文檔處于一個可評審狀態(tài)；會議的時間和地點（如有的話）等。概述（開工會）為參加評審的人提供所有必需信息。準(zhǔn)備評審人必須各自為評審會議做準(zhǔn)備。9靜態(tài)測試通用評審過程（參考：[IEEE1028]）9靜態(tài)測試檢查（評審會議）會議應(yīng)有主持人。目的除了發(fā)現(xiàn)缺陷外，還包括判斷評審對象是否滿足需求以及是否符合標(biāo)準(zhǔn)。評審會議的一些通用準(zhǔn)則：1）評審會議的時間限制在2小時內(nèi)；2）如有評審人缺席或準(zhǔn)備不充分，主持人有權(quán)取消或中止會議；3）檢查對象是被提交的文檔，而非作者；評審人必須注意他們的言語及表達(dá)方式作者不應(yīng)為自己或文檔辯護(hù)4）主持人不應(yīng)同時作為評審人；10靜態(tài)測試檢查（評審會議）10靜態(tài)測試檢查（評審會議）（續(xù)）5）不討論常見的風(fēng)格問題（方針之外的問題）；6）開發(fā)方案和對應(yīng)的討論不是評審團(tuán)隊的任務(wù)；7）每個評審人員必須有機(jī)會充分表達(dá)他們的論點；8）會議紀(jì)要必須完整表達(dá)評審人的意見；9）問題不應(yīng)以命令的形式寫給作者；10）問題必須劃分為不同的權(quán)重：嚴(yán)重缺陷、重要缺陷、一般缺陷、好的；11）評審團(tuán)隊?wèi)?yīng)對評審對象給出最后意見：

接受（無需修改）

有條件接受（需修改，但不需進(jìn)一步評審）

不接受（需進(jìn)一步評審或其他的檢查）11靜態(tài)測試檢查（評審會議）（續(xù)）11靜態(tài)測試檢查（評審會議）（續(xù)）12）要有會議紀(jì)要及總結(jié)包括會議中討論的問題或發(fā)現(xiàn)問題的列表，評審總結(jié)報告等。返工經(jīng)理決定接受評審團(tuán)隊意見修正缺陷，或選擇另外的方法（經(jīng)理必須對此全權(quán)負(fù)責(zé)）跟蹤專人跟蹤缺陷的修改。12靜態(tài)測試檢查（評審會議）（續(xù)）12靜態(tài)測試評審角色和職責(zé)經(jīng)理

確保文檔、必需的資源可用，同時選擇評審人；

經(jīng)理不一定得是管理層人員（導(dǎo)致大家“人心恍惚”）主持人

管理評審有關(guān)的工作：計劃、準(zhǔn)備并保證評審有序進(jìn)行且滿足它的目標(biāo)，收集評審數(shù)據(jù)、發(fā)布評審報告等。作者

文檔的創(chuàng)建者，如為多人，應(yīng)是主要負(fù)責(zé)人。

不要把針對文檔的問題看作是對其人的批評，作者必須明白評審只是用來幫助改進(jìn)產(chǎn)品。(接下頁)13靜態(tài)測試評審角色和職責(zé)13靜態(tài)測試角色和職責(zé)評審人

通常最多5個。他們應(yīng)能識別并描述評審對象中存在的問題。

為保證有效的覆蓋率，可給評審人分配制定的評審主題。記錄員

記錄所有的發(fā)現(xiàn)：問題、采取的措施、決定和建議等。文字應(yīng)簡短和準(zhǔn)確。

最好由文檔作者來擔(dān)當(dāng)。14靜態(tài)測試角色和職責(zé)14靜態(tài)測試評審失敗的可能原因：需要的人沒空或不具備必須的資格和技術(shù)技能。管理層在資源計劃時不準(zhǔn)確的估計準(zhǔn)備不足。文檔不足缺少管理層支持(在下述文獻(xiàn)中詳細(xì)描述了解決這些問題的方法：Freedman,D.P.,Weinberg,G.M.:Handbook

of

Walkthroughs,Inspections,and

Technical

Reviews:Evaluating

Programs,Projects,and

Products,3rd

ed.,Dorset

House,1990)15靜態(tài)測試評審失敗的可能原因：15測試基礎(chǔ)–靜態(tài)測試概述評審代碼檢查16測試基礎(chǔ)–靜態(tài)測試概述16靜態(tài)測試代碼檢查主要檢查代碼和設(shè)計的一致性，代碼對標(biāo)準(zhǔn)的遵循、可讀性，代碼的邏輯表達(dá)的正確性，代碼結(jié)構(gòu)的合理性等方面；以期發(fā)現(xiàn)違背編程標(biāo)準(zhǔn)或編程風(fēng)格問題，程序中不安全、不明確和模糊部分，程序中不可移植部分等。代碼檢查在編譯和動態(tài)測試前進(jìn)行，在檢查前，應(yīng)準(zhǔn)備好需求描述文檔、程序設(shè)計文檔、程序的源代碼清單、代碼編碼標(biāo)準(zhǔn)和代碼缺陷檢查表等。

代碼檢查包括：桌面檢查、代碼審查、代碼走查等。17靜態(tài)測試代碼檢查1718靜態(tài)測試①桌面檢查（DeskChecking）由程序員自查。程序員在程序通過編譯之后，進(jìn)行單元測試設(shè)計之前，對源程序代碼進(jìn)行分析，檢驗，并補充相關(guān)文檔。檢查項目有：檢查變量的交叉引用表重點是未說明的變量和違反了類型規(guī)定的變量；逐個檢查變量的引用、變量的使用序列；臨時變量在某條路徑上的重寫情況；局部變量、全局變量與特權(quán)變量的使用；18靜態(tài)測試①桌面檢查（DeskChecking）19靜態(tài)測試-桌面檢查檢查標(biāo)號的交叉引用表檢查驗證所有標(biāo)號的正確性：命名是否正確；轉(zhuǎn)向指定位置的標(biāo)號是否正確。檢查子程序、宏、函數(shù)驗證每次調(diào)用與被調(diào)用位置是否正確；被調(diào)用的子程序、宏、函數(shù)是否存在；檢驗調(diào)用序列中調(diào)用方式與參數(shù)順序、個數(shù)、類型上的一致性。等值性檢查檢查全部等價變量的類型的一致性，解釋所包含的類型差異。19靜態(tài)測試-桌面檢查檢查標(biāo)號的交叉引用表20靜態(tài)測試常量檢查確認(rèn)每個常量的取值和數(shù)制、數(shù)據(jù)類型；檢查常量每次引用同它的取值、數(shù)制和類型的一致性；標(biāo)準(zhǔn)檢查檢查違反標(biāo)準(zhǔn)的問題。比較控制流比較由程序員設(shè)計的控制流圖和由實際程序生成的控制流圖，尋找和解釋每個差異，修改文檔和校正錯誤。20靜態(tài)測試常量檢查21靜態(tài)測試選擇、激活路徑在程序員設(shè)計的控制流圖上選擇路徑，再到實際的控制流圖上激活這條路徑。如果選擇的路徑在實際控制流圖上不能激活，則源程序可能有錯。用這種方法激活的路徑集合應(yīng)保證源程序模塊的每行代碼都被檢查，即桌前檢查應(yīng)至少是語句覆蓋。風(fēng)格檢查檢查在程序設(shè)計風(fēng)格方面發(fā)現(xiàn)的問題。對照程序的規(guī)格說明，詳細(xì)閱讀源代碼程序員對照程序的規(guī)格說明書、規(guī)定的算法和程序設(shè)計語言的語法規(guī)則，仔細(xì)地閱讀源代碼，逐字逐句進(jìn)行分析和思考，比較實際的代碼和期望的代碼，從它們的差異中發(fā)現(xiàn)程序的問題和錯誤。21靜態(tài)測試選擇、激活路徑22靜態(tài)測試補充文檔桌前檢查的文檔是一種過渡性的文檔，不是公開的正式文檔。通過編寫文檔，也是對程序的一種下意識的檢查和測試，可以幫助程序員發(fā)現(xiàn)和抓住更多的錯誤。這種桌前檢查，由于程序員熟悉自己的程序和自身的程序設(shè)計風(fēng)格，可以節(jié)省很多的檢查時間，但應(yīng)避免主觀片面性。22靜態(tài)測試補充文檔23靜態(tài)測試②代碼審查（CodeReadingReview）代碼審查是由若干程序員和測試員組成一個會審小組，通過閱讀、討論和爭議，對程序進(jìn)行靜態(tài)分析的過程。代碼審查分兩步：第一步，小組負(fù)責(zé)人提前把設(shè)計規(guī)格說明書、控制流程圖、程序文本及有關(guān)要求、規(guī)范等分發(fā)給小組成員，作為評審的依據(jù)。小組成員在充分閱讀這些材料之后，進(jìn)入審查的第二步。第二步：召開程序?qū)彶闀Ｔ跁?，首先由程序員逐句講解程序的邏輯。在此過程中，程序員或其他小組成員可以提出問題，展開討論，審查錯誤是否存在。實踐表明，程序員在講解過程中能發(fā)現(xiàn)許多原來自己沒有發(fā)現(xiàn)的錯誤，而討論和爭議則促進(jìn)了問題的暴露。23靜態(tài)測試②代碼審查（CodeReadingRevi24靜態(tài)測試在會前，應(yīng)當(dāng)給會審小組每個成員準(zhǔn)備一份常見錯誤的清單，把以往所有可能發(fā)生的常見錯誤羅列出來，供與會者對照檢查，以提高會審的實效。這個常見錯誤清單也叫做檢查表，它把程序中可能發(fā)生的各種錯誤進(jìn)行分類，對每一類列舉出盡可能多的典型錯誤，然后把它們制成表格，供在會審時使用。下面列出了代碼檢查應(yīng)查找的問題24靜態(tài)測試在會前，應(yīng)當(dāng)給會審小組每個成員準(zhǔn)備一份常見錯誤的25靜態(tài)測試源代碼格式：是否符合編程標(biāo)準(zhǔn)或規(guī)范？程序語句的使用數(shù)據(jù)引用錯誤數(shù)據(jù)聲明錯誤計算錯誤比較錯誤接口錯誤控制流程錯誤輸入輸出錯誤邏輯和性能維護(hù)性和可靠性25靜態(tài)測試源代碼格式：是否符合編程標(biāo)準(zhǔn)或規(guī)范？26靜態(tài)測試③走查（Walkthroughs）走查與代碼會審基本相同，其過程分為兩步。第一步也把材料先發(fā)給走查小組每個成員，讓他們認(rèn)真研究程序，然后再開會。開會的程序與代碼會審不同，不是簡單地讀程序和對照錯誤檢查表進(jìn)行檢查，而是讓與會者“充當(dāng)”計算機(jī)。即首先由測試組成員為被測程序準(zhǔn)備一批有代表性的測試用例，提交給走查小組。走查小組開會，集體扮演計算機(jī)角色，讓測試用例沿程序的邏輯運行一遍，隨時記錄程序的蹤跡，供分析和討論用。第二步人們借助于測試用例的媒介作用，對程序的邏輯和功能提出各種疑問，結(jié)合問題開展熱烈的討論和爭議，能夠發(fā)現(xiàn)更多的問題。走查時注意時限（避免跑題，不針對某問題無休止討論）和避免現(xiàn)場修改。26靜態(tài)測試③走查（Walkthroughs）27測試基礎(chǔ)–靜態(tài)測試1測試基礎(chǔ)–靜態(tài)測試測試基礎(chǔ)–靜態(tài)測試概述評審代碼檢查28測試基礎(chǔ)–靜態(tài)測試概述2測試基礎(chǔ)–靜態(tài)測試靜態(tài)測試該方法是指在不真正運行被測試程序的情況下檢查程序的運行情況，只對被測對象(設(shè)計或代碼)進(jìn)行特性分析。因此，靜態(tài)測試常稱為“分析”，靜態(tài)分析是對被測對象進(jìn)行特性分析的一些方法的總稱。主要特征不動態(tài)運行程序；充分發(fā)揮人的思維優(yōu)勢；易開展，不需特別條件，但可能非常耗時；對測試人員要求較高，要有編程經(jīng)驗，需要有知識和經(jīng)驗的積累，能發(fā)現(xiàn)問題本身而非征兆。29測試基礎(chǔ)–靜態(tài)測試靜態(tài)測試3測試基礎(chǔ)–靜態(tài)測試為什么要靜態(tài)測試因軟件的復(fù)雜性，可能導(dǎo)致軟件結(jié)構(gòu)不夠合理、混亂，代碼編寫不夠規(guī)范，內(nèi)部存在一些不易察覺的錯等，使軟件運行出錯，維護(hù)不便。靜態(tài)測試內(nèi)容主要包括：各階段的文檔評審、代碼檢查、代碼度量等。靜態(tài)測試可由人工進(jìn)行，也可借助軟件工具自動進(jìn)行。

可以做靜態(tài)分析的工具很多，出名的有LOGICSCOPE，C++

TEST，LDRA

TESTBED，PRQA

C/C++，MACABE

IQ，以及Rational的Purify、Quantify和PureCoverage等

30測試基礎(chǔ)–靜態(tài)測試為什么要靜態(tài)測試4測試基礎(chǔ)–靜態(tài)測試概述評審代碼檢查31測試基礎(chǔ)–靜態(tài)測試概述5靜態(tài)測試評審評審是對所有人工靜態(tài)分析和具體文檔檢查技術(shù)的通稱。評審對象：開發(fā)項目中所有文檔及項目外有價值的文檔。

如：合同、需求定義、設(shè)計規(guī)格說明、程序代碼、測試計劃和手冊等。評審是一種保證質(zhì)量的方法評審的積極作用可降低消除缺陷的成本可縮短開發(fā)時間可減少動態(tài)測試時間和成本可減少系統(tǒng)安裝后的變更申請降低系統(tǒng)運行故障率檢查團(tuán)對活動，改進(jìn)團(tuán)隊成員的工作方法32靜態(tài)測試評審6靜態(tài)測試評審潛在的問題注意不要使作者感到嚴(yán)格檢查是針對他人而非他提交的文檔。評審的成本和收益評審的成本大概占整個開發(fā)預(yù)算的10%~15%,包括評審過程、評審分析和過程改進(jìn)的工作量。估計節(jié)約的成本約為14%~25%。（參見：Bush

M.“SoftwareQuality:TheuseofformalinspectionsattheJetPropulsionLaboratory”，Proceedings

of

the

12th

ICSE,IEEE

1990,pp

196-199.）如評審有效，應(yīng)能發(fā)現(xiàn)70%以上的文檔缺陷。（參見：Gilb，T.，Graham,D.；Software

Inspections，Addison-wesley,1996）33靜態(tài)測試評審潛在的問題7靜態(tài)測試能促使評審成功的因素（[IEEE

1028]建議）每次評審都事先定于一個明確的目標(biāo)；根據(jù)每個人的知識和技能水平選擇合適的評審參與者。34靜態(tài)測試能促使評審成功的因素（[IEEE1028]建議）8靜態(tài)測試通用評審過程（參考：[IEEE

1028]）評審活動分6個步驟：計劃、概述、準(zhǔn)備、檢查（評審會議）、返工和跟蹤。計劃要評審的文檔；評審技術(shù)；估算評審工作量；評審檢查點；組建評審團(tuán)隊；確保文檔處于一個可評審狀態(tài)；會議的時間和地點（如有的話）等。概述（開工會）為參加評審的人提供所有必需信息。準(zhǔn)備評審人必須各自為評審會議做準(zhǔn)備。35靜態(tài)測試通用評審過程（參考：[IEEE1028]）9靜態(tài)測試檢查（評審會議）會議應(yīng)有主持人。目的除了發(fā)現(xiàn)缺陷外，還包括判斷評審對象是否滿足需求以及是否符合標(biāo)準(zhǔn)。評審會議的一些通用準(zhǔn)則：1）評審會議的時間限制在2小時內(nèi)；2）如有評審人缺席或準(zhǔn)備不充分，主持人有權(quán)取消或中止會議；3）檢查對象是被提交的文檔，而非作者；評審人必須注意他們的言語及表達(dá)方式作者不應(yīng)為自己或文檔辯護(hù)4）主持人不應(yīng)同時作為評審人；36靜態(tài)測試檢查（評審會議）10靜態(tài)測試檢查（評審會議）（續(xù)）5）不討論常見的風(fēng)格問題（方針之外的問題）；6）開發(fā)方案和對應(yīng)的討論不是評審團(tuán)隊的任務(wù)；7）每個評審人員必須有機(jī)會充分表達(dá)他們的論點；8）會議紀(jì)要必須完整表達(dá)評審人的意見；9）問題不應(yīng)以命令的形式寫給作者；10）問題必須劃分為不同的權(quán)重：嚴(yán)重缺陷、重要缺陷、一般缺陷、好的；11）評審團(tuán)隊?wèi)?yīng)對評審對象給出最后意見：

接受（無需修改）

有條件接受（需修改，但不需進(jìn)一步評審）

不接受（需進(jìn)一步評審或其他的檢查）37靜態(tài)測試檢查（評審會議）（續(xù)）11靜態(tài)測試檢查（評審會議）（續(xù)）12）要有會議紀(jì)要及總結(jié)包括會議中討論的問題或發(fā)現(xiàn)問題的列表，評審總結(jié)報告等。返工經(jīng)理決定接受評審團(tuán)隊意見修正缺陷，或選擇另外的方法（經(jīng)理必須對此全權(quán)負(fù)責(zé)）跟蹤專人跟蹤缺陷的修改。38靜態(tài)測試檢查（評審會議）（續(xù)）12靜態(tài)測試評審角色和職責(zé)經(jīng)理

確保文檔、必需的資源可用，同時選擇評審人；

經(jīng)理不一定得是管理層人員（導(dǎo)致大家“人心恍惚”）主持人

管理評審有關(guān)的工作：計劃、準(zhǔn)備并保證評審有序進(jìn)行且滿足它的目標(biāo)，收集評審數(shù)據(jù)、發(fā)布評審報告等。作者

文檔的創(chuàng)建者，如為多人，應(yīng)是主要負(fù)責(zé)人。

不要把針對文檔的問題看作是對其人的批評，作者必須明白評審只是用來幫助改進(jìn)產(chǎn)品。(接下頁)39靜態(tài)測試評審角色和職責(zé)13靜態(tài)測試角色和職責(zé)評審人

通常最多5個。他們應(yīng)能識別并描述評審對象中存在的問題。

為保證有效的覆蓋率，可給評審人分配制定的評審主題。記錄員

記錄所有的發(fā)現(xiàn)：問題、采取的措施、決定和建議等。文字應(yīng)簡短和準(zhǔn)確。

最好由文檔作者來擔(dān)當(dāng)。40靜態(tài)測試角色和職責(zé)14靜態(tài)測試評審失敗的可能原因：需要的人沒空或不具備必須的資格和技術(shù)技能。管理層在資源計劃時不準(zhǔn)確的估計準(zhǔn)備不足。文檔不足缺少管理層支持(在下述文獻(xiàn)中詳細(xì)描述了解決這些問題的方法：Freedman,D.P.,Weinberg,G.M.:Handbook

of

Walkthroughs,Inspections,and

Technical

Reviews:Evaluating

Programs,Projects,and

Products,3rd

ed.,Dorset

House,1990)41靜態(tài)測試評審失敗的可能原因：15測試基礎(chǔ)–靜態(tài)測試概述評審代碼檢查42測試基礎(chǔ)–靜態(tài)測試概述16靜態(tài)測試代碼檢查主要檢查代碼和設(shè)計的一致性，代碼對標(biāo)準(zhǔn)的遵循、可讀性，代碼的邏輯表達(dá)的正確性，代碼結(jié)構(gòu)的合理性等方面；以期發(fā)現(xiàn)違背編程標(biāo)準(zhǔn)或編程風(fēng)格問題，程序中不安全、不明確和模糊部分，程序中不可移植部分等。代碼檢查在編譯和動態(tài)測試前進(jìn)行，在檢查前，應(yīng)準(zhǔn)備好需求描述文檔、程序設(shè)計文檔、程序的源代碼清單、代碼編碼標(biāo)準(zhǔn)和代碼缺陷檢查表等。

代碼檢查包括：桌面檢查、代碼審查、代碼走查等。43靜態(tài)測試代碼檢查1744靜態(tài)測試①桌面檢查（DeskChecking）由程序員自查。程序員在程序通過編譯之后，進(jìn)行單元測試設(shè)計之前，對源程序代碼進(jìn)行分析，檢驗，并補充相關(guān)文檔。檢查項目有：檢查變量的交叉引用表重點是未說明的變量和違反了類型規(guī)定的變量；逐個檢查變量的引用、變量的使用序列；臨時變量在某條路徑上的重寫情況；局部變量、全局變量與特權(quán)變量的使用；18靜態(tài)測試①桌面檢查（DeskChecking）45靜態(tài)測試-桌面檢查檢查標(biāo)號的交叉引用表檢查驗證所有標(biāo)號的正確性：命名是否正確；轉(zhuǎn)向指定位置的標(biāo)號是否正確。檢查子程序、宏、函數(shù)驗證每次調(diào)用與被調(diào)用位置是否正確；被調(diào)用的子程序、宏、函數(shù)是否存在；檢驗調(diào)用序列中調(diào)用方式與參數(shù)順序、個數(shù)、類型上的一致性。等值性檢查檢查全部等價變量的類型的一致性，解釋所包含的類型差異。19靜態(tài)測試-桌面檢查檢查標(biāo)號的交叉引用表46靜態(tài)測試常量檢查確認(rèn)每個常量的取值和數(shù)制、數(shù)據(jù)類型；檢查常量每次引用同它的取值、數(shù)制和類型的一致性；標(biāo)準(zhǔn)檢查檢查違反標(biāo)準(zhǔn)的問題。比較控制流比較由程序員設(shè)計的控制流圖和由實際程序生成的控制流圖，尋找和解釋每個差異，修改文檔和校正錯誤。20靜態(tài)測試常量檢查47靜態(tài)測試選擇、激活路徑在程序員設(shè)計的控制流圖上選擇路徑，再到實際的控制流圖上激活這條路徑。如果選擇的路徑在實際控制流圖上不能激活，則源程序可能有錯。用這種方法激活的路徑集合應(yīng)保證源程序模塊的每行代碼都被檢查，即桌前檢查應(yīng)至少是語句覆蓋。風(fēng)格檢查檢查在程序設(shè)計風(fēng)格方面發(fā)現(xiàn)的問題。對照程序的規(guī)格說明，詳細(xì)閱讀源代碼程序員對照程序的規(guī)格說明書、規(guī)定的算法和程序設(shè)計語言的語法規(guī)則，仔細(xì)地閱讀源代碼，逐字逐句進(jìn)行分析和思考，比較實際的代碼和期望的代碼，從它們的差異中發(fā)現(xiàn)程序的問題和錯誤。21靜態(tài)測試選擇、激活路徑48靜態(tài)測試補充文檔桌前檢查的文檔是一種過渡性的文檔，不是公開的正式文檔。通過編寫文檔，也是對程序的一種下意識的檢查和測試，可以幫助程序員發(fā)現(xiàn)和抓住更多的錯誤。這種桌前檢查，由于程序員熟悉自己的程序和自身的程序設(shè)計風(fēng)格，可以節(jié)省很多的檢