一、問題
許多測試類書籍中都有大幅的篇章介紹用例的設計方法，如等價類劃分，邊界值，錯誤推斷，因果圖等。但實際應用中這些理論卻不能給我們很明確的行為指導，尤其是業務複雜，關聯模組緊密，輸入標準和輸出結果間路徑眾多時，完全的遵循這些方法只能讓我們在心理上得到一種滿足，而無法有效的提高測試效率。有時我們只有依靠以前專案的用例編寫經驗(或習慣)，希望能在這乙個專案中更加規範，但多數情況下我們規範的只是「書寫的規範」，在用例設計上以前存在的問題現在依舊。
當好不容易用例基本完成，我們卻發現面對隨之而來的眾多地區特性和新增需求，測試用例突然處於一種十分尷尬的境地：
☉ 從此幾乎很少被執行
☉ 執行用例發現的bug很少
☉ 根本沒有時間為新的功能需求增補用例
☉ 有時間補充，但用例結構越來越亂
☉ 特性的用例與通性用例之間聯絡不明確(以新增需求為主線列出所有涉及到的更改，但特性與通行之間的資料或業務聯絡在用例中逐漸淡化)
☉ 知道怎樣執行這個用例，但它要說明什麼呢?(多數用例給我們的感覺是只見樹木，不見森林，只對某一功能，無法串起)
通過上面的一系列問題可以看到，似乎測試用例給我們帶來的問題遠多於益 處，也正是因為在實際過程中遇到的問題積累，導致我們有很充分的理由忽視或拒絕用例的應用。
但沒有用例或簡略用例的編寫我們又會舒服很多麼?不言自明，誰也不想倒退發展吧。
二、原因
事實上我們在測試用例編寫和設計上遇到的一系列問題只是一種表面的呈現，究其原因我認為有如下幾點：
1、沒有適合的規範
「適合的規範」或稱「本地化的規範」。這是我們在測試過程中遇到的第乙個問題，通常也是很容易習慣且淡忘的。我們擁有相當多的流程文件、書本上的定義，但它適合我們當前的專案麼?
每乙個測試工程師在進入這個職業的初期都會了解一些測試上的概念和術語，進入公司或專案組後也會進一步學習相應的文件，例如怎樣規範編寫，怎樣定義bug級別，軟體實現的主要業務等。但當測試經理開始給我們分配某一模組的用例編寫時，又有多少人知道該怎樣去寫，怎樣寫算是好?
在測試論壇中常能看到介紹用例編寫方法的帖子，而迷茫於怎樣應用到實踐的回覆也不為少數。為何我們無法在公司和專案組內找到明確且適合的規範?於是我們只得選擇從書本或之前的用例中複製，不管是結構還是方式都依賴於以往"的經驗，我並不是說這樣就是錯誤的，但不能總結成文的經驗無法給予測試更多幫助。
我們有太多經驗，但卻沒有形成適合的規範。
2、功能與業務的分離
我們知道怎樣列舉乙個輸入框的用例，但卻很少考慮說明這個輸入框是用來做什麼的，如果仔細分析不難發現，用例中這種功能與業務的分離越來越普遍也越來越明顯。
邊界值、等價類劃分、因果圖，這些用例方法是一種高度提純的方法，本身就很偏向於功能及**，所以怎樣編寫業務的用例我們就從理論上失去了參考。
複雜的業務會貫穿於整個軟體，涉及眾多功能點，裡面組合的分支更不可勝數。測試用例務求簡潔、明確，這一點也與業務「格格不入」。功能用例依賴程式介面，業務描述依賴需求文件。於是我們更偏向於根據已實現的介面編寫功能用例，列舉出眾多的邊界值、等價類。流程的操作只有憑藉經驗和理解，這時測試出的bug是最多的，但我們卻無法使這個bug對應到乙個用例中(點選乙個按鈕報出的錯誤有時原因並不在這個按鈕或按鈕所在的窗體)。正因為我們沒有很好的積累業務上的用例，才使得我們感到執行用例時發現的bug不多。
用例結構的劃分一定程度上也造成了功能和業務的分離，依照介面模組建立資料夾，並在其中新建不同用例，這使得用例從結構上就很難聯通起來。
3、測試未能跟上變化
想象一下，當我們越來越多的聽到開發人員在那裡高呼「擁抱變化」「敏捷開發」的時候，測試又有什麼舉措呢?當地區特性，軟體版本越來越多的時候，測試是否在積極響應呢?變化是我們面臨的最大挑戰，我認為測試未能跟上變化是造成測試過程中遇到種種問題和矛盾的主要原因。
對需求和程式的變化測試人員的感受是非常深的，測試總是跟在需求和開發後面跑，使得所有風險都壓在自己身上。不斷壓縮的時間和資源使我們只能放棄那些「不必要」的工作：盡快投入測試，盡快發現bug，而非從整體把握軟體的質量情況，統籌策略。
疲於應對的直接影響就是程式質量無法準確度量，進度無法控制，風險無法預估。用例與程式脫節，新增用例混亂和缺少。長此以往我們只得放棄修改、增補用例，甚至放棄之前積累的所有成果。用例變為程式變更的記錄摘要，沒有測試資料的保留，測試步驟和重點無法體現，新加功能與原來的程式逐漸「脫離」，可能還會出現相互違背的情況，但這我們卻無法很快發現。
三、可能解決的辦法
在這裡我希望以**的方式提出一些可能的解決辦法，因為上面的問題也許在成熟的公司和專案組內很少遇到，而遇到問題的也需根據不同的情況單獨考慮。不用拘泥形式，最適合的就是最好的。
1、測試驅動開發，用例指導結果，資料記錄變化
「測試驅動開發」(tdd)是乙個比較新的概念，在網上可以看到很多介紹文章，它主要討論如何讓開發的**更奏效(work)更潔淨(clean)，「測試驅動開發的基本思想就是在開發功能**之前，先編寫測試**」。可以看到，tdd是建立在「**」級別的驅動，但目前我們需要**的問題是怎樣在黑盒測試中做到「測試驅動開發」。
首先我們需要糾正乙個態度，很多人認為黑盒測試的技術含量不高，可思考可拓展的內容不多，主要的工作就是用滑鼠在那裡瞎點，於是很多「高階」的技術方法都試圖與黑盒測試劃清界限。但測試人員發現的bug有80%以上都是黑盒測試發現的，手工操作軟體仍是目前檢驗軟體質量最有效的一種方法。
如何在黑盒測試中做到測試驅動開發?我認為可以從用例級別做起，以業務用例指導過程和結果。
開發人員通常比較關注技術，對於業務上的理解容易忽視並出現偏差，而需求文件又不會很明確的指出應該實現怎樣的結果，這使得從業務到功能出現乙個「閱讀上的障礙」，如果最後程式錯誤了還需返工，這樣耗費的人力物力就非常大了。使用業務用例驅動開發，就是乙個比較好的方法，同樣這也需要運用測試中的各種方法，列舉出業務流程裡資料的等價類和邊界值。
業務用例的構造要先於程式實現，與需求和開發人員溝通一致，並以此作為乙個基準，保證程式實現不會錯，還能對整個軟體的進度和質量有乙個很好的估計和度量。業務用例可以不關注程式的介面，但一定要有資料的支援。
這就是測試主導變化的另一點「資料記錄變化」。
我們不僅要應對變化，還要記錄變化，使測試用例成為對程式持續性的監控，資料可以作為最基本、最簡單的支援。當乙個業務很複雜時可以拆分成段(業務段與程式中以窗體或頁面的劃分是不一樣的)，使用典型的用例方法列出實際輸入和預期結果。我們希望資料能做到通用和共享，最理想的情況就是建立乙個「資料庫」，每個業務用例都從「資料庫」中取得輸入資料和預期結果，這個資料只是針對業務入口和出口的，當程式內部設計變更時，保留的資料不會因此而作廢。舉乙個例子，例如我的程式要從某種檔案中讀取資料並計算結果，一段時間後程式內部字段增加了，如果是以儲存的檔案附件方式提供資料，則現在程式很可能就打不開這個檔案了。使用「資料庫」指導測試人員可以在變化的程式裡直接針對業務輸入，而不關心程式內部結構。
再進一步的話「資料庫」就開始涉及到程式內部的介面了，這需要開發人員的配合。
為測試用例標明時間或版本可以起到一種基準的作用，標明專案進度過程中的每乙個階段，使用例直接和需求基線、軟體版本對應。同樣這需要規範流程，也是對變更的一種確認和控制。或者可以為用例增加乙個狀態，指明這個用例目前是否與程式衝突，當程式變更時改變用例的狀態，並更新用例版本。
為測試用例標明優先順序可以指出軟體的測試重點、用例編寫的重點，減少用例回歸的時間，增加重點用例執行的次數，幫助專案組新人盡快了解需求，在自動化測試的初期也可以參考這個優先順序錄製指令碼。
2、功能用例與業務用例分開組織
將功能用例與業務用例分開組織，按照不同關注點列舉執行路徑。業務用例應在開發前或同期編寫，幫助測試人員和開發人員明確業務，了解正確流程和錯誤流程。功能用例更依賴於程式介面的描述，但功能用例並不等於使用說明。對某些模組的等價類、邊界值測試會發現很多嚴重的bug，也許與業務無關，但使用者往往很容易這樣操作(例如登入名，你是否考慮到很長的名字，或者使用者的鍵盤有問題，總是敲入n多空格在裡面，這與業務無關，但程式將會怎樣處理?)。
3、審核用例，結對編寫
測試組長或經理對用例進行審核可以做到用例的補充和校對，但一般情況下是很難做到的，我們可以採用另一種方法，就是結對編寫測試用例(前提是你有兩個以上的測試人員)，內部審核。
測試用例不是乙個人編寫乙個人執行，它需要其他測試人員都能讀懂且明白目標所指。結對編寫可以儘量減少個人的「偏好習慣」，同時也能拓展思維，加強測試重點的確認，小組內部達到統一。一定程度上結對編寫也可以減少組長或經理對用例的管理，提高組員的參與積極性。
四、發展
上面的這些解決方法只是一種建議，具體怎樣實施到專案中還需根據情況而定。可以看到測試的發展方向是很多很廣的，傳統的黑盒測試並不是毫無新意，測試工作怎樣適合我們而發展，將給予我們更多的思考。
USACO各種思想好題歸納
section 1.1 prob broken necklace 這裡也是巧解 id liwei101 prog beads lang c include include include include include include include include include include ...
什麼是物件導向思想？好處是什麼？
什麼是物件導向思想？優化好處？設計模式和物件導向思想的關係？不用設計模式或者不可以使用物件導向思想會有什麼問題？問題或或者場景？生活中 如曹操 寫的詩句 喝酒唱歌，人生真爽 到 對酒當歌，人生真爽 再到 對酒當歌，人生幾何 臣子命令工匠連夜印刷，作為小小印刷工匠的你是不是想罵娘 怎麼老是改呢，還讓不...
測試總體思想
1.對於需求有更改的這種情況來說 測試計畫的編制是為了框定測試範圍。第一步要整理好需求中提到的點 第二步要把需求修改的關聯到的點圈定出來。在測試用例的設計中優先順序應該是這樣的 i.業務流程的測試 畫出業務流程圖。在這個過程中如果能附帶些功能點就帶上 ii.功能用例 iii.公共用例 2.對於完全新...