3.3 用于代码检查的错误列表
常见错误对照表，容易出现的问题：过于注重代风格码而不是代码错误、过于模糊不够具体。
3.3.1 数据引用错误
3.3.2 数据声明错误
3.3.3 运算错误
3.3.4 比较错误
3.3.5 控制流程错误
3.3.6 接口错误
3.3.7 输入/输出错误
3.3.8 其他检查
就像产品经理会有一个清单，在需求和原型完成后对照查看是否有常见的遗漏和错误，代码检查的这些常见错误也涵盖了方方面面。
虽然其中有些专有名词看不太明白，但看得明白的部分确实是一些不太容易发现又确实遇到过的 bug，原来这些问题在代码检查阶段就应该发现。
在实际工作中，时常因为例如接口返回顺序到底应该由产品来规定，还是程序员应该自己决定而无法明确区分权责。
目前的情况就是，对于一些和时间相关的顺序，经过多次纠错，程序员同事已经知道默认使用倒序排序，已经算是从“反常问题”变成了“常规问题”。
但对于一些不那么明显的列表，还是会存在使用莫名其妙的排序方法的问题，例对随机 ID 进行首字母排序，导致从表象来看完全摸不着头脑。
3.4 代码走查(Walkthroughs)
代码走查小组由三至五人组成，其中一人负责协调，一人负责记录所有查出的错误除，一人负责测试。
小组成员组成，除了负责编写项目的程序员外，还可以从以下人员中挑选两到三人：
(1)一位极富经验的程序员
(2)一位程序设计语言专家
(3)一位程序员新手（可以给出新颖，不带偏见的观点）
(4)最终将维护程序的人员(5)一位来自其他不同项目的人员
(6)一位来自该软件编程小组的程序员
不同于仅阅读程序或使用错误检查列表，代码走查的参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。
与代码检查不同的是，走查有了测试人员的参与，加入了对程序的使用。
在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。
走查所有的测试用例并不是完整的，而是只包含一些主要的、典型的部分。
代码走查的目的并不是通过走查找到所有的错误（这是软件测试的目的），而是提供了对程序员的逻辑思路和设计思想质疑的机会。
就像产品需求评审一样，是人们坐在一起对程序的逻辑和需求进行评审的机会。
目的都是尽早发现逻辑错误，以免浪费开发成本，造成更大的损失。
3.5 桌面检查(Desk Checking)
桌面检查可视为由单人进行的代码检查或代码走查：由一个人阅读程序，对照错误列表检查程序，对程序推演测试数据。桌面检查胜过没有检查，但其效果远远逊色于代码检查和代码走查。
3.6 同行评分(Peer Ratings)
• 程序是否易于理解？
• 高层次的设计是否可见且合理？
• 低层次的设计是否可见且合理？
• 修改此程序对评审者而言是否容易？
• 评审者是否会以编写出该程序而骄傲？该过程适用于企业开发和课堂教学环境
通过第三方评价帮助程序员发现自身编程能力的不足。
3.7 小结
标签：艺术,错误,读书笔记,代码,检查,程序员,3.3,走查,软件测试 From： https://www.cnblogs.com/lisaisacat/p/16707586.html大多数的软件项目都应使用到以下的人工测试方法：
• 利用错误列表进行代码检查。
• 小组代码走查。
• 桌面检查。
• 同行评审。