Flash loses charge faster at higher temperatures. However, within a week you probably won't be able to trigger that "rot" at temperature where your flash memory (same for magnetization of hard drives, by the way) doesn't combust so....
So, you'll have to go through different routes. As Justme says, you'll have to stress your medium.
The classical stress here would be write stress. A sensible test would:
- Use a pseudo-random number generator (PRNG) (e.g. xoroshiro128+, or really, anything that takes a seed), and a random seed \$a\$.
- Seed your PRNG with \$a\$.
- Start a timer.
- Generate a block size multiple of random data (e.g. 4 MB) and write it straight to your storage device (not through a file system, but to the raw device). While things are writing, prepare the next block of random data (operating systems tend to buffer things, so that you can continue working while it's writing)
- repeat 4. until your stick is full.
- Close the device and flush the buffers to stick (this is OS-dependent, and easier on Linux than on windows, for example). Note down the time on the timer, and use it as average write speed.
- Seed your PRNG with $a$.
- Start a timer.
- Read a block multiple (e.g. 4MB) of data from your device.
- Generate a random number with your PRNG, compare to device-read data.
- Repeat step 10 until you've checked your whole block. Accumulate the bit error count.
- Repeat 10. – 11. until you've read your whole device.
- Close the devices.
- Note down the time, and use it as average read time. Note down the amount of bit errors.
- Pick a new \$a\$
- Go back to 2.
Depending on your device's quality, your luck, and the speed at which you can write, you should be seeing increasing error rates (i.e. memory cells rotting!) and decreasing read speeds.
Read speed reduction mainly stems from the fact that all modern mass memory employs internal checksums and/or error correcting codes. If they detect a broken memory word, error correction kicks in. Decoding erroneous words takes time, and gets more involved the more broken the codeword is.
The harsh truth is that at modern memory densities, physics isn't nice to anyone, and random bit flips will happen. That's not bad – that's why we have modern channel coding / error correcting codes (they are the same thing). Even a perfectly new storage medium will have some bit errors, but a user will never (or, to be precise, with a probability below some threshold that the user is going to be able to ignore) be subjected to them, because the ability to correct this inevitability of physics is built-in.
By writing repeatedly, you're decreasing the physical qualities of your storage medium more than a week of time could ever do. That simply makes the amount of these physical bit errors (which you don't see) higher. If all goes well, the storage controller is still able to correct these – but it will need to calculate more, and hence take more time, and hence be slower at reading. It might happen that you get more errors than the decoder can correct – and then you actually see a bit error.
It's actually not very trivial measure these, because you'll honestly be measuring the bit error rate of your error-corrected storage medium against the bit error rates of your RAM, which isn't error-corrected (unless you use ECC RAM). That's why step 10 generates small amounts of random data: that will stay in CPU cache, and hopefully not get written to external RAM, which tends to have higher error rates. If you just generated your whole stick's worth of data and wrote it to RAM, and then compared that, you'd be checking your RAM more than your storage medium.