| 表格项 | 说明 |
| 缺陷编号 | 首先把缺陷录入到项目缺陷库，然后再加入到漏测库中。漏测库中的问题编号，就是项目缺陷库中的编号，是唯一的。 |
| 所属模块 | 问题发生的软件部位，可以根据系统实际情况划分模块，比如文件管理、数据库、本地化模块等。 |
| 简要描述 | 问题现象的简要描述，一般不要超过50字。 |
| 详细描述 | 问题现象的详细描述，包括问题的重现步骤等。 |
| 问题级别 | 指致命、严重、一般、次要级别，用来确定是否要进行详细漏测分析。 |
| 漏测产生活动 | 指在软件开发测试过程中，某类被漏测的缺陷最应该在该活动中发现。设置该项分类的目的是为了便于更进一步地细化分析漏测的活动。 |
| 开发阶段主要包括原始需求评审、概念评审、设计评审、代码检视、单元测试、模块联调等。 | |
| 测试阶段主要包括功能测试、系统测试、本地语言测试、设备驱动测试、安装测试、性能测试、异常测试等。 | |
| 发现bug的版本 | 填写发现bug的软件版本号，这个版本号要与代码库中的版本号对应，以便于追溯。 |
| 发现问题时间 | 问题录入的时间、格式（XXXX年XX月XX日） |
| 问题封闭版本 | 录入到漏测库的缺陷必须在预期时间内得到封闭，封闭时需在漏测库填写软件封闭时间。 |
| 关联产品 | 漏测缺陷对哪些产品有影响，必须一一列出 |
| 缺陷影响 | 指缺陷对用户造成的影响，例如系统崩溃、业务终止、数据完整性、命令失效、安装失败、可用性、易用性等，对用户将造成什么样的影响，是一种风险分析。 |
| 问题解决措施 | 对于等级为致命和严重的问题，在此处进行简要说明解决措施。具体的解决措施，需要在漏测问题解决追踪表中进行跟踪 |
| 开发引入原因分析 | 开发人员进行漏测分析，除了分析产生BUG的原因之外，还必须进行相关的影响分析 |
| 开发解决措施 | 开发提出规避漏测的方法 |
| 测试漏测分析 | 测试人员进行漏测分析，除了分析漏测原因之外，还必须就进行相关的影响分析 |
| 测试解决措施 | 测试提出规避漏测的方法 |
| 需求引入分析 | 需求人员进行漏测分析，站在需求角度分析漏测原因，以及进行相关的影响分析 |
| 需求解决措施 | 需求人员提出规避漏测的方法，如果漏测的直接原因，与需求相关，如需求变更了，没有告知给测试，则需求需改进变更的控制方法。 |