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

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

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

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

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

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

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

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

　　一份代码检查记录表。