Originally posted by Syed Saifuddin:
I developed web based HR & Payroll System and now it my responsibility to finalized and assured that this system cannot make mistake in calculating salary and other critical issue such as security factor and performance.
For web applications, you have basically two categories of tools: those that simulate the HTTP protocol and those that control a real web browser.
The power of the former lies in that you can write your tests in Java/Ruby/Python/etc. and run them from anywhere (since they're "headless"). The downside with these tools is that they duplicate the functionality of real web browsers and thus may not be a good enough representation of a browser's capabilities. For example, HttpUnit and JWebUnit rely on the Rhino JavaScript engine which doesn't implement
all Internet Explorer specific JavaScript functions. In other words, even if all your automated end-to-end tests written with a tool like HttpUnit/JWebUnit/HtmlUnit/Canoo WebTest/etc. pass without a single failure, you can't really say that the same tests would pass if executed manually using a specific browser like IE or Firefox. In short, these are great tools but mostly suitable for applications that are strict about using only those features of JavaScript that are supported by the underlying JavaScript engine.
The power of the latter group--those tools that control a real browser--obviously is in how they use the real thing for testing and thus give a better representation of reality in terms of JavaScript. The downside is that executing tests through the browser is rather difficult to do with current tools in a platform/browser independent manner. For example, WTR, PAMIE, SAMIE, and Jiffie all let you control Internet Explorer on Windows but none of those tools work on Linux, for example, nor do they have any kind of support for Mozilla/Firefox. Selenium is platform independent as it supports Internet Explorer, Mozilla/Firefox, and Safari on Windows, Linux, and OS X (where applicable) but it has its own issues (the "TestRunner mode" requires you to manually start your server, launch a browser, and click a button in order to run the tests; the "Driven mode" lets you write your tests in Java/Ruby/Python/etc and execute them with the same tools you use to run your unit tests without manual steps but the driven mode is significantly slower to execute than any of the alternatives (due to its rather exotic architecture).
Now, you can use either class of these tools for functional testing, i.e. verifying that the right things happen when a user clicks through a certain sequence of steps. For performance testing, you might consider wrapping your HttpUnit/JWebUnit/HtmlUnit tests with JPerfUnit or go with a specialized load testing tool such as Grinder or JMeter. There's no way to use one of the browser-controlling tools for performance testing in a meaningful way.
For security, your best bet is to write a couple of "regular" functional tests to verify that you can't access certain areas of the web application unless you've logged in but that's not really a
security issue--just regular functionality. The so-called "real" security testing would involve a security consultant analysing your architecture and running penetration tests against your system with tools like Nessus.
Having said all that, I'd like to suggest that you test domain logic like salary calculations in your *unit* tests instead of functional tests.