1、軟體工程第六版 第十三章 測試策略,軟體測試的策略,軟體測試的策略將軟體測試案例設計方法整合到一系列規劃良好的步驟中，以得到成功的軟體建構。 策略提供一個路線圖(road map)以描述被導入做為測試一部分的步驟、這些步驟何時被計畫並著手進行，和需要多少努力、時間與資源。 任何測試策略必須要合併測試計畫、測試案例設計、測試執行和結果資料的蒐集與評估。,軟體測試的策略,一個軟體測試策略應該有足夠的彈性以促進某種客製化的測試方式。 當計畫進展時，必須要夠嚴謹以促進合理的計畫與管理追蹤。 Shooman討論這些議題時說道： 測試是一種個人化的流程，而不同測試類型的數量變化就像發展方法一樣多。 多年來
2、，我們防護程式設計的錯誤只是很小心的設計與靠程式設計師的智慧。 現代設計的技術(和正式的技術檢視)可以協助我們減少繼承程式碼而來的初期錯誤數量。 不同的測試方法正在開始群集它們自己到某些較為顯著的方式與哲學。 這些方式與哲學就是我們所稱的策略(strategy)。 第14章中會說明軟體測試的技術。 本章聚焦於軟體測試的策略。,快速瀏覽,它是什麼？ 軟體被測試是要揭開在它設計與建構時所不經意產生的錯誤。 但是你要如何主導測試呢？ 你應該為你的測試發展正式的計畫嗎？ 你應該測試整個程式或只是其中的一小部分？ 當你將新的元件加入一個大系統時，應該重做你已經導入過的測試嗎？ 你何時應該涉及到顧客？ 當
3、你發展軟體測試策略時，這些與其他許多的問題都是要回答的。,快速瀏覽,誰完成它？ 軟體測試的策略是由專案經理、軟體工程師和測試專家所共同發展的。 它為何重要？ 測試時常要對比其他任何軟體工程活動投入更多的專案努力。如果它隨意地被導入，不但浪費時間與花費不必要的努力，甚至更糟的是未發現隱藏錯誤。因此，建立一套系統化策略的測試軟體似乎是合理的。,快速瀏覽,步驟為何？ 測試從小的開始，並且進展到大的。由此我們意味著早期的測試聚焦於單一元件或一小群相關的元件，並且應用測試揭發資料和已經含括於元件中的處理邏輯錯誤。在元件測試後，它們必須要整合，直到完整的系統被建構。此時，執行一系列高階的測試以在符合顧客的
4、需求中發現錯誤。當錯誤揭發時，它們必須使用稱為除錯的流程診斷與修正。 工作產品為何？ 測試規格(Test Specification)記載軟體團隊藉由定義一個描述整體策略、一個定義特定測試步驟和將被導入的測試程序的測試方式。,快速瀏覽,我如何確定我所做的是正確的？ 藉由在測試之前檢視測試規格，你可以評估測試案例與測試任務的完整性。有效的測試計畫與程序將導致有條理地建構軟體，並在建構流程中每一個階段錯誤的發現。,13.1 軟體測試的策略方法,測試是可以預先計畫與系統化導入的一組活動。 軟體測試的樣版 - 我們可以放置特定的測試案例技術與測試方法的一組步驟 - 應該為軟體流程而定義。 許多軟體測試
5、策略都提供軟體開發者樣版做為測試，且全部都具有下列的一般特性： 執行有效的測試，一個軟體團隊應該主導有效的正規技術檢視。 藉由執行此一檢視，許多錯誤將會在測試開始前就先被消除。 測試由元件層級開始，並向外朝著整個以電腦為基礎系統的整合。 不同的測試技術適用在不同的時間點上。 測試由軟體的開發者與獨立的測試群組所導入(對於大的計畫)。 測試與除錯是不同的活動，但是除錯必須被容納在任何的測試策略中。,軟體測試的策略範圍,軟體測試的策略必須要容納所必須要驗證的一小段原始碼已經正確地實作的低階測試，和以顧客的需求驗證主要系統功能的高階測試。 策略必須要對從業人士提供指導，並為經理人提供一組里程碑。 因
6、為當截止日期的壓力開始上升時，測試策略的步驟就會出現，進展必須是可量測的，且問題必須要盡快浮現。,13.1.1 驗證與確認,軟體測試是廣泛主題中的一項元素，它時常是以驗證與確認(verification and validation, V&V)而被提到。驗證(verification)依據活動組以確保軟體正確地實作特定的功能。確認(validation)依據一個不同的活動組以確保已建構的軟體對顧客的需求是可追蹤的1。Boehm BOE81 以另一種方法說明： 驗證：我們正確地建構產品嗎？ 確認：我們建構正確的產品嗎？ V&V的定義含括許多在軟體品質保證(software quality ass
7、urance, SQA)中的活動。,驗證與確認的活動內容,驗證與確認含括廣泛的SQA活動，它們包括正式的技術檢視、品質與組態審核、效能監控、模擬、可行性研究、文件檢視、資料庫檢視、演算法分析、發展測試、可用性測試、限定條件(qualification)測試和安裝測試。 測試確實提供最後的堡壘，其中的品質可被評估，錯誤可以被揭發。 測試不應該被視為一張安全網。 當他們說：你不能測試品質。如果在你開始測試前，它不在那裡的話，則在你完成測試後，它也不會在那裡。 品質被併入到遍及整個軟體工程流程的軟體中。 適當的方法與工具的應用、有效的正式技術檢視和穩固的管理與量測，全部都會導致在測試期間被確認的品質
8、。,品質保證的軟體測試,Miller陳述相關品質保證的軟體測試： 程式測試的底層動機是以方法證實軟體的品質，此方法可經濟與有效地應用於大小規模的系統。,13.1.2 軟體測試的組織,對於每一個軟體專案，測試的開始都有一個與生俱來的利益衝突發生。 已經建構軟體的人現在都被要求測試其軟體。這似乎對本身也無任何害處；畢竟，誰會比開發者更為瞭解此程式呢？ 不幸地，這些相同的開發者在展示程式是沒有錯誤的時候，是存有既定利益的，它依照顧客的需求進行，且在期限與預算內完成。 這些利益的每一項都與測試是衝突的。,軟體測試的心理學觀點,從心理學的觀點來看，軟體分析與設計(連同編碼)是有建設性的工作。 軟體工程師
9、分析、塑模，然後產生一支電腦程式與它的文件。 就像任何的建構者，軟體工程師對所建造的雄偉建築感到驕傲，並且斜眼瞄著任何一個試圖想要拆毀它的人。 當測試出現，就會有一個難以捉摸但很明確要毀壞軟體工程師所建造事物的企圖。 從建構者的觀點來看，測試可被視為(精神上)破壞性的。 建構者輕輕地踐踏，設計與執行的測試都展示出程式是可以工作的，而並非是揭發錯誤。 不幸地，錯誤還是會出現。 如果軟體工程師沒有發現它們，顧客則會找到的！,測試的錯誤推論,從前述的討論中經常會有一些錯誤的概念被錯誤地推論： 軟體的開發者一點都不應該做測試。 軟體應該丟過牆壁給陌生人進行毫無仁慈的測試。 測試者只在測試的相關步驟開始
10、時才參與專案。 這些陳述的每一個都是不正確的。 軟體開發者總是負責測試程式的個別單位(元件)，以確保每個都實行功能或展現為它所設計的行為。 在許多情形中，開發者也導入整合測試 - 一個導致完整軟體架構建構(與測試)的測試步驟。 只有在軟體結構完成之後，一個獨立的測試群組才會參與。,獨立測試群組,獨立測試群組(independent test group, ITG)的角色是排除讓建構者測試已經建造事物的原有問題。 獨立測試除去其他方面可能的利益衝突。 ITG的員工是付錢請來發現錯誤的。 軟體工程師並不是將程式交給ITG就可安然脫身。 開發者與ITG在整個軟體工作期間緊密地工作在一起，以確保導入徹
11、底的測試。 當測試導入時，開發者必須要有效地修正被揭發出的錯誤。 ITG是軟體開發專案團隊的一部分。他在分析與設計期間參與，並在整個大型專案內持續參與(計畫與指明測試程序)。 在許多情形中ITG將向軟體品質保證組織報告，因此達成某個程度的獨立性，這是做為軟體工程的一部分組織所不可能達到的。,13.1.3 傳統軟體架構的軟體測試策略,軟體流程可視為如圖13.1中所例舉的螺旋形。 最初，系統工程定義軟體的角色，並在資訊領域、功能、行為、效能、侷限因素和確認軟體建立的標準中導引軟體的需求分析。 沿著螺旋形向內移動，我們來到設計並抵達最後的編碼。 為了開發電腦軟體，我們沿著螺旋狀的流線型向內，每一次轉
12、向都會降低抽象化的程度。,圖13.1 測試策略,軟體測試的策略,軟體測試的策略也可以視為螺旋形(圖13.1)的環境。 單元測試(unit testing)從螺旋形的漩渦開始，並聚焦在被實作成原始碼的每一個軟體單元(即元件)。 測試沿著螺旋形向外移動進展到整合測試(integration testing)，在此的焦點為設計與軟體架構的建構。 朝著螺旋形向外轉一圈，我們遇到確認測試(validation testing)，在此建立做為軟體需求分析一部分的需求對照著已經建構的軟體進行確認。 最後，我們來到系統測試(system testing)，在此對軟體與其他的系統元素進行整體測試。 要測試電腦軟
13、體，我們沿著螺旋形線流向外，每一次轉向都會擴大測試的範圍。,軟體工程環境中的測試步驟,軟體工程環境中的測試實際上是持續實作的一系列四個步驟。此步驟顯示於圖13.2中。 最初，測試聚焦在每一個個別的元件，以確保它是一個可適當運作的單元。 單元測試運用大量的測試技術，在元件的控制結構中操練指定的路徑，以確保完全地涵蓋與偵測出最多的錯誤。接著，元件必須要組裝或整合成完整的軟體套件(package)。 整合測試針對結合驗證與程式建構的雙重問題。 雖然操練指定程式路徑的技術可以確保主要控制路徑的涵蓋，聚焦在輸入與輸出的測試案例設計技術在整合期間則更為普遍。,軟體工程環境中的測試步驟,在軟體整合(建構)之
14、後，一組高階的測試被導入。 確認標準(在需求分析期間所建立的)必須要被評估。 確認測試提供最後的保證使軟體符合所有功能的、行為的和效能的需求。 最後的高階測試步驟落在軟體工程的界限外，並進入電腦系統工程更為廣闊的環境中。 一旦確認，軟體必須與其他的系統元素結合(例如，硬體、人、資料庫)。 系統測試正確地驗證所有的元素網路(mesh)，且整體的系統功能/效能是達成的。,圖13.2 軟體測試步驟,13.1.4 物件導向架構的軟體測試策略,物件導向的系統測試對軟體工程師呈現出一組不同的挑戰。 測試的定義必須要擴大以包括應用在分析與設計模型的錯誤發現技術(例如，正規的技術檢視)。 當它們被建構時，必須
15、評估物件導向表示法的完全性與一致性。 單元測試喪失它的某些意義，且整合策略顯著地改變。 摘要來說，測試策略與測試戰術(第14章)必須要說明物件導向軟體的獨特性。,物件導向軟體的測試策略,就哲學上而言，物件導向軟體的整體策略在哲學上與應用到那傳統架構的是同一個，但在方式上有所不同。 由測試小的開始並向外進行到測試大的。 然而，我們聚焦於從測試小的個別模組(傳統的觀點)轉變成為一個含括屬性和隱含著通訊與協同合作的操作類別上。 當類別被整合進入一個物件導向的架構中時，一系列的回歸測試會執行，以找出類別間通訊與協同合作上的錯誤，和由於新類別(元件)加入所造成的副作用。 最後，對整個系統進行測試以確保能
16、找出需求上的錯誤。,13.1.5 測試完成的標準,在軟體測試討論時，都有一個典型的問題會出現： 我們何時做測試? 我們如何知道我們已經做了充分的測試？ 很不幸地，對這個問題沒有一定的答案，但是有一些務實的回應和在經驗指導下的初期嘗試。 對此問題的一個回應是：你從不做測試；只要很簡單地將你(軟體工程師)的負擔轉嫁給你的顧客身上。 每次顧客/使用者執行一支電腦程式時，此程式就正被測試中。 此一嚴肅的事實強調其他軟體品質保證活動的重要。 另一個回應是(有點挖苦，但仍然是正確的)：當你耗費掉所有的時間，或是你花費掉所有的金錢後，你就做完測試了。,基於統計標準的回應,軟體工程師需要更多嚴格的標準以決定何
17、時已經執行了充分的測試。 Musa與Ackerman建議的一種基於統計標準的回應： 不，我們絕對不可能確信軟體永遠不會失敗，但相對於理論上可靠的與實驗上確認的統計模型，我們已經執行了充分的測試而有百分之95的把握說出在一個可能被定義環境中的1000個CPU小時內沒有失誤的機率至少為0.995。 以統計塑模與軟體可靠度理論，軟體失敗(在測試期間所揭發)的模型可被發展成為執行時間的函式。,13.2 策略議題,如果沒有針對一系列優先性的(overriding)問題，即使是最好的策略都會失敗。 Tom Gilb主張如果要實作成功的軟體測試策略，必須要針對以下的問題： 在測試著手很早之前，採用可量化的方
18、法指明產品的需求。 雖然測試的壓倒性目標是找出錯誤，一項好的測試策略也可評估其他的品質特性，如可攜性、可維護性和可用性(第15章)。這些應該被量測，使測試的結果不會含糊不清。 明確地說明測試的目標。測試的特定目標應該以可測量的項目名稱來陳述。 例如，測試有效性、測試範圍、失敗平均時間、發現和修正缺點的成本、剩餘的缺點密度或發生的次數和每次回歸測試的測試工作小時等，都應在測試計畫中說明。,實作成功軟體測試策略的議題,瞭解軟體的使用者，並對每一種使用者類型發展基本資料(profile)。 描述使用者每個類別互動情境的使用案例，藉由聚焦在產品實際使用的測試，可以降低整體測試的投入。 發展一個強調快速
19、循環測試(rapid cycle testing)的測試計畫。 Gilb推薦一個軟體工程團隊的學習對顧客有用的快速循環測試(2%的專案投入)，至少是實地可試驗的(trialable)，功能性和/或品質改進的遞增。 從這些快速循環測試所產生的回饋可用來控制品質水準和相對應的測試策略。,實作成功軟體測試策略的議題,建立可設計成自我測試強韌的軟體。 軟體應該使用反除錯(antibugging)(第13.3.1節)技術的方法設計。 即軟體應該有診斷某些類別錯誤的能力。 設計應該適應自動化測試與回歸測試。 使用有效的正規技術檢視做為測試之前的過濾器。 正規技術檢視可與測試一樣有效地揭發出錯誤。 因為這個
20、原因，檢視能減少生產高品質軟體所必須要的測試投入。,實作成功軟體測試策略的議題,主導正規的技術檢視以評估測試策略與測試案例本身。 正規技術檢視可以揭發測試方法中的不一致性、疏忽和較為公開的(outrighter)錯誤。 這將節省時間並改善產品品質。 為測試流程發展持續改善的方式。此一測試策略應該被量測。 在測試期間所蒐集的度量(metrics)應該做為軟體測試中統計流程控制方法的一部分。只針對終端使用者需求的測試，如同基於室內設計師工作所做的地基、大樑和配管等工作的費用來檢測整個建築物。 - Boris Beizer,13.3 傳統軟體的測試策略,有許多的策略可利用來測試軟體。 在極端的狀況，
21、軟體團隊可以等到系統完全建構後，然後再對整個系統導入測試，希望能找到錯誤。 雖然很吸引人，但這種方式完全沒有用。 它的結果是造成充滿錯誤的軟體，並且使顧客與終端使用者感到失望。 在另一極端狀況，無論何時系統的任何一部分被建構完成後，軟體工程師可以每天導入測試。 這種方式，雖然對多數的人較不具吸引力，可是非常有效。,測試軟體的策略,不幸地，大多數的軟體開發者對於採用它顯得猶豫。能怎麼做呢？ 大多數軟體團隊所選擇的測試策略都落在二個極端之間。 它採用漸進式的測試觀點，由個別程式單元的測試開始，再移轉到設計以促進單元整合的測試，且最後由操練所建構的系統做為結束。,13.3.1單元測試,單元測試(un
22、it testing)聚焦於軟體設計最小單元的驗證投入 軟體元件或模組。 使用元件層級的設計描述做為指導，重要的控制路徑會被測試以揭發出模組邊界內的錯誤。 測試的相對複雜度和那些測試所揭發出的錯誤被單元測試所建立的侷限範圍所限制。 單元測試聚焦在內部的處理邏輯和元件界限內的資料結構。 這種測試型態可被平行地導入到多重的元件上。,單元測試的考量,發生做為單元測試一部分的測試以圖例的說明方式顯示於圖13.3中。 模組介面被測試以確保資訊適當地流入與流出測試中的程式單元。 區域資料結構被檢查以確保暫時儲存的資料在演算法執行所有步驟的期間維持它的完整性。 遍及控制結構的所有獨立路徑(基本路徑)被操練以
23、確保所有在模組內敘述至少被執行過一次。 邊界條件被測試以確保建立用來限制或約束處理的界限可以適當地操作。 最後，所有的錯誤處理路徑也都被測試過。,圖13.3 單元測試,單元測試的考量,在任何其他的測試啟始前，橫跨模組介面的資料流向測試是必要的。 如果資料沒有正常的進入與離去，則所有的其他測試都是沒有意義的。 區域資料結構應該被操練，並且局部對全域資料的衝擊應該在單元測試期間確定(如可能的話)。 在單元測試期間，執行路徑的選擇測試是必要的工作任務。 測試案例應該設計以揭發由於錯誤的計算、不正確的比較或不適當的控制流向所導致的錯誤。,運算式中普遍的錯誤,在計算中更為普遍的錯誤還有： 誤解或不正確的
24、算數優先順序(precedence) 混合模式的操作 不正確的初始值 精確度不準確不正確的運算式符號表示。,比較與控制流向的測試,比較與控制流向彼此緊密地連接(即在比較後經常發生流向的改變)。測試案例應該揭發出錯誤，例如： 不同資料型式的比較 不正確的邏輯運算子或優先順序 當精準度錯誤使得等式不可能發生時的相等式預期 變數的不正確比較 不當的或不存在的迴圈中止 當遇到發散的(divergent)反覆時失敗地退出 不當地修正迴圈變數,邊界測試,邊界測試是最重要的單元測試任務之一。 軟體時常在它的邊界造成失敗。 當第n維陣列的第n個元素被處理時、當某個具有i回合的第i次重複被召喚時、當遇到最大或最
25、小可允許的值時，錯誤時常會發生。 操練資料結構、控制流程和資料的值小於、正好或大於最大值與最小值等的測試案例很有可能揭發出錯誤。,反除錯的方式,當錯誤確實發生時，良好的設計要求錯誤的情況要預先考量，且設定重繞(reroute)的錯誤處理路徑或俐落地結束處理。Yourdon稱此方式為反除錯(antibugging)。 不幸地，有將錯誤處理納入軟體的趨勢出現，然而卻從不測試它。 一個真實的故事可以做為例子說明： 電腦輔助設計系統在合約的條件下發展。 在某個交易處理模組中，當召喚各種不同控制流程分支的一系列條件測試之後，在隨後的錯誤處理訊息中發生一個真實的笑話：錯誤！你應該沒有路徑可以到達這裡的。
26、這個錯誤訊息是在使用者訓練期間由顧客所揭發的！,應被測試的潛在錯誤,當錯誤處理被評估時，在這些應該被測試的潛在錯誤有： 難以理解的錯誤描述 所提到的錯誤沒有對應到所遇到的錯誤 錯誤條件造成作業系統的干預先於錯誤處理 例外條件處理是不正確的 錯誤的描述沒有提供充足的資訊，以協助錯誤起因位置的尋找。,單元測試程序,單元測試通常考慮成為編碼步驟中的一個附屬產物。 單元測試的設計可在編碼開始之前(一種喜好的機敏方式)或在原始碼產生之後可被實行。 設計資訊的檢視提供建立測試案例的指導，這些測試案例有可能揭發於先前討論的每種類型的錯誤。 每個測試案例應該與一組預期的結果結合在一起。,驅動程式和虛擬常式軟體
27、,因為元件並不是一個單獨的(stand-alone)程式，必須為每一個單元測試發展出驅動程式(driver)和/或虛擬常式(stub)軟體。 單元測試環境於圖13.4中舉例說明。 在大多數的應用程式中，驅動程式如同一支主程式，它接受測試案例資料、傳送這些資料給元件(要被測試的)，並列印出相關的結果。 虛擬常式(stub)做為替換從屬於(被呼叫)所要測試元件模組的一部分。 虛擬常式或假副程式(dummy subprogram)使用從屬模組的介面、可以做很小的數據操作、提供進入的驗證和回傳控制給接受的測試模組。,驅動程式和虛擬常式軟體,驅動程式與虛擬常式代表著額外的負擔。 即兩個都是必須要撰寫的軟
28、體(正規設計的運用並不普遍)，但並不與最終的軟體產品一起遞交。 如果驅動程式與虛擬常式保持簡單，實際上的負擔將相對很低。 不幸的是許多元件不能夠以簡單負擔的軟體進行充份的單元測試。 在此情況中，完整的測試可能被延期到整合的測試步驟中(驅動程式或虛擬常式也被使用)。 當設計一個具有高度凝聚性的元件時，單元測試會被簡化。 當只針對元件的某個功能時，測試案例的數目將會減少，並且錯誤可以更容易地預測與揭發。,圖13.4 單元測試環境,13.3.2 整合測試,一旦所有的模組都經過單元測試，軟體界中的生手(neophyte)會詢問一個表面似乎合理的問題： 如果它們個別地都可以工作，而當我們將它們聚集在一起
29、時，你為什麼對它們會工作產生懷疑呢？ 此問題是將它們聚集在一起 - 介接(interfacing)。 資料越過介面時可能會遺失； 一個模組可能對另一個具有疏忽、有害的影響； 當組合時，子功能可能無法產生所預期的主要功能； 個別可接受的不精準度，可能會被放大到無法接受的程度； 全域的資料結構會出現問題。 很可悲地，此列表不斷地一直繼續著。,整合測試的目標與方式,整合測試(integration testing)是建構軟體架構的一種系統化技術，同時主導測試以揭發與介接有關的錯誤。 其目標是拿取經過單元測試的元件，並建造一個由設計所要求的程式結構。 整合測試的方式: 非漸進式整合(nonincrem
30、ental integration) 漸進式整合(incremental integration),非漸進式整合,經常會有嘗試非漸進式整合(nonincremental integration)的趨勢，即使用大爆炸(big bang)方式建構程式。 所有的元件事先組合 整個程式做為一個整體進行測試 結果通常都是大混亂(chaos) 在整個計畫的龐大費用之下，當遇到一組錯誤時，改正會變得很困難，因為起因的隔離變得更為複雜。 一旦這些錯誤被改正後，新的一些問題又會出現，並且流程在似乎是永無止境的迴圈中繼續。,漸進式整合,漸進式整合(incremental integration)是大爆炸方式的對照
31、。 程式以較小的增量進行建構與測試，其錯誤比較容易隔離與改正。 介面更為可能被完整的測試。 且可以應用系統化的測試方式。,由上而下的整合,由上而下整合的測試是軟體架構建構的漸進方式。 由主要的控制模組(主程式)開始，模組經由控制階層向下整合。 主要控制模組的從屬(和最終從屬)模組以深度優先(depth-first)或寬度優先(breadth-first)的方式被併入結構中。,深度優先整合,參考圖13.5，深度優先整合(deep-first integration)將整合程式結構中主要控制路徑上的所有元件。 主要路徑的挑選是有點隨意的，並依靠著應用程式獨有的特性。例如， 挑選左邊的路徑，元件M1
32、、 M2、 M5將會首先整合。 接著，M8或(如果對M2適當地運作是有其必要時)M6將被整合。 然後，中間與右邊的控制路徑也會被建立出來。,圖13.5 由上而下的整合,寬度優先整合,寬度優先整合(breadth-first integration)水平地移動跨越結構，直接合併每一階層中從屬的所有元件。 圖中元件M2、M3、M4將首先整合。 接著到下一個控制階層的M5、M6等依次類推。,整合流程的步驟,整合流程以一系列的五個步驟實行： 主要控制模組用來做為測試驅動程式，並以虛擬常式替換所有直接從屬於主要控制模組的元件。 依據所挑選的整合方式(即深度或寬度優先)，從屬的虛擬常式每次由一個真實的元件
33、所取代。 當每一個元件被整合時，即導入測試。 每一組測試完成時，另一個虛擬常式就被真實的元件所取代。 導入回歸測試(稍後在本節中討論)以確保沒有引入新的錯誤。 此流程由第2步驟繼續，直到整個程式結構被建立為止。,由上而下的整合策略,由上而下的整合策略在測試流程早期就驗證主要的控制與決策點(decision point)。 在一個分解良好(well-factored)的程式結構中，決策會在階層中的上層發生，也因此會首先遇到。 如果主要的控制問題確實存在，儘早地確認是有必要的。 如果挑選深度優先的整合，軟體的完整功能可以被實作與展示。 例如，考慮典型的交易結構(第10章)，其中一個複雜的連續互動輸
34、入是經由進入路徑(incoming path)被要求、獲取與確認的。 進入路徑可以由上而下的方式整合。 在其他結構元素被整合以前，所有進入的處理(對隨後的交易派遣)可以被展示。 早期功能的能力展示是對開發者與顧客自信心的建立者。,由上而下測試策略的問題,由上而下的策略聽起來相對的不會很複雜，但在實務中可能會發生後勤的(logistical)問題。 當階層中位於底層的處理被要求能充分地測試較高的層級時，這些最常見的問題將會發生。 由上而下的測試開始時，虛擬常式取代底層的模組；所以在程式結構中，沒有顯著的資料能流往向上。,測試者執行時的選擇,測試者只剩下三個選擇： 延後許多測試，直到虛擬常式由真實
35、的模組所取代， 開發模擬真實模組以實行限制功能的虛擬常式， 從階層的底部往上整合軟體。,三種測試方式的利弊,第一個方式(延後許多測試，直到虛擬常式由真實的模組所取代)會造成我們在相對應的特定測試與特定模組合併之間的一致上失去某些控制。 這在決定錯誤的原因會導致困難，並有違反由上而下這個方式所具有高度侷限性質的趨勢。 第二個方式是可行的，但是當虛擬常式變得越來越複雜時，會導致顯著的負擔。 第三個方式稱為由下往上的(bottom-up)測試，將在下一節中討論。,由下往上的整合,由下往上的整合測試(bottom-up integration testing)，就如同它的名稱所隱含的，由自主的(ato
36、mic)模組開始建構與測試(即在程式結構中最底層的元件)。 因為元件由下往上整合，對從屬於某一階層元件所必要的處理總是可以利用的，並且可以消除對虛擬常式的需要。,由下往上的整合步驟,由下往上的整合策略可能以下列的步驟實作： 低層級元件被組合成實行特定軟體子功能的群集(clusters)(有時稱為構造(builds)。 撰寫驅動程式(測試用的控制程式)以協調測試案例的輸入與輸出。 測試群集。 移開驅動程式並將群集移往程式結構的上層組合。,由下往上的整合範例,整合採用圖13.6中所舉例說明的模式。 元件被組合以形成群集1、2和3。 每一個群集使用一個驅動程式測試(以虛線的方塊顯示)。 在群集1與2
37、中的元件是從屬於Ma的。 驅動程式D1與D2被移開，並且群集直接介接到Ma。 同樣地，群集3的驅動程式D3在與模組Mb整合前被移開。 最後，Ma與Mb將與元件Mc整合等。 當整合往上移動時，對個別測試驅動程式的需要減少了。 事實上，如果程式結構最高的二個階層是由上向下整合，驅動程式的數量實質上會減少，且群集的整合將有極大的簡化。,圖13.6 由上而下的整合,回歸測試,回歸測試(regression testing)每次增加一個新的模組成為整合測試的一部分，於是軟體就產生變化。 新的資料流向路徑被建立、新的I/O可能發生、新的控制邏輯也被召喚。 這些改變可能會對先前完美無瑕工作的功能造成問題。
38、在整合測試策略的環境中，回歸測試是重新執行某些已經導入確保改變不會蔓延出所不想要副作用的測試子集合。,回歸測試的導入方式,在更大範圍的環境中，成功的測試(任何種類)的結果是發現錯誤，且錯誤一定要被改正。 軟體無論何時被修改過，軟體組態(程式、它的文件或支援它的資料)的某些面向也會改變。 回歸測試是協助確保改變(由於測試或其他理由)不會引入非計畫中的行為或額外錯誤的活動。 回歸測試可用手動的方式導入，藉由重新執行所有測試案例的子集合或使用自動捕捉/再生(capture/playback)的工具。 捕捉/再生工具讓軟體工程師得以捕捉測試案例和接著的再生與比較的結果。,回歸測試套組,回歸測試套組(被
39、執行的測試子集合)包含三種不同測試案例種類： 一個將操練所有軟體功能的代表性測試範本。 聚焦於改變時可能會被影響到軟體功能的額外測試。 聚焦在已經改變軟體元件的測試。,回歸測試的數量成長,當整合測試進行時，回歸測試的數量會成長的相當大。 回歸測試套組應該設計成只包括針對那些主要程式功能中每一個裡的一個或多個錯誤類別。 一旦改變發生，為每一個程式功能重新執行每一項測試是不務實且沒有效率的。,煙霧測試,煙霧測試(Smoke testing) 是當軟體產品正在發展時，一種普遍使用的整合測試方式。 它對時間緊迫的(time-critical)專案設計成步調固定(pacing)的機制，讓軟體團隊以頻繁的
40、方式評估其專案。,煙霧測試的活動,煙霧測試方式含括下列的活動： 已經轉變成為程式碼的軟體元件被整合入構造(build)中。 構造包括所有的資料檔案、程式庫、可重複使用的模組和需要實作一個或多個產品功能的工程元件。 設計一系列暴露出更多錯誤的測試，以適當地實行功能來維持構造。 此意圖應該是揭發顯現阻塞(show stopper)的錯誤，它有最高的可能性會將軟體拋出計畫的時程之後。 構造每日進行煙霧測試，並會和其他的構造與整個產品(以它目前的形式)整合。 整合方式可能是由上而下或由下往上。,煙霧測試的特性,每日測試整個產品的頻繁度可能會讓一些讀者吃驚。 頻繁的測試可以給管理者與從業人員一個整合測試
41、進展的實際評估。 McConnell以下列的方式描述煙霧測試： 煙霧測試應該從頭到尾地操練整個系統。 它不是一定要徹底的，但是它應該能夠暴露出主要的問題。 如果構造通過煙霧測試應該是完全足夠的，你可假設它是足夠穩定被更徹底地測試。,煙霧測試所提供的好處,當應用在複雜、時間緊迫的軟體工程專案時，煙霧測試提供一些好處： 整合風險降到最低。 因為煙霧測試每日導入執行，不相容性或其他顯現阻塞(show stopper)的錯誤早期就會被揭發。 當錯誤被揭發時，可以降低對時程可能的嚴重衝擊。 終端產品的品質獲得改善。 因為此方式是以建構(整合)為導向的，煙霧測試很可能揭發功能的錯誤和架構與元件層級設計的錯
42、誤。 假如這些錯誤及早改正，就可產生更好的產品品質結果。,煙霧測試所提供的好處,簡化錯誤診斷與改正。 就像所有的整合測試方式，在煙霧測試期間揭發的錯誤可能會和新的軟體增量有關聯。 即增加構造的軟體可能是發現新錯誤的一個原因。 進展更為容易評估。 隨著每天的過去，更多的軟體已被整合，並且展示更多所執行的工作。 這會增進團隊的士氣，並帶給管理者一個表現進步良好的指示。將每日的構造視為專案的心跳。如果沒有心跳，專案就死了。 Jim McCarthy,策略的選擇,對由上而下與由下往上整合測試的相對優點與缺點一直都有許多的討論(例如BEI84)。 通常一個策略的優點很可能是另一個策略的缺點。 由上而下方
43、式的主要缺點是對虛擬常式的需要，並且結合它們伴隨的測試變得困難。 結合虛擬常式的問題可藉由早期測試主要控制功能的優點而抵銷。 由下往上整合的主要缺點是直到加入最後一個模組前，實體的程式不會存在。 此一缺點可藉由較為容易的測試案例設計和沒有虛擬常式而調和。,策略的選擇-三明治測試,一個整合策略的挑選端視軟體的特性，有時也要依據專案的時程。 通常，程式的上層結構使用由上而下的測試，結合從屬層級由下往上測試的這種組合方式(有時稱為三明治測試(sandwich testing)或許是最好的折衷方案。,關鍵模組的特性,當整合測試導入時，測試者應該辨識出關鍵模組(critical modules)。 關鍵
44、模組有一個或多個以下的特性： 針對某些的軟體需求 具有高控制層級(駐留在相對高層的程式結構中) 有複雜或錯誤的傾向 有明確的效能需求。 關鍵模組應該盡可能提早測試。 回歸測試應該專注於關鍵模組的功能。,整合測試文件,軟體整合的整體計畫和特定測試的描述被記錄在測試規格(test specification)中。 此文件包含測試計畫、測試流程，它是軟體流程的工作產品之一，並且成為軟體組態的一部分。 測試計畫描述整合的整體策略。 測試針對軟體特定的功能與行為的特性，區分成為階段(phases)與構造(builds)。 例如，電腦輔助設計系統(CAD)的整合測試可以區分為下列的測試階段： 使用者互動(
45、命令挑選、畫出創作物、顯示的呈現、錯誤的處理與呈現)。 資料操縱與分析(符號產生、規模、旋轉、實際特性的計算)。 顯示處理與產生(二維顯示、三維顯示、圖形與圖表)。 資料庫管理(存取、更新、整合、效能)。,所有測試階段應用的標準測試,這些階段與子階段(括弧中所表示)的每一個描述軟體中大範圍的功能範疇，並且通常可與軟體架構中的特定領域相關。 程式的構造(模組的群體)被產生以對應到每一個階段。 下列的標準與對應的測試被應用到所有的測試階段： 介面的完整性(interface integrity) 當每個模組(或群集)併入結構中時，測試其內部與外部的介面。 功能有效性(functional vali
46、dity) 設計用來揭發功能錯誤的測試應該要導入。 資訊內容(information content) 設計以結合區域或全域資料結構來揭發錯誤的測試應該導入。 效能(performance) 建立於軟體設計期間所設計來驗證效能界限的測試應該導入。,所有測試階段應用的標準測試,整合的時程、額外(overhead)軟體的發展和相關的主題也討論做為測試計畫的一部分。 建立每個階段開始與結束的日期，並為單元測試的模組定義有效性視窗(availability windows)。 對額外軟體(虛擬常式與驅動程式)的簡要描述專注在可能需要特別投入的特性上。 描述測試環境與資源。 不尋常的硬體組態、外來的模擬
47、器和特別的測試工具或技術是許多主題中少數可能要討論的。 描述所需要完成測試計畫的詳細測試程序。 在每個整合步驟中的整合順序與相對應的測試也要描述。 一個所有測試案例(隨後的參考資料有註解)的列表和預期的結果也要包括在內。,所有測試階段應用的標準測試,一個真實測試結果的歷程、問題或特質都記錄在測試報告(test report)中，並可被附加到測試規格(test specification)裡。 如同一個軟體組態的所有其他元素，測試規格的格式可能裁製成軟體工程組織本身的需要。 一個整合策略(包含於測試計畫中)與測試細節(描述於測試流程中)是必要的成分，且必定要出現的。最好的測試者不是發現最多錯誤的
48、人最好的測試者是修補最多錯誤的人。 Cem Kaner等,13.4 物件導向軟體的測試策略,測試的目標是運用於現實的一段時間中，以可管理的投入量，找出最大可能數量的錯誤。 雖然其基本目標沒有因為是物件導向的軟體而改變，但是物件導向軟體的性質改變了測試策略與測試戰術(tactics)。,13.4.1 在OO環境中的單元測試,當考慮物件導向軟體時，單元的概念改變了。 封裝(encapsulation)主導類別的定義。 每一個類別與每個類別的個例(物件)包裝了屬性(資料)和操縱這些資料的操作(功能)。 一個封裝的類別通常是單元測試的焦點。 類別中的操作是最小的可測試單元。 因為一個類別可以包含一些不
49、同的操作，並且一個特定的操作也可能存在而成為許多不同類別的一部分。,改變應用到單元測試的戰術,不再以隔離的方式做單一操作(傳統單元測試觀點)的測試，但寧可做為類別的一部分。舉例說明， 考慮一個類別階層，其中X操作定義於父類別中，並由一些子類別所繼承。 每個子類別使用X操作，但它被應用於子類別所定義的私有屬性與操作的環境中。 因為在此環境中X操作的使用會有一些難以捉摸的各種變化，所以有必要在每一個子類別的環境中測試X操作。 這意味著在物件導向的環境中，以單獨的形式(傳統的單元測試方式)測試X操作通常是沒有效率的。 OO軟體的類別測試等同於傳統軟體的單元測試。 不像傳統軟體的單元測試，它傾向於聚焦
50、在模組的演算法細節和流過模組介面的資料，OO軟體的類別測試是由類別所封裝的操作與類別狀態行為所驅動。,13.4.2 在OO環境中的整合測試,因為物件導向軟體沒有明顯的階層控制結構，傳統由上而下與由下往上的整合策略 (第13.3.2節)已沒有太多的意義。 每次整合一個操作到類別中常常是不可能的(傳統漸進的整合方式)，因為類別是由元件直接與間接的互動所組成的。,OO系統整合測試的策略,OO系統的整合測試有兩種不同的策略： 以執行緒為基礎的測試(thread-based testing) 它整合必須回應一個系統的輸入或事件的類別組。 每個執行緒都是個別的整合與測試。 應用回歸測試以確保沒有副作用的發生。 以使用為基礎的測試(use-based testing) 它藉由測試使用少量(如果有的話)服務類別(server classes)的那些類別(稱為獨立類別(independent classes)開始系統的建構。 在獨立類別測試後，稱為依附類別(dependent classes)的下一層類別，則使用獨立類別進行測試。 依附類別的測試層級依序進行，直到整個系統建構完成為止。,
