基于敏捷測試的技術研究

　隨著敏捷開發過程流行，敏捷測試方法也開始受到更多的關注。同時，軟件測試用例的選擇和生成也是軟件測試中的一個重要研究領域，測試用例的質量將直接決定軟件測試的科學性和有效性。本文基于集成測試框架FIT(Framework for Integrated Test)，并結合兩兩組合覆蓋的測試用例自動生成技術，實現從接口參數邊界值的確定，到以HMTL形式顯示集成測試結果過程的半自動化過程。

　　1 研究背景

　　隨著敏捷開發的流行，傳統的軟件測試也在發生著翻天覆地的變化。傳統的軟件測試已不能適應當前的開發方式，急需新的理論和方法論來尋求改變，并以此來推進軟件工程的進步。本文將關注與敏捷測試相關理論與技術。

　　1.1 敏捷技術方法與分析

　　我們現在面對著飛速變化的業務和技術環境。在這樣一個環境中，傳統的軟件開發方法所認為需求需要在項目初期分析清楚并且保持穩定的想法是行不通的。不能快速持續的將需求變化融合到軟件中就意味著對業務環境反映遲鈍，最終導致業務上的失敗。同樣，新技術不斷地涌現，也要求軟件產品的代碼時刻處于一種良好的狀態，能夠適應各種調整。于是，敏捷開發過程應運而生。

　　2001年以Kent Beck，Martin Fowler，Robert C.Martin及Ward Cunningham等為首的一些軟件工程的專家成立了“敏捷聯盟”(Agile Alliance)，并提出了著名的敏捷宣言，即敏捷過程的價值觀：

　　 人和交互重于過程和工具。

　　 可以工作的軟件重于求全責備的文檔。

　　 客戶合作重于合同談判。

　　 隨時應對變化重于循規蹈矩。

　　這些價值觀是專家們在求同存異的基礎上對敏捷技術的最基本的總結，也是他們在敏捷技術方面達成的最大共識，其反映的是兩個更深層的特點：

　　1) 敏捷型方法是“適應性”而非“預見性”

　　工程方法試圖對一個軟件開發項目在很長的時間跨度內做出詳細的計劃， 然后依計劃進行開發。這類方法在一般情況下工作良好，但(需求、環境等) 有變化時就不太靈了。因此它們本質上是拒絕變化的。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。

　　2) 敏捷型方法是“面向人”的，而非“面向過程”的

　　工程型方法的目標是定義一個過程，不管是誰用都工作。而敏捷型方法 則認為沒有任何過程能代替開發組的技能，過程起的作用是對開發組的 工作提供支持。

　

原文轉自：http://www.anti-gravitydesign.com