进化的测试

Examining the Code – 检查代码。这章主要讲的是(Static White-Box Testing)静态白盒测试：对设计和代码的检查。

(Static Testing)静态测试，就是对那些不运行的东西进行测试–检查和评审。
(White-Box Testing)白盒测试，指可以看到内部结构并且可以对之进行评审。
(Static White-Box Testing)静态白盒测试，就是在不运行软件的情况下对其设计，架构或者代码进行检查。有时候也叫(structural analysis)结构分析。

 (Formal Reviews)正式审查。正式审查是一个严格的正规的活动。如果评审是一个随机的过程，那么所有事情都成了随机，开会时间是随机，发现的bug是随机，效果是随机，回家的时间也是随机的。对于正式审查，有以下4个根本要素

1.(Identify Problems)找出问题。核心我觉得就是一句话，对事不对人。发现了代码或者文档的问题，就只能就这些问题进行批评，而不是去找到谁干的，然后对他劈头盖脸的训斥一顿。

2.(Follow Rules)一切按照规矩走~。无规矩何以成方圆，在审查进行前需要制定一系列规矩并且遵循这些规矩来进行。包括审查数量的多少啊~时间~内容等等。要不然很容易成了吵架大会。

3.(Prepare)事前做好准备。经常看到有人写“那些有充分准备的人才能抓住机会”！因为很多时候，发现问题是在我们准备这个Review的时候，也就是看文档或者代码的时候。不要期望一个脑子一片空白的人进入会议室能对大家带来什么帮助。

4.(Write a Report)。做会议记录。做会议记录是很重要的，记下来都发现了什么，问题集中在哪些地方发生。

另外，除了能发现一些系统的问题，正式审查还有以下“副作用”：
1.更好的沟通，大家坐到一起讨论，新人能够从经验丰富的高手那里学到不少本领~测试员能了解软件的内部结构等等……
2.更好的质量：书上说如果一个人知道自己的代码要被被人看，那么他肯定会更加用心去做。也是，如果在会上发现低级错误那多么丢人啊
3.团队和谐，评审进行的好能促进沟通，彼此尊重信任
4.解决方案，有时候换个角度看问题可能会发现新的解决问题的方法哦

A.(Peer Reviews) – 同行评审。也叫(Buddy Reviews)。
同行评审是正式审查里面最随便的一种。不过需要注意的是进行同行评审要时刻注意以上正规评审的4大要素。一个都不能少啊！

B.(Walkthroughs) – 走查。
走查比同行评审更加正规。在走查的过程中通常有代码的作者来给与会的人讲解自己那份代码是干啥的，为啥那样写。在走查的过程中最好是一个有个高级工程师在场。

C.(Inspections) – 审核。
审核是最正规的的审查形式。对与会者的要求比较高，而且最好是有经验的，培训过的。审核与前两者的不同在于–讲解或者阅读代码的人并不是那份代码的原作者。

编码标准(Standards)和规范(Guidelines)

标准(Standards)是已经确定的，固定的，必须遵循的规则。规范(Guidelines)是建议的最佳实践，推荐的，首选的方式。标准是必须要遵守的，而规范可以有一定的灵活性。我觉得跟法律和道德的关系有点相似哦
很奇怪，既然软件都能run起来了那为啥还说有bug！
1.Reliability（可靠性）
2.Readability/Maintainability（可读性和可维护性）
3.Portability（可移植性）

最后还有好几页讲的是Code Review Checklist。由于List太长而且我又没什么经验，还是留着慢慢琢磨吧~我觉得这个list对于程序员来说价值也很大~：）

Related posts:

1. 《Software Testing》第十一章 – 可用性测试