【正文】 程序的響應(yīng)率50%的變化。對于那些不熟悉的應(yīng)用程序，使用者在 15 到 30 秒意外的延遲（也就是他們短期記憶的半衰期）后會很焦慮。 答案略。 如果你想要給你的學(xué)生一些工作項目表的范例，互聯(lián)網(wǎng)是一個很好的可用性調(diào)查表的來源（大部分都應(yīng)該有超過 20 道的問題，所以你的學(xué)生應(yīng)該需要優(yōu)先考慮他們的選擇） 第十四章 用自己的話描述驗證與確認(rèn)的區(qū)別。兩者都要用測試用例的設(shè)計方法和測試策略嗎？ 答： “驗證”是通過嘗試在功能或性能上發(fā)現(xiàn)錯誤來保證程序的正確性，“確認(rèn)”是保證軟件與需求相一致 —— 這也是質(zhì)量的基本特征。 列出一些可能與獨立測試組（ ITG）的創(chuàng)建相關(guān)的問題。 IGT 與 SQA 小組由相同的人員組成嗎？ 答： 組建 ITG（獨立測試組）最常見的問題是獲得并留住人才，除此之外，如果 ITG 與軟件工程小組的交流組織地不恰當(dāng)?shù)脑?，兩組之間可能會產(chǎn)生敵意。最后， ITG 有可能太晚接手項目，導(dǎo)致沒有時間完成一個周密測試的 計劃和執(zhí)行。 ITG 和 SQA（軟件質(zhì)量保證）小組不必是同一組人。 ITG 只關(guān)注測試， SQA 小組則需要考慮到質(zhì)量保證相關(guān)的所有方面。 使用 節(jié)中描述的測試步驟來建立測試軟件的策略總是可行的嘛？對于嵌入式系統(tǒng)，出現(xiàn)哪些可能的復(fù)雜情況？ 答： 它并不總是能夠進行單元測試的測試環(huán)境，完成單元測試的復(fù)雜性（ 如 復(fù)雜的 驅(qū)動 和存根）可能無法證明效益。集成測試是 復(fù)雜的 通過單元測試的模塊合并計劃的有效性（特別是當(dāng)這些模塊滯后 的時候 ）。在很多情況下（尤其是嵌入式系統(tǒng)）軟件不能充分進行驗證測試硬件配置外 的 目標(biāo)。因此， 驗證和系統(tǒng)測試 要 相結(jié)合。 為什么對具有較高耦合度的模塊進行單元測試？ 答： 一個高度耦合的模塊 要 與其他模塊的數(shù)據(jù)和其他系統(tǒng)元素 進行交互 。因此，其功能往往是依賴于這些耦合元件的操作。為了徹底的單元測試 這樣 一個模塊，耦合因素的功能必須以某種方式模擬。 這將會是 困難和費時 的 。 “防錯法”的概念是一個非常有效的方法。當(dāng)發(fā)現(xiàn)錯誤時，他提供了內(nèi)置調(diào)試幫助： 。 。 。 答： 一個單一的規(guī)則涵蓋了多種情況：所有數(shù)據(jù)在軟件接口（外部和內(nèi)部）應(yīng) 當(dāng)經(jīng)過 驗證（如果可能的話）。 優(yōu)點：錯誤不 會 ―滾 雪球 ‖——越滾越大 缺點：需要額外的處理時間和內(nèi)存（ 那 通常 只 是一個很小的代價）。 項目的進度安排是如何影響集成測試的？ 答： 完成模塊的可用性的影響順序和戰(zhàn)略整合。項目狀態(tài)必須是已知的，可以成功地實現(xiàn)整合規(guī)劃。 在所有的情況下，單元測試都是可能的或是值得做的嗎？提供實例來說明你的理由。 答： 如果一個模塊有 3 或 4 個 下屬供應(yīng)數(shù)據(jù)模塊的一個有意義的評價 是至關(guān)重要的 ，沒有 ―聚類 ‖所有的模塊作為一個單元 ， 它可能無法進行單元測試。 誰應(yīng)該完成確 認(rèn)測試 —— 是軟件開發(fā)人員還是軟件的使用者，說明你的理由。 答： 開發(fā)商，如果客戶驗收測試計劃。開發(fā)人員和客戶（用戶）如果沒有進一步的測試計劃。一個獨立的測試組可能是這里最好的選擇，但這不是一個選擇。 為本書討論的 safehouse 系統(tǒng)開發(fā)一個完整的測試策略，并以測試規(guī)格說明的方式形成文檔。 答：略 作為一個班級項目，為你的安裝開發(fā)調(diào)試指南。這個指南應(yīng)該提供面向語言和面向系統(tǒng)的建議。這些建議是通過總結(jié)學(xué)校學(xué)習(xí)過程中所遇到的挫折得到的。從一個經(jīng)過全班和老師評審過的大綱開始，并在你局部范圍內(nèi)將這 個指南發(fā)布給其他人。 答：略 第十五章 Myers[mye79]用以下程序作為測試能力的自我評估：某程序讀入三個整數(shù)值表示三角形的三條邊。改程序打印信息表明三角形是不規(guī)則的，等腰的或等邊的。開發(fā)一組測試用例測試改程序。 答：參考 Myers[mye79]對此問題提出的 極其詳細的 ―解決方案 ‖。 設(shè)計并實現(xiàn) 描述的程序（適當(dāng)使用錯誤處理）。從該程序中導(dǎo)出流圖并用基本路徑測試方法設(shè)計測試，以保證程序中的所有語句都被測試到。執(zhí)行測試用例并顯示結(jié)果。 答： 你可以選擇發(fā)布程序源代碼 給 您的學(xué)生（ 故意地 嵌入一些錯誤）。 你能夠想出 節(jié)中沒有討論的其他測試目標(biāo)嗎？ 答： 除了 那些 目標(biāo) 之外還有 ： a) 一個成功的測試顯示功能和性能要求； b) 一個成功的測試發(fā)現(xiàn)文件錯誤； c) 一個成功的測試 發(fā)現(xiàn) 接口問題； d) 一個成功的 測試 驗證了程序結(jié)構(gòu)，了解數(shù)據(jù)結(jié)構(gòu)，界面設(shè)計和程序設(shè)計； e) 一個成功的測試，建立了一個進入一個測試案例數(shù)據(jù)庫，以后可以用于回歸測試。 選擇一個你最近設(shè)計和實現(xiàn)的構(gòu)建。設(shè)計一組測試用例，保證利用基本路徑測試執(zhí)行所有語句。 答：略 答：進行一些拓展， 這些問題可以被指定為一個長期的項目。 至少給出三個例子，在這些例子中，黑盒測試能給人“一切正?！钡挠∠?，而白盒測試可能發(fā)現(xiàn)錯誤。再至少給出三個例子，在這些例子中白盒測試能給人“一切正?！钡挠∠?，而黑盒測試可能發(fā)現(xiàn)錯誤。 答： 對于特定的輸入，一個 內(nèi)部發(fā)生的錯誤導(dǎo)致 ： 1) 不恰當(dāng)?shù)臄?shù)據(jù)被設(shè)在 一個全局 數(shù)據(jù)域里 ； 2) 不恰當(dāng) 的 標(biāo)記 將在隨后 進行 的一系列測試 中被測試 ； 3) 不恰當(dāng) 硬件控制，只 可 能在系統(tǒng)測試 時被發(fā)現(xiàn) ； 但是卻產(chǎn)生了正確的輸出 。 不，即使窮舉測試（如果可能的話）也 不能發(fā)現(xiàn)軟件說明書中的性能問題和錯誤。在這種情況下需要同時考慮輸入和輸出的等價類。對每一個類來說，學(xué)生應(yīng)當(dāng)根據(jù)數(shù)值范圍，集合的元素，系統(tǒng)命令等劃定邊界。這可以作為筆試以及一些著名應(yīng)用 GUI 的測試用例的素材 生成一系列用例來幫助測試用戶的文件材料是一個好辦法。 第十六章 用自己的話，描述為什么在面向?qū)ο笙到y(tǒng)中，類是最小的合理測試單元。 答： 類封裝了數(shù)據(jù)以及處理數(shù)據(jù)的操作。由于數(shù)據(jù)和操作被打包成一個整體，一個一個地測試方法沒有作用，不能發(fā)現(xiàn)與消息傳送，職責(zé)和協(xié)作相關(guān)的錯誤。 若現(xiàn) 有類已進行了徹底的測試，為什么我們必須對從現(xiàn)有類 實例化的子類進行重新測試？我們可以使用為現(xiàn)有類設(shè)計的測試用例么？ 答： 由于每一個子類都繼承了父類的私有屬性和操作（事實上這些私有屬性和操作會增加復(fù)雜度），這些子類必須在他們的操作環(huán)境中重新測試。測試用例可以重復(fù)使用，但需要針對子類的私有屬性和操作進行擴充。 ―測試 ‖應(yīng)該從面向?qū)ο蠓治龊驮O(shè)計開始？ 答： 在之后的開發(fā)過程中，面向?qū)ο蠓治龊驮O(shè)計模型提供了大量與系統(tǒng)結(jié)構(gòu)和行為相關(guān)的信息，因此，在生成代碼之前，這些模型必須經(jīng)過嚴(yán)格的審查。所有面向?qū)ο?的模型應(yīng)當(dāng)在模型的語法，語義以及語用論的上下中經(jīng)過正確性，完整性，一致性的測試（包括技術(shù)評審）。這些評審有可能省去很多不必要的工作和修改（錯誤越早發(fā)現(xiàn)，維護的成本越低）。 為 SafeHome 導(dǎo)出一組 CRC 索引卡片，按照 節(jié)講述的步驟確定是否存在不一致性。 答：答案會有不同 基于線程和基于使用的集成測試策略有什么不同？簇測試如何適應(yīng)？ 答： 基于線程的測試用來集成一系列需要對單獨一個程序輸入或事件響應(yīng)的類。基于使用的測試屬于集成測試的一種，通過測試那些很少使用服務(wù)器類的類（稱為獨立 類）開始系統(tǒng)的構(gòu)造。測試完獨立類之后，測試使用獨立類的下一層類（稱為依賴類），按照這樣的順序逐層測試依賴類直到整個系統(tǒng)構(gòu)造完成。 將隨機測試和劃分方法運用到設(shè)計 SafeHome 系統(tǒng)時定義的 3 個類。產(chǎn)生展示操作調(diào)用序列的測試用例。 答：答案會有不同 運用多類測試及從 SafeHome 設(shè)計的行為模型中生成的測試。 答：答案會有不同 運用隨機測試、劃分方法、多類測試及 節(jié)和 節(jié)所描述的銀行應(yīng)用的行為模型導(dǎo)出的測試，再生成另外生成 4 個測試。 答：答案會有不同 第十八章 基于本章給出的信息和自己的經(jīng)驗，列舉出能夠增強軟件工程師能力的“十條戒律”。即，列出 10 條指導(dǎo)原則，使得軟件人員能夠在工作中發(fā)揮其全部潛力。 答： （ 1） 你要 變得更聰明 。 （ 2） 你要注重質(zhì)量 。 （ 3）你要 傾聽客戶 。 （ 4）你要了解問題 （ 5） 你要 對 一個工作過程 不斷 的重復(fù) 。 （ 6） 你不可同意 荒唐 的時間表 。 （ 7） 你要測量產(chǎn)品，過程 和你自己 。 （ 8）你要制定 最有效的工作方法 。 （ 9） 你要記住，別人也會軟件工作 。 （ 10）你要不斷地提高。 SEI 的人員能力成熟度模型定義了培養(yǎng)優(yōu)秀軟件人員的“關(guān)鍵 實踐域”。你的老師將為你指派一個關(guān)鍵實踐域，請你對它進行分析和總結(jié)。 答：略。 描述 3 種現(xiàn)實生活中的實際情況，其中客戶和最終用戶是相同的人。也描述 3 種他們是不同人的情況。 答：相同的人： （ 1） 一個工程師必須開發(fā)一個供個人使用的 程序 。（ 2） 一個 商 人創(chuàng)建供個人使用的 電子表格模型 。（ 3） 一個 擁 有 迷人的手機客戶端這一新概念的 企業(yè)家 。 不同的人：（ 1） 一個 通信 部門的一些業(yè)務(wù)功能的 服務(wù) 。（ 2） 一個軟件開發(fā)團隊服務(wù)營銷的需求 。（ 3） 承包商建立 的 客戶的 規(guī)格 。 高級管理者所做的決策會對軟件工程團隊的效率產(chǎn) 生重大影響。也描述 3 種他們是不同人的情況。 答： 在今天的 環(huán)境，裁員和外包有最直接的、重大的影響 。 此外， “減少開支的措施 ”，導(dǎo)致較低的 產(chǎn)品質(zhì)量 ； 不切實際的項目最后期限 ；對用戶的需求了解失??；或者，反過來說，對軟件工程師的工作提出警告。 溫習(xí) Weiberg 的書 [Wei86]，并寫出一份 23 頁的總結(jié)，說明在使用 MOI 模型時應(yīng)該考慮的問題。 答案：略。 在一個信息系統(tǒng)組織中，你被指派為項目經(jīng)理。你的工作是開發(fā)一個應(yīng)用程序，該程序類似于你的團隊已經(jīng)做過的項目，只是規(guī)模更大而且更復(fù)雜。需求已經(jīng)由用 戶改寫成文檔。你會選擇哪種團隊結(jié)構(gòu)？為什么？你會選擇哪（些）種軟件過程模型？為什么？ 答： 一個封閉 范型 方法的團隊結(jié)構(gòu)是一種選擇 。由于需求明確， 這可能會要求和配置多個 分區(qū) 小組。規(guī)模大的項目緩和了利于 CD 團隊的方面。 由于沒有討論日程，我們假設(shè)的交貨日期是合理的。 因此，有可能使用一個線性的順序過程模型 。 然而，迭代模型（例如，螺旋）也是一個很好的可能性 。 你被指派為一個小型軟件產(chǎn)品公司的項目經(jīng)理。你的工作是開發(fā)一個有突破性的產(chǎn)品，該產(chǎn)品結(jié)合了虛擬現(xiàn)實的硬件和高超的軟件。因為家庭娛樂市場的競爭非常激烈，完成 這項工作的壓力很大。你會選擇哪種團隊結(jié)構(gòu)？為什么？你會選擇哪種過程模型？為什么？ 答： 隨機 式范型 的團隊結(jié)構(gòu)可能是唯一可行的選擇，給出了模糊的要求和工作性質(zhì)的實驗 。應(yīng)該使用原型開發(fā)方法或者一個 曾量 的過程模型。 你被指派為一個大型軟件產(chǎn)品公司的項目經(jīng)理。你的工作是管理該公司已被廣泛使用的字處理軟件的新版本的開發(fā)。由于競爭激烈，已