《软件测试的艺术》读书笔记（二）
由于所在团队很小，项目团队一般由前端/移动端、服务器、底层逻辑开发人员组成，每个角色都只有一个人，测试也偏向于功能测试，直到最近我才了解到代码走查的概念。
或许在短时间内我负责的项目仍然缺失这个测试环节，甚至为了追求效率（实际上是大家都没有在规范的大团队呆过的缘故，压根也不知道规范是什么），连代码评审都没有。
项目开发的工作流程都是通过长期合作磨合出来的结果，更多的时候是凭借经验和直觉推进项目进度。
但个人认为还是有必要去了解完整的测试流程，或许就可以受到启发尝试如何在现有的基础上对流程做出优化，提升软件的质量和开发效率。
第 3 章 代码检查、走查与评审
多年以来，软件界的大多数人都持有一个想法，即编写程序仅仅是为了提供给机器执行，并不是供人们阅读的，软件测试的惟一方法就是在计算机上执行它。
直到今天，恐怕大多数的程序员仍然抱有这个观念：只要程序能够正常运行，代码写的是否符合规范一点也不重要。
然而，除非这个程序是个一次性产品，否则必然需要后期维护。
而在人员流动性如此大的今天，没有一个程序员能够保证自己能够陪伴一个项目到终结，这就必然会出现他人接手项目进行维护的问题。
可见，代码检查不仅是发现错误的手段，同时存在着更加长远的意义。
我见过最夸张的代码是一个简单的脚本竟然写了几十万行代码，开发者还沾沾自喜引以为豪，觉得自己能够写出这么多代码是一件了不得的事情。
错误发现得越早，改正错误的成本越低，正确改正错误的可能性也越大。
代码检查的意义之一，就是在交付验收前，通过查看代码发现疏漏和错误。
根据经验，一个错误越晚被发现，要想修正它，除了要考虑相关功能会不会受到影响，对于已经上线有实际用户的产品来说，更需要考虑的是修正错误会对现有用户产生什么影响。
有一款上线 8 年的产品，用户累计数量已达到千万级，月活跃用户数也有几十万，而在设计初期存在着设计缺陷。
这种情况还需要进行细分，比如新的解决方案明显优于现有设计，不会对老用户造成任何负面影响。
另外一种情况就是，虽然新的方案比现有设计更合理，但老用户已经习惯了“错误的设计”，并在此基础上做出了调整以达到预期的使用体验（在开发平台和工具上更容易遇到这种问题）。
一旦做出改动，老用户升级到新版本反而发现原本运行正常的程序出现了问题。
新的方案就要考虑如何兼容缺陷设计，当然这属于产品设计的内容，在此不做赘述。
3.1 检查与走查(Inspections And Walkthroughs)
代码走查：在代码走查中，一组开发人员（三至四人为最佳）对代码进行审核。参加者当中只有一人是程序编写者。
疑问：这里说的开发人员，必须是和编写者使用同样编程语言的程序员吗？例如前端的代码，走查小组中是否必须都是前端开发？
对于小团队来说，可能整个项目也就只有一两个前端。
代码走查的优点
1. 精准定位。因为是直接查看代码，哪里有问题一目了然，不像平时测试只能通过复现表象问题，找到规律才能定位问题。
2. 错误数量。发现代码的逻辑错误，就很容易联想到有类似代码的功能也存在相同的问题，而功能测试只能看到表面的问题，很难发现内在联系。
代码走查的重要性
在典型的程序中，这些方法通常会有效地查找出 30％～70％的逻辑设计和编码错误。
这里说的错误数量，不是说只要进行了代码走查，测试就能少发现这么多错误。
而是能够发现代码中存在的错误数量的占比。
修改一个现存的程序比编写一个新程序更容易产生错误(以每写一行代码的错误数量计)
还是以我自己的经验为例，有时候面对一个很久没更新的项目，很难想起来不同模块之间的联系，有时候改了一个变量名字，就会导致其他地方出现问题。
有些程序员的不良编程习惯，比如不写注释、代码冗余，使得代码可读性非常差。
每个人的编写习惯和风格大相径庭，修改别人写的代码更是难上加难。
3.2 代码检查(Code Inspections)
代码检查是以组为单位阅读代码，它是一系列规程和错误检查技术的集合。
在我看来，代码检查和走查的区别在于，前者更偏重于自查。
通过代码检查，程序编写者在逐句解释代码的过程中发现存在的问题，就像产品经理编写需求文档和使用说明来强迫自己对软件进行解释，以发现一些忽视的错误和冲突。
要使检查过程有成效，必须树立正确的态度。如果程序员将代码检查视为对其人格的攻击、采取了防范的态度，那么检查过程就不会有效果。代码检查的目标是发现程序中的错误，从而改进软件的质量。应对代码检查的结果进行保密，仪限于参与者范围内部。
