1. Performance Testing
In white box testing testers, developers, system administrators and DBAs work together in order to instrument the application code and the database queries (via specialized profilers for example), and the hardware/operating system of the server(s) running the application and the database (via monitoring tools such as vmstat, iostat, top or Windows PerfMon). All these activities belong to performance testing.
The goal of performance testing is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing.
These bottlenecks can exist at multiple levels:
a. at the application level, developers can use profilers to spot inefficiencies in their code (for example poor search algorithms)
b. at the database level, developers and DBAs can use database-specific profilers and query optimizers
c. at the operating system level, system engineers can use utilities such as top, vmstat, iostat (on Unix-type systems) and PerfMon (on Windows) to monitor hardware resources such as CPU, memory, swap, disk I/O; specialized kernel monitoring software can also be used
d. at the network level, network engineers can use packet sniffers such as tcpdump, network protocol analyzers such as ethereal, and various utilities such as netstat, MRTG, ntop, mii-tool.
From a testing point of view, the activities described above all take a white-box approach, where the system is inspected and monitored "from the inside out" and from a variety of angles.
2. Load Testing
Are you actively profiling your application code and/or monitoring the server(s) running your application? If the answer is yes, then you're engaged in performance testing. If the answer is no, then what you're doing is load testing.
In the testing literature, the term "load testing" is usually defined as the process of exercising the system under test by feeding it the largest tasks it can operate with. Load testing is sometimes called volume testing, or longevity/endurance testing.
In the testing literature, the term "load testing" is usually defined as the process of exercising the system under test by feeding it the largest tasks it can operate with. Load testing is sometimes called volume testing, or longevity/endurance testing.
Examples of volume testing
a. testing a word processor by editing a very large document
b. testing a printer by sending it a very large job
c. testing a mail server with thousands of users mailboxes
d. a specific case of volume testing is zero-volume testing, where the system s fed empty tasks
a. testing a client-server application by running the client in a loop against the server over an extended period of time
Goals of load testing
a. expose bugs that do not surface in cursory testing, such as memory management bugs, memory leaks, buffer overflows, etc.
b. ensure that the application meets the performance baseline established during performance testing. This is done by running regression tests against the application at a specified maximum load.
Although performance testing and load testing can seem similar, their goals are different. On one hand, performance testing uses load testing techniques and tools for measurement and benchmarking purposes and uses various load levels. On the other hand, load testing operates at a predefined load level, usually the highest load that the system can accept while still functioning properly. Note that load testing does not aim to break the system by overwhelming it, but instead tries to keep the system constantly humming like a well-oiled machine.
3. Stress Testing
If you want to actually discover bugs and to see if your application fails and recovers gracefully, you need to do stress testing. Blast your Web server with double the number of users for example. Unplug network cables randomly (or shut down/restart switch ports via SNMP). Take out a disk from a RAID array.
The main purpose behind this madness is to make sure that the system fails and recovers gracefully.
Here are some ways in which stress can be applied to the system:
a. double the baseline number for concurrent users/HTTP connections
b. randomly shut down and restart ports on the network switches/routers that connect the servers (via SNMP commands for example)
c. take the database offline, then restart it
d. rebuild a RAID array while the system is running
e. run processes that consume resources (CPU, memory, disk, network) on the web and database servers
If chair is designed for 100 kg weight, and my weight is 70 kg then that testing is called as normal testing. If my weight is 100 kg then that testing is called as load testing. If my wt is 120 kg then that testing called as stress testing.
Differences
a. Performance test: To determine or validate speed, scalability, and/or stability.
b. Load test: To verify application behavior under normal and peak load conditions
c. Stress test: To determine or validate an application’s behavior when it is pushed beyond normal or peak load conditions.
d. Capacity test: To determine how many users and/or transactions a given system will support and still meet performance goals.
a. Performance test: To determine or validate speed, scalability, and/or stability.
b. Load test: To verify application behavior under normal and peak load conditions
c. Stress test: To determine or validate an application’s behavior when it is pushed beyond normal or peak load conditions.
d. Capacity test: To determine how many users and/or transactions a given system will support and still meet performance goals.
4. GUI Testing
GUI testing is a process to test application's user interface and to make sure that it confirms the design requirements.
1. Text Box
1. Text Box
a. Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar.
b. If it doesn't then the text in the box should be grey or non-updateable.
c. Try to overflow the text by typing to many characters.
d. Enter invalid characters - Letters in amount fields, try strange characters like + , - * etc. in All fields.
e. SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box.
2. Radio Button
Left and Right arrows should move ON Selection. So should Up and Down. Select with mouse by clicking.
Check Boxes: Clicking with the mouse on the box, or on the text should SET/UNSET the box. SPACE should do the same.
3. Command Buttons
a. If Command Button leads to another Screen, and if the user can enter or change details on the other screen then the Text on the button should be followed by three dots.
b. All Buttons except for OK and Cancel should have a letter Access to them. This is indicated by a letter underlined in the button text. The button should be activated by pressing ALT+Letter. Make sure there is no duplication.
c. Click each button once with the mouse - This should activate
Tab to each button - Press SPACE - This should activate
Tab to each button - Press RETURN - This should activate
d. If there is a Cancel Button on the screen , then pressing should activate it.
4. Aesthetic Conditions
a. Is the general screen background the correct colour?
b. Are the field prompts the correct colour?
c. Are the field backgrounds the correct colour?
d. In read-only mode, are the field prompts the correct colour?
e. In read-only mode, are the field backgrounds the correct colour?
f. Are all the screen prompts specified in the correct screen font?
g. Is the text in all fields specified in the correct screen font?
h. Are all the field prompts aligned perfectly on the screen?
i. Are all the field edit boxes aligned perfectly on the screen?
j. Should the screen be resizable?
k. Should the screen be minimisable?
l. Is all user input captured in UPPER case or lower case consistently?
5. Validation Conditions
a. Does a failure of validation on every field cause a sensible user error message?
b. Is the user required to fix entries which have failed validation tests?
c. Have any fields got multiple validation rules and if so are all rules being applied?
d. If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message.?
e. Is validation consistently applied at screen level unless specifically required at field level?
f. For all numeric fields check whether negative numbers can and should be able to be entered.
g. For all numeric fields check the minimum and maximum values and also some mid-range values allowable?
h. For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?
i. Do all mandatory fields require user input?
j. If any of the database columns don't allow null values then the corresponding screen fields must be mandatory. (If any field which initially was mandatory has become optional then check whether null values are allowed in this field.)
6. Usability Conditions
a. Is all date entry required in the correct format?
b. When an error message occurs does the focus return to the field in error when the user cancels it?
c. Do all the fields edit boxes indicate the number of characters they will hold by there length? e.g. a 30 character field should be a lot longer.
7. Data Integrity Conditions
a. Check the maximum field lengths to ensure that there are no truncated characters?
b. Check maximum and minimum field values for numeric fields?
c. If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
8. Date Field Checks
a. Assure that leap years are validated correctly & do not cause errors/miscalculations
b. Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations
c. Assure that 00 and 13 are reported as errors
d. Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations
e. Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations
f. Assure that Feb. 30 is reported as an error
g. Assure that century change is validated correctly & does not cause errors/ miscalculations
9. Alpha Field Checks
a. Use blank and non-blank data
b. Include lowest and highest values
c. Include invalid characters & symbols
d. Include valid characters
e. Include data items with first position blank
f. Include data items with last position blank
5. Negative Testing
1) Testing the application for fail conditions, negative testing is testing the tool with improper inputs.for example entering the special characters for phone number.
2) Testing aimed at showing software does not work. Also known as "test to fail".
3) Negative testing is testing that is directed to showing that something will -not- work. It's such a natural part of regular testing that I doubt that most people know that there is both a "positive" and "negative" testing.
4) Negative Testing is simply testing the application beyond and below of its limits. For example:
A) We want to enter a name for that negative test can be first we enter numbers.
B) We enter some ASCII characters and we will check
C) First numbers and characters we will check
D) Name should have some minimum length below that we will check
5) Negative testing is testing the tool with improper inputs. For example entering the special characters for phone number.
6) Negative testing is kind of testing doing with the Boundary values, may be max val and min val or with some other kind of data type input etc.
7) Testing the application for fail conditions.
8) here we test if system is doing something which it is not supposed to do ex in password field we try to enter only alphabets were as in requirement it is specified password should have at least 1 no, if it accepts only alphabets then test case is fail otherwise it's pass.
9) Negative testing is testing an application giving invalid data, for example entering wrong user id or wrong password to make the test unacceptable.
10) Negative testing is testing the application with negative assumptions and navigations to get a negative result which leads to positive one.
11) This is a type of testing which is done by tester's to make sure that the system works fine for the Inputs which the code dosen't designed for.
12) Negative testing is a testing which ensures that the application should not do what it is not supposed to do.
13) Negative testing is performed to check how the application works if an unexpected input is given which is out of requirements, to check the stability of the application. "For a error to be thrown it doesn’t throw error and error shouldn’t thrown it throws an error".
14) Testing the application for fail conditions, negative testing is testing the tool with improper inputs.for example entering the special characters for phone number.
15) Testing the system using negative data is called negative testing, e.g. testing the password where it should be minimum of 8 characters so testing it using 6 characters is negative testing.
16) In negative testing, we check whether the application or system handles the exception properly or not. It is nothing but "Test to Break" testing.
