在開(kāi)發(fā)面向服務(wù)的體系結構(Service-Oriented Architecture,SOA)應用程序時(shí),您的組織很可能會(huì )存在需要進(jìn)行大量的實(shí)現和測試工作的非功能需求(NonFunctional Requirement,NFR)。Shiv Asthana 在本文中介紹了在測試作為 SOA 環(huán)境的一部分構建的應用程序的非功能需求時(shí)需要遵循的最佳實(shí)踐。
SOA 是一種 IT 體系結構風(fēng)格,支持將您的業(yè)務(wù)轉換為一組相互鏈接的服務(wù)或可重復業(yè)務(wù)任務(wù),可在需要時(shí)通過(guò)網(wǎng)絡(luò )訪(fǎng)問(wèn)這些服務(wù)和任務(wù)。這個(gè)網(wǎng)絡(luò )可以是局域網(wǎng)、Internet,或者一組不同位置提供的分散各處且采用多種技術(shù),但以類(lèi)似于安裝在本地桌面的方式交互的服務(wù)??梢詫@些服務(wù)進(jìn)行結合,以完成特定的業(yè)務(wù)任務(wù),從而讓您的業(yè)務(wù)快速適應不斷變化的客觀(guān)條件和需求。也就是說(shuō),SOA 遵循查找、綁定并執行的關(guān)鍵原則工作,非常適合用于滿(mǎn)足請求/響應類(lèi)型的業(yè)務(wù)需求。
當由能夠解決難點(diǎn)或實(shí)現特定手動(dòng)任務(wù)的自動(dòng)化的策略業(yè)務(wù)目標和需求對 SOA 實(shí)現進(jìn)行引導時(shí),就可以實(shí)現業(yè)務(wù)轉換。這樣能夠帶來(lái)諸多好處,包括:
不過(guò),只有在將功能需求和非功能需求包含到應用程序中并無(wú)縫集成到生產(chǎn)環(huán)境中,才能夠實(shí)現 SOA 承諾的好處。因此,理想的實(shí)現和測試在關(guān)鍵時(shí)刻是必不可少的。
NFR 測試的主要挑戰出現在 SOA 應用程序在實(shí)驗室環(huán)境中開(kāi)發(fā)或作為軟件供應商的新產(chǎn)品投資組合的一部分開(kāi)發(fā)時(shí),在這些情況下,大多數時(shí)候生產(chǎn)環(huán)境都不可用。其他的挑戰包括:
雖然沒(méi)有測試軟件的最佳萬(wàn)能方法,但可以參考下面根據我的經(jīng)驗給出的列表。除了應對上面的一些挑戰外,這些建議還可能會(huì )帶來(lái)其他優(yōu)勢:
| 測試類(lèi)型 | 測試定義 |
|---|---|
| 可訪(fǎng)問(wèn)性 | 驗證訪(fǎng)問(wèn)應用程序功能的能力。 |
| 審核與控制 | 驗證檢查歷史工作流和審核記錄的便利性。 |
| 可用性 | 驗證應用程序是否能提供服務(wù)水平協(xié)議(Service Level Agreement,SLA)中規定的高正常運行時(shí)間。 |
| 兼容性 | 驗證應用程序是否適合之前已有(較舊)的環(huán)境。 |
| 文檔 | 驗證用戶(hù)指南是否提供了正確的說(shuō)明。 |
| 安裝 | 驗證應用程序是否能在所定義的中間件堆棧上工作。 |
| 互操作性 | 驗證在更改環(huán)境中的重要組件后應用程序是否能正常工作。 |
| 負載/容量 | 驗證給定時(shí)間應用程序是否能完成所需處理的事務(wù)數量。 |
| 可維護性 | 驗證在應用程序投入生產(chǎn)環(huán)境中后進(jìn)行維護的便利性。 |
| 性能 | 驗證響應時(shí)間、吞吐量、并發(fā)性等等標準是否滿(mǎn)足需求。 |
| 可靠性 | 驗證應用程序在與生產(chǎn)環(huán)境類(lèi)似的負載壓力下是否能正常工作。 |
| 可伸縮性 | 驗證應用程序是否能滿(mǎn)足業(yè)務(wù)不斷增長(cháng)的需求。 |
| 安全性 | 驗證應用程序是否具有足夠的安全措施,能夠防止信息被盜。 |
| 服務(wù)能力 | 驗證是否能夠在不對業(yè)務(wù)造成任何影響的情況下對應用程序進(jìn)行調試。 |
| 可用性 | 從最終用戶(hù)的角度驗證應用程序是否可用。 |
| 工具 | 功能 |
|---|---|
| IBM Rational AppScan | 支持以集中方式進(jìn)行 SOA 應用程序安全性評估,并提供了完全集成的解決方案集。Rational AppScan 能夠隨著(zhù)企業(yè)體系結構伸縮,支持同時(shí)掃描多個(gè)應用程序。 |
| IBM Rational Functional Tester | 為測試人員提供用于功能和非功能測試、回歸測試、GUI 測試和數據驅動(dòng)測試的自動(dòng)化測試功能。工具的測試自動(dòng)化功能也允許進(jìn)行負載和壓力測試。 |
| IBM Rational Performance Tester | 捕獲響應時(shí)間、頁(yè)面吞吐量和并發(fā)性。此性能測試創(chuàng )建、執行和分析工具供團隊用于在部署前驗證復雜 SOA 應用程序的可伸縮性和可靠性。 |
| IBM Rational Performance Tester Extension for SOA Quality | 擴展 SOA 應用程序的性能和可伸縮性測試。這是負載和性能測試與問(wèn)題分析工具,除了 Rational Performance Tester 的標準功能外,還能夠幫助尋找性能瓶頸。它支持進(jìn)行 SOA 效率問(wèn)題確定,并為支持部署的 Web 服務(wù)提供了廣泛的平臺監視支持部署,且支持服務(wù)器資源數據的收集和可視化。 |
注意: IBM Rational RequisitePro、IBM Rational Test Manager 和 IBM Rational ClearQuest® 可分別用于進(jìn)行需求管理、測試用例管理和缺陷管理。
正如前面提到的,SOA 測試中的一個(gè)挑戰是創(chuàng )建存根和模擬器。存根和模擬器替代生產(chǎn)環(huán)境中的遺留應用程序和其他外部應用程序(在生產(chǎn)中作為后端系統)。除了業(yè)務(wù)領(lǐng)域的知識外,還可以通過(guò)分析所開(kāi)發(fā)的應用程序的系統上下文來(lái)創(chuàng )建存根和模擬器(請參見(jiàn)圖 2)。
在圖 2 中,需要模擬遺留生產(chǎn)系統(藍色)和外部系統(粉紅色)作為存根,以測試新應用程序(功能和非功能測試都需要)。
測試團隊可以首先從了解這些系統的功能入手,然后尋找模擬這些系統進(jìn)行測試的簡(jiǎn)單方法。在大多數情況下,一個(gè)簡(jiǎn)單的數據庫就可以幫助解決問(wèn)題,但其中應該包括支持所要測試的業(yè)務(wù)事務(wù)的所有表格和示例數據。
![]() ![]() |
IBM 名為 Global Business Solutions Center (GBSC) 的團隊開(kāi)發(fā)并測試了名為組合業(yè)務(wù)服務(wù)(Composite Business Service,CBS)的 SOA 應用程序,此類(lèi)應用程序在 IBM SOA Foundation 和中間件堆棧(如 IBM WebSphere® Process Server、IBM WebSphere Application Server、IBM WebSphere Business Services Fabric、IBM WebSphere MQ 和 IBM DB2® 產(chǎn)品)上運行。CBS 是相關(guān)的集成業(yè)務(wù)服務(wù)的集合,能提供特定的業(yè)務(wù)解決方案,并支持在 SOA 上構建的業(yè)務(wù)流程。
通常,CBS 與客戶(hù)環(huán)境中的其他應用程序和/或服務(wù)集成,從而為客戶(hù)提供所需的業(yè)務(wù)解決方案。業(yè)務(wù)解決方案由編排在一起的業(yè)務(wù)服務(wù)組成。也就是說(shuō),CBS 不是獨立解決方案,而是能夠使用一個(gè)或多個(gè) CBS 創(chuàng )建的解決方案。
使用 CBS 創(chuàng )建的端到端解決方案的客戶(hù)目標是銀行、醫療、保險和零售等行業(yè)及政府部門(mén)??紤]到這些行業(yè)的本質(zhì)和規模,您可以發(fā)現,SOA 的角色是支持大容量和任務(wù)關(guān)鍵型業(yè)務(wù)事務(wù)的處理,以及支持異類(lèi)環(huán)境中的持續業(yè)務(wù)更改。
這就是 NFR 為何在對客戶(hù)的業(yè)務(wù)進(jìn)行轉換的過(guò)程中如此重要的原因。目前在 GBSC 中開(kāi)發(fā)的 CBS 已經(jīng)針對上面建議的大部分需求進(jìn)行了測試,在某些情況下具有出眾的性能基準,如在單個(gè)批處理提交中能處理超過(guò) 2 百萬(wàn)個(gè)事務(wù)的能力,以及所報告的各種任務(wù)關(guān)鍵型流程的卓越吞吐量和響應時(shí)間。
測試人員使用 Rational Performance Tester、IBM Tivoli® Composite Application Manager 以及自主構建的實(shí)用工具程序等工具來(lái)創(chuàng )建測試數據和實(shí)現特定測試用例的自動(dòng)化。我在這個(gè)列表中忽略了常規的測試和缺陷管理工具,如 Rational Test Manager 和 Rational ClearQuest 等,因為此類(lèi)常規工具用于同時(shí)支持功能和非功能測試。
圖 3 顯示,在示例應用程序中的業(yè)務(wù)事務(wù) 1 的并發(fā)用戶(hù)數量從 1,000 增加到 1,150 時(shí),平均響應時(shí)間從 3 秒增加到了 3.2 秒。
圖 4 顯示,在示例應用程序中的業(yè)務(wù)事務(wù) 2 的并發(fā)用戶(hù)數量從 1,000 增加到 1,150 時(shí),平均響應時(shí)間從 7.9 秒增加到了 10.7 秒。
回顧與 NFR 關(guān)聯(lián)的表格時(shí),請注意參考數據極為關(guān)鍵。如果沒(méi)有這些數字,就沒(méi)有意義。例如,如果收集并發(fā)布性能相關(guān)的基準,至少應該提供以下參考數據:
![]() ![]() |
雖然測試 NFR 是成功采用 SOA 應用程序所必不可少的步驟,但請記住,如果沒(méi)有具體的量化要求(在可能的情況下),則可能會(huì )遇到麻煩。在實(shí)驗室環(huán)境中進(jìn)行測試和開(kāi)發(fā)時(shí),如果并發(fā)性和容量/負載需求之類(lèi)的非功能標準未量化,而測試團隊進(jìn)入了基準確定階段,則更容易出現這種情況。此時(shí),完成項目所需的時(shí)間和工作量都會(huì )大幅度增加。
不過(guò),如果創(chuàng )建了采用計劃并與所有項目涉眾進(jìn)行了共享,則可以緩解這個(gè)風(fēng)險。接下來(lái)讓我們了解一下如何為項目制定采樣計劃,您需要在其中確定 SOA 應用程序能夠處理的最大事務(wù)量。
首先,將所有可以在測試環(huán)境中處理的事務(wù)排列和組合添加到表格中。請參見(jiàn)表 3 中的示例。
| 文件中的事務(wù)請求數量 | 上載的單個(gè)批次中的文件數量 | ||||
|---|---|---|---|---|---|
| 100 | 10000 | 20000 | 30000 | 40000 | 50000 |
| 1000 | 1000 | 2000 | 3000 | 4000 | 5000 |
| 10000 | 100 | 200 | 300 | 400 | 500 |
| 100000 | 10 | 20 | 30 | 40 | 50 |
| 1000000 | 1 | 2 | 3 | 4 | 5 |
隨后,進(jìn)行了應用程序開(kāi)發(fā)之后,處理少量的文件,并根據得到的數據進(jìn)行推斷??梢陨陷d 100 個(gè)批次,每個(gè)文件中包含 100 個(gè)請求,根據其處理此數目所需的時(shí)間,可以評估處理表 3 中所示的文件排列和組合所需的時(shí)間。
根據可用時(shí)間和資源以及確信度,您可以決定基準確定工作的開(kāi)始和結束時(shí)機。檢查根據表 3 創(chuàng )建的采樣計劃(請參見(jiàn)表 4)。
| 文件中的事務(wù)請求數量 | 上載的單個(gè)批次中的文件數量 | ||||
|---|---|---|---|---|---|
| 100 | 10000 | 20000 | 30000 | 40000 | 50000 |
| 1000 | 1000 | 2000 | 3000 | 4000 | 5000 |
| 10000 | 100 | 200 | 300 | 400 | 500 |
| 100000 | 10 | 20 | 30 | 40 | 50 |
| 1000000 | 1 | 2 | 3 | 4 | 5 |
盡管這些目標值可能會(huì )在確定基準的過(guò)程中失效,但可以幫助規劃這個(gè)級別本身的測試方法。例如,如果采用 100*40000 個(gè)文件的測試用例失敗,那么如何進(jìn)行相關(guān)工作呢?可行且實(shí)際的做法是,僅僅以預先規劃的方式進(jìn)行處理;例如,如果 100*40000 失敗,則嘗試 100*37500,然后 100*35000,以此類(lèi)推。請參見(jiàn)表 5 中給出的更多示例。
| 文件中的事務(wù)請求數量 | 上載的單個(gè)批次中的文件數量 | ||||
|---|---|---|---|---|---|
| 嘗試-1 | 嘗試-2 | 嘗試-3 | 嘗試-4 | 嘗試-5 | |
| 100 | 40000 | 37500 | 35000 | 32500 | 30000 |
| 1000 | 3000 | 2750 | 2500 | 2250 | 2000 |
| 10000 | 300 | 275 | 250 | 225 | 200 |
| 100000 | 20 | 18 | 16 | 14 | 12 |
| 1000000 | 2 | 1 | - | - | - |
在采用 SOA 的過(guò)程中,完全有可能發(fā)掘出現有 IT 系統的全部潛力。但中間件堆棧中使用的各個(gè)組件可能會(huì )造成一些限制,而在運行生產(chǎn)環(huán)境中的 SOA 應用程序和遺留應用程序時(shí)需要中間件堆棧。為了便于理解,讓我們以使用規則引擎為例,該引擎在給定時(shí)間只能處理 X 個(gè)事務(wù)。如果此規則引擎掛鉤到 SOA 應用程序,就會(huì )造成約束,使性能級別不高于 X。
![]() ![]() |
希望通過(guò)本文能夠給您組織的 SOA 采用之旅帶來(lái)一定的幫助。雖然這些最佳實(shí)踐的應用取決于您當前的 SOA 成熟度級別和改進(jìn)機會(huì ),但上面列表中給出的挑戰、非功能特征、工具、實(shí)際實(shí)現示例能夠幫助您確定如何著(zhù)手進(jìn)行此工作。而且,NFR 的成功實(shí)現最終將在 IT 和業(yè)務(wù)流程之間形成一個(gè)關(guān)聯(lián)關(guān)系,而這就是我們的主要目標。
![]() | ||
![]() | ![]() | Shiv Asthana 在位于印度海德拉巴的 IBM GBSC 測試管理團隊任職,該團隊負責對基于 SOA 的資產(chǎn)進(jìn)行測試。Shiv 擁有 Birla Institute of Technology and Science, Pilani (BITS, Pilani) 的質(zhì)量管理碩士學(xué)位,有 8 年 IT 行業(yè)從業(yè)經(jīng)驗。 |
聯(lián)系客服