遵守軟件開發(fā)的規(guī)則
你 可能了解 SEI （軟件工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分為 5 個界別，該模型用來對軟件開發(fā)組織劃分等級。 Jerry Weinberg （美國軟件工程專家）也創(chuàng)建了自己的一套軟件組織模型，在他的組織模型中增加了一個額外的級別，他稱之為零級別。很顯然，一個零模式的組織實(shí)際上也是開發(fā)軟件；零模式組織中，在開發(fā)人員和用戶之間沒有差別 [Weinberg 1992] 。恰恰在這類組織環(huán)境中，經(jīng)常采用自動化測試方法。因此，把資源用于自動化測試，并且把自動化測試當(dāng)作一個軟件開發(fā)活動對待，把軟件測試自動化提升到一級。這是解決測試自動化的核心的方案。我們應(yīng)該像運(yùn)作其他的開發(fā)項(xiàng)目一樣來運(yùn)作軟件自動化測試項(xiàng)目。
像其他軟件開發(fā)項(xiàng)目一樣，我們需要軟件開發(fā)人員專注于測試自動化的開發(fā)任務(wù)；像其他軟件開發(fā)項(xiàng)目一樣，自動化測試可以自動完成具體的測試任務(wù)，對于具體的測試任務(wù)來說，自動化開發(fā)人員可能不是這方面的專家，因此，軟件測試專家應(yīng)該提供具體測試任務(wù)相關(guān)的咨詢，并且提供測試自動化的需求；像其他軟件開發(fā)項(xiàng)目一樣，如果在開發(fā)編碼之前，對測試自動化作了整體設(shè)計有助于測試自動化開發(fā)的順利開展。像其他軟件開發(fā)項(xiàng)目一樣，自動化測試代碼需要跟蹤和維護(hù)，因此，需要采用源代碼管理。像其他軟件開發(fā)項(xiàng)目一樣，測試自動化也會出現(xiàn) BUG ，因此，需要有計劃的跟蹤 BUG ，并且對修改后的 BUG 進(jìn)行測試。像其他軟件開發(fā)項(xiàng)目一樣，用戶需要知道如何使用軟件，因此，需要提供用戶使用手冊。
本文中不對軟件開發(fā)做過多講述。我假定您屬于某個軟件組織，該組織已經(jīng)知道采用何種合理的、有效的方法開發(fā)軟件。我僅僅是推動您在自動化測試開發(fā)過程中遵守已經(jīng)建立的軟件開發(fā)規(guī)則而已。本文按照在軟件開發(fā)項(xiàng)目中采用的標(biāo)準(zhǔn)步驟組織的，重點(diǎn)關(guān)注測試自動化相關(guān)的事宜和挑戰(zhàn)。
* 改進(jìn)軟件測試過程
* 定義需求
* 驗(yàn)證概念
* 支持產(chǎn)品的可測試性
* 可延續(xù)性的設(shè)計（ design for sustainability ）
* 有計劃的部署
* 面對成功的挑戰(zhàn)
1. 改進(jìn)軟件測試過程
如果你負(fù)責(zé)提高一個商業(yè)交易操作的效率，首先，你應(yīng)該確認(rèn)已經(jīng)很好的定義了這個操作的具體過程。然后，在你投入時間和金錢采用計算機(jī)提供一套自動化的商業(yè)交易操作系統(tǒng)之前，你想知道是否可以采用更簡單、成本更低的的方法。同樣的，上述過程也是用于自動化測試。我更愿意把 “ 測試自動化 ” 這個詞解釋成能夠使測試過程簡單并有效率，使測試過程更為快捷，沒有延誤。運(yùn)行在計算機(jī)上的自動化測試腳本只是自動化測試的一個方面而已。
例如，很多測試小組都是在回歸測試環(huán)節(jié)開始采用測試自動化的方法?；貧w測試需要頻繁的執(zhí)行，再執(zhí)行，去檢查曾經(jīng)執(zhí)行過的有效的測試用例沒有因?yàn)檐浖淖儎佣鴪?zhí)行失敗?；貧w測試需要反復(fù)執(zhí)行，并且單調(diào)乏味。怎樣才能做好回歸測試文檔化的工作呢？通常的做法是采用列有產(chǎn)品特性的列表，然后對照列表檢查。這是個很好的開始，回歸測試檢查列表可以告訴你應(yīng)該測試哪些方面。不過，回歸測試檢查列表只是合于那些了解產(chǎn)品，并且知道需要采用哪種測試方法的人。
在開始測試自動化之前，你需要完善上面提到的回歸測試檢查表，并且，確保你已經(jīng)采用了確定的的測試方法，指明測試中需要什么樣的數(shù)據(jù)，并給出設(shè)計數(shù)據(jù)的完整方法。如果測試掌握了基本的產(chǎn)品知識，這會更好。確認(rèn)可以提供上面提到的文檔后，需要明確測試設(shè)計的細(xì)節(jié)描述，還應(yīng)該描述測試的預(yù)期結(jié)果，這些通常被忽略，建議測試人員知道。太多的測試人員沒有意識到他們?nèi)鄙偈裁矗⑶矣捎诤ε聦擂味桓胰デ笾?。這樣一份詳細(xì)的文檔給測試小組帶來立竿見影的效果，因?yàn)?，現(xiàn)在任何一個具有基本產(chǎn)品知識的人根據(jù)文檔可以開展測試執(zhí)行工作了。在開始更為完全意義上的測試自動化之前，必須已經(jīng)完成了測試設(shè)計文檔。測試設(shè)計是測試自動化主要的測試需求說明。不過，這時候千萬不要走極端去過分細(xì)致地說明測試執(zhí)行的每一個步驟，只要確保那些有軟件基本操作常識的人員可以根據(jù)文檔完成測試執(zhí)行工作既可。但是，不要假定他們理解那些存留在你頭腦中的軟件測試執(zhí)行的想法，把這些測試設(shè)計的思路描述清楚就可以了。
以前負(fù)責(zé)過一個軟件模塊的自動化測試工作。這個模塊的一些特性導(dǎo)致實(shí)現(xiàn)自動化非常困難。當(dāng)我了解到這項(xiàng)工作無需在很短的時間內(nèi)完成后，決定制定一個詳細(xì)回歸測試設(shè)計方案。我仔細(xì)地檢查了缺陷跟蹤庫中與該模塊相關(guān)的每個已經(jīng)關(guān)閉的缺陷，針對每個缺陷，我寫了一個能夠發(fā)現(xiàn)該問題的測試執(zhí)行操作。我計劃采用這種方法提供一個詳細(xì)的自動化需求列表，這可以告訴我模塊的那一部分適合自動化測試。在完成上述工作后，我沒有機(jī)會完成測試自動化的實(shí)現(xiàn)工作。不過，當(dāng)我們需要對這個模塊做完整回歸測試的時候，我將上面提到的文檔提供給若干只了解被測試產(chǎn)品但是沒有測試經(jīng)驗(yàn)的測試人員。依照文檔的指導(dǎo)，幾乎不需要任何指導(dǎo)的情況下，各自完成了回歸測試，并且發(fā)現(xiàn)了 BUG 。從某種角度看，這實(shí)際上是很成功的自動化測試。在這個項(xiàng)目中，我們與其開發(fā)自動化測試腳本，還不如把測試執(zhí)行步驟文檔化。后來，在其它項(xiàng)目中，我們開發(fā)了自動化測試腳本，發(fā)現(xiàn)相關(guān)人員只有接受相關(guān)培訓(xùn)才能理解并執(zhí)行自動化測試腳本，如果測試自動化設(shè)計的很好，可能會好一些。不過，經(jīng)過實(shí)踐我們總結(jié)出完成一份設(shè)計的比較好的測試文檔，比完成一份設(shè)計良好的測試腳本簡單的多。
你 可能了解 SEI （軟件工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分為 5 個界別，該模型用來對軟件開發(fā)組織劃分等級。 Jerry Weinberg （美國軟件工程專家）也創(chuàng)建了自己的一套軟件組織模型，在他的組織模型中增加了一個額外的級別，他稱之為零級別。很顯然，一個零模式的組織實(shí)際上也是開發(fā)軟件；零模式組織中，在開發(fā)人員和用戶之間沒有差別 [Weinberg 1992] 。恰恰在這類組織環(huán)境中，經(jīng)常采用自動化測試方法。因此，把資源用于自動化測試，并且把自動化測試當(dāng)作一個軟件開發(fā)活動對待，把軟件測試自動化提升到一級。這是解決測試自動化的核心的方案。我們應(yīng)該像運(yùn)作其他的開發(fā)項(xiàng)目一樣來運(yùn)作軟件自動化測試項(xiàng)目。
像其他軟件開發(fā)項(xiàng)目一樣，我們需要軟件開發(fā)人員專注于測試自動化的開發(fā)任務(wù)；像其他軟件開發(fā)項(xiàng)目一樣，自動化測試可以自動完成具體的測試任務(wù)，對于具體的測試任務(wù)來說，自動化開發(fā)人員可能不是這方面的專家，因此，軟件測試專家應(yīng)該提供具體測試任務(wù)相關(guān)的咨詢，并且提供測試自動化的需求；像其他軟件開發(fā)項(xiàng)目一樣，如果在開發(fā)編碼之前，對測試自動化作了整體設(shè)計有助于測試自動化開發(fā)的順利開展。像其他軟件開發(fā)項(xiàng)目一樣，自動化測試代碼需要跟蹤和維護(hù)，因此，需要采用源代碼管理。像其他軟件開發(fā)項(xiàng)目一樣，測試自動化也會出現(xiàn) BUG ，因此，需要有計劃的跟蹤 BUG ，并且對修改后的 BUG 進(jìn)行測試。像其他軟件開發(fā)項(xiàng)目一樣，用戶需要知道如何使用軟件，因此，需要提供用戶使用手冊。
本文中不對軟件開發(fā)做過多講述。我假定您屬于某個軟件組織，該組織已經(jīng)知道采用何種合理的、有效的方法開發(fā)軟件。我僅僅是推動您在自動化測試開發(fā)過程中遵守已經(jīng)建立的軟件開發(fā)規(guī)則而已。本文按照在軟件開發(fā)項(xiàng)目中采用的標(biāo)準(zhǔn)步驟組織的，重點(diǎn)關(guān)注測試自動化相關(guān)的事宜和挑戰(zhàn)。
* 改進(jìn)軟件測試過程
* 定義需求
* 驗(yàn)證概念
* 支持產(chǎn)品的可測試性
* 可延續(xù)性的設(shè)計（ design for sustainability ）
* 有計劃的部署
* 面對成功的挑戰(zhàn)
1. 改進(jìn)軟件測試過程
如果你負(fù)責(zé)提高一個商業(yè)交易操作的效率，首先，你應(yīng)該確認(rèn)已經(jīng)很好的定義了這個操作的具體過程。然后，在你投入時間和金錢采用計算機(jī)提供一套自動化的商業(yè)交易操作系統(tǒng)之前，你想知道是否可以采用更簡單、成本更低的的方法。同樣的，上述過程也是用于自動化測試。我更愿意把 “ 測試自動化 ” 這個詞解釋成能夠使測試過程簡單并有效率，使測試過程更為快捷，沒有延誤。運(yùn)行在計算機(jī)上的自動化測試腳本只是自動化測試的一個方面而已。
例如，很多測試小組都是在回歸測試環(huán)節(jié)開始采用測試自動化的方法?；貧w測試需要頻繁的執(zhí)行，再執(zhí)行，去檢查曾經(jīng)執(zhí)行過的有效的測試用例沒有因?yàn)檐浖淖儎佣鴪?zhí)行失敗?；貧w測試需要反復(fù)執(zhí)行，并且單調(diào)乏味。怎樣才能做好回歸測試文檔化的工作呢？通常的做法是采用列有產(chǎn)品特性的列表，然后對照列表檢查。這是個很好的開始，回歸測試檢查列表可以告訴你應(yīng)該測試哪些方面。不過，回歸測試檢查列表只是合于那些了解產(chǎn)品，并且知道需要采用哪種測試方法的人。
在開始測試自動化之前，你需要完善上面提到的回歸測試檢查表，并且，確保你已經(jīng)采用了確定的的測試方法，指明測試中需要什么樣的數(shù)據(jù)，并給出設(shè)計數(shù)據(jù)的完整方法。如果測試掌握了基本的產(chǎn)品知識，這會更好。確認(rèn)可以提供上面提到的文檔后，需要明確測試設(shè)計的細(xì)節(jié)描述，還應(yīng)該描述測試的預(yù)期結(jié)果，這些通常被忽略，建議測試人員知道。太多的測試人員沒有意識到他們?nèi)鄙偈裁矗⑶矣捎诤ε聦擂味桓胰デ笾?。這樣一份詳細(xì)的文檔給測試小組帶來立竿見影的效果，因?yàn)?，現(xiàn)在任何一個具有基本產(chǎn)品知識的人根據(jù)文檔可以開展測試執(zhí)行工作了。在開始更為完全意義上的測試自動化之前，必須已經(jīng)完成了測試設(shè)計文檔。測試設(shè)計是測試自動化主要的測試需求說明。不過，這時候千萬不要走極端去過分細(xì)致地說明測試執(zhí)行的每一個步驟，只要確保那些有軟件基本操作常識的人員可以根據(jù)文檔完成測試執(zhí)行工作既可。但是，不要假定他們理解那些存留在你頭腦中的軟件測試執(zhí)行的想法，把這些測試設(shè)計的思路描述清楚就可以了。
以前負(fù)責(zé)過一個軟件模塊的自動化測試工作。這個模塊的一些特性導(dǎo)致實(shí)現(xiàn)自動化非常困難。當(dāng)我了解到這項(xiàng)工作無需在很短的時間內(nèi)完成后，決定制定一個詳細(xì)回歸測試設(shè)計方案。我仔細(xì)地檢查了缺陷跟蹤庫中與該模塊相關(guān)的每個已經(jīng)關(guān)閉的缺陷，針對每個缺陷，我寫了一個能夠發(fā)現(xiàn)該問題的測試執(zhí)行操作。我計劃采用這種方法提供一個詳細(xì)的自動化需求列表，這可以告訴我模塊的那一部分適合自動化測試。在完成上述工作后，我沒有機(jī)會完成測試自動化的實(shí)現(xiàn)工作。不過，當(dāng)我們需要對這個模塊做完整回歸測試的時候，我將上面提到的文檔提供給若干只了解被測試產(chǎn)品但是沒有測試經(jīng)驗(yàn)的測試人員。依照文檔的指導(dǎo)，幾乎不需要任何指導(dǎo)的情況下，各自完成了回歸測試，并且發(fā)現(xiàn)了 BUG 。從某種角度看，這實(shí)際上是很成功的自動化測試。在這個項(xiàng)目中，我們與其開發(fā)自動化測試腳本，還不如把測試執(zhí)行步驟文檔化。后來，在其它項(xiàng)目中，我們開發(fā)了自動化測試腳本，發(fā)現(xiàn)相關(guān)人員只有接受相關(guān)培訓(xùn)才能理解并執(zhí)行自動化測試腳本，如果測試自動化設(shè)計的很好，可能會好一些。不過，經(jīng)過實(shí)踐我們總結(jié)出完成一份設(shè)計的比較好的測試文檔，比完成一份設(shè)計良好的測試腳本簡單的多。