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

　　對于草根一族來講，一開始公司很可能就你一個測試人員，有幾種情況：

　　> 公司將“建立一支專業的軟件(測試)隊伍”的艱巨任務寄托在你身上時，先不要沾沾自喜襲擊已經被boss重視了;

　　> 公司只是拿你來標榜自己擁有了測試，拿你來寫測試計劃，測試報告等提交給客戶看的文檔的專業測試——文檔——人員

　　上面兩種是比較常見的情況，在筆者看來，這兩種情況都很好創造了給你學習的機會，第一種情況你可以打著公司的“建立一支專業的軟件(測試)隊伍”旗號學習;第二種情況來講，如果僅僅是寫文檔的話，那剩余的時間就可以好好利用下來了，而目的在于你想提高自己的技能。而我們的學習方向，筆者大概歸納一下：

　　> 測試理論(包括測試基本概念，流程，管理等等內容。對于測試來講，這才是基本)

　　> 測試文檔 (雖然網絡上的文檔中的內容對于目前的你來說不可能完全有用，但是知道一份專業或者說完整的文檔是怎么寫的也是必要的)

　　> 測試工具(對于剛起步的測試人員，如果你不是開發大牛，建議你還是先使用別人已經寫好的工具)

　　> 開發知識 (有則加之，無則添之，總是是要學，因為這一點是為將來打算，這些知識有助于我們更好地測試)

　　筆者在文章開頭提到了人與工具的問題?，F在各種各樣的測試工具很多，有關于性能的測試工具，有關于功能自動化的測試工具等等。不過昨天看到一篇博文，博文作者深感當前幾乎所有人討論的問題都是測試工具怎么用，而關于測試工具開發相關的帖子卻很少，筆者也認為這是一個不正常的現象。的確，對于大多數軟件項目組來講，自己開發一個性能測試工具并不是一個現實的想法，又鑒于性能測試的重要性，在測試組中擁有掌握主流性能測試工具的專家是很迫切的需求。如果可以的話，我們擁有自動化測試工具的專家，我們擁有自動化測試工具自主開發的專家等等這些都是很有用的。不過這些專家的培養的順序也要順勢而行，不僅急不得而且也急不了。

　　當一個優秀的測試團隊成立起來之后，“米”的問題就解決了，這個時候再來針對某一個具體的項目考慮怎樣“炊”的問題就簡單很多了。簡單，并不代表可以不費吹灰之力就可以把事情擺平了。要知道，人是一個復雜的動物，人的心情會有陰晴圓缺，人會有喜怒哀樂，關于這些跟技術不搭調的問題筆者就不扯了，畢竟筆者的人生閱歷還沒有精彩到可以教讀者怎么做人的地步~關于計劃測試中人有關的話題，在本系列的后續文章中會結合“特定的事”“特定的時間”等等繼續探討。

　　(四)——地

　　正所謂，天時地利人和，前面的一片里面筆者花費了大堆口水在“用兵一時，養兵千日”的怎么“養兵”和“兵”自己怎么實現自我修行。 人有了，該是考慮“地利”的問題了。所謂地利，即指軟件的測試環境，這與開發環境有著很大的不同，同時也保持了一定的聯系(廢話)。

　　測試不會憑空出現，正是因為之前有過太多的教訓，人們開始對質量重視起來。從這個意義上來講，相關組織是為了避免損失而測試，而減少支出其實是賺了錢，所以他們進行測試是為了獲取利潤的。從另外一個方面來看，測試也要投資，而測試環境則在這些支出中免不了分一杯“羹”。

　　先看一個筆者趕制的一個草圖

　　對于上面的圖，簡單說明一下，或者“按圖索驥”吧。 在我們計劃測試的過程中，我們使用由頂向下的分析策略。

　　所謂測試環境(我們這里指的是物理意義上的環境)，對于軟件測試來講“咔嚓”一聲分成兩半：硬件環境和軟件環境。

　　把硬件環境拿出來講，包括了測試項目依賴的硬件環境，測試工作本身依賴的硬件環境。

　　所謂測試項目依賴的硬件環境，舉例來講我們測試一個手機操作系統，總得要拿出個手機來試一試吧;如果拖拉機也需要軟件配備，那么一臺拖拉機也是需要的，另外還需要弄一個庫房或者至少一個空地來放這個拖拉機;所謂測試工作本身依賴的硬件環境，至少得一臺測試用的機器吧，對于特殊要求，比如開發一個嵌入式程序用來監控室內二氧化碳的濃度，這個時候一個特殊的工作室可能也是必要的，至少有一個工具可以改變二氧化碳濃度，有個地方可以困住這些二氧化碳吧。關于機器，我們還需要考慮到機器的配置等等問題。

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