Web Application Structure
Web application is commonly structured as a three-tiered application.
Web based architecture is multi-tier involving atleast a database server(third tier), an application server(middle tier-Dynamic Web content Technlogy Ex:ASP, ASP.NET, CGI, ColdFusion, JSP/Java, PHP,embPerl, Python) and a frontend server(First tier-Web Browser ex:Internet Explorer,Mozilla,Netscspe etc).
Though many variations are possible, a Web application is commonly structured as a three-tiered application. In its most common form, a Web browser is the first tier, an engine using some dynamic Web content technology (such as ASP, ASP.NET, CGI, ColdFusion, JSP/Java, PHP,embPerl, Python, or Ruby on Rails) is the middle tier, and a database is the third tier. The Web browser sends requests to the middle tier, which services them by making queries and updates against the database and generates a user interface.
Client-Server Application Structure
Client-server architecture is two-tier.
The client-server software architecture model, distinguishes client systems from server systems, which communicate over a computer network. A client-server application is a distributed system that constitutes of both client and server software. A client software or process may initiate a communication session, while the server waits for a requests from a client.
Friday, May 16, 2008
Wednesday, May 14, 2008
Negative Testing
Aims of Negative Testing
*Negative Testing as Testing aimed at showing software does not work.
This can lead to a range of complementary and competing aims;
· Discovery of faults that result in significant failures; crashes, corruption and security breaches
· Observation and measurement of a system’s response to external problems
· Exposure of software weakness and potential for exploitation
While a fair definition, it is far from being generally accepted. ‘Negative Testing’ is a term that is re-
defined site-by-site, and sometimes even team-by-team. A common way that practice differs from the
(British Standard) definition is that it includes tests that aim to exercise the functionality that deals with
failure;
· Input validation, rejection and re-requesting functionality (human input and external systems)
· Internal data validation and rejection
· Coping with absent, slow or broken external resources
· Error-handling functionality i.e. messaging, logging, monitoring
· Recovery functionality i.e. fail-over, rollback and restoration
This paper will deal with tests designed to make the system fail, and tests that are designed to exercise functionality that deals with failure.
*Negative Testing as Testing aimed at showing software does not work.
This can lead to a range of complementary and competing aims;
· Discovery of faults that result in significant failures; crashes, corruption and security breaches
· Observation and measurement of a system’s response to external problems
· Exposure of software weakness and potential for exploitation
While a fair definition, it is far from being generally accepted. ‘Negative Testing’ is a term that is re-
defined site-by-site, and sometimes even team-by-team. A common way that practice differs from the
(British Standard) definition is that it includes tests that aim to exercise the functionality that deals with
failure;
· Input validation, rejection and re-requesting functionality (human input and external systems)
· Internal data validation and rejection
· Coping with absent, slow or broken external resources
· Error-handling functionality i.e. messaging, logging, monitoring
· Recovery functionality i.e. fail-over, rollback and restoration
This paper will deal with tests designed to make the system fail, and tests that are designed to exercise functionality that deals with failure.
Monday, May 12, 2008
SMOKE TESTING
SMOKE TESTING
Smoke testing is an integration testing approach that is commonly used when “Shrink-Wrapped” software products are being developed. It is designed as pacing mechanism for
time-critical projects,allowing the software team to asses its project on a frequent basis.
Smoke testing approach encompasses the fallowing activities:
1.Software components that have been translated into code are integrated into a “build”.
A build includes all data files,libraries,reusable modules,and engineering components that are required to implement one or more product functions.
2.A series of tests designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule.
3.The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.
(Source:Software Engineering :Roger S Pressman)
The smoke test should exercise the entire system from end to end.It does not have to be exhaustive,but it should be capable of exposing major problems. The smoke test should be thorough enough that is the build passes,you can assume that it is stable enough to be tested more thoroughly.
Smoke testing benefits:
Integration risk is minimized: Because smoke tests are conducted daily,incompatibilities
and other show-stopper errors are uncovered early,thereby reducing the likelihood of serious schedule impact when errors are uncovered.
The Quality of the end-procuts is improved: Because the approach is construction (integration) oriented,smoke testing is likely to uncover both functional errors and architectural and component-level design defects. If these defects are corrected early,better product quality will result.
Error diagnosis and correction are simplified: Like all integration testing approaches ,errors uncovered during smoke testing are likely to be associated with “new software increments”- that is, the software that has just been added to the build(s) is a probable casue of a newly discovered error.
Progress is easier to asses: With each passing day, more of the software has been integrated and more has been demonstrated to work. This improves team morale and gives managers a good indication that progress is being made.
Smoke testing is an integration testing approach that is commonly used when “Shrink-Wrapped” software products are being developed. It is designed as pacing mechanism for
time-critical projects,allowing the software team to asses its project on a frequent basis.
Smoke testing approach encompasses the fallowing activities:
1.Software components that have been translated into code are integrated into a “build”.
A build includes all data files,libraries,reusable modules,and engineering components that are required to implement one or more product functions.
2.A series of tests designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule.
3.The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.
(Source:Software Engineering :Roger S Pressman)
The smoke test should exercise the entire system from end to end.It does not have to be exhaustive,but it should be capable of exposing major problems. The smoke test should be thorough enough that is the build passes,you can assume that it is stable enough to be tested more thoroughly.
Smoke testing benefits:
Integration risk is minimized: Because smoke tests are conducted daily,incompatibilities
and other show-stopper errors are uncovered early,thereby reducing the likelihood of serious schedule impact when errors are uncovered.
The Quality of the end-procuts is improved: Because the approach is construction (integration) oriented,smoke testing is likely to uncover both functional errors and architectural and component-level design defects. If these defects are corrected early,better product quality will result.
Error diagnosis and correction are simplified: Like all integration testing approaches ,errors uncovered during smoke testing are likely to be associated with “new software increments”- that is, the software that has just been added to the build(s) is a probable casue of a newly discovered error.
Progress is easier to asses: With each passing day, more of the software has been integrated and more has been demonstrated to work. This improves team morale and gives managers a good indication that progress is being made.
Subscribe to:
Posts (Atom)