如何寫一份靠譜的軟件測試計劃？(4)

　　接著就是軟件環境了，跟硬件環境一樣，包括了測試項目依賴的軟件和測試工作本身依賴的軟件，當然最重要的是要有個操作系統，還要搭上待測的應用程序。

　　關于待測應用程序就不講了，想想如果沒有待測程序那我們還測什么啊，是不?測試項目依賴的軟件，這里面的彎彎繞就顯得多了一點了。首先，待測程序引用或者操作的一些應用程序得準備齊整，比如說某應用程序用于監測某個人每天打開了多少次Outlook并收發了多少郵件，如果機器上沒有裝上outlook的那我們就只能測試沒有outlook下該應用程序的的表現這一種情況了，雖然這也是一個很重要的用例，但是更多的有用的用例還是需要我們配備上 outlook來測測的。其次待測程序運行的平臺，.NET開發的你總得安裝上相應的.NET Framework吧，web應用程序沒個瀏覽器也是不行的。

　　測試工作本身依賴的軟件，說明白點主要就是測試工具了，這里面的彎彎繞太多，筆者就不繞進去了。

　　操作系統，對于基于windows操作系統的軟件，我們就需要考慮到微軟這些年來給我們貢獻的這么多版本，如果考慮到其他操作系統，我們就不得不考慮到蘋果等等的貢獻了。

　　總結一下，對于測試人員來講，在項目里面不需要考慮到所有的部分(圖的葉子部分)，但非葉子節點部分還是得好好琢磨琢磨。對于開發人員來講，比較常出現的一個情況是軟件工作的環境問題：應用Team Foundation管理團隊項目的時候，項目開發人員A引用了外部DLL(假設為C.DLL)，當簽入源代碼的時候這個DLL是不被簽入到TFS上的，這就會導致服務器上的版本編譯不通過，提示無法找到DLL之類的錯誤信息。這是一個常見的環境錯誤。另外，如果項目組成員使用的開發環境不一致，也可能導致應用程序集成失敗或者BVT運行不通過;如果開發團隊開發環境一致，那么在對應用程序有兼容性要求的時候，相關的系統兼容性測試是必需的。

　　(五)——時

　　到了“時”了，這是計劃測試過程中最讓人糾結的地方了。計劃本來就是一件很麻煩的事情，關鍵點就在于計劃的時候很難拿捏準時間的長度。在一本稱之為《軟件工程中的事實與謬誤》的書籍中，作者提到一條軟件項目走向失敗的兩大因素中的一條就是估算不準，由此可見計劃之難了。Aaron現在對于時間計劃搞得也是沒模沒樣。

　　初一的時候計劃在十五月圓之夜一起賞月對飲，可是天有不測風云，到了十五那天天氣轉陰了，月亮連個影子都沒有更不要提月圓了。在項目中也會經常遇到這種情況，我們預計某年某月某日我們實現某項功能，可是等真的到了那一天，才發現原來我們想象中的那項功能依然只能存在與想象之中了。

　　那我們怎么做時間計劃呢? 在Aaron看來，因項目性質而異，要知道我們從事的項目大致可以分為兩種：產品性質的和外包性質的。這兩種性質的項目對于時間的要求，對于測試強度的要求是大不一樣的。

　　對于一般外包項目來講，對于測試要求相對較低，而時間是固定的。當前大多數標榜使用螺旋開發的團隊其實只是變相的甚至是變質的瀑布模型，對于測試的現狀更是如此。測試先行，測試與項目同時啟動在大多數項目中都只是一句口號而已，因為大家心里都明白，口號是不要錢的，所以空喊口號這種最廉價的朝臉上貼金的方式廣受軟件作坊主們的歡迎甚至推崇。廢話不扯了，對于這種項目的測試工作來講，一般是標準的段段式的，即計劃測試，測試用例設計，測試用例執行及bug管理，測試報告提交等等階段。這就好弄多了，根據經驗(如果一點經驗都沒有，那還有直覺)我們把這幾個階段換算成比例，然后把測試總時間瓜分了，需要提醒大家的就是記得在瓜分之后留點“緩沖時間”來，否則到時候出了點意外就麻煩了，記住是在每段時間之后加上一個緩沖期，而不是最后加上一次。

　　對于產品來講，測試要求會比較高，時間當然也是需要考慮的，套用IT界最常被引用的一句話，“在這個瞬息萬變的時代”，把握時機對于一個產品來講無疑是很重要的。不過，由于眾公司都不愿意自己的產品一出生生了滿身毒瘡——bug。輕則產品銷量受損，重則產夭折，甚至嚴重影響公司形象乃至導致公司運轉等嚴重問題。這個時候我們還是先將測試分段，對于這種項目，我們首先站在測試質量的角度，實事求是按照功能點數目、難度，測試經驗等來估計測試時間，然后將總時間加起來，如果時間充裕，我們考慮加入更多測試面，如果時間緊迫，我們考慮是否刪除部分非核心功能，以降低開發和測試的時間成本，從而為測試質量保駕護航。

原文轉自：http://www.uml.org.cn/Test/200911128.asp