從測驗用例的問題淺談軟體測驗

一.對于一個測驗人來說，設計和撰寫測驗用例是必須的，但是有效的設計和熟練的撰寫是一項非常復雜的技術，需要你從業務和功能上對整個軟體有一個清晰的把握，如何系統化、結構化地標準化用例，將直接影響后續測驗，同時，測驗用例也將用于控制軟體的整體執行覆寫，并對最終的測驗結果給出一個量化的評估標準，

測驗相關的很多書都有大段章節介紹用例的設計方法，比如等價類劃分、邊界值、錯誤推斷、因果圖、決策表等等，但是這些理論在實際應用中并不能給我們很精準的行為指導，尤其是當業務復雜、相關模塊緊密、輸入標準和輸出結果之間存在多條路徑時，完全遵循這些方法的唯一左右是讓我們內心得到滿足，并不能真正提高測驗水平，也沒有足夠的時間和資源去撰寫完整的用例，通常我們只能依靠以前專案中使用案例寫作的經驗(或者習慣)，希望在這個專案中更加規范，然而，在大多數情況下，我們標準化的是“書面上的標準”，這樣只會導致一個結果，那就是以前使用案例設計的問題仍然存在，

當用例基本完成后，我們發現測驗用例在面對許多地域特性和新需求時，突然處于非常尷尬的境地：

此后幾乎沒有再被執行過
已與程式的實作相沖突(界面變更、功能變更)
執行時發現的bug少得可憐
沒有時間為新的功能需求增添用例
就算有時間補充，但是用例結構愈發混亂

特性用例和一般用例之間的聯系不明確(所有涉及的變更都以新需求為主線列出，但特性和流量之間的資料或業務聯系在用例中逐漸淡化

知道怎樣執行這個用例，但卻無法明確它要說明什么？

通過上述的一系列問題我們會發現，似乎測驗用例給我們帶來的問題已經遠遠超出好處了，很多時候我們忽略和拒絕用例的應用，也是因為在實操程序中總會遇到各式各樣的問題導致的，

但沒有用例的撰寫我們也不見得能好到哪去，

二、原因:

事實上，我們在測驗用例的撰寫和設計中遇到的種種問題僅僅是表面的，我認為原因如下:

1.沒有合適的規范通常這是我們在測驗的程序中遇到的第一個問題，是很容易被習慣和忘記的，我們在書本中有相當多的流程檔案、指導步驟和定義，但是它適合我們當下的專案嗎？

每一個測驗工程師在進入這個職業的初期都會知道測驗中的一些概念和術語，進入公司或者專案組后會進一步學習相應的檔案，比如如何規范撰寫，如何定義bug級別，軟體實作的主要業務，但是，當經理開始給我們分配某個模塊的用例撰寫時，有多少人清楚怎么寫才好呢？

在測驗論壇中，經常可以看到介紹用例撰寫方法的帖子，有不少回復對如何應用到實踐中感到困惑，為什么在公司和專案團隊內部找不到清晰合適的規范？因此，我們不得不選擇從書籍或以前的用例中復制，結構和方式都取決于過去的經驗，我不是說這是錯的，但我們不能總結書面經驗，給予測驗更多幫助，我們有太多的經驗，卻沒有形成一個合適的標準，

2.功能和業務的分離

我們知道如何列出輸入框的用例，但是我們很少考慮解釋輸入框的用途，如果我們仔細分析，不難發現用例中這種功能和業務的分離愈發明顯了，

邊界值、等價類劃分、因果圖，這些用例方法都是高度提純的方法，非常偏向于功能和代碼，所以對于如何撰寫業務用例，我們已經失去了理論參考，

復雜的業務會貫穿整個軟體，涉及很多功能點，其中組合的分支不計其數，測驗用例應該簡潔明了，這也與業務“不兼容”，功能用例依賴于程式介面，業務描述依賴于需求檔案，因此，我們更喜歡根據實作的界面撰寫功能用例，并列出大量的邊界值和等價類，這個流程的操作僅僅依靠經驗和理解，這個時候，測驗的bug最多，但是我們不能讓這個bug對應一個用例(有時候點擊一個按鈕報告的錯誤并不是因為按鈕或者按鈕所在的表單)，所以我們只能添加note向開發者指出錯誤的可能來源，正是因為我們沒有很好地積累業務用例，所以我們覺得在執行用例的時候沒有發現太多的bug，

功能和業務的分離一定程度上跟用例結構的劃分也有關，依照界面模塊建立檔案夾，并在其中新建不同用例，這導致二者從結構上就很難聯通起來，

3.測驗未能跟上變化

試想一下，當我們聽到越來越多的開發人員在那里高喊“擁抱變化”、“敏捷開發”時，測驗人員可以采取哪些措施？當地區特性和軟體版本變得越發的多的時候，測驗是否積極跟進？變化是我們面臨的最大挑戰，我認為測驗跟不上變化是測驗程序中遇到各種問題和矛盾的主要原因，

人們對需求和流程的變化感受是很深的，而測驗總是跟在需求和開發后面跑，所以所有的風險都在自己身上，時間和資源的不斷縮減，讓我們放棄了“不必要”的作業，一心想著盡早投入測驗盡早發現bug，而不是從整體上把握軟體質量，協調策略，

應接不暇的直接影響是軟體質量無法準確衡量，進度無法控制，風險無法預測，用例與程式是分離的，新的用例是混亂和缺乏的，從長遠來看，我們不得不放棄修改和補充用例，甚至放棄之前積累的所有成果，用例成為程式變更的記錄匯總，沒有測驗/的資料留存，就無法體現測驗/的步驟和要點，新增加的功能與原程式逐漸“分離”，可能存在相互違背的情況，但我們卻沒有辦法及時發現，

變化總在決定我們的下一步，這也是混亂的開始，

三、可能解決的方法

上述問題在成熟的公司和專案團隊中可能很少遇到，遇到問題的要根據不同情況分別考慮，分析錯誤不會給我們帶來成功，成功的特征也不會一樣，因此，在這里希望以討論的方式提出一些可能的解決方案，不拘泥于形式，而由結果來決定，最適合的就是最好的，

1.測驗推動開發，指導用例結果，記錄資料變化

“測驗驅動開發”（TDD）在網上可以看到很多介紹文章，主要討論如何讓開發出來的代碼更加潔凈且高效，“測驗驅動開發”的基本思路是先寫測驗代碼，再寫開發功能代碼”，可見，TDD是一個基于“代碼”層面的驅動，但目前需要在黑盒測驗中討論如何實作“測驗驅動開發”，

首先，我們需要端正一個態度，很多人認為Black Box 測驗的技術含量不高，沒有太多可以思考和拓展的地方，主要作業就是用滑鼠在那里瞎摸，所以很多“高級”的技術方法都試圖用黑盒測驗，劃清界限，但是測驗人員發現的bug80％以上是通過黑盒測驗發現的，手工操作軟體仍然是目前檢查軟體質量最有效的方法，

如何在黑盒測驗中開發測驗驅動程式？我覺得可以從用例層面入手，用業務用例來指導結果，

開發人員通常更注重技術，對業務的理解容易被忽視和偏離，而需求檔案并沒有完全指明應該達到什么結果，這就使得從業務到功能出現了“閱讀障礙”，如果發現程式錯誤，需要返工，這將耗費大量的人力物力，測驗人員和最終用戶無需過多關注軟體實作的細節，因此用業務用例驅動開發是更好的方法，給出明確的預期結果，并指導開發人員如何定義是否達到目標，這也需要使用測驗中的各種方法來列出業務流程中資料的等價類和邊界值，

業務用例的構建應該先于程式實作，與需求和開發人員保持一致的溝通，并以此為基準，確保程式實作不會出錯，同時也對整個軟體的進度和質量有一個很好的估計和度量，業務用例可能不關注程式的介面，但是必須有資料支持，這是測驗領先變化的又一次“資料記錄變化”，

我們不僅要處理變更，還要記錄變更，這樣就可以用測驗用例來監控程式的連續性，資料可以作為最基本、最簡單的支撐，當業務非常復雜時，可以進行細分(業務細分不同于程式中用表單或頁面劃分的業務細分)，通過典型用例方法列出實際輸入和預期結果，我們希望資料能夠通用和共享，最理想的情況是建立一個“資料庫”，每個業務用例從“資料庫”中獲得輸入資料和預期結果，該資料僅用于業務入口和出口，當程式內部設計發生變化時，保留的資料不會失效，例如，我的程式需要從某個檔案中讀取資料并計算結果，一段時間后，程式的內部欄位增加，如果資料是作為保存的檔案附件提供的，程式現在可能無法打開該檔案，使用“資料庫”來引導測驗人可以直接針對變更后的程式中的業務輸入，而不考慮程式的內部結構，

2.標記用例的時間(版本)和優先級

標記測驗用例的時間或版本可以作為基準，標記專案進度的每個階段，用例直接對應需求基線和軟體版本，同樣，它需要標準化流程，也是對變更的確認和控制，或者可以給用例添加一個狀態，指明用例目前是否與程式沖突，當程式改變時改變用例的狀態，更新用例的版本，

為測驗用例標記優先級可以指出測驗軟體和用例編譯的關鍵點，減少用例回歸的時間，增加關鍵用例的執行次數，幫助專案組的新人盡快了解需求，在自動化測驗的初始階段，也可以參考該優先級記錄腳本，

3.功能用例和業務用例是分開組織的為業務用例開辟單獨的分類，分別組織功能用例和業務用例，根據不同的關注點列出執行路徑，應該在開發之前或同時準備業務用例，以幫助測驗人員和開發人員識別業務并理解正確和錯誤的流程，功能用例更依賴于程式介面的描述，但功能用例不等于指令，在一些模塊的等價類和邊界值測驗中會發現很多嚴重的bug，可能和業務無關，但是用戶往往很容易這樣操作(比如登錄名，你考慮長名字嗎，或者如果用戶的鍵盤有問題，你總是在里面鍵入n個以上的空格，這和業務無關，但是程式會怎么處理呢？)，

四、發展

以上解決方案只是討論和思考，如何在專案中實施還要看情況，與此同時，即使我們在積極尋求改變，我們仍然會遇到無數新的問題和新的苦惱，也許比以前更多，這是我們必須付出的，

可見測驗的發展方向非常廣泛，即使傳統黑箱測驗并不是什么新鮮事，但高級測量員必須在測驗技能和專業領域都有高度的“修養”，我們該如何去發展自己的測驗事業也應有更多的思考，

下面是我整理出來的一份軟體測驗工程師學習與發展知識架構體系圖，

希望大家能在這個成長程序中收益良多，可以說，這個程序會讓你痛不欲生，但只要你熬過去了，以后的生活就輕松很多，正所謂萬事開頭難，只要邁出了第一步，你就已經成功了一半，古人說的好“不積跬步，無以至千里，”等到完成之后再回顧這一段路程的時候，你肯定會感慨良多，

最后感謝每一個認真閱讀我文章的人這些資料，對于做【軟體測驗】的朋友來說應該是最全面最完整的包括了很多測驗行業常見知識，其中包括了有基礎知識、Linux必備、Shell、互聯網程式原理、Mysql資料庫、抓包工具專題、介面測驗工具、測驗進階-Python編程、Web自動化測驗、APP自動化測驗、介面自動化測驗、測驗高級持續集成、測驗架構開發測驗框架、性能測驗、安全測驗，面試時面試官必問的知識點，精選簡歷等，關注我的微信公眾號；程式媛木子；自行獲取~