A) TECHNICAL FIELD

[0001] The present invention generally relates to embedded system and software and particularly to the development of testing applications in embedded system and software. The present invention more particularly relates to a test execution framework for the development of testing applications in embedded system and software.

B) BACKGROUND OF THE INVENTION

[0002] Testing of software applications for products is a major role of the product development cycle in the field of embedded system and software. For that, the system for testing of software applications is to be well suited and equipped to do the testing of software applications. When there are a huge pile of test cases to get through, the automation of the testing activity of embedded systems becomes more essential than just an option. Test executives are used for the purpose of the automation of the testing of software applications. The test executives are computer application programs.

[0003] Generally the test executives work as test sequence runners. The test executives execute tests one by one in a sequence, validate the results and log the results into the database or into a result log. Then the test executives generate pass or fail reports. But the need of existing test system is more than just running the tests. There is a need for analysis of data such as the data gathered over a period of testing (for a single sample) or the data collected for a collection of product samples and so on. The analysis of the logged data would be used by the user to validate the performance of the products. So, based on this, the choice of different testing tools needed for the purposes like testing, database, analysis etc., becomes an additional task by itself

[0004] The existing test executives are only available with single application interface. Normally the available test executives are developed as customized test executives with a specific application having a Graphical User Interface (GUI). Further to this the existing test executives have a fixed interoperability only. This means that when the test executive installation is interoperable with a set of other applications, an upgraded version of the test executive needs to be installed which supports the new applications, in order to expand the interoperability to work with other new applications..

[0005] For example, the need for testing in a development cycle of a product is in two forms: they are (a) plan based product testing and; (b) product diagnostics and troubleshooting. The plan based product testing is the defacto form of testing. The plan based product testing includes pre-defmed test cases against the product which is to be tested. Then the results of the performance of the product is logged and worked on.
[0006] The product diagnostics and troubleshooting is more like a non-preplanned testing and is mostly semi-automated. Though the product diagnostics and troubleshooting is more useful during the design and development phase, at times, based on the results of the plan based product testing, some kinds of diagnosis and troubleshooting need to be done. Having all the basic features equipped for the plan based product testing, the user should also be able to occasionally modify and support manual diagnosis during the development phase.

[0007] As one more example, there are various hardware black box validation test scenarios in the testing segment of development life cycle of a product. The various hardware black box validation test scenarios are broadly classified as comprehensive fiinctional parametric tests and limited functionality tests. The comprehensive fionctional parametric tests are used in design validation and product validation. The limited functionality tests are mainly used during product validation for environmental tests where there is a need for quick sanity checks. Limited functionality testing is employed mostly for constant monitoring of the product's stability during environmental testing and runs in endless loops for the entire duration of the environmental testing constantly maintaining logs. In some scenarios the test executive intelligently performs auto recovery actions on the product when the products operation stalls. Also there is a need for multiple features in test application mostly unique to certain groups of tests. In this way there a many more custom requirements of the user which the test executive should cater to. For this purpose to be achieved the test executive needs to be flexible in nature.

[0008] The task of including all possible features into one application would not only be complex but almost impossible. Also the task of including all features into one test application to cater to all possible test environments is an over load on the test application from the point of view of the Personal Computer's (PC) resources point and makes the task of managing the menus and options hard for a developer of the test application. Yet another issue that arises while trying to put all features in one application is that complexity increases and lessens its user-friendliness. This is simply because all tests may not use all the provided features, since each test may use a fraction of the provided features only. It would be desired to provide a test application installed with all the features, but while the test application is running, only the required features need to be loaded on need to use basis.

[0009] There is a need for a testing tool that meets all these requirements and ensures that the automation testing covers maximum of the test cases. In addition to this looking from the point of maintainability of the test platform it would be desirable to provide a testing tool that can be modified for the future requirements. At the same time, the need for unforeseen features should be satisfied by the ability to provide the need later on to the deployment of the fundamental package. Hence there is a requirement to provide the test executives having a variety of features and the test executives which are flexible in nature and yet be simple for the user to use.

[0010] The above mentioned shortcomings, disadvantages and problems are addressed herein and which will be understood by reading and studying the following specification.

C) OBJECTS OF THE INVENTION

[0011] The primary object of the present invention is to develop a test execution framework to configure and construct custom computer applications suited for the development of testing applications in embedded system and software.

[0012] Another object of the present invention is to develop a test execution framework installed with many features to only load the required features on the need to use basis when the test application is run.

[0013] Yet another object of the present invention is to develop a test execution framework providing scalable modularity for the framework for customization and expansion of any test application created from the framework.

[0014] Yet another object of the present invention is to develop a test execution framework including features such as programmer friendly interfacing, cross component compatibility, version compatibility feature and so on.

[0015] Yet another object of the present invention is to develop a flexible test execution framework that can be modified for the future requirements.

[0016] These and other objects and advantages of the present invention will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings.

D) SUMMARY OF THE INVENTION

[0017] The various embodiments of the present invention provide a test execution framework to configure and construct custom computer applications suited for the development of testing applications in embedded system and software. According to one embodiment of the present invention, an embedded system and software Test Executive (EmTex) is a computer application framework used to configure and construct the custom computer applications suited for testing of the applications. One or more applications with the required tool modules for the EmTex are developed based on the requirements to provide test executive solutions.

[0018] The design of EmTex is based on modules and an environment. The modules are the building blocks of the EmTex application. The environment is created for the modules to function and interact with each other. The computer application framework implements the environment to load and manage the modules. The computer application framework includes fundamental modules such as scripting modules, Graphical User Interface (GUI) modules, test executive modules, test database modules, simulated modules, intermediate modules, hardware driver modules and so on. An interfacing mechanism is provided for the interaction between modules. A set of rules is designed for externally developed modules to be identified and integrated with the application. The features required for building a test executive application are created as external modules and integrated to form a custom application.
[0019] Every application of the EmTex is started in an environment which is known as a workspace. The workspace has a core module of its own and various kinds of modules that build the application of the EmTex. All the management activity of the workspace is achieved by the core module. The core module provides one point interface for all the dynamically loaded modules in the core module. The modules interface to each other using the core module. There are some modules designed as add-on modules and they are known as tools. The tools are essential templates. The tools may be instantiated to form the dynamic modules. The tool may be a GUI panel, a communication bus, a logger or a sequencer. The framework is an add-on based architecture. Hence all features in the framework are broken down into the tools. A tool can be developed separately and deployed to integrate with the existing EmTex installation. The tools can be instantiated as objects into the workspace.

[0020] The instantiated objects in the workspace are termed as dynamic modules. The dynamic modules at the root level of the core module are known as integrants. The workspace includes some other modules known as static libraries in the workspace. All the modules in the workspace interact wdth each other based on the user settings. The workspace and configurations of the workspace such as essential settings of the all the modules in the workspace are serialized and saved into a file (or in to multiple files with one root file) known as a project. Thus the EmTex has a unique architecture that helps in building configurable test executive application programs.

[0021] The installation of EmTex is available with a range of libraries. The installation of EmTex is used to suite for various choices of the test users. The libraries are built in the form of executable file extensions (i.e. '.exe' file format) and dynamic link libraries files (i.e. '.dll' file format) and other configuration files. These library files include Graphical User Interface (GUI) panels, instrument interfaces or driver modules, Personal Computer (PC) resource interfaces, scripting engines, test tools (such as test sequencers, result loggers), diagnostic tools (such as trace loggers, diagnostic GUI panels), protocol handlers and services, Integrated Test Development Environment (ITDE) applications and so on. In addition, the EmTex is designed with customized features to cater to specific requirements.

[0022] The test-developer uses only the required modules based on the test environment where in the required modules are supposed to be operated. Then the test-developer develops the tests. Also, the concept of the tools in EmTex allows different flavors of the same kind of modules to be developed and used as per user preferences. Hence the need for modifying the entire application is eliminated just for the sake of one feature.
[0023] The EmTex caters to delayed deployment. The tools in the EmTex are developed independent of the basic development. The tools may need to only hold reference to the fundamental Dynamic Link Library (DLL) of the EmTex. At run time, the framework is designed to search and find the tools. If a newly developed DLL exists in the search path of the core, the EmTex loads the newly developed DLL and automatically adds the newly developed DLL into the available tools in the tool box list of the EmTex,

[0024] The search path for the tools can also be customized based on the application and hence the search can be made custom to the project. So that it is possible to keep certain DLL specific to the project in the project path. Also the tools in that certain DLL are only used by the project and the tools are not available to any other projects.

[0025] Based on the environment required to be tested, the user chooses the required tools to build the test application. The selected required tools are loaded into the workspace and each of the selected required tools is configured appropriately. The workspace and configurations of the workspace are saved into a file with extension of \etx'. This file is loaded at the time of testing the application.

E) BRIEF DESCRIPTION OF THE DRAWINGS:

[0026] The other objects, features and advantages will occur to those skilled in the art from the following description of the preferred embodiment and the accompanying drawings in which:

[0027] FIG. 1 illustrates a functional block diagram of the basic structure of an embedded system and software Test Executive (EmTex) computer application framework according to one embodiment of the present invention.

[0028] FIG. 2 illustrates a functional block diagram of various modules integrated on need to use basis in an embedded system and software Test Executive (EmTex) computer application framework, according to one embodiment of the present invention.

[0029] FIG. 3 illustrates a functional block diagram of an example test execution framework application loaded with the required tools according to one embodiment of the present invention.

[0030] FIG. 4 illustrates a functional block diagram of an example test execution framework application with addition of a new module in the workspace according to one embodiment of the present invention.

[0031] FIG. 5 illustrates a functional block diagram of an example test execution framework application with addition of a new feature in the workspace according to one embodiment of the present invention.

[0032] Although the specific features of the present invention are shown in some drawings and not in others. This is done for convenience only as each feature may be combined with any or all of the other features in accordance with the present invention.

F) DETAILED DESCRIPTION OF THE INVENTION

[0033] In the following detailed description, a reference is made to the accompanying drawings that form a part hereof, and in which the specific embodiments that may be practiced is shown by way of illustration. These embodiments are described in sufficient detail to enable those skilled in the art to practice the embodiments and it is to be understood that the logical, mechanical and other changes may be made without departing from the scope of the embodiments. The following detailed description is therefore not to be taken in a limiting sense.

[0034] The various embodiments of the present invention provide a test execution framework for the development of testing applications in embedded system and software. According to one embodiment, an Embedded system and software Test Executive (EmTex) is a computer application framework. The EmTex is used to configure and construct the custom computer applications suited for testing of the applications. One or more applications with the required tool modules for the EmTex are developed based on the requirements to provide test executive solutions.

[0035] The design of EmTex is based on modules and an environment. The modules are the building blocks of the EmTex application. The environment is created for the modules to function and interact with each other. The computer application framework implements the environment to load and manage the modules. The computer application framework includes fundamental modules such as scripting modules, Graphical User Interface (GUI) modules, test executive modules, test database modules, simulated modules, intermediate modules, hardware driver modules and so on. An interfacing mechanism is provided for the interaction between modules. A set of rules is designed for extemally developed modules to be identified and integrated with the application. The features required for building a test executive application are created as external modules and integrated to form a custom application.

[0036] Every application of the EmTex is started in the environment which is known as a workspace. The workspace has a core module of its own and other various kinds of modules that build the application of the EmTex. All the management activity of the workspace is achieved by the core module. The core module provides one point interface for all the dynamically loaded modules in the core module. The modules interface to each other using the core module. There are some modules designed as add-on modules and they are known as tools. The tools are analogous to the templates. The framework is an add-on based architecture. Hence all features in the framework are broken down into the tools. In a workspace the tools reside in a toolbox and may be instantiated to form the dynamic modules. The tool may be a GUI panel, a communication bus, a logger or a sequencer. The tool is developed separately and deployed to integrate with the existing EmTex installation. The tools are instantiated as objects into the workspace.

[0037| The instantiated objects in the workspace are termed as dynamic modules. The dynamic modules at the root level of the core module are known as integrants. The workspace includes some other modules known as static libraries. All the modules in the workspace interact with each other based on the user settings. The workspace and configurations of the workspace such as essential settings of the all the modules in the workspace are serialized and saved into a file known as a project. Thus the EmTex has a unique architecture that helps in building configurable test executive application programs.
[0038] The installation of EmTex is available with a range of libraries. The installation of EmTex is used to suite for various choices of the test users. The libraries are built in the form of executable file extensions (i.e. '.exe' file format), dynamic link libraries files (i.e. *.dir file format) and other configuration files. These library files include Graphical User Interface (GUI) panels, instrument interfaces or driver modules, Personal Computer (PC) resource interfaces, scripting engines, test tools (such as test sequencers, result loggers), diagnostic tools (such as trace loggers, diagnostic GUI panels), protocol handlers and services, Integrated Test Development Environment (ITDE) applications and so on. In addition, the EmTex is designed with customized features to cater to specific requirements.

[0039| The test-developer uses only the required modules based on the test environment in where the required modules are supposed to be operated. Then the test-developer develops the tests. Also, the concept of the tools in the EmTex allows different flavors of the same kind of modules to be developed and used as per the user's preferences. Hence the need for modifying the entire application is eliminated just for the sake of one feature.
[0040] The EmTex caters to delayed deployment. The tools in the EmTex are developed independent of the basic development. The tools only hold reference to the fundamental Dynamic Link Library (DLL) of the EmTex. At run time, the framework is designed to search and find the tools. If a newly developed DLL exists in the search path of the core, the EmTex loads the newly developed DLL and automatically adds the newly developed DLL into the available tools in the tool box list of the EmTex.

[0041] The search path for the tools is also customized based on the application and hence the search is made custom to the project. So that it is possible to keep certain DLL which is specific to the project, in the project path. Also the tools in that certain DLL are only used by the project and the tools are not available to any other projects.
[0042] Based on the environment required to be tested, the user chooses the required tools to build the test application. The selected required tools are loaded into the workspace and each of the selected required tools is configured appropriately. The workspace and configurations of the workspace are saved into a file with extension of '.etx'. This file is loaded at the time of testing the application.

[0043] For example, the user instantiates a Controller Area Network (CAN) bus, a test sequence, a test sequence tool bar and so on. Then the user adds some CAN tests to the test sequence and run the CAN tests to obtain suitable resuhs. If the user later wants to observe the messages that are transacted on the CAN, the user adds another module such as a CAN trace window to the workspace and links the added module to a CAN bus. Then the user is able to view the messages on the CAN bus. In this way the needed modules are added to the workspace to construct the test application.

[0044] If suppose another required feature say, a Key Word Protocol (KWP) Service which is a KWP protocol handler that works on CAN is not available in the tool box. This KWP module is developed separately and deployed to operate with the existing package. On execution of the tool box, the newly added DLL is automatically recognized. The available tools in the DLL are displayed to the user. Then the user

instantiates the KWP module as an object in to the existing workspace. Links it to the existing CAN module and uses it to perform the required KWP tasks. In this way, the new features are later added separately without disturbing the existing installation.
[0045] The EmTex is developed in a programming language (for example, C#.Net programming language) using a software framework (for example, .Net 3.5) as the base platform. The base library and the features of the EmTex are programmed using the integrated development environment applications (for example, visual studio-2008). Since the .Net platform is being the base platform, it is capable to extend the interoperability of the EmTex with many other languages and applications such as Visual Basic .Net, Iron Pj^hon .Net, NI LabView, NI TestStand, Matlab and so on.

[0046] FIG. 1 illustrates a functional block diagram of the basic structure of an Embedded system and software Test Executive (EmTex) computer application framework according to one embodiment of the present invention. With respect to FIG. 1, the design of Embedded system and software Test Executive (EmTex) computer application framework is based on modules and an environment. The modules are the building blocks of the EmTex application. Every application of the EmTex is started in the environment which is known as a workspace 102. The workspace 102 is created for the modules to function and interact with each other. The computer application framework implements the workspace 102 to load and manage the modules. An interfacing mechanism is provided for the interaction between modules. A set of rules is designed for externally developed modules to be identified and integrated with the application. The features required for building a test executive application are created as external modules and integrated to form a custom application.

[0047] The workspace 102 has a core module 104 of its own and various kinds of modules that build the application of the EmTex. All the management activity of the workspace 102 is achieved by the core module 104. The core module 104 provides one point interface for all the dynamically loaded modules in the core module 104. The modules interface to each other using the core module 104. The workspace includes a user interface module 106. There are some modules designed as add-on modules and they are known as tools 108. In the workspace tools are grouped under a tool box. The tools 108 are analogous to the templates. The framework is an add-on based architecture. Hence all features in the framework are broken down into the tools 108. The tools 108 may be instantiated to form the dynamic modules. The tool 108 may be a GUI panel, a communication bus, a logger or a sequencer. The tool 108 is developed separately and deployed to integrate with the existing EmTex installation.

[0048] The tools 108 are instantiated as objects into the workspace. The instantiated objects in the workspace 102 are termed as dynamic modules. The dynamic modules at the root level of the core module are known as integrants 110. The workspace 102 includes some other modules known as libraries 112 in the workspace 102. The libraries 112 are static libraries. The installation of EmTex is available with a range of libraries 112. The libraries 112 are built in the form of executable file extensions (i.e. '.exe' file format), dynamic link libraries files (i.e. '.dlP file format) and other configuration files. The files in the library 112 include and are not limited to Graphical User Interface (GUI) panels, instnmient interfaces or driver modules. Personal Computer (PC) resource interfaces, scripting engines, test tools (such as test sequencers, result loggers), diagnostic tools (such as trace loggers, diagnostic GUI panels), protocol handlers and services. Integrated Test Development Environment (ITDE) applications and so on.

[0049] All the modules in the workspace 102 interact with each other based on the user settings. The workspace 102 and configurations of the workspace 102 such as essential settings of the all the modules in the workspace 102 are serialized and saved into a file known as a project. Thus the EmTex has a unique architecture that helps in building configurable test executive application programs.

[0050] FIG. 2 illustrates a functional block diagram of various modules integrated on need to use basis in an Embedded system and software Test Executive (EmTex) computer application framework, according to one embodiment of the present invention. With respect to FIG, 2, the Embedded system and software Test Executive (EmTex) computer application framework includes fundamental modules which are the building blocks of the EmTex application. The EmTex computer application framework includes fundamental modules such as scripting modules 202, Graphical User Interface (GUI) modules 204, test executive modules 206, test database modules 208, simulated modules 210, intermediate modules 212 and hardware driver modules 214. All the modules are integrated in the EmTex application on need to use basis. An interfacing mechanism is provided for the interaction between the modules. A set of rules is designed in the EmTex computer application framework for externally developed modules to be identified and integrated with the application. The features required for building a test executive application are created as external modules and integrated to form a custom application.
[0051] FIG. 3 illustrates a functional block diagram of an example test execution framework application loaded with the required tools according to one embodiment of the present invention. With respect to FIG. 3, the EmTex computer application framework includes workspace tools 302 which are developed independent of the basic development. The workspace tools 302 only hold reference to the fundamental Dynamic Link Library (DLL) of the EmTex. The workspace tools 302 include tools such as a test sequence User Interface (UI) tool bar 306, a test sequence 308, a test database 310, a Communication (COM) port 312, a COM trace 314, a General Purpose Interface Bus (GPIB) socket 316, a telnet American Standard Code for Information Interchange (ASCII) Command Line Interface (CLI) 318, Controller Area Network (CAN) tests 320, a virtual CAN bus 322, a soft CAN port 324, a National Instruments (NI) CAN port 326, a vector CAN port 328 and a CAN trace 330. A user instantiates the required tools like the test sequence UI tool bar 306, the test sequence 308, the virtual CAN bus 322 and the vector CAN port 328 in workspace integrants 304 based on the environment required to be tested. The selected required tools are loaded into the workspace and each of the selected required tools is configured appropriately. Then the user adds the CAN tests 320 to the test sequence 308 and run the CAN tests 320 to obtain suitable results. The workspace and configurations of the workspace are saved into a file with extension of '.etx'. This file is loaded at the time of testing the application.

[0052] FIG. 4 illustrates a functional block diagram of an example test execution framework application with addition of a new module in the workspace according to one embodiment of the present invention. With respect to FIG. 4, the user adds another module such as a CAN trace window 402 to the workspace integrants 304, when the user later wants to observe the messages that are transacted on the CAN.

The CAN trace window 402 is linked to the virtual CAN bus 322. So that the user is able to view the messages on the virtual CAN bus 322. In this way the needed modules are added to the workspace to construct the test application in the EmTex computer application framework which caters to the delayed deployment.

[0053] FIG. 5 illustrates a functional block diagram of an example test execution framework application with addition of a new feature in the workspace according to one embodiment of the present invention. With respect to FIG. 5, a KWP panel 502, a KWP service 504 and CAN KWP tests 506 are developed separately and added in the workspace tools 302 to operate with the existing package. On execution of the workspace tools 302, the newly added file CAN KWP.dll 508 is automatically recognized by the EmTex computer application Iramework and the file CAN KWP .dll 508 is available in the workspace tools 302 to the user. Then the user instantiates the KWP module as an object in to the existing workspace integrants 304 and uses the KWP module to perform the required KWP tasks. Thus a KWP Service 510 which is a KWP protocol handler is later added as a new feature in the EmTex computer application framework. In this way, the new features are later added separately without disturbing the existing installation in the EmTex computer application framework.

G) ADVANTAGES OF THE INVENTION

[0054] The various embodiments of the present invention provide a test execution framework for the development of testing applications in embedded system and software. The test execution framework provides scalable modularity for the framework for customization and expansion of any test application created from this framework. The test execution framework is built with a programmer friendly interfacing. The framework is intuitive enough, so that the programmer is able to understand and make use of the components of the framework in an efficient and easy way. Further the programmer develops a separate GUI interface based on the custom requirement with the EmTex framework at the rear end.

[0055] The test execution framework includes a feature called as cross component compatibility. The cross component compatibility is applicable only to the certain
components of the framework wherein the interfaces of a component appear similar to their other variants. This is done by implementing generic interfacing norms. For example, making the NICAN and Vector CAN module both appear similar from programmers' interfacing point of view. Further the test execution framework provides version compatibility feature to achieve simplified compatibility between versions of library releases. Thus the test execution framework is a flexible framework and is useful for test executive applications in the embedded system and software.
[0056] The test execution framework is basically used to design test applications for products that are embedded devices and for domains such as industrial automation, automotive, avionics etc. The test execution framework is also used in black box testing of hardware as well as software for the embedded devices. The test execution framework has a unique architecture that helps in building configurable test executive application programs to suite the user's needs.

[0057] Although the invention is described with various specific embodiments, it will be obvious for a person skilled in the art to practice the invention with modifications. However, all such modifications are deemed to be within the scope of the claims.
[0058] It is also to be understood that the following claims are intended to cover all of the generic and specific features of the present invention described herein and all the statements of the scope of the invention which as a matter of language might be said to fall there between.


CLAIMS

What is claimed is:

1. A test execution framework system for the development of testing applications in embedded system and software, comprising: a workspace having a core module; and a plurality of modules; wherein the workspace is created to load and manage the modules to function and interact with each other based on a user's settings.

2. The system according to claim 1, wherein the modules interface to each other using the core module.

3. The system according to claim 1, wherein the required modules are selected by the user based on the test environment in where the required modules are supposed to be operated.

4. The system according to claim 1, wherein the core module provides one point interface for all the dynamically loaded modules in the workspace.

5. The system according to claim 1, wherein the modules are scripting modules. Graphical User Interface (GUI) modules, test executive modules, test database modules, simulated modules, logging modules, intermediate modules, hardware driver modules.

6. The system according to claim 1, wherein the modules are designed as add-on modules are tools.

7. The system according to claim 1, wherein the tools are developed independent of the basic development.

8. The system according to claim 1, wherein the tools hold a reference to the fundamental Dynamic Link Library.

9. The system according to claim 1, wherein the tools are analogous to the templates.

10. The system according to claim 1, wherein the tool is a Graphical User Interface panel, a communication bus, a logger or a sequencer.

11. The system according to claim 1, wherein the tools in the certain DLL are used by a particular assigned project only.

12. The system according to claim 1, wherein newly developed tools in the search path of the core are automatically added into the available tools during the execution.

13. The system according to claim 1, wherein the tools are instantiated as objects into the workspace.

14. The system according to claim 1, wherein the instantiated objects in the workspace are dynamic modules.

15. The system according to claim 1, wherein the dynamic modules at the root level of the core module are integrants.

16. The system according to claim 1, wherein the workspace includes the modules such as libraries.

17. The system according to claim 1, wherein the libraries are built in the form of executable file extensions, dynamic link libraries files and other configuration files.

18. The system according to claim 1, wherein the library files include Graphical User Interface panels, instrument interfaces or driver modules, Personal Computer resource interfaces, scripting engines, test tools, diagnostic tools. protocol handlers and services and Integrated Test Development Environment applications.

19. The system according to claim 1, wherein the workspace and configurations of the workspace such as essential settings of the all the modules in the workspace are serialized and saved into a file (or multiple files with one root file) known as project file.

20. The system according to claim 1, wherein the modules which are created as external modules based on the features required for building a test executive application are integrated in the workspace to form a custom application.

21. The system according to claim 1, further comprises an interfacing mechanism for the interaction between modules.

22. The system according to claim I, further comprises a set of rules designed for externally developed modules to be identified and integrated with the application.