way2softwaretechnology

Boundary Value Analysis ( BVA) Testing

2008-12-25T12:24:00.004+05:30

Boundary value analysis is the method of making sure that behaviour of system is certain for the input and output boundary conditions. the reason why boundary conditions are necessary for testing is because defects could be inserted at the boundaries very easily.

let us see this following example :
Input should be greater than equal to 5 and less than 10
Probably you will write something like
if (input >=5 AND input <10)>
then
do this
else
do some thing else.

So, according to this input values from 5 to 9 are valid, but if you make mistake in specifying the conditions, following things can happen
input >5 AND input <10-------> Input value 10 in invalid now
input <=5 AND input <10> Input value 4 is valid now
input >=5 AND input <=10 -----> Input value 10 is valid now
input >=5 AND input >10 -----> Input value 9 is invalid now

Because it is very easy to introduce defects at boundaries, boundary values are important. So for the above example, at the minimum we should have following test cases for boundaries
4,5,6 and 8, 9, 10
lower_boundary - 1, lower_boundary, lower_boundary + 1 and upper_boundary - 1, upper_boundary, upper_boundary + 1.

what is off-by-one
off-by-one: An exceedingly common error induced in many ways, such as by starting at zero when you should have started at one or vice-versa.

Related Topics:

Unit Testing

2008-12-17T18:31:00.003+05:30

The aim of Unit Testing is to take a small piece of software from the application, isolate it from the reminder of the code and check whether it works exactly as you expect. like wise each unit is testing in this manner seperately before intergrating them into modules to test into interfaces between modules, and most of the defects are identified during this unit test.

Unit testing requires drivers and stubs to be written, here the driver simulates a calling unit and the stub simulates a called unit. though the Driver and Stub costs time and money, unit testing provides some unquestionable advantages, this allows automation of testing process, reduces troubles of exploring errors contained in more complex pieces of the application, test coverage is often raised because attention is given to each unit.

Example: if we have 3 units, lets see how to check it..

check is the error due to unit1
check is the error due to unit2
check is the error due to unit3
check weather it is because of the problem with 3 units
check is the error due to interfaces between units
it might be due to defect in the process of testing

Identifying the error (or errors) in the integrated module is much more complicated than first insulating the units, testing each module and integrating them as an integrated unit and testing thee whole system.

Driver and Stub can be reused to reduce the time and cost instead of writing large amount of code.

Related Topics:

Code Coverage?

2008-12-13T18:51:00.003+05:30

Code Coverage - which indicates to measure the quality of code in a software, this degree describes the degree to which the source code of a program has been tested, Code Coverage is a form of testing that inspects the code directly and is therefore a form of white box testing. now the the use of code coverage is extended to the field of digital hardware, the contemporary design method of which relies on Hardware Languages.

To know the metric level of this method, we need to know what are the coverage criteria that need to be exercised, there are few important criteria's that i mentioned below:

Function Coverage - Here needs checking of each function in the program been executed
Statement Coverage - To check each line of code is been executed
Decision Coverage - To check each control structure evaluated both to true or false
Condition Coverage - To check each Boolean sub-expression evaluated both to true and false
Path Coverage - to check weather every possible route through, a given part of code been executed
Entry/Exit Coverage - To check weather every possible call and return of the function been executed

safety critical applications are often required to demonstrate that testing achieves 100% of some form of code coverage.

Related Topics:

Function Points

2008-12-11T19:56:00.006+05:30

A function point is a unit of measurement to express the amount of business functionality an information system provides to a user.

Function Point Analysis:

The method of measuring the size of an information system and expressing it in a number of function points is called function point analysis (FPA). A function point analysis expresses the functional size of an information system in a number of function points (for example: the size of a system is 314 FPs). There are many uses and benefits of function points & the functional size may be used as input into many projects and organization decisions, some of the aspects are shown below:

budget for application development or enhancement costs.
budget for the annual maintenance costs of the application portfolio.
project productivity after completion of the project.
size of the software for cost estimation.

Criticism of Function Points:

Function points have been criticized as adding little value relative to the cost and complexity of the effort, the effect on this is very marginal error reduction. because much of the variance in software cost estimates are not considered like business changes, scope changes, unplanned resource constraints or reprioritizations, and there may be many more reasons. Also, if the measurement is used for the decision of whether to invest in the software, then a given measurement effort, it is argued, is more valuable if it is applied to measure benefits than costs

Related Topics:

Fault, Fault Tolerance, Fault Injection Method

2008-12-09T19:04:00.008+05:30

Fault - An incorrect step, process, or data definition in a program is called a fault.

Fault Tolerance - The capability of the software product to maintain a specified level of performance in cases of software faults (defects) or of infringement of its specified interface.

Fault Injection - The process of intentionally incorporating errors in code in order to measure the ability of the tester or processes to detect such errors is called fault Injection.

Related Topics:

What is Mutation Testing?

2008-12-08T13:41:00.011+05:30

Mutation Testing is a powerful method for finding errors in software programs. It was introduced as a way of measuring the accuracy of test suites. Generally, there is no easy way to tell if the test suite completely tests the program or not. If the program passes the test suite, one may say that program works correctly on all the cases that are included in the test suite. The more cases a test suite contains, the higher the probability that the program will work correctly in the real world. However, there is no method to measure how accurate the test suite is and the probability that the program will work correctly.

In mutation testing, one is in some sense trying to solve this problem by inverting the scenario. The thinking goes as follows:

Let’s assume that we have a perfect test suite, one that covers all possible cases. Let’s also assume that we have a perfect program that passes this test suite. If we change the code of the program (this process is called mutating) and we run the mutated program (mutant) against the test suite, we will have two possible scenarios:

The results of the program were affected by the code change and the test suite detects it. We assumed that the test suite is perfect, which means that it must detect the change. If this happens, the mutant is called a killed mutant.
The results of the program are not changed and the test suite does not detect the mutation. The mutant is called an equivalent mutant.

If we take the ratio of killed mutants to all the mutants that were created, we get a number that is smaller than 1; this number measures how sensitive the program is to the code changes.

we got another scenario when in the case of not having perfect program and perfect test case suite, the below scenario will be raised.

The results of the program are different, but the test suite does not detect it because it does not have the right test case.

If we take the ratio of all the killed mutants to all the mutants generated, we get a number smaller than 1 that also contains information about accuracy of the test suite.

Benefits of Mutation Testing:

Automatic mutation testing brings a new level of error-detection to the software developer.
Tools that automate mutation testing are able to uncover ambiguities in code previously thought impossible to detect automatically.
By using tools that incorporate mutation testing into state-of-the-art error-detection technology, developers are able to flush out more faults than with any other technology.
Software developers and testers using tools that incorporate this approach to mutation testing will benefit enormously, as such tools automatically uncover more bugs than any other technology.
The customer also benefits from mutation testing, as the program a user receives is less buggy and more reliable. This increased confidence will in turn benefit your company where it matters most- the bottom line.

Related Topics:

White box Testing

2008-12-06T18:05:00.012+05:30

White box Testing is just opposite to Black box Testing, when the tester has access to the internal data structures and algorithms.

Now let us know how many types of white box testing are there:

Code coverage - creating tests to satisfy some criteria of code coverage. the test designer can create tests to cause all statements in the program to be executed atleast once.

Mutation testing methods.

Fault injection methods.

Static Testing - white box testing include all static testing.

Code completeness evaluation

White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested.

Two common forms of code coverage are:

function coverage which reports on functions executed
statement coverage which reports on the number of lines executed to complete the test.

They both return a coverage metric, measured as a percentage.

Related Topics:

Peer Review

2008-12-05T19:04:00.003+05:30

Peer Reviews are considered an industry best-practice for detecting software defects early and learning about software. It is been taken with reference to walkthroughs and inspections made on the work product and are integral to software activities. A collection of collective knowledge, skills, and behaviors facilitates the best possible practice of Peer Reviews. The elements of Peer Reviews include the structured review process, standard of excellence product check-lists, defined roles of participants, and the forms and reports.
Software inspections plays most rigorous form of Peer Reviews and fully utilize these elements in detecting defects. Software walkthroughs draw selectively upon the elements in assisting the producer to obtain the deepest understanding of an architecture and reaching a consensus among participants. Measured results reveal that Peer Reviews produce an attractive return on investment obtained through accelerated learning and early defect detection. For best results, Peer Reviews are rolled out within an organization through a defined program of preparing a policy and procedure, training practitioners and managers, defining measurements and populating a database structure, and sustaining the roll out infrastructure.

Related Topics:

Inspection

2008-12-05T18:54:00.006+05:30

Inspection in softare Testing refers to peer review of any work product by trained individuals who search for defects using a well defined process. lets us see this Inspection in detail...

Goal of Inspection: it is to satisfy all of its inspectors to reach consensus on that work product and approve it to be used in the project. a product is selected for review and a team will gather for reviewing that particular products, a moderator is choosen to moderate the meeting, and the participant first read and prepare with the work products to raise the defects that come in the work flow as it is the main goal to identify the defects this meeting is conducted.

The process will be in this manner:

Planning: The inspection is planned by the moderator.
Overview meeting: The author describes the background of the work product.
Preparation: Each inspector examines the work product to identify possible defects.
Inspection meeting: During this meeting the reader reads through the work product, part by part and the inspectors point out the defects for every part.
Rework: The author makes changes to the work product according to the action plans from the inspection meeting.
Follow-up: The changes by the author are checked to make sure everything is correct.

The process is ended by the moderator when it satisfies some predefined exit criteria.

Related Topics:

Black Box Testing

2008-12-05T15:11:00.005+05:30

Black box testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid input and determines the correct output. There is no knowledge of the test object's internal structure.
The design is applicable to all levels of software testing: unit, integration, functional testing, system testing and acceptance testing. the higher the level, and hence the bigger and more complex the box, while this procedure is used remove the cover of all the unimplemented parts of the specification, one cannot be sure that all the existing paths are completely tested.

Related Topics:

Boundary Value Analysis ( BVA Testing )
White Box Testing
Sanity Testing
Smoke Testing
Stress Testing

Verification and Validation

2008-12-04T22:47:00.006+05:30

Verification & Validation is the process of checking that a software system meets specification and fulfils its intended purpose, it is the process of software testing in the project., this is also called as V&V Model.

Verification: to determine if the process that was followed to develop the final product is right.

Validation: if the product is built according to the requirements of the user. Other methods, such as reviews, when used early in the Software Development Life Cycle provide for validation.

Verification can be called as a part of validation process.

Dynamic Testing

2008-12-04T18:23:00.010+05:30

Dynamic Testing is the the term used in software engineering to describe the testing of the dynamic behaviour of the code at different situations. In dynamic testing the software must actually be compiled and Run, and it in real involves working with the software, giving input valves and checking whether the output is as expected, these are called the validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the dynamic Testing methodologies, dynamic testing means testing based on a specifi test cases by execution of the running programs.

Dynamic testing is used to test software through executing it, it is almost similar to static testing.

Related Topics:

Static Testing

Static Testing

2008-12-04T14:17:00.009+05:30

Static Testing is a type of software testing where the software is not actually used, this is in contrast to Dynamic Testing. It is genrally not detailed testing, but it checks mainly for the sanity of the code, algorithm or document. it is primarily systax checking of the code and manually reading of the code or document to find errors. This type of testing can be used by the developer who has written the code, in isolation. here Code Reviews, inspections and walkthroughs are also used.

when we think from black box tesing point, Static tesing involves review of requirements and specifications. this is done with an eye toward completeness for the task at hand, this is actually the verification portion of verification and validation.

Even Static Testing Can be automated, as this suite consists in programs to be analized by an interpreter/compiler that asserts the programs syntactic validity. Bugs discovered at this stage of development are less expensive to fix then in the later development cycle.

Related Topics:

Reverse Walkthrough

2008-12-03T22:15:00.002+05:30

Reverse Walkthrough: when the consumer of the product takes the author through it, then we can call it as Reverse walkthrough.

A reverse walkthrough is a confirmation that the consumers of a technical product have the same understanding as the author of that product. The authors ask questions about the content to confirm that the consumer has understood it. this is common in software engineering for software reviews or business process reviews when the developer reads the source/usecase/process back to the author.

The reverse walkthrough should be made when the consumers of the technical product have reviewed it and there is a risk that their understanding may not be reflective of the original intent.

Objectives & Participants:

A Reverse walkthrough is meant to confirm a common understanding about the content from consumers of a technical product.

Related Topics:

Walkthrough

Walkthroughs

2008-12-03T20:53:00.003+05:30

In Software Engineering, a walkthrough is some thing like a software peer review, in which a designer or programmer leads members of the development team and other interested parties through a software product and the members keep asking questions and making comments about possible errors, voilation of development standards and other problems.

A Walkthrough differ from software technical reviews in its openness of model and its objective of familiarization, it differs from software inspection in its ability to suggest direct alterations to the product reviewed, it lacks of a direct focus on training and process improvement and its removal of process and product measurement.

Objectives and Participants:
The main objctive of this Walkthroughs is to gain feed back about the technical quality/content of the document.
To familiarize the audiance with the content
This Walkthrough is organized by Author of the Technical document.

Related Topics:

Reverse Walkthrough

Code Review

2008-12-03T20:24:00.006+05:30

Code Review can often find and remove vulnarablilities such as format string exploits, race conditions, memory leaks and buffer over flows, there by improving software security.
types of Code Reviews:

Code review practices often fall into two main categories: formal code review and lightweight code review.
Code review practices often fall into two main categories: formal code review and lightweight code review like Fagon Inspection involves a careful and detailed process with multiple participants and multiple phases. Formal code reviews are the older, traditional method of review, in which developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review. However, some criticize formal reviews as taking too long to be practical.
Lightweight code review typically requires less overhead than formal code inspections, though it can be equally effective when done properly, Lightweight reviews are often conducted as part of the normal development process:

Over-the-shoulder: One developer looks over the author's shoulder as the latter walks through the code.
Email pass-around: Source code management system emails code to reviewers automatically after checkin is made.
Pair Programming: here Two authors develop code together at the same workstation, such as is common in Extreme Programming.
Tool-assisted code review: Authors and reviewers use specialized tools designed for peer code review. Programmers often find tool-assisted code review to be less tedious and more efficient than some other methods

Criticism:

Some argue that code review is less important when certain rules or secure coding methodologies are followed from the software's inception, the Extreme programming approach includes the practice of pair programming, which can be argued to be code review during development. Extreme Programming proponents argue that other Extreme Programming practices, such as refactoring and creating tests before even writing the code, produces code that doesn't need to be reviewed or rewritten as often and thus speeds software development.

Related Topics:

Static Vs Dynamic Tesing?

2008-12-03T19:52:00.006+05:30

Static Vs Dynamic Testing

There are many approaches to software testing, Riviews, walkthroughts or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. The former can be, and unfortunately in practice often is, omitted, whereas the latter takes place when programs begin to be used for the first time - which is normally considered the beginning of the testing stage. This may actually begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions).

Eg: Spreadsheet programs are, by their very nature, tested to a large extent on the fly during the build process as the result of some calculation or text manipulation is shown interactively immediately after each formula is entered.

Related Topics:

common problems that occur during software development

2008-12-01T21:07:00.004+05:30

what are the common problems that occur during software development

Poorly Written Requirements: Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems.
Unrealistic Schedules: The schedule is unrealistic if too much work is crammed in too little time.
Inadequate Testing: Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes.
Adding New Features while development is underway: It's extremely common that new features are added after development is underway.
Poor Communication: Miscommunication either means the developers don't know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed.

Related Topics:

Quality Software

2008-12-01T20:35:00.005+05:30

What is Quality Software.

Quality software is software that is reasonably bug-free, delivered on time, with in budget, meets requirements and expectations and is maintainable. However, Quality is a subjective term.
Quality depends on who the customer is and their overall influence in the scheme of things.

Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization's management, test engineers, testers, salespeople, software engineers, stockholders and accountants.
Eg: Every customer will have his or her own slant on quality. The Finance department might define quality in terms of profits, where as the end-user might define quality as user friendly and bug free.

Related Topics:

When is Tesing Complete?

2008-11-26T21:20:00.008+05:30

Testing Complete?
It is very difficult to say when testing is complete. there are 3 criterias used in practice for completion of testing, they are:

When you run out of time
When you run out of money
Based on statistical criteria

Unfortunately, the first two criteria are followed, during the planning stage, certain time and money are allocated for testing process, the test team keeps tesing the software and when they run out of Time/Money, the product is delivered to avoid the penalty for late delivery. most managers do not realize that as this is a dangerous practice if the software fails at customer environment, there is a problem to the reputation of the organization.

Another more practical approach for declaring that the testing is complete is to use the third criteria where after the coding is completed, and testing begins, initially many defects are detected. slowly, the number of defects found in a given time keeps reducing week by week (say in a day or a week), if the number of defects found per week remains less than a predefined threshold consecutively, then the software can be considered as a matured product and released to the client.

Related Topics:

Analyze Results, Report, and Retest in Core Performance Testing

2008-11-25T16:54:00.004+05:30

Final procedure in Performance Testing is to Analyze Results, Report, and Retest

Consider the following important points while analyzing the data returned by your performance test:

Analyze the captured data and compare the results against the metric’s acceptable or expected level to determine whether the performance of the application being tested shows a trend toward or away from the performance objectives.
If all of the metric values are within accepted limits and none of the set thresholds have been violated, the tests have passed and you have finished testing that particular scenario on that particular configuration.
If the test fails, a diagnosis and tuning activity are generally warranted. {Explained: The Performance Tester’s Role in Diagnosis and Tuning}
If you fix any bottlenecks, repeat the testing process from step 4 onwards until the test succeeds.
Performance testing should produce meaningful performance tests mapping to the real world requirements
Performance testing results should provide analysis to go deep into components and correlate back to the real world. Example performance testing contribution defined 2x orders increase with same infrastructure
Performance testing should deliver informed architecture and business decisions

Note: If required, capture additional metrics in subsequent test cycles. For example, suppose that during the first iteration of load tests the process shows a marked increase in memory consumption, indicating a possible memory leak. In subsequent test iterations, additional memory counters related to generations can be captured, allowing you to study the memory allocation pattern for the application.

Considerations

Immediately share test results and make raw data available to your entirel team.
Talk to the consumers of the data to validate that the test achieved the desired results and that the data means what you think it means. Modify the test to get new, better, or different information now while the test objectives are fresh in your mind, especially if the results do not represent what the test was defined to determine.
Filter out any unnecessary data. For example, if 87 of the 100 pages tested failed to meet their target response time, remove them from the graph to avoid redundancy.
Make your report using strong but factual language, with supporting paragraphs and graphics if available. For example, “The home page fails to achieve target response time for 75% of the users.”
Make your report using business language, not simply technical data. For example, do no say, “The CPU utilization is hovering at 85%”; rather, say, “The application server is not powerful enough to support the target load as the application is currently deployed/operating.”
Use current results to set priorities for the next test.
After each test, tell the team what you expect the next two tests to be so the team members can provide input concerning what they would like to have tested next while you are executing the current test.
Always keep supporting data handy and deliver it in the Appendix.

Related Topics:

Configuring Test Environment in Performance Testing
Plan and Design Tests
Identifying Performance Acceptance Criteria
How to Identify Test Environment in web application
Implement Test Design in Performance Testing
How to Execute Core Performance Testing

Executing Core Performance Testing

2008-11-25T15:24:00.006+05:30

Execute Test in Core Performance Testing

After the Implementation of Test Design have been completed to an appropriate degree, for the test you want to execute, it is worth the time to double check that the following items have been accomplished before starting a formal test execution:

Validate that the test environment matches the configuration that you were expecting andte/or designed your test for.
Ensure that both the test and the test environment are correctly configured for metrics collection.
Before running the real test, execute a quick “smoke test” to make sure that the test script and remote performance counters are working correctly.
Reset the system (unless your scenario is to do otherwise) and start a formal test execution.
Make sure test scripts execution are representing the workload model, For example check for number of orders posted, searches and other business metrics
Make sure the load test containing test scripts, is collecting key performance indicators and business indicators

Considerations

If at all possible, execute every test twice. If the results produced are not very similar, execute the test again. Try to determine what factors account for the difference.
Observe your test during execution and pay close attention any behavior you feel is unusual. Your instincts are usually right, or at least valuable.
No matter how far in advance a test is scheduled, give the team 30-minute and 5-minute warnings before launching the test (or starting the day’s testing) if you are using a shared test environment. Inform the team whenever you are not going to be executing for more than 1 hour in succession.
Do not process data, write reports, or draw diagrams on your load-generating machine while generating a load because this can skew the results of your test.
Turn off any active virus-scanning on load-generating machines during testing to minimize the likelihood of unintentionally skew the results of your test.
Use the system manually during test execution so that you can compare your observations with the results data at a later time.
Remember to simulate ramp-up and cool-down periods appropriately.
Do not throw away the first iteration because of application script compilation, web server cache building or other similar reasons. Instead, measure this iteration separately so you will know what the first user after a system-wide reboot can expect.
Test execution is never really finished, but eventually you will reach a point of diminishing returns on a particular test. When you stop obtaining valuable information, change your test.
If neither you feel like you are not making progress in understanding an observed issue, it may be more efficient to eliminate one or more variables/potential causes and run the test again.

Related Topics:

Configuring Test Environment in Performance Testing
Plan and Design Tests
Identifying Performance Acceptance Criteria
How to Identify Test Environment in web application
Implement Test Design in Performance Testing

Implement Test Design in Performance Testing

2008-11-25T14:29:00.006+05:30

Here creating an executable performance test are extremely tool-specific. Regardless of the tool that you are using, creating a performance test typically involves taking a single instance of your test script and gradually adding more instances and/or more scripts over time, thereby increasing the load on the component or system.

To determine how many instances of a script are necessary to accomplish the objectives of your test, you first need to identify a workload that appropriately represents the usage scenario related to the objective.

Finding Workload of Combined User Scenarios

A workload profile consists of an aggregate mix of users performing various operations. Consider the following activities to identifying the workload:

Identify the distribution (ratio of work). For each key scenario, identify the distribution / ratio of work. The distribution is based on the number of users executing each scenario, based on your application scenario.
Identify the peak user loads. Identify the maximum expected number of concurrent users of the Web application. Using the work distribution for each scenario, calculate the percentage of user load per key scenario.
Identify the user loads under a variety of conditions of interest. For instance, you might want to identify the maximum expected number of concurrent users for the Web application at normal and peak hours.

Creating the Performance Test

After you have identified the workload for each user scenario to be tested, create your performance test by performing the following activities:

Create a performance test that will take a single instance of the test script that corresponds to the user scenario to be tested. Later, more instances will be added for each additional scenario.
Gradually add more instances over time, increasing the load for the user scenario to the maximum workload identified in the above step. It is important to allow sufficient time between each s increase in the number of users, so that the system has enough time to stabilize before the next set of user connections executes the test case.
Integrate measurement of resource utilization of interest on the server(s): for example, CPU, Memory, Disk, and Network.
If possible, set thresholds in your testing tool according to your performance test objectives; for example, the resource utilization thresholds can be as follows:

1) Processor\% Processor Time: 75 percent

2) Memory\Available MBytes: 25 percent of total physical RAM

Consider some key points when implementing test scripts to meet business requirements:

Test data feeds implemented correctly being consumed by the test script
Application data feeds implemented in the database or other server like email, message queue etc to simulate business scenarios. For example placing an order with volume of orders pending shipment.
Validation rules implemented. Some Web server requests return success error code, but transactions fail to complete.
Extraction rules implemented. Some session data and other response hidden fields are returned, and need to be submitted in subsequent requests. Consider handling such data correct, otherwise transactions will fail.
Key performance indicators. Work with those indicators in load tests, so load test result analysis can be done.
Business performance indicators. Add pertinent indicators that will facilitate articulating business performance. For examples creating a transaction around orders submittal will give you relevant volume per given time, that you will be able to read from load test results.

Related Topics:

Configuring Test Environment in Performance Testing
Plan and Design Tests
Identifying Performance Acceptance Criteria
How to Identify Test Environment in web application

Configuring Test Environment

2008-11-24T14:21:00.002+05:30

How to Configure Test Environment?

configuring of test environment required some work,

Validation of load tests execution for hardware components for switches and network cards: correct full duplex mode operation, correct emulation of user latency and bandwidth
Validation of load tests execution for test data feeds in application and test consumption: number of products, user ids, and orders shipped, etc.
Validation of load tests execution for cluster load balancing: IP switching, percentage of distribution, priority settings.
Validation of load tests execution for SQL deployment: data and log files distribution, network cards in web servers etc.

Note: With a conceptual strategy, get the tools and resources prepared to execute the strategy as features and components become available for test.

Load generation and application monitoring tools are almost never as easy to get up and running as one expects. Whether issues arise from setting up isolated network environments, procuring hardware, coordinating a dedicated bank of IP addresses for IP spoofing, or version compatibility between monitoring software and server operating systems, issues always seem to arise.
Also, it is inevitable that load generation tools are always behind evolving technologies and practices. Tool creators can only build in support for the most prominent technologies, and even then, they have to become prominent before the support can be built.
This often means that some of the biggest challenges a performance testing project faces may include: getting your first three-user, two-scenario, three-loop prototype test running with no script errors; parameterized variables; authentication and sessions handled correctly; data collected correctly; and users generally being simulated in such a way that the application under test cannot legitimately tell the difference between real users and simulated users. Plan for this and do not be surprised when it takes significantly longer than expected to get it all working smoothly.
Additionally, plan to periodically reconfigure, update, add or otherwise enhance your load generation environment and associated tools throughout the project. Even if the application under test stays the same and the load generation tool is working properly, it is likely that the metrics you wish to collect will change. This frequently implies some degree of change to or addition of monitoring tools.

Related Topics:

Manually downloaded file in LoadRunner

2008-11-23T16:10:00.008+05:30

How to Check Manually a Downloaded File - Visual video

How to check file or page was downloaded successfully in LoadRunner?

This present LoadRunner video tutorial explains you how to do that. All you need is to check LoadRunner snapshot files (inf-files) located in LoadRunner script folder:

Here is the Visual Tutorial how to How to Check Manually a Downladed file in LR:

Win Runner Interview Questions along with answers.

2008-11-21T20:21:00.003+05:30

What is the purpose of GUI spy? - a) Using the GUI Spy, you can view the properties of any GUI object on your desktop. You use the Spy pointer to point to an object, and the GUI Spy displays the properties and their values in the GUI Spy dialog box. You can choose to view all the properties of an object, or only the selected set of properties that WinRunner learns.
What is the purpose of obligatory and optional properties of the objects? - a) For each class, WinRunner learns a set of default properties. Each default property is classified “obligatory” or “optional”.i. An obligatory property is always learned (if it exists).ii.An optional property is used only if the obligatory properties do not provide unique identification of an object. These optional properties are stored in a list. WinRunner selects the minimum number of properties from this list that are necessary to identify the object. It begins with the first property in the list, and continues, if necessary, to add properties to the description until it obtains unique identification for the object.
When the optional properties are learned? - a) An optional property is used only if the obligatory properties do not provide unique identification of an object.
What is the purpose of location indicator and index indicator in GUI map configuration? - a) In cases where the obligatory and optional properties do not uniquely identify an object, WinRunner uses a selector to differentiate between them. Two types of selectors are available:i. A location selector uses the spatial position of objects.
The location selector uses the spatial order of objects within the window, from the top left to the bottom right corners, to differentiate among objects with the same description. - ii. An index selector uses a unique number to identify the object in a window.
The index selector uses numbers assigned at the time of creation of objects to identify the object in a window. Use this selector if the location of objects with the same description may change within a window.
How do you handle custom objects? - a) A custom object is any GUI object not belonging to one of the standard classes used by WinRunner. WinRunner learns such objects under the generic “object” class. WinRunner records operations on custom objects using obj_mouse_ statements.b) If a custom object is similar to a standard object, you can map it to one of the standard classes. You can also configure the properties WinRunner uses to identify a custom object during Context Sensitive testing.
What is the name of custom class in WinRunner and what methods it applies on the custom objects? - a) WinRunner learns custom class objects under the generic “object” class. WinRunner records operations on custom objects using obj_ statements.
In a situation when obligatory and optional both the properties cannot uniquely identify an object what method WinRunner applies? - a) In cases where the obligatory and optional properties do not uniquely identify an object, WinRunner uses a selector to differentiate between them. Two types of selectors are available:i. A location selector uses the spatial position of objects.ii. An index selector uses a unique number to identify the object in a window.63 What is the purpose of different record methods 1) Record 2) Pass up 3) As Object 4) Ignore.a) Record instructs WinRunner to record all operations performed on a GUI object. This is the default record method for all classes. (The only exception is the static class (static text), for which the default is Pass Up.)b) Pass Up instructs WinRunner to record an operation performed on this class as an operation performed on the element containing the object. Usually this element is a window, and the operation is recorded as win_mouse_click.c) As Object instructs WinRunner to record all operations performed on a GUI object as though its class were “object” class.d) Ignore instructs WinRunner to disregard all operations performed on the class.
How do you find out which is the start up file in WinRunner? - a) The test script name in the Startup Test box in the Environment tab in the General Options dialog box is the start up file in WinRunner.
What are the virtual objects and how do you learn them? - a) Applications may contain bitmaps that look and behave like GUI objects. WinRunner records operations on these bitmaps using win_mouse_click statements. By defining a bitmap as a virtual object, you can instruct WinRunner to treat it like a GUI object such as a push button, when you record and run tests.b) Using the Virtual Object wizard, you can assign a bitmap to a standard object class, define the coordinates of that object, and assign it a logical name.To define a virtual object using the Virtual Object wizard:i. Choose Tools > Virtual Object Wizard. The Virtual Object wizard opens. Click Next.ii. In the Class list, select a class for the new virtual object. If rows that are displayed in the window. For a table class, select the number of visible rows and columns. Click Next.iii. Click Mark Object. Use the crosshairs pointer to select the area of the virtual object. You can use the arrow keys to make precise adjustments to the area you define with the crosshairs. Press Enter or click the right mouse button to display the virtual object’s coordinates in the wizard. If the object marked is visible on the screen, you can click the Highlight button to view it. Click Next.iv.Assign a logical name to the virtual object. This is the name that appears in the test script when you record on the virtual object. If the object contains text that WinRunner can read, the wizard suggests using this text for the logical name. Otherwise, WinRunner suggests virtual_object, virtual_push_button, virtual_list, etc.v. You can accept the wizard’s suggestion or type in a different name. WinRunner checks that there are no other objects in the GUI map with the same name before confirming your choice. Click Next.
How you created you test scripts 1) by recording or 2) programming? - a) Programming. I have done complete programming only, absolutely no recording.
What are the two modes of recording? - a) There are 2 modes of recording in WinRunneri.Context Sensitive recording records the operations you perform on your application by identifying Graphical User Interface (GUI) objects.ii.Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.
What is a checkpoint and what are different types of checkpoints? - a) Checkpoints allow you to compare the current behavior of the application being tested to its behavior in an earlier version.You can add four types of checkpoints to your test scripts:i. GUI checkpoints verify information about GUI objects. For example, you can check that a button is enabled or see which item is selected in a list.ii. Bitmap checkpoints take a “snapshot” of a window or area of your application and compare this to an image captured in an earlier version.iii. Text checkpoints read text in GUI objects and in bitmaps and enable you to verify their contents.iv. Database checkpoints check the contents and the number of rows and columns of a result set, which is based on a query you create on your database
What is parameterizing? - a) In order for WinRunner to use data to drive the test, you must link the data to the test script which it drives. This is called parameterizing your test. The data is stored in a data table.
How do you maintain the document information of the test scripts? - a) Before creating a test, you can document information about the test in the General and Description tabs of the Test Properties dialog box. You can enter the name of the test author, the type of functionality tested, a detailed description of the test, and a reference to the relevant functional specifications document.
What do you verify with the GUI checkpoint for single property and what command it generates, explain syntax? - a) You can check a single property of a GUI object. For example, you can check whether a button is enabled or disabled or whether an item in a list is selected. To create a GUI checkpoint for a property value, use the Check Property dialog box to add one of the following functions to the test script:i. button_check_infoii. scroll_check_infoiii. edit_check_infoiv. static_check_infov. list_check_infovi. win_check_infovii. obj_check_infoSyntax: button_check_info (button, property, property_value );edit_check_info ( edit, property, property_value );
What do you verify with the GUI checkpoint for object/window and what command it generates, explain syntax? - a) You can create a GUI checkpoint to check a single object in the application being tested. You can either check the object with its default properties or you can specify which properties to check.b) Creating a GUI Checkpoint using the Default Checksi. You can create a GUI checkpoint that performs a default check on the property recommended by WinRunner. For example, if you create a GUI checkpoint that checks a push button, the default check verifies that the push button is enabled.ii. To create a GUI checkpoint using default checks: Choose Create > GUI Checkpoint > For Object/Window, or click the GUI Checkpoint for Object/Window button on the User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode as well. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens on the screen.
WinRunner captures the current value of the property of the GUI object being checked and stores it in the test’s expected results folder. The WinRunner window is restored and a GUI checkpoint is inserted in the test script as an obj_check_gui statement - Syntax: win_check_gui ( window, checklist, expected_results_file, time );c) Creating a GUI Checkpoint by Specifying which Properties to Checkd) You can specify which properties to check for an object. For example, if you create a checkpoint that checks a push button, you can choose to verify that it is in focus, instead of enabled.e) To create a GUI checkpoint by specifying which properties to check:i. Choose Create > GUI Checkpoint > For Object/Window, or click the GUI Checkpoint for Object/Window button on the User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode as well. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens on the screen.ii. Double-click the object or window. The Check GUI dialog box opens.iii. Click an object name in the Objects pane. The Properties pane lists all the properties for the selected object.iv. Select the properties you want to check.
To edit the expected value of a property, first select it. Next, either click the Edit Expected Value button, or double-click the value in the Expected Value column to edit it.
To add a check in which you specify arguments, first select the property for which you want to specify arguments. Next, either click the Specify Arguments button, or double-click in the Arguments column. Note that if an ellipsis (three dots) appears in the Arguments column, then you must specify arguments for a check on this property. (You do not need to specify arguments if a default argument is specified.) When checking standard objects, you only specify arguments for certain properties of edit and static text objects. You also specify arguments for checks on certain properties of nonstandard objects. To change the viewing options for the properties of an object, use the Show Properties buttons.
Click OK to close the Check GUI dialog box. WinRunner captures the GUI information and stores it in the test’s expected results folder. The WinRunner window is restored and a GUI checkpoint is inserted in the test script as an obj_check_gui or a win_check_gui statement. - Syntax: win_check_gui ( window, checklist, expected_results_file, time );obj_check_gui ( object, checklist, expected results file, time );
What do you verify with the GUI checkpoint for multiple objects and what command it generates, explain syntax? - a) To create a GUI checkpoint for two or more objects:i. Choose Create > GUI Checkpoint > For Multiple Objects or click the GUI Checkpoint for Multiple Objects button on the User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR MULTIPLE OBJECTS softkey in order to avoid extraneous mouse movements. The Create GUI Checkpoint dialog box opens.ii. Click the Add button. The mouse pointer becomes a pointing hand and a help window opens.iii. To add an object, click it once. If you click a window title bar or menu bar, a help window prompts you to check all the objects in the window.iv. The pointing hand remains active. You can continue to choose objects by repeating step 3 above for each object you want to check.v. Click the right mouse button to stop the selection process and to restore the mouse pointer to its original shape. The Create GUI Checkpoint dialog box reopens.vi. The Objects pane contains the name of the window and objects included in the GUI checkpoint. To specify which objects to check, click an object name in the Objects pane. The Properties pane lists all the properties of the object. The default properties are selected.
To edit the expected value of a property, first select it. Next, either click the Edit Expected Value button, or double-click the value in the Expected Value column to edit it.
To add a check in which you specify arguments, first select the property for which you want to specify arguments. Next, either click the Specify Arguments button, or double-click in the Arguments column. Note that if an ellipsis appears in the Arguments column, then you must specify arguments for a check on this property. (You do not need to specify arguments if a default argument is specified.) When checking standard objects, you only specify arguments for certain properties of edit and static text objects. You also specify arguments for checks on certain properties of nonstandard objects.
To change the viewing options for the properties of an object, use the Show Properties buttons. - vii. To save the checklist and close the Create GUI Checkpoint dialog box, click OK. WinRunner captures the current property values of the selected GUI objects and stores it in the expected results folder. A win_check_gui statement is inserted in the test script.Syntax: win_check_gui ( window, checklist, expected_results_file, time );obj_check_gui ( object, checklist, expected results file, time );
What information is contained in the checklist file and in which file expected results are stored? - a) The checklist file contains information about the objects and the properties of the object we are verifying.b) The gui*.chk file contains the expected results which is stored in the exp folder
What do you verify with the bitmap check point for object/window and what command it generates, explain syntax? - a) You can check an object, a window, or an area of a screen in your application as a bitmap. While creating a test, you indicate what you want to check. WinRunner captures the specified bitmap, stores it in the expected results folder (exp) of the test, and inserts a checkpoint in the test script. When you run the test, WinRunner compares the bitmap currently displayed in the application being tested with the expected bitmap stored earlier. In the event of a mismatch, WinRunner captures the current actual bitmap and generates a difference bitmap. By comparing the three bitmaps (expected, actual, and difference), you can identify the nature of the discrepancy.b) When working in Context Sensitive mode, you can capture a bitmap of a window, object, or of a specified area of a screen. WinRunner inserts a checkpoint in the test script in the form of either a win_check_bitmap or obj_check_bitmap statement.c) Note that when you record a test in Analog mode, you should press the CHECK BITMAP OF WINDOW softkey or the CHECK BITMAP OF SCREEN AREA softkey to create a bitmap checkpoint. This prevents WinRunner from recording extraneous mouse movements. If you are programming a test, you can also use the Analog function check_window to check a bitmap.d) To capture a window or object as a bitmap:i. Choose Create > Bitmap Checkpoint > For Object/Window or click the Bitmap Checkpoint for Object/Window button on the User toolbar. Alternatively, if you are recording in Analog mode, press the CHECK BITMAP OF OBJECT/WINDOW softkey. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens.ii. Point to the object or window and click it. WinRunner captures the bitmap and generates a win_check_bitmap or obj_check_bitmap statement in the script. The TSL statement generated for a window bitmap has the following syntax:win_check_bitmap ( object, bitmap, time );iii. For an object bitmap, the syntax is:obj_check_bitmap ( object, bitmap, time );iv. For example, when you click the title bar of the main window of the Flight Reservation application, the resulting statement might be:win_check_bitmap (”Flight Reservation”, “Img2″, 1);v. However, if you click the Date of Flight box in the same window, the statement might be:obj_check_bitmap (”Date of Flight:”, “Img1″, 1);Syntax: obj_check_bitmap ( object, bitmap, time [, x, y, width, height] );
What do you verify with the bitmap checkpoint for screen area and what command it generates, explain syntax? - a) You can define any rectangular area of the screen and capture it as a bitmap for comparison. The area can be any size: it can be part of a single window, or it can intersect several windows. The rectangle is identified by the coordinates of its upper left and lower right corners, relative to the upper left corner of the window in which the area is located. If the area intersects several windows or is part of a window with no title (for example, a popup window), its coordinates are relative to the entire screen (the root window).b) To capture an area of the screen as a bitmap:i. Choose Create > Bitmap Checkpoint > For Screen Area or click the Bitmap Checkpoint for Screen Area button. Alternatively, if you are recording in Analog mode, press the CHECK BITMAP OF SCREEN AREA softkey. The WinRunner window is minimized, the mouse pointer becomes a crosshairs pointer, and a help window opens.ii. Mark the area to be captured: press the left mouse button and drag the mouse pointer until a rectangle encloses the area; then release the mouse button.iii. Press the right mouse button to complete the operation. WinRunner captures the area and generates a win_check_bitmap statement in your script.iv. The win_check_bitmap statement for an area of the screen has the following syntax:win_check_bitmap ( window, bitmap, time, x, y, width, height );
What do you verify with the database checkpoint default and what command it generates, explain syntax? - a) By adding runtime database record checkpoints you can compare the information in your application during a test run with the corresponding record in your database. By adding standard database checkpoints to your test scripts, you can check the contents of databases in different versions of your application.b) When you create database checkpoints, you define a query on your database, and your database checkpoint checks the values contained in the result set. The result set is set of values retrieved from the results of the query.c) You can create runtime database record checkpoints in order to compare the values displayed in your application during the test run with the corresponding values in the database. If the comparison does not meet the success criteria youd) specify for the checkpoint, the checkpoint fails. You can define a successful runtime database record checkpoint as one where one or more matching records were found, exactly one matching record was found, or where no matching records are found.e) You can create standard database checkpoints to compare the current values of the properties of the result set during the test run to the expected values captured during recording or otherwise set before the test run. If the expected results and the current results do not match, the database checkpoint fails. Standard database checkpoints are useful when the expected results can be established before the test run.Syntax: db_check(, );f) You can add a runtime database record checkpoint to your test in order to compare information that appears in your application during a test run with the current value(s) in the corresponding record(s) in your database. You add runtime database record checkpoints by running the Runtime Record Checkpoint wizard. When you are finished, the wizard inserts the appropriate db_record_check statement into your script.Syntax:db_record_check(ChecklistFileName,SuccessConditions,RecordNumber );ChecklistFileName A file created by WinRunner and saved in the test’s checklist folder. The file contains information about the data to be captured during the test run and its corresponding field in the database. The file is created based on the information entered in the Runtime Record Verification wizard.Contains one of the following values:DVR_ONE_OR_MORE_MATCH - The checkpoint passes if one or more matching database records are found. -DVR_ONE_MATCH - The checkpoint passes if exactly one matching database record is found. -DVR_NO_MATCH - The checkpoint passes if no matching database records are found. - RecordNumber An out parameter returning the number of records in the database.
How do you handle dynamically changing area of the window in the bitmap checkpoints? - a) The difference between bitmaps option in the Run Tab of the general options defines the minimum number of pixels that constitute a bitmap mismatch.
What do you verify with the database check point custom and what command it generates, explain syntax? - a) When you create a custom check on a database, you create a standard database checkpoint in which you can specify which properties to check on a result set.b) You can create a custom check on a database in order to:i. check the contents of part or the entire result setii. edit the expected results of the contents of the result setiii. count the rows in the result setiv. count the columns in the result setc) You can create a custom check on a database using ODBC, Microsoft Query or Data Junction.
What do you verify with the sync point for object/window property and what command it generates, explain syntax? - a) Synchronization compensates for inconsistencies in the performance of your application during a test run. By inserting a synchronization point in your test script, you can instruct WinRunner to suspend the test run and wait for a cue before continuing the test.b) You can a synchronization point that instructs WinRunner to wait for a specified object or window to appear. For example, you can tell WinRunner to wait for a window to open before performing an operation within that window, or you may want WinRunner to wait for an object to appear in order to perform an operation on that object.c) You use the obj_exists function to create an object synchronization point, and you use the win_exists function to create a window synchronization point. These functions have the following syntax:Syntax:obj_exists ( object [, time ] );win_exists ( window [, time ] );
What do you verify with the sync point for object/window bitmap and what command it generates, explain syntax? - a) You can create a bitmap synchronization point that waits for the bitmap of an object or a window to appear in the application being tested.b) During a test run, WinRunner suspends test execution until the specified bitmap is redrawn, and then compares the current bitmap with the expected one captured earlier. If the bitmaps match, then WinRunner continues the test.Syntax:obj_wait_bitmap ( object, image, time );win_wait_bitmap ( window, image, time );
What do you verify with the sync point for screen area and what command it generates, explain syntax? - a) For screen area verification we actually capture the screen area into a bitmap and verify the application screen area with the bitmap file during executionSyntax: obj_wait_bitmap(object, image, time, x, y, width, height);
How do you edit checklist file and when do you need to edit the checklist file? - a) WinRunner has an edit checklist file option under the create menu. Select the “Edit GUI Checklist” to modify GUI checklist file and “Edit Database Checklist” to edit database checklist file. This brings up a dialog box that gives you option to select the checklist file to modify. There is also an option to select the scope of the checklist file, whether it is Test specific or a shared one. Select the checklist file, click OK which opens up the window to edit the properties of the objects
How do you edit the expected value of an object? - a) We can modify the expected value of the object by executing the script in the Update mode. We can also manually edit the gui*.chk file which contains the expected values which come under the exp folder to change the values.
How do you modify the expected results of a GUI checkpoint? - a) We can modify the expected results of a GUI checkpoint be running the script containing the checkpoint in the update mode.
How do you handle ActiveX and Visual basic objects? - a) WinRunner provides with add-ins for ActiveX and Visual basic objects. When loading WinRunner, select those add-ins and these add-ins provide with a set of functions to work on ActiveX and VB objects.
How do you create ODBC query? - a) We can create ODBC query using the database checkpoint wizard. It provides with option to create an SQL file that uses an ODBC DSN to connect to the database. The SQL File will contain the connection string and the SQL statement.
How do you record a data driven test? - a) We can create a data-driven testing using data from a flat file, data table or a database.i. Using Flat File: we actually store the data to be used in a required format in the file. We access the file using the File manipulation commands, reads data from the file and assign the variables with data.ii. Data Table: It is an excel file. We can store test data in these files and manipulate them. We use the ‘ddt_*’ functions to manipulate data in the data table.iii.Database: we store test data in the database and access these data using ‘db_*’ functions.
How do you convert a database file to a text file? - a) You can use Data Junction to create a conversion file which converts a database to a target text file.
How do you parameterize database check points? - a) When you create a standard database checkpoint using ODBC (Microsoft Query), you can add parameters to an SQL statement to parameterize the checkpoint. This is useful if you want to create a database checkpoint with a query in which the SQL statement defining your query changes.
How do you create parameterize SQL commands? - a) A parameterized query is a query in which at least one of the fields of the WHERE clause is parameterized, i.e., the value of the field is specified by a question mark symbol ( ? ). For example, the following SQL statement is based on a query on the database in the sample Flight Reservation application:i. SELECT Flights.Departure, Flights.Flight_Number, Flights.Day_Of_Week FROM Flights Flights WHERE (Flights.Departure=?) AND (Flights.Day_Of_Week=?)SELECT defines the columns to include in the query.FROM specifies the path of the database.WHERE (optional) specifies the conditions, or filters to use in the query.Departure is the parameter that represents the departure point of a flight.Day_Of_Week is the parameter that represents the day of the week of a flight.b) When creating a database checkpoint, you insert a db_check statement into your test script. When you parameterize the SQL statement in your checkpoint, the db_check function has a fourth, optional, argument: the parameter_array argument. A statement similar to the following is inserted into your test script:db_check(”list1.cdl”, “dbvf1?, NO_LIMIT, dbvf1_params);The parameter_array argument will contain the values to substitute for the parameters in the parameterized checkpoint.
Explain the following commands: - a) db_connectto connect to a databasedb_connect(, );b) db_execute_queryto execute a querydb_execute_query ( session_name, SQL, record_number );record_number is the out value.c) db_get_field_valuereturns the value of a single field in the specified row_index and column in the session_name database session.db_get_field_value ( session_name, row_index, column );d) db_get_headersreturns the number of column headers in a query and the content of the column headers, concatenated and delimited by tabs.db_get_headers ( session_name, header_count, header_content );e) db_get_rowreturns the content of the row, concatenated and delimited by tabs.db_get_row ( session_name, row_index, row_content );f) db_write_recordswrites the record set into a text file delimited by tabs.db_write_records ( session_name, output_file [ , headers [ , record_limit ] ] );g) db_get_last_errorreturns the last error message of the last ODBC or Data Junction operation in the session_name database session.db_get_last_error ( session_name, error );h) db_disconnectdisconnects from the database and ends the database session.db_disconnect ( session_name );i) db_dj_convertruns the djs_file Data Junction export file. When you run this file, the Data Junction Engine converts data from one spoke (source) to another (target). The optional parameters enable you to override the settings in the Data Junction export file.db_dj_convert ( djs_file [ , output_file [ , headers [ , record_limit ] ] ] );
What check points you will use to read and check text on the GUI and explain its syntax? - a) You can use text checkpoints in your test scripts to read and check text in GUI objects and in areas of the screen. While creating a test you point to an object or a window containing text. WinRunner reads the text and writes a TSL statement to the test script. You may then add simple programming elements to your test scripts to verify the contents of the text.b) You can use a text checkpoint to:i.Read text from a GUI object or window in your application, using obj_get_text and win_get_textii.Search for text in an object or window, using win_find_text and obj_find_textiii. Move the mouse pointer to text in an object or window, using obj_move_locator_text and win_move_locator_textiv. Click on text in an object or window, using obj_click_on_text and win_click_on_text
Explain Get Text checkpoint from object/window with syntax? - a) We use obj_get_text (, ) function to get the text from an objectb) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.
Explain Get Text checkpoint from screen area with syntax? - a) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.
Explain Get Text checkpoint from selection (web only) with syntax? - a) Returns a text string from an object.web_obj_get_text (object, table_row, table_column, out_text [, text_before, text_after, index]);i. object The logical name of the object.ii. table_row If the object is a table, it specifies the location of the row within a table. The string is preceded by the # character.iii. table_column If the object is a table, it specifies the location of the column within a table. The string is preceded by the # character.iv. out_text The output variable that stores the text string.v. text_before Defines the start of the search area for a particular text string.vi. text_after Defines the end of the search area for a particular text string.vii. index The occurrence number to locate. (The default parameter number is numbered 1).
Explain Get Text checkpoint web text checkpoint with syntax? - a) We use web_obj_text_exists function for web text checkpoints.web_obj_text_exists ( object, table_row, table_column, text_to_find [, text_before, text_after] );a. object The logical name of the object to search.b. table_row If the object is a table, it specifies the location of the row within a table. The string is preceded by the character #.c. table_column If the object is a table, it specifies the location of the column within a table. The string is preceded by the character #.d. text_to_find The string that is searched for.e. text_before Defines the start of the search area for a particular text string.f. text_after Defines the end of the search area for a particular text string.

Test Automation Interview Questions

2008-11-21T20:06:00.002+05:30

How did you use automating testing tools in your job?
What automating testing tools are you familiar with?
How do you plan test automation?
Can test automation improve test effectiveness?
What is data - driven automation?
What are the main attributes of test automation?
Does automation replace manual testing?
How will you choose a tool for test automation?
How you will evaluate the tool for test automation?
How you will describe testing activities?
What are main benefits of test automation?
What could go wrong with test automation?
What testing activities you may want to automate?
What types of scripting techniques for test automation do you know?
What tools are available for support of testing during software development life cycle?
What are principles of good testing scripts for automation?
Can the activities of test case design be automated?
What are the limitations of automating software testing?
What skills needed to be a good software test automator?
How to find that tools work well with your existing system?
Describe some problem that you had with automating testing tool?
What are the main attributes of test automation?
What testing activities you may want to automate in a project?
How to find that tools work well with your existing system?
What are some of the common misconceptions during implementation of an automated testing tools for the first time?

Plan and Design Tests in LoadRunner

2008-11-21T16:01:00.009+05:30

When designing and planning tests,the target is to simulate real-world tests that can provide reliable data so as to provide informed decisions around the business.So that Real world tests design will prove the system to meet larger realistic objectives. The following are the considerations when designing tests:

Real world design tests are more inclusive of non-computerized dependencies like humans, other systems interacting with the application etc.
Realistic test design will be based on real operations and data, and does not rely on mechanistic procedures.
Realistic test design will be more credible for the project and will enhance the value of performance testing
Component-level performance tests are integral part of real-world testing, and not the end goal.
Real world test design can be more costly and time consuming but they provide more accuracy for the business and stakeholders. Extrapolation of performance results from non realistic tests can be inaccurate as the system scope increases.

Identify Metrics of Interest
When identified, captured, and reported correctly, metrics provide information about how your application’s performance compares to your desired performance characteristics. In addition, metrics can help you identify problem areas and bottlenecks within your application.
Using the desired performance characteristics identified in step 1, identify metrics to be captured that focus on measuring performance and identifying bottlenecks in the system.
When identifying metrics, use either specific desired characteristics or indicators that are directly or indirectly related to those . The following table presents an example of a metric corresponding to the performance objectives identified in step 1.
Metric Accepted level
Request execution time Must not exceed 8 seconds

Throughput 100 or more requests / second
% process time Must not exceed 75%
Memory available 25% of total RAM

Considerations

Although it may seem like a commonsense practice, it is important to verify that system clocks are synchronized on all of the machines from which resource data will be collected. Doing so can save you significant time, and prevent you from having to dispose of the data entirely and repeat the tests after synchronizing the system clocks.
Involve the developers and administrators in the process of determining which metrics are likely to add value and which method best integrates the capturing of those metrics into the test.
Collecting metrics frequently produces very large volumes of data. While it is tempting to reduce the amount of data, always exercise caution when using data reduction techniques as valuable data can be lost when reducing data.

Scenarios

Key user scenarios for the application typically surface during the process of identifying the desired performance characteristics of the application (Step 1). If this is not the case for your test project, you will need to explicitly determine the usage scenarios that are the most valuable to script. {For more information, see How To: Identify Key Usage Scenarios for Performance Testing.} To create test scripts from the identified or selected scenarios, most performance testers follow an approach similar to the following:

Identify the activities or steps involved in each of the scenarios; for example, the “Place an Order” scenario for an e-commerce application may include the following activities:

a.Log on to the application.
b.Browse a product catalog.
c.Select a product.
d.Place order, and so on.

For each activity or step, consider and design the data associated with that step. A method is to use a table similar to the one below:Only after you have detailed the individual steps can you effectively and efficiently create a test script to emulate the necessary requests against the application to accomplish the scenario {For more information, see How To: Implement Workload Models in VSTS 2005}.

Considerations

If the request accepts parameters, ensure that the parameter data is populated properly with random and/or unique data to avoid any server-side caching.
If the tool does not do so automatically, you will likely want to add a wrapper around the requests in the test script in order to measure the request response time.
Beware of allowing your tools to influence your test design. Better tests almost always result from designing tests on the assumption that they can be executed and then adapting the test or the tool when that assumption is proven false, rather than by not designing particular tests based on the assumption that you do not have access to a tool to execute the test.
It is generally worth taking the time to make the script match your designed test, rather than changing the designed test to save scripting time.
Significant value can be gained from evaluating the data collected from executed tests in order to test or validate script development.
Once a test has been implemented using a tool, it’s a good idea to double check that the test matches the test design. If they don’t match, it’s generally worth the effort to make them match by modifying one (or both) items and communicating the modification with the team.

Related Topics:

Identifying Performance Acceptance Criteria

2008-11-21T15:54:00.002+05:30

It generally makes most sense to start identifying, or at least estimating, the desired performance characteristics early in the application development life cycle. Record the performance characteristics that your users and stakeholders would equate to a successfully performing application, in a manner that is appropriate to your project’s standards and expectations.
Characteristics that frequently correlate to a user’s or stakeholder’s satisfaction typically include:

Business Performance indicators identified; orders per second (Normal and peak), Help desk calls per hour
Workload modeling for the business performance indicators. Example number of users for normal and peal loads
Key Performance indicators identified: response time, throughput, utilization levels for processor, network, disk and memory.
Resource utilization mapping to the business objectives; for example database transactions/messages/searches per second to satisfy number of orders or help desk calls per hour.

Response time: For example, the product catalog must be displayed in less than three seconds.
Throughput: For example, the system must support 100 transactions per second.
Resource utilization: For example, CPU utilization is not more than 75 percent. Other important resources that need to be considered for setting objectives are memory, disk I/O, and network I/O.

How to Identifying Test Environment in Web Application Performance Testing

2008-11-21T14:48:00.005+05:30

Test environment also includes business requirements? I believe this is what we call business environment?

The degree of similarity between the hardware, software and network configuration of the application under test conditions and under actual production conditions is often a significant consideration when deciding what performance tests to conduct and what size loads to test. It is important to remember, it is not only the physical environment that impacts performance testing, but also the business/project environment. The business environment includes things like business drivers where as project environment includes such items like the approach that will be used for performance testing .

In addition to the physical, project and business environments, you should consider the following when identifying your test environment:

Identify the amount and type of data the application must be seeded with . Determine what kind of data the application requires and consumes at each step of activity through the system. How many records are moving throughout the end-to-end transaction? How big are the queried results sets? How much unique data will I need to have in the database in order to emulate real-world conditions?
Identify critical system components. Does the system have any known bottlenecks or weak points? Are there any integration points that are beyond your control for testing?

Identify the Physical Environment

The key factor in identifying your test environment is to completely understand the similarities and differences between the test and production environments. Some critical factors to consider are:

Machine configurations
Machine hardware (processor, RAM, etc.)
Overall machine setup (software installations, etc.).
Network architecture and end-user location.
Cluster and DNS configurations

Considerations:

Although few performance testers install, configure, and administrate the application being tested, it is beneficial for them to have access to the servers, software, and administrators who do.
Recommendations for configuring the load generation tool:

Performance testing is frequently conducted on an network segment to prevent disruption of other business operations. If this is not the case for your test project, ensure that you obtain permission to generate loads during certain hours on the available network.
Get to know the IT staff. You will likely need their support to perform tasks such as monitoring overall network traffic and configuring your load-generation tool to simulate a realistic number of Internet Protocol (IP) addresses.
Remember to figure out how to get load balancers to treat the generated load as though it were an actual user load.
Check configuration in load balancers for priority and percentage of requests. Monitor resource utilization across servers in the load balancer during a load test to validate load is distributed.
Validate name resolution with DNS. This may account for significant latency when opening database connections.
Validate that firewalls, Domain Name System (DNS), routing, and so on treat the generated load like a load that would typically be encountered in an actual production environment, and that the test environment is treated similarly to the production environment.
Determine how much load you can generate before the load generators becomes a bottleneck. Typically load generators can bottleneck in processor and memory

It is often appropriate to have systems administrators set up resource monitoring software, diagnostic tools, and other utilities on the servers hosting the Application Under Test (AUT).

How to Parameterize 'Select next row = unique' in the Video format

2008-11-20T15:04:00.011+05:30

How to Parameterize 'Select next row = unique' in the Video format

Here is last method of LoadRunner video tutorial on work with LoadRunner parameters.It explains different combinations of the parameter setting 'Select next row' = 'Unique'.

This LoadRunner video tutorial covers the following:
Settings on Parameter List dlgOption 'Select next row' = 'Unique'

Option 'Update value on' = 'Each iteration'
Option 'Update value on' = 'Each occurrence'
Option 'Update value on' = 'Once'
Option 'When out of values' = 'Abort Vuser'
Option 'When out of values' = 'Continue in a cyclic manner'
Option 'When out of values' = 'Continue with last value'

'Allocate Vuser values in the Controller'
How to view an output value of LoadRunner parameter
This Video explains you how to parameterize a scenario using "select next row = Unique" option:

Smoke Testing in LoadRunner

2008-11-20T14:22:00.005+05:30

How to analyse Smoke Testing in performance testing?

A performance smoke test is a test designed to determine, if your application can successfully perform all of its operations under a normal load condition for a short time.
Benefits

Provides a quick assessment of whether a build or configuration is performing within a reasonable degree of deviation from expectations.
Enables you to quickly compare one build or configuration to another build or configuration that a performance smoke test was previously executed against.
Enables you to quickly determine if there are obvious and significant performance issues with a build or configuration.
Enables you to quickly provide data to do an initial prioritization of additional performance tests to be conducted against a build or configuration.
Helps to determine if a build/configuration is ready for additional performance testing.

Challenges and Areas Not Addressed

Does not provide a complete data set.
Many potential performance issues go undetected.
Is not suitable for predictive analysis or drawing detailed conclusions.
Results can easily be given more weight than they deserve if not reported properly.

For HP Load Runner Tool - Trial Version from HP Download

Parameterization select next row = Random

2008-11-20T13:37:00.008+05:30

How to create new LoadRunner parameterization using Option 'select next row' = 'Random'

Option is Update value on = 'Each iteration',
Option is Update value on = 'Each occurrence',
Option is Update value on = 'Once'

How to view an output value of parameter:
This Video is just only a Visual Video which has got no Audio but you have the text Explanation.

Types of Performance Testing

2008-11-20T10:36:00.005+05:30

The Matrix Benefits of Performance Testing Types

Capacity Planning: 1. Provides actual data to the capacity planners.
2. Validates capacity planning models.
3. Determines current usage and capacity.
4. Provides usage and capacity data.
Component : 1. This type Provides information to help detect and tune component-level performance issues.
2. Provides a baseline of performance characteristics.
Endurance : 1. Detects slow memory leaks.
2. Detects insufficient file storage capacity.
3. Identifies slowness due to volume of stored data.
4. Is the most realistic scenario for predicting production conditions.
Investigation : Collects useful information at various development stages.
Load : 1. Determines throughput of the peak load.
2. Determines hardware adequacy.
3. Determines database capacity.
4. Evaluates the adequacy of a load balancer.
5. Collects scalability and capacity-planning data.
Smoke : 1. Provides a quick assessment of current performance.
2. Quickly compares one build to another.
3. Quickly finds obvious performance issues.
4. Quickly provides data to help prioritize next steps.
Spike : 1. Detects memory leaks.
2. Identifies disk I/O concerns (thrashing).
3. Identifies slow returns to steady state.
Stress : 1. Determines if data can be corrupted by overstressing the system.
2. Estimates the conditions under which errors appear.
3. Establishes application-monitoring triggers.
4. Ensures that security holes are not opened up by stressful conditions.
Unit : 1. Provides immediate feedback about code performance.
2. Helps isolate and tune performance issues.
3. Provides a baseline of performance characteristics.
4. Allows testing middle tier and database layers in isolation.
Validation : Determines what requirements and goals are and are not being met.

Why software Performance Testing Required

2008-11-19T16:45:00.005+05:30

Why Does software Performance Testing Required?
Most common reasons for conducting performance testing can be summarized as follows:
To compare the current performance characteristics of the application with the performance characteristics that tally to end-user satisfaction when using the application.
To test that the application exhibits the desired performance characteristics, within the budgeted constraints of resource utilization. These performance characteristics may include several different parameters such as the time it takes to finish a particular usage scenario (called as response time) or the number of simultaneous requests that can be supported for a particular operation at a given response time. The resource characteristics may be set with respect to server resources such as processor utilization, memory, disk input/output (I/O), and network input/output.
To analyze the behavior of the Web application at various load levels. The behavior is measured in measurement/Metrics related to performance characteristics, as well as other metrics that help to identify bottlenecks in the application.
To identify bottlenecks in the Web application. Bottlenecks can be caused by several issues such as memory leaks, slow response times, or sometimes contention under load.
To determine the capacity of the application’s infrastructure, and to determine the future resources required to deliver acceptable application performance.
To compare different system configurations to determine which one works best for both the application and the business.

There are risks associated with lack or improper performance testing. Some considerations are outline below:
1. Revenue losses to the competition due to scalability, stability issues.
2. Loss of credibility that may affect the branding image of the company.

Performance Testing, Load Testing, and Stress Testing

2008-11-19T15:37:00.007+05:30

Performance Testing, Load Testing, and Stress Testing
Performance tests most typically fall into one of the following three categories:

Performance Testing: It is a kind of testing to determine or validate the speed, scalability, and/or stability, characteristics of the system under test. Performance is concerned with achieving response times, throughput, and resource utilization levels that meet the performance objectives for the application under test.

Load Testing: It is a type of performance test focused on determining or validating performance characteristics of the product under test when subjected to workload models and load volumes anticipated during production operations. These tests are designed to answer questions in such as "How many?", "How big?", and "How much?".

Stress testing: This type of performance test focused on determining or validating performance characteristics of the product under test when subjected to workload models, and load volumes beyond those anticipated during production operations. Stress tests may also include tests focused on determining or validating performance characteristics of the product under test when subjected to workload models and load volumes when the product is subjected to other stressful conditions, such as limited memory, insufficient disk space, or server failure. These tests are designed to determine:

Under what conditions an application will fail
How it will fail
What indicators can be monitored to warn of an impending failure.

Core Performance Testing Activities

2008-11-19T15:28:00.004+05:30

Here is a structure of how to implement Core Performance Testing Activities on a perticular scenario:

1. Identify the Test Environment
2. Identify Performance Acceptance Criteria
3. Plan and Design Tests
4. Configure or Update tools & Load Generation Environment
5. Implement Test Design
6. Execute Tests
7. Analyze Results, Reports and Retest

Performance testing approach of each described here for the above seven activities are:

1. Identify the Test Environment Which means Identifying the physical environment and the business environment. The physical environment includes the appropriate hardware, software, and network configurations where as the business environment includes business objectives, risks, team roles and contacts.

2. Identify Performance Acceptance Criteria: Identify the response time, throughput and resource utilization goals and constraints. To be in general, response time is generally a user concern, throughput is a business concern, and resource utilization is a system concern.

3. Plan and Design Tests: which indicates us to Identifying key scenarios and metrics.

4. Configure or Update Tools and Load Generation Environment which meann to get the tools and resources prepared to execute this strategy as features and components become available for test.

5. Implement Test Design is used Identify the workloads and workload profiles and Create the performance tests.

6. Execute Test: Run your tests that were prepared.

7. Analyze Results, Report, and Retest: If all of the metric values are within accepted limits and none of the set thresholds have been violated, the tests have passed and you have finished testing that particular scenario on that particular configuration.

LoadRunner Video on parameterization on Select Row = ' Sequential '

2008-11-18T18:56:00.008+05:30

How to use ( select row = sequential ) using parameters in LoadRunner, here is a guided Video Show Below:

How to create new LoadRunner Parameter
How to use parameter features
Settings on parameter list dialog

Option ' Select next Row' = Sequencial

Option ' Update Value on' = Each Iteration

Option ' Update Value on' = Each Occurance

Option ' Update Value on' = Once
How to View an output valve of parameter
LoadRunner Parameterization Select Next Row = Seqential explained below

Automated Correlation in LoadRunner

2008-11-18T16:12:00.012+05:30

How to make Automated correlation in LoadRunner?

Correlation is a key concept of HP LoadRunner. The present LoadRunner video tutorial explains how to correlate dynamic values in LoadRunner automatically:

How to find dynamic values to be correlated
How to compare recorded & replayed dynamic values
How to correlate them in LoadRunner
How to verify correlation

There is a screenshot from the present LoadRunner video:

This LoadRunner video explains concepts of Correlation and how Correlation works.Video tutorial demonstrates LoadRunner Correlation by the example of HP Web Tours application, which is shipped with LoadRunner. So, you can repeat and learn all shown actions yourself.

Manual Correlation in LoadRunner

2008-11-17T17:56:00.019+05:30

How to Manually Correlate Dynamic Values?

In previous LoadRunner video [Automated correlation] I showed you how to use Automated Correlation. The present LoadRunner video explains how to manually correlate dynamic values:

How to find dynamic values in a server response
How to correlate them in LoadRunner
How to verify the correlation

There is a screenshot from the present LoadRunner video:

Manual Correlation in LoadRunner - Video

Related Topics:

Automated Correlations