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

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

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

　　在代码检查会议上，“主持人”的角色要注意履行他的职责，控制会议高效地进行。

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