按照以前自己的測試模板設計了一份測試計劃,但是正好想起來前幾天買的一本書來,翻了一下這本號稱“軟件測試與質量保證圣經”p79,關于測試計劃的部分,不看不知道,一看才發現自己的測試計劃中很多東西都不夠完善,有很多必要的內容沒有加入進去。此時無比慶幸自己的測試計劃文檔尚未提交,否則把這個交給那個大牛老大,估計要被批了,抓緊時間按照書上的內容對測試計劃進行了修訂,因為“圣經”上組織的比較亂,有重復的現象,所以這次修訂還是花了自己不少時間。
再次審閱了一下自己的文檔,終于放心的將文檔發出去了??墒鞘虑檫€沒有完,下午的時候大牛老大還是找我了,而且是因為測試計劃不合格,雖然他說的很委婉……他說主要問題是因為我的測試計劃形式上的東西比較多,而他所關心的內容卻并沒有多少。他給我看了幾份微軟內部的測試計劃文檔(老大剛從微軟辭職回來),結合文檔我確實發現了很多不一樣的地方。微軟的測試計劃中更注重的是測試思路,或者說這就是一份測試設計文檔,而對于其他的諸如測試人員,測試進度,測試方法等等內容卻沒有介紹,總之他們的測試計劃目的是讓讀者看了就對整個測試區域的測試思路很了解,甚至可以直接由此來組織生成用例,這樣看來這份測試計劃的使用性就更加強了。加上前些日子在上一個項目寫測試報告時候,我所看到的微軟測試模板,也是關注的是測試結果和分析,而對于測試的執行,測試人員等一些信息卻很少介紹或者沒有介紹。這樣看來,微軟內部文檔的實用主義觀念是相當深入人心啊,而且個人看來這種實用主義對于測試本身是相當有用的。
其實話說回來,并不是說微軟的文檔就比其他的文檔好了,其他的文檔,包括網絡上流傳的很多測試計劃的模板,以及“圣經”上面對于測試計劃的介紹,都是很詳細的很有用的,我們在工作中使用哪種模板,更多的要考慮公司龜腚或者實際需要了。實際上我看到的另外一份微軟GenericTestPlan就是極其詳盡,包括了測試各個方面,這就更加印證了剛才那句話,做事情還是對癥下藥才好。
原文轉自:http://www.anti-gravitydesign.com