靜態(tài)測試技術(shù)

靜態(tài)測試技術(shù)第一頁，共七十八頁，2022年，8月28日軟件測試方法和技術(shù)董瑞志/~nature_dongEmail:聯(lián)系電話：第二頁，共七十八頁，2022年，8月28日內(nèi)容提要靜態(tài)測試技術(shù)桌面檢查代碼審查代碼走查技術(shù)評審靜態(tài)測試的內(nèi)容需求定義的靜態(tài)測試設(shè)計文檔的靜態(tài)測試源代碼的靜態(tài)測試第三頁，共七十八頁，2022年，8月28日靜態(tài)測試的定義不執(zhí)行程序代碼而尋找代碼中可能存在的錯誤或評估程序代碼的過程。 靜態(tài)測試可以手工進行，也可以借助軟件工具自動進行。北京測試空間是注冊于北京市海淀區(qū)高新技術(shù)園的軟件企業(yè)，目前主要業(yè)務(wù)范圍包括軟件測試管理工具研發(fā)、軟件測試項目外包和軟件測試專業(yè)技術(shù)人才培養(yǎng)及派遣。北京測試空間地址：北京市海淀區(qū)學(xué)院路40號大唐電信測試空間樓聯(lián)系電話：010-623032236230326062303230第四頁，共七十八頁，2022年，8月28日靜態(tài)測試的特點靜態(tài)測試不必動態(tài)的執(zhí)行程序，也就是不必進行測試用例設(shè)計和結(jié)果判讀等工作；靜態(tài)測試可以由人手工方式進行，充分發(fā)揮人的優(yōu)勢，行之有效。解鈴還須系鈴人，由于人的思維及交流障礙而造成的邏輯錯誤，有人通過邏輯思維去解決，是一種非常有效的方法；特別是在充分利用人思維互補的情形，檢驗出錯誤的水平非常高。靜態(tài)測試實施不需要特別條件，容易開展第五頁，共七十八頁，2022年，8月28日靜態(tài)測試的內(nèi)容主要由人工進行代碼審查(CodeInspection)

代碼走查(Walkthrough)

桌面檢查技術(shù)審查主要由軟件工具自動進行的靜態(tài)分析廣義的理解，還包括軟件需求分析和設(shè)計階段的技術(shù)評審第六頁，共七十八頁，2022年，8月28日代碼審查和代碼走查由若干程序員與測試員組成一個小組，集體閱讀并討論程序，或者用“腦”執(zhí)行并檢查程序的過程分兩步完成預(yù)先作一定的準備工作然后舉行會議進行討論會議的主題是發(fā)現(xiàn)錯誤而不是糾正錯誤第七頁，共七十八頁，2022年，8月28日桌面檢查程序員閱讀自己所編的程序缺點：第一，由于心理上的原因，容易對自己的程序的偏愛，沒有發(fā)現(xiàn)錯誤的欲望（這和已經(jīng)知道了程序錯了讀程序找錯誤所在極為不同）第二，由于人的思維定勢，有些習(xí)慣性的錯誤自己不易發(fā)現(xiàn)第三，如果根本對功能理解錯了，自己不易糾正所以這種方法效率不高，可作為個人自我檢查程序中明顯的疏漏或筆誤第八頁，共七十八頁，2022年，8月28日代碼審查與代碼走查的優(yōu)點不僅比桌面檢查優(yōu)越得多，而且與動態(tài)測試的方法相比也有很多優(yōu)點第一，使用這種方法測試，一旦發(fā)現(xiàn)錯誤，就知道錯誤的性質(zhì)和位置，因而調(diào)試所花費的代價低第二，使用這種方法一次能揭示一批錯誤，而不是一次只揭示一個錯誤又，如果使用動態(tài)測試，通常僅揭示錯誤的征兆。 程序不終止運行，而對錯誤的性質(zhì)和位置還得逐個查找。第九頁，共七十八頁，2022年，8月28日代碼審查與代碼走查的效果經(jīng)驗表明，使用這種方法能夠優(yōu)先的發(fā)現(xiàn)30~70％的邏輯設(shè)計和編碼錯誤IBM使用代碼審查方法表明，錯誤的檢測效率高達全部查出錯誤的80％Myers的研究發(fā)現(xiàn)代碼審查和代碼走查平均查出全部錯誤的70%第十頁，共七十八頁，2022年，8月28日代碼審查、代碼走查與動態(tài)測試相互補充研究表明使用代碼審查和代碼走查發(fā)現(xiàn)某類錯誤比用動態(tài)測試更有效，而對另一類錯誤情況正好相反由此可見代碼審查和代碼走查方法與動態(tài)測試結(jié)合，測試效果更佳。第十一頁，共七十八頁，2022年，8月28日代碼審查的測試內(nèi)容檢查代碼和設(shè)計的一致性檢查代碼對標準的遵循、可讀性檢查代碼的邏輯表達的正確性檢查代碼結(jié)構(gòu)的合理性第十二頁，共七十八頁，2022年，8月28日代碼審查的組成和方式代碼審查由一組程序和錯誤檢查技術(shù)組成以代碼審查組方式組織第十三頁，共七十八頁，2022年，8月28日代碼審查組通常由四人組成，其中一人為組長組長是關(guān)鍵，最好是一個稱職的程序員，但不是被測試程序的編寫者，也不需要對所檢查的程序很熟悉，但需要較強的組織協(xié)調(diào)和語言能力組長的職責(zé)包括分配資料、安排計劃、主持開會、記錄并保存被發(fā)現(xiàn)的錯誤其余成員包括資深程序員、程序編寫者與專職測試人員根據(jù)測試的組織方式（如內(nèi)部測試和獨立測試）不同，代碼審查小組組成可以調(diào)節(jié)，但組長角色不能變動第十四頁，共七十八頁，2022年，8月28日代碼審查的步驟準備程序閱讀審查會議跟蹤及報告第十五頁，共七十八頁，2022年，8月28日準備組長提前把程序目錄表和設(shè)計說明書等材料分配給小組成員小組成員熟悉這些材料由被測程序的設(shè)計和編碼人員向?qū)彶榻M詳細說明所準備的材料，特別是代碼的主要功能與功能間的關(guān)系第十六頁，共七十八頁，2022年，8月28日程序閱讀審查組人員仔細閱讀代碼和相關(guān)材料對照代碼審查單標出明顯缺陷及錯誤第十七頁，共七十八頁，2022年，8月28日審查會議審查會由組長主持首先由程序員逐句闡明程序的邏輯，在此過程中可由程序員或其他小組成員提出問題，追蹤錯誤是否存在經(jīng)驗證明在上述闡述過程中，有很多錯誤由講述程序者而不是其他小組成員發(fā)現(xiàn)大聲地朗讀程序給聽眾，這樣簡單的工作是有效的錯誤檢測技術(shù)然后利用代碼審查單來分析討論組長負責(zé)討論沿著建設(shè)性的方向前進，而其他人則集中注意力發(fā)現(xiàn)錯誤，但不去糾正錯誤第十八頁，共七十八頁，2022年，8月28日跟蹤和報告會后把發(fā)現(xiàn)的錯誤登記造表并交給程序開發(fā)人員如果發(fā)現(xiàn)錯誤較多或發(fā)現(xiàn)重大錯誤，那么在改正之后，組長要再次組織審查會議為了改進以后的審查工作，對錯誤登記表也要分析，歸類和精煉第十九頁，共七十八頁，2022年，8月28日以第三方測試的方式進行代碼審查應(yīng)就發(fā)現(xiàn)的缺陷及錯誤與軟件開發(fā)人員討論避免由于理解不一致產(chǎn)生問題，形成共同認可的審查結(jié)果第二十頁，共七十八頁，2022年，8月28日審查會議的時間大約以1.5~2小時為宜審查會需要高度集中注意力，時間太長反而容易使效率降低每次會議可能處理一個或幾個模塊第二十一頁，共七十八頁，2022年，8月28日代碼審查單代碼審查單是代碼審查過程所用的主要技術(shù)通常是把程序設(shè)計及編碼中可能發(fā)生的各種錯誤進行分類，對每一類列舉出盡可能多的典型錯誤，然后制成表格其它測試中發(fā)現(xiàn)的錯誤也要及時歸入代碼審查單，形成某一類型軟件針對性的代碼審查單，以供審查時使用第二十二頁，共七十八頁，2022年，8月28日的代碼審查單（部分）數(shù)據(jù)引用錯誤是否引用了未賦值或者未初始化的變量？所有的數(shù)組引用，其下標值是否都在各自的相應(yīng)維數(shù)定義界內(nèi)？所有的數(shù)組引用，每一個下表是否是整數(shù)值？所有引用的指針或變量當(dāng)前是否已經(jīng)分配儲存了？（即是否存在“懸掛引用”的問題）在檢索操作或下標引用數(shù)組時，是否存在“差1”的錯誤？Tobecontinue……第二十三頁，共七十八頁，2022年，8月28日的代碼審查單（部分）數(shù)據(jù)說明錯誤所有變量是否都顯示地說明了？是否每個變量都賦予正常的長度、類型和存儲分類？變量的初始化和它的存儲類型是否有矛盾？Tobecontinue……第二十四頁，共七十八頁，2022年，8月28日的代碼審查單（部分）計算錯誤是否使用過非一致的數(shù)據(jù)類型的變量進行運算？是否存在混合運算？賦值語句的目標變量是否比其右邊的表達式小第二十五頁，共七十八頁，2022年，8月28日代碼審查單的其他內(nèi)容還可以包括編程風(fēng)格、標準、規(guī)范的符合性方面的內(nèi)容在代碼審查單的錯誤登記表中，應(yīng)寫明所查出的錯誤的類型、錯誤類別、錯誤的嚴重程度、錯誤的位置、錯誤的原因等信息。第二十六頁，共七十八頁，2022年，8月28日閱讀的方法要仔細閱讀需求設(shè)計等文檔，特別是了解軟件的整體物理意義、應(yīng)用背景以及在大系統(tǒng)中的地位對大型軟件而言，這些信息會在閱讀程序時有效地幫助讀者從一定的高度審視，而不是停留在逐行掃描代碼有些錯誤要有整體觀才能發(fā)現(xiàn)第二十七頁，共七十八頁，2022年，8月28日閱讀結(jié)構(gòu)化代碼的兩種方法追蹤通過每個子程序的主要邏輯行，主要邏輯行全部跟蹤完，然后開始跟蹤第二條路徑相當(dāng)于深度優(yōu)先遍歷。按排列順序追蹤代碼，從主要行開始，然后檢查較低層的程序段 相當(dāng)于廣度優(yōu)先遍歷第二十八頁，共七十八頁，2022年，8月28日兩種閱讀方法的綜合使用這兩種方式的差別在于何時進入下層模塊，選擇那種方式要視具體程序特點而定廣度優(yōu)先遍歷有助于很快地了解程序的全貌深度優(yōu)先適于詳細查閱功能處理步驟應(yīng)綜合使用上述兩種方法，在頭一兩遍閱讀時，采用廣度優(yōu)先，然后用深度優(yōu)先第二十九頁，共七十八頁，2022年，8月28日程序閱讀的次數(shù)Beizer提出至少要讀程序4次，分別針對印刷錯誤、數(shù)據(jù)結(jié)構(gòu)、控制流和處理4次閱讀要比讀一次能更快、更容易、更可靠的完成任務(wù)第三十頁，共七十八頁，2022年，8月28日代碼審查的輔助工具匯編或編譯器生成的交叉引用表（變量、標號、子程序）逆向工程工具（例如從源代碼生成流程圖）帶有快速查找的編輯器第三十一頁，共七十八頁，2022年，8月28日代碼走查代碼走查與代碼審查相似，它也是由一組程序和錯誤檢查技術(shù)組成，只是程序和錯誤檢查技術(shù)不完全相同。第三十二頁，共七十八頁，2022年，8月28日代碼走查組代碼走查以小組方式進行代碼走查組包括組長，類似代碼審查組長秘書，負責(zé)記錄發(fā)現(xiàn)的錯誤，要有一定水平測試人員，應(yīng)是具有經(jīng)驗的程序設(shè)計人員，或精通程序設(shè)計語言的人員，或從未介入被測試程序的設(shè)計工作的技術(shù)人員（這樣的人沒有被已有的設(shè)計框?。?，沒有約束，比較容易發(fā)現(xiàn)問題。第三十三頁，共七十八頁，2022年，8月28日代碼走查的過程與代碼審查過程相似先把材料交給每個小組人員，讓他們認真研究程序，然后再召開代碼走查會議。第三十四頁，共七十八頁，2022年，8月28日代碼走查會議的內(nèi)容與代碼審查不同，不是讀程序和使用代碼審查單，而是由被指定的作為測試員的小組成員提供若干測試用例（程序的輸入數(shù)據(jù)和期望的輸出結(jié)果），讓參加會的成員當(dāng)計算機，在會議上對每個測試用例用頭腦來執(zhí)行程序，也就是用測試用例沿程序邏輯走一遍，并由測試人員講述程序執(zhí)行過程，在紙上或黑板上監(jiān)視程序狀態(tài)（變量的值）每次開會時間以1－2小時為宜，但不允許中斷如果發(fā)現(xiàn)問題由秘書記下來，中間不討論任何糾錯問題，主要是發(fā)現(xiàn)錯誤第三十五頁，共七十八頁，2022年，8月28日測試用例在代碼走查中的作用代碼走查中，測試用例并不是關(guān)鍵，也并不是僅想驗證這幾個測試用例運行是否正確，人腦畢竟比計算機慢太多這里測試用例是作為懷疑程序邏輯與計算錯誤的啟發(fā)點，在隨測試實例游歷程序邏輯時，在懷疑程序的過程中發(fā)現(xiàn)錯誤這樣，比幾個測試用例本身直接發(fā)現(xiàn)的錯誤要多得多第三十六頁，共七十八頁，2022年，8月28日代碼走查中的缺點代碼走查使用測試用例啟發(fā)檢測錯誤，人們注意力會相對集中在隨測試用例游歷的程序邏輯路徑上，不如代碼審查檢查的范圍廣，錯誤覆蓋面全。第三十七頁，共七十八頁，2022年，8月28日技術(shù)評審綜合運用走查和審查技術(shù)，逐頁、逐節(jié)地檢查軟件開發(fā)前期需求分析和設(shè)計的文檔，對軟件的需求，設(shè)計結(jié)構(gòu)等方面提出問題評審也被當(dāng)作一種管理工具，經(jīng)過評審不僅可以提高各階段軟件產(chǎn)品的質(zhì)量，還可以收集到一些有關(guān)該軟件產(chǎn)品質(zhì)量的數(shù)據(jù)技術(shù)評審屬于廣義的測試范疇，也是一種質(zhì)量保證手段軟件開發(fā)過程中每個階段的評審都必須十分正規(guī)的，嚴格的加以定義，并根據(jù)規(guī)程實施。第三十八頁，共七十八頁，2022年，8月28日靜態(tài)測試的內(nèi)容針對不同的軟件中間產(chǎn)品，靜態(tài)測試的內(nèi)容也不盡相同；對不同的文檔進行靜態(tài)測試的內(nèi)容可以體現(xiàn)在對特定文檔的測試對照條例中。下面以軟件開發(fā)過程中的幾個有代表性的主要文檔和代碼，列舉靜態(tài)測試的對照條例，以說明靜態(tài)測試的內(nèi)容：第三十九頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例對需求定義的測試著重于測試對用戶需求的描述和解釋是否完整、準確；下面是根據(jù)有關(guān)標準整理而成的對需求定義進行靜態(tài)測試的對照條例。我們把這些條例按照所測試的軟件質(zhì)量因素分成10組：Tobecontinue……第四十頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例兼容性 界面需求是否使軟硬件系統(tǒng)具有兼容性？第四十一頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例完備性需求定義是否包含了有關(guān)文件（指質(zhì)量手冊、質(zhì)量計劃以及其它有關(guān)文件）中所規(guī)定的需求定義所應(yīng)該包含的所有內(nèi)容？需求定義是否包含了有關(guān)功能、性能、限制、目標、質(zhì)量等方面的所有需求？功能性需求是否覆蓋了所有非正常情況的處理？是否對各種操作模式（如正常、非正常、有干擾等等）下的環(huán)境條件都作了規(guī)定？是否對所有功能與時間有關(guān)的方面都作了考慮？是否識別出了所有與時間因素有關(guān)的功能？它們的時間準則是否都說明了？時間準則的最大、最小執(zhí)行時間是否都定義了？是否識別并定義了在將來可能會變化的需求？第四十二頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例完備性（續(xù)）是否定義了系統(tǒng)所有的輸入？是否標識清楚了系統(tǒng)輸入的來源？是否識別出了系統(tǒng)的輸出？是否說明了系統(tǒng)輸入、輸出的類型？是否說明了系統(tǒng)輸入、輸出的值域、單位、格式等等？是否說明了如何進行系統(tǒng)輸入的合法性檢查？是否定義了系統(tǒng)輸入、輸出的精度？是否定義了系統(tǒng)性能的各個方面？在不同負載情況下，系統(tǒng)的生產(chǎn)率如何？在不同的情況下，系統(tǒng)的響應(yīng)時間如何？系統(tǒng)對軟件、硬件或電源故障必須作什么樣的反應(yīng)？是否充分地定義了關(guān)于人機界面的需求？第四十三頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例一致性各個需求之間是否一致？是否有沖突和矛盾？所規(guī)定的模型、算法和數(shù)值方法是否相容？是否使用了標準的術(shù)語和定義形式？需求是否與其軟硬件操作環(huán)境相容？是否說明了軟件對其系統(tǒng)和環(huán)境的影響？是否說明了環(huán)境對軟件的影響？第四十四頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例正確性需求定義是否滿足標準的要求？算法和規(guī)則是否有科技文獻或其它文獻作為基礎(chǔ)？有哪些證據(jù)說明用戶提供的規(guī)則或規(guī)定是正確的？是否定義了對在錯誤、危險分析中所識別出的各種故障模式和錯誤類型所需的反應(yīng)？是否參照了有關(guān)的標準？是否對每一個需求都給出了理由？理由是否充分？對設(shè)計和實現(xiàn)的限制是否都有論證？第四十五頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例可行性需求定義是否使軟件的設(shè)計、實現(xiàn)、操作和維護都可行？所規(guī)定的模型、數(shù)值方法和算法是否對待解問題合適？是否能夠在相應(yīng)的限制條件下實現(xiàn)？是否能夠達到關(guān)于質(zhì)量的要求？第四十六頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例易修改性對需求定義的描述是否易于修改（例如，是否采用良好的結(jié)構(gòu)和交叉引用表等等）？是否有冗余的信息？是否一個需求被定義多次？第四十七頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例健壯性是否有容錯的需求？第四十八頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例易追溯性是否可從上一階段的文檔查找到需求定義中的相應(yīng)內(nèi)容？需求定義是否明確的表明前階段中提出的有關(guān)需求和設(shè)計限制都已經(jīng)被覆蓋了？（例如，使用覆蓋矩陣或交叉引用表）？需求定義是否便于向后繼續(xù)開發(fā)階段查找信息？第四十九頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例易理解性是否每一個需求都只有一種解釋？功能性需求是不是以模塊方式描述的，是否明確的標識出了其功能？是否有術(shù)語定義一覽表？是否使用了形式化或半形式化的語言？語言是否有歧義性？需求定義中是否只包含了必要的實現(xiàn)細節(jié)而不包含不必要的實現(xiàn)細節(jié)？是否過分細致了？需求定義是否足夠清楚和明確使其能夠作為開發(fā)設(shè)計規(guī)約和功能性測試數(shù)據(jù)的基礎(chǔ)？需求定義的描述是否將對程序的需求和所提供的其它信息分離開來了？第五十頁，共七十八頁，2022年，8月28日需求定義的靜態(tài)測試對照條例易測試性和可驗證性需求是否可以驗證？（即是否可以檢驗軟件是否滿足了需求？）是否對每一個需求都指定了驗證過程？數(shù)學(xué)函數(shù)的定義是否使用了精確定義的語法和語義符號？第五十一頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例對設(shè)計文檔的靜態(tài)測試著重于分析設(shè)計是否與需求定義一致，所采用的數(shù)值方法和算法是否適用于待解問題，程序的設(shè)計中對程序的劃分是否與待解問題相適應(yīng)，需求是否都被滿足了等等。第五十二頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例--完備性軟件設(shè)計規(guī)約是否包含了有關(guān)文件（指質(zhì)量手冊、質(zhì)量計劃及其它有關(guān)文件）中所規(guī)定的所有內(nèi)容？是否有充分的數(shù)據(jù)（如邏輯結(jié)構(gòu)圖、算法、存儲分配圖等）來保證設(shè)計的完整性？算法、公式等是否充分、準確、完善？是否在設(shè)計中明確地說明了產(chǎn)品的開發(fā)中所需要的軟件、硬件和測試所需要的軟硬件？對于每一個程序界面，設(shè)計是否都實現(xiàn)了所要求的行為？Tobecontinue……第五十三頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例--完備性是否標識出了程序的每一個輸入、輸出和數(shù)據(jù)庫成分？其描述是否詳細到了可以編碼的程度了？是否說明了程序的操作環(huán)境？是否包含了所有的處理步驟？是否給出了每一個決策點的所有出口轉(zhuǎn)向？設(shè)計是否考慮到了所有可能的情況和條件？設(shè)計是否指明了在出現(xiàn)異常情況和不正當(dāng)輸入的情況下的行為？設(shè)計是否參照了有關(guān)的設(shè)計標準？第五十四頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—一致性在設(shè)計文檔中，是否始終使用標準的術(shù)語和定義？文檔的風(fēng)格和詳細程度是否前后始終一致？界面之間是否相容？設(shè)計是否包含內(nèi)在矛盾？模型、算法和數(shù)值方法之間是否在數(shù)學(xué)上是相容的？輸入／輸出的格式是否一致？類似的功能和相關(guān)的功能的設(shè)計是否一致？計算中的輸入、輸出和數(shù)據(jù)庫成分的計量單位和計算精度是否一致？邏輯表達式是否一致？第五十五頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—正確性設(shè)計文檔是否滿足有關(guān)標準的要求？設(shè)計是否只完成需求定義中要求的功能？若包含額外的功能，則這些功能的必要性是否經(jīng)過論證？測試文檔是否準確？設(shè)計邏輯是否正確？即，程序是否會完成所需的功能？設(shè)計是否與所描述的操作環(huán)境相一致？界面的設(shè)計是否與文檔所描述的界面部分一致？對于設(shè)計者不能選擇的輸入輸出和數(shù)據(jù)庫成分的數(shù)據(jù)格式、內(nèi)容和數(shù)據(jù)率，設(shè)計是否正確地給予了安排？第五十六頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—可行性所設(shè)計的模型、算法和數(shù)值方法對于應(yīng)用領(lǐng)域來說是否可以接受？設(shè)計能否在所規(guī)定的限制條件下和開發(fā)代價下實現(xiàn)？在可用的資源條件下，所設(shè)計的功能能實現(xiàn)嗎？第五十七頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—易修改性設(shè)計是否使用了信息隱藏技術(shù)？模塊的組織使對一條需求的改變只影響較少的模塊對于可能改變的數(shù)據(jù)與函數(shù)的結(jié)構(gòu)的設(shè)計使它門的界面對于單個函數(shù)的改變不敏感將數(shù)據(jù)結(jié)構(gòu)的取接、數(shù)據(jù)庫的取接和I/O的取接從應(yīng)用程序中分離開來，并使用專門的程序來完成之，不使用全局可取接的數(shù)據(jù)功能分解成一系列子程序，使每一個子程序都具有最大限度的內(nèi)部緊密聯(lián)系和最低限度的互相依賴高內(nèi)聚、低耦合每一個子程序都只有一個功能嗎？第五十八頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—模塊性是否采用了模塊化的機制？設(shè)計是否使軟件系統(tǒng)由一系列相對來說較小的、以層次結(jié)構(gòu)相互聯(lián)系的子程序組成？是否每一個子程序都只完成一個特定的功能？設(shè)計是否使用了特殊的規(guī)則來限制子程序的大??？第五十九頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—可預(yù)測性設(shè)計是否包含了子程序來提供在已經(jīng)標識出的出錯情況下所需的反應(yīng)？所設(shè)計的計算機資源調(diào)度方式是否是確定的和可預(yù)測的，而不是動態(tài)的？設(shè)計是否使用了盡量少的中斷和事件驅(qū)動，對使用這樣的功能是否進行了論證？是否設(shè)計了在程序的運行過程中進行正確性檢查來發(fā)現(xiàn)運行時刻的錯誤和違反運行許可的情況？第六十頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—結(jié)構(gòu)化設(shè)計是否使用了層次式的邏輯控制結(jié)構(gòu)？第六十一頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—易追溯性設(shè)計文檔中是否包含設(shè)計與需求定義中的需求、設(shè)計限制等內(nèi)容的對應(yīng)關(guān)系？設(shè)計是否標識出了設(shè)計中所包含的需求定義之外的功能？是否對所有函數(shù)都進行了適當(dāng)?shù)臉俗R使代碼能夠唯一地引用該標識？設(shè)計規(guī)約是否包含修改歷史記錄，并使所有的對設(shè)計的修改和修改理由都記錄在內(nèi)并賦以編號了？設(shè)計規(guī)約是否包含了設(shè)計備案文檔并記錄了與設(shè)計有關(guān)的決策？第六十二頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—易理解性設(shè)計是否避免了不必要的成分和表達形式？設(shè)計文檔是否不致造成歧義性解釋？第六十三頁，共七十八頁，2022年，8月28日設(shè)計文檔的靜態(tài)測試對照條例—可驗證性/易測試性設(shè)計中對每一個函數(shù)的描述是否都使用了良好的術(shù)語和符號？是否可以驗證它與需求定義相一致？是否定量地說明了使用條件、限制等內(nèi)容？是否可以由此產(chǎn)生測試數(shù)據(jù)？第六十四頁，共七十八頁，2022年，8月28日源代碼的靜態(tài)測試對源代碼的靜態(tài)測試著重于分析實現(xiàn)是否正確、完備。第六十五頁，共七十八頁，2022年，8月28日源代碼的靜態(tài)測試對照條例—完備性代碼是否完全、準確地實現(xiàn)了設(shè)計規(guī)約中所規(guī)定的內(nèi)容？代碼是否滿足設(shè)計要求？代碼是否創(chuàng)建了所需的數(shù)據(jù)庫或其它初始化數(shù)據(jù)？是否有未引用的或未定義的變量、常量或數(shù)據(jù)類型？第六十六頁，共七十八頁，2022年，8月28日源代碼的靜態(tài)測試對照條例—一致性代碼在邏輯上與設(shè)計規(guī)約一致嗎？是否自始至終使用了相同的格式、調(diào)用約定、結(jié)構(gòu)等等？第六十七頁，共七十八頁，2022年，8月28日源代碼的靜態(tài)測試對照條例—正確性代碼是否符合標準？變量的定義和使用都正確嗎？注釋是否正確？子程序調(diào)用的參數(shù)個數(shù)正確嗎？