Ask a Question

Modularize the script

shilpi_agarwal
Contributor

Modularize the script

I am unable to modularize the script. Can you please help me out to write the script in formal way. The Script is related to validate the Login Screen.

Following is excel file named "TestSheet.xls".

 testsheet.jpg

 

Following is the Script-

 

Sub Test1
Dim prowin
Dim loginMainWin
Dim loginFrame
Dim edit
Dim uName,pwd
Dim strCaption

' Creates the driver
Set Driver = DDT.ExcelDriver("D:\TCProject\GUITestingAutomation\Stores\TestSheet.xls", "Sheet1")
TestedApps.prowin.Run
Set prowin = Aliases.prowin
Set loginMainWin = prowin.wndProMainWin
Set loginFrame = loginMainWin.ProClientWin.proFrame
Set uname = loginFrame.Edit
Set pwd = loginFrame.Edit2

' Iterates through records
rec = 0
While Not Driver.EOF()
rec = rec + 1
Call uname.Keys("^a")
Call uname.Keys("[BS]")
if rec <> 2 and rec <> 5 then
Call uname.Keys(Driver.Value(0))
end if
Call uname.Keys("[Tab]")
Call pwd.Keys("^a")
Call pwd.Keys("[BS]")
if rec <> 3 and rec <> 5 then
Call pwd.Keys(Driver.Value(1))
end if
loginFrame.btnLogin.ClickButton
if rec = 2 then 'When UserName is Blank
'Call aqObject.CheckProperty(Aliases.prowin.dlgMessage.Static, "WndCaption", cmpEqual, Driver.Value(2), True)
strCaption = Aliases.prowin.dlgInformation.Static.WndCaption
If strCaption <> Driver.Value(2) Then
Log.Error("Property value " & strCaption & " does not match data value " & Driver.Value(2))
End If
prowin.dlgInformation.btnOK.ClickButton
End if

if rec = 3 then 'When Passowrd is Blank
strCaption = Aliases.prowin.dlgInformation.Static2.WndCaption
If strCaption <> Driver.Value(2) Then
Log.Error("Property value " & strCaption & " does not match data value " & Driver.Value(2))
End If
prowin.dlgInformation.btnOK.ClickButton
End if

if rec = 4 then 'Invalid username or password
strCaption = Aliases.prowin.dlgMessage.Static.WndCaption
If strCaption <> Driver.Value(2) Then
Log.Error("Property value " & strCaption & " does not match data value " & Driver.Value(2))
End If
prowin.dlgMessage.btnOK.ClickButton
End if

if rec = 5 then 'When Both Username and Password are blank
strCaption = Aliases.prowin.dlgInformation.Static.WndCaption
If strCaption <> Driver.Value(2) Then
Log.Error("Property value " & strCaption & " does not match data value " & Driver.Value(2))
End If
prowin.dlgInformation.btnOK.ClickButton
End if

if rec <> 2 and rec <> 3 and rec <> 4 and rec <> 5 then
prowin.wndProMainWin2.Close
end if
Call Driver.Next()
Wend

loginMainWin.Close
prowin.wndProMainWin3.Close
' Closes the driver
'Call DDT.CloseDriver(Driver.Name)
End Sub

 

Here I am using simple if and based on the record exist on excel file, checking the data and Logging error. Please help me to make this script general using some techniques(like DDT loops or some other) if any. 

5 REPLIES 5
tristaanogre
Esteemed Contributor

I'm not entirely certain what you're asking. You are already using a "while" loop to iterate through the spreadsheet (what could be called a DDT loop). Can you clarify what you want to see differently?


Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
Marsha_R
Community Hero

I think it's best not to depend on the record numbers.  Look at the data instead.

 

For instance, I think here you are trying to treat the login differently depending on what is in username and password:

 

Call uname.Keys("^a")
Call uname.Keys("[BS]")
if rec <> 2 and rec <> 5 then
Call uname.Keys(Driver.Value(0))
end if
Call uname.Keys("[Tab]")
Call pwd.Keys("^a")
Call pwd.Keys("[BS]")
if rec <> 3 and rec <> 5 then
Call pwd.Keys(Driver.Value(1))

 

Try instead just entering whatever is in the UserName and Password fields, or if you do want to skip, check the data as you go.  Something like:

 

If UserName <> blank then

Call uname.Keys(Driver.Value(1))

Else

Call uname.Keys("[Tab]")

 

I don't have your syntax right but hopefully you will see what I mean.  That will work for all your records and you don't need the records to be in a particular order and you don't need to know what the particular scenario is every time.

 

 

 

 

 


Marsha_R
[Community Hero]
____
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
https://community.smartbear.com/t5/custom/page/page-id/hall-of-fame
tristaanogre
Esteemed Contributor

Good answer @Marsha_R.  The only thing I'd add is to wrap the text for the user name in a aqConvert.VarToStr call to actually get a "blank" value. Otherwise, you might get an error.


Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available

Thanks a lot. Really appreciate, Now the script would not be depend on the existence of records in excel file.

Again Thank you so much.

The way I set my input up on excel is:

 

Run Flag / Result / Function Name / Data 1 / Data 2 / Data 3 / ...... up to as many Data inputs as you want.

 

Run Flag - indicates whether that line should be run or not.

Result - starts empty. Is populated when the test runs. (The input file becomes the high level results file. More details are stored in an associated log file)

Function Name - relates to a function in Test Complete.

Data 1-? - It reads along the row until it hits a blank cell. So you can have as much input data as you need. Each Data cell has to start with a prefix. The prefix tells it what the cell contains. "P:" is an input parameter. "E:" is an expected result. "FILE:" - is also an input parameter, but the input is in a file. It follows the path given and loads the text content of the file. "D:" is a dependency - which means check if the stated previous test line passed (or failed) and do (or don't) run this line as a result. "M:" is a marker - which is used when dependency checking (relying on line numbers in the spreadsheet would be bad). You can have as many markers, dependencies, input parameters, and expected results as you want or a function needs.

 

Similarly, it reads down the spreadsheet until it hits a blank line. This is assumed to be the end of a test. You can add notes easily enough by simply putting a note on a line (usually in a different colour so it stands out) but leaving the run flag blank.

 

When it completes a sheet, it looks in it's input folder to see if there are more. It works though all the ones it finds until they're done.

 

I provide the flexible framework. Others populate the spreadsheets for tests (can have many spreadsheets as well). So everything can be switched on or off. Test sheets can be moved in and out of the run folder. Individual tests within a sheet can be switched off independently. So it's fully granular. It also writes results to TFS via the TFS RESTful API. That can also be switched on and off during a run and can refer to multiple projects, suites and tests.

 

Obviously, this means I also have a TON of validation around my inputs. Have to. To stop bad input data crashing it. It also means I need to provide decent documentation so that the testers know what each function does. What it expects for input. And what it can check as an expected result.

 

All this is built as script extensions so it's all pretty much built into the IDE now.

 

Works great. But your error handling has to be VERY robust.

cancel
Showing results for 
Search instead for 
Did you mean: