静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。

　　静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

　　静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。

　　在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现 30%～70%的逻辑设计和编码缺陷；代码检查看到的是问题本身而非征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。静态测试具有的发现缺陷早、降低返工成本、覆盖重点和发现缺陷的概率高的优点以及耗时长、不能测试依赖和技术能力要求高的缺点。

　　“静态测试”在学术文献中的解释：

　　1、静态测试是指无须执行被测代码，而是借助专用的软件测试工具评审软件文档或程序，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率；

　　2、静态测试是指测试不运行的部分：只是检查和审阅,如规范测试、软件模型测试、文档测试等。动态测试是通常意义上的测试，也就是运行和使用软件；3、通过评审文档、阅读代码等方式测试软件称为静态测试，通过运行程序测试软件称为动态测试。在动态测试中，通常使用白盒测试和黑盒测试从不同的角度设计测试用例，查找软件代码中的错误；

　　4、静态测试是指不用执行程序的测试，它主要采取方案—代码走查、技术评审、代码审查的方法对软件产品进行测试。(t)称为：时刻的瞬时利息率(是无风险利率)。

　　结构分析：

　　静态结构分析主要是以图形的方式表现程序的内部结构，例如函数调用关系图、函数内部控制流图。其中，函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系；控制流图显示一个函数的逻辑结构，它由许多节点组成，一个节点代表一条语句或数条语句，连接结点的叫边，边表示节点间的控制流向。

　　检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册。

　　一个项目或者一个企业，如果要下决心实施软件质量，实施软件工程，第一步要做的就是软件编码规范。编码规范是程序编写过程中必须遵循的规则，一般会详细规定代码的语法规则、语法格式等。企业实施怎样的编码规范，取决于很多个因素：l 编程采用的语言，例如 C、C++、JAVA、ADA 等。项目的规范化程度。目前现成的 C/C++编码规范有很多，例如前几年网络上比较流行的《华为公司编程规范》、《摩托罗拉 C+编程规范》等。但项目不能完全照搬，应该根据自己所处的阶段，定制属于自己的规范，否则的话，会让程序员无所适从，严重打击程序员的积极性。不同的行业对软件的可靠性有不同的要求，例如航空/航天的嵌入式软件对代码的要求很高，而传统的 windows 平台应用软件则相对要宽松。在嵌入式软件中，尤其是汽车行业，国际上目前流行的 C 语言编程规则为 MISRA-C:2004，其中包括包括 141 条规则，其中 121 条是强制（Required）遵守的，20 条是建议（Advisory）遵守的。

　　有了统一的规范后，测试工程师或者程序员自身，就可以实施编码规范检查了。要真正把编码规范贯彻下去，单单靠测试员程序员的热情，很难坚持下去，所以笔者建议借助于一些专业的工具来实施。在 C/C++语言的编程规则检查方面，比较专业的工具有 Coverity，C++Test、LINT 工具、KlocWork（Insight）/QAC/QAC++等，这些工具通常可以和比较流行的开发工具集成在一起，程序员在编码过程中，在编译代码的同时即同时完成了编程规则的检查。

　　有了严格的编程规范，只能算是万里长征迈出了第一步。要提高软件的可重用性，以及软件的可维护性，还需要进一步的努力，即静态质量度量。静态质量度量所依据的标准是 ISO9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性（Maintainability）、可移植性(Portability)。以 ISO9126 质量模型为基础，可以构造质量度量模型。具体到静态测试，这里主要关注的是可维护性。要衡量软件的可维护性，可以从四个方面去度量，即可分析性（Analyzability）、可改变性（Changeability）、稳定性（Stability）以及可测试性（Testability）。具体到软件的可测试性怎么去衡量。又可以从三个度量元去考虑，例如圈复杂度、输入/输出的个数等。圈复杂度越大，说明代码中的路径越多；路径越多，意味着要去做测试，需要写更多的测试用例。输入/输出的个数同样的道理。在具体的实践中，专门的质量度量工具是必要的。没有工具的支持，这一步很难只靠人工完成。在这个阶段，比较专业的工具有 Testbed、Logiscope 等。

　　在传统意义上认为，错误检测应该是动态的系统测试的范围。但在 bug 的成本上分析，有以下公认的结论。

　　bug 发现的越晚，修正的成本就越高，测试阶段修正 bug 的成本是编码阶段的约 4 倍的关系。为了减少成本，bug 被发现的越早越好。在编程阶段，静态的分析代码就能找到代码的 bug，是很多人的梦想。这个梦想在 21 世纪初变成了现实。以 PolySpace、Klocwork、Coverity 为代表的静态分析软件，实现了只要静态分析代码，就可以发现代码的 bug，例如数组越界、除数为 0、缓冲区溢出等，虽然还不是特别完美。微软在其最新的开发工具 VisualStudio2005 的 teamsystemediton 中集成了安全工具 PREFix。PREFix 原来就是著名的静态分析工具，后被微软收购过来。从微软的倾向看发展走势，类似的静态工具未来会成为市场的主流。PolySpace 详细的信息可以参考我的另外一篇文章《嵌入式软件动态运行时错误的检测》。

　　挑选合适的复审员

　　复审活动人数控制在 3-7 个人，每次复审活动不要超过 2 小时，否则应该功能分解或者形式分解。准备充分的复审一小时以内完成。

　　管理部门的参与

　　任何对使复审由只关注技术转变为与人事产生关系的情况都应该避免。技术经理分配复审给下面有潜力的员工是经理自己成长的必然之路。为复审活动分配时间和资源，特殊情况关于时间、场地选取的一些建议。IBM 一个关于电话会议进行复审的一个案例。

　　注意事项

　　结队复审方法，对比结队编程。10-12 点是进行复审的完美时间，复审完成大家共进午餐可以帮助解决问题，想起新问题。选择那些不会引起争论不休的内容作为每次初期复审对象。对走查、审查和技术复审的活动指南进行复审，效果会很好。复审规则：复审过程本身的目的是提出问题，而不是解决这些问题。找一只愿意倾听的耳朵，即使这样，复审也会很有效果。（makesenseonbanian）复审比培训来得更有效，这是推广新技术的好方法。双项目同时启动，并且互相担当复审主导的形式非常有效，还会有良性竞争出现。要求项目规模比较小。对复审领导进行工作中复审培训一个月左右，10-16 个领导就可以担当一年内培养公司 200 名员工的任务。正式复审与非正式复审的差距是由领导控制的，其中的灵活度，多少 push，多少愉快的气氛的培养正是做领导的艺术，也是他们拿那么多 Money 的原因。

　　技术复审与项目管理

　　确定两次复审之间的时间间隔的根据使你在完全失去对工作状况的了解的情况下能够坚持的最长时间。大多数这个时间是 2-4 个星期。不管做什么都会犯错误，因此把错误犯在最安全的地方是一个不错的策略，这也是复审活动“宁缺勿滥”的理由。以随即选定的方法对审核的工作进行抽样，使会有风险的。尽量不要这么做。

　　复审领导

　　复审领导的工作是保证复审活动获得成功-或者是负责汇报复审活动未能获得成功的原因。未能成功原因比如：成员在材料充分的情况下依然没有做好准备、预定的会议室发现泥水匠正在拆墙。复审活动的成功与待复审产品的质量之间没有必然联系，复审领导不可能也不必承担待复审产品的质量的责任，而只需对复审活动本身的质量负责。但一旦宣布检验出合格产品，他就获得了一份对该产品因该承担的责任。复审领导应该有一些技术素质，至少应该精通开发的过程、使用的开发工具、现代的软件方法，特别应该了解复审活动在整个开发过程中的位置。对于复审领导的个人品质很难一概而论，一句话：结果比方式更重要。毕竟领导风格千千种，很难说那种是对是错。技术领导最糟糕的性格特点就是不能主动置身于他碰巧很感兴趣的技术讨论之外。告诉那些以自己缺乏管理经验为由拒绝出任复审领导的“专业程序员”，这次复审正是他提高技能的绝好的锻炼机会。实际上，多人都可以胜任这个职位，确实是个不错的锻炼机会。

　　任何可能因为职位的原因引起利益冲突的人都不应该出现在复审现场，所以，领导对自己的团队进行复审应该尽力避免。复审活动前，复审领导应该准备好充分的文档，并在会议当天应用 CheckList 检查是否符合开会条件。会议中要确保准备充分的参加者能够有时间阐述自己意见，否则以后的会议之前没人会认真准备。如果复审偏离主题，复审领导首先要做的是，留心观察这次跑题是否是某些成员掩盖其缺乏准备的一个诡计。如果不是，提醒大家注意本次会议的目的。如果还不行，可以直接介入，公开终止对技术细节的讨论，还要告诉记录员把它记下来。如果再有人没有停下来，提醒他本次会议的目的是提出问题，而不是解决问题。他的意见会被纪录，复审会议后解决问题时再被讨论。如果真的有人蓄意妨碍，复审领导可以宣布这次会议不再有建设性而终止会议。并且记录你认为终止会议的真正原因上报，还要同事做好为自己做辩护的准备。对于没有勇气直接发言的腼腆成员可以直接提问题给他，没有人会害羞到不能回答直接提问的地步。据说“专家就是在自己犯了大错误的过程中还在挑剔别人小错误的人”。复审领导应该保证复审组中没有这样的专家。如果再次复审的原因的成员的准备不够充分，那么下次进行复审还应该是原班人马。 关于如何鼓励复审组成员有勇气职责别人的工作，可以要求每人分别给出一个正面评价和一个负面评价。把批评仪式化，这样有利于得到真实正确的建议。如何对待迟到早退，这是每个领导一直会遇到的问题，可以参考温伯格的意见，也可以自按照从前的经验来。如果找麻烦的人想重新设计这个产品以“是他变得更好”，可以打断她，然后要求他提出一些“是产品变的更糟”的办法。这会增加一些幽默的气氛，同时让他们看到该产品并非遭到一无是处，进而让他们知道他们的意见不怎么样。温伯格是如何控制开会的公共议程与每个人自己的私人议程：其中包含一个小的实验，验证会议每个人的真实私人议程。要求每个人说出材料中是否有遗漏是一个检查这个人对材料是否准备好了的好办法。只要牢记一条简单的规则，复审领导就能轻松些的结束会议，那就是：作为复审领导，我有责任保证复审的高效率。如果我认为这个目标没法实现，我有责任终止这次复审。

　　记录员

　　记录员的首要职责是为确保复审报告的准确性提供信息。最好使用活动挂图，投影等方式使得记录员的即时记录信息能被大家同时看到。或者用高级可打印白板。最好不要使用录像机在正式的场合，会导致某些人不自然，而且复审会议也不需要那么大的信息量。不要让复审领导同时担当记录员，首先它会在进行记录的时候失去对会议的控制，其次，记录原有很大权利，很容易忘记或者多记一些内容，因此要使用分权这一屡试不爽的办法。不要怀疑，任何人都可以作为记录员，因此可以自己进行调度。还可以在会议开始的时候依次问询大家对这次复审的意见，挑选在某的 session 没什么话好说的人作为这个 session 的记录员。确信会议中的任何人都可以很方便的看到记录，尤其是复审领导。当自己在做记录员并且有话要说的时候，把笔或者电脑交给身边的人。每个被安排为记录员的成员需要去检查 CheckList。

　　规则和惯例

　　准备好你的工作。不要掩饰。要乐意合作。时刻注意自己评审的是产品而不是同事，任何人都可能犯错。注意你的语言。不要以“为什么”开头，最好用“我不明白…”。正面和负面的评价。实在没有正面的评价可以“我喜欢你用来评审的水笔的颜色。”提出问题，但不要解决问题。可以在吃午饭的时候讨论解决方案。不要讨论风格。要遵循标准否则就扔掉它。只允许有技术能力的人参加复审。不是排斥技术新人，是为避免政治目的的人。所有的问题都要公开记录。坚持讨论技术问题。不要忘了教育。不要评价生产者。要尽早分发复审报告。让生产者决定他们的产品接受复审的时间。否则就是浪费时间。

　　规则

　　要表现出对复审过程的信任。要为复审过程安排时间。要做好准备让真正合适的人去参加复审。鼓励复审活动的参与者做好准备工作。要帮忙解决会场问题。不要小事聪明大事糊涂。要奖励那些发现劣质产品的优质复审不管产品怎样，一定要惩罚所有的劣质复审要惩罚糟糕的复审行为。推翻复审决定只会让你自己担风险。

　　用户与复审

　　缺乏技术能力，不能为复审做出贡献的人不该出现在复审现场。生产者通常会试图让你为自己不能理解他们那些绝妙的产品而感到自卑，这是需要站稳立场，让他们在问题列表上写下这样的语句：“用户代表不能理解。”