從測試用例看測試的問題及變化(3)

　　再進一步的話“數據庫”就開始涉及到程序內部的接口，屬于單元和集成測試，這需要開發人員的配合。

　　2、為用例標明時間(版本)和優先級

　　為測試用例標明時間或版本可以起到一種基準的作用，標明項目進度過程中的每一個階段，使用例直接和需求基線、軟件版本對應。同樣這需要規范流程，也是對變更的一種確認和控制?；蛘呖梢詾橛美黾右粋€狀態，指明這個用例目前是否與程序沖突，當程序變更時改變用例的狀態，并更新用例版本。

　　為測試用例標明優先級可以指出軟件的測試重點、用例編寫的重點，減少用例回歸的時間，增加重點用例執行的次數，幫助項目組新人盡快了解需求，在自動化測試的初期也可以參考這個優先級錄制腳本。

　　3、功能用例與業務用例分開組織

　　為業務用例單獨開辟出一種分類，將功能用例與業務用例分開組織，按照不同關注點列舉執行路徑。業務用例應在開發前或同期編寫，幫助測試人員和開發人員明確業務，了解正確流程和錯誤流程。功能用例更依賴于程序界面的描述，但功能用例并不等于使用說明。對某些模塊的等價類、邊界值測試會發現很多嚴重的bug，也許與業務無關，但用戶往往很容易這樣操作(例如登錄名，你是否考慮到很長的名字，或者用戶的鍵盤有問題，總是敲入n多空格在里面，這與業務無關，但程序將會怎樣處理?)。

　　4、審核用例，結對編寫

　　測試組長或經理對用例進行審核可以做到用例的補充和校對，但一般情況下是很難做到的，我們可以采用另一種方法，就是結對編寫測試用例(前提是你有兩個以上的測試人員)，內部審核。

　　測試用例不是自己編寫自己執行，它需要其他測試人員都能讀懂且明白目標所指。結對編寫可以盡量減少個人的“偏好習慣”，同時也能拓展思維，加強測試重點的確認，小組內部達到統一。一定程度上結對編寫也可以減少組長或經理對用例的管理負擔，提高組員的參與積極性。

　　四、發展

　　上面的這些解決方法只是一種建議，具體如何實施到項目中還需根據情況而定。同時即使我們正在積極的尋求改變，我們還是會碰到無數的新問題和新苦惱，也許會比以前更為眾多，這是我們必須付出的。

　　可以看到測試的發展方向很多很廣，即使傳統的黑盒測試并不是毫無新意，高級的測人員必須同時在測試技巧和專業領域方面都有很高的“修為”。測試工作怎樣更適合我們而發展，將給予我們更多的思考。

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