如何編寫優質的軟件測試需求文檔

　　編寫需求文檔，在嵌入式開發領域是非常普遍的。需求文檔被用來定義開發任務，協調大規模的研發計劃。對于最終的產品，需求文檔扮演著開發者行為和消費者行為之間溝通紐帶的角色。當需求文檔書寫正確的時候，便可以發揮巨大的作用。然而，如果你在嵌入式開發領域工作的時間足夠長，你就會很快發現，這個領域里不合格的需求文檔實在是太多了。當你嘗試對這些不合格的文檔進行修復時，你又會很快發現，書寫正確的需求文檔絕非易事。在這里，我們提出一些建議，希望能將書寫正確需求文檔這件事情變得清晰一些。

　　從較高的層次來看，書寫需求文檔的目的就是要提供對所需行為的有效描述。該所需行為可用一個黑盒系統描述，并需要注意以下細節：

　　工程師可以根據系統所說進行實現

　　測試人員，在不與開發人員溝通的前提下，可以利用滿足硬件要求的設備驗證需求。

　　最終產生的成果滿足終端用戶的要求。

　　黑盒測試 書寫優質的需求文檔：

　　最基本的原則是：需求文檔應當盡量簡潔，用最易懂的描述來約束系統的預期行為。如果你遵循這個原則，剩下的那些重要因素(可測試性、避免過度設計等等)都將變得順理成章。

　　列舉一下更詳細的規則，通常會更有幫助。下面是書寫優質需求文檔需要遵循的步驟：

　　1、定義系統的邊界。這也是黑盒系統所必要的。

　　2、定義輸入和輸出。這也應當是你看待內部系統的唯一方式。

　　3、用最易懂的方式描述系統的預期行為

　　4、除了輸入和輸出之外，你的需求是不是還涉及了系統的其他部分?如果是，那么你的需求就設計過度了。重構需求，讓它變得精簡

　　5、你的需求是不是過于模棱兩可?加入更多的限定規范。注意：有些模棱兩可的描述并不是壞事，假設描述所包含的所有情況均可被接受，且測試的時候不需要附加的信息加以說明，那么就沒關系。你不需要(也不應該)把系統的行為限制得過頭。

　　6、你的需求是否可測試?(這里指的是黑盒測試)如果不是，你最好返回到第4步。如果這種返工發生很多次，那就說明你的黑盒無法正確描述系統，或者你的測試工具不夠優秀。無論是哪種情況，不可測試的需求文檔幾乎就是一文不值的。

　　7、你的需求文檔通俗易懂么?如果你的需求文檔非常難以讀懂，那就說明你寫得不好，只能給那些照著你的需求負責實施的人帶來無盡的痛苦。如果是這樣，回到第3步。

　　8、你是不是真的做到了第4步?你確認么?再檢查一下。

　　例子：下面的例子，讓我們描述一個自制的嵌入式設備的需求，這個設備能從彎曲傳感器上讀取彎曲的頻率，并根據不同的頻率值讓一個LED閃爍。

　　顯然，我們已經完成了步驟2和步驟3了!

　　輸入：從彎曲傳感器讀取數據。

　　輸出：LED。

　　但是我們跳過了步驟1：

　　在這個例子里，我們將把黑盒畫到設備的微處理器上。

　　讓我們繼續往下進行，

　　第4步：除了輸入和輸出以外，我們是否還涉及了其他的系統邊界?

　　微處理器并不關心從彎曲傳感器讀取什么樣的數據，從處理器的角度來看，僅需要做的是測量ADC腳的電壓而已。

　　LED僅由數字輸出腳控制

　　下面，讓我們來修正這個問題：

　　第0版本的需求：

　　1、該設備應當根據ADC腳的不同頻率的電壓，來切換數字輸出端的狀態。

　　第5步： 需求寫模棱兩可么?

　　恩，我們的描述太模棱兩可了.輸出端切換的速度要多快? 跟電壓的關系如何? 輸入電壓的范圍是多少? 讓我們加一些更細節的描述吧：

　　版本0.1

　　1、輸出端應當由一個自由活動的定時器進行控制

　　2、自由運行定時器的頻率最高不得高于每秒10次，不得低于每秒1次.

　　3、自由運行定時器的觸發頻率應當在最高和最低值之間呈線性變化，并與ADC端的輸入電壓成正比.

　　4、ADC端的輸入電壓應當每100毫秒讀取一次

　　5、當ADC端的輸入電壓端被讀入時，控制自由運行定時器周期時間的注冊值也應當被更新.

　　6、ADC輸入端的電壓有效范圍應當被控制在0到1伏之間.

　　第6步： 你的需求是可測試的么?

原文轉自：http://www.uml.org.cn/Test/201205185.asp