Performance Testing - Load testing
Load testing: is subjecting a system to a statistically representative (usually) load. The two main reasons for using such loads is in support of software reliability testing and in performance testing. The term "load testing" by itself is too vague and imprecise to warrant use. For example, do you mean representative load," "overload," "high load," etc. In performance testing, load is varied from a minimum (zero) to the maximum level the systemcan sustain without running out of resources or having, transactions suffer (application-specific) excessive delay.
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Monday, June 29, 2009
Integration Testing
Integration Testing
One of the most difficult aspects of software development is the integration and testing of large, untested sub-systems. The integrated system frequently fails in significant and mysterious ways, and it is difficult to fix it
Integration testing exercises several units that have been combined to form a module, subsystem, or system. Integration testing focuses on the interfaces between units, to make sure the units work together. The nature of this phase is certainly 'white box', as we must have a certain knowledge of the units to recognize if we have been successful in fusing them together in the module.
There are three main approaches to integration testing: top-down, bottom-up and 'big bang'. Top-down combines, tests, and debugs top-level routines that become the test 'harness' or 'scaffolding' for lower-level units. Bottom-up combines and tests low-level units into progressively larger modules and subsystems. 'Big bang' testing is, unfortunately, the prevalent integration test 'method'. This is waiting for all the module units to be complete before trying them out together.
Integration tests can rely heavily on stubs or drivers. Stubs stand-in for finished subroutines or sub-systems. A stub might consist of a function header with no body, or it may read and return test data from a file, return hard-coded values, or obtain data from the tester. Stub creation can be a time consuming piece of testing.
The cost of drivers and stubs in the top-down and bottom-up testing methods is what drives the use of 'big bang' testing. This approach waits for all the modules to be constructed and tested independently, and when they are finished, they are integrated all at once. While this approach is very quick, it frequently reveals more defects than the other methods. These errors have to be fixed and as we have seen, errors that are found 'later' take longer to fix. In addition, like bottom up, there is really nothing that can be demonstrated until later in the process.
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
One of the most difficult aspects of software development is the integration and testing of large, untested sub-systems. The integrated system frequently fails in significant and mysterious ways, and it is difficult to fix it
Integration testing exercises several units that have been combined to form a module, subsystem, or system. Integration testing focuses on the interfaces between units, to make sure the units work together. The nature of this phase is certainly 'white box', as we must have a certain knowledge of the units to recognize if we have been successful in fusing them together in the module.
There are three main approaches to integration testing: top-down, bottom-up and 'big bang'. Top-down combines, tests, and debugs top-level routines that become the test 'harness' or 'scaffolding' for lower-level units. Bottom-up combines and tests low-level units into progressively larger modules and subsystems. 'Big bang' testing is, unfortunately, the prevalent integration test 'method'. This is waiting for all the module units to be complete before trying them out together.
Integration tests can rely heavily on stubs or drivers. Stubs stand-in for finished subroutines or sub-systems. A stub might consist of a function header with no body, or it may read and return test data from a file, return hard-coded values, or obtain data from the tester. Stub creation can be a time consuming piece of testing.
The cost of drivers and stubs in the top-down and bottom-up testing methods is what drives the use of 'big bang' testing. This approach waits for all the modules to be constructed and tested independently, and when they are finished, they are integrated all at once. While this approach is very quick, it frequently reveals more defects than the other methods. These errors have to be fixed and as we have seen, errors that are found 'later' take longer to fix. In addition, like bottom up, there is really nothing that can be demonstrated until later in the process.
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Functional testing
Functional testing
Functional testing: Application of test data derived from the specified functional requirements without regard to the final program structure. Also known as black-box testing.
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Functional testing: Application of test data derived from the specified functional requirements without regard to the final program structure. Also known as black-box testing.
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Exploratory Testing
Exploratory Testing
An interactive process of concurrent product exploration, test
design, and test execution. The heart of exploratory testing can be
stated simply: The outcome of this test influences the design of the
next test.
The plainest definition of exploratory testing is test design and
test execution at the same time. This is the opposite of scripted
testing (predefined test procedures, whether manual or automated).
Exploratory tests, unlike scripted tests, are not defined in advance
and carried out precisely according to plan. This may sound like a
straightforward distinction, but in practice it's murky. That's
because "defined" is a spectrum. Even an otherwise elaborately
defined test procedure will leave many interesting details (such as
how quickly to type on the keyboard, or what kinds of behavior to
recognize as a failure) to the discretion of the tester. Likewise,
even a free-form exploratory test session will involve tacit
constraints or mandates about what parts of the product to test, or
what strategies to use. A good exploratory tester will write down
test ideas and use them in later test cycles. Such notes sometimes
look a lot like test scripts, even if they aren't. Exploratory
testing is sometimes confused with "ad hoc" testing. Ad hoc testing
normally refers to a process of improvised, impromptu bug searching.
By definition, anyone can do ad hoc testing
What kinds of specifics affect ET? Here are some of them:
1. the mission of the test project
2. the mission of this particular test session
3. the role of the tester
4. the tester (skills, talents, and preferences)
5. available tools and facilities
6. available time
7. available test data and materials
8. available help from other people
9. accountability requirements
10. what the tester‘s clients care about
11. the current testing strategy
12. the status of other testing efforts on the same product
13. the product, itself- its user interface - its behavior - its
present state of execution - its defects- its testability- its
purpose
14. what the tester knows about the product- what just happened in
the previous test - known problems with it- past problems with it -
strengths and weaknesses - risk areas and magnitude of perceived risk
- recent changes to it - direct observations of it- rumors about it -
the nature of its users and user behavior - how it‘s supposed to work
- how it‘s put together - how it‘s similar to or different from other
products
15. what the tester would like to know about the product
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about
software testing.
http://www.crestech.in
href="http://www.crestechsoftware.com.au">http://www.crestechsoftware
.com.au
An interactive process of concurrent product exploration, test
design, and test execution. The heart of exploratory testing can be
stated simply: The outcome of this test influences the design of the
next test.
The plainest definition of exploratory testing is test design and
test execution at the same time. This is the opposite of scripted
testing (predefined test procedures, whether manual or automated).
Exploratory tests, unlike scripted tests, are not defined in advance
and carried out precisely according to plan. This may sound like a
straightforward distinction, but in practice it's murky. That's
because "defined" is a spectrum. Even an otherwise elaborately
defined test procedure will leave many interesting details (such as
how quickly to type on the keyboard, or what kinds of behavior to
recognize as a failure) to the discretion of the tester. Likewise,
even a free-form exploratory test session will involve tacit
constraints or mandates about what parts of the product to test, or
what strategies to use. A good exploratory tester will write down
test ideas and use them in later test cycles. Such notes sometimes
look a lot like test scripts, even if they aren't. Exploratory
testing is sometimes confused with "ad hoc" testing. Ad hoc testing
normally refers to a process of improvised, impromptu bug searching.
By definition, anyone can do ad hoc testing
What kinds of specifics affect ET? Here are some of them:
1. the mission of the test project
2. the mission of this particular test session
3. the role of the tester
4. the tester (skills, talents, and preferences)
5. available tools and facilities
6. available time
7. available test data and materials
8. available help from other people
9. accountability requirements
10. what the tester‘s clients care about
11. the current testing strategy
12. the status of other testing efforts on the same product
13. the product, itself- its user interface - its behavior - its
present state of execution - its defects- its testability- its
purpose
14. what the tester knows about the product- what just happened in
the previous test - known problems with it- past problems with it -
strengths and weaknesses - risk areas and magnitude of perceived risk
- recent changes to it - direct observations of it- rumors about it -
the nature of its users and user behavior - how it‘s supposed to work
- how it‘s put together - how it‘s similar to or different from other
products
15. what the tester would like to know about the product
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about
software testing.
http://www.crestech.in
href="http://www.crestechsoftware.com.au">http://www.crestechsoftware
.com.au
Boundary Value Analysis
Boundary Value Analysis
Large number of errors tend to occur at boundaries of the input domain.
BVA leads to selection of test cases that exercise boundary values.
BVA complements equivalence partitioning. Rather than select any element in an equivalence class, select those at the ''edge' of the class.
Examples:
For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1).
If input conditions specify a number of values n, test with (n-1), n and (n+1) input values.
Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum size).
If internal program data structures have boundaries (e.g., buffer size, table limits), use input data to exercise structures on boundaries.
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Large number of errors tend to occur at boundaries of the input domain.
BVA leads to selection of test cases that exercise boundary values.
BVA complements equivalence partitioning. Rather than select any element in an equivalence class, select those at the ''edge' of the class.
Examples:
For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1).
If input conditions specify a number of values n, test with (n-1), n and (n+1) input values.
Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum size).
If internal program data structures have boundaries (e.g., buffer size, table limits), use input data to exercise structures on boundaries.
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
About Software Testing
About Software Testing
Process of evaluation of Software application: To verify it satisfy the specified requirements With intent to find errors To Check if the system ?Fit for Purpose? Simulation of real time scenarios.
Testing is not a one-time activity—applications need to be tested throughout their lifecycle. Every version upgrade, module addition, or enhancement, as well as every implementation at a new site or increase in user load, needs to be put through comprehensive testing. The Program Doesn‘t Work Nobody would pay you to test if their program didn‘t have bugs. All programs have bugs. Any change to a program can cause new bugs, and any aspect of the program can be broken. You DON‘T ?verify that the program is working.? You FIND bugs. “If you set your mind to show that a program works correctly, you’ll be more likely to miss problems than if you want and expect the program to fail.” Complete Testing is Impossible:
1. There are a nearly infinite number of paths through any non-trivial program.
2. There are a virtually infinite set of combinations of data that you can feed the program.
You can’t test them all.
1. Therefore, your task is to find bugs --not to find all the bugs.
2. You want to find as many bugs as possible
3. Find the most serious bugs
4. Find bugs as early as possible
5. Your challenges will require judgment, trade-offs, and efficiency.
“Q: How many QA testers does it take to change a lightbulb?
A: QA testers don't change anything. They just report that it's dark.” Kerry Zallar?
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Process of evaluation of Software application: To verify it satisfy the specified requirements With intent to find errors To Check if the system ?Fit for Purpose? Simulation of real time scenarios.
Testing is not a one-time activity—applications need to be tested throughout their lifecycle. Every version upgrade, module addition, or enhancement, as well as every implementation at a new site or increase in user load, needs to be put through comprehensive testing. The Program Doesn‘t Work Nobody would pay you to test if their program didn‘t have bugs. All programs have bugs. Any change to a program can cause new bugs, and any aspect of the program can be broken. You DON‘T ?verify that the program is working.? You FIND bugs. “If you set your mind to show that a program works correctly, you’ll be more likely to miss problems than if you want and expect the program to fail.” Complete Testing is Impossible:
1. There are a nearly infinite number of paths through any non-trivial program.
2. There are a virtually infinite set of combinations of data that you can feed the program.
You can’t test them all.
1. Therefore, your task is to find bugs --not to find all the bugs.
2. You want to find as many bugs as possible
3. Find the most serious bugs
4. Find bugs as early as possible
5. Your challenges will require judgment, trade-offs, and efficiency.
“Q: How many QA testers does it take to change a lightbulb?
A: QA testers don't change anything. They just report that it's dark.” Kerry Zallar?
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Performance Testing - Stress testing 2
Performance Testing - Stress testing 2
Stress testing :is subjecting a system to an unreasonable load while
denying it the resources (e.g., RAM, disc, mips, interrupts, etc.)
needed to process that load. The idea is to stress a system to the
breaking point in order to find bugs that will make that break
potentially harmful. The system is not expected to process the
overload without adequate resources, but to behave (e.g., fail) in a
decent manner (e.g., not corrupting or losing data). Bugs and failure
modes discovered under stress testing may or may not be repaired
depending on the application, the failure mode, consequences, etc.
The load (incoming transaction stream) in stress testing is often
deliberately distorted so as to force the system into resource
depletion.
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about
software testing.
http://www.crestech.in
href="http://www.crestechsoftware.com.au">http://www.crestechsoftware
.com.au
Stress testing :is subjecting a system to an unreasonable load while
denying it the resources (e.g., RAM, disc, mips, interrupts, etc.)
needed to process that load. The idea is to stress a system to the
breaking point in order to find bugs that will make that break
potentially harmful. The system is not expected to process the
overload without adequate resources, but to behave (e.g., fail) in a
decent manner (e.g., not corrupting or losing data). Bugs and failure
modes discovered under stress testing may or may not be repaired
depending on the application, the failure mode, consequences, etc.
The load (incoming transaction stream) in stress testing is often
deliberately distorted so as to force the system into resource
depletion.
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about
software testing.
http://www.crestech.in
href="http://www.crestechsoftware.com.au">http://www.crestechsoftware
.com.au
Why White box testing when black box testing is there to test conformance to requirements
Why White box testing when black box testing is there to test conformance to requirements
Logic errors and incorrect assumptions most likely to be made when coding for "special cases". Need to ensure these execution paths are tested.
May find assumptions about execution paths incorrect, and so make design errors. White box testing can find these errors.
Typographical errors are random. Just as likely to be on an obscure logical path as on a mainstream path.
Software Testing Training
Software testing institute
corporate training software testing
Logic errors and incorrect assumptions most likely to be made when coding for "special cases". Need to ensure these execution paths are tested.
May find assumptions about execution paths incorrect, and so make design errors. White box testing can find these errors.
Typographical errors are random. Just as likely to be on an obscure logical path as on a mainstream path.
Software Testing Training
Software testing institute
corporate training software testing
Regression Testing
Regression Testing
Testing conducted for the purpose of evaluating whether or not a change to the system (all CM items) has introduced a new failure. Regression testing is often accomplished through the construction, execution and analysis of product and system tests.
Regression testing is an expensive but necessary activity performed on modified software to provide confidence that changes are correct and do not adversely affect other system components. Four things can happen when a developer attempts to fix a bug. Three of these things are bad, and one is good:
Because of the high probability that one of the bad outcomes will result from a change to the system, it is necessary to do regression testing.
It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Most industrial testing is done via test suites; automated sets of procedures designed to exercise all parts of a program and to show defects. While the original suite could be used to test the modified software, this might be very time-consuming. A regression test selection technique chooses, from an existing test set, the tests that are deemed necessary to validate modified software.
There are three main groups of test selection approaches in use:
Minimization approaches seek to satisfy structural coverage criteria by identifying a minimal set of tests that must be rerun.
Coverage approaches are also based on coverage criteria, but do not require minimization of the test set. Instead, they seek to select all tests that exercise changed or affected program components.
Safe attempt instead to select every test that will cause the modified program to produce different output than original program.
An interesting approach to limiting test cases is based on whether we can confine testing to the "vicinity" of the change. (Ex. If I put a new radio in my car, do I have to do a complete road test to make sure the change was successful?) A new breed of regression test theory tries to identify, through program flows or reverse engineering, where boundaries can be placed around modules and subsystems. These graphs can determine which tests from the existing suite may exhibit changed behavior on the new version.
Regression testing has been receiving more attention as corporations focus on fixing the 'Year 2000 Bug'. The goal of most Y2K is to correct the date handling portions of their system without changing any other behavior. A new 'Y2K' version of the system is compared against a baseline original system. With the obvious exception of date formats, the performance of the two versions should be identical. This means not only do they do the same things correctly, they also do the same things incorrectly. A non-Y2K bug in the original software should not have been fixed by the Y2K work.
A frequently asked question about regression testing is 'The developer says this problem is fixed. Why do I need to re-test?’ to which the answer is 'The same person probably told you it worked in the first place'
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Testing conducted for the purpose of evaluating whether or not a change to the system (all CM items) has introduced a new failure. Regression testing is often accomplished through the construction, execution and analysis of product and system tests.
Regression testing is an expensive but necessary activity performed on modified software to provide confidence that changes are correct and do not adversely affect other system components. Four things can happen when a developer attempts to fix a bug. Three of these things are bad, and one is good:
Because of the high probability that one of the bad outcomes will result from a change to the system, it is necessary to do regression testing.
It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Most industrial testing is done via test suites; automated sets of procedures designed to exercise all parts of a program and to show defects. While the original suite could be used to test the modified software, this might be very time-consuming. A regression test selection technique chooses, from an existing test set, the tests that are deemed necessary to validate modified software.
There are three main groups of test selection approaches in use:
Minimization approaches seek to satisfy structural coverage criteria by identifying a minimal set of tests that must be rerun.
Coverage approaches are also based on coverage criteria, but do not require minimization of the test set. Instead, they seek to select all tests that exercise changed or affected program components.
Safe attempt instead to select every test that will cause the modified program to produce different output than original program.
An interesting approach to limiting test cases is based on whether we can confine testing to the "vicinity" of the change. (Ex. If I put a new radio in my car, do I have to do a complete road test to make sure the change was successful?) A new breed of regression test theory tries to identify, through program flows or reverse engineering, where boundaries can be placed around modules and subsystems. These graphs can determine which tests from the existing suite may exhibit changed behavior on the new version.
Regression testing has been receiving more attention as corporations focus on fixing the 'Year 2000 Bug'. The goal of most Y2K is to correct the date handling portions of their system without changing any other behavior. A new 'Y2K' version of the system is compared against a baseline original system. With the obvious exception of date formats, the performance of the two versions should be identical. This means not only do they do the same things correctly, they also do the same things incorrectly. A non-Y2K bug in the original software should not have been fixed by the Y2K work.
A frequently asked question about regression testing is 'The developer says this problem is fixed. Why do I need to re-test?’ to which the answer is 'The same person probably told you it worked in the first place'
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Performance Testing - Volume Testing
Performance Testing - Volume Testing
Volume Testing: Testing where the system is subjected to large volumes of data. As regards faults that should be found through volume testing are those, where the behaviour of the software deviates from that expected for a specified volume of data. Thus a bank system will be tested for faults at much larger volumes of data, than that of small retailer software. A fault which is only manifested on a table with a million records will be of no concern to the retail software, but will be picked up by the bank testers.
For example, a window often used window object is populated with data, by calling a database object which runs a complex SQL query. Supposing the component is tested against tables with only 4-5 records. Of course it will return within seconds. Everything seems fine. It is then integrated with the window, and system tested. Again everything seems ok. It is only when the application is in User Acceptance (or even gone live) and it is tested against 100,000 records, is it discovered that, the SQL was not properly optimized and the tables not indexed. Thus it should have been tested at the component level.
Volume testing needs two things. Firstly clear expected outcomes of how the software is to behave for a given level of data. Secondly, data, and lots of it.
The expected behaviour at various levels, should be in the specification documentation. Ideally this will say something like "the customers details will be returned returned on the screen within 3 seconds, from a database with 1 million customer records." This gives the tester a benchmark to base a test case on.
The second requirement for data, needs either real life data, or simulated data. Usually, real life data will come in the form of a customer database, that has had private information, such as names and account numbers scrambled. Alternatively records can be created from scratch using automated tools or by adding rules directly on to the database, with SQL.
As with all testing, proper records must be kept showing the inputs, outputs other information, to aid potential debugging and audit purposes
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Volume Testing: Testing where the system is subjected to large volumes of data. As regards faults that should be found through volume testing are those, where the behaviour of the software deviates from that expected for a specified volume of data. Thus a bank system will be tested for faults at much larger volumes of data, than that of small retailer software. A fault which is only manifested on a table with a million records will be of no concern to the retail software, but will be picked up by the bank testers.
For example, a window often used window object is populated with data, by calling a database object which runs a complex SQL query. Supposing the component is tested against tables with only 4-5 records. Of course it will return within seconds. Everything seems fine. It is then integrated with the window, and system tested. Again everything seems ok. It is only when the application is in User Acceptance (or even gone live) and it is tested against 100,000 records, is it discovered that, the SQL was not properly optimized and the tables not indexed. Thus it should have been tested at the component level.
Volume testing needs two things. Firstly clear expected outcomes of how the software is to behave for a given level of data. Secondly, data, and lots of it.
The expected behaviour at various levels, should be in the specification documentation. Ideally this will say something like "the customers details will be returned returned on the screen within 3 seconds, from a database with 1 million customer records." This gives the tester a benchmark to base a test case on.
The second requirement for data, needs either real life data, or simulated data. Usually, real life data will come in the form of a customer database, that has had private information, such as names and account numbers scrambled. Alternatively records can be created from scratch using automated tools or by adding rules directly on to the database, with SQL.
As with all testing, proper records must be kept showing the inputs, outputs other information, to aid potential debugging and audit purposes
Software Testing Training
http://www.qacampus.com
QACampus is Center of Education for anything and everything about software testing.
http://www.crestech.in
http://www.crestechsoftware.com.au
Tuesday, May 26, 2009
Automated Functional Testing
Automated Functional Testing
By Bhrigu Malhotra
First of all let me make you all aware that I’m a developer and what you are going to read further is a developer’s account, so it may sound to you like a layman tester. But what I’m going to share is something which has been very helpful to me to ‘functionally’ test the web application our team has been building and I thought this may help you as well. So even if you are a tester, try to think the way developer’s think for some time, I’m sure this would be useful to you too.
Before I go ahead, I think we all understand that Functional Testing is testing the functionality of our application which means you’d probably be going through a login using some credentials, clicking some links, verifying some outputs - in simplest terms. Now just give it a thought that if you can automate these i.e. invest some time for once and then while you are sipping a cup of coffee, someone is testing what you coded. Change your code 10 times and run your test 10 times to ensure nothing breaks, so easy. Not just this if you have continuous integration server setup which runs your tests, you’d come to know immediately if and when someone else broke your code. Believe me ones who have used it, feel it is fantastic.
There are a variety of tools available for this over internet each with pros/cons but I’m going to share some info here about one which I liked very much and have been using for a while now. I’d also share why I preferred it over others.
Ok, no longer prolonging the suspense the tool I’m talking about is called Canoo WebTest (webtest.canoo.com) which is a free Open Source tool for automated testing of web applications in a very effective way. The primary reason why I liked it is that it is FAST; very fast … most of the test cases that I’ve written are executed in less than a minute and that too over remote applications deployed on servers on the other side of globe. Second reason for liking it so much is the ease of writing; very quickly you can build up your tests. Though they have released a WebTest recorder plug-in which when installed in Mozilla Firefox can record the script for you, but believe me the more you start writing there test cases, the less reliant you will become on the recorder. Third thing is these tests do not use a browser so that completely eliminated browser-specific issues which some tools are plagued with.
Now some things about WebTest which some people don’t like is you actually do not see the tests being executed i.e. loading of a browser window, automatic clicking on buttons and errors on the screen (if any). But that I feel that it is so by design …. Doing all this takes time and then browser issues too creep in, so I’m happy like this way only. I agree they can improve on reporting of errors but again the objective of this tool is to test and just to test, if you want to report issues manual intervention is needed.
At last I’ll just say go give it a try, I’m sure once past initial hiccups, you’ll start liking it the way I am.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Bhrigu Malhotra
First of all let me make you all aware that I’m a developer and what you are going to read further is a developer’s account, so it may sound to you like a layman tester. But what I’m going to share is something which has been very helpful to me to ‘functionally’ test the web application our team has been building and I thought this may help you as well. So even if you are a tester, try to think the way developer’s think for some time, I’m sure this would be useful to you too.
Before I go ahead, I think we all understand that Functional Testing is testing the functionality of our application which means you’d probably be going through a login using some credentials, clicking some links, verifying some outputs - in simplest terms. Now just give it a thought that if you can automate these i.e. invest some time for once and then while you are sipping a cup of coffee, someone is testing what you coded. Change your code 10 times and run your test 10 times to ensure nothing breaks, so easy. Not just this if you have continuous integration server setup which runs your tests, you’d come to know immediately if and when someone else broke your code. Believe me ones who have used it, feel it is fantastic.
There are a variety of tools available for this over internet each with pros/cons but I’m going to share some info here about one which I liked very much and have been using for a while now. I’d also share why I preferred it over others.
Ok, no longer prolonging the suspense the tool I’m talking about is called Canoo WebTest (webtest.canoo.com) which is a free Open Source tool for automated testing of web applications in a very effective way. The primary reason why I liked it is that it is FAST; very fast … most of the test cases that I’ve written are executed in less than a minute and that too over remote applications deployed on servers on the other side of globe. Second reason for liking it so much is the ease of writing; very quickly you can build up your tests. Though they have released a WebTest recorder plug-in which when installed in Mozilla Firefox can record the script for you, but believe me the more you start writing there test cases, the less reliant you will become on the recorder. Third thing is these tests do not use a browser so that completely eliminated browser-specific issues which some tools are plagued with.
Now some things about WebTest which some people don’t like is you actually do not see the tests being executed i.e. loading of a browser window, automatic clicking on buttons and errors on the screen (if any). But that I feel that it is so by design …. Doing all this takes time and then browser issues too creep in, so I’m happy like this way only. I agree they can improve on reporting of errors but again the objective of this tool is to test and just to test, if you want to report issues manual intervention is needed.
At last I’ll just say go give it a try, I’m sure once past initial hiccups, you’ll start liking it the way I am.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
Script Maintenance
Script Maintenance
By Renu Bala
Script maintenance is a great challenge faced by automation testers. As the course of development proceeds, applications undergo changes, which cause automation test scripts to break. For example, Developers change underlying attributes (like object name) that the test script rely upon to identify the object. So testers need to rework on scripts.
Script maintenance at some level is a fact of automation but too much maintenance can be a drain on team’s time, resulting in decreasing value of automation. Automation testing tool that build scripts that are resistant to breaking are extremely valuable.
Testers must constantly update scripts to handle minor application changes but testers may make mistakes when they update scripts.
One solution to these changes is to update the object map so that all scripts can reference updated object map and identify objects.
Second solution to these changes is Script Assure Technology introduced by Rational Functional Tester. This technology makes test scripts more resilient to changes in applications. With script assure technology, RFT evaluates the closeness of objects that it finds and attempts to match something that is closest. If objects are close enough, test continues with no intervention from tester and will log a warning so that tester is made aware of a possible discrepancy. So more tests can execute with less intervention, even with significant changes being made to objects in application. In this way RFT automatically finds changed target objects in application without object remapping. Benefit of this technology is reduced maintenance and more reliable scripts. Additionally, this flexibility is completely under tester’s control. Tester can determine what level of closeness is sufficient enough for the project.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Renu Bala
Script maintenance is a great challenge faced by automation testers. As the course of development proceeds, applications undergo changes, which cause automation test scripts to break. For example, Developers change underlying attributes (like object name) that the test script rely upon to identify the object. So testers need to rework on scripts.
Script maintenance at some level is a fact of automation but too much maintenance can be a drain on team’s time, resulting in decreasing value of automation. Automation testing tool that build scripts that are resistant to breaking are extremely valuable.
Testers must constantly update scripts to handle minor application changes but testers may make mistakes when they update scripts.
One solution to these changes is to update the object map so that all scripts can reference updated object map and identify objects.
Second solution to these changes is Script Assure Technology introduced by Rational Functional Tester. This technology makes test scripts more resilient to changes in applications. With script assure technology, RFT evaluates the closeness of objects that it finds and attempts to match something that is closest. If objects are close enough, test continues with no intervention from tester and will log a warning so that tester is made aware of a possible discrepancy. So more tests can execute with less intervention, even with significant changes being made to objects in application. In this way RFT automatically finds changed target objects in application without object remapping. Benefit of this technology is reduced maintenance and more reliable scripts. Additionally, this flexibility is completely under tester’s control. Tester can determine what level of closeness is sufficient enough for the project.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
How to Access Command prompt from QTP
How to Access Command prompt from QTP
By Parul Wahi
We can even access Microsoft Windows command prompt also known as MS-DOS from QTP interface.cmd.exe is a 32-bit command prompt used in Windows NT, 2000 and XP and offers disk and file maintenance functions as well as network functions. It can be found under System32 folder.
To launch cmd.exe from QTP write :
SystemUtil.Run “cmd.exe”, “”, “c:\WINDOWS\system32”,”open”
Once DOS window launches, this window can be leant and added to object repository
To write on command prompt window use the following code:
Window( “object class:=ConsoleWindowClass”).Type “Ping crestechsoftware.com”
Window( “object class:=ConsoleWindowClass”).Type micReturn
Using WshShell object
The WshShell object gives your scripts the ability to work with Windows shell .Your scripts can use the WshShell object to perform a number of system administration tasks, including running programs, reading from and writing to the registry, and creating shortcuts.
Following are the list of few methods used with wcript object:
1)The Environment property helps in getting environment variables
2)The Exec method returns a WshScriptExec object, which provides status and error information about a script run with Exec along with access to the StdIn, StdOut, and StdErr channels. The Exec method allows the execution of command line applications only.
3)Pop Up Method Displays text in a pop-up message box.
4)RegRead Method helps in reading from registry
Example
The following example demonstrates the basics of the Exec method.
Dim WshShell, oExec
Set WshShell = CreateObject(”WScript.Shell”)
Set oExec = WshShell.Exec(”calc”)
Do While oExec.Status = 0
WScript.Sleep 100
Loop
WScript.Echo oExec.Status
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Parul Wahi
We can even access Microsoft Windows command prompt also known as MS-DOS from QTP interface.cmd.exe is a 32-bit command prompt used in Windows NT, 2000 and XP and offers disk and file maintenance functions as well as network functions. It can be found under System32 folder.
To launch cmd.exe from QTP write :
SystemUtil.Run “cmd.exe”, “”, “c:\WINDOWS\system32”,”open”
Once DOS window launches, this window can be leant and added to object repository
To write on command prompt window use the following code:
Window( “object class:=ConsoleWindowClass”).Type “Ping crestechsoftware.com”
Window( “object class:=ConsoleWindowClass”).Type micReturn
Using WshShell object
The WshShell object gives your scripts the ability to work with Windows shell .Your scripts can use the WshShell object to perform a number of system administration tasks, including running programs, reading from and writing to the registry, and creating shortcuts.
Following are the list of few methods used with wcript object:
1)The Environment property helps in getting environment variables
2)The Exec method returns a WshScriptExec object, which provides status and error information about a script run with Exec along with access to the StdIn, StdOut, and StdErr channels. The Exec method allows the execution of command line applications only.
3)Pop Up Method Displays text in a pop-up message box.
4)RegRead Method helps in reading from registry
Example
The following example demonstrates the basics of the Exec method.
Dim WshShell, oExec
Set WshShell = CreateObject(”WScript.Shell”)
Set oExec = WshShell.Exec(”calc”)
Do While oExec.Status = 0
WScript.Sleep 100
Loop
WScript.Echo oExec.Status
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
How to Execute QTP script from Command Prompt using Automation Object Model
How to Execute QTP script from Command Prompt using Automation Object Model
By Parul Wahi
In order to run QTP scripts on schedule, we can run them directly from command line.
In order to do so we can make use of QTP Automation Object Model which can help us in automating QuickTest operations. Using the objects, methods, and properties exposed by the QuickTest automation object model, we can write scripts that configure QuickTest options and run tests instead of performing these operations manually using the QuickTest interface.
In the following code we are trying to execute a QTP script called “Google_search” from command line. Let’s create a script in QTP and save it as Google_search.Write the following code in a vbs (VB Script) file as save it as demo.vbs:
Dim qtApp ‘ Declare the Application object variable
Dim qtTest ‘ Declare a Test object variable
Dim qtResultsOpt ‘Declare a Run Results Options object variable
Set qtApp = CreateObject(”QuickTest.Application”) ‘ Create the Application object
qtApp.Launch ‘ Start QuickTest
qtApp.Visible = True ‘ Make the QuickTest application visible
qtApp.Open “C:\Documents and Settings\pwahi\Desktop\Google search“, True ‘ Open the test in read-only mode
‘ set run settings for the test
Set qtTest = qtApp.Test
qtTest.Run’ Run the test
WScript.StdOut.Write “Status is:” & qtTest.LastRunResults.Status ‘ Check the results of the test run
qtTest.Close ‘ Close the test
Set qtTest = Nothing ‘ Release the Test object
Set qtApp = Nothing ‘ Release the Application object
Now in order to execute QTP script from command line we have to execute the above created vbs file from command prompt which will in turn launch QTP, open the script, run it and will display the result in command prompt only. Open command prompt and write following code:
C:\Documents and Settings\pwahi\Desktop>cscript //nologo demo.vbs
And press enter
This command will execute the demo.vbs file which in turn launch QTP, open the script Google search, execute it and will display the result in QTP result file. We can also see the results in command prompt as shown below.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Parul Wahi
In order to run QTP scripts on schedule, we can run them directly from command line.
In order to do so we can make use of QTP Automation Object Model which can help us in automating QuickTest operations. Using the objects, methods, and properties exposed by the QuickTest automation object model, we can write scripts that configure QuickTest options and run tests instead of performing these operations manually using the QuickTest interface.
In the following code we are trying to execute a QTP script called “Google_search” from command line. Let’s create a script in QTP and save it as Google_search.Write the following code in a vbs (VB Script) file as save it as demo.vbs:
Dim qtApp ‘ Declare the Application object variable
Dim qtTest ‘ Declare a Test object variable
Dim qtResultsOpt ‘Declare a Run Results Options object variable
Set qtApp = CreateObject(”QuickTest.Application”) ‘ Create the Application object
qtApp.Launch ‘ Start QuickTest
qtApp.Visible = True ‘ Make the QuickTest application visible
qtApp.Open “C:\Documents and Settings\pwahi\Desktop\Google search“, True ‘ Open the test in read-only mode
‘ set run settings for the test
Set qtTest = qtApp.Test
qtTest.Run’ Run the test
WScript.StdOut.Write “Status is:” & qtTest.LastRunResults.Status ‘ Check the results of the test run
qtTest.Close ‘ Close the test
Set qtTest = Nothing ‘ Release the Test object
Set qtApp = Nothing ‘ Release the Application object
Now in order to execute QTP script from command line we have to execute the above created vbs file from command prompt which will in turn launch QTP, open the script, run it and will display the result in command prompt only. Open command prompt and write following code:
C:\Documents and Settings\pwahi\Desktop>cscript //nologo demo.vbs
And press enter
This command will execute the demo.vbs file which in turn launch QTP, open the script Google search, execute it and will display the result in QTP result file. We can also see the results in command prompt as shown below.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
Script Services
Script Services
By Renu Bala
Script Support Functions enables you to insert code into Functional Tester Script to perform variety of tasks. These tasks include:
• Calling a script from a Functional Test Script
• Inserting Log Messages into Functional Test Script
• Using timers with Functional Test Script
• Setting delays and sleep states for Functional Test Script Playback
• Inserting comments into Functional Test Script
The Script Support Functions dialog box has following tabs:
1. Call Script for Calling a script from a Functional Test Script
2. Log Entry for Inserting Log Messages into Functional Test Script
3. Timer for Using timers with Functional Test Script
4. Sleep for Setting delays and sleep states for Functional Test Script Playback
5. Comment for Inserting comments into Functional Test Script
To use script support commands Click on Insert Script Support Commands button on Recording Monitor Toolbar.
Call Script
While recording or editing a functional test script, you can insert a call to a previously recorded script. This lets you avoid repeatedly recording similar actions on the AUT by taking advantage of scripts that already exist.
CallScript inserts following code in the script at the cursor location:
callScript (“scriptname”)
Where scriptname is the name you selected in the script name field.
Log Entry
You can insert a log message into a functional test script and indicate whether it is a message, a warning or an error. During playback, RFT inserts this information into the log.
LogEntry inserts the following code into the script based on the option you selected (message, warning, error):
logInfo(“Message”)
logWarning(“Message”)
logError(“Message”)
Where Message is the text you entered
Timer
You can insert timers with different names into the same script to measure time it takes to perform a variety of separate tasks. You have to explicitly stop the timer to calculate the time taken by the set of events.
The code generated is:
timerStart(“name”)
timerStop(“name”)
Where name is the variable name you want to use for the timer.
Sleep
You can insert sleep command into Functional test script to delay the script for specified time.
The code generated is:
Sleep(seconds)
Where seconds is the time entered in seconds fields.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Renu Bala
Script Support Functions enables you to insert code into Functional Tester Script to perform variety of tasks. These tasks include:
• Calling a script from a Functional Test Script
• Inserting Log Messages into Functional Test Script
• Using timers with Functional Test Script
• Setting delays and sleep states for Functional Test Script Playback
• Inserting comments into Functional Test Script
The Script Support Functions dialog box has following tabs:
1. Call Script for Calling a script from a Functional Test Script
2. Log Entry for Inserting Log Messages into Functional Test Script
3. Timer for Using timers with Functional Test Script
4. Sleep for Setting delays and sleep states for Functional Test Script Playback
5. Comment for Inserting comments into Functional Test Script
To use script support commands Click on Insert Script Support Commands button on Recording Monitor Toolbar.
Call Script
While recording or editing a functional test script, you can insert a call to a previously recorded script. This lets you avoid repeatedly recording similar actions on the AUT by taking advantage of scripts that already exist.
CallScript inserts following code in the script at the cursor location:
callScript (“scriptname”)
Where scriptname is the name you selected in the script name field.
Log Entry
You can insert a log message into a functional test script and indicate whether it is a message, a warning or an error. During playback, RFT inserts this information into the log.
LogEntry inserts the following code into the script based on the option you selected (message, warning, error):
logInfo(“Message”)
logWarning(“Message”)
logError(“Message”)
Where Message is the text you entered
Timer
You can insert timers with different names into the same script to measure time it takes to perform a variety of separate tasks. You have to explicitly stop the timer to calculate the time taken by the set of events.
The code generated is:
timerStart(“name”)
timerStop(“name”)
Where name is the variable name you want to use for the timer.
Sleep
You can insert sleep command into Functional test script to delay the script for specified time.
The code generated is:
Sleep(seconds)
Where seconds is the time entered in seconds fields.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
SOA Testing Simplified
SOA Testing Simplified
By Pallavi Sharma
So far, we have undertaken the difficult voyage of web services, SOA-Architecture and have come out of it empowered with the knowledge of what this new buzz SOA is all about. In this series of blog we will delve deeper into SOA and understand how do, we go about testing SOA. We will also see what all tools both open source and commercial are available in the market to help us achieve it. We will also take each tool one by one and understand how to best utilize it to test SOA.
Let’s first understand what all issues needs to be considered when we test any web service: [Ref 1]
• Web Services are intrinsically distributed and are platform and language agnostic.
• Web Services can be chained with dependencies on other 3rd party Web Services that can change without notice.
• Web Services ownership is shared across various stakeholders.
• Web Services client developers typically only have access to interfaces (WSDLs) and lack access to code.
• High level of reuse of web services.
As we know web services are based upon loosely coupled architecture. They are platform and language independent which increases the complexity of testing them. A web service usually calls another web service which might be a third party service. Oftenly 3rd party web service changes without prior information resulting in your web service failure. Also, if you are using a 3rd party web service all you have access to is a WSDL document of the web service and no code is available. A 3rd party web service can be used by a large number of users raising performance and security concerns which needs to be taken care of also.
Keeping all this in mind we need to also judge a test tool which takes the following issues into consideration:
• No User Interface to easily play a test
• High level of reuse of the services
• Testing at the service and end-to-end levels
• Interoperability, conformance, security penetration…
• Support of SOA standards and specific implementations WSDL, SOAP, UDDI, HTTP, WS-Security, …
A test tool to test any web service should support the various SOA standards like WSDL, SOAP, XML. Usually there is no UI available to test a web service. So the test tool should provide a user friendly interface to test the GUI less service. It should also assist in testing the interoperability, conformance issues which do arises in web service testing.
The commercial tools which are available in the market to test web services are:
1. IBM : Rational SOA Tester
2. HP: LR and QTP
3. Crosschecknet
4. Parasoft
The open source tools for SOA testing are as follows: [Ref 2]
1. Eviware SoapUI 1.6
2. PushToTest TestMaker
3. WebInject
In the coming series we will take each tool one by one and understand how do, we test the web service using it.
References:
1. http://www.crosschecknet.com/soa_testing_black_white_gray_box.php
2. http://www.infoworld.com/article/07/05/11/19TCwebservicetest_1.html
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Pallavi Sharma
So far, we have undertaken the difficult voyage of web services, SOA-Architecture and have come out of it empowered with the knowledge of what this new buzz SOA is all about. In this series of blog we will delve deeper into SOA and understand how do, we go about testing SOA. We will also see what all tools both open source and commercial are available in the market to help us achieve it. We will also take each tool one by one and understand how to best utilize it to test SOA.
Let’s first understand what all issues needs to be considered when we test any web service: [Ref 1]
• Web Services are intrinsically distributed and are platform and language agnostic.
• Web Services can be chained with dependencies on other 3rd party Web Services that can change without notice.
• Web Services ownership is shared across various stakeholders.
• Web Services client developers typically only have access to interfaces (WSDLs) and lack access to code.
• High level of reuse of web services.
As we know web services are based upon loosely coupled architecture. They are platform and language independent which increases the complexity of testing them. A web service usually calls another web service which might be a third party service. Oftenly 3rd party web service changes without prior information resulting in your web service failure. Also, if you are using a 3rd party web service all you have access to is a WSDL document of the web service and no code is available. A 3rd party web service can be used by a large number of users raising performance and security concerns which needs to be taken care of also.
Keeping all this in mind we need to also judge a test tool which takes the following issues into consideration:
• No User Interface to easily play a test
• High level of reuse of the services
• Testing at the service and end-to-end levels
• Interoperability, conformance, security penetration…
• Support of SOA standards and specific implementations WSDL, SOAP, UDDI, HTTP, WS-Security, …
A test tool to test any web service should support the various SOA standards like WSDL, SOAP, XML. Usually there is no UI available to test a web service. So the test tool should provide a user friendly interface to test the GUI less service. It should also assist in testing the interoperability, conformance issues which do arises in web service testing.
The commercial tools which are available in the market to test web services are:
1. IBM : Rational SOA Tester
2. HP: LR and QTP
3. Crosschecknet
4. Parasoft
The open source tools for SOA testing are as follows: [Ref 2]
1. Eviware SoapUI 1.6
2. PushToTest TestMaker
3. WebInject
In the coming series we will take each tool one by one and understand how do, we test the web service using it.
References:
1. http://www.crosschecknet.com/soa_testing_black_white_gray_box.php
2. http://www.infoworld.com/article/07/05/11/19TCwebservicetest_1.html
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
Performance Testing: Handling maximum database user connection
Performance Testing: Handling maximum database user connection
By Pankaj Goel
While working on performance testing assignments, many a times, I came across situation where following error was reported while applying load on the system
“The Maximum Connection Limit Has Been Reached”
On further analysis, I found that the error was being returned by the database (MS SQL Server in this case). Here is in this post, I have tried to detail what all to do when you get this error
So for MS SQL Server (2000 or 2005), if you have identified that the number of user connections is high, you can control the number of user connections by doing one of the following:
• Enable Microsoft SQL Server to automatically add user connections as needed. Do this through the Microsoft SQL Server SQL Server Properties window by setting the user connections configuration option to 0. If you specify a value other than 0, Microsoft SQL Server allocates memory for those connections at startup, which burns up portions of the memory pool.
• Specify a maximum number of user connections. Set this amount to the expected maximum number of concurrent users. Microsoft SQL Server rejects new login requests after reaching the maximum number of user connections when this value is set. After changing the maximum number of user connections, you must restart Microsoft SQL Server.
To re-configure the maximum number of user connection, In SQL Server 2000, you can use the sp_configure stored procedure. When you install SQL Server, the default value for user connections is 0 (32767 concurrent connections).
a) Start SQL server from command prompt
sqlservr.exe -c -f
b) Issue the following command
sp_configure ‘user connections’, 0
go
reconfigure with override
This code sets user connections back to the default setting.
c) Restart SQL server normally
For further details about the optimum SQL server settings, resources @ the following link contain some good information
http://support.microsoft.com/kb/319942/EN-US/
http://support.microsoft.com/kb/224587/
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Pankaj Goel
While working on performance testing assignments, many a times, I came across situation where following error was reported while applying load on the system
“The Maximum Connection Limit Has Been Reached”
On further analysis, I found that the error was being returned by the database (MS SQL Server in this case). Here is in this post, I have tried to detail what all to do when you get this error
So for MS SQL Server (2000 or 2005), if you have identified that the number of user connections is high, you can control the number of user connections by doing one of the following:
• Enable Microsoft SQL Server to automatically add user connections as needed. Do this through the Microsoft SQL Server SQL Server Properties window by setting the user connections configuration option to 0. If you specify a value other than 0, Microsoft SQL Server allocates memory for those connections at startup, which burns up portions of the memory pool.
• Specify a maximum number of user connections. Set this amount to the expected maximum number of concurrent users. Microsoft SQL Server rejects new login requests after reaching the maximum number of user connections when this value is set. After changing the maximum number of user connections, you must restart Microsoft SQL Server.
To re-configure the maximum number of user connection, In SQL Server 2000, you can use the sp_configure stored procedure. When you install SQL Server, the default value for user connections is 0 (32767 concurrent connections).
a) Start SQL server from command prompt
sqlservr.exe -c -f
b) Issue the following command
sp_configure ‘user connections’, 0
go
reconfigure with override
This code sets user connections back to the default setting.
c) Restart SQL server normally
For further details about the optimum SQL server settings, resources @ the following link contain some good information
http://support.microsoft.com/kb/319942/EN-US/
http://support.microsoft.com/kb/224587/
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
Descriptive Programming in QTP
Descriptive Programming in QTP
By Parul Wahi
What is Descriptive Programming?
QTP can perform some action on objects at run time only when it is able to uniquely identify the object. In order to identify the object at run time (play back), QTP learns some physical properties of the object at the time of recording and stores them in object Repository (OR). When QTP runs the script, it compares these properties and values to the actual objects appearing in the application, and performs the action on the object if it finds it.
Thus, it is not possible for QTP to perform action on objects during run time if the objects are not there in OR. But descriptive programming provides a way to perform action on objects which are not in Object repository. We can instruct QTP to perform methods on the objects that are not there in object repository with the help of programmatic description or descriptive programming.
When and Why to use Descriptive programming?
When using Descriptive Programming (DP), we’re bypassing the native object repository (OR) mechanism which may have many advantages. Let’s examine the situations in which the OR’s advantages are outweighed by the DP.
Suppose we are testing the site that displays the list of users whose details matches with the search criteria that is entered in search text field. With the names, the application also displays checkboxes against each name. Now, we want to test the scenario where application sends mail to all the users whose names are displayed in the list. But we are not sure how many check boxes will be displayed on the page as the search criteria can differ . In this situation, you can use a programmatic description to instruct QuickTest to perform a Set “ON” method for all objects that fit the description: HTML TAG = input, TYPE = check box
The other usage of DP can be as follows:
1) Programmatic descriptions can be used to perform the same operation on several objects with certain identical properties, or to perform an operation on an object whose properties match a description that is determined dynamically during the run session.
2) One place where DP can be of significant importance is when you are creating functions in an external file. You can use these function in various actions directly, eliminating the need of adding object(s) in object repository for each action [If you are using local object repository]
3) The objects in the application are dynamic in nature and need special handling to identify the object. The best example would be of clicking a link which changes according to the user of the application, Ex. “Logout”.
4) When object repository is getting huge due to the no. of objects being added. If the size of Object repository increases too much then it decreases the performance of QTP while recognizing a object.
5) When you don’t want to use object repository at all. Consider the following scenario which would help understand why not Object repository
Scenario 1: Suppose we have a web application that has not been developed yet.Now QTP for recording the script and adding the objects to repository needs the application to be up, that would mean waiting for the application to be deployed before we can start of with making QTP scripts. But if we know the descriptions of the objects that will be created then we can still start off with the script writing for testing
Scenario 2: Suppose an application has 3 navigation buttons on each and every page. Let the buttons be “Cancel”, “Back” and “Next”. Now recording action on these buttons would add 3 objects per page in the repository. For a 10 page flow this would mean 30 objects which could have been represented just by using 3 objects. So instead of adding these 30 objects to the repository we can just write 3 descriptions for the object and use it on any page.
6) When you want to take action on similar type of object i.e. suppose we have 20 textboxes on the page and there names are in the form txt_1, txt_2, txt_3 and so on. Now adding all 20 the Object repository would not be a good programming approach.
How to use Descriptive programming?
There are two ways in which descriptive programming can be used
• Static. You list the set of properties and values that describe the object directly in a VBScript statement.
• Dynamic. You add a collection of properties and values to a Description object, and then enter the Description object name in the statement.
Static method
In Static method , we can write down the physical description of the object in the script itself rather than using it’s logical name. The syntax for this is :
TestObject(”PropertyName1:=PropertyValue1?, “PropertyName2:= PropertyValue2?)
Where, TestObject is . The test object class. Eg WinButton , WebEdit , WinCheckBox etc
PropertyName:=PropertyValue. The test object property and the value identification string. Each property:=value pair should be separated by commas and quotation marks
Eg.1 DP code for login into the FLIGHT RESERVATION (sample Application of QTP) is :
Dialog(”text:=Login”).WinEdit(”nativeclass:=Edit”,”attachedtext:=Agent Name:”). Set “fgfdgfdgf”
Dialog(”text:=Login”).WinEdit(”nativeclass:=Edit”,”attachedtext:=Password:”).SetSecure “48a1881a08961df276749334f4511d5a7d35e922?
Dialog(”text:=Login”).WinButton(”text:=OK”,”nativeclass:=Button”).Click
Window(”title:=Flight Reservation”).Close
Dynamic Method
QTP provides another method which provides more efficiency, power and flexibility known as Dynamic method.
Under Dynamic method you can use the Description object to return a Properties collection object containing a set of Property objects. A Property object consists of a property name and value. You can then specify the returned Properties collection in place of an object name in a statement.
Eg2. The first example mentioned above for Flight Reservation application can be written as follows using Dynamic method:
Set desc=description.Create()
desc(”text”).value=”Login”
desc(”Class Name”).value=”Dialog”
Set agent=description.Create()
agent(”nativeclass”).value=”Edit”
agent(”attachedtext”).value=”Agent Name:”
Set password=description.Create()
password(”nativeclass”).value=”Edit”
password(”attachedtext”).value=”Password:”
Set button=description.Create()
button(”nativeclass”).value=”Button”
button(”text”).value=”OK”
Dialog(desc).WinEdit(agent). Set “fgfdgfdgf”
Dialog(desc).WinEdit(password).SetSecure “48a1881a08961df276749334f4511d5a7d35e922?
Dialog(desc).WinButton(button).Click
Window(”title:=Flight Reservation”).Close
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Parul Wahi
What is Descriptive Programming?
QTP can perform some action on objects at run time only when it is able to uniquely identify the object. In order to identify the object at run time (play back), QTP learns some physical properties of the object at the time of recording and stores them in object Repository (OR). When QTP runs the script, it compares these properties and values to the actual objects appearing in the application, and performs the action on the object if it finds it.
Thus, it is not possible for QTP to perform action on objects during run time if the objects are not there in OR. But descriptive programming provides a way to perform action on objects which are not in Object repository. We can instruct QTP to perform methods on the objects that are not there in object repository with the help of programmatic description or descriptive programming.
When and Why to use Descriptive programming?
When using Descriptive Programming (DP), we’re bypassing the native object repository (OR) mechanism which may have many advantages. Let’s examine the situations in which the OR’s advantages are outweighed by the DP.
Suppose we are testing the site that displays the list of users whose details matches with the search criteria that is entered in search text field. With the names, the application also displays checkboxes against each name. Now, we want to test the scenario where application sends mail to all the users whose names are displayed in the list. But we are not sure how many check boxes will be displayed on the page as the search criteria can differ . In this situation, you can use a programmatic description to instruct QuickTest to perform a Set “ON” method for all objects that fit the description: HTML TAG = input, TYPE = check box
The other usage of DP can be as follows:
1) Programmatic descriptions can be used to perform the same operation on several objects with certain identical properties, or to perform an operation on an object whose properties match a description that is determined dynamically during the run session.
2) One place where DP can be of significant importance is when you are creating functions in an external file. You can use these function in various actions directly, eliminating the need of adding object(s) in object repository for each action [If you are using local object repository]
3) The objects in the application are dynamic in nature and need special handling to identify the object. The best example would be of clicking a link which changes according to the user of the application, Ex. “Logout
4) When object repository is getting huge due to the no. of objects being added. If the size of Object repository increases too much then it decreases the performance of QTP while recognizing a object.
5) When you don’t want to use object repository at all. Consider the following scenario which would help understand why not Object repository
Scenario 1: Suppose we have a web application that has not been developed yet.Now QTP for recording the script and adding the objects to repository needs the application to be up, that would mean waiting for the application to be deployed before we can start of with making QTP scripts. But if we know the descriptions of the objects that will be created then we can still start off with the script writing for testing
Scenario 2: Suppose an application has 3 navigation buttons on each and every page. Let the buttons be “Cancel”, “Back” and “Next”. Now recording action on these buttons would add 3 objects per page in the repository. For a 10 page flow this would mean 30 objects which could have been represented just by using 3 objects. So instead of adding these 30 objects to the repository we can just write 3 descriptions for the object and use it on any page.
6) When you want to take action on similar type of object i.e. suppose we have 20 textboxes on the page and there names are in the form txt_1, txt_2, txt_3 and so on. Now adding all 20 the Object repository would not be a good programming approach.
How to use Descriptive programming?
There are two ways in which descriptive programming can be used
• Static. You list the set of properties and values that describe the object directly in a VBScript statement.
• Dynamic. You add a collection of properties and values to a Description object, and then enter the Description object name in the statement.
Static method
In Static method , we can write down the physical description of the object in the script itself rather than using it’s logical name. The syntax for this is :
TestObject(”PropertyName1:=PropertyValue1?, “PropertyName2:= PropertyValue2?)
Where, TestObject is . The test object class. Eg WinButton , WebEdit , WinCheckBox etc
PropertyName:=PropertyValue. The test object property and the value identification string. Each property:=value pair should be separated by commas and quotation marks
Eg.1 DP code for login into the FLIGHT RESERVATION (sample Application of QTP) is :
Dialog(”text:=Login”).WinEdit(”nativeclass:=Edit”,”attachedtext:=Agent Name:”). Set “fgfdgfdgf”
Dialog(”text:=Login”).WinEdit(”nativeclass:=Edit”,”attachedtext:=Password:”).SetSecure “48a1881a08961df276749334f4511d5a7d35e922?
Dialog(”text:=Login”).WinButton(”text:=OK”,”nativeclass:=Button”).Click
Window(”title:=Flight Reservation”).Close
Dynamic Method
QTP provides another method which provides more efficiency, power and flexibility known as Dynamic method.
Under Dynamic method you can use the Description object to return a Properties collection object containing a set of Property objects. A Property object consists of a property name and value. You can then specify the returned Properties collection in place of an object name in a statement.
Eg2. The first example mentioned above for Flight Reservation application can be written as follows using Dynamic method:
Set desc=description.Create()
desc(”text”).value=”Login”
desc(”Class Name”).value=”Dialog”
Set agent=description.Create()
agent(”nativeclass”).value=”Edit”
agent(”attachedtext”).value=”Agent Name:”
Set password=description.Create()
password(”nativeclass”).value=”Edit”
password(”attachedtext”).value=”Password:”
Set button=description.Create()
button(”nativeclass”).value=”Button”
button(”text”).value=”OK”
Dialog(desc).WinEdit(agent). Set “fgfdgfdgf”
Dialog(desc).WinEdit(password).SetSecure “48a1881a08961df276749334f4511d5a7d35e922?
Dialog(desc).WinButton(button).Click
Window(”title:=Flight Reservation”).Close
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
SOA Testing Simplified- IV
SOA Testing Simplified- IV
By Pallavi Sharma
In the last series we saw what are the various challenges which a tool should overcome to test a SOA based application. We saw a list of commercial and open source tools which can assist us in testing our web services.
From this series we will take each tool one by one and understand what all it has to offer us. The first solution to web service testing we will consider is the one provided by Rational. Rational offers the following solutions:
a. Rational Tester for SOA Quality
b. Rational Performance Tester Extension for SOA Quality.
Following are the list of features which they offer:
• Both built on Rational Performance Tester technology
• Support for Web Services standards UDDI, WSDL, SOAP, HTTP, HTTPS, WS-Security
• Integrated with Rational Test Management tools (Test Manager with ClearQuest)
• Monitoring tools (Tivoli) can be easily integrated with it.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Pallavi Sharma
In the last series we saw what are the various challenges which a tool should overcome to test a SOA based application. We saw a list of commercial and open source tools which can assist us in testing our web services.
From this series we will take each tool one by one and understand what all it has to offer us. The first solution to web service testing we will consider is the one provided by Rational. Rational offers the following solutions:
a. Rational Tester for SOA Quality
b. Rational Performance Tester Extension for SOA Quality.
Following are the list of features which they offer:
• Both built on Rational Performance Tester technology
• Support for Web Services standards UDDI, WSDL, SOAP, HTTP, HTTPS, WS-Security
• Integrated with Rational Test Management tools (Test Manager with ClearQuest)
• Monitoring tools (Tivoli) can be easily integrated with it.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
SOA Testing Simplified
SOA Testing Simplified (Series-IV)
By Pallavi Sharma
In the last series we saw what are the various challenges which a tool should overcome to test a SOA based application. We saw a list of commercial and open source tools which can assist us in testing our web services.
From this series we will take each tool one by one and understand what all it has to offer us. The first solution to web service testing we will consider is the one provided by Rational. Rational offers the following solutions:
a. Rational Tester for SOA Quality
b. Rational Performance Tester Extension for SOA Quality.
Following are the list of features which they offer:
• Both built on Rational Performance Tester technology
• Support for Web Services standards UDDI, WSDL, SOAP, HTTP, HTTPS, WS-Security
• Integrated with Rational Test Management tools (Test Manager with ClearQuest)
• Monitoring tools (Tivoli) can be easily integrated with it.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
By Pallavi Sharma
In the last series we saw what are the various challenges which a tool should overcome to test a SOA based application. We saw a list of commercial and open source tools which can assist us in testing our web services.
From this series we will take each tool one by one and understand what all it has to offer us. The first solution to web service testing we will consider is the one provided by Rational. Rational offers the following solutions:
a. Rational Tester for SOA Quality
b. Rational Performance Tester Extension for SOA Quality.
Following are the list of features which they offer:
• Both built on Rational Performance Tester technology
• Support for Web Services standards UDDI, WSDL, SOAP, HTTP, HTTPS, WS-Security
• Integrated with Rational Test Management tools (Test Manager with ClearQuest)
• Monitoring tools (Tivoli) can be easily integrated with it.
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
Subscribe to:
Posts (Atom)