專利名稱：測試處理裝置和測試處理方法
技術領域：
本發(fā)明涉及軟件測試領域，具體而言，涉及ー種測試處理裝置和一種測試處理方法。
背景技術：
OSGi (Open Service Gateway Initiative)是面向 Java 的動態(tài)模型系統(tǒng)，它為模塊化應用的開發(fā)定義了ー個基礎架構，使得應用程序可以實現定義精煉的、可重用的和可協作的標準組件，井能夠靈活地、動態(tài)地組裝和部署到應用系統(tǒng)中。由于這些特性，OSGi已經得到了業(yè)界的廣泛應用，成為軟件集成和企業(yè)開發(fā)的首選架構之一。然而由于OSGi環(huán)境下采用不同的類加載器來加載程序代碼來實現組件的松散耦 合和動態(tài)部署，這種機制與傳統(tǒng)的應用程序完全不同，使得傳統(tǒng)的應用程序開發(fā)中所使用的測試方法并不能簡單地移植到OSGi環(huán)境中。這種矛盾使得目前基于OSGi的軟件系統(tǒng)開發(fā)存在ー些不同程度的常見問題a、無法進行自動化測試而只能采用效率低下的手工測試，在軟件系統(tǒng)發(fā)生變更后進行的回歸測試耗時費力，測試覆蓋率低；b、測試用例代碼緊密依賴于測試的目標構件而無法分開部署；c、測試用例只能針對ー些不依賴與系統(tǒng)上下文環(huán)境運行的構件進行測試，導致那些依賴于業(yè)務上下文環(huán)境的構件無法建立自動化測試用例。綜上所述，在OSGi環(huán)境中對軟件構件進行測試面臨的主要問題是測試用例運行的上下文環(huán)境與測試目標構件的真實環(huán)境的差異問題。對于此，現有常見的做法是為每個測試用例建立獨立的測試上下文來加載并執(zhí)行測試用例，如圖IA所示。這種方式下執(zhí)行測試用例的上下文環(huán)境是由測試框架本身定義的，并不同于被測試構件在軟件系統(tǒng)上執(zhí)行的真實環(huán)境(如圖IB所示)，而且每個測試用例的上下文是隔離的，這就要求被測試的構件不能依賴于其所在的軟件系統(tǒng)的執(zhí)行環(huán)境。因此這種方法的適用范圍比較受限，通常軟件系統(tǒng)的功能構件大多都在事務、安全、數據訪問、日志等功能方面需要依賴于系統(tǒng)的上下文環(huán)境，所以上述測試框架無法支持對這類構件的測試。故需要一種新的技術方案，可以為被測試用例的執(zhí)行提供與真實環(huán)境一致的上下文，避免由于執(zhí)行環(huán)境的不同而導致的測試結果的差異，同時，實現測試用例和測試對象之間的松耦合，測試用例可以批量的方式被執(zhí)行，進而提高軟件系統(tǒng)的測試效率，提升軟件系統(tǒng)的開發(fā)質量。

發(fā)明內容
本發(fā)明所要解決的技術問題在于，提供一種新的技術方案，可以為被測試用例的執(zhí)行提供與真實環(huán)境一致的上下文，避免由于執(zhí)行環(huán)境的不同而導致的測試結果的差異，同時，實現測試用例和測試對象之間的松耦合，測試用例可以批量的方式被執(zhí)行，進而提高軟件系統(tǒng)的測試效率，提升軟件系統(tǒng)的開發(fā)質量。
有鑒于此，本發(fā)明提供了ー種測試處理裝置，包括測試用例獲取模塊，獲取系統(tǒng)中的測試用例；上下文參數設置模塊，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中；測試用例執(zhí)行模塊，執(zhí)行所述測試用例，以測試所述目標構件。在該技術方案中，通過所述上下文參數設置模塊，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中，從而為被測試用例提供了與真實環(huán)境一致的上下文，進而能夠避免由于執(zhí)行環(huán)境的不同而導致的測試結果的差異，提高軟件測試的質量。在上述技術方案中，優(yōu)選地，還包括規(guī)范設置模塊，設置所述測試用例的數據結構、部署方式和/或加載方式；測試用例實現模塊，按所述數據結構、所述部署方式和/或所述加載方式在所述系統(tǒng)中實現所述測試用例，所述測試用例獲取模塊按所述部署方式，從所述系統(tǒng)中獲取所述測試用例，和/或所述測試用例執(zhí)行模塊根據所述數據結構，創(chuàng)建所述測試用例的編程對象實例，以測試所述目標構件，和/或按所述加載方式，加載所述測試 用例，以執(zhí)行所述測試用例來測試所述目標構件。在本技術方案中，測試用例的數據結構，定義了展現或指明一個測試用例時應包含的信息，例如編號、名稱、版本、作者等；測試用例的部署和加載方式，定義了測試用例的存在形式，將據此采用對應的方式來查找和加載測試用例。在上述技術方案中，優(yōu)選地，在所述系統(tǒng)為動態(tài)模塊系統(tǒng)時，所述測試用例獲取模塊從所述系統(tǒng)的上下文獲取所有啟動的模塊，并從所述啟動的模塊取得包含所述測試用例的模塊。在該技術方案中，可以根據具體的系統(tǒng)環(huán)境來取得測試用例，尤其適用于OSGi(Open Service Gateway Initiative)實現的軟件系統(tǒng),例如，在OSGi環(huán)境下,可以從啟動的bundle中過濾出包含測試用例的bundle。在上述技術方案中，優(yōu)選地，還包括模塊實現模塊，在所述系統(tǒng)中，以模塊形式實現所述測試用例和所述目標構件。在該技術方案中，需要在系統(tǒng)中環(huán)境中，以模塊的形式預先將目標構件和測試用例部署好，有利于減少目標構件與測試用例之間的耦合性，例如，在OSGi環(huán)境下，目標構件和測試用例都可以bundle形式實現。在上述技術方案中，優(yōu)選地，所述上下文參數包括登錄用戶、數據源、會話標識和/或事務標識。在該技術方案中，本領域技術人員應當理解，上述內容僅為上下文參數的示例，并不對其進行限制，上下文參數可以包含更多類型的內容。本發(fā)明還提供了ー種測試處理方法，包括步驟202，獲取系統(tǒng)中的測試用例；步驟204，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中；步驟206，執(zhí)行所述測試用例，以測試所述目標構件。在該技術方案中，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中，從而為被測試用例提供了與真實環(huán)境一致的上下文，進而能夠避免由于執(zhí)行環(huán)境的不同而導致的測試結果的差異，提高軟件測試的質量。在上述技術方案中，優(yōu)選地，在所述步驟202之前，還包括設置所述測試用例的數據結構、部署方式和/或加載方式，并按所述數據結構、所述部署方式和/或所述加載方式在所述系統(tǒng)中實現所述測試用例；所述步驟202包括按所述部署方式，從所述系統(tǒng)中獲取所述測試用例；和/或所述步驟206包括根據所述數據結構，創(chuàng)建所述測試用例的編程對象實例，以測試所述目標構件，和/或按所述加載方式，加載所述測試用例，以執(zhí)行所述測試用例來測試所述目標構件。在本技術方案中，測試用例的數據結構，定義了展現或指明一個測試用例時應包含的信息，例如編號、名稱、版本、作者等；測試用例的部署和加載方式，定義了測試用例的存在形式，將據此采用對應的方式來查找和加載測試用例。在上述技術方案中，優(yōu)選地，所述步驟202包括在所述系統(tǒng)為動態(tài)模塊系統(tǒng)時，從所述系統(tǒng)的上下文獲取所有啟動的模塊，并從所述啟動的模塊取得包含所述測試用例的模塊。
在該技術方案中，可以根據具體的系統(tǒng)環(huán)境來取得測試用例，尤其適用于OSGi(Open Service Gateway Initiative)實現的軟件系統(tǒng),例如，在OSGi環(huán)境下,可以從啟動的bundle中過濾出包含測試用例的bundle。在上述技術方案中，優(yōu)選地，在所述步驟202之前，還包括在所述系統(tǒng)中，以模塊形式實現所述測試用例和所述目標構件。在該技術方案中，需要在系統(tǒng)中環(huán)境中，以模塊的形式預先將目標構件和測試用例部署好，有利于減少目標構件與測試用例之間的耦合性，例如，在OSGi環(huán)境下，目標構件和測試用例都可以bundle形式實現。在上述技術方案中，優(yōu)選地，所述上下文參數包括登錄用戶、數據源、會話標識和/或事務標識。在該技術方案中，本領域技術人員應當理解，上述內容僅為上下文參數的示例，并不對其進行限制，上下文參數可以包含更多類型的內容。通過以上技術方案，可以為被測試用例的執(zhí)行提供與真實環(huán)境一致的上下文，避免由于執(zhí)行環(huán)境的不同而導致的測試結果的差異，同時，實現測試用例和測試對象之間的松耦合，測試用例可以批量的方式被執(zhí)行，進而提高軟件系統(tǒng)的測試效率，提升軟件系統(tǒng)的開發(fā)質量。


圖IA示出了相關技術中的OSGi環(huán)境下一般的構件測試方法的運行環(huán)境示意圖；圖IB示出了相關技術中的軟件系統(tǒng)構件實際的運行環(huán)境示意圖；圖2示出了根據本發(fā)明的實施例的測試處理方法的流程圖；圖3示出了根據本發(fā)明的實施例的測試處理裝置的框圖；圖4示出了根據本發(fā)明的實施例的測試處理裝置的結構示意圖；圖5示出了根據本發(fā)明的實施例的測試處理裝置的模塊示意圖；圖6示出了根據本發(fā)明的實施例的測試處理裝置的工作流程圖。
具體實施例方式為了能夠更清楚地理解本發(fā)明的上述目的、特征和優(yōu)點，下面結合附圖和具體實施方式
對本發(fā)明進行進一歩的詳細描述。在下面的描述中闡述了很多具體細節(jié)以便于充分理解本發(fā)明，但是，本發(fā)明還可以采用其他不同于在此描述的其他方式來實施，因此，本發(fā)明并不限于下面公開的具體實施例的限制。圖2示出了根據本發(fā)明的實施例的測試處理方法的流程圖。如圖2所示，本發(fā)明還提供了ー種測試處理方法，包括步驟202，獲取系統(tǒng)中的測試用例；步驟204，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中；步驟206，執(zhí)行所述測試用例，以測試所述目標構件。在該技術方案中，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中，從而為被測試用例提供了與真實環(huán)境一致的上下文，進而能夠避免由于執(zhí)行環(huán)境的不同而導致的測試結果的差異，提高軟件測試的質量。
在上述技術方案中，在所述步驟202之前，還包括設置所述測試用例的數據結構、部署方式和/或加載方式，并按所述數據結構、所述部署方式和/或所述加載方式在所述系統(tǒng)中實現所述測試用例；所述步驟202包括按所述部署方式，從所述系統(tǒng)中獲取所述測試用例；和/或所述步驟206包括根據所述數據結構，創(chuàng)建所述測試用例的編程對象實例，以測試所述目標構件，和/或按所述加載方式，加載所述測試用例，以執(zhí)行所述測試用例來測試所述目標構件。在本技術方案中，測試用例的數據結構，定義了展現或指明一個測試用例時應包含的信息，例如編號、名稱、版本、作者等；測試用例的部署和加載方式，定義了測試用例的存在形式，將據此采用對應的方式來查找和加載測試用例。在上述技術方案中，所述步驟202包括在所述系統(tǒng)為動態(tài)t旲塊系統(tǒng)時，從所述系統(tǒng)的上下文獲取所有啟動的模塊，并從所述啟動的模塊取得包含所述測試用例的模塊。在該技術方案中，可以根據具體的系統(tǒng)環(huán)境來取得測試用例，尤其適用于OSGi(Open Service Gateway Initiative)實現的軟件系統(tǒng),例如，在OSGi環(huán)境下,可以從啟動的bundle中過濾出包含測試用例的bundle。在上述技術方案中，在所述步驟202之前，還包括在所述系統(tǒng)中，以模塊形式實現所述測試用例和所述目標構件。在該技術方案中，需要在系統(tǒng)中環(huán)境中，以模塊的形式預先將目標構件和測試用例部署好，有利于減少目標構件與測試用例之間的耦合性，例如，在OSGi環(huán)境下，目標構件和測試用例都可以bundle形式實現。在上述技術方案中，所述上下文參數包括登錄用戶、數據源、會話標識和/或事務標識。在該技術方案中，本領域技術人員應當理解，上述內容僅為上下文參數的示例，并不對其進行限制，上下文參數可以包含更多類型的內容圖3示出了根據本發(fā)明的實施例的測試處理裝置的框圖。如圖3所示，本發(fā)明提供了ー種測試處理裝置300，包括測試用例獲取模塊302，獲取系統(tǒng)中的測試用例；上下文參數設置模塊304，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中；測試用例執(zhí)行模塊306，執(zhí)行所述測試用例，以測試所述目標構件。在該技術方案中，通過所述上下文參數設置模塊304，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中，從而為被測試用例提供了與真實環(huán)境一致的上下文，進而能夠避免由于執(zhí)行環(huán)境的不同而導致的測試結果的差異，提高軟件測試的質量。在上述技術方案中，還包括規(guī)范設置模塊308，設置所述測試用例的數據結構、部署方式和/或加載方式；測試用例實現模塊310，按所述數據結構、所述部署方式和/或所述加載方式在所述系統(tǒng)中實現所述測試用例，所述測試用例獲取模塊302按所述部署方式，從所述系統(tǒng)中獲取所述測試用例，和/或所述測試用例執(zhí)行模塊306根據所述數據結構，創(chuàng)建所述測試用例的編程對象實例，以測試所述目標構件，和/或按所述加載方式，カロ載所述測試用例，以執(zhí)行所述測試用例來測試所述目標構件。在本技術方案中，測試用例的數據結構，定義了展現或指明一個測試用例時應包含的信息，例如編號、名稱、版本、作者等；測試用例的部署和加載方式，定義了測試用例的存在形式，將據此采用對應的方式來查找和加載測試用例。在上述技術方案中，在所述系統(tǒng)為動態(tài)模塊系統(tǒng)時，所述測試用例獲取模塊302從所述系統(tǒng)的上下文獲取所有啟動的模塊，并從所述啟動的模塊取得包含所述測試用例的 模塊。在該技術方案中，可以根據具體的系統(tǒng)環(huán)境來取得測試用例，尤其適用于OSGi(Open Service Gateway Initiative)實現的軟件系統(tǒng),例如，在OSGi環(huán)境下,可以從啟動的bundle中過濾出包含測試用例的bundle。在上述技術方案中，還包括模塊實現模塊312，在所述系統(tǒng)中，以模塊形式實現所述測試用例和所述目標構件。在該技術方案中，需要在系統(tǒng)中環(huán)境中，以模塊的形式預先將目標構件和測試用例部署好，有利于減少目標構件與測試用例之間的耦合性，例如，在OSGi環(huán)境下，目標構件和測試用例都可以bundle形式實現。在上述技術方案中，所述上下文參數包括登錄用戶、數據源、會話標識和/或事務標識。在該技術方案中，本領域技術人員應當理解，上述內容僅為上下文參數的示例，并不對其進行限制，上下文參數可以包含更多類型的內容。以下結合實施例，詳細說明本發(fā)明的技術方案。本實施例中提出的測試處理裝置設計為與被測試的軟件系統(tǒng)是在同一環(huán)境中運行，這樣能夠為測試用例的執(zhí)行提供與真實環(huán)境一致的上下文，解決背景技術中所提到的問題，相對于現有技術方案，本實施例的技術方案的測試處理裝置的示意圖可以如圖4所示，測試用例可結合實際的實際運行環(huán)境來進行目標構件的測試。本實施例提出的測試處理裝置可以如圖5所示，由測試管理模塊502、測試接ロ模塊504、測試用例模塊506三部分組成I、測試接ロ模塊502 (相當于前述的規(guī)范設置模塊)此部分定義了測試用例模塊506需要遵循的接ロ規(guī)范。測試管理模塊504和測試用例模塊506都依賴于此模塊。2、測試管理模塊504 (相當于前述的上下文參數設置模塊和測試用例獲取模塊)此部分功能是從運行的OSGi環(huán)境中捜索、加載和運行已經部署的測試用例，為測試用例設置代碼執(zhí)行的線程上下文，并收集和輸出測試結果。3、測試用例模塊506 (相當于前述的模塊實現模塊)此部分定義了針對特定目標進行測試的測試用例。此模塊依賴但獨立于被測試的目標構件所在的模塊，是ー個可獨立部署的單位，可按需部署。測試管理模塊504、測試接ロ模塊502、測試用例模塊506在實現的形態(tài)上與測試目標所在的模塊在物理形態(tài)上都是相同的，都被實現為OSGi的bundle，以相同形式部署到OSGi運行環(huán)境中。測試管理模塊504、測試接ロ模塊502、測試用例模塊506之間沒有直接依賴，它們之間是依照OSGi運行環(huán)境提供的松耦合的方式形成依賴。本發(fā)明的裝置包括I個測試管理模塊504、1個測試接ロ模塊502和O、個測試用例模塊506。測試用例模塊506是可以根據需要進行部署的，測試管理模塊504以動態(tài)的方式從OSGi上下文中收集測試用例模塊506中定義的所有測試用例。 一、測試接ロ模塊502 此模塊是測試管理模塊504和測試用例模塊506的公共模塊，它的核心是定義測試用例和測試管理模塊504都共同遵循的接ロ規(guī)范。測試用例遵循該接ロ規(guī)范來實現，測試管理模塊504也遵循同樣的接ロ規(guī)范來加載和運行測試用例。測試接ロ模塊502是ー個邏輯上抽象的存在，它定義的接ロ規(guī)范的實際形式可以表現為編程語言上的接ロ或者類，也可以表現為ー份需要共同遵守的XML文檔，或者其它格式的文檔。因而，在物理上，測試接ロ模塊502可以是ー個包含了構成接ロ規(guī)范的編程語言的接ロ、類、XML文檔等數據文件的ー個獨立的OSGi Bundle，也可以將這些數據文件與測試管理模塊一起實現在同一個OSGi Bundle中。接ロ規(guī)范定義的要素包括( I)測試用例的數據結構定義了展現或指明一個測試用例時應包含的信息，例如編號、名稱、版本、作者等;(2)測試用例的部署和加載方式定義了測試用例的存在形式，測試管理模塊504將據此采用對應的方式來查找和加載測試用例。例如，以下是一段關于測試用例接ロ規(guī)范的描述測試用例要求都要包含名稱、版本、作者、描述等內容，需要實現接ロ類型com.my. test. ITestCase ;測試用例中的測試方法以小寫“test”開頭，沒有返回值和參數；測試斷言通過類型com. my. test. Test的一系列靜態(tài)方法assertEquals判斷是否通過測試；測試用例所在的Bundle中以XML文件testbundle. xml配置了測試Bundle中定義的所有的測試用例的ClassName, testbundle. xml文件位于META-INF目錄中。同樣地,在接ロ模塊中定義出接ロ類型com. my. test. ITestCase和Test如下
package com.mv.test; public interface ITestCase {
String getNamei);
String getVersion();
String getAuthoi'O;
String getDescriptionO;
}
package com.my.test;public class Test {public static void assertEquais(int expected,int actual) { //判斷expected和actual的值是否相等; if (expected != actual) {
throw new TestException("expected value :" + expected + ", butactual :" + actual +
}
}
public static void assertEquaIsiString expected,String actual){
//判斷expected和actual的值是否相等; if (! ex pec ted. equa i s( actual))(
throw new TestException("expected value + expected + ", butactual :" 一 actual + "!")；
}
}
//……
}ニ、測試管理模塊504的實現測試管理模塊504是本發(fā)明的核心模塊，實現該模塊的關鍵在于將其實現為OSGiBundle，與測試目標同樣地部署于目標系統(tǒng)的OSGi環(huán)境中，與測試目標在相同的上下文中執(zhí)行。這樣，在執(zhí)行測試用例之前，可以將目標系統(tǒng)的上下文參數設置到執(zhí)行用例的線程上下文中，以此保證了測試用例對測試目標構件的測試調用得以正確進行。一次測試任務的執(zhí)行主要由以下的幾個的操作構成I、收集測試用例從當前的系統(tǒng)環(huán)境中查找和收集部署的測試用例是執(zhí)行測試任務的前提，具體過程要遵循測試接ロ模塊定義的接ロ規(guī)范來進行實現。
第一歩，從OSGi Bundle上下文獲取當前OSGi環(huán)境下的所有啟動的Bundle。根據OSGi環(huán)境提供的BundleContext對象提供了相應的編程方法(例如getBundles())即可獲得所有Bundle。第二步，按照測試接ロ規(guī)范的定義過濾出包含了測試用例的Bundle。由于定義測試用例的Bundle與測試目標構件的Bundle都是部署在一起的，因此需要從Bundle上下文獲得的Bundle列表過濾出包含測試用例的Bundle，過濾的方法遵循測試接ロ模塊定義的接ロ規(guī)范。以之前所舉接ロ規(guī)范示例為例，相應地，在此可以按照Bundle中的META-INF目錄中是否包含了 testbundle. xml配置文件并且文件中配置了至少ー個測試用例作為過濾條件，對符合條件的Bundle執(zhí)行后續(xù)的處理。第三步，從Bundle中查找獲得測試用例的列表；這ー步是需要遵循測試接ロ模塊定義的接ロ規(guī)范來收集測試用例的信息。以之前所舉接ロ規(guī)范示例為例，相應地，解析Bundle中META-INF目錄下的testbundle. xml配置文件獲取在其中配置的測試用例的類型、名稱、參數等，這些信息將在執(zhí)行測試用例時用于創(chuàng)建測試用例的編程對象實例。

2、初始化用例執(zhí)行上下文這ー過程是將測試目標構件所需要的上下文參數設置到測試用例的線程上下文中，使得測試用例對目標構件的測試調用得以有效運行。上下文的初始化方式與實際的軟件系統(tǒng)相關，一般來說包括但不限于當前登錄用戶、當前數據源、會話ID，事務ID等系統(tǒng)環(huán)境參數。3、執(zhí)行測試用例輸出測試結果根據之前操作中收集到的測試用例信息，加載測試用例，執(zhí)行測試用例中的測試方法，記錄并輸出這些測試方法的執(zhí)行結果。對測試用例的加載以及測試方法的執(zhí)行需要根據測試接ロ模塊定義的接ロ規(guī)范來實現。以之前所舉接ロ規(guī)范示例為例，相應地，創(chuàng)建那些實現了 com. my. test. ITestCase接ロ的類型的實例,逐個執(zhí)行其中以test開頭的方法，對于執(zhí)行完成沒有拋出異常的test方法的測試結果輸出為通過測試，拋出異常的輸出為測試失敗，并輸出異常信息。三、測試用例模塊506:測試用例模塊506是用于定義測試用例的，其實現形式為OSGiBundle，依賴于測試接ロ模塊502和測試目標構件，與測試目標構件的Bundle —同部署，其對測試目標構件的依賴通過OSGi提供的Service、Package Import等方式引入,對測試目標構件沒有入侵性。在測試用例模塊506中，測試用例是遵循了測試接ロ模塊502定義的接ロ規(guī)范并實現針對特定構件進行代碼執(zhí)行結果驗證的代碼實現類，其具體的實現得視其測試的目標對象的功能而定。以測試接ロ模塊502中所舉的接ロ規(guī)范為例，一個測試用例可以實現為以下的形式package com.my.testcase;
import com.my.test.ITestCase;import com.my.test.Test;
public class CustomerOrderTestCase implements ITestCase {
產*
*測試分發(fā)客戶訂單;
*/
public void testDistributeOrders() { int expectedValue = getExepectedValue(); int aclualVaiue = getTestResuit();
Test.assert.Equais(expecled Value, actual Value);*測試上傳客戶訂單；
*1
public volet testUploadOrdersi){
int ex pec ted Value = jietExepectedVaiue(); int actualValue = getTestResult();
Test.assertEquais(expectedValue, actualValue);
}
(i Override public String getName() {
return ”客戶訂單測試用例,';
}
(i Override
public Siring getVersion() { return "2.1
}
(i Override
public String getAuthor() { return "john
}
Override
public String tietDescnption() {
return ”測試客戶訂單的分發(fā)和上傳”;
}
}對應地在Bundle的META-INF目錄中的testbundle. xml的實現示例如下
< xral version=" 1.0" encoding="UTF-8" >

くtest〉
<testcase class="com.my.testcase.CustomerOrderTestCase"/><testcase Class=inCOin.my.tesi:case.OtherTestCase"/>
</test>以上是測試用例實現的ー個示例，該示例遵循接ロ規(guī)范實現了接ロ ITestCase，定義了兩個測試方法 testDistributeOrders、testUploadOrders。圖6示出本發(fā)明的實施例的測試處理裝置的工作流程。如圖6所示，步驟602，從OSGi上下文收集所有Bundle信息；
步驟604，逐個處理收集到的Bundle ；步驟606，判斷該Bundle是否是有效測試用例模塊，在是時進入步驟608，在否時進入步驟612 ；步驟608，加載測試用例模塊中定義的測試用例；步驟610，將測試用例加入執(zhí)行隊列；步驟612，判斷是否有未處理的Bundle，有則返回步驟604，沒有則進入步驟614 ；步驟614，初始化測試用例執(zhí)行上下文；步驟616，執(zhí)行測試用例輸出測試結果。通過以上技術方案，可以實現ー種測試處理裝置和一種處理方法，提高了軟件系統(tǒng)的測試效率，提升了軟件系統(tǒng)的開發(fā)質量。以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。
權利要求
1.一種測試處理裝置，其特征在于，包括 測試用例獲取模塊，獲取系統(tǒng)中的測試用例； 上下文參數設置模塊，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中； 測試用例執(zhí)行模塊，執(zhí)行所述測試用例，以測試所述目標構件。
2.根據權利要求I所述的測試處理裝置，其特征在于，還包括 規(guī)范設置模塊，設置所述測試用例的數據結構、部署方式和/或加載方式； 測試用例實現模塊，按所述數據結構、所述部署方式和/或所述加載方式在所述系統(tǒng)中實現所述測試用例，所述測試用例獲取模塊按所述部署方式，從所述系統(tǒng)中獲取所述測試用例，和/或所述測試用例執(zhí)行模塊根據所述數據結構，創(chuàng)建所述測試用例的編程對象實例，以測試所述目標構件，和/或按所述加載方式，加載所述測試用例，以執(zhí)行所述測試用例來測試所述目標構件。
3.根據權利要求I所述的測試處理裝置，其特征在于，在所述系統(tǒng)為動態(tài)模塊系統(tǒng)時，所述測試用例獲取模塊從所述系統(tǒng)的上下文獲取所有啟動的模塊，并從所述啟動的模塊取得包含所述測試用例的模塊。
4.根據權利要求3所述的測試處理裝置，其特征在于，還包括 模塊實現模塊，在所述系統(tǒng)中，以模塊形式實現所述測試用例和所述目標構件。
5.根據權利要求I至4中任一項所述的測試處理裝置，其特征在于，所述上下文參數包括登錄用戶、數據源、會話標識和/或事務標識。
6.—種測試處理方法,其特征在于,包括 步驟202，獲取系統(tǒng)中的測試用例； 步驟204，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中； 步驟206，執(zhí)行所述測試用例，以測試所述目標構件。
7.根據權利要求6所述的測試處理方法，其特征在于，在所述步驟202之前，還包括設置所述測試用例的數據結構、部署方式和/或加載方式，并按所述數據結構、所述部署方式和/或所述加載方式在所述系統(tǒng)中實現所述測試用例； 所述步驟202包括按所述部署方式，從所述系統(tǒng)中獲取所述測試用例；和/或 所述步驟206包括根據所述數據結構，創(chuàng)建所述測試用例的編程對象實例，以測試所述目標構件，和/或 按所述加載方式，加載所述測試用例，以執(zhí)行所述測試用例來測試所述目標構件。
8.根據權利要求6所述的測試處理方法，其特征在于，所述步驟202包括 在所述系統(tǒng)為動態(tài)模塊系統(tǒng)時，從所述系統(tǒng)的上下文獲取所有啟動的模塊，并從所述啟動的模塊取得包含所述測試用例的模塊。
9.根據權利要求8所述的測試處理方法，其特征在于，在所述步驟202之前，還包括 在所述系統(tǒng)中，以模塊形式實現所述測試用例和所述目標構件。
10.根據權利要求6至9中任一項所述的測試處理方法，其特征在于，所述上下文參數包括登錄用戶、數據源、會話標識和/或事務標識。
全文摘要
本發(fā)明提供了一種測試處理裝置，包括測試用例獲取模塊，獲取系統(tǒng)中的測試用例；上下文參數設置模塊，將測試目標構件所需的上下文參數設置到所述測試用例的線程上下文中；測試用例執(zhí)行模塊，執(zhí)行所述測試用例，以測試所述目標構件。相應地，本發(fā)明還提供了一種測試處理方法。通過本發(fā)明的技術方案，針對基于OSGi(Open Service Gateway Initiative)實現的軟件系統(tǒng)，可以為被測試用例的執(zhí)行提供與真實環(huán)境一致的上下文，避免由于執(zhí)行環(huán)境的不同而導致的測試結果的差異，同時，實現測試用例和測試對象之間的松耦合，測試用例可以批量的方式被執(zhí)行，進而提高軟件系統(tǒng)的測試效率，提升軟件系統(tǒng)的開發(fā)質量。
文檔編號G06F11/36GK102819488SQ20121022613
公開日2012年12月12日 申請日期2012年6月29日 優(yōu)先權日2012年6月29日
發(fā)明者黃海泉 申請人:用友軟件股份有限公司