我之所以在《軟件測試自動化的探索與管理》一文中將軟件開發成熟度作達到一定程度為自動化實施的一個前提條件,是因為自動化測試所依賴的還是沒有自動化情況下的測試體系建設水平。不過總有人愿意自我麻痹:我們現有的測試工作做得遇到瓶頸了,需要通過自動化來提高我們測試工作的效率和精確度。我曾在微薄上和吳博士爭論到底是否需要建設好產品用例庫再去做自動化,無論大家認同與否,我覺得在做測試自動化之前有幾件事情是要好好反省一下自己有沒有做好:
測試完整性——測試人員或者說參與自動化測試的人是否熟悉整個系統的全部邏輯?
測試復用性——測試需求或者說補丁需求在持續地、周期性地追加或變更,測試人員設計出的測試用例是否每次版本發布之后就失去作用?
測試探索性——測試人員是否能夠在測試過程中不斷修改和補充測試用例來讓測試更加完善?
測試經濟性——測試人員有沒有能力使用最小的數據矩陣去完成所有當前版本的需求的測試?
測試效率性——測試人員最快能夠在多少小時之內完成整個版本很多個SRS的一輪測試執行?
測試有效性——測試人員是否在每一個必須的測試檢查點上做了足夠的檢查?
這些方面如果沒有考慮清楚或者沒有做好,我覺得還是不要妄談測試自動化了,因為手動測試做的不好,自動化測試的設計必然也不會很優秀。因此造成的自動化負擔為長期的測試工作帶來的效益很小,但是花費很大,是很不值得的。我們的出發點應該是軟件質量,而并非只是為了節省時間或者人力,如果說人力、進度和質量這三者需要一個平衡點,那么自動化測試在忽略質量的時候,這鐵三角一個都得不到。就像朱少民老師提到的軟件測試的8組關系、13項原則、21個關鍵域,看起來很學院風,但其實也只是測試經驗的提煉而已,我們也可以有自己的測試關注點總結。如果我們在日常的測試工作中接到任意一個或者一組需求都能夠考慮到這因素,那說明我們的質量意識是已經養成了的,我們的基礎工作做得好才能穩定地保證我們的軟件質量。在能夠保證質量或以保證質量為前提的情況下,再去考慮效益的提高才能使鐵三角穩固,重復建設的災難才不會重演。