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