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

 對于一個測試人員來說測試用例的設計編寫是一項必須掌握的能力。但有效的設計和熟練的編寫卻是一個十分復雜的技術，它需要你對整個軟件不管從業務還是從功能上都有一個明晰的把握。

一、問題：
    許多測試類書籍中都有大幅的篇章介紹用例的設計方法，如等價類劃分，邊界值，錯誤推斷，因果圖等。但實際應用中這些理論卻不能給我們很明確的行為指導，尤其是業務復雜，關聯模塊緊密，輸入標準和輸出結果間路徑眾多時，完全的遵循這些方法只能讓我們在心理上得到一種滿足，而無法有效的提高測試效率。有時我們只有依靠以前項目的用例編寫經驗（或習慣），希望能在這一個項目中更加規范，但多數情況下我們規范的只是“書寫的規范”，在用例設計上以前存在的問題現在依舊。
    當好不容易用例基本完成，我們卻發現面對隨之而來的眾多地區特性和新增需求，測試用例突然處于一種十分尷尬的境地：
 從此幾乎很少被執行
 已經與程序的實現發生了沖突（界面變動，功能變動）
 執行用例發現的bug很少
 根本沒有時間為新的功能需求增補用例
 有時間補充，但用例結構越來越亂，
 特性的用例與通性用例之間聯系不明確（以新增需求為主線列出所有涉及到的更改，但特性與通行之間的數據或業務聯系在用例中逐漸淡化）
 知道怎樣執行這個用例，但它要說明什么呢？（多數用例給我們的感覺是只見樹木，不見森林，只對某一功能，無法串起）

    通過上面的一系列問題可以看到，似乎測試用例給我們帶來的問題遠多于益處，也正是因為在實際過程中遇到的問題積累，導致我們有很充分的理由忽視或拒絕用例的應用。
但沒有用例或簡略用例的編寫我們又會舒服很多么？不言自明，誰也不想倒退發展吧。

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

1、沒有適合的規范
    “適合的規范”或稱“本地化的規范”。這是我們在測試過程中遇到的第一個問題，通常也是很容易習慣且淡忘的。我們擁有相當多的流程文檔、書本上的定義，但它適合我們當前的項目么？
每一個測試工程師在進入這個職業的初期都會了解一些測試上的概念和術語，進入公司或項目組后也會進一步學習相應的文檔，例如怎樣規范編寫，怎樣定義bug級別，軟件實現的主要業務等。但當測試經理開始給我們分配某一模塊的用例編寫時，又有多少人知道該怎樣去寫，怎樣寫算是好？
在測試論壇中常能看到介紹用例編寫方法的帖子，而迷茫于怎樣應用到實踐的回復也不為少數。為何我們無法在公司和項目組內找到明確且適合的規范？于是我們只得選擇從書本或之前的用例中復制，不管是結構還是方式都依賴于以往•的經驗，我并不是說這樣就是錯誤的，但不能總結成文的經驗無法給予測試更多幫助。
我們有太多經驗，但卻沒有形成適合的規范。

2、功能與業務的分離
    我們知道怎樣列舉一個輸入框的用例，但卻很少考慮說明這個輸入框是用來做什么的，如果仔細分析不難發現，用例中這種功能與業務的分離越來越普遍也越來越明顯。
邊界值、等價類劃分、因果圖，這些用例方法是一種高度提純的方法，本身就很偏向于功能及代碼，所以怎樣編寫業務的用例我們就從理論上失去了參考。
  

軟件測試技術: 軟件測試工程師 測試用例 功能測試　測試管理　缺陷管理　手機測試 自動測試　單元測試　性能測試　安全測試 軟件測試環境 Windows Unix 網絡知識　 服務器 開源測試: 開源功能測試 開源性能測試 開源缺陷管理 開源配置管理 開源解決方案 測試開發: JAVA .net UML 腳本語言 數據庫 中間件 測試資料 商業測試工具 開源測試工具 軟件測試教程 質量保證 項目管理 需求管理　軟件度量　 項目估算 質量模型 解決方案 測試工具 Mercury測試工具 Rational測試工具　Silk測試工具　其它

原文轉自：http://www.kjueaiud.com