Wednesday, October 21, 2009
Here I am provding the code for finding the number of lines in a Text file.
Const ForReading = 1
Set fso = CreateObject( "Scripting.FileSystemObject" )
Set textFile = fso.OpenTextFile( "your file path ", ForReading )
Print "Number of lines: " & textFile.Line
Monday, October 12, 2009
Most of us would be familiar with logging defects in Quality Center manually.
How about Adding a defect using a QTP script?
Here we go !!!
Set TDConnection = CreateObject(”TDApiOle.TDConnection”)
TDConnection.InitConnection “http://yovav/tdbin” ‘ DB URL
TDConnection.ConnectProject “TD76″,”bella”,”pino” ‘ Valid login information
If TDConnection.Connected Then
MsgBox(”Connected to ” + chr (13) + “Server ” + TDConnection.ServerName _+ chr (13) +”Project ” + TDConnection.ProjectName )
‘Get the IBugFactory
Set BugFactory = TDConnection.BugFactory
‘Add a new empty bug
Set Bug = BugFactory.AddItem (Nothing)
‘fill the bug with relevant parametersBug.Status = “New”
Bug.Summary = “Connecting to TD”
Bug.Priority = “4-Very High” ‘ depends on the DB
Bug.AssignedTo = “admin” ‘ user that must exist in the DB’s users list
Bug.DetectedBy = “admin” ‘ user that must exist in the DB’s users list
‘Post the bug to DB ( commit )
Tuesday, October 6, 2009
Below are the important points which need to be noticed by us prior to using Virtual Objects in QTP.
Important Points :
1. A group of Virtual Objects are stored in Virtual Object Manager under a descriptive name known as “Virtual Object Collection”.
2. Analog & Low-level recording on Virtual Objects is not supported by QTP.
3. Recognition of Virtual Objects can be disabled without deleting them from Virtual Object Manager.
4. Virtual Objects can only be used when recording & Running the tests. Any type of checkpoint on a virtual object cannot be inserted.
5. The Virtual Object Collections shown in the Virtual Object Manager are stored in our computer (where they are created) and not in the tests that include the virtual object steps. This means that if you the virtual object in a script, the object will be recognized during the run session only if it is run on the computer containing the appropriate Virtual Object Definition. To Copy your virtual object definitions to another computer, copy the contents of your \Dat\VoTemplate folder (or individual collection files within this folder) to the same location on the destination computer.
6. Virtual Objects can only be defined for objects on which you can click or Dbl click and that record a click or Dbl click operation. Otherwise, the virtual object is ignored. For example, if you define a virtual Object manager over the WinList object, the “Select” operation is recorded, and the virtual Object operation is ignored.
7. You cannot use the Object Spy to view the properties of Virtual Object.
Many times people tend to ask what Limitations does QTP has.
Now it is very difficult for one to list out clear limitations of a tool but it is far more easier for one to point the enhancements required.
With now over 5 years of experience from QTP 8 to QTP 10, thought of highlighting all the enhancements that we could think of.
Lets hope HP would look at few of these seriously and incorporate them in upcoming version of QTP. :):):)
In case you can think of other enhancements that can be included in the below then do let us know .
Object Spy Enhancements :
1. Object spy to have an option to export all the objects in hierarchy with their properties and methods to a XLS/XML file. And also to have an option to reload this offline. This feature would help for others to analyze a object recognition remotely
2. Object spy to have the ability to run without QTP. Currently object spy can only be loaded through QTP
3. Object spy to have an option to disable the Auto spy. Currently hovering on any object displays it properties without the need to click the object. This at time gives poor performance while spying objects
4. Currently Object Spy button gets disabled when the script is run, one has to launch object repository and then launch Object Spy from there. The Object Spy should enable directly when the script is run
5. Object Spy Automation capability, so other tools can leverage the same and automate the OR creation based on custom rules
6. Ability to open multiple scripts at one time
7. Project explorer with capability to create folder and organize library files in them
8. Improved Intellisense for objects created through DotNetFactory
9. Intellisense for VBScript classes
10. Function folding in the IDE
11. Transition from Design mode to Run mode causes too many flickers in the IDE UI. This needs to be smooth
12. Ability to view code for Test flow in Expert view. This is currently only possible through Keyword view
13. Design time non-syntax error check for issues like Duplicate variable declaration etc
14. Intellisense of current associated libraries in all Libraries. Currently if Lib1 and Lib2 are associated with a Test. The Lib1 will only show Intellisense for Lib1 and not for Lib2. The Test will show Intellisense for both Lib1 and Lib2. This creates difficulty when Lib2 functions need to be called in Lib1
Object Repository Enhancements :
15. Ability to create and load OR’s from QTP script itself
16. Ability to load Shared ORs dynamically to all the Actions. Currently RepositoriesCollection.Add methods adds the SOR to the current Action only and not other actions
17. Changes made through SetTOProperty in one Action does not get propagated to Next Action
18. Ability to enumerate all child objects present in the OR for a specified object
19. Ability to specify nickname for Objects. This would help get a complete object hierarchy through just the nick name
Object Repository Manager Enhancements
20. Ability to load and save directly to OR in XML format
21. Ability for multiple users to access the Shared OR at the same time for updating
22. Export/Import of Checkpoints from one SOR to another
23. Merging of SOR’s to an existing SOR. Currently when two SOR are merged, the merged SOR needs to be saved as a different file
24. Ability to update code when conflict resolution renames object during SOR merge. In case object A and B are merged and name A is chosen over B, all scripts using name B needs to be updated manually
25. More options for other scripting languages i.e. JScript, VB.NET, C#.NET etc…
26. Support for start and finish events in Action and Test. E.g. – Test_Init, Test_Terminate, Action_Init, Action_Terminate. Currently this can be achieved through use of class but it would be easier for people to use if the functionality is built-in
27. Ability to execute specified VBScript even before the test execution starts. This script would run outside QTP and would help make changes to QTP settings that cannot be done during run-time. This would help in overcoming limitations like Libraries cannot be associated at run-time
28. Ability to execute specified VBScript even after the test execution starts. This script would run outside QTP and would help perform post execution code. This would be helpful in scenarios like sending email with the report
29. Ability to create error handler functions which are automatically called when an error occurs
30. Performance improvement when using Descriptive programming when compared to Object Repository usage
31. Ability to Debug libraries loaded during run-time using Execute, ExecuteGlobal and ExecuteFile
32. Ability to register generic functions for any object type. Currently RegisterUserFunc can only be used to register the method for a single object type. So if a new Set method is created then multiple RegisterUserFunc statements need to be written. QTP should provided some way to use a pattern or something to apply the same method to multiple object types
33. Ability to Unlock a locked system from within the code34. Ability to prevent screen locking during the execution
35. Ability to debug error which occurs during terminations of script. Currently any errors that occur during the termination of the script cannot be debugged and launches.
Recovery Scenarios Enhancements:
36. Recovery scenarios (RS) to run in a separate thread. Currently recovery scenarios run in the same thread as QTP. This causes recovery scenarios to be useless in case a Modal dialog blocks QTP
37. Option to stop chaining in recovery scenarios. Currently if RS1 and RS2 both match the trigger criteria then both of the scenarios are executed. There is no way to specify that RS2 should not be executed if RS1 is executed
38. Currently there is no way to enumerate recovery scenarios present in a File
39. Recovery scenarios don’t work when they are associated at run-time
Test Reporting Enhancements:
40. Ability to create reports in different format. Excel, Word, HTML etc…
41. Reporting of errors or failure in different categories and priority. E.g. – Reporting a error with severity, priority and category (Application, Script, Validation, Checkpoint)
42. Exact location of the error in the script. This should include the line of code, error number, error statement
43. Direct ability to send report to a specified list of email addresses when the test end
44. Currently the reports can only be viewed through QTP reporter viewer and cannot be viewed on machines without this tool. Report should be made completely Web compatible so that I can be viewed in any browser in the same way it is displayed in report viewer
45. Ability to view status of current Action. Currently Reporter.RunStatus only provides the status of whole test and not for current action
46. Ability to enumerate the current status from within a Test i.e. Actions executed with details, checkpoints executed with details, recovery scenarios executed with details
47. Ability to alter properties of all checkpoints during run-time. E.g. Expected bitmap of a bitmap checkpoint, expected values of a Table/DB checkpoint etc
48. Ability to create checkpoints at run-time
49. Ability to load checkpoints from a external file at run-time
50. Ability to enumerate all checkpoints present in current script
Most of the times , we might have noticed the term "Keyword Driven Testing" in QTP.
So, let's know some thing more about the Keyword Driven Testing.
This requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test script code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test. In this method, the entire process is data-driven, including functionality.
Once creating the test tables, a driver script or a set of scripts is written that reads in each step executes the step based on the keyword contained the Action field, performs error checking, and logs any relevant information.
Merits of keyword driven testing
The merits of the Keyword Driven Testing are as follows,
-> The Detail Test Plan can be written in Spreadsheet format containing all input and verification data.
-> If "utility" scripts can be created by someone proficient in the automated tool’s Scripting language prior to the Detail Test Plan being written, then the tester can use the Automated Test Tool immediately via the "spreadsheet-input" method, without needing to learn the Scripting language.
->The tester need only learn the "Key Words" required, and the specific format to use within the Test Plan. This allows the tester to be productive with the test tool very quickly, and allows more extensive training in the test tool to be scheduled at a more convenient time.
Demerits of keyword driven testing
-> Development of "customized" (Application-Specific) Functions and Utilities requires proficiency in the tool’s Scripting language. (Note that this is also true for any method)
-> If application requires more than a few "customized" Utilities, this will require the tester to learn a number of "Key Words" and special formats. This can be time-consuming, and may have an initial impact on Test Plan Development. Once the testers get used to this, however, the time required to produce a test case is greatly improved.
Note: Keyword-Driven Testing is generally implemented in Keyword Driven Framework.
Here we go about Hybrid Test Automation Framework.
Prior to knowing about the Hybrid Test Automation Framework , weshould know about the existing frameworks.
Generally we have,
- Data Driven Framework
- Test Script Modularity Framework
- Keyword Driven Framework
- Test Library Architecture Framework
- Hybrid Framework
Hybrid Framework is the most commonly implemented framework is a combination of of the above techniques, pulling from their strengths and trying to mitigate their weaknesses.
This Hybrid test automation framework is what most frameworks evolve into over time and multiple projects.
Hybrid Automation Frameworks generally can accommodate any of the below:
Keyword-Driven & Data Driven
Test Script Modularity & Data Driven
Keyword-Driven,Data Driven & Test Library Architecture so on so forth.