KabInfo.Net                                     

Q. Checking Bitmaps:
A. You can check an area of a Web page or application as a bitmap. While creating a test or component, you specify the area you want to check by selecting an object. You can check an entire object or any area within an object. QuickTest captures the specified object as a bitmap, and inserts a checkpoint in the test or component. You can also choose to save only the selected area of the object with your test or component in order to save disk space.
When you run the test or component, QuickTest compares the object or selected area of the object currently displayed on the Web page or application with the bitmap stored when the test or component was recorded. If there are differences, QuickTest captures a bitmap of the actual object and displays it with the expected bitmap in the details portion of the Test Results window. By comparing the two bitmaps (expected and actual), you can identify the nature of the discrepancy. For more information on test results of a checkpoint, see Viewing Checkpoint Results.
For example, suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. You can record the new map that is displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, you can check that the map zooms in correctly.
You can create bitmap checkpoints for all supported testing environments (as long as the appropriate add-ins are loaded).
Note: The results of bitmap checkpoints may be affected by factors such as operating system, screen resolution, and color settings.
 

Q. Text/Text Area Checkpoint .

A. In the Text/Text Area Checkpoint Properties dialog box, you can specify the text to be checked as well as which text is displayed before and after the checked text. These configuration options are particularly helpful when the text string you want to check appears several times or when it could change in a predictable way during run sessions.

Note: In Windows-based environments, if there is more than one line of text selected, the Checkpoint Summary pane displays [complex value] instead of the selected text string. You can then click Configure to view and manipulate the actual selected text for the checkpoint.

QuickTest automatically displays the Checked Text in red and the text before and after the Checked Text in blue. For text area checkpoints, only the text string captured from the defined area is displayed (Text Before and Text After are not displayed).

To designate parts of the captured string as Checked Text and other parts as Text Before and Text After, click the Configure button. The Configure Text Selection dialog box opens

Checking XML :

XML (Extensible Markup Language) is a meta-markup language for text documents that is endorsed as a standard by the W3C. XML makes the complex data structures portable between different computer environments/operating systems and programming languages, facilitating the sharing of data.

XML files contain text with simple tags that describe the data within an XML document. These tags describe the data content, but not the presentation of the data. Applications that display an XML document or file use either Cascading Style Sheets (CSS) or XSL Formatting Objects (XSL-FO) to present the data.

You can verify the data content of XML files by inserting XML checkpoints. A few common uses of XML checkpoints are described below:

An XML file can be a static data file that is accessed in order to retrieve commonly used data for which a quick response time is needed—for example, country names, zip codes, or area codes. Although this data can change over time, it is normally quite static. You can use an XML file checkpoint to validate that the data has not changed from one application release to another.
An XML file can consist of elements with attributes and values (character data). There is a parent and child relationship between the elements, and elements can have attributes associated with them. If any part of this structure (including data) changes, your application's ability to process the XML file may be affected. Using an XML checkpoint, you can check the content of an element to make sure that its tags, attributes, and values have not changed.
XML files are often an intermediary that retrieves dynamically changing data from one system. The data is then accessed by another system using Document Type Definitions (DTD), enabling the accessing system to read and display the information in the file. You can use an XML checkpoint and parameterize the captured data values in order to check an XML document or file whose data changes in a predictable way.
XML documents and files often need a well-defined structure in order to be portable across platforms and development systems. One way to accomplish this is by developing an XML schema, which describes the structure of the XML elements and data types. You can use schema validation to check that each item of content in an XML file adheres to the schema description of the element in which the content is to be placed.
 

Q. Object Repositories types, Which & when to use?

   Deciding Which Object Repository Mode to Choose    

 To choose the default object repository mode and the appropriate object repository mode for each test, you need to understand the differences between the two modes.

          In general, the object repository per-action mode is easiest to use when you are creating simple record and run tests, especially under the following conditions:

          You have only one, or very few, tests that correspond to a given application, interface, or set of objects.

          You do not expect to frequently modify test object properties.

          You generally create single-action tests.

          Conversely, the shared object repository mode is generally the preferred mode when:

          You have several tests that test elements of the same application, interface, or set of objects.

          You expect the object properties in your application to change from time to time and/or you regularly need to update or modify test object properties.

          You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options.

Q.Can we Script any test case with out having Object repository? or Using Object Repository is a must?
A.  No. U can script with out Object repository by knowing the Window Handlers, spying and recognizing the
objects logical names and properties available.
Q. How to execute a WinRunner Script in QTP?
A.  a. TSLTest.RunTest TestPath, TestSet [, Parameters ] --> Used in QTP 6.0 used for backward compatibility
Parameters : The test set within Quality Center, in which test runs are stored. Note that this argument is relevant only when working with a test in a Quality Center project. When the test is not saved in Quality Center, this parameter is ignored.
e.g : TSLTest.RunTest "D:\test1", ""
b. TSLTest.RunTestEx TestPath, RunMinimized, CloseApp [, Parameters ]
TSLTest.RunTestEx "C:\WinRunner\Tests\basic_flight", TRUE, FALSE, "MyValue"
CloseApp : Indicates whether to close the WinRunner application when the WinRunner test run ends.
Parameters : Up to 15 WinRunner function argument