“測試驅動開發”(TDD)是一個比較新的概念,在網上可以看到很多介紹文章,它主要討論如何讓開發的代碼更奏效(Work)更潔凈(Clean),“測試驅動開發的基本思想就是在開發功能代碼之前,先編寫測試代碼”??梢钥吹?,TDD是建立在“代碼”級別的驅動,但目前我們需要探討的問題是怎樣在黑盒測試中做到“測試驅動開發”。
首先我們需要糾正一個態度,很多人認為黑盒測試的技術含量不高,可思考可拓展的內容不多,主要的工作就是用鼠標在那里瞎點,于是很多“高級”的技術方法都試圖與黑盒測試劃清界限。但測試人員發現的bug有80%以上都是黑盒測試發現的,手工操作軟件仍是目前檢驗軟件質量最有效的一種方法。
如何在黑盒測試中做到測試驅動開發?我認為可以從用例級別做起,以業務用例指導實現的結果。
開發人員通常比較關注技術,對于業務上的理解容易忽視并出現偏差,而需求文檔又不會很全面的指出應該實現怎樣的結果,這就使得從業務到功能出現一個“閱讀上的障礙”,如果最后發現程序錯了還需返工,這樣耗費的人力物力就非常大了。測試人員和最終用戶不用過分關心軟件實現的細節,所以以業務用例驅動開發,就是一個比較好的方法。給出一個明確的預期結果,指導開發人員如何界定是否達成目標,同樣這也需要運用測試中的各種方法,列舉出業務流程里數據的等價類和邊界值。
業務用例的構造要先于程序實現,與需求和開發人員溝通一致,并以此作為一個基準,保證程序實現不會出錯,還能對整個軟件的進度和質量有一個很好的估計和度量。業務用例可以不關注程序的界面,但一定要有數據的支持。這就是測試主導變化的另一點“數據記錄變化”。
我們不僅要應對變化,還要記錄變化,使測試用例成為對程序持續性的監控,數據可以作為最基本、最簡單的支持。當一個業務很復雜時可以拆分成段(業務段與程序中以窗體或頁面的劃分是不一樣的),使用典型的用例方法列出實際輸入和預期結果。我們希望數據能做到通用和共享,最理想的情況就是建立一個“數據庫”,每個業務用例都從“數據庫”中取得輸入數據和預期結果,這個數據只是針對業務入口和出口的,當程序內部設計變更時,保留的數據不會因此而作廢。舉一個例子,例如我的程序要從某種文件中讀取數據并計算結果,一段時間后程序內部字段增加了,如果是以保存的文件附件方式提供數據,則現在程序很可能就打不開這個文件了。使用“數據庫”指導測試人員可以在變化的程序里直接針對業務輸入,而不關心程序內部結構。
再進一步的話“數據庫”就開始涉及到程序內部的接口,屬于單元和集成測試,這需要開發人員的配合。
2、為用例標明時間(版本)和優先級
為測試用例標明時間或版本可以起到一種基準的作用,標明項目進度過程中的每一個階段,使用例直接和需求基線、軟件版本對應。同樣這需要規范流程,也是對變更的一種確認和控制?;蛘呖梢詾橛美黾右粋€狀態,指明這個用例目前是否與程序沖突,當程序變更時改變用例的狀態,并更新用例版本。
為測試用例標明優先級可以指出軟件的測試重點、用例編寫的重點,減少用例回歸的時間,增加重點用例執行的次數,幫助項目組新人盡快了解需求,在自動化測試的初期也可以參考這個優先級錄制腳本。
3、功能用例與業務用例分開組織
為業務用例單獨開辟出一種分類,將功能用例與業務用例分開組織,按照不同關注點列舉執行路徑。業務用例應在開發前或同期編寫,幫助測試人員和開發人員明確業務,了解正確流程和錯誤流程。功能用例更依賴于程序界面的描述,但功能用例并不等于使用說明。對某些模塊的等價類、邊界值測試會發現很多嚴重的bug,也許與業務無關,但用戶往往很容易這樣操作(例如登錄名,你是否考慮到很長的名字,或者用戶的鍵盤有問題,總是敲入n多空格在里面,這與業務無關,但程序將會怎樣處理?)。
4、審核用例,結對編寫
測試組長或經理對用例進行審核可以做到用例的補充和校對,但一般情況下是很難做到的,我們可以采用另一種方法,就是結對編寫測試用例(前提是你有兩個以上的測試人員),內部審核。
測試用例不是自己編寫自己執行,它需要其他測試人員都能讀懂且明白目標所指。結對編寫可以盡量減少個人的“偏好習慣”,同時也能拓展思維,加強測試重點的確認,小組內部達到統一。一定程度上結對編寫也可以減少組長或經理對用例的管理負擔,提高組員的參與積極性。
四、發展
上面的這些解決方法只是一種建議,具體如何實施到項目中還需根據情況而定。同時即使我們正在積極的尋求改變,我們還是會碰到無數的新問題和新苦惱,也許會比以前更為眾多,這是我們必須付出的。
可以看到測試的發展方向很多很廣,即使傳統的黑盒測試并不是毫無新意,高級的測人員必須同時在測試技巧和專業領域方面都有很高的“修為”。測試工作怎樣更適合我們而發展,將給予我們更多的思考。
原文轉自:http://www.anti-gravitydesign.com