可测性维度包括架构设计、代码2个层面。
架构层面拟从2个角度出发积累：
1）将日常qa碰到可测性及架构建议沉淀下来
2）和架构师探讨sei atam架构评审方法
代码层面可测性可单独用testability explorer度量，也可使用hudson上testability explorer插件度量。
Google内部广泛使用的testability explorer静态分析java bytecode并按规则计算类的可测性分数，将类划分为优秀、可容忍、需要调整3个等级，默认分数分别为<=50,<=100; >100（见CommandLineConfig.java）。
Testability explorer逐行递归分析判断是否不可注入、全局变量，如果是则分值加1,直到递归深度达到Depth。本质上，testability explorer驱动研发养成符合依赖注入风格的编码习惯。Google内部也组合testability explorer等多个工具一起提升代码质量。
可测性判断用途：
1）加入到持续集成hudson/continuum内，成为进度度量指示器
2）研发根据可测性判断是否需要重构
更多参考：http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/
http://misko.hevery.com/category/testability/
可测性和代码高效间需要做平衡，可测性不能做：
1） need work的类就直接让研发重构代码
2） 直接找bug
很多的事实证明，测试领域没有银弹。测试需要借助工具在合适场合辅助提高测试效率，最核心的还是人的判断力。
