最近，我需要為自己工作的項目制定一份完整的測試策略。在我剛來到這個項目組時，我發現開發人員試圖使用一個不完整的瀑布生命周期模型。這就意味著開發過程要具備專門的團隊基礎。剛好，這個項目組有大約12個開發人員，正處在利用并行開發工作來研究更多迭代方法的過程中。有一個測試新手，工作非常努力，為項目提供僅有的測試。而我為了幫助他們測試，也加入了這個項目。與此同時，項目組雇用了新的項目經理和架構師，非常主動地承諾會在剩余的一年時間內結束項目。這種沉悶的情景是不是聽起來很熟悉？我猜它會是這樣，因為這不是我第一次碰到這種情況。
這里，首要的問題是制定一份測試策略。什么是測試策略？這要看是誰在問你。這篇文章里，我們會把測試策略作為所有測試階段、測試技術和項目所使用的測試工具的目標。最重要的一點，測試策略應該使測試過程中的交流變得更為容易，而它會影響到整個項目組。
通過制定測試策略來指導我們的工作，下面是項目組所碰到過的一些具體問題，我們需要尋找一些解決他們的方法：
· 缺乏可重復性測試—-項目缺少回歸測試。
· 缺乏可見性測試—-沒有收集衡量結果的指標，唯一的標準就是發布代碼的期限。
· 反作用的構建過程—-他們只對項目的緊急程度構建響應，沒有預測其他構建人的需要。
· 沒有對測試環境或測試數據進行控制。
· 代碼發布后，沒有進行單元或集成測試。
· 沒有簡單的自動化過程，沒有測試過程。
下面的故事會告訴我們如何定義并實施一個測試策略。
讓我們開始吧
在制定測試策略時，你需要和項目中的關鍵人物一起，將關注點放在你們所面對的問題上，制定一個長期的解決方案，可以在整個項目周期內實施。除了上面列出的那些問題之外，我們的項目解決方案還要滿足測試策略的基本需求：在開發周期內，幫助項目組盡可能早的找到最嚴重的bugs。想盡早地發現最嚴重的缺陷，需要把項目的測試部分和開發部分聯合在一起，包括不同的測試階段、測試類型、項目環境，以及如何在環境、角色、職責之間升級代碼，還有普遍使用的工具。
這個看起來是不是有點復雜？實際上，它比你想象的簡單。
保持簡單：寫字板上的計劃
測試策略應該盡量的簡單，這樣我們可以將其展現在白色的寫字板上，同時，一個簡短的會議，你應該可以把它的含義解釋給項目組內的任何一個人。在你花時間把測試策略的細節寫入文檔之前，清晰地定義簡化的概念是簡單性的保證。把想法和內容寫到寫字板上的過程是一件非常有參與性的事情，它可以幫助人們共享意見和觀點，這時候，寫字板往往是最好的媒介。人們使用寫字板時，會畫一些漂亮的圖和流程圖，而這些圖形符號每個人都能理解。
制定測試策略時，你需要把項目組的其他人包含進來。一般有項目經理、開發主管、架構師、DBA（數據庫管理員），以及其他一些關鍵人物，他們具有一些可利用的技術資源，所以他們可能具有更好的想法。此外，你的測試策略應該覆蓋整個項目的生命周期，讓每個人都能按照它的方式工作。這意味著你需要這些技術人員投入其中，以保證它能夠成功地實施。至少，他們可以給你更多有關測試類型的現實想法（單元測試、代碼復查、執行期分析等等）。我通常試著尋找那些最大程度地包含在項目中的人，和他們一起開會討論。因為，他們的洞察力和建議往往是非常寶貴的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
