Windows Group Policies control many different aspects of a running machine. I'm not sure there could be a single way to test the breadth of what a policy could cover.
My approach is to define a test for each policy component (that can be tested) and use whatever tool is appropriate to execute that test. Sometimes that tool can be a script (Powershell, Python, etc.), a packaged tool (Nexpose, metasploit, etc.) or a manual test (click here then there, etc.).
The idea is to treat the security policy like a software development project and to use the concept of "unit testing". Each new "function" needs to be tested for expected behaviour (does it do what I'm asking it to do?) and for unexpected behaviour (what happens when I modify the inputs it controls?). These tests are documented and the results saved. When I make a change to the policy, I re-run the tests and add whatever new tests are appropriate. In this way, I can prove that the policy is effective, and I have evidence for Change Management and Auditors (when applicable). I rest easy knowing that I am not "hoping for the best" when I set a policy.
Having this documented test process also means that when a security incident happens, I can rule out the demonstrated behaviour of the policies and look for ways that the incident occurred despite the successful running of the policy (in other words, I can ask, "if everything worked, how could this have happened?"). Or I know where a policy can fail and I can design mitigating processes to make up for the weaknesses in the policy.
By the way, I use the same process for firewall rules.
