An issue with the use of tmp files during testing came up a week or so ago here, and it may be that a solution in that thread is going to be similar to the solution you will have to employ:

t/CVE-2015-1592.t uses File::Temp to create a temporary directory. Typically this will be in /tmp for linux, or wherever Windows thinks temp directories should go. File::Temp uses File::Spec's tmpdir function to tell it where to put tempfiles and tempdirs. On Windows, File::Spec gets that information from File::Spec::Win32, which has the following semantics:

=item tmpdir

Returns a string representation of the first existing directory
from the following list:

    $ENV{TMPDIR}
    $ENV{TEMP}
    $ENV{TMP}
    SYS:/temp
    C:\system\temp
    C:/temp
    /tmp
    /
[download]

In other words, you can set $ENV{TMPDIR} or one of several other environment variables to influence where the temporary directory will be created. By default it will be in SYS:/temp, or C:\system\temp, or C:/temp, or /tmp, or /, in that order. But you could specify an alternate location before running the tests. It's been years since I used Windows in any meaningful way, but Google seems to find for me that set or setx can be used to set the appropriate environment variable. I've found under Linux it's useful to create a ~/tmp/ for times when the systemwide /tmp is not appropriate. For example, on my centos7 box /tmp is mounted without executable set, so tests that must execute something in /tmp will fail (local::lib, for example) unless I hint the system to use a different temp directory with less restrictive execution privileges.

Before I posted I suspected the temp file so I tested it. I modified the test file to print the temp file location to STDERR and turned off the CLEANUP option in tempdir(CLEANUP => 1). I then ran the install again and found the 'sploit' file in the temp folder. That wasn't the problem.

The file "t/CVE-2015-1592.inc" is one of the files included with the module in the test folder. It is being deleted by the Antivirus scanner as soon as it is copied to the hard drive. When "t/CVE-2015-1592.t" runs it attempts to run the inc file with Perl (actually $^X) but it isn't there so Perl complains with the "Can't open Perl script [...]" I posted in the OP. Normally, the test runs the inc file, which contains the exploit code, and outputs the result to sploit. It then checks the contents of the sploit file for the warning that Storable is supposed to produce when it detects the exploit.

The file "t/CVE-2015-1592.inc" is one of the files included with the module in the test folder. It is being deleted by the Antivirus scanner as soon as it is copied to the hard drive

Your AV software is committed to sabotaging the test.
If you want to install version 3.11, I can see only 2 options - either you disable the AV software, or you force install Storable-3.11.
I guess a third option is to modify t/CVE-2015-1592.t to be skipped if t/CVE-2015-1592.inc is missing.

The version of Storable that ships with current blead is 3.14 and, although it contains a test file named t/CVE-2015-1592.t, there's no sign of CVE-2015-1592.inc.
Perhaps its removing of CVE-2015-1592.inc is in response to the very problem you are experiencing.

I don't know why Storable-3.14 is not available separately.

I guess another option is to grab that source from blead source (it's in the 'dist' directory) and see how it goes - or even update your perl to the latest devel vesion of 5.29.7.
Perl-5.29.7 is proving to be very serviceable for me on Windows 7. It's just a matter of whether you're prepared to build it and use it.

Cheers,
Rob