目录
缺陷报告的简单处理流程/缺陷的生命周期（从无到有，从有到无）
软件缺陷的判定准则：
- 软件未达到产品说明书标明的功能：对开发的产品进行定义，给出产品的细节、如何做、做什么、不能什么；
- 软件出现了产品说明书指定不会出现的错误；
- 软件功能超出产品说明书指明范围；
- 软件未达到产品说明书虽指出但应达到的目标；
- 软件测试员认为软件难以理解、不宜使用、运行速度缓慢，或者最终用户认为不好，主要体现在易用性方面。
软件缺陷的表现形式：
- 用户要求的功能、特性没有实现或部分实现；
- 运行出错，包括运行中断、系统崩溃、界面混乱等；
- 数据结果不正确、精度不够、不完整或格式不统一；
- 文字显示内容不正确或拼写错误；
- 系统性能低下、系统资源浪费。
分离和再现软件缺陷：
发现缺陷后，应该做好分离和再现，排查发现的“缺陷”是不是软件本身的问题，然后才能提交，再现3次。
避免提交缺陷的缺陷和重复缺陷：
- 缺陷的缺陷：1.是测试人员提交的不是缺陷的缺陷；
2.是一种无效缺陷；
3.解决办法：正确理解需求，做好缺陷复现。- 重复缺陷：1.同一个缺陷A测试工程师提交后，B测试工程师又提交或者自己提交的缺陷与之前提交的缺陷相同或类似；
2.是一种无效缺陷；
3.解决办法：尽量避免两个人同时测试同一模块；自己提交的缺陷与自己的重复，提交前查一下，增强开发知识。
无法再现的缺陷：
- 首先，对这样的缺陷进行详细的记录，使用不同方法去尝试复现；
- 其次，要合理地安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度，并尽快提交给开发人员；
- 最后，在测试过程中对未再现缺陷予以关注。
缺陷报告：
缺陷报告是对缺陷进行记录、分类（严重性等）和跟踪（修改情况）的文档。
缺陷报告的读者对象：
- 软件开发人员（细节）：报告缺陷是为了缺陷得到修复；希望获得缺陷的本质特征和复现步骤；
- 质量管理人员、市场人员、技术支持人员：希望获得缺陷的严重程度和分布情况，以及对市场和用户的影响程度。
缺陷报告的写作准则（5C）：
- correct（准确）：每个组成部分的描述准确，不会引起误解；
- clear（清晰）：每个组成部分的描述清晰，易于理解；
- concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
- complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
- consistent（一致）：按照一致的格式书写全部缺陷报告。
缺陷报告的组织结构：
- 缺陷的标题/缺陷摘要/缺陷概述/缺陷基本信息：什么地方做了什么事（简洁）;
- 预处理：根据具体条件，有时候写有时候不写（相当于用例里的预置条件）；
- 复现步骤：用例里的操作步骤（完整、简洁）；
- 期望结果：用例里的预期结果；
- 实际结果：根据软件实际结果；
- 缺陷的严重程度；
- 缺陷的优先级：解决缺陷的先后顺序；
- 测试的软件和硬件环境：操作系统、CPU、内存等；
- 测试的软件版本；
- 缺陷的类型：功能、性能、易用性；
- 注释文字和缺陷截图：不好陈述的问题可以用截图。
缺陷报告的写作要求：
缺陷标题：
- 尽量按缺陷发生的原因与结果的方式书写：
执行完A后，发生B；
在什么地方，做了什么事情，出了什么结果：使用“在...以后”，“在...时候”或“在...期间”等连接词有助于描述缺陷的原因和结果；- 避免使用模糊不清的词语；
- 为了方便搜索和查询，尽量使用关键字（软件相关的术语）；
- 为了便于他人理解，避免使用术语、俚语或过分具体的测试细节。
复现步骤：
- 提供测试的预备步骤和信息；
- 步骤完整、准确、简短，没有缺漏任何操作步骤，没有任何多余的步骤；
- 将常见步骤合并为较少步骤；
- 简单地一步一步地引导复现该缺陷；
- 每一个步骤尽量只记录一个操作；
- 每一个步骤前使用数字对步骤编号；
- 尽量使用短语和短句，避免复杂句型和句式；
- 只记录各个操作步骤是什么，不要包括每个步骤的执行结果。
预期结果：
软件应该具有的结果，或者说正确结果应该是什么样子。
实际结果：
- 实际结果的描述要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”；
- 如果一个动作产生彼此不同的多个缺陷结果，或者一个动作将产生一个结果，而这个结果又产生另一个结果，为了易于阅读，这些结果应该使用数字列表分隔开来，如实际结果：
1.显示“命令代码行...错误”；
2.显示“并且终止...服务”。
注释/截图： 包含
- 截图缺陷特征图像文件；
- 测试过程所使用的测试文件：使用的数据及数据存放位置；
- 测试附加的打印机驱动程序：程序存放的位置（或以附件形式发送）；
- 再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息；
- 再次指明该缺陷是否在前一版本就已经存在；
- 多个平台之间是否具有不同表现；
- 注释包含缺陷的隔离信息，指出缺陷的具体影响范围：缺陷A导致其他功能产生问题。
- 案例：
能在win2000和winXP文本框中显示文本内容，但不支持win98；
屏幕刷新后，现象会消失；
使用二进制文件，不存在该错误；
参见附加的使用说明书和测试文件。
怎么提交高质量的缺陷报告：
- 尽早提交缺陷报告：发现一个提交一个；
- 清楚地说明此问题对用户价值的危害；
- 提供尽可能多的技术信息（如包含复现该缺陷需要的环境变量或测试所用的数据文件），方便程序员调试；
- 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确；
- 易于搜索软件测试报告的缺陷；
- 一个缺陷报告中只报告了一种缺陷；
- 缺陷报告中不要提问题；
- 避免常见的错误：
我、你、他；
情绪化的语言和强调符号！！！；
似乎；
看上去可能；
认为比较幽默的内容；
不确定的测试问题/不确定是否是缺陷。
缺陷的分类标准：
| 分类标准 | 含义 |
| 缺陷类型 | 根据缺陷的自然属性划分的缺陷种类（功能、性能） |
| 缺陷严重程度（等级） | 指因缺陷引起的故障对软件产品的影响程序。 |
| 缺陷优先级 | 指缺陷必须被修复的紧急程度。 |
| 缺陷状态 | 指缺陷通过一个跟踪修复过程的进展情况。 |
根据缺陷类型对缺陷分类：
- 功能缺陷；
- 界面缺陷；
- 文档缺陷；
- 代码缺陷；
- 算法缺陷；
- 性能缺陷。
根据缺陷的等级对缺陷分类：
- A类——致命缺陷，包括以下各种错误：
- 由于程序所引起的死机，非法退出；
- 死循环；
- 数据库发生死锁；
- 因错误操作导致的程序中断；
- 功能错误；
- 与数据库连接错误；
- 数据通讯错误。
- B类——严重缺陷（一般功能未实现），包括以下各种错误：
- 程序错误；
- 程序接口错误；
- 数据库的表、业务规则、缺省值未加完整性等约束条件。
- C类——一般缺陷，包括以下各种错误：
- 操作界面错误（包括数据窗口内列名定义、含义是否一致）；
- 打印内容、格式错误；
- 简单的输入限制未放在前台进行控制；
- 删除操作未给出提示；
- 数据库表中有过多的空字段。
- D类——较小缺陷，包括以下各种错误：
- 界面不规范；
- 辅助说明描述不清楚；
- 输入输出不规范；
- 长操作未给用户提示；
- 提示窗口文字未采用行业术语；
- 可输入区域和只读区域没有明显的区分标志。
- E类——意见或建议。
根据缺陷处理的优先级对缺陷分类：
| 缺陷优先级 | 描述 |
| 1 | 缺陷必须立即解决 |
| 2 | 缺陷需要正常排队等待修复 |
| 3 | 缺陷可以在方便时被纠正 |
| 4 | 下一版本修复 |
| 5 | 不修复或列入软件发布清单 |
根据缺陷状态对缺陷分类：
| 缺陷状态 | 描述 |
| submitted/已提交 | 已提交的缺陷 |
| open/打开 | 确认“提交的缺陷”，等待处理 |
| rejected/已拒绝 | 拒绝“提交的缺陷”，不需要修复或不是缺陷 |
| resolved/已解决 | 缺陷被修复 |
| verified/已验证 | 确认缺陷确实被开发修正 |
| closed/已关闭 | 确认被修复的缺陷，将其关闭 |
缺陷报告的简单处理流程/缺陷的生命周期（从无到有，从有到无）
- 软件测试人员提交缺陷报告；
- 测试负责人审核后将缺陷报告分配给相关的开发人员修改；
- 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测；
- 返测通过的缺陷报告由负责人关闭，返测未通过的缺陷报告直接返回开发人员重新修改，缺陷报告直到缺陷被修复以后才关闭；
- 关闭或已解决的缺陷报告可能会被阶段性的复审重新打开，这些报告一旦被再次打开应该立即处理。
缺陷报告的标准处理流程：
- 正常缺陷；
- 重复缺陷；
- 无效缺陷；
- 推迟修改；
- 验证不通过；
- 描述不清楚。
缺陷管理工具的功能：
- 缺陷提交；
- 缺陷跟踪；
- 缺陷分析：
- 有效的缺陷分析不仅可以评价软件质量，同时可以帮助项目组很好地掌握和评估软件的研发过程，进而改进研发过程，未对缺陷进行分析就无法对研发流程进行改进；
- 缺陷分析还能为软件新版本的开发提供宝贵的经验，进而在项目开展之前，指定准确、有效的项目控制计划，为开发高质量的软件产品提供保障。
常见缺陷管理工具：
- Bugzilla；
- Bugfree；
- Mantis；
- Jira；
- ZenTao（禅道）；
- Quality Center/Application Lifecycle Management（项目管理工具）。
1948
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
