There are multiple ways to test a game, two most used are: unit and integration testing.
For unit testing you're testing the inner workings of the game, without actually running it. You can do this for specific modules which have dependencies abstracted away (e.g., logic that computes the Quest XP you get, based on a given set of factors; whether a given sound is played). Depending on how much you abstract your logic, you could test more, but for unity specifically, it might be harder given the way the game architecture is done (e.g., inheriting from monobehaviour). Nevertheless, applying OOP patterns like composition, you can extract bits of logic that can be tested in a deterministic way (e.g., physics), even if sometimes it can be seen as a bit extreme. It all depends on how much time you have, whether you started from scratch with the project or not, how much experience you have, etc. In general, I haven't seen much unit testing in games compared to the other non-game software projects. This kind of testing is quite easy to automate as you provide mocked behaviors that you simulate.
For integration testing, you interact with the "whole" game at a given time, when all parts are running. Depending on the depth of things you want to test, I see it might be very easy to outright impossible.
One idea would be to have an "integration test" build, which logs every (most) actions it does (i.e., spawning monster, playing sound, starting effect, spawning particle). After it runs for a given time, you can check the logs to see whether it matches a given pattern (this also depends on how random the game is, based on the inputs). Now, this sounds simple, but the question is: how you tell the game to do the wanted actions? Which brings me to the second idea.
Other idea would be to have kind-of server in the game, again, for testing purposes, which is able to process requests (e.g., via a REST API), and which acts upon the entities. The requests could be things like: move left, jump, rotate X degrees, change viewport, etc. With this approach you can also do the "checks" that the game is acting as expected, either by checking state directly, or verifying a virtual log of events that happened. This approach is used by other UI-testing tools for mobiles (e.g., Xamarin Test Cloud)
For the controlling part, if your game is touch/browser based, you can instead simulate the actions via a virtual touch/input device, but this is a bit more hard, depending on the actions complexity.
Another idea, with regards the visual aspect, is to take some reference screenshots, images during an initial phase, and comparing them after the same action sequence happened on a newer build. The comparison can have a specific deviation allowance, to guard against minor changes. During the tests, you can log the screens that didn't match and see the difference. It may be the case that the reference screens need to be updated due to different changes. In that case the game could be run again with the preset actions, and reference images be updated. This will probably not work very well with particle systems, or randomly-generated scenes, unless you use the previous idea to set some sort of seed, that is used to generate the particles.
For the sounds, it might be a bit harder, cause it will involve "listening" to the OUT device (which is not always possible IIRC, since it depends on the hardware of the system). But if it's possible you can do the same reference-based comparison as you do with the images.
I hope this sheds some light on how you could automatise the game testing.
Later Edit: I just see that there was another related question which might give you some pointers on how you'd do certain bits: Automated testing of games