上课第四章.ppt

測試的種類 最初的測試焦點是在元件的層級，且經常稱為單元測試(unit testing)。 其他測試的層級包括： 整合測試(integration testing)(當系統被建構後導入)； 驗證測試(validation testing)評估整個系統(或軟體增量)中，是否已經完全符合需求；和 接受測試(acceptance testing)是由顧客所導入，以儘力操練所有必要的性能與功能。 5.5.1 編碼原則與概念 指導編碼任務的原則與概念和編程型態(programming style)、程式語言、編程方法有密切的關係。其基本原則如下： 準備原則：在撰寫任一行程式前，你要確定： 瞭解你嘗試要解決的問題。 瞭解基本的設計原則與概念。 選擇程式設計語言以符合軟體被建構的需要，和它所運作的環境。 選擇編程環境以提供使你的工作變得更為容易的工具。 創造一組單元測試，一旦你所編寫的程式完成後，它將會被應用。 編碼原則與概念 編碼原則：當你開始撰寫程式碼時，你要確定： 藉由遵循結構化程式設計實務，限制你的演算法。 選擇符合設計需要的資料結構。 瞭解軟體架構，並創造與它一致的介面。 保持條件邏輯儘可能地簡單。 用可容易測試的方式創造巢狀迴圈。 選擇有意義的變數名稱，並遵循其他局部的編碼標準。 撰寫可自我說明(self-documenting)的程式碼。 創造視覺化的排版(例如，縮排與空行)，以幫助瞭解。 編碼原則與概念 確認原則(Validation Principles)：當你已經完成第一回編碼後，你得確定： 適當時機實施程式碼排練(walkthrough)。 執行單元測試，並修正你所發現的錯誤。 重構(refactor)程式碼。 建構的一般任務組 5.5.2 測試原則 軟體測試的目的是什麼？ 在一本經典軟體測試的書中，Glen Myers陳述許多可作為測試目的良好規則： 測試是以發現錯誤的意圖執行程式的一種流程。 良好的測試情況是有很高機率發現一個尚未發現的錯誤。 成功的測試是發掘出到目前尚未發現的錯誤。 測試的基本原則 Davis所建議一組測試原則： 原則 #1：所有的測試對顧客的需求都應該是可追蹤的。 軟體測試的目的是發掘錯誤。它遵循著最嚴格的缺陷(the most severe defects)(從顧客的觀點)就是那些造成程式失效的卻是它的需求。 原則 #2：在開始測試之前，它就應該先被計畫。 測試計劃(第13章)可於分析模型完成後隨即開始。 測試案例的詳細定義可以在設計模型確定後隨即開始。 所有測試可以在任何程式碼產生以前進行計劃與設計。 測試的基本原則 原則 #3：將Pareto原則應用於軟體測試。 簡單地說，Pareto原則意謂著於測試期間所有的80%錯誤都可以在所有的2 0%程式元件中追蹤到。 問題是如何將這些可疑的元件隔離，並且徹底地測試它們。 原則 #4：測試應該從「小的」開始，然後再進展到「大的」。 第一個被測試與執行的計畫通常聚焦於個別的元件。 當測試向前進展後，則嚐試將焦點移往整合的元件群集(clusters)與最終移至整個系統，以發現錯誤。 測試的基本原則 原則 #5：徹底的測試(exhaustive testing)是不可能的。 對一個普通規模的程式而言，其路徑排列的數目也是特別多的。 測試期間要執行每個路徑的組合是不可能的。 有可能的是，含括足夠程式邏輯與確保元件層級設計的所有情況都已經被操練過(第14章)。 一般的測試任務組 5.6 部署(Deployment) 部署活動含括三個動作(actions)： 交付(delivery) 支援(support) 回饋(feedback) 現代的軟體流程模型是自然演進的，部署的發生不只一次，而其中的許多次是軟體朝向完成的過程中所發生的。 每個交付周期提供顧客與終端使用者可以運作的軟體增量，此增量提供可以使用的功能與性能。 每個支援周期對所有在部署周期期間內所引入的功能與性能，提供文件與人員的協助。 每個回饋周期提供軟體團隊重要的指導，其對功能、性能與方式修正的結果將提供給下個增量。 部署的關鍵原則 對任何軟體專案而言，軟體增量的交付代表著一個重要的里程碑。 當團隊準備交付軟體增量時，許多關鍵的原則應該被遵循： 原則 #1：顧客對軟體的期望一定要管理。 顧客的期望經常超過團隊所答應交付的，使得失望立即發生。 此一回饋的結果並不具有生產力，但卻毀掉團隊的士氣。 在Naomi Karten有關管理期望的書中說道：「為管理期望而對於你溝通些什麼與如何溝通的起始點變得更為煞費苦心」。她建議軟體工程師一定要小心地將相關的矛盾訊息(即許下超過你能於所提供的限期內合理交付的承諾，或對某個軟體增量交付超過你所承諾的，然後對下一個軟體增量則少於你所承諾的)傳達