肖新鳳

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

0 前言

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

1 需求分析

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

1.1 配置管理

管理員在配置管理模塊對(duì)相關(guān)的內(nèi)容，進(jìn)行瀏覽配置信息、添加配置信息、刪除配置信息、編輯配置信息、查詢配置信息等操作。提取編輯配置信息時(shí)不一定要修改所屬項(xiàng)目的分類。配置管理用例圖如1所示。

圖1 配置管理用例圖

1.2 Bug管理

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

圖2 Bug管理的用例圖

1.3 Bug處理

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

圖3 Bug處理的用例圖

2 系統(tǒng)設(shè)計(jì)

2.1 插件式設(shè)計(jì)

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

圖4 插件式設(shè)計(jì)模式

基于插件設(shè)計(jì)的應(yīng)用程序由應(yīng)用程序框架、插件接口、插件和公共項(xiàng)目類庫四部分組成。

應(yīng)用程序框架負(fù)責(zé)應(yīng)用程序的整體運(yùn)作，它清楚程序整個(gè)流程，但并不知道每個(gè)過程具體要做什么。它在適當(dāng)?shù)臅r(shí)候調(diào)用一些插件，來完成真正的功能。插件接口是一個(gè)協(xié)議。插件按照這個(gè)協(xié)議實(shí)現(xiàn)出來，就可以加入到應(yīng)用程序中來。當(dāng)然，對(duì)于復(fù)雜的系統(tǒng)，插件接口可能有多個(gè)，各自具有獨(dú)立的功能。插件是完成實(shí)際功能的實(shí)體，實(shí)現(xiàn)了要求的插件接口。盡管實(shí)現(xiàn)什么以及怎么實(shí)現(xiàn)，完全是插件自己的自由。在實(shí)際情況來，一般還是有些限制，因?yàn)椴寮涌诒旧砜赡芫褪且粋€(gè)限制。如，實(shí)現(xiàn)編譯功能的插件，自然不能實(shí)現(xiàn)成一個(gè)聊天功能的插件。公共項(xiàng)目類庫是一組函數(shù)或者類，應(yīng)用程序框架和插件都可以調(diào)用。它通常是一個(gè)獨(dú)立的庫。應(yīng)用程序框架本身是公用的，是代碼復(fù)用的一種方式。但并不是所有可復(fù)用代碼都可以放在框架中，特別是插件會(huì)用到的公共代碼，那會(huì)造成插件對(duì)框架的依賴。把這些公共代碼提取到一個(gè)獨(dú)立的庫中，是一種好的方法。

2.2 開發(fā)設(shè)計(jì)模型的改進(jìn)

2.2.1 系統(tǒng)整體模式架構(gòu)

為更好地體現(xiàn)出系統(tǒng)的靈活性和可擴(kuò)展性，本系統(tǒng)采用了MVC三層模式開發(fā)和插件設(shè)計(jì)的混合開發(fā)模式，實(shí)現(xiàn)表現(xiàn)層和業(yè)務(wù)層的分離?？蛻舳擞蒄lex的事件處理（Event）和Fabrication的消息(Notification)處理的機(jī)制實(shí)現(xiàn)View層的功能，服務(wù)端使用Hibernate充當(dāng)Model層，Spring實(shí)現(xiàn)Controller層的功能，對(duì)服務(wù)端的Model層的數(shù)據(jù)進(jìn)行操作，并發(fā)布Services接口，供Flex的客戶端調(diào)用。如圖5所示。

圖5 系統(tǒng)整體模式架構(gòu)

Flex客戶端與Java服務(wù)端之間的通信是基于BlazeDS使用RemoteObject方式進(jìn)行數(shù)據(jù)交互。然而在系統(tǒng)的Flex客戶端也是一個(gè)MVC結(jié)構(gòu)的開發(fā)模式，F(xiàn)lex客戶端使用Fabrication框架又進(jìn)行了MVC三層劃分。跟Java服務(wù)端進(jìn)行交互的調(diào)用接口放在了Model層的proxy完成，使用消息（Notification）的機(jī)制在Controller層由command調(diào)用proxy的具體方法，具體的視圖的展現(xiàn)由View層的mediator完成。

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

圖6 Flex客戶端主程序運(yùn)行流程圖

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

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

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

2.3 核心模塊設(shè)計(jì)

圖7 基于Fabrication框架的Flex模塊內(nèi)運(yùn)作流程圖

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

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

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

3 總結(jié)

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