測試基礎(chǔ)靜態(tài)測試

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

2、存在一些不易察覺的錯等，使軟件運行出錯，維護不便。o 靜態(tài)測試內(nèi)容主要包括：各階段的文檔評審、代碼檢查、代碼度量等。靜態(tài)測試可由人工進行，也可借助軟件工具自動進行。 可以做靜態(tài)分析的工具很多，出名的有LOGICSCOPE，C+ TEST，LDRA TESTBED，PRQA C/C+，MACABE IQ，以及Rational的Purify、Quantify和PureCoverage等 整理課件5測試基礎(chǔ) 靜態(tài)測試o 概述o 評審o 代碼檢查整理課件6靜態(tài)測試o 評審n評審是對所有人工靜態(tài)分析和具體文檔檢查技術(shù)的通稱。n評審對象：開發(fā)項目中所有文檔及項目外有價值的文檔。如：合同、需求定義、設(shè)計規(guī)格

3、說明、程序代碼、測試計劃和手冊等。n評審是一種保證質(zhì)量的方法n評審的積極作用可降低消除缺陷的成本可縮短開發(fā)時間可減少動態(tài)測試時間和成本可減少系統(tǒng)安裝后的變更申請降低系統(tǒng)運行故障率檢查團對活動，改進團隊成員的工作方法整理課件7靜態(tài)測試n評審潛在的問題注意不要使作者感到嚴格檢查是針對他人而非他提交的文檔。n評審的成本和收益評審的成本大概占整個開發(fā)預(yù)算的10%15%,包括評審過程、評審分析和過程改進的工作量。估計節(jié)約的成本約為14%25%。（參見：Bush M. “Software Quality:The use of formal inspections at the Jet Propulsion

4、 Laboratory”，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）整理課件8靜態(tài)測試n能促使評審成功的因素（IEEE 1028建議）每次評審都事先定于一個明確的目標；根據(jù)每個人的知識和技能水平選擇合適的評審參與者。整理課件9靜態(tài)測試o 通用評審過程（參考：IEEE 1028）評審活動分6個步驟：計劃、概述、準備、檢查（評審會議）、返工和跟蹤。n計劃要評審的文檔；評審技

5、術(shù)；估算評審工作量；評審檢查點；組建評審團隊；確保文檔處于一個可評審狀態(tài)；會議的時間和地點（如有的話）等。n概述（開工會）為參加評審的人提供所有必需信息。n準備評審人必須各自為評審會議做準備。整理課件10靜態(tài)測試n檢查（評審會議）會議應(yīng)有主持人。目的除了發(fā)現(xiàn)缺陷外，還包括判斷評審對象是否滿足需求以及是否符合標準。評審會議的一些通用準則：1）評審會議的時間限制在2小時內(nèi)；2）如有評審人缺席或準備不充分，主持人有權(quán)取消或中止會議；3）檢查對象是被提交的文檔，而非作者；評審人必須注意他們的言語及表達方式作者不應(yīng)為自己或文檔辯護4）主持人不應(yīng)同時作為評審人；整理課件11靜態(tài)測試n檢查（評審會議）（續(xù)）

6、5）不討論常見的風(fēng)格問題（方針之外的問題）；6）開發(fā)方案和對應(yīng)的討論不是評審團隊的任務(wù)；7）每個評審人員必須有機會充分表達他們的論點；8）會議紀要必須完整表達評審人的意見；9）問題不應(yīng)以命令的形式寫給作者；10）問題必須劃分為不同的權(quán)重：嚴重缺陷、重要缺陷、一般缺陷、好的；11）評審團隊應(yīng)對評審對象給出最后意見：接受（無需修改）有條件接受（需修改，但不需進一步評審）不接受（需進一步評審或其他的檢查）整理課件12靜態(tài)測試n檢查（評審會議）（續(xù)）12）要有會議紀要及總結(jié)包括會議中討論的問題或發(fā)現(xiàn)問題的列表，評審總結(jié)報告等。n返工經(jīng)理決定接受評審團隊意見修正缺陷，或選擇另外的方法（經(jīng)理必須對此全權(quán)負

7、責(zé)）n跟蹤專人跟蹤缺陷的修改。整理課件13靜態(tài)測試o 評審角色和職責(zé)n經(jīng)理確保文檔、必需的資源可用，同時選擇評審人；經(jīng)理不一定得是管理層人員（導(dǎo)致大家“人心恍惚”）n主持人管理評審有關(guān)的工作：計劃、準備并保證評審有序進行且滿足它的目標，收集評審數(shù)據(jù)、發(fā)布評審報告等。n作者文檔的創(chuàng)建者，如為多人，應(yīng)是主要負責(zé)人。不要把針對文檔的問題看作是對其人的批評，作者必須明白評審只是用來幫助改進產(chǎn)品。整理課件14靜態(tài)測試o 角色和職責(zé)n評審人通常最多5個。他們應(yīng)能識別并描述評審對象中存在的問題。為保證有效的覆蓋率，可給評審人分配制定的評審主題。n記錄員記錄所有的發(fā)現(xiàn)：問題、采取的措施、決定和建議等。文字應(yīng)簡

8、短和準確。最好由文檔作者來擔當。整理課件15靜態(tài)測試o 評審失敗的可能原因：n需要的人沒空或不具備必須的資格和技術(shù)技能。n管理層在資源計劃時不準確的估計n準備不足。n文檔不足n缺少管理層支持(在下述文獻中詳細描述了解決這些問題的方法：Freedman,D.P.,Weinberg,G.M.:Handbook of Walkthroughs,Inspections,and Technical Reviews:Evaluating Programs,Projects,and Products,3rd ed.,Dorset House,1990)整理課件16測試基礎(chǔ) 靜態(tài)測試o 概述o 評審o 代碼檢

9、查整理課件17靜態(tài)測試o 代碼檢查主要檢查代碼和設(shè)計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結(jié)構(gòu)的合理性等方面；以期發(fā)現(xiàn)違背編程標準或編程風(fēng)格問題，程序中不安全、不明確和模糊部分，程序中不可移植部分等。代碼檢查在編譯和動態(tài)測試前進行，在檢查前，應(yīng)準備好需求描述文檔、程序設(shè)計文檔、程序的源代碼清單、代碼編碼標準和代碼缺陷檢查表等。 代碼檢查包括：桌面檢查、代碼審查、代碼走查桌面檢查、代碼審查、代碼走查等。整理課件18靜態(tài)測試 桌面檢查（Desk Checking）由程序員自查。程序員在程序通過編譯之后，進行單元測試設(shè)計之前，對源程序代碼進行分析，檢驗，并補充相關(guān)文檔。檢查

10、項目有：n檢查變量的交叉引用表 重點是未說明的變量和違反了類型規(guī)定的變量；逐個檢查變量的引用、變量的使用序列；臨時變量在某條路徑上的重寫情況；局部變量、全局變量與特權(quán)變量的使用；整理課件19靜態(tài)測試 -桌面檢查n檢查標號的交叉引用表 檢查驗證所有標號的正確性：命名是否正確；轉(zhuǎn)向指定位置的標號是否正確。n檢查子程序、宏、函數(shù) 驗證每次調(diào)用與被調(diào)用位置是否正確；被調(diào)用的子程序、宏、函數(shù)是否存在；檢驗調(diào)用序列中調(diào)用方式與參數(shù)順序、個數(shù)、類型上的一致性。n等值性檢查 檢查全部等價變量的類型的一致性，解釋所包含的類型差異。整理課件20靜態(tài)測試n常量檢查 確認每個常量的取值和數(shù)制、數(shù)據(jù)類型；檢查常量每次引

11、用同它的取值、數(shù)制和類型的一致性；n標準檢查 檢查違反標準的問題。n比較控制流 比較由程序員設(shè)計的控制流圖和由實際程序生成的控制流圖，尋找和解釋每個差異，修改文檔和校正錯誤。整理課件21靜態(tài)測試n選擇、激活路徑 在程序員設(shè)計的控制流圖上選擇路徑，再到實際的控制流圖上激活這條路徑。如果選擇的路徑在實際控制流圖上不能激活，則源程序可能有錯。用這種方法激活的路徑集合應(yīng)保證源程序模塊的每行代碼都被檢查，即桌前檢查應(yīng)至少是語句覆蓋。n風(fēng)格檢查 檢查在程序設(shè)計風(fēng)格方面發(fā)現(xiàn)的問題。n對照程序的規(guī)格說明，詳細閱讀源代碼 程序員對照程序的規(guī)格說明書、規(guī)定的算法和程序設(shè)計語言的語法規(guī)則，仔細地閱讀源代碼，逐字逐句

12、進行分析和思考，比較實際的代碼和期望的代碼，從它們的差異中發(fā)現(xiàn)程序的問題和錯誤。整理課件22靜態(tài)測試n補充文檔 桌前檢查的文檔是一種過渡性的文檔，不是公開的正式文檔。通過編寫文檔，也是對程序的一種下意識的檢查和測試，可以幫助程序員發(fā)現(xiàn)和抓住更多的錯誤。這種桌前檢查，由于程序員熟悉自己的程序和自身的程序設(shè)計風(fēng)格，可以節(jié)省很多的檢查時間，但應(yīng)避免主觀片面性。整理課件23靜態(tài)測試 代碼審查（Code Reading Review）代碼審查是由若干程序員和測試員組成一個會審小組，通過閱讀、討論和爭議，對程序進行靜態(tài)分析的過程。 代碼審查分兩步：第一步，小組負責(zé)人提前把設(shè)計規(guī)格說明書、控制流程圖、程序文

13、本及有關(guān)要求、規(guī)范等分發(fā)給小組成員，作為評審的依據(jù)。小組成員在充分閱讀這些材料之后，進入審查的第二步。第二步：召開程序?qū)彶闀?。在會上，首先由程序員逐句講解程序的邏輯。在此過程中，程序員或其他小組成員可以提出問題，展開討論，審查錯誤是否存在。實踐表明，程序員在講解過程中能發(fā)現(xiàn)許多原來自己沒有發(fā)現(xiàn)的錯誤，而討論和爭議則促進了問題的暴露。整理課件24靜態(tài)測試在會前，應(yīng)當給會審小組每個成員準備一份常見錯誤的清單，把以往所有可能發(fā)生的常見錯誤羅列出來，供與會者對照檢查，以提高會審的實效。這個常見錯誤清單也叫做檢查表，它把程序中可能發(fā)生的各種錯誤進行分類，對每一類列舉出盡可能多的典型錯誤，然后把它們制成表格，供在會審時使用。下面列出了代碼檢查應(yīng)查找的問題整理課件25靜態(tài)測試o源代碼格式：是否符合編程標準或規(guī)范？o程序語句的使用o數(shù)據(jù)引用錯誤o數(shù)據(jù)聲明錯誤o計算錯誤o比較錯誤o接口錯誤o控制流程錯誤o輸入輸出錯誤o邏輯和性能o維護性和可靠性整理課件26靜態(tài)測試 走查（Walkthroughs）走查與代碼會審基本相同，其過程分為兩步。第一步也把材料先發(fā)給走查小組每個成員，讓他們認真研究程序，然后再開會。開會的程序與代碼會審不同