測試服務:SOA的完整性和擴展性

2019-11-17 04:57:05

字體：大中小

來源：轉載

供稿：網友

隨著開發軟件往可復用服務的遷移，很多軟件開發生命周期中的范式被開發了出來。正如面向對象要求一個非凡的概念集合來達到有效的開發，面向對象架構也帶來了它共享的具體途徑。在接下來的段落中，我們將會我們將會探索開發服務的許多重要方面中的一個：測試。依靠于你們組織中的軟件治理類型，測試可以通常作為一個全局過程或者最高優先權的過程。以前的方法，在代碼行之間用靈敏開發技巧，強迫把測試推遲到服務被完全實現以后才進行測試，而隨后的服務就會采用這個還沒有經過測試的服務，并且不等到你使之成為一個“預備好”的服務。當有支持者確認了一個調查，在開始就進行測試并且采用靈敏原則比直到最后的開發階段才測試更有好處，我們暫且不管這些，我們先把關于何時把測試引入到你具體的工程中去的討論擱置一邊，讓我們關注一下如何進行測試。測試決不是一個簡單的東西，有很多不同的測試類型可以應用在軟件上。依據測試的復雜性和領域，即使專業的團隊——QA團隊——可以被雇來完成特定的任務，但是是為了特定的目定，我們將會關注兩種類型的測試，他們都相對輕易的開發:單元測試和壓力測試。單元測試是指通過預先定義的一些列數據集合來驗證一個服務的既定目的的過程，這個數據集合是用來模擬顯示世界的用法從而能夠及時的方式來探測到缺陷。當為你的服務進行單元測試的時候，在服務被發布為正是的產品以前你可以把他們看成安全保護網，因為你能夠在實際數據流在這個系統運行之前使用這些預先的數據集合來測試你的服務的邏輯。另外一個單元測試為你的開發帶來的那些好處在當你的系統開始用上了一段時間之后就會更加突出了。因為演化的服務意味著底層邏輯的修改，這些修改可能會破壞服務本來被希望忙足的一些具體的使用設定。盡管如此，通過現有的單元測試套件，并且保證一直保持同這些測試的一致，保護任何使用你服務的依靠部分免受在以后可能新的修訂中帶來的任何破壞實際的單元測試的進行很大程度上依靠于編程語言或者你使用來部署你的服務的平臺，但是更加可能的情況是為了能更輕易的進行測試的步步為營，確認和部署，將會通過一個特定的框架來完成這些 ——換一句話說就是，自動化的進行所有的能夠使得單元測試成為必需的過程。在所有的最流行的單元測試的框架中有:java的JUnit 和.NET的Unit Testing Framework ，Unit Testing Framework 構成了Visual Studio的一部分。對于深度的解釋他們的框架或者其他的一些單元測試套件將不會在本文中討論，但是列表1.1展示的就是一個Java支持的服務的Junit測試是怎樣的。列表1.1 對Java類構成的Web Services的Junit單元測試import junit.framework.*;

public class PayrollTest extends TestCase {

PRivate Payroll basePayroll;

private Employee accountingE;

public PayrollTest(String type) {

super(type);

}

protected void setUp() {

// Initialize Payroll object

basePayroll = new Payroll();

// Generate employee, assign to payroll

accountingE = new Employee("John Smith", 5743.00);

basePayroll.addEmployee(accountingE);

}

protected void tearDown() {

// Reinitialize Payroll object

basePayroll = null;

}

public void testAddEmployee() {

Employee contractE = new Employee("Auditor", 2843.00);

basePayroll.addEmployee(contractE);

double totalPayroll = accountingE.getSalary() + contractE.getSalary();

assertEquals(totalPayroll, basePayroll.getTotal(), 0.0);

assertEquals(2, basePayroll.countEmployees());

}

public void testEmptyPayroll() {

basePayroll.emptyPayroll();

assertTrue(basePayroll.emptyPayroll());

}

public void testEliminateEmployee() throws EmployeeNotFound {

basePayroll.eliminateEmployee(accountingE);

assertEquals(0, basePayroll.countEmployees());

assertEquals(0.0, basePayroll.getTotal(), 0.0);

}

public static Test suite() {

TestSuite suite = new TestSuite(PayrollTest.class);

return suite;

}

public static void main(String args[]) {

junit.textui.TestRunner.run(suite());

}

}
這個測試列表表示的是對兩個將會用來構成決定薪水冊的數據的Web service進行測試的一個例子。請注重Payroll和Employee類的實例是如何創建的，它們都會被后面的testXXX()命名的方法來操縱。一旦被這些方法操作，請注重看到是通過不同的以assertXXX()命名的Junit方法來調用的。用來調用預先定義的數據塊的不同的斷言方法的參數在底層的服務類之間傳遞，在這些類上進行同所期望的值進行比對，這個比對是在當測試框架給出一個錯誤或者返回一個正確的執行的時候進行。單元測試是用來驗證一個服務邏輯的完整性，重點測試是用來決定一個服務在一個特定的用戶附載的時候應該具有什么樣的行為，它是一個可以幫助決定對一個服務的基礎架構的適當支持的過程，這些基礎架構包括如硬件能力，應用程序配置和可以獲得的網絡帶寬，以及其他的東西。一個可以幫助你進行壓力測試的工具是JMeter ，它是一個由Apache組織開發的一個開源項目。盡管Jmeter是基于java的，它可以產生SOAP和xmlRPC類型的請求，有效地發揮一個Web services客戶端的功能，來壓力測試任何服務端的部署。圖1.1展示的是一個使用這個工具進行的在SOAP/XML-RPC服務上的附載測試。測試服務:SOA的完整性和擴展性

圖1.1:Jmeter對Web services的壓力測試在Jmeter中創建上述的壓力測試的過程如下:1. 在Jmeter的主界面，將你的鼠標移動到Test Plan按鈕上并點擊右鍵。從彈出的菜單中選擇:Add – Thread Group。Thread Group按鈕將會被創建。2.定位在Thread Group按鈕上左邊的窗體中將會顯示不同的參數。參數Number of threads 表示的是你的壓力測試將會對你的服務仿效的請求的數。3.下一步，當鼠標在Thread Group按鈕上點擊右鍵，從彈出的菜單中選擇:Add – Sampler – SOAP/XML-RPC Request。SOAP/XML-RPC請求按鈕將會被創建。4.鼠標定位在SOAP/XML-RPC請求按鈕，左邊的窗體中將會顯示不同的參數。有關于你的Web service的URL的介紹，以及你希望發出的每一個請求的載荷。5.當鼠標在SOAP/XML-RPC請求按鈕上時，點擊右鍵，從彈出的菜單中選擇:Add – Listener – Monitor Results，和Add – Listener – View Results。兩個顯示壓力測試結果的按鈕將會生成。注重:假如需要，你可以添加更多的監聽者，這是Jmeter進行壓力測試結果的表示術語。6.保存你的測試，并從最高層的菜單中選擇Run-Start選項開始你的壓力測試。7.最后移動你的鼠標到每一個不同的Listener按鈕上，觀察你在對你的Web service進行壓力測試時獲得的性能參數。和單元測試框架相類似的本質，解釋Jmeter的許多復雜——或者任何其他壓力測試工具的這方面的問題——將會超出本文的范圍，但是Jmeter提供了全面可理解的并可自由獲取的文檔來解釋不同的壓力測試功能。我們總結我們對在Web services環境下單元測試和壓力測試的熟悉，這是在很多的測試過程中你可以在你的面向服務設計中的兩個方法，從而能夠確保你的部署的完整性和可測量性。

上一篇：終極SOA技術

下一篇：注冊儲存 SOA的核心問題