静态测试是进行接口测试的必然经历，很多人忽视了静态测试，但是实际过程中静态做的好可以很大程度上提升功能测试效率。

　　1.直接查看代码，与查找同类功能对比。

　　静态测试时我们不仅要关注业务逻辑，也要重视小的代码点，并专门与对应的同类功能产生联想。

　　1）客户端软件有很多的输入界面，其中判空处理是必须的。开发代码中常用的一个判空函数是if（xxx.isempty（））。首先界面类查找是否有控件对象未使用该函数，若未使用肯定存在bug；其次即使使用这个函数也是有bug，该函数并未完全满足需求。这个函数漏掉了输入空格的情况，正确的做法是if（xxx.trimme（）.isempty（））。那么如果在全工程内，搜索isempty，对比发现bug，最后可以选择一个输入项进行测试，通过后所有输入控间判空测试均告完毕。静态测试最多只需要10分钟，对应所有可输入业务控件不为空以及过滤空格的功能点用例可能有几十个，执行时间至少半个小时以上。静态效率比大于1：3。

　　2）可输入控件一般均有记忆功能，开发会将记忆功能浓缩成一个公共函数。同理测试一个输入项的记忆功能成功，那么所有业务输入项的记忆功能均告测试完毕。如果开发未将该功能浓缩成一个公共函数，那么出于测试效率以及代码的完美性上，我们有必要告之开发。

　　以上仅仅是一点小举例还有太多相似例子。

　　2.运行代码调试定位bug，配合功能测试。

　　很多同学在功能测试时肯定会经常遇到“不可重现”的bug，或者说crash类的bug。

　　那么开启代码，配合功能测试，一但遇到这类问题，加载客户端的进程代码调试之，堆栈，输出，中断代码行，全部显现。神马不可重现，全是浮云！录bug时很痛快，告诉开发第几行。。。。一句话：他不会说他看不懂。首先避免了你给他解释bug的时间；其次你不会费劲周折的给他试图重现，他也试图重现，或者你重现了，他机器上未重现；最后这种定位最精准一步到位，节省大把的时间。

　　（个人是不相信有不可重现bug：个人认为不可重现原因：1.隐藏太深，你测试时无法第2次触发他，但是用户可能会，2.开发有代码修改，已经间接的把这个问题merge掉了）

　　我认为开着代码调试也应该属于静态测试范畴，我们只是在看。。看堆栈，看错误的代码行和错误的参数值。

　　3.静态测试帮助增减用例。

　　静态测试理解了内部逻辑与架构，那么我们可以很容易查找到自己用例的冗余点和不足之处，特别是能发现隐藏的风险点。这个可是我们评审后最好的修复用例时机，不容错过。

　　静态测试时一点点小的改善和用心，都会对我们测试效率有着本质上的提升，做静态测试不能浮躁，需要与功能测试配合。绝对会有收货。