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進行有效的軟件測試方面得出了很多的研究成果。
1.3 基于接口參數的測試用例自動生成算法
在軟件測試工作中，由于輸入、輸出空間，特別是輸入空間的無限性，使得無法對軟件進行全面的測試。因此，如何從大量的輸入數據中挑選適量的具有代表性、典型性的數據，特別是怎樣用較少的測試用例對軟件進行較全面的測試是測試人員面臨的一大難題。
測試用例的選擇無論是對黑箱測試還是對白箱測試都起著關鍵的作用，決定著軟件測試的質量和效果。所謂測試用例選擇就是指從所有的可用測試用例中選出少量典型的測試用例，以達到對測試域的最大限度覆蓋。多年來，許多研究者對之進行了廣泛而深入的研究，并取得了許多研究成果。常用的基于接接口參數的黑箱測試用例選擇方法是對系統每個接口參數采用邊際值分析法和等價類劃分法等選取一組典型的值，然后在這些取值組合中隨機選取一組測試用例，或者使用一些啟發式方法從中進行篩選。但這些方法的缺點是帶有主觀傾向性，不具有普遍性。
2 基于敏捷測試的相關技術討論
2.1 FIT框架及應用
在敏捷開發過程中，軟件測試是至關重要的，尤其是在最為流行的敏捷開發過程：極限編程（XP）中顯的更為突出。誠然，所有的過程都提到測試，但一般都不怎么強調。可是XP將測試作為開發的基礎，要求每個程序員寫一段源碼時都得寫相應的測試碼。這些測試片段不斷地積累并被整合到系統中。這樣的過程會產生一個高度可靠的建造平臺，為進一步開發提供了良好的基礎。
但是，即使是單元測試工具JUnit也存在一些缺點：比如JUnit里要進行數據填充，但是數據經常改變，使維護工作變成了可怕的噩夢，測試不同的組合，需要不同的數據，這也許會使測試工作變得日益復雜。而目前的集成測試又缺乏有效的方法論，不能自動化，測試的質量比較依賴測試人員的水平。
Framework for Integrated Test（簡稱FIT）就是一個用于增強交流和協作的工具。FIT創建了一個在客戶和程序員之間的反饋循環。FIT讓客戶和測試人員可以使用諸如Microsoft Office之類的工具來給出程序應當如何表現的例子——而無需成為直接編碼的程序員。FIT自動針對實際的程序檢測那些例子，這樣就在業務世界和軟件工程世界之間建立了一個簡單而且有效的橋梁。
FIT給予了客戶和程序員一個關于軟件的精確交流的方法。客戶所給的具體的例子讓程序員能深刻理解將要構建的產品。程序員的對于裝置的工作和軟件可以讓客戶給出不同的例子進行試驗來獲取對于軟件如何真正工作更深入的了解。這樣通過一起工作，整個團隊可以學會更多關于產品的內容并產生更好的結果。
2.2 測試用例自動生成技術
正交試驗設計起源于科學試驗，它由田口玄一博士在1949年創立，并于60年代初從日本傳人中國。它應用依據Galois理論導出的正交表，從大量試驗條件中挑選出適量的、有代表性的條件來合理地安排試驗。運用這種方法安排的試驗具有“均勻分散、整齊可比”的特點。“均勻分散”性使試驗點均衡地分布在試驗范圍內，讓每個試驗點有充分的代表性；“整齊可比”性使試驗結果的分析十分方便，可以估計各因素對指標的影響，找出影響事物變化的主要因素。
但正交試驗設計仍然存在著一些有待解決的弊端：比如正交表難以構造，因素、水平過多時測試用例數目還是過多等。所以一些專家又提出一種基于對接口參數進行組合覆蓋的黑箱測試用例自動生成算法模型，據此來得到一個對所有接口參數進行兩兩組合覆蓋的測試用例表。這種方法有著類似正交試驗設計的特點，實際上，在特定情況下，這種算法模型得出的測試用例表就是正交表。
3 技術實現的考慮
3.1 基于FIT框架對軟件進行集成測試
使用基于FIT框架的開源FIT工具來實現真正的測試先行開發過程，并讓客戶、需求提報工程師、開發人員、以及測試人員進行協同工作，達到需求更精準、減少需求更改、測試數據與JUnit單元測試代碼分離的目的，讓這一切更簡潔、更易于維護。
將根據以下步驟進行研究：
1) 使用FIT框架進行實際項目測試的實踐，從中提煉出一套使用FIT框架進行集成測試的通用方法。
2) 通過實踐，對FIT框架進行合理的改進和拓展，結合JUnit單元測試，現實單元測試和集成測試的無縫連接，達到提高軟件質量的效果。
3) 在理論研究和實踐的基礎上，規約出適用于單元測試和集成測試的通用方法。
3.2 整合測試用例的自動生成技術至FIT
按照敏捷過程中“簡單”原則，本課題將編寫一個輔助接口測試的工具，用來自動產生少而有效的測試用例，以達到對測試域的最大限度覆蓋。通過該工具產生的測試用例表，能符合FIT框架的要求，并可被FIT所執行而得到HTML形式的可視化的測試結果。通過這種方式，大大增加了測試的自動化。
為了實現該目標，將按照以下步驟進行研究：
1) 查看“正交試驗設計方法”的原理及其資料，了解測試用例生成的規則。
2) 查閱兩兩覆蓋測試用例生成的相關算法，并根據算法用程序實現，進行實踐研究。
3) 根據實踐研究，對兩兩覆蓋測試用例進行改進，以期能更高效的實現測試用例的生成。
4) 修改依據改進后的算法實現的測試工具，使其輸入輸出符合FIT框架的要求。在此基礎上，把此工具集成到FIT框架中。
4 小結
本文討論了當前軟件測試中的兩大重要研究領域：敏捷測試方法和測試用例的選擇與生成技術。進一步的工作是，根據“敏捷”的集成測試框架FIT需要人工構造表格形式的數據作為輸入的前提，深入研究如何自動生成FIT需要的表格數據？再對FIT進行擴展，為FIT嵌入測試用例表格自動生成功能。其中測試用例集的生成將依據各參數兩兩覆蓋的原則，以求達到對測試域的最大限度覆蓋