3、静态测试有助于发挥测试人员的潜力

　　传统的测试是按照需求设计文档来验证程序的问题，没料到这个”唯一的”“测试依据”其实很多时候都靠不住，问题丛生，暗含杀机。

　　分析：当测试人员养成完全依赖UC（或者PRD）的习惯后，变会缺乏主动思考、创新思考的能力。下意识的就把UC和PRD当成测试的立足点，以此来验证软件产品的质量，这样将导致测试人员发现的问题质量低，问题深度不够，难以发现用户体验相关的缺陷，并且容易使测试人员当因某个测试问题与开发意见不一时，争辩时腰板挺不直，使问题得过且过，丧失测试人员的地位。

　　运用静态测试后：

　　● 激发了测试人员的潜力，层层深入业务核心，从被动接受，转变为主动思考，敢于质疑设计，敢于异议架构！

　　● 对测试人员思考和分析能力的锻炼；

　　● 姿态的转变——“客户的代言人”

　　4、静态测试有助于测试准备阶段对测试人员的绩效评估

　　分析：传统测试在测试准备阶段，测试经理除了通过测试用例对测试人员的工作情况进行评估外，很难有其他方法对其绩效进行了解。而测试设计和测试用例的产出相对是滞后的，这样就给测试经理提前预警带来了难度，一旦到了测试准备阶段后期才发现问题，就让测试准备工作陷入被动的境地。

　　运用静态测试以后

　　● 每天可以对每位测试人员按功能模块提交的静态测试问题数进行统计；

　　● 每周都可以为每位测试人员应提交的静态测试问题数目制定目标；

　　● 每周可以对每位测试人员的静态测试问题质量进行评估和总结，营造积极进取的测试团队氛围

　　【静态测试的问题分类及切入点】

　　● 文档规范问题

　　“文档规范”类的问题属于所有问题分类中比较浅显，但同时也是问题数量较为庞大的一类。诸如软需中字段缺失，字段描述错误，错别字等等。

　　查找方法：多采用横向对比、纵向对比、多元对比的方法，细心、耐心的查找即可做好。当项目大或者工期紧的情况，可以不必花太多精力在此类问题上。

　　● 设计错误问题——“设计出来了，但是设计错了”

　　此类问题需要对程序处理流程和业务处理逻辑非常清楚才能挖掘出来，具有较高的难度，测试经理和测试骨干应多关注和发现此类的问题。

　　查找方法：可在编写流程图、mm图和状态迁移图的时候，理清楚程序处理流程和业务处理逻辑，再结合PRD、UC和开发设计文档查找设计得不对的静态测试问题。

　　● 设计不完善问题——“设计出来了，但是设计得不好”

　　“设计不完善”类的问题在大多数文档中是频频出现的，比如前后逻辑矛盾，表述歧义，表达不清晰，逻辑混乱，存在误解等等。此类问题应该是项目组成员重点关注的问题，因为这直接影响了了解需求的深度和广度，直接影响了测试用例的编写实效，以及将来测试执行时的测试粒度和深度。

　　查找方法：要发现此类问题，同样可以借助编写流程图和状态迁移图，同时多思考，多分析，多询问，多考察，借助所有提交静态测试的文档，真正做到“咀嚼需求”，这样能提示测试质量和测试效果，是事半功倍。

　　● 设计遗漏问题

　　此类问题在各项目静态测试中所占比重是较小的，但若是有，则是将是高质量的问题。此类问题需要站得高，看得远，没有多年的相关业务背景的积淀，和对项目的充分广泛的涉猎，此类问题是很难发现的。

　　查找方法：在充分了解业务相关背景的基础上，凭借业务设计经验，充分理解了文档和设计思想后，才能发现其中没有考虑到的问题。

　　● 需求问题

　　此类问题是以发现目前设计与原始需求相矛盾、相抵触或者不一致的问题为目的，弥补因某些原因错写、漏写的需求要点，保证设计的完整性、完善性和正确性。

　　查找方法：综合前面所有的查找方法。