1、Rquirement
◆根據系統的需求進行編寫測試需求，測試需求的編寫，需求簡單明了。
◆測試需求點加上與系統需求一致的編碼。
規則：
◆在Requirement、Test Plan、Test Lab中，基本流只存在一個，并且排在第一項。
(在TD中的后續步驟中，可對該基本流進行重復的運行測試)
◆在需求編寫的大體分級上，應該遵循的順序：主菜單→次菜單→功能點。
◆測試中的需求點要與實際的系統編碼一致。
◆當需要對功能點的某一需求進行分級時，也遵循“功能點－需求點”的規范
以task2007為例子，制定需求的編寫格式：
◆在task2007中，二級菜單就是頁面的各個功能點，所以按“主菜單→功能點”編寫。
◆task分為new、edit、delete、remind
◆逐一對功能點進行細分，new又可分為Basic Flow（基本流）和Alternation Flow（可選流）。
◆可選流可以有多個，按照A01、A02、A03等進行編號，需求點A01還可以繼續進行劃分， A0101、A0102等，依次類推。
◆當需求編寫完畢后要導到Test Plan中。
2、Test Plan
◆編寫Test Plan中的主要大的功能點，要和需求中的一致；
◆根據功能點的具體項進行分支，編寫測試用例；
規則：
◆在Test Plan中，基本流只存在一個，并且排在第一項。
◆測試用例的上下級關系必須與需求保持一致，多級的用例允許用文件夾進行分類
◆如果在測試用例上有做功能點名稱的修改，在需求中也應做相應的更新。
◆可以通過在需求中選擇不同的視圖進行匹配，達到一一對應的關系。
以task2007為例子，制定Test Plan的編寫格式：
◆從Requirement導到Test Plan中，根據具體的功能的進行劃分，然后編寫測試用例。
◆如果在Test Plan中有進行功能點的修改時，應該與需求進行匹配，達到一一對應。
3、Test Lab
◆編寫Test Lab的編寫和Test Plan中的主要大的功能點是一一對應的。
◆可以通過再次拖動測試用例，對測試用例進行多次執行。
規則：
◆在Test Lab中，基本流只存在一個，并且排在第一項。
◆當你要執行多次測試用例時，在Test Lab中應該保存執行的結果。
◆可以通過在Test Lab中編寫的功能點，需達到一一對應的關系。
4 、Defects
◆提交或者修改bug時，必須在TD中填寫相應的信息。
規則：
◆開發人員修改bug時，需要填寫bug修改的優先級和估計修改的時間
◆除開發人員填寫的內容外，其他均由測試人員進行填寫；
◆計劃關閉bug的版本欄位允許為空。
驗證bug的標準
◆根據bug的描述重復該bug的發生操作；
◆需要重新對該bug所屬的用例進行重新執行；
◆驗證bug，需要在TD上留下相關的文字說明及描述。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
