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