Model Based Testing – MBT
Model-based testing or MBT is a general term that signifies an approach that bases common testing tasks such as test case generation and test result evaluation on a model of the application under test.
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.
» Filed Under Featured, General Testing Concepts, Headline | 1 Comment
Run QTP framework in quality center
If you have made an excel driven framework in QTP which runs on the local machine and now want to run it from quality center as well without making major changes in the script, then this post is for you.
In this scenario, you can download QTP files from quality center using QC-OTA.
Create folders/subfolders on the drives using vbs and download the appropriate files that are attached to a testset / testsetfolder etc.
Keywords for OTA:-
- AttachmentFactory
- Attachment
- ExtendedStorage
- TestSetFolder
- TestSetFactory
- TestSet
There is one more way to do the same. You need to save the QTP script in Quality Centre and run it from there under the test set.
To save the attachment as the attachment of the test run, here is the code:
File in file system to attach:
SaveAttachment “C:\BusServiceMVI_IT_OT_QTP8_081506.xls”, “Test Description”
Public Sub SaveAttachmentToTestObj(TestObj, LocalFilePath, FileDescription)
Set Attachments = TestObj.Attachments
Set Attachment = Attachments.AddItem(Null)
Attachment.FileName = LocalFilePath
Attachment.Description = FileDescription
Attachment.Type = 1′TDATT_FILE
Attachment.Post ‘ Commit changes
End Sub
This function saves an attachment to the current test (the test must be existing on TestDirector).
LocalFilePath: Path indicating the location of the attachment on the local filesystem
FileDescription: Description of the file (Description field on TestDirector)
Public Function SaveAttachment(LocalFilePath, FileDescription)
SaveAttachmentToTestObj QCUtil.CurrentTest, LocalFilePath, FileDescription
End Function
Just remember, all you need is QTP and access to a project created in quality Center. This is all that is required. Rest can be done by the code.
» Filed Under QTP, Quality Center | 2 Comments
Designing Test Object Configuration XML File in QTP
In this file, you define any custom test object classes that you want QTP to use to represent your custom controls in tests and components. Define a test object class for each custom control that cannot be adequately represented by an existing Delphi test object class.
In a test object configuration XML, you define the test object classes (for example, their identification properties, the test object methods they support, and so on). To do this you define a ClassInfo element for each test object class. In addition, you define the name of the environment or custom toolkit for which the test object classes are intended (in the TypeInformation\PackageName attribute), and the QTP add-in which these test object classes extend (in the TypeInformation\AddinName attribute). If the relevant add-in is not loaded when QTP opens, QTP does not load the information in this XML. Similarly, if the name of the environment or custom toolkit is displayed in the Add-in Manager dialog box and its check box is not selected, the information in this XML is not loaded.
A test object class definition can include the following:
- The name of the new test object class and its attributes, including the base class—the test object class that the new test object class extends. The test object class name must be unique among all of the environments whose support a QTP user might load simultaneously.
- The generic type for the new test object class, if you want the new test object class to belong to a different generic type than the one to which its base class belongs. (For example, if your new test object class extends DelphiObject (whose generic type is object), but you would like QTP to group this test object class with the edit test object classes.)
- The path of the icon file to use for this test object class (Optional. If not defined, a default icon is used.) The file can be a .dll or .ico file.
- A context-sensitive Help topic to open when F1 is pressed for the test object in the Keyword View or Expert View. The definition includes the Help file path and the relevant Help ID within the file.
- A list of methods for the test object class
- The test object operation that is selected by default in the Keyword View and Step Generator when a step is generated for an object of this class.
- A list of identification properties for the test object class
Note: You can also create a definition for an existing test object class in the test object configuration XML. This definition is added to the existing definition of this test object class, affecting all test objects of this class. It is therefore not recommended to modify existing test object classes in this way.
If you add a test object method, it appears in the list of test object methods in QTP, but if you use the test object method in a test, and it is not implemented for the specific object, a run-time error occurs.
If you add test object methods to existing test object classes, you might add a prefix to the method name that indicates the toolkit support for which you added the method (for example, CustomButtonClick, CustomEditSet). This enables test designers to easily identify the custom methods and use them in test steps only if they know that the custom method is supported for the specific object.
» Filed Under QTP | Leave a Comment
