對于目前大部分公司存在的狀況，軟件評測師的很多測試計劃文檔只是一種形式而已，所以希賽小編的理解是：怎樣讓測試計劃對整個測試工作真正具有指導作用。

    這里把測試計劃和測試方案分開來講（計劃對應于管理層面的問題，方案對應于技術方面的問題）

    測試計劃中最重要的內容包括：進度安排;人力、物力資源分配（包括組織結構等）、風險假設和規(guī)避措施。（其他像軟件版本號之類的，只要是個人都會寫，這里不列了）

    寫好測試計劃的關鍵在于：

    1充分了解你的團隊的整體實力和團隊中每個成員的特點

    2充分理解為當前軟件制訂的整個研發(fā)活動過程

    帶過項目的人都知道：在實際項目中，往往進度才是第一位的，但是對進度的把握和估算卻是極其困難的。只有做到這兩點才有可能對進度有比較準確的把握，對人員有一個合理的分配。否則所謂的進度，所謂的資源分配，都是拍腦袋得出的結果，風險假設更是無從談起，這樣的測試計劃文檔只能流于形式也就不足為奇了。

    寫好測試方案的關鍵在于：

    1有一個合理的測試計劃

    2熟悉相關業(yè)務

    3深入體會用戶的實際需求

    這個不想多解釋了，不難理解。

    至于測試用例，看到上面不少朋友認為關鍵在于理解用戶需求。

    其實理解用戶實際需求是一切的根本，并且對于有些測試（比如像單元測試）對應的測試用例通常和用戶需求之間的關系可能并不直接或是十分密切。

    當然，如果有一份好的需求和設計文檔的話，什么事情都解決了?？墒乾F(xiàn)實往往是不存在這樣的文檔的。

    所以我的看法是：

    1對業(yè)務理解的深入程度

    2經(jīng)驗

    3有自己的文檔

    前兩條不解釋了。自己的文檔包括兩方面：一個是常用的特殊測試數(shù)據(jù)，比如一些特殊字符，極限長度的輸入等等。這個在項目時間緊迫的時候是非常有幫助的（有的時候甚至可以當成checklist）。另一個就是自己測試模塊對應的相關需求和設計文檔。服務器上的標準文檔拖到本地來并且記得及時更新。然后在測試過程中，需要什么內容文檔上沒有，最直接的方法是和開發(fā)人員溝通。（其實我很反對這么做。你想，按開發(fā)人員自己說的標準去測他們自己開發(fā)的模塊能測出因為需求或者設計錯誤導致的問題么……應該是和客戶和designer去溝通，可惜一般沒有這條件－_－）任何標準文檔上缺少的內容，只要是和你有關的，一定要記得做記錄。當然你有時間有精力把整個系統(tǒng)的需求和設計文檔都搗鼓出來最好，不過通常是沒這可能性的。

    補充說明：最后提到的“完全憑借自己的經(jīng)驗在執(zhí)行測試活動”不如說是完全憑借自己的感覺在執(zhí)行測試活動。

    項目需要的用例詳盡程度可以商量，但是必須要有。如果進度很緊，可以用一部分用例加上checklist進行測試活動。

    相關推薦：

  軟件評測師新手如何掌握測試技巧 

  不會編程就做不好軟考測試師么？

  系統(tǒng)集成項目管理工程師考試資訊及備考經(jīng)驗

  軟件測試的原則和經(jīng)驗分享

  信息系統(tǒng)項目管理師案例分析之變更案例答題技巧