Something like that, to implementing it takes tons of code, and nightmare with data maintainability. I you keep the save in DB, it will single lines of code and couple of complicated SQLs.
On Sat, Apr 30, 2011 at 7:12 PM, <[email protected]> wrote: > 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]> 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] 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]> 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] 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 -- 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
