代码可测性度量工具Testability explorer
可测性维度包括架构设计、代码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
很多的事实证明，测试领域没有银弹。测试需要借助工具在合适场合辅助提高测试效率，最核心的还是人的判断力。
部署编译
确认机器已经搭建好maven2的环境。
设置环境变量（本机eclipse路径，更多看http://code.google.com/p/testability-explorer/wiki/HowToContribute）：
ECLIPSE_LAUNCHER_JAR=D:\eclipse-java-ganymede-SR1-win32\plugins\org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar
（否则提示错误：
Caused by: D:\project\google_testability_explorer\eclipse-plugin\build.xml:13: Java returned: 1
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)）
取出源代码：svn checkout http://testability-explorer.googlecode.com/svn/trunk/ testability-explorer
cd testability-explorer
执行安装部署：mvn install
调整被测工程的pom.xml
在project节内加入：
<reporting>
<plugins>
<plugin>
<groupId>com.google.testability-explorer</groupId>
<artifactId>maven-testability-plugin</artifactId>
<version>1.3.4-SNAPSHOT</version>
</plugin>
</plugins>
</reporting>
具体的版本号根据：D:\project\google_testability_explorer\maven-testability-plugin\target生成的jar定。
在 C:\Documents and Settings\jianzhao.liangjz\.m2\repository\com\google\testability-explorer\maven-testability-plugin\1.3.4-SNAPSHOT有maven-testability-plugin-1.3.4-SNAPSHOT.jar
从D:\project\google_testability_explorer\maven-testability-plugin\src\main\java\com\google\maven\TestabilityExplorerMojo.java 找到目标testability。
执行maven目标分析代码可测性
D:\project\morgan\trunk\member.service.china> mvn clean install
D:\project\morgan\trunk\member.service.china>mvn com.google.testability-explorer:maven-testability-plugin:1.3.4-SNAPSHOT:testability
或者看： http://code.google.com/p/testability-explorer/wiki/HowToMakeARelease
在顶级工程上执行上述命令也可，但是site目录会仅生成在各个子工程目录下。
结果如下：
Issues that cause the most untestable classes
Cost: 6,376
Classcom.alibaba.china.biz.dal.EncryptPtpis hard to test because:
It is expensive to construct an instance of the class, and every test will need to call a constructor.
These static initializers will need to be run once, when the class is loaded.Why is it bad?
| On line 30, | static void generateCipher(String)is declared | contributing 20% of total class cost |
Instead of initializing this state statically, try initializing a fresh copy in each instance. Creating new objects in Java is cheap, and this static state can't be cleaned up between tests.
Cost: 6,254
Classcom.alibaba.china.biz.common.security.BlowfishEncrypteris hard to test because:
It is expensive to construct an instance of the class, and every test will need to call a constructor.
These static initializers will need to be run once, when the class is loaded.Why is it bad?
| On line 29, | static BlowfishEncrypter()is declared | contributing 20% of total class cost |
Instead of initializing this state statically, try initializing a fresh copy in each instance. Creating new objects in Java is cheap, and this static state can't be cleaned up between tests.
Cost: 4,982
Classcom.alibaba.china.member.internal.security.Authenticationis hard to test because:
It is expensive to construct an instance of the class, and every test will need to call a constructor