Yes, you are doing the correct approach. Or rather, "a" correct approach, in your specific circumstance.
You are proposing to build the image beforehand, not as part of each individual Jenkins job. Then your Jenkins job will consist of running the image; and in that ephemeral state (i.e., inside the container) you are checking out the test script, and running it.
The more usual alternative would be to leave the actual git checkout to Jenkins, and pull the script into your container with a bind volume. Jenkins has to be able to access your git repository anyways, so you get this checkout for free. There are two sides to the coin here: if you do the git checkout from inside the container, then you can run your test outside of Jenkins with no change whatsoever - say, during development, on your own machine. In any case, if you do the git checkout from inside, and if you need credentials to access the git repository, be sure to handle those securely. Don't put cleartext passwords in the image, or ssh keys with an empty passphrases.
The benefit you are getting from this is that your test environment (libraries, 3rd party test drivers and so forth) is well defined, so you can run it on any Jenkins node you have available. By not creating new images whenever your code changes, you avoid creating and distributing new images for every job.
I do not need any product code, my scripts is all that is required
So you would never actually deploy those images anyways - hence it is perfectly fine to not build them each time. You still should be automatically building your images - no matter if you do it as part of the actual job, or as a separate job which only does it when the Dockerfile (and whichever files it pulls in with ADD / COPY) changes. Not for technical reasons, but to avoid a manual step.
