Take the 2-minute tour ×

I have about 4000 lines of code for a web-application in JavaScript / PHP / CSS / HTML. How can I test it properly?

I only support the latest version of IE and Safari. I've worked out all the bugs. Is there a good way to test it so that I could go so far as to call the code robust?

I've considered using perl Mechanize to auto fill in forms or do something similar.

I also have a PHP test class to test the inner working of my PHP classes. However is there some sort of standard or conformance guidelines to be met? Is there a way to say this code passes IEEE xxx foo standards for code robsustness etc.?

I have validated my HTML using W3 validators and I've validated my JavaScript using jslint.com.

Here is list of dilligence items:

  1. HTML / CSS passes W3 validation
  2. JavaScript passes jslint
  3. PHP passes internal PHP Test Class

User Testing

  1. Create a set of User Actions and Implement using perl mechanize or similar.

Are there standards or procedures for releasing code to the web?

share|improve this question
PHPUnit will probably be much better respected as a method for testing your PHP classes than a custom solution as it's the de facto standard for testing PHP code. –  rdlowrey Jan 2 '12 at 17:45
the only "standard" out there is private beta+ public beta with a lot of time for enough time. Your guess is as good as mine as to what values put there. –  Itay Moav -Malimovka Jan 2 '12 at 17:46
add comment

migrated from stackoverflow.com Jan 2 '12 at 18:05

This question came from our site for professional and enthusiast programmers.

3 Answers

up vote 1 down vote accepted

Software validation is a huge area, there is no one definite answer to your question. Moreover, software validation engineer is usually a special position requiring much more knowledge than development and many skills (like for example "debugging specification" that is really very non-trivial) that are now common in developer community.

Second, software validation (and code validation as an essential part of it) is not testing. There is a famous quote by Dijkstra:

Testing shows the presence, not the absence of bugs

So, this is the main difference from software validation (i.e. stating that your software is valid, contains no errors) and testing (for potential errors or bugs).

If we reduce your question to "how to properly validate a PHP-based web application?" I can give the following answer:

Taint analysis.

There are some neat tools(1,2) to perform taint analysis on PHP. This is a static analysis (that means it is done without, running your code) that identifies possible sinks (leaks) of confidential information.

I have used some of these tools (Pixy) in my own practice and found out that they, as all other tools in static analysis, seem to overestimate the potential danger. Nonetheless, they can help you to identify some security problems you might not be aware. This is especially important for web applications dealing with some sensitive data.

This won't exclude all possible vulnerabilities, like XSS, but will cover many common ones, like PHP code and SQL injections etc.

Conformity validation.

This step you already did by having run JSLint and CSS/HTML validators against your complete website.

Load tests.

If availability of your web application is an issue (or even a part of your SLA) then I would also perform some load tests. Those can be generated by some IDEs, like Visual Studio, or you can also use the open-source JMeter framework for this purposes.

share|improve this answer
Thank you very much I did not realize there were static analysis tools for PHP like there was for Javascript...I'll look into this first. –  user44388 Jan 4 '12 at 16:57
add comment

Standards are only as good as the people that enforce them. (especially true with ISO quality standards...)

If you'd like to fully test your software, you need a good requirements spec that can be used to verify the fact that you've accomplished/implemented all the tasks/features/etc as they should be implemented. Also it helps to have someone else to look at the project from just a quality assurance/software testing perspective (from code reviews to exploratory user testing).

Another note you might want to consider is that fact that without a clear requirements spec as the developer you will probably more often than not assume things as 'features' instead of 'bugs' :)

There are IEEE standards for requirements specs (IEEE 830) and test plans (IEEE 829). However I think they're a bit OTT for a lot of projects.

(I'm also slightly surprised you don't have a database?)

share|improve this answer
I have a database..I considered testing it as part of the PHP testing..as that is the only way I access it. Thanks for your input..I'll lookk at IEEE 830, and IEEE 829 just for some extra lateral knowledge...thank you for your input. –  user44388 Jan 4 '12 at 16:51
add comment

The answer is not popular.

You must have users beat the living hell out of it. After you have exhausted the list of bugs reported after many iterations of testing, you then can only call your code robust.

You testing it alone will be of little use because you are in the trees coding and cannot see the forest.

Don't you know developers are the worst testers ever? I'm a developer and I know this only after many years of falling on my face after stating proudly, "this work perfectly on my laptop".

share|improve this answer
It is also the easiest, because you test only what is being used. Another user referred ot this as Beta, and Private Beta as you don't want public users to discover bugs as they will use someone else's product if they do. –  user44388 Jan 4 '12 at 16:54
add comment

Your Answer

