軟件計劃測試系列(五)——時 測試計劃
到了“時”了，這是計劃測試過程中最讓人糾結的地方了。計劃本來就是一件很麻煩的事情，關鍵點就在于計劃的時候很難拿捏準時間的長度。在一本稱之為《軟件工程中的事實與謬誤》的書籍中，作者提到一條軟件項目走向失敗的兩大因素中的一條就是估算不準，由此可見計劃之難了。Aaron現在對于時間計劃搞得也是沒模沒樣。
初一的時候計劃在十五月圓之夜一起賞月對飲，可是天有不測風云，到了十五那天天氣轉陰了，月亮連個影子都沒有更不要提月圓了。在項目中也會經常遇到這種情況，我們預計某年某月某日我們實現某項功能，可是等真的到了那一天，才發現原來我們想象中的那項功能依然只能存在與想象之中了。
那我們怎么做時間計劃呢? 在Aaron看來，因項目性質而異，要知道我們從事的項目大致可以分為兩種：產品性質的和外包性質的。這兩種性質的項目對于時間的要求，對于測試強度的要求是大不一樣的。
對于一般外包項目來講，對于測試要求相對較低，而時間是固定的。當前大多數標榜使用螺旋開發的團隊其實只是變相的甚至是變質的瀑布模型，對于測試的現狀更是如此。測試先行，測試與項目同時啟動在大多數項目中都只是一句口號而已，因為大家心里都明白，口號是不要錢的，所以空喊口號這種最廉價的朝臉上貼金的方式廣受軟件作坊主們的歡迎甚至推崇。廢話不扯了，對于這種項目的測試工作來講，一般是標準的段段式的，即計劃測試，測試用例設計，測試用例執行及bug管理，測試報告提交等等階段。這就好弄多了，根據經驗(如果一點經驗都沒有，那還有直覺)我們把這幾個階段換算成比例，然后把測試總時間瓜分了，需要提醒大家的就是記得在瓜分之后留點“緩沖時間”來，否則到時候出了點意外就麻煩了，記住是在每段時間之后加上一個緩沖期，而不是最后加上一次。
對于產品來講，測試要求會比較高，時間當然也是需要考慮的，套用IT界最常被引用的一句話，“在這個瞬息萬變的時代”，把握時機對于一個產品來講無疑是很重要的。不過，由于眾公司都不愿意自己的產品一出生生了滿身毒瘡——bug。輕則產品銷量受損，重則產夭折，甚至嚴重影響公司形象乃至導致公司運轉等嚴重問題。這個時候我們還是先將測試分段，對于這種項目，我們首先站在測試質量的角度，實事求是按照功能點數目、難度，測試經驗等來估計測試時間，然后將總時間加起來，如果時間充裕，我們考慮加入更多測試面，如果時間緊迫，我們考慮是否刪除部分非核心功能，以降低開發和測試的時間成本，從而為測試質量保駕護航。
回到上面的“月圓之夜”的故事片段上來，這個片段提醒了我們在時間計劃的時候還有一些問題需要注意。上面提到計劃失敗是因為“月圓”這個外界因素沒有達到要求，這就提醒我們在計劃的過程中，應當盡量減少對于外界的依賴，如果依賴是必需的，那么對于依賴可能導致的意外我們要多出幾套應急方案。另外，在項目執行過程中，及時檢查項目進度也是必要的，這可以避免我們跑在錯誤的道路上，那樣只會越錯越遠，這部分不屬于計劃測試的范疇，因此不做考慮了，如果有興趣可以看一下持續集成相關的資料。
文章來源于領測軟件測試網 http://www.k11sc111.com/
