实作及整合阶段.PPTVIP

第九章 實作及整合階段 議題 簡介 實作及整合 實作與整合階段的測試 圖形介面的整合測試 產品測試 接受度測試 實作與整合階段的CASE工具 整合環境 簡介 實作階段進行每一個模組(或物件)的實作，也就是程式撰寫(Coding)的工作。 整合階段，所有的模組會整合成一個系統並進行測試。 實作與整合階段的工作應該要並行進行 。 實作及整合 待解決的難題 提供模組測試用的「stub」 錯誤點隔離(Fault Isolation) 方式如下列所示 由上而下之實作與整合 由下而上之實作與整合 三明治之實作與整合 物件導向軟體實作與整合的方式 模組流程圖 由上而下(Top-Down)的實作與整合 若模組mTop呼叫模組mDown，則mTop會在mDown之前進行實作及整合。 根據所設計的模組流程圖，其實作及整合的順序有兩種 m1、m2、m3、m4、m5、m6、m7、m8、m9、m10、m11、m12及m13； 以群組進行編碼，則為 m1、「m2、m5、m8」、「 m3、m4、m6、m9」、「 m7、m10、m11、m12、m13 」 由上而下(Top-Down)的實作與整合 優點 在軟體開發早期就會顯示設計上的主要的缺失。 缺點 需要重複使用的模組可能無法進行適當地測試。 例如，底層的操作模組 由下而上(Bottom-Up)的實作及整合 若模組mUp呼叫模組mBottom，則mBottom會較mUp先進行實作與整合。 根據所設計的模組流程圖，其實作及整合的順序有兩種 m12、m13、m8、m9、m10、m11、m5、m6、m7、m2、m3、m4及m1； 以群組進行編碼，則為「m8、m5及m2」、「m9、m6及m3」、「m12、m13、m10、m11及m7」，m4、m1 由下而上(Bottom-Up)的實作及整合 優點 default isolation的優勢 操作模組可以仔細測試 缺點 主要的設計錯誤會很遲才會在整合階段中發現，而邏輯模組是最後整合的模組。 三明治(Sandwich)實作及整合 根據所設計的模組流程圖，其實作及整合的方式為 m1、m2、m3、m4、m7、m10為邏輯模組 ，以由上而下方式進行實作與整合。 m5、m6、m8、m9、m11、m12及m13，實作與整合方法是由下而上。 當所有的模組已整合完成時，在二模組群組間的介面會一個個進行測試 各種實作與整合方式的優缺點 物件導向軟體系統的實作及整合 由上而下的方式進行 物件內的每一個方法將如上述傳統由上而下實作與整合的方式，撰寫相對的stubs 由上而下的方式進行 首先物件不會傳送任何的訊息給其他實作與整合的物件， 爾後物件會傳送訊息至其他物件進行實作與整合， 依此方式進行，直到所有的物件實作整合完成為止。 三明治實作整合的方法 物件視為如前述操作模組，來進行由上而下的實作與整合， 然後非物件的邏輯模組以由上而下的方式實作與整合 ， 最後再將其與相關物件整合。 實作與整合階段的測試 對於每一個新的模組而言 單元測試(Unit Test) 軟體擁有圖形化使用者介面 圖形介面整合測試(Integration Tesing) 產品測試(Product Testing) 接受度測試(Acceptance Testing) 圖形介面的整合測試 撰寫測試案例(Test Cases) 進行回歸性測試(regression testing) 提供GUI介面自動化測試的工具 以錄製撥放(Record and Replay) 方式 特定的描述語言(Script)撰寫測試案例 產品 IBM Rational的Robot (Windows Platform) Mercury Interactive 的X Runner (UNIIX) Seapine的QA Wizard for Web 產品測試 為了要保證接受度測試（acceptance testing）成功，SQA小組必須要進行軟體產品測試（product testing） 以相當接近接受度測試的方式 採用黑箱( black-box )測試 強健性( robustness )測試 壓力( stress )測試 巨量( volume )測試 接受度測試 客戶根據接受度測試（acceptance testing）來確認軟體產品所有的特性，是否符合開發人員與其客戶所擬定的需求內容。 四個主要的任務 測試正確性、 強健性、 執行效能、 撰寫文件 一旦軟體產品通過接受度測試，開發人員的任務即告完成，往後軟體產品任何的修改動作均會在維護期間進行。 實作與整合階段的CASE工具 元件整合 、版本控制工具、建構工具和組態管理工具 前端工具(Front-end Tool)