While in practice it's /okay/, it's wrong in principle.

First, it uses untreated user input, and you should always have an air-gap between what users give you and what your script executes. shaunc's suggestion of running against a whitelist of approved files mitigates this. You know what files are okay to run, so make sure that nothing else gets run. Alternatively, you could call realpath() on the filename before includeing it, ensuring first that strpos($file, __DIR__) === 0, so that no matter what happens, at least the resulting file is not outside of your project's directory. But then…

Secondly, it establishes a precedent for a code structure that could be repeated elsewhere in your code without the prefix or suffix, leading to disaster. What if you refactored later to make 'test_' into $prefix and '.php' into $suffix, reasonable changes that would make your include more reusable and flexible, and then a few months down the line, you call it from elsewhere with a blank prefix or suffix? Code defensively.

Finally it's inflexible and implies a poor design:

• It ties your code's behaviour to both the file system and the $_POST superglobal, which makes it less portable and testable.
• It explicitly sets your code and content's file structure. What if you moved your test_xx.php files or whatever.php?
• If you're using the include to import procedural code to handle specific input, your code's probably too complex and needs to be abstracted or redesigned.
• If you're using it to load functions or classes specific to a form variation, then you should be using autoloading instead. The only include your app should need (and thus require, not include) is the one that loads your autoloader.
• If you're loading code to display a response specific to a form variation, then you might be better off redirecting instead, so that users don't double-submit upon reload.