Your question's pretty broad. There's a lot of different commands you can use to troubleshoot and monitor QoS, so I'll focus on the primary question you have, which is how to reasonably verify your QoS configuration is working and how to read the policy-map interface output.
The only true way to verify that QoS is working is to hook up a traffic generator and monitor your drop rate in various queues. Since that isn't typically feasible, particularly in a production environment, all you can really do is verify that the traffic is being marked and classified properly.
What you're really looking for, when it comes to verifying if your QoS configuration is working, is for the counters in the policy-map interface command to increment.
So, for example, in the output your provided:
Class-map: VOICE (match-any)
3860628 packets, 1070196895 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol sip
97348 packets, 49867304 bytes
5 minute rate 0 bps
Match: protocol rtp
3763280 packets, 1020329591 bytes
5 minute rate 0 bps
Match: access-group name NEC-PBX
0 packets, 0 bytes
5 minute rate 0 bps
Priority: 40% (340 kbps), burst bytes 8500, b/w exceed drops: 5
You can see that you're seeing packets under SIP and RTP, but not NEC-PBX. If you know you're getting SIP and RTP traffic across a link, you should see the packet counts increment and that's a reasonable way to know that your configuration is basically working.
The most common reason I've seen for alloc failures has been serious misconfiguration of the default route -- ip route 0.0.0.0 0.0.0.0 f0/0 will cause this because it's proxy-arp, and the ARP table will grow to an insane size.
A distant second place goes to dynamic routing protocols causing severe memory fragmentation.
We (and TAC) will need a lot more information to debug this. The first place I would suggest looking is the output of show memory failures alloc after failures are happening. (before rebooting)
Note: because memory is relatively cheap (when not bought from Cisco), I tend to load my routers with as much memory as they'll hold.
Best Answer
It will probably be easier to understand if you look at larger chassis (7600, 12k) and for example their SPA Interface Processor modules (SIPs) and SPA cards. Chassis have slots in which you can place designated hardware modules and those modules can have sub-slots. Keep in mind that some of this stuff can be integrated (probably the thing that is confusing you) or left for you to populate with desired hardware.
So in my example with SIP and SPA you will place SIP module in slot of the chassis, and then you place SPA cards inside sub-slots of the SIP.
In these configurations you will have interface names as:
In larger, high end routers, with IOS XR you can also see the chassis:
So the interface name describes the location of the interface from most significant part (slot in my example) to a least significant part (port in my example).