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上留下相關的文字說明及描述。