Home | About Us | Search | FAQ | Contact Us
|
|
|
|
|
Home | About Us | Search | FAQ | Contact Us |
|
|
|
|
|
|
|
||
|
What is
Topdown Testing? What is Localization Testing? What is Functionality and Compatibility Testing? What is Load Testing? What is Stress Testing? What is Reliability Testing? What is Maximum Simultaneous Connection Testing? What is Get Requests Capacity Testing? What is Error Introduction Testing? What is Bounds Testing? What is Proof of Concept Testing? What is Regression Testing? What is Usability Testing?
What is Topdown Testing? These areas are often defined in topdown test sheets. There may be one set for File, one for Edit, one for Format, and another for Help. In large programs, there may be hundreds or thousands of test groups. The concept is that you test "from the top level down (top...down)." This helps catch problems that are often missed if you don't specifically test each area. This type of testing is critical, but should be accompanied by "creative testing" in which a tester has a lot of freedom to figure out what to do and how to do things. The combination of the two in a quality testing environment will uncover most of the problems before a product ships.
Localization Testing is testing a product or application in a native language. An example: Microsoft releases their Internet Explorer application in many languages. Let's pick French. They would want to have the French version of IE tested on the French version of Windows 95, 98, NT, 2000, and XP. They would have a machine set up with the appropriate code page info as if it was in France. The idea is to ensure that internationally localized versions do not have problems that are unique to the environment or language.
Do all the links work?
How well will my Web site handle the number of visitors I anticipate? Load testing is designed to verify that your site can handle the load (number of simultaneous users) you expect. The concept is simple. If you think your site will need to accommodate a certain number of simultaneous users, for instance 200 people buying the same widget at the same time using your secure credit card servers, then you would want to test for that load before putting your site into production. Actually generating a real-world load to test your site gets fairly complicated though. Each of those 200 visitors will access your site with different browsers and different versions of the same browser. They will use different machines, with different platforms. Their connections will range from 28k modem dial up to high-bandwidth data lines. Each variation that makes up the world of unique users who will visit your site has a different effect on its ability to handle the load. We leverage the capabilities of the Mercury Interactive suite of load and performance testing tools to create real-world user loads that take into account the complexity and latency of the Internet. When we load test your site with our proven tools and methodology, you will get results you can count on, because the last thing that should create a problem with your site is an expected load.
How many simultaneous users can my site take without slowing down significantly or crashing? Stress testing is nothing more than applying a steadily increasing load to your site until it reaches the breaking point (when site performance degrades to unacceptable levels). What this test tells you is how well your site will handle unexpected loads that may come as a result of unplanned events like changing market forces, the failure of your competitors to fill the needs of their customers, or serendipitous national publicity. Knowing your breaking point will tell you how much excess capacity you have and give you the opportunity to create a scalability plan that will ensure a quick response when your site gets hit by a rapidly increasing load.
How reliable is my site over an extended period of high user load? During a reliability test, we generate a real-world load and maintain that load over a period of time while monitoring site performance. We tell you exactly when your site begins to degrade and when it breaks under the sustained load. As Web sites become more interactive and more complex, they become more demanding on the systems that support them. These systems must store and maintain data that is left behind by each unique visitor; information such as user names, transaction records, user preferences, key user information that drives customized content, community archives, and logged data. This means that consistently high user loads have an increasingly negative impact on site performance. Most of the time we conduct various levels of all of these tests in one combined testing package. Each test contributes to the overall picture of Web site health and performance capabilities.
This is a test performed to determine the number of connections which the firewall is capable of handling.
HTTP Get requests are made by multiple users. These requests are monitored over time to determine how many Get requests the web server can handle per second
Error Introduction testing involves checking an application's ability to handle erroneously entered information.
Bound Testing Validates an application's ability to handle out-of-bounds information such as oversize integers and out-of-range dates.
Proof of Concept testing provides testing and modeling for proving a site's configuration before launch.
This testing will determine whether new features or bug fixes have caused new bugs or problems with the function of a web site. Every page on the web site will be examined for broken links, images, or other missing elements. Every form will be filled out with appropriate information and the results checked against the design specification for the web site. This testing should be repeated for each significant change to the web site to insure its integrity. Any new errors found will be reported in a standard format including the issue, steps to duplicate it, expected results, actual results, and any additional comments. The length of time that is required for this testing is very dependent on the complexity of the web site being tested. The testing can be automated, but any scripts must be maintained in order to be effective. Steps include review of the design specification, setup for testing, and test execution.
This testing measures the ease with which a user can accomplish pre-defined tasks. To accomplish this testing, a designated number of testers will be assigned a predefined list of tasks. Notes will be made as each link is selected to help keep a trail of selected pages. More than one tester should run through each task, and it is recommended that they fit different demographics to provide a better sampling of users. If there is more than one way to accomplish a certain task, testers can repeat the process after being guided toward the different method. All of the notes from each tester will be gathered into a final report. The notes will all be in a standard format and will include the task being attempted, the starting URL, the date, the tester's name, the number of times this task has been attempted, a rating of how easy the task was, and any specific comments from the tester. The length of time that is required for this testing is dependent on the number of tasks selected for testing and the number of users to run the tests. The phases for this test usually include task definition, setup, and test execution. |
|
|||||
|
|
|
|
|
|
|
| Home | About Us | Search | FAQ | Contact Us |
 |
 |
|
