基于敏捷測試的技術研究[1]

　　基于敏捷測試的技術研究[1]   軟件測試

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

　　1 研究背景

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

　　1.1 敏捷技術方法與分析

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

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

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

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

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

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

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

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

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

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

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

　　敏捷聯盟還以這4個價值觀為原則，提出了敏捷過程的12條指導原則，以期能更好的指導人們了解敏捷過程。

　　敏捷開發過程，指的就是一種與傳統的瀑布模型開發和CMM(Capability Maturity Model，軟件開發的能力成熟度模型)所追求的嚴謹的文檔制度截然相反的開發過程。這一開發過程注重開發團隊和成員之間的關系而不是以開發的進程和使用的工具為重點，注重所開發的軟件產品而不是追求廣泛的文檔編制，注重開發過程中與客戶的協同工作而不是以簽訂合同的談判為工作的核心，注重在開發過程中隨時調整計劃而不是同意完全遵循某一開發計劃，以實現所謂開發過程的“敏捷”。

　　1.2 敏捷測試及其研究現狀

　　敏捷方法的發展，打破了傳統的瀑布開發模型，改變了整個軟件開發過程中的角色和定位。由于在敏捷開發運動的初期，主要依靠開發人員來進行推動。很多測試人員不了解敏捷方法，仍然習慣了按照傳統的瀑布模式進行軟件測試，即按照V模型所指導的步驟進行測試，保證軟件與需求、設計的相符合，但這樣很容易形成了一種測試思維的定勢。當“用戶需求不明確”、“需求變化較快”時，沿用傳統測試方法的測試人員將變的無所適從。

　　目前比較流行的敏捷測試方法有測試驅動開發和相關環境驅動測試等。還有很多國外知名專家按照“敏捷”的原理為軟件測試開發了相應的測試框架，其中最著名的就是Kent Beck等提出的xUnit系列單元測試框架和Ward Cunningham等提出的Framework for Integrated Test(FIT)集成測試框架。xUnit系列提出的比較早，目前已有一套完善的測試工具和方法論來支持了，適用于各種語言的單元測試。FIT框架是當前國內外的研究重點，很多知名的測試專家如Lisa Crispin等都在如何使用FIT進行有效的軟件測試方面得出了很多的研究成果。

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