代码检查 代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。
在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷；代码检查看到的是问题本身而非征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。
静态结构分析 静态结构分析主要是以图形的方式表现程序的内部结构，例如函数调用关系图、函数内部控制流图。其中，函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系；控制流图显示一个函数的逻辑结构，它由许多节点组成，一个节点代表一条语句或数条语句，连接结点的叫边，边表示节点间的控制流向。
检查项：
* 代码风格和规则审核
* 程序设计和结构的审核
* 业务逻辑的审核
走查、审查与技术复审手册
静态测试的要点：
3.挑选合适的复审员
复审活动人数控制在3-7个人，每次复审活动不要超过2小时，否则应该功能分解或者形式分解。准备充分的复审一小时以内完成。
疑问：每个公司的复审员是由谁来挑选的？
4.管理部门的参与
任何对使复审由只关注技术转变为与人事产生关系的情况都应该避免。
技术经理分配复审给下面有潜力的员工是经理自己成长的必然之路。
为复审活动分配时间和资源
特殊情况关于时间、场地选取的一些建议。
IBM一个关于电话会议进行复审的一个案例。
6.复审活动启动过程中的注意事项
结队复审方法，对比结队编程。
10-12点是进行复审的完美时间，复审完成大家共进午餐可以帮助解决问题，想起新问题。
选择那些不会引起争论不休的内容作为每次初期复审对象。
对走查、审查和技术复审的活动指南进行复审，效果会很好。
复审规则：复审过程本身的目的是提出问题，而不是解决这些问题。
找一只愿意倾听的耳朵，即使这样，复审也会很有效果。（make sense on banian）
复审比培训来得更有效，这是推广新技术的好方法。
双项目同时启动，并且互相担当复审主导的形式非常有效，还会有良性竞争出现。要求项目规模比较小。
对复审领导进行工作中复审培训一个月左右，10-16个领导就可以担当一年内培养公司200名员工的任务。
正式复审与非正式复审的差距是由领导控制的，其中的灵活度，多少push，多少愉快的气氛的培养正是做领导的艺术，也是他们拿那么多Money的原因。
认真去读P58,没再见过比这更好的比喻与阐述。
7.技术复审与项目管理
标准的项目管理示意图：图7-2
很多公司的模型是这样：图7-3，生产单元既是被告，又是法官。这显然不make sense.
应该改成这样的模型：图7-4。
确定两次复审之间的时间间隔的根据使你在完全失去对工作状况的了解的情况下能够坚持的最长时间。大多数这个时间是2-4个星期。
不管做什么都会犯错误，因此把错误犯在最安全的地方是一个不错的策略，这也是复审活动“宁缺勿滥”的理由。
以随即选定的方法对审核的工作进行抽样，使会有风险的。尽量不要这么做。
8.复审领导
复审领导的工作是保证复审活动获得成功- 或者是负责汇报复审活动未能获得成功的原因。
未能成功原因比如：成员在材料充分的情况下依然没有做好准备、预定的会议室发现泥水匠正在拆墙。
复审活动的成功与待复审产品的质量之间没有必然联系，复审领导不可能也不必承担待复审产品的质量的责任，而只需对复审活动本身的质量负责。但一旦宣布检验出合格产品，他就获得了一份对该产品因该承担的责任。
复审领导应该有一些技术素质，至少应该精通开发的过程、使用的开发工具、现代的软件方法，特别应该了解复审活动在整个开发过程中的位置。
对于复审领导的个人品质很难一概而论，一句话：结果比方式更重要。毕竟领导风格千千种，很难说那种是对是错。
技术领导最糟糕的性格特点就是不能主动置身于他碰巧很感兴趣的技术讨论之外。一旦复审领
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
