Programmatically 'measuring' password security is really hard: What you want is a number that tells you how hard it is for an attacker to guess the password.
A good approximation usually is to look at the number of possible passwords that would result from using the same generation algorithm, operating under the assumption that the attacker knows the generation algorithm and that the password is picked randomly among all the possible outputs of this algorithm.
This is easy to get, if you define the algorithm yourself and give the user a fixed, generated password. You can then do a calculation along the lines of "10 characters randomly selected from a set of 62 characters" = 839299365868340224 possibilities ~ 59.5 bits of entropy.
Unfortunately a lot of sites let the user choose the password and then things get hairy. Now neither you nor the attacker knows the generation algorithm. The attacker has to settle for the next smartest thing: Try a couple of reasonable algorithms, and all generated passwords for each algorithm (skipping duplicates). Sensibly the attacker would start with common algorithms (such as "name of a family member") and/or ones that generate only a small number of possible passwords ("4-digit PIN").
Now to get a numeric grasp on the security of the resulting password you can't just look at the total number of possible passwords, but have to also take into account the order that an attacker would try them in. Something along the lines of a weighed average of the number of passwords per algorithm and probability of that algorithm being used.
There's a closely related concept called Kolmogorov complexity: It describes the information content of a string as the length of the shortest program (in some generic programming language) that can recreate the string. Example: "aaaaa" and "abcdefghijklmnopqrstuvwxyz" have approximately the same complexity of 3 if our language allows to say things like "5*a" and "a-z", while "oabuf" would have complexity 5.
A smart attacker would try passwords in order of increasing Kolmogorov complexity, so you would be home free if you could calculate that. Unfortunately you can't.
Overall the best approach to password security is to give useful advice to users on how to choose a good password, see this study. This paper recommends the pass phrase method: Take a sentence, and use the first letters of all the words. This gives good memorability and security.
Another good method is the XKCD method, also known as correct horse battery staple (the comic also gives a good illustration of my remarks on multiple algorithms above).
Given that you can't reasonably compute password strength without knowing the algorithm, and you can't generally know the algorithm, I would suggest refraining from trying to do so. Having a non-functioning password strength meter will send the wrong signals to your users (for example, most password strength meters vastly underestimate the strength of XKCD passwords). Instead:
- Give advice on how to choose a good password
- Don't make it hard to use a good password (e.g. by having arbitrary limits on the length and character set; you're going to hash the password anyway, right?)
- Use cracklib on the server side to weed out catastrophically bad passwords.