軟體發展的主要問題乃是缺乏定義完善的需求。若需求未能完善定義，那麼錯誤在發展過程中就會倍數增殖。軟體錯誤可能發生在過程開始的時候。這些錯誤可能發生在需求定義的時候，其目標可能是錯誤的，或是沒有完善地規定；發生在稍後的設計與發展階段，這些目標會被實作出來；或發生在軟體維護與營運階段，其時，需要軟體變更以消除錯誤或是強化效能。

對由於測試不完整所增加的軟體成本估計，可以協助凸顯軟體生命週期成本的特徵。以電腦系統營運生命週期平均計算，發展成本約佔全系統成本的30%。其餘70%生命週期成本是與維護有關的，其包括了系統提升與錯誤矯正。發展階段早期的完整測試，可以偵測該等錯誤。錯誤矯正的相對成本，以始於發展過程之時間的函數增加。錯誤矯正的相對成本，在需求與設計階段急遽增加，且在程式碼實作期間，增加更為快速。

先前的軟體測試與評估(T&E)領域研究顯示，所有維護的成本，有一半是花費是用在矯正先前未偵測到之錯誤。大約有一半的營運生命週期成本可以直接追溯到不充分及不完整的測試活動上。除了成本增加外，軟體的錯誤，在營運意義上，可以引發任務關鍵軟體失效，進而衝擊到任務的成功與人員的生命安全。

在軟體測試上，吾人所需要的是更加系統化與嚴謹的作法。為了達到效果，此作法必須採取經過規劃與協調的方式，適用至發展過程的所有階段上，其始於最早的設計階段，並進至整合後之系統的營運測試。儘早、詳盡的軟體T&E規劃對於電腦系統的成功發展至為關鍵。

用於生產營運軟體的軟體工程技術乃是發展計畫中的重要風險因素。T&E計畫應能協助專案人員判斷哪些軟體工程技術會增加風險，對具有生命週期上的衝擊。風險的主要來源乃是發展營運軟體所需的支援軟體。從生命週期衝擊的角度來看，營運軟體的問題通常與軟體部署後之維護與支援的困難度有關。軟體評鑑需要對生命週期衝擊做分析，而生命週期衝擊會隨著軟體設計與實作所使用的技術而變化。例如，降低長期生命週期風險的作法之一，乃是在軟體的發展與營運全程，使用某特定的程式語言與共通硬體。這類會影響到營運能力的生命週期特性，應在測試與評估主計畫(TEMP)中提及，並且應發展各種測試，以識別因該等特性而造成的問題。用以設計及實作軟體的技術，可能會明顯地影響到軟體的可支援性(supportability)與可維護性(maintainability)。

TEMP必須根據達成營運有效性(operational effectiveness)與適合性(suitability)的書面規格，充分地描述驗收準則或軟體成熟度度量。前述的規格必須定義必要的軟體度量，以為任務關鍵功能，設定目標與閾值。此外，這些度量應在系統發展的適當階段，而非於某些恣意設定的里程碑上予以評估。

軟體測試是一項反覆實施的過程，於所有發展階段上，檢驗程式設計與程式碼，以找出錯誤。軟體測試規劃應和其他系統組件的測試規劃一樣，謹慎地說明於TEMP中。

----------------
引文:

　　軟體發展對整體的獲取過程的整合，規定了與硬體發展所採取之由下而上作法一致的測試過程。軟體測試最早期階段的特徵，乃是人力密集的參與基本設計與程式編碼過程。因此，人工測試被定義為架構、設計與介面評估的非正式、非電腦為基礎方法。其包括：
• 檢視(Inspections) – 程式工對一小群同儕解釋其產出，並進行討論及獲得錯誤、不一致與遺漏部分的直接回饋。
• 導覽(Walk-through) – 一組同儕人員，共同制訂測試個案，以評估截至目前為止的產出，並直接對程式工提供回饋。
• 桌上檢核(desk checking) – 程式工對於自己產出的自我評估。識別出自己邏輯或程式編碼錯誤的機率很低。
• 同儕評等(peer ratings) – 集體評估與回饋的作法，由數組同儕相互支援、不計名方式履行的審查。
• 設計審查(design reviews) – 初步設計審查(PDR)與關鍵設計審查(CDR)於發展工作中，提供審查截至目前為止的發展與評估結果的里程碑。負責獨立驗證與確認(IV&V)的合約商可以增進業主提出有意義之回饋的能力。

　　一旦發展工作已成熟到人工測試(靜態測試)不能產生效果時，電腦化、僅對軟體實施的測試(動態測試)或屬適當。其將軟體當成一個個體或 “構物(build)”履行測試，以判斷軟體的功能性(functionality)。文件控制極其重要，以便使測試結果與構物的適當版本關聯在一起。軟體測試通常以 “黑箱”與 “白箱”測試的某種組合來進行。

• 黑箱(black box) –毋須了解軟體單元的內部結構或邏輯的功能測試，在處理輸入，以獲得規定的輸出。邊界(within-boundary)內與邊界外(out-of-boundary)之刺激(含邊界值、或邊界條件)，在測試軟體處理異常事件的能力。使用最有可能性的個案測試，為軟體將能展現規定之效能，提供合理的保證。就算是最單純的軟體設計，均很快地超過我們測試所有替代方案的能力(capacity)。

• 白箱測試(white box) – 內部邏輯與軟體結構的結構測試，在提供更廣泛之識別與關鍵路徑測試的機會。相對而言，其過程與目標與黑箱測試極為類似。

　　測試應由下開始向上履行。最小的受控軟體模組—電腦軟體單元(CSU)—係採個別方式測試。之後，這些電腦軟體單元被組合或整合起來，以較大的匯集群組或構物進行測試。當此過程完成時，軟體系統以其整體交付測試。當測試進程的稍後階段發現錯誤時，需要回到發展進程的稍早部分進行矯正。錯誤偵測與矯正的成本衝擊，可以使用由下而上的測試作法而獲得減少

----------------
引文:

　　電腦軟體組態項目(CSCI)中的所有模組均完成程式編碼與個別測試後，系統層級的測試即可開始。配備充分電腦時間與適當模擬器材的軟體整合實驗室(SIL)的使用，將有助於硬體模擬/仿真及營運環境的營造。若資料分析指出，軟體正適切地運作，那就表示測試活動，可以前進至更複雜且實際之測試環境了。

• 熱平台測試(hot bench testing) – 從SIL釋出之軟體的整合，使用硬體迴路(hardware-in-the-loop, HWIL)設施中的實際系統硬體，進行全面(full-up)測試，標記出發展過程中的重大進展。與實際營運環境的極為近似，可以提供所需的測試順序與壓力，以評估軟體系統的有效性。 “吵嚷環境”所模擬出來的問題、介面問題、電磁干擾(EMI)與各種電氣暫態等都能浮現。向上導引至HWIL測試的良好硬體與軟體測試進程，可以協助將問題區隔至系統的硬體或軟體面。應小心避免所有可能觸發不現實之回應的外部刺激。

• 場域測試(field testing) – 發展測試與評估(DT&E)及營運測試與評估(OT&E)事件，須設計以提供資料蒐集過程與(資料蒐集)儀具，其將測量系統的回應，並讓資料分析師能識別異常的適切成因。場域測試應該嚴謹、能提供營運情境中可能遭遇到的環境壓力及任務組合(mission profiles)。擔負軟體系統未來維護之責的業主軟體支援設施(含人員)，應帶到現場，使之熟悉系統的營運特性與文件。他們的專業知識應納入到軟體T&E過程中，以協助可能暴露軟體問題之刺激的選擇。

　　諸如TEMP與測試計畫之類文件含有充分的軟體T&E資訊極其重要。TEMP必須定義關鍵軟體組件的特性，該等特性能有效地說明任務關鍵功能的目標與閾值。有效性測量(measures of effectiveness, MOEs)必須支持關鍵軟體議題。測試計畫應規定將應用的測試方法論。測試方法論包含兩個組件。首先是指引整體測試投入的測試策略，其二，乃是在測試策略的框架內使用的測試技法。

　　有效的測試方法論要要求要有真實的軟體測試環境與情境。測試情境必須適合於測試目標；亦即，測試結果必須可以從軟體測試目標的角度去解讀。測試情境與分析應實質地驗證與確認需求的完成程度。測試環境必須就將展現之特性分析及該分析與發展、營運及支援環境的關係謹慎地選擇。此外，環境必須能代表軟體維護所處的環境。

----------------
引文: