Scripting the copy of SQL Server production database to test environment
But it seems it's problematic because it solely generates a .bak file
  although this file is still "linked" with .mdf/.ldf files. So when
  restoring it in our test environment these .mdf/.ldf files are not
  found. Then I went on specifying a 'WITH MOVE' options in the restore
  command in order to specify the location of the .mdf/.ldf file over a
  network share but I think the production server locks these file and
  prevent any read on them from the test server.


This whole statement does not really make sense. A backup file is not "linked" to the mdf/ldf files, it contains the files of that database in order to recreate them when you restore it. When you go to restore them on another server you add WITH MOVE and specify the location you want the mdf/ldf files to be stored at on that server. They do not link back to the original location where the backup was taken from, at all.

Using backups is the most common method for refreshing a development environment. You would generally base current you can keep the data in development (if needed) on how your backups are done in production (e.g. full/diff/log or just full/diff).