Please discuss further the separation of the DB level into two parts...the Tasks vs. the TaskProperties. I understand the basic idea of 3 levels, especially Driver Script and Function Library. But I want to have a better understanding of the DB level including the ODBC. I am using a similar approach but using EXCEL for DB level for table driven function calls via Driver Script with VBScript Case Statements calling Functions or Subroutines. I guess I don't fully understand the separation of Tasks and Task Properties because it seems to me, in my opinion, it would be less complicated or easier with one table that passed the function name with the properties from different columns on the same row, and let the whole script be implied or assumed to be related to the same Application...but maybe I'm not thinking of some smart concept of db normalization. It may be that I am just more comfortable with EXCEL instead of ACCESS, but I'm willing and open to learn more. Please advise with examples for a logon web page with parameters of User, Password, and webButton... And then, if we have not exhausted this topic which has me hungry to learn more, and always improve, I'd like to expand this into an argument or what everyone thinks about the value of using Dynamic code to pass these parameters from the DB level so the Script Driver never changes, but the tester only needs to change the DB level and thereby never have to re-record script code!???! Isn't that too much overhead and to complicated to maintain (Roman?) In a message dated 2/10/11 5:42:26 A.M. Eastern Standard Time, [email protected] writes:
Hi, In general you should create 3 levels in your automation framework. The higher level is general interface for calling task in your test were test is a set of serial tasks. Like-------> G_RunTask Create,Elemet,"","" Where CreateElement is areal function which will reside at one of your libary function file This functions libary is the lowest level and in between resides the DB level Which contains parameters for the tasks which each task takes on runtime to call the task function The DB basicaly should contain two tables Tasks & TaskProperties 1.Task contains for each task the Application on which it runs,the vbscript function that the task runs. 2.Task Properties contains list of parameters and there values This is the idea in general(this frame work runs for 3 years running almost 1000 tests) You can use ODBC to make the connection to the DB which can be any db we choose Access. If you have more questions regarding the frame work please ask. On 8 פברואר, 06:17, kalyani k <[email protected]> wrote: > Hi, I want to know how to Create Test Automation Frameworks. Can > anybody tell me. -- You received this message because you are subscribed to the Google "QTP - HP Quick Test Professional - Automated Software Testing" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/MercuryQTP?hl=en -- You received this message because you are subscribed to the Google "QTP - HP Quick Test Professional - Automated Software Testing" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/MercuryQTP?hl=en
