基于J2EE+Flex技術的軟件測試管理系統分析與設計

肖新鳳

（廣東環(huán)境保護工程職業(yè)學院，廣東佛山，528216）

0 前言

軟件測試就是利用測試工具按照測試方案和流程對產品進行功能和性能測試，甚至根據需要編寫不同的測試工具，設計和維護測試系統，對測試方案可能出現的問題進行分析和評估。執(zhí)行測試用例后，需要跟蹤故障，以確保開發(fā)的產品適合需求。隨著軟件測試的重要性日益漸顯，如何更好的管理開發(fā)與測試之間的溝通，以及及時監(jiān)控產品的質量報告，讓這個管理過程軟件信息化。這就需要一些軟件測試的管理系統來維護，因此與基于J2EE+Flex技術的軟件測試管理系統的開發(fā)目的和需求相迎合。

1 需求分析

FTest軟件測試管理系統設計目的旨在建立一個以J2EE+Flex+MySQL為基礎，功能簡單實用、結構靈活而且簡潔輕量、精致的軟件測試管理系統。主要應用目標是小型的開發(fā)團隊在軟件開發(fā)的過程中對軟件的測試，在開發(fā)與測試人員之間的交流進行管理，能夠滿足不同的用戶角色（如團隊領導、開發(fā)和測試人員）的工作需要，提供了足夠靈活的接口去實現上述需求的關鍵，各個環(huán)節(jié)通過網絡實現了對共享數據的及時訪問，避免了由于數據分散而導致的數據不一致現象的發(fā)生。本系統包括：主要包括配置管理、缺陷管理和測試流程制定與管理及項目管理功能等等。插件式開發(fā)功能：事件和消息處理機制。部分功能用例分析如下。

1.1 配置管理

管理員在配置管理模塊對相關的內容，進行瀏覽配置信息、添加配置信息、刪除配置信息、編輯配置信息、查詢配置信息等操作。提取編輯配置信息時不一定要修改所屬項目的分類。配置管理用例圖如1所示。

圖1 配置管理用例圖

1.2 Bug管理

管理員對Bug管理相應的內容，進行瀏覽Bug信息、添加新的Bug信息、編輯Bug信息、刪除Bug信息和查詢Bug信息的操作。其中添加新的Bug信息時可以選擇直接分配任務對改Bug進行處理，提取編輯Bug信息用例時不一定會修改所屬項目、優(yōu)先級、類型和狀態(tài)如圖2所示。

圖2 Bug管理的用例圖

1.3 Bug處理

管理員對Bug處理相應的內容，進行瀏覽Bug處理信息、編輯Bug處理信息和查詢Bug處理信息；其中提取編輯Bug處理信息時不一定會修改流程狀態(tài)或狀態(tài)如圖3所示。

圖3 Bug處理的用例圖

2 系統設計

2.1 插件式設計

基于插件式設計比起許多設計模式更簡單，更容易理解。各種基于插件設計的架構都有自己的特色，但從總體架構上看，其模型都大同小異。

圖4 插件式設計模式

基于插件設計的應用程序由應用程序框架、插件接口、插件和公共項目類庫四部分組成。

應用程序框架負責應用程序的整體運作，它清楚程序整個流程，但并不知道每個過程具體要做什么。它在適當的時候調用一些插件，來完成真正的功能。插件接口是一個協議。插件按照這個協議實現出來，就可以加入到應用程序中來。當然，對于復雜的系統，插件接口可能有多個，各自具有獨立的功能。插件是完成實際功能的實體，實現了要求的插件接口。盡管實現什么以及怎么實現，完全是插件自己的自由。在實際情況來，一般還是有些限制，因為插件接口本身可能就是一個限制。如，實現編譯功能的插件，自然不能實現成一個聊天功能的插件。公共項目類庫是一組函數或者類，應用程序框架和插件都可以調用。它通常是一個獨立的庫。應用程序框架本身是公用的，是代碼復用的一種方式。但并不是所有可復用代碼都可以放在框架中，特別是插件會用到的公共代碼，那會造成插件對框架的依賴。把這些公共代碼提取到一個獨立的庫中，是一種好的方法。

2.2 開發(fā)設計模型的改進

2.2.1 系統整體模式架構

為更好地體現出系統的靈活性和可擴展性，本系統采用了MVC三層模式開發(fā)和插件設計的混合開發(fā)模式，實現表現層和業(yè)務層的分離。客戶端由Flex的事件處理（Event）和Fabrication的消息(Notification)處理的機制實現View層的功能，服務端使用Hibernate充當Model層，Spring實現Controller層的功能，對服務端的Model層的數據進行操作，并發(fā)布Services接口，供Flex的客戶端調用。如圖5所示。

圖5 系統整體模式架構

Flex客戶端與Java服務端之間的通信是基于BlazeDS使用RemoteObject方式進行數據交互。然而在系統的Flex客戶端也是一個MVC結構的開發(fā)模式，Flex客戶端使用Fabrication框架又進行了MVC三層劃分。跟Java服務端進行交互的調用接口放在了Model層的proxy完成，使用消息（Notification）的機制在Controller層由command調用proxy的具體方法，具體的視圖的展現由View層的mediator完成。

基于Fabrication框架下設計的Flex客戶端，把子功能都當一個獨立的小項目來開發(fā)設計，在Flex中我們稱作Module。主程序整體達到了松耦合的設計，我們把公共的函數或者類抽取在公共項目中進行提供給子模塊項目進行引用。每個模塊都有它自己的獨立性，而跨模塊之間的互通信，在此設計模式下設計的程序也能完全實現?？缒K的通信，可以通過Fabrication提供的RouteNotification發(fā)送相應的消息命令，執(zhí)行我們的相關任務。

圖6 Flex客戶端主程序運行流程圖

Java服務端通過BlazeDS這個中間件，能實現我們Flex與Java端的數據進行互通。通過BlazeDS，我們把Java服務端需要提供給外界調用的接口進行暴露，而且能具體到接口里面的每一個方法是否允許被訪問的控制。

2.2.2 插件式開發(fā)架構

初始化模型，主程序系統提供通用插件接口系統函數庫或類庫裝載完畢，準備初始化插件，通常在插件被加載時調用。至于插件(子模塊)要完成什么功能，要插到哪里，在執(zhí)行LaunchCommand后決定，它調用公共項目模塊里的方法把自己注冊到主程序中某個位置。而專用插件接口，這些插件接口是專用的，看到它的接口函數說明。

2.3 核心模塊設計

圖7 基于Fabrication框架的Flex模塊內運作流程圖

整個軟件測試管理系統的分析設計、系統基本架構和模塊結構。分析了MVC三層模式，分析插件式設計的開發(fā)模型，結合插件式開發(fā)模型，提出一種擴展辦法，簡化應用框架的復雜度，讓框架更容易實現，并提高擴展的靈活性，系統的子模塊實現了WEB模式和AIR桌面富客戶端的自由集成。盡管提出一種結合插件式設計的開發(fā)模型，為系統提出一種擴展辦法，但一種開發(fā)模型并不能解決所有的問題，而且還需要付出相應的代價和努力，還有許多仍待解決的缺陷和不足。

事實上，MVC三層模式和插件式開發(fā)模型都有一個共通點，就是文件和庫管理繁瑣，隨著開發(fā)過程的深入，插件式開發(fā)模式下會產生許多子項目，而基于插件式設計開發(fā)下，就需要管理公共項目、主程序庫等文件。構建系統需要花費不少時間，多虧如此，在實現系統過程中，我花了不少精力和時間在項目的集成研究中。

同時，插件式開發(fā)在插件接口上的問題也如出一轍，問題同樣出于插件接口的管理，放置插件接口的地方和時機的考慮并不容易；插件接口越多、可開發(fā)的插件種類就越多，不同種類的插件可能對應用程序造成的許多不同問題；插件越多，系統的資源開銷就越大等。

3 總結

JFTest軟件測試管理系統中，是采用了MVC設計模式，它是一個經過考驗的真正的軟件設計模型，它可以使程序成為可維護的、模塊化的和快速開發(fā)的包。使用分離的模型(Model)、視圖(View)和控制器(Controller)組織的程序是輕便的。新的特性很容易就被加入，舊的程序換上新的外觀也是一下子的功夫。模塊化和分離的設計使得開發(fā)者和設計者能夠同時工作，這包括了快速原型的能力。分離的設計令開發(fā)者可以修改應用的一部分而不會影響到其它部分，而且本系統最大的特點是能實現可持續(xù)的子模塊集成。