To my mind, an automated build is something that
- happens automatically, either on a schedule or with each commit to source control
- creates a set of artefacts that can be deployed simply to any server
The aim is to have a deployment process that can be repeated -- read: tested -- so that by the time you deploy to production, you have a fair degree of certainty that things won't go wrong. The less human interaction in the build and deploy processes, the safer your release will be.
If you have a non-compiled language, you can still build a site and zip it up to create a single artefact.
A good CI tool will allow you to script many tasks into the build process, including the running of unit tests. It will also keep records of your successful and unsuccessful builds, test coverage, etc. But none of that is part of what I'd define as an automated build. (ie. A good automated build process has these things, but a poor one doesn't fail to be called "automated build" because it lacks those things.)
I would suggest that integration/regression tests be run as part of the deployment process, rather than the build process (although, if you have a convenient environment, you can deploy with every build).