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.
If it's 877 you need to put QoS configuration on the VLAN interface (SVI), not physical FE ports. Also SVI doesn't support HQoS, so you'll need to simplify it for SVI.
Best Answer
@Mud, you've pretty much got the answer to your question spread over several comments so I'm merely consolidating it here in a single answer.
On the 7600s/6500s you can filter BFD (control-plane traffic) at the interface level just like any other traffic (transit traffic passing through the device).
When you apply an ACL to a port on the line card its applied to all traffic on that interface. Traffic that needs to be process by the RSP or DFCs if you are using them needs to be punted there which is after the ACL is processed.
As a rule of thumb I have been including control-plane traffic in QoS policies of late, such as the following where "class NC" matches CS6 & CS7 only:
If you write a CoPP policy for your 7600s/6500s you need to write ACLs that match all your relevant kinds of control-plane traffic. So you can also match BFD traffic by matching traffic to/from UDP port 3784 (and lock that down further to your interface IP if possible).
As @ytti said you need to be wary of the BFD timers on your setup, if you haven't got DFCs your running BFD on the RSP/CPU power. In that case you might also want to look at tweaking you "process-max-time" global command and the process schedule "scheduler allocate xxx xxx".
The Cisco recommended minimum is
bfd interval 100 min_rx 100 multiplier 3
but on some production boxes without DFCs I am actually runningbfd interval 500 min_rx 500 multiplier 3
which has been fine, I think on the boxes with DFCs which I don't have access to right now I'm running the same.You can see these references for more info, which cover BFD tuning and ACLs for control plane traffic (both CoPP and interface ACLs), and also some control-plane tuning that is generally good practice, also QoS behaviour with control-plane traffic:
http://www.cisco.com/c/en/us/td/docs/routers/7600/troubleshoot/guide/7600_Trouble_Shooting.pdf
http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/12-2SR/configuration/guide/swcg/dos.html
http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html
http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html