软件静态测试方法

静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
代码检查 代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。
　　 在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现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.复审领导
复审领导的工作是保证复审活动获得成功- 或者是负责汇报复审活动未能获得成功的原因。
未能成功原因比如：成员在材料充分的情况下依然没有做好准备、预定的会议室发现泥水匠正在拆墙。
复审活动的成功与待复审产品的质量之间没有必然联系，复审领导不可能也不必承担待复审产品的质量的责任，而只需对复审活动本身的质量负责。但一旦宣布检验出合格产品，他就获得了一份对该产品因该承担的责任。
复审领导应该有一些技术素质，至少应该精通开发的过程、使用的开发工具、现代的软件方法，特别应该了解复审活动在整个开发过程中的位置。
对于复审领导的个人品质很难一概而论，一句话：结果比方式更重要。毕竟领导风格千千种，很难说那种是对是错。
技术领导最糟糕的性格特点就是不能主动置身于他碰巧很感兴趣的技术讨论之外。一旦复审领导都被卷入技术漩涡中，谁还能拯救这次复审呢？
告诉那些以自己缺乏管理经验为由拒绝出任复审领导的“专业程序员”，这次复审正是他提高技能的绝好的锻炼机会。实际上，多人都可以胜任这个职位，确实是个不错的锻炼机会。 
任何可能因为职位的原因引起利益冲突的人都不应该出现在复审现场，所以，领导对自己的团队进行复审应该尽力避免。
复审活动前，复审领导应该准备好充分的文档，并在会议当天应用CheckList检查是否符合开会条件。
会议中要确保准备充分的参加者能够有时间阐述自己意见，否则以后的会议之前没人会认真准备。
如果复审偏离主题，复审领导首先要做的是，留心观察这次跑题是否是某些成员掩盖其缺乏准备的一个诡计。如果不是，提醒大家注意本次会议的目的。如果还不行，可以直接介入，公开终止对技术细节的讨论，还要告诉记录员把它记下来。如果再有人没有停下来，提醒他本次会议的目的是提出问题，而不是解决问题。他的意见会被纪录，复审会议后解决问题时再被讨论。
如果真的有人蓄意妨碍，复审领导可以宣布这次会议不再有建设性而终止会议。并且记录你认为终止会议的真正原因上报，还要同事做好为自己做辩护的准备。
对于没有勇气直接发言的腼腆成员可以直接提问题给他，没有人会害羞到不能回答直接提问的地步。
据说“专家就是在自己犯了大错误的过程中还在挑剔别人小错误的人”。复审领导应该保证复审组中没有这样的专家。
如果再次复审的原因的成员的准备不够充分，那么下次进行复审还应该是原班人马。
关于如何鼓励复审组成员有勇气职责别人的工作，可以要求每人分别给出一个正面评价和一个负面评价。把批评仪式化，这样有利于得到真实正确的建议。
如何对待迟到早退，这是每个领导一直会遇到的问题，可以参考温伯格的意见，也可以自按照从前的经验来。
如果找麻烦的人想重新设计这个产品以“是他变得更好”，可以打断她，然后要求他提出一些“是产品变的更糟”的办法。这会增加一些幽默的气氛，同时让他们看到该产品并非遭到一无是处，进而让他们知道他们的意见不怎么样。
复审整个形式化步骤：P81。
查明没有做好准备的复审者：P82。
复审检查表：P86。
温伯格是如何控制开会的公共议程与每个人自己的私人议程：P90。其中包含一个小的实验，验证会议每个人的真实私人议程。很有趣。
要求每个人说出材料中是否有遗漏是一个检查这个人对材料是否准备好了的好办法。
只要牢记一条简单的规则，复审领导就能轻松些的结束会议，那就是：作为复审领导，我有责任保证复审的高效率。如果我认为这个目标没法实现，我有责任终止这次复审。

9. 记录员
记录员的首要职责是为确保复审报告的准确性提供信息。
最好使用活动挂图，投影等方式使得记录员的即时记录信息能被大家同时看到。或者用高级可打印白板。
最好不要使用录像机在正式的场合，会导致某些人不自然，而且复审会议也不需要那么大的信息量。
不要让复审领导同时担当记录员，首先它会在进行记录的时候失去对会议的控制，其次，记录原有很大权利，很容易忘记或者多记一些内容，因此要使用分权这一屡试不爽的办法。
不要怀疑，任何人都可以作为记录员，因此可以自己进行调度。  还可以在会议开始的时候依次问询大家对这次复审的意见，挑选在某的session没什么话好说的人作为这个session的记录员。
确信会议中的任何人都可以很方便的看到记录，尤其是复审领导。
当自己在做记录员并且有话要说的时候，把笔或者电脑交给身边的人。
每个被安排为记录员的成员需要去检查P106页的CheckList。
10. 对复审员有所帮助的规则和惯例 
准备好你的工作。不要掩饰。
要乐意合作。时刻注意自己评审的是产品而不是同事，任何人都可能犯错。
注意你的语言。不要以“为什么”开头，最好用“我不明白…”。
正面和负面的评价。实在没有正面的评价可以“我喜欢你用来评审的水笔的颜色。”
提出问题，但不要解决问题。可以在吃午饭的时候讨论解决方案。
不要讨论风格。 
要遵循标准- 否则就扔掉它。
只允许有技术能力的人参加复审。不是排斥技术新人，是为避免政治目的的人。
所有的问题都要公开记录。
坚持讨论技术问题。
不要忘了教育。
不要评价生产者。 
要尽早分发复审报告。
让生产者决定他们的产品接受复审的时间。否则就是浪费时间。
11. 对管理部门有帮助的规则
要表现出对复审过程的信任。
要为复审过程安排时间。
要做好准备让真正合适的人去参加复审。
鼓励复审活动的参与者做好准备工作。
要帮忙解决会场问题。
不要小事聪明大事糊涂。
要奖励那些发现劣质产品的优质复审
不管产品怎样，一定要惩罚所有的劣质复审
要惩罚糟糕的复审行为。
推翻复审决定只会让你自己担风险。
12. 用户与复审 
缺乏技术能力，不能为复审做出贡献的人不该出现在复审现场。
生产者通常会试图让你为自己不能理解他们那些绝妙的产品而感到自卑，这是需要站稳立场，让他们在问题列表上写下这样的语句：“用户代表不能理解。”

原文转自：http://www.ltesting.net