【正文】 的其他人員報(bào)告其文檔，所發(fā)現(xiàn)的錯(cuò)誤或懷疑是錯(cuò)誤的問題則由召集人記錄在案。 ? 審閱的中心問題是發(fā)現(xiàn)錯(cuò)誤而不是糾正錯(cuò)誤，在結(jié)構(gòu)化走通的審閱后，由文檔的產(chǎn)生者負(fù)責(zé)記錄在案的錯(cuò)誤糾正。 ? 結(jié)構(gòu)化走通成功的關(guān)鍵是事先的準(zhǔn)備，報(bào)告者必須在事先選擇對(duì)審閱最能有所貢獻(xiàn)的人員參加，推舉最能有效地組織和執(zhí)行審閱的人員擔(dān)當(dāng)召集人，并選擇適當(dāng)?shù)臅r(shí)間和地點(diǎn)，被審閱的文檔必須事先散發(fā)給審閱參加者，并留有充足的時(shí)間讓審閱者在審閱會(huì)議之前進(jìn)行檢查，準(zhǔn)備工作越充分，結(jié)構(gòu)化審閱就會(huì)越有效率。 測(cè) 試 靜態(tài)測(cè)試方法（ Fagan檢查） ? Fagan檢查是在一般的檢查技術(shù)的基礎(chǔ)上發(fā)展起來的，其總的原理與結(jié)構(gòu)化走通非常相似。 ? Fagan檢查將審閱放在一個(gè)質(zhì)量計(jì)劃、度量和控制的更廣泛的環(huán)境下，使之具有雙重目的：第一，發(fā)現(xiàn)產(chǎn)品中的錯(cuò)誤；第二，通過對(duì)錯(cuò)誤的統(tǒng)計(jì)，提供今后對(duì)所發(fā)現(xiàn)的同類錯(cuò)誤進(jìn)行控制的數(shù)據(jù)。 ? Fagan檢查旨在發(fā)現(xiàn)錯(cuò)誤，而不是改正錯(cuò)誤；強(qiáng)調(diào)對(duì)錯(cuò)誤進(jìn)行分類和統(tǒng)計(jì)，從而發(fā)現(xiàn)共同 的錯(cuò)誤類型和將來避免這類錯(cuò)誤的方法。簡(jiǎn)言之， Fagan檢查強(qiáng)調(diào)對(duì)開發(fā)過程的反饋和從錯(cuò)誤中吸取教訓(xùn)。 測(cè) 試 靜態(tài)測(cè)試內(nèi)容 ? 需求定義的靜態(tài)測(cè)試 對(duì)需求定義的靜態(tài)測(cè)試著重于測(cè)試對(duì)用戶需求的描述和解釋是否完整、準(zhǔn)確。 ? 設(shè)計(jì)文檔的靜態(tài)測(cè)試 對(duì)設(shè)計(jì)文檔的靜態(tài)測(cè)試著重于分析設(shè)計(jì)是否與需求定義一致。 ? 源代碼的靜態(tài)測(cè)試 對(duì)源代碼的靜態(tài)測(cè)試著重于分析實(shí)現(xiàn)是否正確、完備。 測(cè) 試 需求定義的靜態(tài)測(cè)試 ? 兼容性 界面需求是否使軟件硬件系統(tǒng)具有兼容性？ ? 完備性 需求定義是否包含了有關(guān)文件（指質(zhì)量手冊(cè)、質(zhì)量計(jì)劃以及其他有關(guān)文件）中所規(guī)定的需求定義所應(yīng)該包含的所有內(nèi)容？ ? 一致性 各個(gè)需求之間是否一致？是否有沖突和矛盾？ ? 正確性 需求定義是否滿足標(biāo)準(zhǔn)的要求？ ? 可行性 需求定義是否使軟件的設(shè)計(jì)、實(shí)現(xiàn)、操作和維護(hù)都可行？ ? 易修改性 對(duì)需求定義的描述是否易于修改（例如，是否采用良好的結(jié)構(gòu)和交叉引用表等）？ ? 健壯性 是否有容錯(cuò)的需求？ ? 易追溯性 是否可以從上一階段的文檔查找到需求定義中的相應(yīng)內(nèi)容？ ? 易理解性 是否每一個(gè)需求都只有一種解釋？ ? 易測(cè)試性和可驗(yàn)證性 需求是否可以驗(yàn)證？（即是否可以檢驗(yàn)軟件是否滿足了需求？） 測(cè) 試 設(shè)計(jì)文檔的靜態(tài)測(cè)試 ? 完備性 軟件設(shè)計(jì)規(guī)約是否包含了有關(guān)文件（指質(zhì)量手冊(cè)、質(zhì)量計(jì)劃以及其他有關(guān)文件）中所規(guī)定的所有內(nèi)容？ ? 一致性 在設(shè)計(jì)文檔中，是否始終使用標(biāo)準(zhǔn)的術(shù)語和定義？文檔的風(fēng)格和詳細(xì)程度是否前后始終一致？ ? 正確性 設(shè)計(jì)文檔是否滿足有關(guān)標(biāo)準(zhǔn)的要求？ ? 可行性 所設(shè)計(jì)模型、算法和數(shù)值方法對(duì)于應(yīng)用領(lǐng)域來說是否可以接受？ ? 易修改性 設(shè)計(jì)是否使用了信息隱蔽技術(shù)從而方便于修改？ ? 模塊性 是否采用了模塊化的機(jī)制？ 測(cè) 試 設(shè)計(jì)文檔的靜態(tài)測(cè)試 ? 健壯性 設(shè)計(jì)是否覆蓋了需求定義中所要求的容錯(cuò)和故障弱化指標(biāo)？ ? 結(jié)構(gòu)化 設(shè)計(jì)是否使用了層次式的邏輯控制結(jié)構(gòu)？ ? 易追溯性設(shè)計(jì)文檔中是否包含設(shè)計(jì)與需求定義中的需求、設(shè)計(jì)限制等內(nèi)容的對(duì)應(yīng)關(guān)系？ ? 易理解性 設(shè)計(jì)是否避免了不必要的成分和表達(dá)形式？設(shè)計(jì)文檔是否不致造成歧義性解釋？ ? 可驗(yàn)證性 /易測(cè)試性 設(shè)計(jì)中對(duì)每一個(gè)模塊的描述是否都使用了良好的術(shù)語和符號(hào)？是否可以驗(yàn)證它與需求定義相一致？是否定量地說明了使用條件、限制等內(nèi)容？是否可以由此產(chǎn)生測(cè)試數(shù)據(jù)？ 測(cè) 試 源代碼的靜態(tài)測(cè)試 ? 完備性 代碼是否完全、準(zhǔn)確地實(shí)現(xiàn)了設(shè)計(jì)說明書中所規(guī)定的內(nèi)容？代碼是否滿足設(shè)計(jì)要求？代碼是否創(chuàng)建了所需的數(shù)據(jù)庫或其他初始化數(shù)據(jù)？是否有未引用的或未定義的變量、常量或數(shù)據(jù)類型？ ? 一致性 代碼在邏輯上與設(shè)計(jì)說明一致嗎？是否自始致終地使用了相同的格式、調(diào)用約定、結(jié)構(gòu)等等？ ? 正確性 代碼是否符合標(biāo)準(zhǔn)？變量的定義和使用都正確嗎？注釋是否準(zhǔn)確？過程調(diào)用的參數(shù)個(gè)數(shù)和類型正確嗎？ ? 易修改性 代碼中對(duì)常數(shù)的使用是否都通過符號(hào)來進(jìn)行使其便于修改？是否有交叉引用表或數(shù)據(jù)字典來表明程序?qū)ΤＡ亢妥兞康娜〗?？代碼是否有單入口、單出口的結(jié)構(gòu)組成？代碼是否避免了直接使用地址，而采用標(biāo)號(hào)和符號(hào)常量？ 測(cè) 試 源代碼的靜態(tài)測(cè)試 ? 可預(yù)測(cè)性 是否避免了使用自我修改的代碼？是否避免了依賴于程序設(shè)計(jì)語言中的缺省值的代碼？代碼是否包含無窮循環(huán)？ ? 健壯性 代碼是否防止可以發(fā)現(xiàn)的運(yùn)行時(shí)刻的錯(cuò)誤？如下標(biāo)變量越界、除數(shù)為零、變量值越界、棧溢出等等。 ? 結(jié)構(gòu)化 程序的每一個(gè)功能是否都可以作為一塊代碼而識(shí)別出？循環(huán)是否只有一個(gè)入口？ ? 易追溯性 是否有一個(gè)交叉引用表，通過它可以便捷地從代碼找到相應(yīng)的設(shè)計(jì)？ ? 易理解性 注釋是否使用了簡(jiǎn)潔明了的語言對(duì)每一個(gè)過程都作了充分的描述？是否使用了便于記憶的命名約定？命名是否反映了變量的類型？變量的有效值域是否定義了？ ? 可驗(yàn)證性 實(shí)現(xiàn)是否避免了使用測(cè)試難度大的技術(shù)和方法？ 測(cè) 試 動(dòng)態(tài)測(cè)試 ? 所謂動(dòng)態(tài)測(cè)試，就是通過運(yùn)行軟件來檢驗(yàn)軟件的動(dòng)態(tài)行為和運(yùn)行結(jié)果的正確性； ? 運(yùn)行軟件并非動(dòng)態(tài)測(cè)試的目的，通過運(yùn)行來檢驗(yàn)軟件是否正確才是動(dòng)態(tài)測(cè)試的真正目的； ? 動(dòng)態(tài)測(cè)試包括三個(gè)基本要素： 被測(cè)試程序； 用以運(yùn)行軟件的數(shù)據(jù)，稱為測(cè)試數(shù)據(jù)。 軟件需求規(guī)格說明。 測(cè) 試 一個(gè)成熟的動(dòng)態(tài)測(cè)試方法必須回答如下問題： ? 如何選擇或產(chǎn)生測(cè)試數(shù)據(jù)？ ? 如何組織軟件的測(cè)試運(yùn)行？ ? 如何考察和記錄軟件動(dòng)態(tài)運(yùn)行的行為？ ? 如何判斷軟件動(dòng)態(tài)行為的正確性？ ? 測(cè)試過程何時(shí)結(jié)束？ ? 如何通過軟件測(cè)試結(jié)果分析軟件性質(zhì)？ 測(cè) 試 按照選擇或產(chǎn)生測(cè)試數(shù)據(jù)所根據(jù)的信息的來源，動(dòng)態(tài)測(cè)試方法可以分為： ? 以程序?yàn)榛A(chǔ)的測(cè)試 ? 以需求和功能說明為基礎(chǔ)的測(cè)試 ? 程序與需求相結(jié)合的測(cè)試 ? 以界面為基礎(chǔ)的測(cè)試 測(cè) 試 按照選擇或產(chǎn)生測(cè)試數(shù)據(jù)以及判斷測(cè)試充分性的方法，動(dòng)態(tài)測(cè)試方法可以分為： ? 結(jié)構(gòu)測(cè)試（白箱測(cè)試） ? 功能測(cè)試（黑箱測(cè)試） 測(cè) 試 結(jié)構(gòu)測(cè)試（白箱測(cè)試）： ? 結(jié)構(gòu)測(cè)試詣在充分地覆蓋軟件的結(jié)構(gòu)，并以軟件中的某類成分是否都已得到測(cè)試為準(zhǔn)則來判斷軟件測(cè)試的充分性 測(cè) 試 窮盡結(jié)構(gòu)測(cè)試 例：一段程序?qū)η短椎?IF語句執(zhí)行 20次，共有 520?1014條通路， 若每執(zhí)行一次需 1毫秒，則需 3000年。 測(cè) 試 功能測(cè)試（黑箱測(cè)試）： ? 功能測(cè)試根據(jù)軟件所需的功能和所實(shí)現(xiàn)的功能選擇測(cè)試數(shù)據(jù)，分析測(cè)試的充分性 測(cè) 試 窮盡功能測(cè)試 例：一個(gè)程序需 3個(gè)整型的輸入數(shù)據(jù)，若計(jì)算機(jī)的字長(zhǎng)為 16位，則每個(gè)數(shù)據(jù)可能取的值有 216個(gè)， 3個(gè)數(shù)的排練組合共有 216 ? 216 ? 216 = 248 ? 3 ? 1014 （種） 若每執(zhí)行一次需 1毫秒，則需 1萬年。 測(cè) 試 軟件測(cè)試的步驟： ? 單元測(cè)試 ? 組裝測(cè)試 ? 有效性測(cè)試 ? 系統(tǒng)測(cè)試 測(cè) 試 單元測(cè)試 ? 單元測(cè)試集中檢驗(yàn)軟件設(shè)計(jì)中最小單元 模塊。 ? 根據(jù)詳細(xì)設(shè)計(jì)的說明，應(yīng)測(cè)試重要的控制路徑，力求在模塊范圍內(nèi)發(fā)現(xiàn)錯(cuò)誤。 ? 由于測(cè)試范圍有限，測(cè)試不會(huì)太復(fù)雜，所能發(fā)現(xiàn)的 錯(cuò)誤也是有限的。 ? 單元測(cè)試總是采用白箱測(cè)試方法，而且可以多個(gè)模塊并行進(jìn)行。 測(cè) 試 單元測(cè)試的內(nèi)容 ? 模塊接口 ? 局部數(shù)據(jù)結(jié)構(gòu) ? “重要的”運(yùn)行路徑 ? 出錯(cuò)處理路徑 ? 影響以上各點(diǎn)的邊界條件 測(cè) 試 單元測(cè)試的過程 ? 單元測(cè)試和編碼屬于軟件開發(fā)的同一階段。 ? 模塊并不是獨(dú)立的程序，必須為每個(gè)單元測(cè)試開發(fā)驅(qū)動(dòng)模塊和承接模塊。 ? 驅(qū)動(dòng)模塊：是一個(gè)“主程序”。接收測(cè)試數(shù)據(jù)，把這些數(shù)據(jù)傳送給被測(cè)模塊，并且打印結(jié)果。 ? 承接模塊：用以代替被測(cè)試模塊所調(diào)用的模塊，采用被代替模塊的接口，可以做很少的數(shù)據(jù)處理，打印數(shù)據(jù)，并把控制返回給被測(cè)模塊。 ? 驅(qū)動(dòng)模塊和承接模塊是一種額外的開銷，也就是說，它們都是必須編寫的軟件，但卻不作為最終的軟件產(chǎn)品提供給用戶。 測(cè) 試 組裝測(cè)試 ? 在把經(jīng)過單元測(cè)試的模塊按照設(shè)計(jì)要求組裝起來的過程中進(jìn)行測(cè)試，重點(diǎn)查找與接口有關(guān)的錯(cuò)誤。 ? 與接口有關(guān)的錯(cuò)誤包括： 數(shù)據(jù)穿過接口時(shí)可能丟失； 某個(gè)模塊對(duì)另一個(gè)模塊可能產(chǎn)生不利的影響； 把子功能組合起來可能不產(chǎn)生預(yù)期的主功能； 個(gè)別原可以接受的誤差可能累計(jì)到不能接受的程度； 全程數(shù)據(jù)結(jié)構(gòu)可能有問題。 測(cè) 試 組裝測(cè)試方法 ? 自頂向下組裝測(cè)試方法：按照控制的結(jié)構(gòu)，從主控模塊（主程序）開始，向下逐個(gè)把模塊連接起來進(jìn)行測(cè)試。把附屬于主控模塊的子模塊孫模塊等等組裝起來的方式有兩種，先縱深組裝法和先橫寬組裝法。 ? 自底向上組裝測(cè)試方法：按照控制結(jié)構(gòu)，從最基本的模塊（即在軟件結(jié)構(gòu)中最低層的模塊）開始進(jìn)行組裝及測(cè)試。正是因?yàn)槭菑淖畹蛯舆M(jìn)行組裝，在逐步處理以上層次的模塊時(shí)所需要的子模塊總是可以得到的，所以不再需要承接模塊了。 測(cè) 試 自頂向下組裝測(cè)試過程 （ 1）主控模塊用做為測(cè)試驅(qū)動(dòng)模塊，直接附屬于主控模塊的各個(gè)模塊全部用承接模塊代替； （ 2）按照所選的組裝法（先縱深或先橫寬）每次用一個(gè)真模塊取代一個(gè)附屬的承接模塊； （ 3）在裝入每個(gè)真模塊后進(jìn)行一次測(cè)試； （ 4）做完每一次測(cè)試后再用一個(gè)真模塊代替另一個(gè)承接模塊； （ 5）必要時(shí)進(jìn)行回歸測(cè)試（即重新再做過去的全部或部分測(cè)試）以保證新加的模塊沒有引起新的錯(cuò)誤。 測(cè) 試 自底向上組裝測(cè)試過程 （ 1）把低層模塊組合起來形成某個(gè)特定的軟件子功能簇； （ 2）編寫一個(gè)驅(qū)動(dòng)模塊以安排測(cè)試數(shù)據(jù)的輸入輸出； （ 3）對(duì)簇進(jìn)行測(cè)試； （ 4）拆去各個(gè)小簇的驅(qū)動(dòng)模塊，把幾個(gè)小簇合并成大簇，重復(fù)（ 2）（ 3）（ 4）。 測(cè) 試 組裝測(cè)試方法比較 ? 自頂向下組裝法：不需要驅(qū)動(dòng)模塊；能夠在測(cè)試階段早期驗(yàn)證系統(tǒng)的主要功能，早期發(fā)現(xiàn)接口錯(cuò)誤；需要較多的承接模塊，可能遇到與之相聯(lián)系的測(cè)試?yán)щy；低層關(guān)鍵模塊中的錯(cuò)誤發(fā)現(xiàn)較晚。 ? 自底向上組裝法：不需要承接模塊；需要較多的驅(qū)動(dòng)模塊；在最后一個(gè)模塊裝入之前，軟件實(shí)體并不存在。 ? 一般使用兩種方法的結(jié)合，測(cè)試階段早期采用自頂向下組裝法，后期采用自底向上組裝法，很多情況下二者可以同時(shí)進(jìn)行。 測(cè) 試 組裝測(cè)試文件（測(cè)試說明書） 1. 測(cè)試范圍 2. 測(cè)試計(jì)劃 ? 測(cè)試方面（把測(cè)試劃分為幾個(gè)方面，分別測(cè)試軟件的各種特性） ? 進(jìn)度 ? 額外軟件（驅(qū)動(dòng)模塊和承接模塊） ? 環(huán)境與資源 3. 測(cè)試步驟 ? 第 n測(cè)試 階段的說明：組裝的次序；測(cè)試目的和應(yīng)測(cè)的模塊；專用的工具或技術(shù)；額外軟件的說明；測(cè)試用例數(shù)據(jù)。 ? 第 n測(cè)試階段的預(yù)期結(jié)果 4. 實(shí)際測(cè)試結(jié)果 5. 參考資料 6. 附錄 測(cè) 試 有效性測(cè)試（驗(yàn)證軟件系統(tǒng)的有效性） ? 軟件有效性：當(dāng)軟件的功能和性能如同用戶合理期待的那樣，則軟件是有效的。 ? 問題：怎樣算是合理的期望（需求說明）；誰是公斷人（測(cè)試人員）。 ? 方法：黑箱測(cè)試法。 ? 標(biāo)準(zhǔn)：全部的功能要求都得到滿足；全部的性能要求都達(dá)到了；文檔是正確的并且便于使用；其它要求也達(dá)到了（包括易維護(hù)性、易移植性、兼容性、出錯(cuò)自動(dòng)恢復(fù)等）。 ? 可能出現(xiàn)的結(jié)果：功能與性能與技術(shù)要求一致；發(fā)現(xiàn)與技術(shù)要求不一致的地方（與用戶協(xié)商）。 ? 軟件系列文件復(fù)審：確認(rèn)軟件系列文件的各個(gè)部分都已做好，已經(jīng)編目，并有必要的細(xì)節(jié)說明，作為以后維護(hù)階段的基本資料。 測(cè)