A couple of quick points... i'll do it in reverse
Flashlights are good for testing fiber - spent many a night in a damp field doing that... just one funky trick... most everyone has a smart phone nowadays... use the camera on your smart phone to check that there is a clean connection all the way through from the fibre tranceiver in the switch... the CCD cameras will show the "light" from an SFP module as a saturated white light... this is great for showing up if there is a speck of dust caught on the SFP lens, or something on the fiber itself... just an idea.
As for the question on capacity/bandwidth.
If you have physically separate primary and secondary networks I would not bother with VLANs at all... you are just running the risk of getting into more trouble.
My suggestion with this is now, use features as tools... I don't use a wrench in my car as a daily tool (actually... ever really) I certainly don't pop the hood everyday before I start her up to drive to an appointment (modern cars... like modern networks are a bit more reliable than the used to be to say the least!). Putting things in separate VLANs in a layer 3 paradigm is really just creating a false sense of security. All you are doing with VLANing up a network is placing a number in the dot1q header... like that is going to save your show, or magically create bandwidth, or have any real effect on anything (oh yeah... Voodoo LANs... they are magic of course... silly me).
DSCP QoS actually does something about traffic shaping (be warned using the blunt instrument of VLAN traffic shaping is really going to cause issues in a real-time network if you haven't got a lot of time to simulate all circumstances).
Having said all that - lets deal with some real numbers and make it more like the real world...
I am assuming that you are working on an audio centric network, and that you are not dealing with any services that are concerned with anything other than smooth running of the audio media and control systems (just providing a definition... not excluding other applications... but I am just trying to avoid going skiing in my Speedos.)
so my little torture test to see whether I 'like' a switch or not goes as follows...
I first take the thing out of the box and throw as much Dante Audio through a single port as I can - the easy way to do this is to generate as much Multicast audio as I can (as it will go absolutely everywhere if there is no management). I can generate over 1Gbps of multicast traffic using the various pieces of Dante equipment in my office (there are a lot of them... and a battery of 128x128 PCIe cards can make a big noise!).
Unsurprisingly if I smash out over 1Gbps of multicast audio over a gigabit port.. absolutely everything breaks spectacularly... to the extent that things have to be physically unplugged to regain enough control to turn off some channels!).
I use nothing more complicated than Dante Controller to measure how much multicast there is going on (to hit 1Gbps you are looking at somewhere like 640 or so channels.. which is why we say 512 as a rule of thumb).
I am measuring an entire system... not a component. My component is one of the controlled variables in the experiment, the observed effect is the performance of the system as a whole. It is pointless analysing the performance of a variable, when the concern is the performance of the system.
It would be easy at this stage to point out that not many people have enough equipment to make that much multicast bandwidth... in which case... if you don't have enough equipment to actually cause a problem... then you probably don't have a problem... so as a compromise... take all your gear... and see if you can cause a problem...
so my next stage is to remove multicast channels until I get a stable enough system running that I get decent audio through (typically I will have spotify playing some tunes through virtual soundcard to the hifi that is connected to a one of the breakout boxes I have... if the neighbours are in ... i'll even put headphones on.) The great things about using multicast for this test are:
1. I don't need to patch channels together... the devices when told to send multicast just hammer it out there like a TV transmitter
2. it causes a lot more stress to the switches in terms of actually switching data than unicast (which on the whole is fairly easy to handle).
3. The default mode of Dante is unicast... so testing a system under greater stress circumstances is more confidence inspiring.
once I am happy that I have the system "stable"... I tend to define that as at least 15 minutes operation without a crackle or a pop or anything I take a note of how much bandwidth I am using, and how many channels this is.
Next I add some channels to get the old popping and cracking back... again I note how much bandwidth I am using and how many channels that is.
Now I go into the switch and set up QoS.
Theoretically... if I have set it up "right" I should get my 15 minutes of perfect performance back... this would indicate that QoS is actually doing "something"
If I don't get my required 15 minutes of good performance back... I reduce the channel count until I do.
If the channel count I achieve with this QoS setting is in fact lower than without... then I have to ask... Did I set up QoS "wrong"... after all I just used a tool and make things worse (and yes I have used a wrench on some poor unsuspecting mechanical system that was minding its own business in the past... and yes I did make it a whole lot worse... anyone who has never made a system deteriorate by using a "tool" probably is either lying... or has never really tried it). If the QoS is "right" then its time for a sanity check... turn off QoS again, and go back to your carefully set earlier benchmark... was that right?
Once you have tweaked and played with a system and got some results... ask yourself this one question... am I EVER going to use that much resource?
I recently went through this process with a company that had some switches... these switches spectacularly failed the multicast torture test... but they did hold up to doing 256x256 channels of audio on a port. The requirement for these switches was for a 20 channel speaker distribution system... they cost a few 10s of $ each... so they failed at unrealistic counts, but exceeded the requirement by 10x... they were judged to be good... in the same way I wouldn't try to lift a 1.5ton PA hang with a 1ton motor... I might do it with a pair of 2-ton motors. Would I lift a single 400lb cabinet with a pair of 2-ton motors... no.. that would be silly... I could use a 1/2ton motor for the job. Is it better to use the pair of 2-tons... well... no... its irrelevant really... except for the obvious waste
To the point of creating torture for networks... you could "try this at home" using a battery of Virtual Soundcards... anyone who is interested in doing this... get in touch and we'll work out how!