三、可能的解決辦法：

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

　　1、測試驅(qū)動開發(fā)，用例指導結(jié)果，數(shù)據(jù)記錄變化

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

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

　　如何在黑盒測試中做到測試驅(qū)動開發(fā)?我認為可以從用例級別做起，以業(yè)務用例指導實現(xiàn)的結(jié)果。

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

　　業(yè)務用例的構(gòu)造要先于程序?qū)崿F(xiàn)，與需求和開發(fā)人員溝通一致，并以此作為一個基準，保證程序?qū)崿F(xiàn)不會出錯，還能對整個軟件的進度和質(zhì)量有一個很好的估計和度量。業(yè)務用例可以不關(guān)注程序的界面，但一定要有數(shù)據(jù)的支持。這就是測試主導變化的另一點“數(shù)據(jù)記錄變化”。

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

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

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

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

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

　　3、功能用例與業(yè)務用例分開組織

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

　　4、審核用例，結(jié)對編寫

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

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

　　四、發(fā)展

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

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

　　2010年下半年軟考成績查詢時間及方式匯總

　　2011年上半年計算機軟考時間及科目安排

　　2011年軟件水平考試軟件測評師基礎(chǔ)知識輔導匯總

　　2011軟考軟件測評師測試技術(shù)輔導匯總