所以我的理解是：怎樣讓測試計劃對整個軟件測試工作真正具有指導作用
這里把測試計劃和測試方案分開來講（計劃對應于管理層面的問題，方案對應于技術方面的問題）
測試計劃中最重要的內容包括： 進度安排；人力、物力資源分配（包括組織結構等）、風險假設和規避措施。（其他像軟件版本號之類的，只要是個人都會寫，這里不列了）
寫好測試計劃的關鍵在于：
1 充分了解你的團隊的整體實力和團隊中每個成員的特點
2 充分理解為當前軟件制訂的整個研發活動過程
帶過項目的人都知道：在實際項目中，往往進度才是第一位的，但是對進度的把握和估算卻是極其困難的。只有做到這兩點才有可能對進度有比較準確的把握，對人員有一個合理的分配。否則所謂的進度，所謂的資源分配，都是拍腦袋得出的結果，風險假設更是無從談起，這樣的測試計劃文檔只能流于形式也就不足為奇了。
寫好測試方案的關鍵在于：
1 有一個合理的測試計劃
2 熟悉相關業務
3 深入體會用戶的實際需求
這個不想多解釋了，不難理解。
至于測試用例，看到上面不少朋友認為關鍵在于理解用戶需求。
其實理解用戶實際需求是一切的根本，并且對于有些測試（比如像單元測試）對應的測試用例通常和用戶需求之間的關系可能并不直接或是十分密切。
當然，如果有一份好的需求和設計文檔的話，什么事情都解決了。 可是現實往往是不存在這樣的文檔的。
所以我的看法是：
1 對業務理解的深入程度
2 經驗
3 有自己的文檔
前兩條不解釋了。 自己的文檔包括兩方面：一個是常用的特殊測試數據，比如一些特殊字符，極限長度的輸入等等。這個在項目時間緊迫的時候是非常有幫助的（有的時候甚至可以當成check list）。 另一個就是自己測試模塊對應的相關需求和設計文檔。服務器上的標準文檔拖到本地來并且記得及時更新。然后在測試過程中，需要什么內容文檔上沒有，最直接的方法是和開發人員溝通。（其實我很反對這么做。你想，按開發人員自己說的標準去測他們自己開發的模塊能測出因為需求或者設計錯誤導致的問題么……應該是和客戶和designer去溝通，可惜一般沒有這條件-_-）任何標準文檔上缺少的內容，只要是和你有關的，一定要記得做記錄。 當然你有時間有精力把整個系統的需求和設計文檔都搗鼓出來最好，不過通常是沒這可能性的。
補充說明：lz最后提到的“完全憑借自己的經驗在執行測試活動”不如說是完全憑借自己的感覺在執行測試活動。
項目需要的用例詳盡程度可以商量，但是必須要有。 如果進度很緊，可以用一部分用例加上check list進行測試活動（比如很多日本外包項目的UI測試，相當一部分可以用check list來代替具體的用例，效果并不差）
文章來源于領測軟件測試網 http://www.kjueaiud.com/
