也許有或也許沒有實際的可執行程序作為 LCO 簡報的一部分。這些可能由技術示范者、現有產品的快速出租，或者也許是更實質的東西組成。我的意見是在如此初步的階段執行如此正式的操作是不適當的。
因為測試成本對總的開發成本做出貢獻，所以我已經列出許多對測試成本做出貢獻的行為。
測試風險
風險需要減輕計劃，減輕風險需要花費金錢。測試風險是各種各樣的。例如，需求可能迅速地變更，這可能會破壞可測試性或測試成本設想。后繼的精化階段可能會利用新的測試難點的解決方案來解決技術風險�？赡苄枰袷� MC/DC(Modified Condition/Decision Coverage)測試、ISO 標準、SEI 標準，IEEE 標準，等等這樣的標準。 1 這些標準可以減少整個業務成本，但是順應成本在某種程度上落在測試人員上，并且應該更加明顯�？赡艽嬖谂c數據安全相關的政府規章，如保密性規章，使對“真實”數據的測試變得困難或昂貴。
可測試性
可測試性與可行性直接相關，并且很可能找到很難測試的高層次需求。一些需求是非可測試的，因為他們是主觀的，或者不是有助于度量或量度的。一些是不可測試的，因為從技術上很難安排一個合適的測試。例如，一些戰略防御計劃(Strategic Defense Initiative，SDI)的批評家提到在美國執行其導彈防御的可接受性測試時，讓蘇聯啟動非武裝的洲際彈道導彈(Intercontinental Ballistic Missile，ICBM)的困難。在軟件開發項目中，這種情況發生于格外昂貴的硬件不能為了測試很容易地重新執行任務的時候，或者當獨特的環境因素使測試的安排變得困難時。
準備測試實驗室
通過“實驗室”，我的意思是一個環境，在其中有我們測試每個需求所需要的東西，一個被提供但與產品環境有很難區分的不同。即使我們在早期的需求發現階段，仍有可能估算您很可能需要的資源。
資源可能包括 1) 硬件、計算機、網絡，以及由慢速管道或很長的往返傳遞，及防火墻所引起的瓶頸，2) 軟件，包括測軟件及其他必需或采用的軟件，所有的都處于已知版本層(或根據所有版本進行測試!)，3) 測試軟件，如測試經理，測試自動化軟件，如記錄或回放 GUI 測試人員，以及用于可伸縮測試的用戶虛擬化，4) 數據，包括用于冒煙測試和功能測試的小型數據集，以及用于可伸縮性測試的大型數據集。
注意到盡管潛在的實驗室特性的列表很長，我們還必須在存在相應的實際需求的地方指定實驗室需求。例如，不是所有的系統都有可伸縮性需求，所以不是所有的實驗室都將需要用戶虛擬化工具。
估算需求或場景的整體測試成本
大多數需求將作為普通的功能需求出現。與測試相關的成本通常與編碼或設計的成本大致成比例，因此測試工作一般來說將是編碼和設計成本的某個比例(比方說 25%)。此系數將具體到每個組織，并且可以通過收集一兩個項目量度按經驗尋找。系數將被平臺的數量或所需的其他類型的測試工作副本所修改。
2 缺陷管理、構建，發布過程
存在與將測試人員插入開發過程中有關的成本。測試人員共享其他項目團隊使用的特定開發工具，如用于缺陷跟蹤的工具，以及構建和發布工具，如用于配置管理的工具。
精化(Elaboration)階段：管理技術風險
RUP 的精化階段是對準技術風險的管理的。為了制定出自該階段的可行或不可行的決策，我們需要論證一個對每個鑒別出的技術風險的滿意解決方案。通常，最糟的技術問題由非功能需求導致。非功能需求可以造成這樣的有趣斷言“系統將擁有 99.999% 的可用性，”或者“系統將支持 10,000 個同時發生的用戶會話�！边@些需求寫起來便宜，但滿足和測試起來昂貴。為了進行適當的評估，我們需要了解：
文章來源于領測軟件測試網 http://www.k11sc111.com/
