本文來自于 Rational Edge：在對軟件迭代開發(fā)生命周期中的測試人員的作用進(jìn)行探討的同時，作者考慮，除了 RUP 測試規(guī)程中提供的描述，測試人員還能如何對項目做出廣泛的貢獻(xiàn)。
從測試工程師那里聽到的最普遍的抱怨是直到過程中很晚的時候才能有效地參與到軟件開發(fā)項目中。此外，測試通常是在開發(fā)人員在抗?fàn)帗p壞一個接一個版本候選的很晚出現(xiàn)的缺陷時所逼出的行為。到一個合適的候選版本出現(xiàn)的時候，測試人員已經(jīng)成為瓶頸，顯然，要對進(jìn)一步的延遲負(fù)責(zé)。
Rational Unified Process®，或 RUP®，廣泛地概括了測試規(guī)程（Test Discipline），并介紹了測試角色如何及早地參與項目生命周期。
我希望在本文中介紹另一種觀點。代替由測試規(guī)程開始，我將依次考慮每個 RUP 階段的風(fēng)險管理原則，并詢問經(jīng)驗豐富的測試人員，為了促進(jìn)那些目標(biāo)他們可能會做些什么。雖然測試工程師不能估算總的項目成本，但是他們的確可以評估對成本的測試貢獻(xiàn)，并且提出測試風(fēng)險和可行性。雖然他們不應(yīng)該計劃解決方案架構(gòu)，但是他們可以幫忙度量。雖然測試人員不構(gòu)建一系列可執(zhí)行程序，但是他們可以評估每個可執(zhí)行程序如何表示一個從前一個而來的進(jìn)展。雖然測試人員不構(gòu)建最終的候選版本，但是他們可以確保具有可接受的質(zhì)量。
我相信在 RUP 的每個階段，測試人員都有機(jī)會對項目做出大量貢獻(xiàn)。該貢獻(xiàn)遠(yuǎn)遠(yuǎn)地擴(kuò)展了，例如，要求更早地測試交付內(nèi)容 —— 或者更早地執(zhí)行一組標(biāo)準(zhǔn)的測試 —— 比傳統(tǒng)的瀑布驅(qū)動過程中。本文應(yīng)作為面向開發(fā)團(tuán)隊中的測試人員的 RUP 原則的激勵說明來閱讀。它不應(yīng)該作為 RUP 測試規(guī)程的概要或初級讀物。雖然我相信許多測試人員會覺得該信息很有用，但是我還相信管理人員將會對看到測試人員的能力和經(jīng)驗如何在 RUP 項目的所有階段中更有效地應(yīng)用感興趣。
初始（Inception）階段：管理業(yè)務(wù)風(fēng)險
RUP 的初始階段是對準(zhǔn)業(yè)務(wù)風(fēng)險的管理。為了制定出自該階段的可行或不可行的決策，我們需要了解
待解決問題的性質(zhì)。
解決方案的價值，不論是就節(jié)約或收益而言，還是以一些其他的業(yè)務(wù)價值，如質(zhì)量或時間性而言。
潛在的解決方案，因此我們至少知道問題是可解決的。
對解決方案的粗略成本估算。
危害解決方案的風(fēng)險。
帶著此信息，涉眾被聚集到生命周期目標(biāo)（Lifecycle Objectives，LCO）會議上。如果項目被視為是可行且值得做的，那么項目會繼續(xù)進(jìn)入精化階段。
評估成本
可行性和成本是 LCO 會議上的重要因素，并且測試人員無疑可以為該決策貢獻(xiàn)重要的數(shù)據(jù)。測試人員可以估算對成本的測試貢獻(xiàn)，甚至有時候可以有助于可行性問題。記住，在初始階段中，盡管我們只對球場的數(shù)字感興趣。過高的精確度將給我們帶來不真實精確度的不適當(dāng)安全感。
也許有或也許沒有實際的可執(zhí)行程序作為 LCO 簡報的一部分。這些可能由技術(shù)示范者、現(xiàn)有產(chǎn)品的快速出租，或者也許是更實質(zhì)的東西組成。我的意見是在如此初步的階段執(zhí)行如此正式的操作是不適當(dāng)?shù)摹?BR> 因為測試成本對總的開發(fā)成本做出貢獻(xiàn)，所以我已經(jīng)列出許多對測試成本做出貢獻(xiàn)的行為。
測試風(fēng)險
風(fēng)險需要減輕計劃，減輕風(fēng)險需要花費金錢。測試風(fēng)險是各種各樣的。例如，需求可能迅速地變更，這可能會破壞可測試性或測試成本設(shè)想。后繼的精化階段可能會利用新的測試難點的解決方案來解決技術(shù)風(fēng)險。可能需要遵守 MC/DC（Modified Condition/Decision Coverage）測試、ISO 標(biāo)準(zhǔn)、SEI 標(biāo)準(zhǔn)，IEEE 標(biāo)準(zhǔn)，等等這樣的標(biāo)準(zhǔn)。 1 這些標(biāo)準(zhǔn)可以減少整個業(yè)務(wù)成本，但是順應(yīng)成本在某種程度上落在測試人員上，并且應(yīng)該更加明顯?？赡艽嬖谂c數(shù)據(jù)安全相關(guān)的政府規(guī)章，如保密性規(guī)章，使對“真實”數(shù)據(jù)的測試變得困難或昂貴。
可測試性
可測試性與可行性直接相關(guān)，并且很可能找到很難測試的高層次需求。一些需求是非可測試的，因為他們是主觀的，或者不是有助于度量或量度的。一些是不可測試的，因為從技術(shù)上很難安排一個合適的測試。例如，一些戰(zhàn)略防御計劃（Strategic Defense Initiative，SDI）的批評家提到在美國執(zhí)行其導(dǎo)彈防御的可接受性測試時，讓蘇聯(lián)啟動非武裝的洲際彈道導(dǎo)彈（Intercontinental Ballistic Missile，ICBM）的困難。在軟件開發(fā)項目中，這種情況發(fā)生于格外昂貴的硬件不能為了測試很容易地重新執(zhí)行任務(wù)的時候，或者當(dāng)獨特的環(huán)境因素使測試的安排變得困難時。
準(zhǔn)備測試實驗室
通過“實驗室”，我的意思是一個環(huán)境，在其中有我們測試每個需求所需要的東西，一個被提供但與產(chǎn)品環(huán)境有很難區(qū)分的不同。即使我們在早期的需求發(fā)現(xiàn)階段，仍有可能估算您很可能需要的資源。
資源可能包括 1) 硬件、計算機(jī)、網(wǎng)絡(luò)，以及由慢速管道或很長的往返傳遞，及防火墻所引起的瓶頸，2) 軟件，包括測軟件及其他必需或采用的軟件，所有的都處于已知版本層（或根據(jù)所有版本進(jìn)行測試?。?) 測試軟件，如測試經(jīng)理，測試自動化軟件，如記錄或回放 GUI 測試人員，以及用于可伸縮測試的用戶虛擬化，4) 數(shù)據(jù)，包括用于冒煙測試和功能測試的小型數(shù)據(jù)集，以及用于可伸縮性測試的大型數(shù)據(jù)集。
注意到盡管潛在的實驗室特性的列表很長，我們還必須在存在相應(yīng)的實際需求的地方指定實驗室需求。例如，不是所有的系統(tǒng)都有可伸縮性需求，所以不是所有的實驗室都將需要用戶虛擬化工具。
估算需求或場景的整體測試成本
大多數(shù)需求將作為普通的功能需求出現(xiàn)。與測試相關(guān)的成本通常與編碼或設(shè)計的成本大致成比例，因此測試工作一般來說將是編碼和設(shè)計成本的某個比例（比方說 25％）。此系數(shù)將具體到每個組織，并且可以通過收集一兩個項目量度按經(jīng)驗尋找。系數(shù)將被平臺的數(shù)量或所需的其他類型的測試工作副本所修改。
2 缺陷管理、構(gòu)建，發(fā)布過程
存在與將測試人員插入開發(fā)過程中有關(guān)的成本。測試人員共享其他項目團(tuán)隊使用的特定開發(fā)工具，如用于缺陷跟蹤的工具，以及構(gòu)建和發(fā)布工具，如用于配置管理的工具。
精化（Elaboration）階段：管理技術(shù)風(fēng)險
從測試工程師那里聽到的最普遍的抱怨是直到過程中很晚的時候才能有效地參與到軟件開發(fā)項目中。此外，測試通常是在開發(fā)人員在抗?fàn)帗p壞一個接一個版本候選的很晚出現(xiàn)的缺陷時所逼出的行為。到一個合適的候選版本出現(xiàn)的時候，測試人員已經(jīng)成為瓶頸，顯然，要對進(jìn)一步的延遲負(fù)責(zé)。
Rational Unified Process®，或 RUP®，廣泛地概括了測試規(guī)程（Test Discipline），并介紹了測試角色如何及早地參與項目生命周期。
我希望在本文中介紹另一種觀點。代替由測試規(guī)程開始，我將依次考慮每個 RUP 階段的風(fēng)險管理原則，并詢問經(jīng)驗豐富的測試人員，為了促進(jìn)那些目標(biāo)他們可能會做些什么。雖然測試工程師不能估算總的項目成本，但是他們的確可以評估對成本的測試貢獻(xiàn)，并且提出測試風(fēng)險和可行性。雖然他們不應(yīng)該計劃解決方案架構(gòu)，但是他們可以幫忙度量。雖然測試人員不構(gòu)建一系列可執(zhí)行程序，但是他們可以評估每個可執(zhí)行程序如何表示一個從前一個而來的進(jìn)展。雖然測試人員不構(gòu)建最終的候選版本，但是他們可以確保具有可接受的質(zhì)量。
我相信在 RUP 的每個階段，測試人員都有機(jī)會對項目做出大量貢獻(xiàn)。該貢獻(xiàn)遠(yuǎn)遠(yuǎn)地擴(kuò)展了，例如，要求更早地測試交付內(nèi)容 —— 或者更早地執(zhí)行一組標(biāo)準(zhǔn)的測試 —— 比傳統(tǒng)的瀑布驅(qū)動過程中。本文應(yīng)作為面向開發(fā)團(tuán)隊中的測試人員的 RUP 原則的激勵說明來閱讀。它不應(yīng)該作為 RUP 測試規(guī)程的概要或初級讀物。雖然我相信許多測試人員會覺得該信息很有用，但是我還相信管理人員將會對看到測試人員的能力和經(jīng)驗如何在 RUP 項目的所有階段中更有效地應(yīng)用感興趣。
初始（Inception）階段：管理業(yè)務(wù)風(fēng)險
RUP 的初始階段是對準(zhǔn)業(yè)務(wù)風(fēng)險的管理。為了制定出自該階段的可行或不可行的決策，我們需要了解
待解決問題的性質(zhì)。
解決方案的價值，不論是就節(jié)約或收益而言，還是以一些其他的業(yè)務(wù)價值，如質(zhì)量或時間性而言。
潛在的解決方案，因此我們至少知道問題是可解決的。
對解決方案的粗略成本估算。
危害解決方案的風(fēng)險。
帶著此信息，涉眾被聚集到生命周期目標(biāo)（Lifecycle Objectives，LCO）會議上。如果項目被視為是可行且值得做的，那么項目會繼續(xù)進(jìn)入精化階段。
評估成本
可行性和成本是 LCO 會議上的重要因素，并且測試人員無疑可以為該決策貢獻(xiàn)重要的數(shù)據(jù)。測試人員可以估算對成本的測試貢獻(xiàn)，甚至有時候可以有助于可行性問題。記住，在初始階段中，盡管我們只對球場的數(shù)字感興趣。過高的精確度將給我們帶來不真實精確度的不適當(dāng)安全感。
也許有或也許沒有實際的可執(zhí)行程序作為 LCO 簡報的一部分。這些可能由技術(shù)示范者、現(xiàn)有產(chǎn)品的快速出租，或者也許是更實質(zhì)的東西組成。我的意見是在如此初步的階段執(zhí)行如此正式的操作是不適當(dāng)?shù)摹?BR> 因為測試成本對總的開發(fā)成本做出貢獻(xiàn)，所以我已經(jīng)列出許多對測試成本做出貢獻(xiàn)的行為。
測試風(fēng)險
風(fēng)險需要減輕計劃，減輕風(fēng)險需要花費金錢。測試風(fēng)險是各種各樣的。例如，需求可能迅速地變更，這可能會破壞可測試性或測試成本設(shè)想。后繼的精化階段可能會利用新的測試難點的解決方案來解決技術(shù)風(fēng)險。可能需要遵守 MC/DC（Modified Condition/Decision Coverage）測試、ISO 標(biāo)準(zhǔn)、SEI 標(biāo)準(zhǔn)，IEEE 標(biāo)準(zhǔn)，等等這樣的標(biāo)準(zhǔn)。 1 這些標(biāo)準(zhǔn)可以減少整個業(yè)務(wù)成本，但是順應(yīng)成本在某種程度上落在測試人員上，并且應(yīng)該更加明顯?？赡艽嬖谂c數(shù)據(jù)安全相關(guān)的政府規(guī)章，如保密性規(guī)章，使對“真實”數(shù)據(jù)的測試變得困難或昂貴。
可測試性
可測試性與可行性直接相關(guān)，并且很可能找到很難測試的高層次需求。一些需求是非可測試的，因為他們是主觀的，或者不是有助于度量或量度的。一些是不可測試的，因為從技術(shù)上很難安排一個合適的測試。例如，一些戰(zhàn)略防御計劃（Strategic Defense Initiative，SDI）的批評家提到在美國執(zhí)行其導(dǎo)彈防御的可接受性測試時，讓蘇聯(lián)啟動非武裝的洲際彈道導(dǎo)彈（Intercontinental Ballistic Missile，ICBM）的困難。在軟件開發(fā)項目中，這種情況發(fā)生于格外昂貴的硬件不能為了測試很容易地重新執(zhí)行任務(wù)的時候，或者當(dāng)獨特的環(huán)境因素使測試的安排變得困難時。
準(zhǔn)備測試實驗室
通過“實驗室”，我的意思是一個環(huán)境，在其中有我們測試每個需求所需要的東西，一個被提供但與產(chǎn)品環(huán)境有很難區(qū)分的不同。即使我們在早期的需求發(fā)現(xiàn)階段，仍有可能估算您很可能需要的資源。
資源可能包括 1) 硬件、計算機(jī)、網(wǎng)絡(luò)，以及由慢速管道或很長的往返傳遞，及防火墻所引起的瓶頸，2) 軟件，包括測軟件及其他必需或采用的軟件，所有的都處于已知版本層（或根據(jù)所有版本進(jìn)行測試?。?) 測試軟件，如測試經(jīng)理，測試自動化軟件，如記錄或回放 GUI 測試人員，以及用于可伸縮測試的用戶虛擬化，4) 數(shù)據(jù)，包括用于冒煙測試和功能測試的小型數(shù)據(jù)集，以及用于可伸縮性測試的大型數(shù)據(jù)集。
注意到盡管潛在的實驗室特性的列表很長，我們還必須在存在相應(yīng)的實際需求的地方指定實驗室需求。例如，不是所有的系統(tǒng)都有可伸縮性需求，所以不是所有的實驗室都將需要用戶虛擬化工具。
估算需求或場景的整體測試成本
大多數(shù)需求將作為普通的功能需求出現(xiàn)。與測試相關(guān)的成本通常與編碼或設(shè)計的成本大致成比例，因此測試工作一般來說將是編碼和設(shè)計成本的某個比例（比方說 25％）。此系數(shù)將具體到每個組織，并且可以通過收集一兩個項目量度按經(jīng)驗尋找。系數(shù)將被平臺的數(shù)量或所需的其他類型的測試工作副本所修改。
2 缺陷管理、構(gòu)建，發(fā)布過程
存在與將測試人員插入開發(fā)過程中有關(guān)的成本。測試人員共享其他項目團(tuán)隊使用的特定開發(fā)工具，如用于缺陷跟蹤的工具，以及構(gòu)建和發(fā)布工具，如用于配置管理的工具。
精化（Elaboration）階段：管理技術(shù)風(fēng)險