測試即是文檔_測試文檔

       文檔需要全面，即時更新，並且易懂。我說的全面是指除了介紹程式的功能外還應該覆蓋到代碼中一些重要的地方。對很多人來說文檔的重要性不言而喻，但很難保持它的及時性和準確性。糟糕的文檔的後果通常會浪費更多的資源和時間。往往都是出於一些錯誤的原因而編寫的文檔。
　　要求文檔的一些原因
　　有很多原因導致我們需要編寫文檔。團隊經常會由於一些制度上的要求而編寫文檔，或者就是純粹出於無知。下面是一些編寫文檔的錯誤的理由：
　　有人認為文檔和項目的成敗息息相關。
　　文檔能夠證明某些人的存在。
　　需求方除了文檔也不知道要什麼好
　　要你提供文檔的人也就是求個安心，知道事情都OK了
　　工作流程提示說，你該建立文檔了
　　文檔都是過時的
　　軟體文檔的一個主要的問題就是它通常都不是最新的。代碼的某個部分可能發生了改動，但是文檔卻體現不出這個情況。這句話適用於幾乎所有的文檔，影響最大的其實還是需求和測試案例。不管你多努力，文檔的到期無可避免。
　　文檔對誰有用。
　　取決於不同的受眾，文檔的類型和格式也會相應地有所不同。開發人員，測試人員，客戶，主管，終端使用者都是文檔的最大的潛在使用者。
　　開發人員
　　開發人員不應該依賴於文檔，因為它們通常都是過時的。除此之外，沒有什麼文檔能比代碼本身更能提供詳細以及最新的資訊了。如果你想知道某個方法做了些什麼，看下這個方法吧。不確定某個類是幹嘛的。看一眼它。通常只有代碼寫的太差了才需要給它添加文檔。
　　使用代碼本身作為文檔，這並不代表不需要其它的文檔了。關鍵是要避免冗餘。如果看一下代碼就能擷取到系統的詳細資料，那麼還可以有一些其它的文檔來提供快速導讀以及更高層面的一個概述的功能。代碼本身的文檔是回答不了這個系統是幹嘛的或者這個系統用到了什麼技術啊這種類型的問題。大多數情況下，對於開發人員而言，一個簡單的README.md就足夠他快速入門的了。像項目描述，環境配置，安裝，構建及打包指令這些東西對項目的新成員來說非常有用。但那之後，代碼就是你的聖經。產品代碼提供了所有需要的詳細資料，而測試代碼則是作為產品代碼的內在意圖的一個描述。測試案例就是可執行檔文檔，而TDD（測試驅動開發）就是實現它的最常見的方式。
　　假設你用了某種持續整合的方式，如果測試-文檔（這裡測試就是文檔，文檔也是測試）中有一部分不對了，這個用例會執行失敗，它將會很快得到修複。持續整合解決了測試-文檔不正確的問題，不過它不能保證所有功能都是有文檔的。由於這個原因（當然也有其它原因）測試-文檔應當用TDD的方式來建立。如果在代碼開發前，所有的功能都定義成測試案例，那麼測試案例就能作為開發人員的一個完備的最新的文檔了。
　　那團隊的其它成員怎麼辦。測試人員，客戶，主管，還有其它非碼農呢，他們可能無法從產品和測試的代碼中擷取到所需要的資訊。
.......
本文轉自 51Testing軟體測試網