According to blogs I've read by SQL folks, the counts of reads and writes are PHYSICAL actions, not logical ones. That is, an actual request to the disk I/O subsystem to read a block(s). [Reads are typically 64K, whereas writes are 12K.]

So, one SELECT would typically take multiple reads. But it could take none, if the entire table were already in buffers.

If you can stop other activity, then of course you could capture sys.dm_io_virtual_file_stats before and after the SELECT statement and compare them too.

Note that earlier activity on the table CAN affect the results you get. If the table was read earlier and is still in the buffers, you will see much less reads than you would if the table was not already in the buffers.

That is, anything that was already read is "saved", so it won't count against you when you re-read it. But later SQL might have "forgotten" what was read earlier from your table, and have to read the whole table again, thus showing more reads the second time.

On a test/qa system, you could flush the buffers and make sure you counted every read, but that can hurt performance, so it's best not to do it on a prod system.