Here's a basic plan. I'm happy to produce anything resembling success, it's a Uni project. Pseudo code is great.

1. Spider the site.
2. Search for forms on each page.
3. Submit each form without filling in the details to elicit a guaranteed fail.
4. Fill in the first field on the form with '-- .
5. Submit the form and compare the response to the fail (elicited by 3).
6. If response (elicited by 5) is different (than fail) then assume vulnerability.
7. If same (response = fail) then return to 4. but move to the next field.
8. If no more fields remain, move to another page.

...

However, 6. is clearly both the critical part of the application and wrong. For example, a page might respond like this

Error: '-- is not a valid user name.

Where in stage 4. the response was

Error:  is not a valid user name.

Or

Error: username must be a minimum of 6 characters.

It seems like at (4), you want to try sending some benign values first so you can see what type of page is returned under normal conditions.

For example, generate a random three-letter "user name" and submit it. You'll probably get a response like "Error: bfw is not a valid user name". or "Error: username too short".

Once you've done that, you can send your string attempting SQL injection and see if the result is qualitatively different. So if you send '-- and get the same result as you did when you sent your random benign "username", it's probably not vulnerable. On the other hand, if you get a response back that's different and includes text like "Warning, you have an error in your SQL at line 1..." then it's probably vulnerable. (It doesn't have to spit out warnings for you to conclude it's vulnerable, though. Even a generic error page might indicate vulnerability if it's substantially different to the response you got from your benign data.)

"SQL Injection Attacks and Defense" by Justin Clarke.

Offers a number of tests to discover and confirm SQL injection vulnerabilities, here's my summary of page 65.

Error triggering

"Send ' or '-- and expect to receive an error."

An error message or 500 server error indicates vulnerability. Responses tidily containing ' or '-- (as in user ' or '-- is not available with that password...) probably aren't vulnerable unless its a stack-trace.

Always true condition

"Send 1' or '1'='1 or 1') or ('1'='1 and expect to receive every entry in the database."

A site can be assumed to be vulnerable when the response code is 200 and the attack string is not received in the response. Pages containing the word 'error' or the attack string indicate resistance, as does a 500.

No condition

"Send value' or '1'='2 or value') or ('1'='2 and expect a vulnerable app to respond as though it had only received value."

Always false condition

"1' and '1'='2 or 1') and ('1'='2. If successful, it returns no rows from the table."

Microsoft SQL Server concatenation

"1' or 'ab'='a'+'b or 1') or ('ab'='a'+'b. If successful, it returns the same information as an always true condition"

MySQL concatenation

"1' or 'ab'='a' 'b or 1') or ('ab'='a' 'b. If successful, it returns the same information as an always true condition"

Oracle concatenation

"1' or 'ab'='a'||'b or 1') or ('ab'='a'||'b. If successful, it returns the same information as an always true condition"

Further examples are included throughout the book.