1. In Visual C, create a new project – dynamic link library (dll). Select File > New and click the Projects tab.
2. In the Wizard, select empty dll
3. Add a new cpp file with 3 exported function: init, run, end
4. Add library file lrun50.lib
5. Select the C/C++ tab and select Code generation (Category) > Use Run Time library (List). Change it to: Multithreaded dll
6. Select the C/C++ tab and select Preprocessor (Category) > Preprocessor definitions (edit field) Remove _DEBUG
7. Add code from your client application, or program as you normally would
8. Enhance your script with Vuser API functions. For example, lr_output_message to issue messages, lr_start_transaction to mark transactions, and so forth
9. Build the project. The output will be a DLL
10. Create a directory with the same name as the DLL and copy the DLL to this directory
11. In the lrvuser.usr file in the Template directory, Update the USR file key BinVuser with the DLL name: BinVuser=<DLL_name>

In the following example, the lr_output_messsage function issues messages indicating which section is being executed. The lr_eval_string function retrieves the name of the user. To use the following sample, verify that the path to the Vuser API include file, lrun.h is correct

#include “c:\lrun_5\include\lrun.h”

extern “C” {

int __declspec(dllexport) Init (void *p)

{

lr_output_message(“in init”);

return 0;

}

int __declspec(dllexport) Run (void *p)

{

const char *str = lr_eval_string(“<name>”);

lr_output_message(“in run and parameter is %s”, str);

return 0;

}

int __declspec(dllexport) End (void *p)

{

       lr_output_message(“in end”);

return 0;

}

} //extern C end

Model-based testing involves developing and using a data mode to generate tests. The model is essentially a specification of the inputs to the software. The suite includes inputs, expected outputs and necessary infrastructure to run the tests automatically. Testers using MBT approach concentrate on a data model and genration infrastructure instead of hand crafting individual tests.

It is essentially meant for functional testing and is a black box testing technique.

MBT is based on the premise that the reliability of the test process that can ensure the high quality of software demands that the test cases be derived form functional specifications. The test cases should guarantee that the functionality called out in specifications is completely covered and that the application can be fully excercised through execution of test cases. If testers can indeed develop such test cases directly from functional specifications, the at least functional specifications can not be faulted for corresponding deficiency in the application and it can be reasonably hoped that the desired functionality may have been sucessfully translated into the delivered application. MBT models tests based on the specifications.

MBT separates the testing logic from the actual test implemantation. This allows the developer to focus on developing good tests specific to the application while relying on the automation tool’s test execution environment to solve problems related to test execution.

MBT has as its roots applications in hardware testing, most notably telephone switched and recently has spread to a wide variety of software domains.

MBT is directly applicable for supporting mission critical applications, in fact MBT becomes imperative. NASA and the Europe space agency have already implemented model based testing.

There is promising future for MBT as software becomes even more ubiquitous and quality becomes the only distinguishing factor between brands. Modelling in general seems to be gaining favour particularly in domains where quality is essential and less than adequate software is not an option.

MBT is a natural choice for testers concerned about completeness, effectiveness and efficiency.