This kind of testing can be incredibly fun and can expose a wide variety of defects outside of its core focus; making sure you can't destroy data. I'm no expert but I do have a few tips I hope you'll find helpful.
There are a variety of ways to try and inject SQL queries and commands into the web application; text input fields are the most obvious but depending on how your site works, you may be able to manipulate URLs to transmit injection attacks. If you can upload to your web application, don't forget to try setting file names as injection attacks.
Some familiarity with the database in question is a must; if it's not terribly complex ask the designer for an ERD ( Entity Relationship Diagram ). If it's very complex ( lots of tables, views and indexes ) then ask for some guidance on crucial fields.
The kinds of attacks I generally try consist of trying to delete tables, trying to delete or change entities, or trying to hit the database with complex queries in rapid succession to try and overtax the database server. You'll need an introduction to SQL syntax in the environment you're using ( MySQL vs MS SQL ).
Lastly, I tend to use a variety of ways to outsmart filters that might be on the text boxes; after vanilla SQL syntax is tried, using HTML or UTF encoding instead of character literals can reveal a ton of bugs. Something like this:
<alert"!xss!</<
As opposed to using literals:
<alert>"xss"</alert>
This can sometimes trick the application server into converting otherwise innocuous characters into a dangerous string.
As mentioned before, this kind of testing will often find bugs that have nothing to do with your database. For example, I once uploaded a file with an encoded "drop table" query that broke the page so that my upload history could not be shown.
Hope this helps.