I am experimenting with using QTP for some webapp ui automation testing and I was wondering how people usually write their QTP tests. Do you use the object map, descriptive programming, a combination or some other way all together? Any little code example would be appreciated, Thank you
Here's my suggestion.
1) Build your test automation requirements matrix.
You can use samples from my blog
http://automation-beyond.com/2009/06/06/qa-test-automation-requirements-usability/
http://automation-beyond.com/2009/06/07/qa-test-automation-requirements-usability-2/
http://automation-beyond.com/2009/06/10/qa-test-automation-requirements-5-maintainability/
http://automation-beyond.com/2009/06/08/qa-test-automation-requirements-robustness/
http://automation-beyond.com/2009/06/09/qa-test-automation-requirements-scalability/
2) Choose your automation approach
3) Write your testing scripts according to the approach you chose
Note. QTP Repository way or Descriptive Programming belong to GUI recognition part of front-end functional test automation. They matter in terms of robustness and maintenance.
Technically, it's nearly the same. In both cases you should understand GUI recognition concept well, or you will have problems no matter the approach.
You can store GUI object recognition properties in XML-like data structure and map the record to an English-like name. Whenever the original object's properties change, you update your record in repository, while a code still refers to a mapped name.
Or you can address GUI objects by directly putting same recognition properties into a function call. Whenever the original object's properties change, you have to do code change. But you don't have to maintain extra files along with your scripts.
A good framework should support both GUI-mapped and descriptive programming notations by operating at object reference level. I.e. you should keep object recognition and object interaction tasks separate.
Note that depending on context Descriptive Programming notation may slowdown performance of your scripts and it always demands extra maintenance effort while in other cases using Object Repositories only may lead to unwanted duplication of objects' descriptions or it may limit recognition of dynamically changing GUI.
I illustrate some points made above in the following article:
A little QTP performance test: Object Repository vs. Descriptive Programming
Straight code examples (for a practical automation I recommend GUI Function Wrapping).
Descriptive programming - addressing objects by physical description properties.
Dim sProfile
sProfile = "Guest"
Set objWebParent = Browser("title:=Select Profile").Page("title:=Select Profile")
Set objWebObject = objWebParent.Link("text:="&sProfile)
boolRC = objWebObject.Exist(0)
If Not boolRC Then
'error-handling
End If
objWebObject.Click
Addressing objects by mapped GUI names
Browser("Select Profile").Page("Select Profile").Link("Guest").Click
Thank you,
Albert Gareev
http://automation-beyond.com/
I know I am late here, and you must already have what you are looking for, but I wanted to provide my inputs as well for anyone visiting this topic.
I generally never use OR, unless I encounter an environment where Descriptive Programming is a no-go. Just recently, I worked with a Mainframe Front-End GUI application that has absolutely no naming convention for objects. If you choose to use Descriptive Programming with such an application, the only way to work with its objects would be through Index or Location Ordinal Identifiers, which is not the best course of action considering 100's of objects in each pane.
So, the answer to your question really depending upon the environment and your experience with OR and DP. Most people I have worked with at my job, and on online communities prefer to work with Descriptive Programming whenever its feasible. However, I have also seen people work wonders with OR.
I have a few code samples, but, unfortunately, they are deal with Descriptive Programming. For instance, the following article talks about creating modular VBScript classes to divide application's functionality into small manageable components:
http://relevantcodes.com/qtp-using-classes-as-test-modules-i/
Similarly, this article shows how Descriptive Programming can be used to verify multiple properties of target objects through a single block of code:
http://relevantcodes.com/qtp-verify-multiple-object-properties-an-elegant-approach/
Also, a demo framework is also available for you to view here:
http://relevantcodes.com/relevantcodes1one-qtp-automation-framework/
The framework is built completely on the principles of Descriptive Programming, but in the next release, some functionality will be added that will enable users to work with ORs as well.
Thank you,
Anshoo Arora
(Thanks for linking to the original articles, Motti)
Related
Can someone direct me to online resources for designing and implementing abstract semantic graphs (ASG)? I want to create an ASG editor for my language. Being able to edit the ASG directly has a number of advantages:
Only identifiers and literals need to be typed in and identifiers are written only once, when they're defined. Everything else is selected via the mouse.
Since the editor knows the language's grammar, there are no more syntax errors. The editor prevents them from being created in the first place.
Since the editor knows the language's semantics, there are no more semantic errors.
There are some secondary advantages:
Since all the reserved words are easily separable, a program can be written in one locale and viewed in other. On-the-fly changes of locale are possible.
All the text literals are easily separable, so changes of locale are easily made, including on-the-fly changes.
I'm not aware of a book on the matter, but you'll find the topic discussed in portions of various books on computer language. You'll also find discussions of this surrounding various projects which implement what you describe. For instance, you'll find quite a bit of discussion regarding the design of Scratch. Most workflow engines are also based on scripting in semantic graphs.
Allow me to opine... We've had the technology to manipulate language structurally for basically as long as we've had programming languages. I believe that the reason we still use textual language is a combination of the fact that it is more natural for us as humans, who communicate in natural language, to wield, and the fact that it is sometimes difficult to compose and refactor code when proper structure has to be maintained. If you're not sure what I mean, try building complex expressions in Scratch. Text is easier and a decent IDE gives virtually as much verification of correct structure.*
*I don't mean to take anything away from Scratch, it's a thing of beauty and is perfect for its intended purpose.
What is the frst step in OOD?
There are no steps, it's not a process.
The answer is..
(source: headfirstlabs.com)
http://headfirstlabs.com/books/hfooad/
http://www.amazon.com/dp/0596008678/?tag=forelangstud-20
Practice, read broadly and more practice.
Especially with others to review and comment on approaches.
Reading should cover not just OOD, but also patterns to see how others have approached common problems.
It's a lot of practice. The first thing is to get your mind around the way objects work--especially if you are a procedural programmer.
Practice making many small objects--I've literally never seen a system with too many objects; it's possible but I've never seen it. It should be really obvious when you need to put many objects into one, but it's not as obvious when an object should be broken up.
Ask an object to do something, don't ask for it's data. Try to avoid getters and setters and concentrate on methods where you ask it to do something with it's data. If you EVER see code like o.a=o.b+o.c or o.setA(o.getB()+o.getC() you are doing it wrong.
Constantly try to refactor out duplication. Rewrite your code repeatedly until there is none (or as little as possible). This will probably do more for your OO design skills than any other practice. As you get more knowledgeable, try refactoring things you didn't think you could refactor before. Anything that even looks like a pattern can probably be refactored. For instance here's a very basic example--if you had lines of code that looked like this:
a = b + c * d;
g = h + i * d;
Chances are there are HUGE refactorings missing in your code even though it doesn't look like it off the bat. You probably are missing an object that would hold a,b,c and a second instance would hold g,h,i, after creating these objects a bunch of stuff would factor into your new object. Learning to recognize new opportunities like this is critical.
I've been programming for over 20 years now, over half of it has been OO at this point and it seems like every few years I think I know it all--a year later I look back and realize how ignorant I was.
the first step is object oriented analysis - its aim is to identify the objects that make up a system and how they interact; given this knowledge you can then specify the behavior of the object (the interface methods) and then the internals (what are the required data members of an object)
The design process produces a number of diagrams - these are tools that are supposed to help with working out the details of the system :
first come a set of 'use cases' - a use case is a verbal description of a scenario that is implemented by the system (one is supposed to pick the most substantial ones); these are then used to identify the main actors and concepts which are supposed to map to the classes of a system. This understanding is then refined by working out 'object interaction diagrams' 'class diagrams' and 'sequence diagrams' sometimes state charts are used to visual state machines - these diagrams are tools to gain an even better understanding of the system, as a result you have a sufficient understanding of the system to write the class header files/class definitions. There are no fixed rules which one of these diagrams come first, these are used as appropriate.
i found the following book very useful :
OBJECT-ORIENTED ANALYSIS AND DESIGN With applications (second edition) by Grady Booch
the book goes through the process of designing several example systems step by step (i think it is enough to read the design process for these example systems); One minor problem is that the notation used in this book is a bit dated : modern practice is to use the UML notation for diagrams, however the book still uses the older Booch notation. The strong point of the book is that it is always explaining each concept by working through concrete examples.
There are some preliminary steps:
Understand OOD (in general)
Understand the problem/application domain (the functional specification)
Have a high-level/architectural design: know what O/S, libraries, frameworks etc. you can use
I then use a mixture of top-down and bottom-up development:
Top-down: decide what components and what APIs (object interfaces) I would like to have in order to implement the application (and then, develope those API)
Bottom-up: decide how to add new functionality to existing APIs (object interfaces), by adding new methods and new types of object (and sometimes splitting a large object into several smaller objects).
The first step of OOD are the OOD principles. Check out The Principles of OOD.
I am a programmer trying to learn to code in the object oriented paradigm... I mainly work with PHP and i thought of learning the zend framework... So, felt I need to learn to code in OO PHP....
The problem is, having done code using functions for quite a long time, i just can't get my head to think in the OO way....
Also felt that probably I am not the only one facing this problem since the beginning of time...
So, how did you people learn object oriented programming... especially how did you succeed in "unlearning" to code using functions... and learn to see you code as objects...?
Is there any good resource books or sites where one could find help...??
Thanks for sharing your knowledge and experiences...
I've been doing software development with OO for over 20 years now, and I can tell you that looking at other peoples code is more often than not going to teach you how to do procedural programming in an object oriented language.
What I would recommend is to use the following techniques, which if applied liberally, will force you to use OO techniques, even though you may not yet be aware of them.
Do not copy and paste code - ever.
Create classes that represent the things you talk about when talking about the functionality - for example, an order entry system will have Orders, Customers, Accounts, OrderItems, InventoryItems, etc.
When creating these classes, do NOT code any public set and get methods to access the class data members.
Add methods to these domain model classes that perform the work on the object in question. Order.invoice(), account.close(), InventoryItem.decrement(). The lack of public get methods will show you the correct location for the code (where the data is - in the appropriate domain object). Remember, an object is data and the code that operates on it - anything short of both is not an object.
You will eventually find that you have to add some public get methods for some class members, and that is ok, just hold off until you are forced to do so. Reluctantly add public get methods.
At the level of the application, almost every line of code should be moving mountains. In other words, most of the lines of code at the application level should be calling on domain model methods.
Put all of the functionality in the domain model objects, then expose that functionality in an application by hooking it up to a user interface. I repeat, put the functionality in the domain model, not the application.
If you follow these guidelines, you will definitely be producing object oriented code, and probably at a much higher level of proficiency than many experienced developers.
Finally, avoid injection - i.e. Spring, Unity, etc!! There are probably a handful of valid cases for using injection - most uses arise out of a lack of object oriented design experience. As a guideline for whether to inject or not, consider how often what you are thinking of injecting is likely to change. In many, many cases, I find that what is being injected will never change - in these cases, the only thing being injected is pure overhead.
Good luck!
Read other people's code - people who you know are good developers
Books/articles that teach "idomatic usage" of the language
(Avoid anything with the words "in 21 days")
It takes time.
Moving from procedural programming to object oriented is difficult. These days, many people start with object oriented, so they don't struggle with this paradigm change.
Learn about the fundamentals of OOP and keep referring to them to start with.
Read OO code - there are lots of open source projects out there that you could sample.
read one of the following book
2015_Book_Object-OrientedAnalysisDesignA
Head First Design Patterns By Eric Freeman and Elisabeth Freeman Small
Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D
enjoy
PDF LINKS
1) Head First Object-Oriented Analysis and Design
Head First Object-Oriented Analysis and Design.pdf
2) Head First Design Patterns
Head First Design Patterns.pdf
At the moment I am learning Objective-C 2. I'm aware that it's used heavily by Mac developers, but I'm more interested in learning the language at this point in time than the frameworks for developing on Mac OS X/iPhone (except for Foundation). In order to do this I want to write a few intermediate* console applications, but I'm stuck for ideas.
Most examples are something along the lines of "Write a Fraction class that has getters/setters and a print function", which isn't very challenging coming from a C++ background. I'd like some generic examples of programs, but I don't want them to include any Objective-C implementation details. I want to figure out the program structure/write my own interfaces and learn the language from there.
In summary: I am curious as to what example programs Objective-C programmers would recommend for exploring the language.
An example of an "intermediate" application would be something along the lines of "Write a program that takes a URL from the command line and returns the number of occurrences of a certain word in data returned:
example -url www.google.com -word search
"Project Euler" is a standard response for this kind of thing, but I get the feeling that you're less interested in being told to implement algorithmic stuff (since that knowledge is easier to port between languages) and more interested in miniprojects that will familiarize you with core libraries. Is this fair?
If so, IMO, you ought to know the basics of how to do the following with the standard libraries of language you hope to use for serious work:
Standard IO
Network IO
Disk IO and navigating the filesystem
Regexp utilities
Structured data (XML libraries and CSV libraries if they exist)
Programming problems I would recommend for those:
It sounds like you've already done this.
A very simple proxy - something like what you described in your post, but that listens on a port for a message containing a URL rather than taking it on the command line, and likewise returns the results to whatever contacted it over the network rather than outputting to stdio. [Obviously you need to have the machine behind an appropriate firewall for this!]
Something which takes a directory path and recursively tallies the number of lines its children contain. (So, get the directory's listing, open each child file and count the number of line breaks. Then open each of its child directories, get their listings, ...) Record any errors encountered (e.g., no read privileges) in a reasonable way. Write out the final results to file in the directory supplied.
Usually if I tool around in a language enough, I'll run across some problem which I just naturally find myself using regexps for. I'll assume the same is true for you and punt this element for now.
Fetch StackOverflow.com, and [by putting it into a DOM model and navigating that] determine whether this question is still on the front page.
I got the most out of Objective-C by exploring it with a testing framework. I have written a short blog post about it. You should also wrap your head around the memory management conventions employed by Objective-C, reference counting takes a little time to get used to but works very well if responsibilities are clearly segregated (I have written about that on my blog too).
By getting my hands dirty on a testing framework (GHUnit for that matter), I was able to learn far more about the language than I could have in a "traditional" way. Of course you'll need a little pet project, otherwise this approach doesn't make sense.
I don't think your example is a very good idea as it requires you to mess with http connections, resources etc. which is a little framework specific after all. Parsing a text file would be a little easier in this regard. Using a unit testing framework has the following advantages for you:
learn about platform specific build systems and deployment details
forced to develop components in a loosely coupled fashion from the ground up
thereby exploring unique mechanisms of the language, that might require new or make known patterns redundant (e.g. categories make dependency injection obsolete etc.)
fast compile-test cycle, less time spent in front of the debugger
combined with source control: painless experiments
You should also look into the testing framework implementation, as testing frameworks always require to work with metadata to some extend. Testing frameworks are often used together with isolation frameworks. They basically create objects at runtime that comply to certain interfaces and act as stand-ins for concrete objects. Looking at their implementation will teach you about the runtime manipulations that can be done in Objective-C (keyword: Method-Swizzling)
I asked this question about Microsoft .NET Libraries and the complexity of its source code. From what I'm reading, writing general purpose libraries and writing applications can be two different things. When writing libraries, you have to think about the client who could literally be everyone (supposing I release the library for use in the general public).
What kind of practices or theories or techniques are useful when learning to write libraries? Where do you learn to write code like the one in the .NET library? This looks like a "black art" which I don't know too much about.
That's a pretty subjective question, but here's on objective answer. The Framework Design Guidelines book (be sure to get the 2nd edition) is a very good book about how to write effective class libraries. The content is very good and the often dissenting annotations are thought-provoking. Every shop should have a copy of this book available.
You definitely need to watch Josh Bloch in his presentation How to Design a Good API & Why it Matters (1h 9m long). He is a Java guru but library design and object orientation are universal.
One piece of advice often ignored by library authors is to internalize costs. If something is hard to do, the library should do it. Too often I've seen the authors of a library push something hard onto the consumers of the API rather than solving it themselves. Instead, look for the hardest things and make sure the library does them or at least makes them very easy.
I will be paraphrasing from Effective C++ by Scott Meyers, which I have found to be the best advice I got:
Adhere to the principle of least astonishment: strive to provide classes whose operators and functions have a natural syntax and an intuitive semantics. Preserve consistency with the behavior of the built-in types: when in doubt, do as the ints do.
Recognize that anything somebody can do, they will do. They'll throw exceptions, they'll assign objects to themselves, they'll use objects before giving them values, they'll give objects values and never use them, they'll give them huge values, they'll give them tiny values, they'll give them null values. In general, if it will compile, somebody will do it. As a result, make your classes easy to use correctly and hard to use incorrectly. Accept that clients will make mistakes, and design your classes so you can prevent, detect, or correct such errors.
Strive for portable code. It's not much harder to write portable programs than to write unportable ones, and only rarely will the difference in performance be significant enough to justify unportable constructs.
Even programs designed for custom hardware often end up being ported, because stock hardware generally achieves an equivalent level of performance within a few years. Writing portable code allows you to switch platforms easily, to enlarge your client base, and to brag about supporting open systems. It also makes it easier to recover if you bet wrong in the operating system sweepstakes.
Design your code so that when changes are necessary, the impact is localized. Encapsulate as much as you can; make implementation details private.
Edit: I just noticed I very nearly duplicated what cherouvim had posted; sorry about that! But turns out we're linking to different speeches by Bloch, even if the subject is exactly the same. (cherouvim linked to a December 2005 talk, I to January 2007 one.) Well, I'll leave this answer here — you're probably best off by watching both and seeing how his message and way of presenting it has evolved :)
FWIW, I'd like to point to this Google Tech Talk by Joshua Bloch, who is a greatly respected guy in the Java world, and someone who has given speeches and written extensively on API design. (Oh, and designed some exceptionally good general purpose libraries, like the Java Collections Framework!)
Joshua Bloch, Google Tech Talks, January 24, 2007:
"How To Design A Good API and Why it
Matters" (the video is about 1 hour long)
You can also read many of the same ideas in his article Bumper-Sticker API Design (but I still recommend watching the presentation!)
(Seeing you come from the .NET side, I hope you don't let his Java background get in the way too much :-) This really is not Java-specific for the most part.)
Edit: Here's another 1½ minute bit of wisdom by Josh Bloch on why writing libraries is hard, and why it's still worth putting effort in it (economies of scale) — in a response to a question wondering, basically, "how hard can it be". (Part of a presentation about the Google Collections library, which is also totally worth watching, but more Java-centric.)
Krzysztof Cwalina's blog is a good starting place. His book, Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, is probably the definitive work for .NET library design best practices.
http://blogs.msdn.com/kcwalina/
The number one rule is to treat API design just like UI design: gather information about how your users really use your UI/API, what they find helpful and what gets in their way. Use that information to improve the design. Start with users who can put up with API churn and gradually stabilize the API as it matures.
I wrote a few notes about what I've learned about API design here: http://www.natpryce.com/articles/000732.html
I'd start looking more into design patterns. You'll probably not going to find much use for some of them, but as you get deeper into your library design the patterns will become more applicable. I'd also pick up a copy of NDepend - a great code measuring utility which may help you decouple things better. You can use .NET libraries as an example, but, personally, i don't find them to be great design examples mostly due to their complexities. Also, start looking at some open source projects to see how they're layered and structured.
A couple of separate points:
The .NET Framework isn't a class library. It's a Framework. It's a set of types meant to not only provide functionality, but to be extended by your own code. For instance, it does provide you with the Stream abstract class, and with concrete implementations like the NetworkStream class, but it also provides you the WebRequest class and the means to extend it, so that WebRequest.Create("myschema://host/more") can produce an instance of your own class deriving from WebRequest, which can have its own GetResponse method returning its own class derived from WebResponse, such that calling GetResponseStream will return your own class derived from Stream!
And your callers will not need to know this is going on behind the scenes!
A separate point is that for most developers, creating a reusable library is not, and should not be the goal. The goal should be to write the code necessary to meet requirements. In the process, reusable code may be found. In that case, it should be refactored out into a separate library, where it can be reused in the future.
I go further than that (when permitted). I will usually wait until I find two pieces of code that actually do the same thing, or which overlap. Presumably both pieces of code have passed all their unit tests. I will then factor out the common code into a separate class library and run all the unit tests again. Assuming that they still pass, I've begun the creation of some reusable code that works (since the unit tests still pass).
This is in contrast to a lesson I learned in school, when the result of an entire project was a beautiful reusable library - with no code to reuse it.
(Of course, I'm sure it would have worked if any code had used it...)