分类： 项目管理
2009-09-22 08:22:34
l 代码检查和代码走读的共同点
上篇，提到人工测试技术的四种方法。其中，代码检查和代码走查稍略胜一筹。于是，作者在本章着重讲了这两个方法。其实，这两种方法很类似，那就先看看这两种方法的优之共通点吧！具体可分为一下几个点：
⊙方法：组成一个小组来阅读或直观检查特定的程序；并在“头脑风暴会”上要形成统一的目标：找出错误，但不必找出改正错误的方法。换句话说，是测试，而不是调试。该组开发人员（三至四人为最佳）是对代码进行审核，其中参加者当中只有一人是程序编写者；也可以说它是对过去桌面检查过程的改进。
⊙优点：一旦发现错误，就可以在代码中对其进行精确定位，这就降低了调试的成本；还通常可以发现成批的错误，这样就可以一同得到修正，这也优于机器测试，因为后者只能暴露出错误的某个表症。
⊙效果：通常是能够有效地查找出30%-70%的逻辑设计和编码错误，但不能有效地查找出高层次的设计错误。
⊙地位：是与计算机的测试互补的，缺少其中任何一种错误检查的效率都会降低。
值得提出的是：该处的错误发现率，并不是说所有错误中多达70%可能会被找出来，而是讲这些方法在测试过程结束时，可以有效地查找出多达70%的已知错误。
应始终记住的是：程序中的错误总数始终是未知的。否则就会浪费大量的精力跟人力，也会在经济效益上或多或少有一些损失的。不过，就经验而言，修改一个现存的程序比编写一个新程序更容易产生错误，这依据于以每写一行代码的错误数量来计的。
l 代码检查
⊙定义上：所谓的代码检查，其实就是以组为单位阅读代码，是一系列规程和错误检查技术的集合。该过程通常将注意力集中在发现错误上，而不是纠正错误。
⊙成员组成：一个代码检查小组通常是由四人组成，其中一人发挥着协调作用、一人是该程序的编码人员、一人是其他成员通常是程序的设计人员、一人是测试专家。
这里，值得一提的是：那个发挥着协调作用的成员。该协调人应该是个称职的程序员，但不是该程序的编码人员，不需要对程序的细节了解得很清楚。协调人的职责包括几点：为代码检查分发材料、安排进程；在代码检查中起主导作用；记录发现的所有错误；确保所有错误随后得到改正。
程序员自己读代码会发现最多的错误。同时要有以前常见问题的列表。如果出现问题较多，有必要修改后再次检查。同样的问题多次出现，要考虑设计的问题。
代码检查过程。
1.在代码检查的时间和地点上的选择上，应避免所有的外部干扰；
2.代码检查会议的理想时间应在90-120分钟之内；
3.大多数的代码检查都是按每小时大约阅读150行代码的速度进行；
4.对大型软件的检查应安排多个代码检查会议同时进行，每个代码检查会议处理一个或几个模块或子程序。
除此之外，还需要从心理学角度给予提前的心理筹备。因为，要使检查过程有成效，还必须树立正确的态度。其心理因素必须要提前分析正确，否则事倍功半。假设程序员将代码检查视为对其个人的攻击、采取了防范的态度，那么检查过程就不会有效果。而正确的做法应该是：
⊙一方面：提出的建议应针对程序本身，而不应针对程序员，即：软件中存在的错误不应被视为编写程序的人员本身的弱点，且这些错误应被看做是伴随着软件开发的艰难性所固有的；
⊙另一方面：程序员必须怀着非自我本位的态度来对待错误检查，对整个过程采取积极和建设性的态度：代码检查的目标是发现程序中的错误，从而改进程序的质量。
正因为这个原因，大多数人建议应对代码检查的结果进行保密，仅限于参与者范围内部。尤其是如果管理人员想利用代码检查的结果，那么就与检查过程的目的背道而驰了。
文尾，顺便提一下代码检查附带的几个有益的作用吧。
⊙程序员通常会得到编程风格、算法选择及编译技术等方面的反馈信息；⊙其他参与者也可以通过接触其他程序员的错误和编程风格而同样受益匪浅；
⊙代码检查还是早期发现程序中最易出错部分的方法之一，有助于在基于计算机的测试过程中将更多的注意力集中在这些地方。
错误列表
在代码检查过程中，一个重要的部分是需要对照一份编程错误列表，来分析程序是否存在常见的错误。于是，作者接下来就给出了一份错误列表，该份错误列表在很大程度上是独立于编程语言的，即：大多数的错误都可能出现在用任意语言编写的程序中的。并建议读者可以把自己使用的编程语言中特有的错误，以及代码检查发现的错误补充到这份错误列表中去。
作者给出的该列表比较详细，因此，不在这里详述，只是给出该错误列表的总的构架。该列表共分为八个部分：数据引用错误、数据声明错误、运算错误、比较错误、控制流程错误、输入/输出错误、接口错误、其他检查。
代码走查
说完代码检查，现在来谈谈代码走查。从定义上来讲，代码走查是以小组为单元进行代码阅读的，同样也是一系列规程和错误检查技术的集合。且代码走查也采用了持续一至两个小时的不间断会议的形式。代码走查的小组成员的构成而言，一般是由三至五人组成，其中一人扮演“协调人”；一人担任秘书角色，负责记录所有查处的错误；还有一人担任测试人员。不过最佳的组合应该是：
⊙一位极富经验的程序员；
⊙一位程序设计语言专家；
⊙一位程序员新手（可以给出新颖、不带偏见的观点）；
⊙最终将维护程序的人员；
⊙一位来自其他不同项目的人员；
⊙一位来自该软件编程小组的程序员。
至于测试的流程跟代码检查很类似，类似之处就不多谈，只说一下不同之处吧。稍有不同的是代码走查的任务：就是参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。且在会议期间，每个测试用例都在人们头脑中进行推演，即：把测试数据沿程序的逻辑结构走一遍，并把程序的状态（如变量的值）记录在纸张或白板上以供监视。
这里，需指出：这些书面的测试用例必须结构简单、数量较少，因为人脑执行程序的速度比计算机执行程序的速度慢上若干量级。之所以提供这些测试用例，目的不是在于其本身对测试了关键的作用，而是其提供了启动代码走查和质疑程序员逻辑思路及其设想的手段。因为，在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。
文尾，至于代码走查所需要从心理学角度给予提前的心理筹备、后续过程和附带的几个有益的作用，都与代码检查的类似，所以在这里就不提了。
桌面检查与同行评分
在本章的最后，作者附带提了一下桌面检查和同行评分这两个方法。
首先，来谈下桌面检查。桌面检查可视为由单人进行的代码检查或代码走查；并由一个人阅读程序，对照错误列表检查程序，对程序推演测试数据。由此，我觉得桌面检查可以说是上述两种方法的一个内核或者说是雏形吧。所以也可知其效率是相当低的。
然后，看一下同行评分。需指明：其该方法与测试并无关系，因为其目标并不是为了发现错误的，只是它与代码阅读的思想有一定的关联而已。
⊙定义上：同行评分是一种依据程序整体质量、可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。不难看出，该技术的目的是为程序员提供自我评价的手段。
⊙其小组成员的构成为：一位管理员，负责担任该评分过程的管理工作；6-20名参与者，并要保持匿名性，且要具备相似的背景。
⊙评分的资料：由参与者自己挑出两个由自己编写的程序以供评审，其中一个应是自认为能代表其自身能力的最好作品；另一个是自认为质量较差的作品。
