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

　　用例結構的劃分一定程度上也造成了功能和業務的分離，依照界面模塊建立文件夾，并在其中新建不同用例，這使得用例從結構上就很難聯通起來。

　　3、測試未能跟上變化

　　變化!想象一下，當我們越來越多的聽到開發人員在那里高呼“擁抱變化”“敏捷開發”的時候，測試又有什么舉措呢?當地區特性，軟件版本越來越多的時候，測試是否在積極響應呢?變化是我們面臨的最大挑戰，我認為測試未能跟上變化是造成測試過程中遇到種種問題和矛盾的主要原因。

　　對需求和程序的變化測試人員的感受是非常深的，測試總是跟在需求和開發后面跑，使得所有風險都壓在自己身上。不斷壓縮的時間和資源使我們只能放棄那些“不必要”的工作：盡快投入測試，盡快發現bug，而非從整體把握軟件的質量情況，統籌策略。

　　疲于應對的直接影響就是程序質量無法準確度量，進度無法控制，風險無法預估。用例與程序脫節，新增用例混亂和缺少。長此以往我們只得放棄修改、增補用例，甚至放棄之前積累的所有成果。用例變為程序變更的記錄摘要，沒有測試數據的保留，測試步驟和重點無法體現，新加功能與原來的程序逐漸“脫離”，可能還會出現相互違背的情況，但這我們卻無法及時發現。

　　永遠是變化決定我們的下一步工作，這也是混亂的開始。

　　三、可能的解決辦法：

　　上面的問題也許在成熟的公司和項目組內很少遇到，而遇到問題的也需根據不同的情況單獨考慮。分析錯誤并不能給我們帶來成功，而成功的特質也不會盡為相同。所以在這里我希望以探討的方式提出一些可能的解決辦法，不拘泥形式，以結果來確定，最適合的就是最好的。

　　1、測試驅動開發，用例指導結果，數據記錄變化

　　“測試驅動開發”(TDD)是一個比較新的概念，在網上可以看到很多介紹文章，它主要討論如何讓開發的代碼更奏效(Work)更潔凈(Clean)，“測試驅動開發的基本思想就是在開發功能代碼之前，先編寫測試代碼”?？梢钥吹?，TDD是建立在“代碼”級別的驅動，但目前我們需要探討的問題是怎樣在黑盒測試中做到“測試驅動開發”。

　　首先我們需要糾正一個態度，很多人認為黑盒測試的技術含量不高，可思考可拓展的內容不多，主要的工作就是用鼠標在那里瞎點，于是很多“高級”的技術方法都試圖與黑盒測試劃清界限。但測試人員發現的bug有80%以上都是黑盒測試發現的，手工操作軟件仍是目前檢驗軟件質量最有效的一種方法。

　　如何在黑盒測試中做到測試驅動開發?我認為可以從用例級別做起，以業務用例指導實現的結果。

　　開發人員通常比較關注技術，對于業務上的理解容易忽視并出現偏差，而需求文檔又不會很全面的指出應該實現怎樣的結果，這就使得從業務到功能出現一個“閱讀上的障礙”，如果最后發現程序錯了還需返工，這樣耗費的人力物力就非常大了。測試人員和最終用戶不用過分關心軟件實現的細節，所以以業務用例驅動開發，就是一個比較好的方法。給出一個明確的預期結果，指導開發人員如何界定是否達成目標，同樣這也需要運用測試中的各種方法，列舉出業務流程里數據的等價類和邊界值。

　　業務用例的構造要先于程序實現，與需求和開發人員溝通一致，并以此作為一個基準，保證程序實現不會出錯，還能對整個軟件的進度和質量有一個很好的估計和度量。業務用例可以不關注程序的界面，但一定要有數據的支持。這就是測試主導變化的另一點“數據記錄變化”。

　　我們不僅要應對變化，還要記錄變化，使測試用例成為對程序持續性的監控，數據可以作為最基本、最簡單的支持。當一個業務很復雜時可以拆分成段(業務段與程序中以窗體或頁面的劃分是不一樣的)，使用典型的用例方法列出實際輸入和預期結果。我們希望數據能做到通用和共享，最理想的情況就是建立一個“數據庫”，每個業務用例都從“數據庫”中取得輸入數據和預期結果，這個數據只是針對業務入口和出口的，當程序內部設計變更時，保留的數據不會因此而作廢。舉一個例子，例如我的程序要從某種文件中讀取數據并計算結果，一段時間后程序內部字段增加了，如果是以保存的文件附件方式提供數據，則現在程序很可能就打不開這個文件了。使用“數據庫”指導測試人員可以在變化的程序里直接針對業務輸入，而不關心程序內部結構。

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