Nice chat, Roman. I think by "Driver" and three levels he meant Excel (level 1) with Actions and parameters that are pulled by script, or Driver (level 2) to call specific Function from the Function Library (level 3). For your example framework model, I'm guessing there would be 6 sheets on the Excel spreadsheet: The Master sheet or Global sheet used to identify the other 5 sheets and their parameters (up to 15 each) for each of the pages (ex: 5) in the application. To be sure I understand, I wanted to ask: Did you mean by your example a script with 1 global sheet for the Master one used to "coordinate the scenarios", and by this did you mean to call each of the 5 functions and pass them the up to 15 field parameters used on each of the 5 pages? And if so, am I correct in assuming there would be 5 functions and 1 Global sheet and 5 Local sheets for the below example? In a message dated 4/3/11 9:27:44 P.M. Eastern Daylight Time, [email protected] writes:
I don't know what is the discussion about (I mean 3 levels, drivers, etc.), I want to make just a small remark about data Excel. You will be perfectly fine using Excel with any scenario for login screen, the problems start when you have complicated and long scenarios. Imagine, you have an application with numbers of pages and 15 fields on each page. For each page you will create excel, but also you will need a master sheet which will coordinate the scenarios... Example Customer buys books on Amazon 1. Login data 2. books on Wish List 3. new books customer add to the basket (multiple items of different types: books, CDs, games) 4. credit card card information 5. shipping address you will need actions add to wish list move from wish items to basket fill order add a new item to basket cancel order fill shipping info ... now try to design scenario (in Excel) customer N opens account, and buying 3 books, 2 CDs On Sun, Apr 3, 2011 at 3:32 PM, <[email protected]_ (mailto:[email protected]) > wrote: Get a few years of regular stuff under your belt before you try to understand that...it is so complex they don't even teach it in Advance QTP classes...you'll just drive yourself nuts. In a message dated 4/3/11 12:41:30 P.M. Eastern Daylight Time, [email protected]_ (mailto:[email protected]) writes: Hi Dude am new in framework part .Could u explain the data drive frame work and to create script and function library and driver script On Sun, Apr 3, 2011 at 9:51 PM, <[email protected]_ (mailto:[email protected]) > wrote: 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]_ (mailto:[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]_ (mailto:[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]_ (mailto:[email protected]) To unsubscribe from this group, send email to [email protected]_ (mailto:[email protected]) For more options, visit this group at _http://groups.google.com/group/MercuryQTP?hl=en_ (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
