《例項化需求》閱讀筆記（3）-活的文件

寫筆記前先吐槽一個英文單詞 “tests”。這個詞其實是測試指令碼的意思，也就是我們們所說的測試用例，“測試用例”（testcase）是rational公司首先提出來的，我們們用這個詞比較多。但是老外不認，測試大牛們只會用tests這個詞，它是個靜態的東西，自動化指令碼，手工測試用例其實都是tests。但是發現翻譯過來的書籍都直接翻譯成“測試”二字，測試我們一般看成一個動作，容易引起誤解。btw，老外說把測試當做動詞的時候寫成test，少一個s，就差遠了。翻譯真是個難做的活兒，3.2節最後一段話讓譯者鬱悶了吧。

書簡述了ATDD和BDD的區別。ATDD側重於讓開發目標更加明確。BDD則側重於制定系統行為的場景。兩者對防止功能退化十分重要。但是書指出，例項化需求既不是防止退化的充分條件，也不是必要條件，只是有效條件。

並且，在Estimating Software Costs 這本書中作者做了統計：通過迴歸測試移除缺陷的平均有效率只有23%。 也就是是說，從保證軟體質量角度，例項化需求所做的長期投資並不是非常划算。但是從其它角度來說卻比較合算，比如。。。blabulabula。。。。。（其實主要在說的是文件的有用性。比如說逆向工程，這好像也是我們目前面臨的問題，從主機裡讀程式碼是讓程式設計師很死腦細胞的事情，耗費了大量精力，並且有時候還會出錯誤。） 書中給出了SongKick公司團隊使用tests來指導系統變更實現時節省了50%的時間，這個很驚人。

根據可執行的需求說明建立文件 觀點： 1.由於可以快速驗證，可以低成本的保持被測系統與可執行文件的一致性。 2.文件是增量式的，其它工作可以同時進行。如果編制文件較大，完全沒有必要讓其他人等候！ 3.書中推薦了一個實用工具relish，可以嘗試一下。

以文件為中心的模型所具有的好處： 交付團隊應該把測試文件看做是一個單獨工件，與交付的系統等同重要。把文件當成關鍵性交付物是以文件為中心的模型最核心的部分。 增強技術結構或者澄清測試意圖不再是技術負債！ 把驗收測試的工作交給初級開發人員和測試人員是有問題的！ （注：同意這句話，不過對測試人員比較有殺傷力，要考慮出路鳥，哈哈哈。） 把活文件看成交付過程中的單獨工件，團隊還可以避免對它投資過度！

Remember： 例項化需求說明的兩種模型 BDD，ATDD及其應用場景。 例項化需求說明的建立是循序漸進的。 活文件是交付過程中的重要工件，與程式碼一樣重要。 側重於建立業務流程文件系統可以幫助你避免長期維護需求說明和測試指令碼造成的大部分常見問題。