文檔測試范疇
軟件產品由可運行的程序、數據和文檔組成。文檔是軟件的一個重要組成部分。
文檔內容
測試方案
主要設計怎么測試什么內容和采用什么樣的方法，經過分析，在這里可以得到相應的測試用例表。
測試執行策略
可以主要包括哪些可以先測試，哪些可以放在一起測試之類的。
測試用例
主要根據測試用例列表，寫出每一個用例的操作步驟、緊急程度、預置結果和備注信息。
BUG描述報告
主要可以包括，測試環境的介紹，預置條件，測試人員，問題重現的操作步驟和當時測試的現場信息。
整個項目的測試報告
從設計和執行的角度上來對此項目測試情況的介紹，從分析中總結此次設計和執行做的好的地方和需要努力的地方和對此項目的一個質量評價。
用戶文檔測試要點
1、讀者群。文檔面向的讀者定位要明確。對於初級用戶．可能需要從鼠標的用法、 點擊確定按鈕等講起：對於中級用戶，重要界面的截圖和關鍵步驟每一個參數 的選擇方法都需要介紹：對於高級用戶．則沒有必要給出太多的界面截圖，但對重要參數的講解一定要深入．用詞要專業。特別是不論用戶群定位如何．文檔都不可以寫成散文、詩歌或者偵探、言情小說．文檔的目的是要讓用戶看得懂．能理解。
2、術語。文檔中用到的術語要適用於定位的讀者群。用法一致。標准定義與業界規范相吻合。如果有索引或交叉引用，所有的術語都應能夠進行索引和交叉引用。如果術語較多，在紙介質手冊的末尾應給出術語索引：如果被測軟件提供二次開發功能．有大量函數．則有必要編寫獨立的函數手冊和開發指南。
3、正確性。這是非常重要的．會占用文檔測試的大量時問和人力。測試中需檢查所有信息是否真實正確，查找由於過期產品說明書和銷售人員誇大事實而導致的錯誤。檢查所有的目錄，索引和章節引用是否已更新，嘗試鏈接是否准確，產品支持電話、地址和郵政編碼是否正確。
4、完整性。慢慢地仔細閱讀文字．完全根據提示進行操作，不要作任何假設。對照軟件界面檢查是否有重要的分支沒有描述到，甚至是否有整個大模塊沒有描述到，耐心補充遺漏的步驟。用戶不會知道遺漏了什么信息，直到有一天他使用軟件時走到了這個分支。對於極其熟悉被測軟件的人來說，這項測試相當困難，因為思路己固定地按照一定的流程去測試．極易忽略不常用的部分。因此．可以考慮讓不是很熟悉被測軟件的人員進行此項目的測試。
5、一致性。按照文檔描述的操作執行后，檢查軟件返回的結果是否與文檔描述相同。要留意軟件界面上出現的版本號與手冊、幫助上的信息是否一致。
6、易用性。紙介質文檔可以通過目錄、關鍵詞索引提高用戶使用的易用性。條理清晰、結構合理的文檔是優質軟件的一個顯著特征。對關鍵步驟以租體或背景色給用戶以提示．合理的頁面布局、適量的圖表都可以給用戶更高的易用性。電子文檔或幫助系統顯然比紙介質在這方面有更大的優勢。需要注意的是．文檔要有助於用戶排除錯誤．只描述正確操作而不描述錯誤處理辦法的文檔是不負責任的。與程序大多用於錯誤處理一樣．文檔對於用戶看到的錯誤信息應當有更詳細的文檔解釋，而且不應讓用戶花費太多的時間去尋找所需的解釋。
7、圖表與界面截圖。檢查所有圖表與界面截圖是否與發行版本相同。對於成熟的軟件開發商來說．界面在設計階段就應基本確定，不應在軟件開發后期有大的變動。而此項測試就是要發現在文檔完成后是否有界面變動．確保屏幕截圈源於發行版本。測試中還要注意圖表標題的正確性。
8、樣例和示例。像用戶一樣載入和使用樣例。如果是一段程序．就輸入數據並執行它。以每一個模板制作文件．確認它們的正確性。想像一下樣例不能執行的問題交給技術支持人員時的情景……
9、語言。對於英語文檔來說，拼寫和語法檢查器太常見了．一般不會出現拼寫和語法錯誤。但對於中文文檔來說，可以采用一些校對工具輔助人工檢查，並進行細致專業的校對．不要讓用戶發現錯別字，不要出現有二義性的說法。特別耍注意的是屏幕截圖或繪制圈形中的文字．不能想當然．沒有任何工具能夠從圖形中找出語法錯誤．
10、印刷與包裝。文檔鍘試似乎完成了，文檔終於變成精美的冊子，這時．測試人員還需抽查印刷質量，看看手冊厚度與開本是否合適．翻看起來是否方便，包裝盒的大小是否合適，光盤盤的固定有沒有問題，有沒有零碎易丟失的小部件等等。這時發現的問題．如果不是太嚴重．己不可能在這個版本中進行改進．但對下一個版本的制作來說是非常有價值的。
文檔測試注意事項
1、文檔常常得不到足夠的重視，文檔的開發缺乏足夠的資金和技術支持，而文檔 的測試更得不到重視。一個好的軟件項目．一定要為文檔測試留出預算，像對程序一樣對文檔給予關注。對文檔中發現的缺陷．也需像發現程序缺陷一樣給出報告。
2、編寫文檔的人可能並不是軟件特性方面的專家，對軟件功能可能了解得並不深入。其結果就是寫出來的產品說明書可能並不到位．或者不能解釋復雜的產品特性。軟件文檔測人員可以與文擋作者緊密合作．保證文檔中所包含信息的質量，並隨產品的更新而更新。更重要的是，測試人員可以發現並出程序中難以使用或難以理解之處，讓文檔作者在文檔中作出更好的解釋。
3、由於文檔的印刷需要花費少的時間，可能是幾周．如果追求印刷質量的話可能需要幾個月。而在這段時間內，軟件發現的錯誤可以有時問修改，程序報可能已經發生了改變，而文檔無法反映最終的修改。Readme發明正因為如此，它是將最的改動通知用戶的方式。它能使文檔保持到最后一刻發布．從而保證與軟件程序的同步。同時，隨軟件發布的聯機幫助信息也可以盡可能地反映最新修改。如果文檔測試不夠充分．大量錯誤將不得不隨着印刷精美的手冊到達用戶手中．而Readme文件就不是最新特性的發布而是長長的勘誤表了。
4、文檔測試不僅僅是對文字的校對．更可以輔助找到更多的程序錯誤。文檔編寫人員與文檔測試人員審視程序的角度與程序員和程序測試人員井不相同，因此由文檔測試提示的問題也不同於程序員和程序測試人員所發現的問題，文檔測試往往會發現其他測試無法發現的嚴重錯誤，例如，功能實現錯誤、易用性不好、用戶手冊與程序實現不吻合等問題。當然，這是在全面測試的基礎上．而全面測試意味着每3—5頁花費l小時的時間。測試人員審看文檔的速度越快，從文檔和程序中發現問題的機會就越少。加強測試監督、重新培訓測試人員，甚至更換測試人員能有助於解決這一問題
用戶手冊文檔測試
用戶手冊是用戶文檔中最重要的一部分。在對用戶手冊進行測試時，應拿着它坐在計算機前，進行如下操作。
1、准確地按照手冊的描述使用程序。在每個例子中如實地進行每個鍵盤操作。用戶在按照手冊運行程序時可能會進行錯誤的操作，因此鍘試時測試人員也可以隨心所欲地“犯錯誤”。檢查計算機對錯誤的處理和手冊對錯誤處理的描述應當占用測試人員的大部分精力。
2、嘗試每一條建議。即使建議並沒有完全表達清楚，仍應按步驟去嘗試。用戶依照建議會做什么，測試人員就應當做什么，甚至嘗試更多的可能性。
3、檢查每條陳述。測試人員需要對每條陳述進行檢查．園為用戶手冊是產品最終的規范．是用戶檢查程序運行是否正確首先求證的地方。查找容易誤導用戶的內容。有些示例和特征描述得並不准確。一般的讀者可能會從中歸納出錯誤的結論。用戶可能對程序的能力抱有過高的期望．或是憑空想象一些實際並不存在的約束條件。盡早標識出易被人誤解的內容．這一點極其重要。
幫助文檔測試
幫助文檔的測試在很大程度上與用戶手冊測試相同．但幫助並不只是用戶手冊的電子版．因此再給出以下幾點補充說明。
1、准確性。對幫助准確性檢查的細致程度至少要接近於對用戶手冊的檢查。通常幫助文本都沒有得到良好的處理和充分涮試．無法受到用戶的欣賞。一旦用戶發現幫助中存在明顯的錯誤．他可能對幫助系統的信任程度大大下降。
2、幫助是文檔編寫和程序編寫的結合。不僅要檢查文本的准確性．還要檢查程序的可靠性，制作幫助的人員往往並不是專業的程序員，他們在使用幫助制作工具的技巧．與程序的接口等問題上不可能達到完美。
3、幫助索引。如果幫助系統包含了索引或主題列表，允許用戶由索引進入到主題中．測試人員就必須逐條進行檢查。
4、超鏈接。陳非是早期開發的軟件或開發商對幫助過於不重視，超鏈接是在線幫助中必須的功能。測試人員必須對每個鏈接都測試到．復雜的超鏈接可能會對一個主題形成樹狀結構展開的若干頁面．甚至構成網狀結構。測試人員有義務檢查每條分支。
5、鏈接的意義。索引和鏈接的條目應當是有意義的，測試人員需要發現是否有一些幫助主題未出現在索引里．或出現的名稱不恰當。如果用戶不能迅速找到所需的信息．只能說幫助系統在一程度上是失敗的。
6、幫助的風格。很少會有用戶能悠用地查看幫助，幫助的閱讀者是帶着問題、焦躁不安而缺乏耐心的。幫助文本需要比用戶手冊更為簡潔，風格也應更為簡單。良好的幫助系統應該是面向任務或面向操作的．它必須提供一些有意義的信息．讓用戶能立即開始或繼續他的操作。任何在幫助中出現的令人迷惑或離題的內容都可以作為測試問題
