林振文

（同濟大學，中國 上海 200092）

1 問題分析

許多測試類的書籍都有大幅篇章介紹用例的設計方法，如等價類劃分，邊界值，錯誤推斷，因果圖，判定表等。但實際應用中這些理論卻不能給我們很明確的行為指導，尤其是業(yè)務復雜、關聯(lián)模塊緊密、輸入標準和輸出的結果之間路徑很多的時候，一味的遵循固有的方法只能夠在心理層面上得到滿足，而無法真正有效地提高測試的效果，并且我們也沒有足夠的時間和資源編寫完備的用例。通常我們只能依靠以前項目的用例編寫經(jīng)驗（或習慣），希望能夠在一個完整的項目中更做的加規(guī)范化，但絕大多數(shù)的情況是只停留在“書寫的規(guī)范”的層面上，真正的測試用例設計上還是存在很多的問題。

知道如何執(zhí)行這個用例，但它要說明什么呢？（多數(shù)用例給我們的感覺是“只見樹木，不見森林”，只說明某一功能的實現(xiàn)，無法串起）通過上面的一系列問題可以看到，似乎測試用例給我們帶來的問題遠多于益處，也正是因為在實際過程中遇到的問題積累，導致我們有很充分的理由忽視或拒絕用例的應用。但沒有用例或簡略用例的編寫我們又會舒服很多么？不言自明，誰也不想倒退發(fā)展。

2 產(chǎn)生原因

事實上我們在測試用例編寫和設計上遇到的一系列問題只是一種表面的呈現(xiàn)，究其原因我認為有如下幾點：

2.1 沒有適合的規(guī)范

“適合的規(guī)范”或稱“本地化的規(guī)范”。這是我們在測試過程中遇到的第一個問題，通常也是很容易習慣且淡忘的。我們擁有相當多的流程文檔、指導步驟和書本上的定義，但它適合我們當前的項目么？每一個測試工程師在進入這個職業(yè)的初期都會了解一些測試上的概念和術語，進入公司或項目組后也會進一步學習相應的文檔，例如怎樣規(guī)范編寫，怎樣定義bug級別，軟件實現(xiàn)的主要業(yè)務等。但當測試經(jīng)理開始給我們分配某一模塊的用例編寫時，又有多少人知道該怎樣去寫，怎樣寫算是好？

在測試論壇中常能看到介紹用例編寫方法的帖子，而迷茫于怎樣應用到實踐的回復也不為少數(shù)。為何我們無法在公司和項目組內(nèi)找到明確且適合的規(guī)范？于是我們只得選擇從書本或之前的用例中復制，不管是結構還是方式都依賴于以往的經(jīng)驗，我并不是說這樣就是錯誤的，但不能總結成文的經(jīng)驗無法給予測試更多幫助。我們有太多經(jīng)驗，但卻沒有形成適合的規(guī)范。

2.2 功能與業(yè)務的分離

舉個例子來說，現(xiàn)在的技術往往是知道如何進行一個輸入框的測試，而卻忽略了對此輸入框的功能來進行說明，深入的分析下去我們會發(fā)現(xiàn)，測試用例的選取和其功能存在著越細致分離其聯(lián)系越緊密的特點。往往我們采用的測試用例選取方法如：邊界值分析、等價類選取、因果圖法，而這些選取用例的方法往往停留在理論層面的方法，是一種經(jīng)驗的總結，其本身比較偏向代碼方面的考量，而對實際業(yè)務層面的測試用例的選取還需要更多的去考慮其功能上面的影響和測試。

整個軟件中存在很多復雜的業(yè)務，也涉及了很多功能，其內(nèi)部的分支更是繁多，這樣一來測試用例的涉及就需要簡明、準確。對于功能的測試用例往往依賴于程序界面，對其業(yè)務的描述往往依賴于需求分析文檔。這樣一來對于測試就需要更偏向于依照實際的用戶接口來編寫測試用例，找到其邊界值，給出其等價類的代表性測試用例。對于業(yè)務流程只能憑借測試經(jīng)驗來進行理解，這時測試出來的BUG是最多的，可能無法使這個BUG對應到具體的用例上，只能自己添加note向開發(fā)人員指出可能出錯的源頭。正因為我們沒有很好的積累在業(yè)務上的測試用例，才使得我們感到執(zhí)行測試用例時發(fā)現(xiàn)的錯誤不多。

2.3 測試未能跟得上程序的變化

當我們越來越多的聽到開發(fā)人員在那里高呼“擁抱變化”“敏捷開發(fā)”的時候，測試又有什么舉措，當?shù)貐^(qū)特性，軟件版本越來越多的時候，測試是否在積極響應，程序的變化往往是我們面臨的最大的挑戰(zhàn)，測試未能跟上變化是造成測試過程中遇到種種問題和矛盾的主要原因。

3 解決方法

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

3.1 驅動測試開發(fā)，指導用例結果，記錄數(shù)據(jù)變化

“驅動測試開發(fā)”（TDD）是一個非常新的測試概念，各類刊物上也有對其描述，主要研究的是如何使代碼更奏效 （Work）、更潔凈（Clean），“驅動測試開發(fā)的基本宗旨是在軟件開發(fā)相應的功能前，先對于其所實現(xiàn)的功能編寫測試用例代碼”。顯而易見，TDD是在“代碼”級的驅動觸發(fā)的，但目前研究的問題是如何在黑盒測試過程中實現(xiàn)“驅動測試開發(fā)”，一般認為可從測試用例的級別開始做起，用具體實際的業(yè)務來指導實現(xiàn)的結果。

軟件開發(fā)人員往往注重代碼如何實現(xiàn)其功能，而對業(yè)務上的實際操作的理解并不透徹，而需求分析報告有不會全面的給出具體要實現(xiàn)什么樣的功能和場景，這就樣一來就存在了程序開發(fā)人員和實際需求者的不一致的現(xiàn)象，如果最后發(fā)現(xiàn)程序錯了就需要重做，這樣不僅耗費人力更加對公司的開發(fā)進度有著很大的影響。軟件測試人員與最終用戶不用過分關心軟件實現(xiàn)的細節(jié)，所以用業(yè)務用例來對開發(fā)進行驅動，是一個比較合適的選擇。給出一個明確的預期結果，指導開發(fā)人員如何界定是否達成目標，還需要用到各種軟件測試方法來分析出各個業(yè)務過程中需要測試的等價類和邊界值。

3.2 設置測試用例版本和優(yōu)先級

為不同時期的測試用例設置不同的版本能夠起到基準的作用，標明項目進度過程中的每一個階段，使用例直接和需求基線、軟件版本對應。同樣這需要規(guī)范流程，也是對變更的一種確認和控制。或者可以為用例增加一個狀態(tài)，指明這個用例目前是否與程序沖突，當程序變更時改變用例的狀態(tài)，并更新用例版本。

3.3 用例審核，結對編寫

負責整個測試的管理人員對用測試例進行審核能夠對用例進行補充和校正，可現(xiàn)實的測試過程中往往比較難實現(xiàn)，而普遍采用的方式是結對編寫測試用例 （前提是你有兩個以上的測試人員），內(nèi)部審核。測試用例非自己編寫自己執(zhí)行，而是需要其他測試人員來進行測試并有著很好的可讀性。這樣一來所編寫的測試用例的可移植性和可維護性大大提高，同時能拓展了測試思維，加強了對測試重點的確認，進而使得小組內(nèi)部達到了統(tǒng)一。一定程度上結對編寫也可以減少測試負責人的工作壓力，提高組員的參與積極性。

4 展望

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

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

［1］景宏磊，林丁報.軟件性能測試的基本概念和一般過程[J].科技資訊，2011.

［2］林丁報，景宏磊.WEB 應用前端性能優(yōu)化淺析[J].科技資訊，2011.