WO2010034548A1

WO2010034548A1 - Test module and method for testing an o/r imaging middleware

Info

Publication number: WO2010034548A1
Application number: PCT/EP2009/059846
Authority: WO
Inventors: Uwe Hohenstein; Michael Jäger
Original assignee: Siemens Aktiengesellschaft
Priority date: 2008-09-25
Filing date: 2009-07-30
Publication date: 2010-04-01
Also published as: DE102008048862A1; EP2329374A1

Abstract

The present invention relates to a testing of a middleware configured for the reciprocal imaging of object-oriented data of an object-oriented application and relational data of a relational database. For this purpose, testing is carried out utilizing a data model for modeling relational types of relational data models with regard to object-oriented data models, utilizing test data which is test data provided according to a data model of the object-oriented application, utilizing specified test cases for testing the middleware, wherein the test cases comprise queries corresponding to data queries of the object-oriented application to the relational database via the middleware, and by means of analysis of the results of the specified test cases. The present invention particularly relates to applications comprising O/R imaging middleware, and allows efficient and correct handling and operation of processes or sequences, and/or components or modules of an industry sector or products dependant on efficiently and correctly functioning O/R imaging middleware.

Description

description

Test module and method for testing an O / R imaging middleware

The invention relates to testing of middleware configured to inter-map object-oriented data of an object-oriented application and relational database relational data. The invention describes a test environment for schematically determining the behavior of the middleware. In particular, the present invention relates to a test module, a method for testing the middleware, a computer program product by which the method is implemented and / or a data carrier comprising the computer program product.

An object / relational (O / R) mapping middleware is software that establishes the connection between an object-oriented application and a relational database. The purpose of this O / R mapping middleware is to transfer the data of an application in an object-oriented data structure to the tabular memory structure of common relational database systems and vice versa, especially if the object-oriented application queries data from the relational database. The combination of an object-oriented data structure on the one hand and a relational database on the other hand represents a common application in the industrial use of software systems.

Fig. 1 shows a typical structure of an application case of an O / R imaging middleware. An object-oriented application 11 does not access the relational database 13 directly. Instead, the O / R mapping middleware 12 is placed therebetween to establish the connection between both sides. The objects of the object-oriented application 11 are converted by the O / R mapping middleware 12 into data corresponding to the relational schema or data model correspond to the relational database 13 and thus in the relational database 13 can be stored. In this way, the persistence of the data of the object-oriented application is established and a decoupling between storage and processing of the data is realized. That is, the objects of the object-oriented application 11 are permanently stored in this way in the relational database 13 and are retrievable from the database 13 and recoverable.

In the following, the data of the object-oriented application, which are created according to the object-oriented model of the object-oriented application and thus exist as objects of the object-oriented application, can also be referred to as object-oriented data. Further, the data of the relational database, which are created according to the relational schema or model of the relational database and exist in the form of tables and / or relations in the relational database, are also referred to as relational data.

Object-oriented software is used in many industrial applications. These object-oriented applications act e.g. managing, regulating, monitoring and / or controlling the industrial processes or processes and / or the industrial components or modules. Examples include production processes, plant control processes, plants, components and modules of the plants. There are many and different uses. Furthermore, object-oriented applications are also used to control, govern, manage, and / or monitor processes and / or components also within products (e.g., equipment, devices, etc.). Even products themselves can be controlled, controlled, managed and / or monitored by object-oriented applications.

All of these use cases have the common feature of treating the data as objects of the object-oriented application. An object-oriented application itself, however, is not able to secure these objects permanently. With Upon termination of the application and / or with switching or switching between different workspaces of the application, the objects created and thus the data of the object-oriented application are lost. For this reason, relational databases are used to ensure permanent storage of the data and thus of the objects of the object-oriented application or the persistence of the object-oriented application and to be able to store the data permanently. This is important in terms of safe and correct handling and operation of processes or processes and / or components or modules of the respective industry or products.

Furthermore, correct, error-free and comprehensive retrieval or restoration of the objects from a relational database is also important since the correct and secure handling and operation of processes or sequences and / or components or modules of the respective industry or products is essentially dependent on the Completeness and correctness of the recovered objects. Therefore, an O / R mapping middleware fulfills an important purpose by transforming the objects of an object-oriented application into relational data structures, and vice versa, and ensuring proper operation. Safe and correct handling and operation of processes or processes and / or components or modules of the respective industry or products is thus highly dependent on a secure and correctly functioning O / R imaging middleware.

Currently, there are several software solutions, such

Implement O / R Mapping Middleware. Examples of such products include Hibernate, TopLink, iBATIS, OpenJPA and Kodo. These conventional software solutions differ, in particular, according to which method data in the database is persisted or permanently backed up. Differences may exist, for example, in the order, scope and / or structuring of the persistence operations. Likewise, the O / R imaging Middleware querying data from the database when requested by the application. Here, too, the software solutions differ in the order, scope and / or structure according to which data is read from the database.

It should be noted that the procedures for persisting and querying have a significant impact on the speed of execution and hence the performance of the application. Therefore, one has to know exactly the behavior of an O / R imaging middleware when using it, otherwise drastic losses in system performance can be expected.

One aspect of getting the data (data is handled by the

O / R mapping middleware queried from the relational database and provided to the object-oriented application in the form of objects) represents the so-called fetching behavior. Fetching generally refers to the most efficient retrieval or restoration of object-oriented data from a relational database and is initiated by appropriate requests or queries from the object-oriented application. In the following, the term "fetching" is used for this retrieval or restoration of object-oriented data.

When it comes to fetching, a distinction is made between "Eager Fetching" and "Lazy Fetching". "Eager Fetching" is a very extensive and costly recovery or recovery of object-oriented data to understand a query is extended to the extent of an object graph. Again, lazy fetching refers to a reduced and fast restoration of object-oriented data. Since these terms have become commonplace in the field of object-oriented and relational modeling, these terms are used below. A so-called Eager Fetching is characterized by the fact that when requesting or querying an object by the object-oriented application from a relational database not only the directly corresponding data record from the database is retrieved, but also other data are taken into account via relationships associated with the actual (core) data set. This behavior is particularly advantageous if, during the processing of the actual object in the object-oriented application, processing of data associated with this object automatically also occurs. However, this behavior can also have disadvantages. This is the case in particular when data associated with the application logic of the object-oriented application is not required and therefore its query and its receipt are superfluous. Depending on whether associated data is to be queried or ignored, it is "Eager Fetching" or "Lazy Fetching".

Since relational data models allow several different forms of representation of relationships or associations (eg 1-to-1, 1-to-n or n-to-m relationships) and the associations can extend as far as desired depending on the application, there is a lot of room for Given implementations of O / R mapping middleware. These implementations can be solved in very different ways. Each O / R imaging middleware offers several levers that can influence behavior and vary greatly in number and type.

Depending on the setting, Eager Fetching results in one or more query expressions (so-called "SELECT statements") of varying complexity, as a result of which the processing time can multiply quickly by an increase in the query expressions.

Conversely, lazy fetching can unfavorably reduce a query expression, leaving at least one separate further query is necessary and an additional expense arises. Therefore, configuring the fetching behavior is an important part of optimizing performance.

Furthermore, problems arise because of existing ones

Software solutions the fetching behavior is insufficiently documented and / or deviates from the documentation in details. Due to the large number of setting screws that influence the behavior, precise documentation is also very difficult. Furthermore, the implementation of feting may change in different versions of O / R imaging middleware. This leads to a changed performance during a version change. As a result, tests are needed to analyze and document the behavior of the O / R imaging middleware. Only then can the best configuration of the O / R mapping middleware be accomplished in terms of fetching behavior such that optimal performance of the O / R imaging middleware can be achieved.

The multitude of options for configuring the Apache OpenJPA O / R imaging middleware illustrates the problems of traditional O / R imaging middleware implementations while confirming the need to test the O / R imaging middleware.

Implementations, in particular to ensure the safe, correct and efficient handling and operation of processes or processes and / or components or modules of the respective industry or products that depend on a secure, correct and efficient O / R imaging middleware.

In the following, the multitude of configuration options are explained using the Apache OpenJPA O / R mapping middleware, for example. The following mechanisms are possible with OpenJPA: 1. Load Behavior Configuration in an XML Mapping File: This sets the fetching behavior for relationships. This means that queries and object traversals or object tracking via these relationships that affect corresponding data objects automatically assume the set behavior.

2. Configuration of the loading behavior as a note of corresponding instance variables in the code: As with the configuration in the XML file, the fetching for relationships is set accordingly, but now in the code.

3. Configuration of so-called Fetch Groups, in which targeted relationships can be summarized. For these fetch groups, the behavior may be e.g. towards Eager Fetching or Lazy Fetching. The Fetch Groups can exist in addition to the aforementioned settings and can also be activated and deactivated at runtime.

4. Configure a query at runtime to specifically configure the fetching. It is up to the developer, whether a query in individual cases or generally with the respective Fetching behavior is performed. This possibility can also be combined with the previously mentioned.

Other products offer similar mechanisms, but in other notations and with different behavior. For example, Bibernate also offers XML configurations and notations for an Eager and Lazy Fetching setting, as well as several variants of expressions for querying a relational database, such as Structured Query Language (SQL) expressions "," Select "and" subselect ", which sometimes allow a more nuanced behavior, but the Fetch Groups are missing.

In order to be able to carry out a meaningful performance analysis, it must be known, for example, which has priority over another. This is especially important in conflicting definitions. For example, in OpenJPA, prioritization is not documented and therefore needs to be determined through testing. Furthermore, in addition to the above-mentioned mechanisms, there are also gradations of the Eager Fetching behavior per se, which can be adapted:

1. It is possible to determine the depth with which the following relationships should be followed. Basically, Eager Fetching can not only load the object of the direct relationship, but also take into account other data objects that are related to the already reloaded object. It should be noted that this is not a binary setting, but one that should be gradually adjusted. Accordingly, several test cases are created for this scenario.

2. It is offered to influence the formulation of statements: Depending on the query, different join expressions or, alternatively, the separation into individual select expressions may have different effects on the resulting performance. Again, a setting is possible both in general and per query case.

The fact that the different configuration points can be combined with each other results in a large number of combinations that have to be taken into account in different test cases. The range of configuration options makes it clear that testing the fetching behavior is very useful.

So far, however, the existing documentation has been trusted and, in the case of performance problems, the behavior has been specifically investigated for the performance-critical case. As a result, tests have hitherto been performed at best individually for an integration case of a particular O / R imaging middleware. For economic use, however, this approach involves at least the following problems:

1. In the preparation step: For the application logic, the relevant relationships in the data model must be identified. This creates the special problem that the data model must first be analyzed when the data model and integration of the O / R imaging middleware are performed by different people. The analysis process is to identify the locations relevant to the fetching behavior in the data model.

2. In the test design: The setup of the tests must take into account several factors: There must be test cases depending on the relationship type, depth and configuration option of the

O / R imaging middleware are created. This requires temporary changes in code and configuration - purely for testing purposes. It also requires the creation of test data, which in most cases is more expensive than generating test data for functional tests, since the data must have sufficient depth in terms of relationships.

3. In the case of test execution: The evaluation of the tests in a manual way means the evaluation of the query expressions sent to the database - in the case of manual evaluation this is a time-consuming and error-prone process. In reality, query expressions are printed in standard output. In order for these to be associated with particular implementations in the application, the application must be modified to receive marks in the standard output. This, in turn, creates the risk that the application is unintentionally modified for testing the fetching behavior, or that marking instructions corresponding to the test are not removed from the application logic.

4. Infrastructure: If the underlying development project reaches a critical size, then the Installation, configuration and execution of the underlying software resources and time consuming. This means that to test the fetching behavior, software is automatically run that is not relevant to determining the results.

In addition, the previous procedures have no systematics. Test results from a use case can not basically be taken over for a new use case, since under certain circumstances the existing combinations differ in terms of configuration and data model.

The object of the present invention is to provide an efficient and correct functioning O / R imaging

To provide, inter alia, efficient and correct handling and operation of processes or processes and / or components or modules in industrial applications and / or products that use O / R imaging middleware.

The object is achieved by a test module having the features of claim 1, by a method having the features of claim 10, by a computer program product having the features of claim 19 and / or by a data carrier having the features of claim 20.

The subclaims specify further embodiments of the present invention.

The above object is achieved by means of a test module, wherein the test module is configured to test a middleware which is configured to mutually map object-oriented data of an object-oriented application and relational database relational data, the test module comprising: a data model module that specifies a data model for modeling relationship types of relational data models with respect to object-oriented data models; a test data module having test data, the test data being test data provided in accordance with a data model of the object-oriented application; a test case module having predetermined test cases for testing the middleware, the test cases having queries corresponding to data queries of the object-oriented application to the relational database via the middleware; and an analysis module configured to analyze results of the given test cases.

In this way, the present invention enables a systematization of previously implemented test methods dependent on specific application cases. That the present invention provides a methodology for application and / or product independent testing of O / R imaging middleware. In accordance with the present invention, testing the O / R imaging middleware is based on a data model that generally covers the relevant cases of fetching behavior.

In addition, the test module provides test cases that implement corresponding implementations according to the underlying object-oriented application to target fetching in the corresponding O / R mapping middleware.

According to one embodiment of the present invention, the data model is implemented in an object-oriented programming language.

According to a further exemplary embodiment of the present invention, the test data module has an object-oriented implementation of the test data. This allows a flexible and comprehensive handling of the data model and / or the test data with all the advantages of object-oriented programming.

According to an embodiment of the present invention, the test module is configured to apply the data model to the test data. In doing so, the relationships and structures contained in the test data are analyzed with regard to the relationship types of relational data models contained in the data model.

According to one exemplary embodiment of the present invention, the test module has a write-in module which is configured to transmit the test data for storage in the relational database via the middleware to the relational database.

In accordance with another embodiment of the present invention, the test case module is configured to query test data stored in the relational database using the test cases through the middleware.

In this way, the present invention allows the inventive application and / or product-independent approach of testing to be combined with concrete configurations of a concrete object-oriented application, a concrete middleware and / or a concrete relational database,

According to an embodiment of the present invention, the test case module is configured to analyze the test data retrieved by the middleware using the data model from the data model module and the test data from the test data module.

According to another embodiment of the present invention, the analysis module is configured to analyze results of the predetermined test cases using analysis results of the test case module. In this way, a multi-layered analysis of the mapping of relational data to object-oriented data on the test data is made possible.

According to an exemplary embodiment of the present invention, the analysis module is configured to provide results of the analyzes performed by the analysis module to a user of the test module.

In this way a structured output of the analysis results can be made possible, which enables a systematic analysis, evaluation and documentation of the tested middleware.

The above object is further achieved by a method for testing a middleware, wherein the middleware is configured to mutually map object-oriented data of an object-oriented application and relational data of a relational database, the method comprising:

Providing (and providing) a data model for modeling relationship types of relational data models with respect to object-oriented data models; Providing test data, the test data being test data provided according to a data model of the object-oriented application;

Providing predetermined test cases for testing the middleware, the test cases having queries corresponding to data queries of the object-oriented application to the relational database via the middleware; and analyzing results of the given test cases.

The method for testing a middleware also makes it possible to systematize previously implemented, dependent on specific use cases, implemented tests, as already described above with regard to the test module. The steps of the method generally correspond to the operations performed by the above-presented test module and / or the modules included in the test module. Therefore, the advantages of the features of the test module can also be listed in relation to the corresponding steps of the method introduced above.

According to another embodiment of the present invention, the test data is provided in the form of an object-oriented implementation.

According to an embodiment of the present invention, the method comprises applying the data model to the test data. In the process, the relationships and structures contained in the test data are analyzed with regard to the relationship types of relational data models.

According to an embodiment of the present invention, the method comprises transmitting the test data via the middleware for storing the test data in the relational database.

According to an embodiment of the present invention, the method comprises querying the test data stored in the relational database by the middleware using the test cases.

According to an embodiment of the present invention, the method comprises analyzing the test data queried by the middleware using the provided data model and the provided test data. According to an embodiment of the present invention, the method comprises analyzing results of the predetermined test cases using results of analyzing the test data retrieved by the middleware.

According to an embodiment of the present invention, the method comprises providing results of analyzing the results of the predetermined test cases.

The above object is also achieved by a computer program product having a coding configured to implement the method outlined above and explained in more detail below.

The coding can be contained in a data carrier. Further, the computer program product may be configured to perform the method when the computer program product is executed by a computing unit (e.g., a processor).

The above object is further achieved by means of a data carrier, wherein the data carrier has the computer program product explained above.

The present invention, particularly by providing a test module, provides significant time savings for the preparation, design, and performance of the tests and analysis of the test results. According to the known test methods, the infrastructure of the application must be provided for such tests, but this is not conceptually necessary for the tests. In large software projects this is associated with considerable resource expenditure and time losses. The present invention avoids or circumvents this problem. Thus, the present invention provides efficient O / R mapping middleware testing that is time efficient and resource efficient. Further, the present invention allows comparing the test results of different O / R imaging middleware solutions, as the testing is done in an application and / or product independent manner. Replacing the products will then reveal performance issues with each middleware.

In addition, preparation, design, testing, and analysis of results require expertise that is now made available throughout the test module. This no longer has to be done individually for each individual application.

Furthermore, the actual application in which an O / R mapping middleware is to be integrated is not affected by the tests. This rules out the possibility of accommodating unintentional modifications for analysis purposes, which can damage or disturb the actual application. Furthermore, the data in the database is not mixed with the test data because the tests use their own data, which can be separated from the actual application data and can then be deleted so that the application data remain unaffected by the deletion.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Show it:

1 shows a system with a conventional O / R imaging middleware; and

2 shows a system with a test module according to an embodiment of the present invention.

It is therefore important to ensure that the O / R mapping middleware 12 is working efficiently and correctly and that the O / R mapping middleware 12 does not sacrifice performance when mapping relational data to object-oriented data. When these conditions are met, safe, correct and efficient handling and operation of processes or processes and / or components or modules are ensured in an industrial application and / or in products.

This is achieved by the test device or by a test module 20. In this case, the test device or the

Test module 20, first, a data model module 201, which contains a data model for modeling relationship types of relational data models.

The data model covers various relationship types of relational databases that affect the fetching behavior of an O / R mapping middleware. Such relationship types are, for example, 1-to-1 relationships, 1-to-n relationships, n-to-m relationships. Furthermore, for example, illustrations of tables on classes and vice versa, treatment of attributes with complex types, mapping of associations and aggregations and / or mapping of inheritances by the data model are also discussed.

The data model is implemented in an object-oriented programming language. Optionally, the provision of standardized relational database system instructions may be necessary to establish the appropriate data structure. This part is not necessary in cases where the O / R mapping middleware provides a function of creating an appropriate relational data structure in the database from an existing data model on the object-oriented page.

The data model is an abstract data model that is general and not focused on concrete applications or products. It defines general principles of mapping the object-oriented data to relational data and vice versa. Furthermore, the test module 20 has a test data module 202 that is configured to provide test data. The test data are provided in such a way that they have the necessary scope to cope with the consequences of the set fetching

Being able to study behavior with different depths. That the test data is constructed for queries of varying depth, the queries corresponding to the queries actually transmitted from the object-oriented application via the O / R mapping middleware 12 to the relational database 13 to retrieve the data stored in the relational database 13 ,

The test data are entered via an object-oriented implementation of the test module 20 and represent exemplary object-oriented data of the concrete object-oriented application. The test data is used exclusively for testing the O / R imaging middleware 12. In this way, independence of the test module 20 from the O / R mapping middleware 12 used and the database system 13 used is established.

The data model contained in the data model module 201 is applied to the test data contained in the test data module 202. That the test data is analyzed for its object-oriented structure and relationships, and the Relational Relationship-General Data Model derives the relationships and structures necessary for O / R mapping, based only on the data model of the test module 20 or data model module

201 and not on the basis of the actually given model of the relational database 13 happens.

The test module 20 furthermore has a dubbing module 203, wherein the dubbing module 203 is configured to transmit the test data from the test data module 202 to the O / R imaging middleware 12, as would otherwise be done by the object-oriented application. Further, the test data is from the O / R imaging middleware

12 edited as specified and in the relational database

13 stored. Subsequently, the test data stored in the relational database 13 are queried by the test module 20 for test purposes. In doing so, the test module 20 sends queries that correspond to the queries sent by the object-oriented application.

For this purpose, the test module 20 has a test case module 204. The test case module 204 has ready-made test cases that can be tested for different aspects of a fetching setting. That the test cases provide queries for the test data, with the queries matching those of the object-oriented application. The test cases formulate data accesses to the relational database 13, wherein the data accesses are designed to cover the relevant places of the object-oriented data model and to trigger the fetching behavior of an O / R mapping middleware, depending on the configuration.

The test case module 204 obtains the test data, which is object-oriented data, from the test data module 202, results of the queries performed on test data in the relational database 13 from the O / R imaging middleware, and the data model of the data model module 201.

The test case module 204 establishes relationships between the obtained data which will help to determine how well the results on the queries made by the O / R blur middleware 12 correspond to the results actually desired or expected by the object-oriented application.

The test case module 204 detects query expressions to aid in the evaluation of the data obtained. The test module 20 outputs query expressions via a standard output. Since the output is structured according to the test cases, the Order of test cases and resulting query expressions for the purpose of evaluation possible. In this way, the evaluation is automated per test case. It is also possible to machine the query expressions and to provide the test results in an aggregated form.

In obtaining the results on queries regarding the test data, the O / R imaging middleware prepares a standard output (e.g., a log file) 21 which is analyzed by an analysis module 205. In this case, the data obtained in the test case module 204 and the findings made in the test case module 204 are taken into account.

The analysis module 205 provides its evaluations to the person involved in testing the O / R imaging middleware. From this, the person can make conclusions regarding the behavior and functioning of the O / R mapping middleware and possibly make improvements in the implementation of the O / R mapping middleware.

Thus, the present invention relates to testing of middleware configured to inter-map object-oriented data of an object-oriented application and relational data relational data. Testing is performed using a data model to model relational data model relationship types with respect to object-oriented data models, using test data that is test data provided according to a data model of the object-oriented application, using predetermined test cases to test the middleware, the test cases Have queries that correspond to data queries of the object-oriented application to the relational database via the middleware and performed by analyzing the results of the given test cases. The present invention relates in particular to applications with O / R

Mapping middleware and allows efficient and correct handling and operation of processes or processes and / or components or modules of an industrial sector or of products that depend on efficient and properly functioning O / R imaging middleware.

Although the invention is explained above with reference to the embodiment according to the accompanying drawings, it is to be understood that the invention is not limited to the embodiment but may be modified within the scope of the inventive idea disclosed above and in the appended claims. It goes without saying that there may be other embodiments which are the principle of the invention and are equivalent, and thus various modifications can be implemented without departing from the scope of the invention. Thus, e.g. the modules of the test module or the test device are designed differently, wherein a module can perform a plurality of functions according to the invention and / or a function according to the invention can be performed by a plurality of modules.

Claims

claims

A test module configured to test a middleware (12) configured to map object-oriented data of an object-oriented application (11) and relational data of a relational database (13), the test module (20) comprising: a data model Module (201) having a data model for modeling relationship types of relational data models with respect to object-oriented data models; a test data module (202) having test data, the test data being test data provided according to a data model of the object-oriented application (11); a test case module (204) having predetermined test cases for testing the middleware (12), the test cases comprising queries corresponding to data queries of the object-oriented application (11) to the relational database (13) via the middleware (12); and an analysis module (205) configured to analyze results of the predetermined test cases.

The test module of claim 1, wherein the data model is implemented in an object-oriented programming language.

3. Test module according to at least one of the preceding claims, wherein the test data module (202) has an object-oriented implementation of the test data.

4. Test module according to at least one of the preceding claims, wherein the test module (20) is configured to apply the data model to the test data.

5. test module according to at least one of the preceding claims, wherein the test module (20) a Einspielmodul (203) configured to transmit the test data for storage in the relational database (13) via the middleware (12) to the relational database (13).

A test module according to at least one of the preceding claims, wherein the test case module (204) is configured to query test data stored in the relational database (13) using the middleware (12) using the test cases.

The test module of claim 6, wherein the test case module (204) is configured to analyze the test data retrieved by the middleware (12) using the data model from the data model module (201) and the test data from the test data module (202).

The test module of claim 7, wherein the analysis module (205) is configured to analyze results of the predetermined test cases using analysis results of the test case module (204).

9. The test module according to claim 1, wherein the analysis module (205) is configured to provide results of the analyzes performed by the analysis module (205) to a user of the test module.

A method of testing a middleware (12) configured to map object-oriented data of an object-oriented application (11) and relational data of a relational database (13), the method comprising:

Providing a data model for modeling relationship types of relational data models with respect to object-oriented data models;

Providing test data, wherein the test data is test data provided according to a data model of the object-oriented application (11); Providing predetermined test cases for testing the middleware (12), the test cases comprising queries corresponding to data queries of the object-oriented application (11) to the relational database (13) via the middleware (12); and

Analyze results of given test cases.

11. The method of claim 10, wherein the data model is implemented in an object-oriented programming language.

12. The method of claim 10 or 11, wherein the test data is provided in the form of an object-oriented implementation.

The method of at least one of the preceding claims 10 to 12, wherein the method comprises applying the data model to the test data.

14. The method according to claim 10, wherein the method comprises transmitting the test data via the middleware to store the test data in the relational database.

15. The method of claim 1, wherein the method comprises querying the test data stored in the relational database by the middleware using the test cases.

The method of claim 15, wherein the method comprises analyzing the test data retrieved by the middleware (12) using the provided data model and the provided test data.

17. The method of claim 16, wherein the method comprises analyzing results of the predetermined test cases Using results of analyzing the queried by the middleware (12) test data.

18. The method of claim 10, wherein the method comprises providing results of analyzing the results of the predetermined test cases.

19. A computer program product having an encoding configured to implement a method according to claim 10.

20. Data carrier, wherein the data carrier comprises a computer program product according to claim 19.