You cannot check for implementation flaws. What you can see from a client are:
Usage of inherently weak protocols. By checking that the server supports TLS 1.1 and 1.2, you are already ruling that out.
Flagrant inappropriateness. For instance, if the server's public key (seen in the server certificate) is way too small for security (e.g. a 512-bit RSA key). Or if you notice that the server's "random" is always the same.
This reverses the burden of proof. Normally, a given implementation should proactively strive to demonstrate that it does things correctly, by (for instance) explaining, in its documentation, that proper development rules have been followed when implementing. This can be as simple as stating "we use LibfoobarSSL version 42.17", but there must be some sort of documentation. It is not your job to "validate" the implementation against flaws; it is well-known that such a posteriori blind validation does not work. You might notice the most glaring holes, but not finding anything does not mean that there is nothing to found.
As an example, circa 1996, the SSL implementation in Netscape (the then-leading Web browser) was hopefully weak because of a very bad PRNG -- statistical tests could not show the problem, though, because the issue was bad seeding: most of the internal state of the PRNG was predictable, so it was a matter of a few seconds to crack any SSL tunnel, but statistical tests would not have shown anything amiss. Detection of that flaw required reverse engineering. This cannot be automated with a tool.