[总结]静态白盒测试 - Code Review 2

 

三、      在项目中应用静态白盒测试

再次说明一下，之所以需要在项目中使用这些静态白盒测试方法是基于这样的原则：错误发现得越早，改正错误的成本越低，正确改正错误的可能性越大，改正错误时可能引发的其他错误的数量也越少。

项目里负责执行静态白盒测试的角色并不固定。在某些项目中，程序员是组织和执行的人，软件测试员被邀请作为独立的观察者。而另外一些项目中，软件测试员是该任务的执行人，编写代码的程序员和其他同时协助测试。项目组可以选择两者之一，这取决于哪种更适合项目的情况。

和很多事情一样，如果决定在项目中实行一些静态白盒测试活动，那么首先需要考虑的就是“目的”、“目标”、“策略”等等。假定在项目A中，我们决定采用桌面检查和代码检查来保障代码质量和产品年质量。我们可以想到如下的应用方案。

应用方案

目的

在编码阶段发现更多程序错误,保证软件的功能质量和产品质量。

目标

1、通过在编码阶段由开发人员进行一些静态白盒测试活动，来保证提交后的任务质量，减少任务返工。
2、降低后期功能测试阶段的bug数量，缩短产品稳定需要的时间。

策略

考虑到桌面检查与代码检查各自的特点，可将两者结合使用，以桌面检查为主，以代码检查为辅助。
1、在制定开发进度计划时，应考虑何时何处需要进行桌面检查，并且需要指定合适的检查人员。
2、根据桌面检查的结果，针对一些较复杂、预期问题最多或存在争议的代码组织相关人员进行代码检查。

注意事项

1、在制定进度计划时需要考虑静态白盒测试消耗的时间以及发现问题后的处理时间。
2、检查的唯一目的是发现“程序错误”而不是“人的错误”。

 

接下来需要考虑如何操作和执行这些检查。首先，需要在开发进度计划中安排一系列的检查点，在这些检查点上执行对特定任务的检查。如果开发进度计划按照里程碑的方式分阶段安排，那么其中的检查点也需要分阶段进行安排。其次，我们还需要一个制度或流程以及一些文档来规范检查活动。再次，正如前文所说，静态白盒测试的方法中包含了很多人为因素，所以要取得良好的效果，必须正确的把握这些与“人”有关的因素。

下面的故事也许更生动些。

项目A的产品开发团队决定在开发过程中使用桌面检查、代码检查等静态白盒测试方法。老岳需要在编码阶段的进度计划中安排合适的检查点。老岳把这一阶段需要安排的所有任务（WBS）浏览了一遍。他想，没有必要针对所有的任务都执行检查，那样检查点太多会增加开发团队的压力。只需要把代码上关联较大的任务组织起来，当它们都提交时进行一次检查就可以了，最好这些任务的持续时间在3-5天。于是老岳又开始浏览任务，并在一些较大的任务块上设置了需要执行检查的标记。最后，老岳又找来小白，讨论了一下这些检查点设置得是否合理。

做完这些，老岳又想起来以前的一些项目也组织过代码的检查活动，但是当时没有表现出好的效果。可能有几方面的原因。其一，大家并没有理解代码检查的真正意义，从直觉上，有人把代码检查理解成了对代码作者的评价。其二，没有一个明确的代码检查的制度、流程和反馈。想到这里，老岳决定在执行代码检查制度之前需要对所有开发人员进行一些培训，要让大家认识到，代码检查唯一的目的是发现“程序错误”、改进软件的质量，它不包含任何对程序员的“人身攻击”。其次，需要制定一个检查活动的流程，规范活动生成的文档。老岳先制定了一份检查记录表。看着这张表格，老岳忽然又想到：应该把它放在哪儿呢？——无所谓了，只要在版本控制的范围里就好。

 

总之，若要在项目编码过程中应用静态白盒测试，必须注意一下几点：

Ø  必须使开发人员对检查过程采取积极和建设性的态度。这一点至关重要。如果开发人员对检查活动产生情绪，那么检查就会毫无效果。

Ø  把静态白盒测试的活动合理地融合到进度计划中。

Ø  明确检查活动的工作流程，制定标准的工作文档，并且保留文档记录。

 

一份代码检查记录表。

代码检查记录表

日期

主持人

　

参与人员

　

范围

　

总结

　

说明

　

　

发现的问题

后续处理

编号

问题描述

类别

处理人

处理日期

处理说明

1

　

　

　

　

　

2

　

　

　

　

　

3

　

　

　

　

　

4

　

　

　

　

　

　

跟踪检查

日期

参与人员

　

处理结果

　

说明

　

 

具体的检查活动在每个检查点上进行。还是看一个桌面检查的故事。

老岳收到了新的任务提交提醒——小白提交了任务A-2。根据这个任务上的检查标记，老岳需要对它进行桌面检查。老岳找到小白，大概询问了任务的情况（新增、修改的代码或使用的其他特殊资源等等）。

老岳创建一份新的检查记录表，填写“日期”、“主持人”、“参与人员”及“范围”等项，然后打开小白更改的代码准备检查。在进行检查之前，老岳把手头的错误检查列表浏览了一遍，然后摆上桌子。老岳开始跟着代码逻辑查看任务代码。在一个类的析构函数里，老岳发现有一个List对象没有释放。老岳把它记在检查记录表里，接着继续查看代码。阅读完所有的代码，老岳发现已记录了4条问题。

老岳找来小白，和他确认记录的4条问题是否有误。在他们确认了所有问题后，老岳在“处理人”栏填上小白的名字，把记录表发送给小白。

小白收到老岳的记录表，逐个查看其中列出的问题并修改自己的代码。小白发现自己总是忘记释放内存对象。每修改一个问题之后，小白填写上问题的“处理日期”。在所有问题都处理之后，小白把记录表回复给老岳。老岳再次打开代码复查问题是否都已正确处理或有没有新的问题产生。复查中未发现其他问题，老岳在记录表里填写上跟踪检查的“日期”、“参与人员”、“处理结果”等内容，然后把这份记录表存放到工作目录里。最后老岳在进度计划里通过了任务A-2，任务A-2被标记为100%完成。

 

小组检查与单人进行的检查略有不同，检查的过程在多人参与的会议中进行。

3天之后，小白又提交了任务A-3。这个任务涉及软件中比较核心的代码，需要进行小组代码检查。老岳收到任务提交的提醒后，开始为小组会议做准备。和之前一样，他先跟小白讨论了一下任务，大概了解了代码范围和功能并把它们记了下来。然后老岳把它们和相关的需求文档、设计文档打包在一起。

这时，老岳开始想：他应该邀请谁来参加这个会议呢？老岳想到了老段和老张。老段参与了这段代码的设计工作，老张对任务中依赖的另外一些技术比较熟悉，而且这两个人的编码经验都很丰富，也在项目组工作很长时间了——这会让检查会议更加顺利的，老岳想。老岳给小白、老段、老张发送了一封邮件，征询他们什么时候可以空闲出2小时参加代码检查会议，并在附件里包含了那些打包的文档。经过协商，他们最终把时间定在2天后的下午2：00-4:00。老岳在OA系统上预定第6会议室，然后给大家发送了会议通知。老岳本来打算再邀请一位懂编码的测试人员，但没有想到合适的人选。

2天后，大家都按时到达第6会议室。作为检查会议的主持人，老岳准备了一份新的检查记录表，填写上“日期”、“主持人”、“参与人员”及“范围”等项，准备着记录待会发现的问题。老岳在开场白里用几句话介绍了一下任务A-3，然后给每人发放了一份错误检查列表，而此前，老段和老张也都熟悉了老岳发送给他们的文档。接着，小白开始给大家讲他的代码。从程序进入的接口开始，小白几乎逐条语句地朗读他的代码，然后给大家解释代码的作用。在读到一处文件读写操作的代码时，老段指出打开的文件没有关闭，于是老岳在记录表里记录下了这个问题。在老岳记录的同时，小白添加了一句关闭文件的代码，并写上注释。接下来的过程中，大家又发现了一些其他的问题，老岳都逐一记录了下来。

老岳发现，在讲到某些代码的时候，大家总会把注意力集中到其他的一些事情上。比如在讲用到平台的一处代码时，大家就讨论起平台的发展了。每到这个时候，老岳就要提醒大家继续检查代码，否则2小时的会议得改4小时了。

2小时后，会议终于要结束了。老岳最后向大家展示了他的记录表。记录表里列出的问题不是很多，改动也较小，所以他们决定在小白修改了所有问题后不再进行小组的检查会议，而是由老岳单人跟踪检查一下。小白还记得以前有个任务，由于发现的问题太多，被这个小组检查了两次。

小组发现，小白经常忘记释放内存对象。其他一些程序员也经常犯这个错误。于是，他们把这条问题记录在了错误检查列表里。

 

在代码检查会议上，“主持人”的角色要注意履行他的职责，控制会议高效地进行。代码检查和桌面检查的工作流程如下：

 

每一个开发项目都有它的特点和限制条件，在执行静态白盒测试时也会遇到不同的问题——但有一点是相同的：问题总是会遇到的。如果已经决定在项目中使用静态白盒测试方法，那么在遇到问题时，就应该考虑如何解决问题以使其发挥其效果，而不是质疑静态白盒测试本身。