Sunday, October 16, 2011

Understanding Report.ReportEvent method in QTP

You can define a message that QTP sends to your test results. For example, suppose you want to check that a password edit box exists in the Login Form. If the edit box exists, then a password is entered. Otherwise, QTP sends a message to the test results indicating that the object is absent.
To send a message to your test results:
In the Keyword View, select a step and choose Insert > Step > Report or right-click a step and choose Insert Step > Report. The Insert Report dialog box opens.
Report.ReportEvent method in QTP
Select the status that will result from this step from the Status list.
  • Passed: Causes this step to pass. Sends the specified message to the report.
  • Failed: Causes this step (and therefore the test or component itself) to fail. Sends the specified message to the report.
  • Done: Sends a message to the report without affecting the pass/fail status of the step.
  • Warning: Sends a warning status for the step, but does not cause the test or component to stop running, and does not affect its pass/fail status.
In the Name box, type a name for the step, for example, Password edit box.
In the Details box, type a detailed description of this step to send to your test results, for example, Password edit box does not exist.
Click OK. A report step is inserted into the Keyword View and a ReportEvent statement is inserted into your script in the Expert View.
For example:
Reporter.ReportEvent micFail, "Password edit box", "Password edit box does not exist"
In this example, micFail indicates the status of the report (failed), Password
edit box is the report name, and Password edit box does not exist is the report message.

How to Debug custom functions in QTP

Debugging suggestions include:1. Use the suggestions above for debugging a script.
2. Verify the code works when it is not within a function. If the code does not work when it is not in a function in a QuickTest Professional (QTP) script or within a pure VBS script (while QuickTest Professional is not in use), it will not work when it is placed within a function. The following example shows the step by step process of debugging a simple function.

Example:
Function ex_func(obj, txt)
msgbxo obj.Exist
msgboxx txt
End Function
To debug the above function (which has intentional typos), copy the statements into a QuickTest Professional script:
msgbxo obj.Exist
msgboxx txt
If needed, modify any references to a generic object to an actual object:
msgbxo Browser("Browser").Exist
msgboxx txt
Execute the code; debug as needed:
msgbox Browser("Browser").Exist ' corrected typo: msgbxo -> msgbox
msgbox txt ' corrected typo: msgboxx –> msgbox
Copy the corrected code into the function. Verify it works as expected:
Function ex_func(obj, txt)
msgbox Browser("Browser").Exist
msgbox txt
End Function
If needed, modify references to specific objects back to general references:
Function ex_func(obj, txt)
msgbox obj.Exist
msgbox txt
End Function
Verify the function works as expected.
(Optional) Move the function into a function library.

3. If your function is returning a value, the value should be assigned to the function name. This is a VBScript requirement.
Example:
Function examplefunc
examplefunc = "returned value"
End Function
msgbox examplefunc

4. If your function is saved in an external function library, make sure you associate the function library with the test script.

Bug Advocacy

"The best tester isn't the one who finds the most bugs or embarrasses the most programmers," says Dr. Cem Kaner, Professor of Software Engineering at the Florida Institute of Technology. "The best tester is the one who gets the right bugs fixed."
Finally Bug Advocacy is on the way. 1st class of 2011 will starts from Feb 13, 2011.I would like to suggest to all testers must gone thru this course.
About Bug Advocacy
Bug reports are not just neutral technical reports. They are persuasive documents. The key goal of the bug report author is to provide high-quality information, well written, to help stakeholders make wise decisions about which bugs to fix. Key aspects of the content of this course include:
  • Defining key concepts (such as software error, quality, and the bug processing work-flow)
  • The scope of bug reporting (what to report as bugs, and what information to include)
  • Bug reporting as persuasive writing
  • Bug investigation to discover harsher failures and simpler replication conditions
  • Excuses and reasons for not fixing bugs
  • Making bugs reproducible
  • Lessons from the psychology of decision-making: bug-handling as a multiple-decision process dominated by heuristics and biases.
  • Style and structure of well-written reports
  • Gaining real world experience writing bug reports in a public forum, suitable for presenting at interviews or to an employer.

Usability Testing Approaches

Usability requirements are not always testable & cannot be measured accurately. Classic non-testable requirement: "System must be user-friendly." But think about this – User friendly to whom? Who are the users?
Suggested Approaches for Usability Testing:
  1. Qualitative & Quantitative
  2. Qualitative Approach:
Qualitative Approach
  • Each and every function should available from all the pages of the site.
  • User should able to submit each and every request with in 4-5 actions.
  • Confirmation message should be displayed for each and every submit.
Quantitative Approach:
  • Heuristic Checklist should be prepared with all the general test cases that fall under the classification of checking.
  • This generic test cases should be given to 10 different people and ask to execute the system to mark the pass/fail status.
  • The average of 10 different people should be considered as the final result.
Example: Some people may feel system is more users friendly, If the submit is button on the left side of the screen. At the same time some other may feel its better if the submit button is placed on the right side.

Recovery Testing

  • It is - Ability to restart the operations after the integrity of the application is lost.
  • Objective of the recovery testing is to ensure that the operations can continue even though the disaster is happening.
  • Recovery testing includes:
        1. Storage of data in the preserved location.
        2. Documents need to maintain properly about recovery.
        3. Assign the professional testers involving in Recovery process.
        4. Develop a recovery tool and make it available all the times.
  • Recovery testing is normally takes care by professional testers, System analysts you know entire flow of the applications.
  • It is advised that the operational staff need not involved in recovery testing and only professionals need to be involved.
  • Recovery can be conducted in two modes:
        1. Either with the recovery tools and the set of the methods and procedures to resolve it.
        2. Once the system is developed and the failure is introduced in to the system and the ability to recover it.
The user should estimate the potential loss inability to recover over the time spans. Ability not to recover may lead to the business loss. The potential loss is calculated in such that the amount of resource used for recovery testing

Which test cases to be Automated?

The testing elapsed time can be shortened, therefore leading to a huge saving in terms of time and money. Generally, the ROI begins to appear in the third iteration of automated testing
High Scoring Test Cases
  • Tests that need to be run for every build of the application (sanity check, regression)
  • Tests that use multiple data values for the same actions (data driven tests)
  • Complex and time consuming tests
  • Tests requiring a great deal of precision
  • Tests involving many simple, repetitive steps
  • Testing needed on multiple combinations of OS, DBMS & Browsers
  • Creation of Data & Test Beds
  • Data grooming
Low Scoring Test Cases
  • Usability testing - "How easy is the application to use?"
  • One-time testing
  • "ASAP" testing - "We need to test NOW!"
  • Ad hoc/random testing - based on intuition and knowledge of application
  • Device Interface testing
  • Batch program testing
  • Back-end testing

Thursday, October 13, 2011

Useful Testing Metrics

1.Introduction
When we can measure what we are speaking about and express it in numbers, we know something about it; but when we cannot measure, when we cannot express it in numbers, our knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge, but we have scarcely, in your thoughts, advanced to the stage of science.

Why we need Metrics?
“We cannot improve what we cannot measure.”
“We cannot control what we cannot measure”
AND TEST METRICS HELPS IN
  • Take decision for next phase of activities
  • Evidence of the claim or prediction
  • Understand the type of improvement required
  • Take decision on process or technology change

2. Type of metrics

Base Metrics (Direct Measure)
Base metrics constitute the raw data gathered by a Test Analyst throughout the testing effort. These metrics are used to provide project status reports to the Test Lead and Project Manager; they also feed into the formulas used to derive Calculated Metrics.
Ex: # of Test Cases, # of Test Cases Executed

Calculated Metrics (Indirect Measure)
Calculated Metrics convert the Base Metrics data into more useful information. These types of metrics are generally the responsibility of the Test Lead and can be tracked at many different levels (by module, tester, or project).
Ex: % Complete, % Test Coverage

Base Metrics & Test Phases
  • • # of Test Cases (Test Development Phase)
  • • # of Test Cases Executed (Test Execution Phase)
  • • # of Test Cases Passed (Test Execution Phase)
  • • # of Test Cases Failed (Test Execution Phase)
  • • # of Test Cases Under Investigation (Test Development Phase)
  • • # of Test Cases Blocked (Test dev/execution Phase)
  • • # of Test Cases Re-executed (Regression Phase)
  • • # of First Run Failures (Test Execution Phase)
  • • Total Executions (Test Reporting Phase)
  • • Total Passes (Test Reporting Phase)
  • • Total Failures (Test Reporting Phase)
  • • Test Case Execution Time ((Test Reporting Phase)
  • • Test Execution Time (Test Reporting Phase

Calculated Metrics & Phases
The below metrics are created at Test Reporting Phase or Post test Analysis phase
  • • % Complete
  • • % Defects Corrected
  • • % Test Coverage
  • • % Rework
  • • % Test Cases Passed
  • • % Test Effectiveness
  • • % Test Cases Blocked
  • • % Test Efficiency
  • • 1st Run Fail Rate
  • • Defect Discovery Rate
  • • Overall Fail Rate

3. Crucial Web Based Testing Metrics

Test Plan coverage on Functionality
Total number of requirement v/s number of requirements covered through test scripts.
  • • (No of requirements covered / total number of requirements) * 100
Define requirements at the time of Effort estimation
Example: Total number of requirements estimated are 46, total number of requirements tested 39; blocked 7…define what is the coverage?
Note: Define requirement clearly at project level

Test Case defect density
Total number of errors found in test scripts v/s developed and executed.
  • • (Defective Test Scripts /Total Test Scripts) * 100
Example: Total test script developed 1360, total test script executed 1280, total test script passed 1065, total test script failed 215
So, test case defect density is
215 X 100
---------------------------- = 16.8%
1280
This 16.8% value can also be called as test case efficiency %, which is depends upon total number of test cases which uncovered defects

Defect Slippage Ratio
Number of defects slipped (reported from production) v/s number of defects reported during execution.
  • • Number of Defects Slipped / (Number of Defects Raised - Number of Defects Withdrawn)
Example: Customer filed defects are 21, total defect found while testing are 267, total number of invalid defects are 17
So, Slippage Ratio is
[21/ (267-17)] X 100 = 8.4%

Requirement Volatility
Number of requirements agreed v/s number of requirements changed.
  • • (Number of Requirements Added + Deleted + Modified) *100 / Number of Original Requirements
  • • Ensure that the requirements are normalized or defined properly while estimating
Example: VSS 1.3 release had total 67 requirements initially, later they added another 7 new requirements and removed 3 from initial requirements and modified 11 requirements
So, requirement Volatility is
(7 + 3 + 11) * 100/67 = 31.34%
Means almost 1/3 of the requirement changed after initial identification

Review Efficiency
The Review Efficiency is a metric that offers insight on the review quality and testing
Some organization also use this term as “Static Testing” efficiency and they are aiming to get min of 30% defects in static testing
Review efficiency=100*Total number of defects found by reviews/Total number of project defects
Example: A project found total 269 defects in different reviews, which were fixed and test team got 476 defects which were reported and valid
So, Review efficiency is [269/(269+476)] X 100 = 36.1%

Efficiency and Effectiveness of Processes
  •  Effectiveness: Doing the right thing. It deals with meeting the desirable attributes that are expected by the customer.
  •  Efficiency: Doing the thing right. It concerns the resources used for the service to be rendered

Metrics for Software Testing
• Defect Removal Effectiveness
DRE= (Defects removed during development phase x100%) / Defects latent in the product
Defects latent in the product = Defects removed during development
Phase+ defects found later by user
• Efficiency of Testing Process (define size in KLoC or FP, Req.)
Testing Efficiency= Size of Software Tested /Resources used

Usefull sctipts for LoadRunnaer

Problem Description: To get the password of an auto-generated lr_decrypt() function:
char * password;
web_set_user("2testuser", lr_decrypt("41754c8245221983220368db"),"preview.fanniemae.com:80");
password=lr_decrypt("41754c8245221983220368db");
lr_output_message("password:%s",password);
  
Problem Description: How to capture the total bytes of a request/response from the server

Solution: Use the web_get_int_property function
In VuGen 8.1, there are additional options available for the web_get_int_property function like HTTP_INFO_TOTAL_REQUEST_STAT and HTTP_INFO_TOTAL_RESPONSE_STAT. These options return the accumulative size (including header and body) of requests and responses.

Problem Description: How to verify the size of the last download in bytes

Solution: Use web_get_int_property( HTTP_INFO_DOWNLOAD_SIZE )
You can use the web_get_int_property() function with HTTP_INFO_DOWNLOAD_SIZE to check the size (in bytes) of the last download.
Example:
long i;
//Start a transaction to download the file.
lr_start_transaction("file_download");
//HTTP call to the .pdf file 
web_url("<HTTP call to the pdf file>");
//Get the download size.
i = web_get_int_property( HTTP_INFO_DOWNLOAD_SIZE );
//Output file size
lr_output_message("File size downloaded : %d", i );
//End a transaction to download the file.
lr_end_transaction("file_download", LR_PASS);

Problem Description: How to capture HTTP return code information
The user uses the following function to capture the return code of a webpage:
   HttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE)
However, this function only captures the last status code that was received. If there is a redirection in between, it is not reflected. How can user detect redirection on a page?

Solution: Function to capture HTTP return code
To capture the HTTP returned code, you can use the web_get_int_property function.
Example:
HttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE)
Note:
The web_get_int_property function only captures the last status code that was received. If there is a redirection in between, it is not reflected. To get all of the responses, you can use the web_reg_save_param function with:
1. The "ORD=ALL" attribute to capture all occurrence.
2. The "Search=Headers" attribute to search the response header only.
Example:
web_reg_save_param("response","LB=HTTP/1.1 ", "RB= ", "Search=Headers" ,"ORD=ALL", LAST);

Problem Description: How to change the default host in the Controller
When creating a new scenario, LoadRunner automatically adds "localhost" as the default Load Generator machine. Is it possible to change this default?

Solution: Change DefaultHost in the wlrun7.ini file
1. Go to the C:/Windows or C:/WinNT folder. 
2. Open the wlrun7.ini file in Notepad.
3. Search for "DefaultHost."
4. Replace "localhost" with the name or IP address of the machine you want set as the default host.

Problem Description: How to save the list of Load Generators or hosts in the Controller

Solution: Use the "Save LoadGenerator List as Default" option
1. Create a new scenario.
2. Click on the "Generators" button to bring up the list of Load Generators.
3. Click on the "Add" button to add the new hosts.
4. Repeat step 3 for all the hosts.
When you are done, go to Scenario -> "Save LoadGenerator List as Default."

Problem Description: Which file stores the Load Generator list
Which file on the Controller machine stores the list of Load Generators when the option Scenario -> Save Load Generators as Default list is selected?

Solution: The wlrun7.hst file located in the C:\winnt folder
The wlrun7.hst file located in the C:\winnt folder. It has sections defined for each of the Load Generators.

Problem Description: How to delete default URL on the Web Recorder's pull down menu
When the user opens the Web Recorder (starting with LoadRunner 7) and tries to record, the recorder opens a list of URLs that were recently accessed. How can the user remove unwanted entries from this menu?

Solution: Edit the HKEY_CURRENT_USER\Software\Mercury Interactive\QuickTest\Recording History registry key
All recently accessed URLs' information is stored in the registry under HKEY_CURRENT_USER\Software\Mercury Interactive\QuickTest\Recording History.
To remove an unwanted URL:
1. Go to Start -> Run and enter "Regedit" to open the Registry Editor.
2. Open the HKEY_CURRENT_USER -> Software -> Mercury -> QuickTest -> Recording History folder. This lists all the URLs in the Web Recorder's pull down menu.
3. Delete those entries you no longer want to appear.

Problem Description: How to remove the scripts that are listed in "Available Scripts"
How can the user remove the scripts that are listed in "Available Scripts" when creating a new scenario?

Solution: Delete the unwanted script entries from the registry
All recently accessed URL information is stored in the registry under HKEY_CURRENT_USER\Software\Mercury Interactive\RecentScripts.
To remove unwanted URL:
1. Go to Start -> Run and type in regedit to open the Registry Editor.
2. Open the HKEY_CURRENT_USER -> Software -> Mercury -> Recent Scripts folder. This lists all the files listed in the "Available Scripts" section when the Controller is launched.
3. Delete those entries you no longer want to appear.

How LoadRunner Works


HP LoadRunner Process:
  • LoadRunner emulates hundreds or thousands of human users with Virtual Users (Vusers) to apply measurable & repeatable production workloads and stresses an Application end-to-end.
  • Vusers emulate the actions of human users by performing typical Business Processes.
  • For each user action, the tool submits an input request to server and receives the response.
  • Increase number of Vusers, to increase the load on the Server.
LoadRunner
Click on the above image for clear view 

File System Objects(FSO) scripts for QTP

FSO stands for Files system object, during testing we need to do some basic task like add, move, copy, create and delete folders and files. We can also handle drives related things using File system object method. So It is very much important to learn File system object.

Below are some Useful QTP File System Scripts:

1) Create a Folder


Option Explicit
Dim objFSO, objFolder, strDirectory
strDirectory = "D:\BraidyHunter"
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.CreateFolder(strDirectory)


2) Delete a Folder
Set oFSO = CreateObject("Scripting.FileSystemObject")
oFSO.DeleteFolder("E:\BraidyHunter")


3) Copying Folders
 

Set oFSO=createobject("Scripting.Filesystemobject")
oFSO.CopyFolder "E:\gcr", "C:\jvr", True


4) Checking weather the folder available or not, if not creating the folder
Option Explicit
Dim objFSO, objFolder, strDirectory
strDirectory = "D:\BraidyHunter"
Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FolderExists(strDirectory) Then
Set objFolder = objFSO.GetFolder(strDirectory)
msgbox strDirectory & " already created "
else
Set objFolder = objFSO.CreateFolder(strDirectory)
end if


5) Returning a collection of Disk Drives
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set colDrives = oFSO.Drives
For Each oDrive in colDrives
MsgBox "Drive letter: " & oDrive.DriveLetter
Next


6) Getting available space on a Disk Drive
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oDrive = oFSO.GetDrive("C:")
MsgBox "Available space: " & oDrive.AvailableSpace

Common mistakes while using Descriptive Programming (DP) in QTP


Using strings with Pattern
Let’s assume we want to click a link “Logout (Tarun)” on my web page. Two possible methods that can be used are
Method 1
Browser("miccclass:=Browser").Page("micclass:=Page").Link("text:=Logout (Tarun)").Click
Method 2
Set oDesc = Description.Create
oDesc("text").Value = "Logout (Tarun)"
Browser("miccclass:=Browser").Page("micclass:=Page").Link(oDesc).Click
Now both the above methods will fail giving below mentioned error
Cannot identify the object “[ Link ]” (of class Link). Verify that this object’s properties match an object currently displayed in your application.

Cannot identify the link object
Looking through the naked eyes on the web page the link does exist indeed
So what went wrong? The problem was with the characters “(” and “)” present in the text of the link we used. By default QTP treats all DP properties as regular expression (r.e.) patterns and “(xxx)” is considered as a group of patter xxx. The text “Logout (Tarun)” when treated as a r.e. gets a literal meaning of “Logout Tarun”, and since there is no such link on the web page QTP throws an error. To avoid such situations we need to escape the regular expression characters using the escape character “\”. Now we have three different solutions to correct the problem
Method 1
Browser("miccclass:=Browser").Page("micclass:=Page").Link("text:=Logout \(Tarun\)").Click
Method 2
Set oDesc = Description.Create
oDesc("text").Value = "Logout \(Tarun\)"
Browser("miccclass:=Browser").Page("micclass:=Page").Link(oDesc).Click
Method 3
Set oDesc = Description.Create
oDesc("text").Value = "Logout (Tarun)"
'Do not treat the value as regular expression.
oDesc("text").RegularExpression = False
Browser(”miccclass:=Browser”).Page(”micclass:=Page”).Link(oDesc).Click
IMO Method 3 should be preferred for a neater coding as we are using the actual text of the link.
Overpopulated description while identifying objects
An overpopulated description does not help in recognizing the object. We should use minimum no. of properties which are stable enough to recognize the object on every single run. Consider the below overpopulated description
Set oDesc = Description.Create
oDesc("html tag").Value = "TABLE"
oDesc("micclass").Value = "WebTable"
oDesc("innertext").Value = "abcde"
oDesc("outertext").Value = "abcde"
oDesc("innerhtml").Value = "<tbody><tr><td>abcde</td></tr></tbody>"
oDesc("outerhtml").Value = "<table><tbody><tr><td>abcde</td></tr></tbody></table>"
oDesc("rows").Value = 1
oDesc("cols").Value = 1
Consider the following advices while create such a description
·                 rows and cols are dynamic properties which might change if the table gets updated. These properties should be avoided
·                 Only one of the properties from innertext, outertext, outerhtml and innerhtml should be used
·                 outerhtml and innerhtml properties should be avoided as they contains various tags and difficult to express
·                 When using Browser().Page().WebTable(oDesc) we can skip specifying the micclass and html tag properties also because as soon as we enclose oDesc with the WebTable() test object these two properties are mostly implied.
Considering the above points we can reduce our description to just
Set oDesc = Description.Create
oDesc("outertext").Value = "abcde"
Underpopulated description while using ChildObjects
Though we reduced the no. of properties in the description object when identified a table in the last section but while using ChildObjects method we should make sure the following
·                 Maximum description properties should be used to reduce the final result set. Though we should still follow the advices specified in earlier section of overpopulated descriptions except the last one (Where we ignore micclass and HTML tag).
·                 When using ChildObjects to find WebElements, “html tag” should always be provided to avoid errors.
·                 Property names used in description should be as the same case provided in the QTP help file. IMO changing the case sometimes causes general run error during script run. Though there is no documentation proving that description names are case sensitive
Using “Class Name” instead of “micclass”
Don’t know why by Mercury/HP preferred to show micclass as “Class Name” in the object spy. This misleads many DP user to create a description with non-existent property class name
Class Name shown in object spy
'Below is the wrong way
Browser("Class Name:=Browser")

'Below is the right way
Browser("micclass:=Browser")

'Below is the wrong way
Set oDesc = Description.Create
oDesc("Class Name").Value = "Browser"
oDesc("title").Value = "My title"

'Below is the right way
Set oDesc = Description.Create
oDesc("micclass").Value = "Browser"
oDesc("title").Value = "My title"

When to Automate the test cases? And QTP Tips

Lots of efforts need to spend before Software Test Automation is started. One needs to ensure:
  • Stability of product/application – If new features are being introduced and there is a possibility of the existing functionality being disturbed, more effort is required for automation due to rework (Script Fixing)
  • Interface to be tested has been identified
  • Scope of automation has been identified
  • Individual test cases to be automated have been identified & are complete
  • Standard Coding definitions for objects is adhered to
  • Right tool has been identified
1. Can I change the Active Screen page which is shown on every new test?
This page can be changed to be any valid HTML page. The page can be located either locally or on the network.
For example, if you want your entire organization to view the same Active Screen page when they open QTP, you should open the NewTest.inf file located under the dat\snapshots directory of QTP and set the next line:
FileName1=<any full path to an HTML file>
FileName1=\\mercury\public\MainPage.html
2. How to create an action template?
You can create a template action script that will be used on every new action that is created. You can use this, for example, to add a header comments to each action.
To create the template action you should create a text file with the name ActionTemplate.mst and place it under QTP dat folder.
3. How to pass parameters when calling actions?
You can pass information between actions in several ways:
1. Using the new Action Parameters feature in Quick Test 8.0
2. Putting the variable in the data table and then accessing this data table from the called action.
3. Defining the variable as an environment variable that can be accessed from the entire test.
4. How to configure the report to show only error (by default)?
You can configure the report to show only error by default by adding the following section to the QTReport.ini file (located under QTP bin directory).
[FilterDialog]
ReportAppDefaultFilter=1 # for error only
ReportAppDefaultFilter=3 # shows all messages (default)
5. How to use Environment variable?
QuickTest supports using environment variables. Environment variables can be either system variables or user defined variables.
You can define the user defined variables in an external file which will be read by QuickTest when it will be launched.
6. Does QuickTest have any debugging capabilities?
In order to debug tests you must install the Microsoft Script Debugger. If you did not download and installed it while installing QuickTest, the debugger can be still downloaded from the Microsoft Script Technologies site. After downloading it, double-click on the self-extracting executable and follow the instructions on your screen.
Once the Script Debugger is installed, an arrow points to the current step that is being executed in the Tree View and the Expert View. You can then use the debugger to view local action variables, use the command window, view the objects properties, and more.
More information can be found in the QuickTest User’s Guide.
7. What command-line arguments can I use when launching QuickTest?
Please refer to the QuickTest Command Line utility for more information on how to run QuickTest using a command line.
8. I have a Microsoft Access database that contains data I would like to use in my test. How do I do this?
The powerful ‘Expert View’ allows you to access databases using ADO and ODBC. Below is a sample test that uses the information contained in the Authors table of a database to search for books written by the author.
Dim MyDB
Dim MyEng
Set MyEng = CreateObject(“DAO.DBEngine.35″)
Dim Td
Dim rs
‘ Specify the database to use
Set MyDB = MyEng.OpenDatabase(“BIBLIO.MDB”)
‘ Read and use the name of the first 10 authors
Set Td = MyDB.TableDefs(“Authors”)
Set rs = Td.OpenRecordset
rs.MoveFirst
For i = 1 To 10
Browser(“Book Club”).Page(“Search Books”).WebEdit(“Author Name”).Set rs(“Author”)
Browser(“Book Club”).Page(“Search Books”).WebButton(“Search”).Click
Next
9. How do I add a manual wait step to my test?
A manual wait (think time) can be added to a QuickTest test using the following command:
Call Wait(<time in seconds to wait>)
10. How do I make the test prompt the user for input while it is running?
The VBScript InputBox function allows you to display a dialog box that prompts the user for input and then continue running the test. You can use the value that was entered by the user later on in the test. See the VBScript reference manual for more information on the InputBox function.
The following example shows the InputBox function used to prompt the user for the password.
Browser(“Mercury Tours”).Page(“Mercury Tours”).WebEdit(“username”).Set “administrator”
Passwd = inputbox (“Enter password”, “User Input”)
Browser(“Mercury Tours”).Page(“Mercury Tours”).WebEdit(“password”).Set Passwd



Related Posts Plugin for WordPress, Blogger...

 
Powered by Blogger