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

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

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

    寫好測試計劃的關(guān)鍵在于：

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

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

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

    寫好測試方案的關(guān)鍵在于：

    1有一個合理的測試計劃

    2熟悉相關(guān)業(yè)務(wù)

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

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

    至于測試用例，看到上面不少朋友認(rèn)為關(guān)鍵在于理解用戶需求。

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

    當(dāng)然，如果有一份好的需求和設(shè)計文檔的話，什么事情都解決了。可是現(xiàn)實往往是不存在這樣的文檔的。

    所以我的看法是：

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

    2經(jīng)驗

    3有自己的文檔

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

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

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

    相關(guān)推薦：

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

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

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

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

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