第三章 识别和描述缺陷.pptVIP

/ 目录 什么是Bug 缺陷的识别 再现与优化缺陷 怎样有效记录缺陷 缺陷报告的用途 缺陷的分类 缺陷报告的处理流程 缺陷跟踪系统 什么是Bug Bug一词的原意是“臭虫”或“虫子”。 现在泛指计算机硬件和软件中的缺陷或错误。 缺陷的识别 什么是缺陷（defect）? 不满足用户确定需求 缺陷的特征 1、软件未实现需求说明书要求的功能 2、软件出现了需求说明书指明不该出现的错误 3、软件实现了需求说明书未提到的功能 4、软件未实现需求说明书未明确提及但应该实现的目标 5、软件难以理解、不易使用、运行缓慢等。 缺陷的识别 产生缺陷的原因是什么？ 人员（用户、设计、开发、测试、技术支持等）之间的沟通交流不够，交流上有误解或者根本不进行交流 文档不完善甚至没有文档（尤其是国内中小软件企业） 需求不断的变化 参与人员的过度自信 程序设计本身有错误 软件复杂度大，缺陷很难避免（例如Windows、Word） 工期短，任务重，时间压力大 软件开发工具与系统软硬件的支持 缺陷的识别 信息传递的误差 1、用户想要的 2、用户所说的 3、需求人员理解的 4、《系统需求规格说明书》 5、开发人员理解的 6、实际软件 实际软件与用户想要的有偏差。 缺陷的识别 缺陷的识别 软件测试人员发现了问题，判断这个问题是否是缺陷的依据是什么？ 通过参考文档来确认缺陷 需求规格说明书 概要设计、详细设计 用户手册 … 通过了解软件行业标准、行业背景（或参考同类典型软件）来发现缺陷 通过沟通来确认和识别缺陷 再现与优化缺陷 再现（又叫重现）与优化缺陷的必要性 备注：优化缺陷并不是指优化缺陷本身，而是优化缺陷的再现步骤 为什么要再现与优化缺陷？ 关于软件中“随机”出现的缺陷如何处理？ 再现与优化缺陷 再现与优化缺陷的方法 不要想当然的接受任何假设 查找依赖关系和竞争条件的问题 与压力和负荷相关的边界条件软件缺陷、内存泄漏和数据溢出缺陷的发生有一定的前提条件 状态缺陷仅在特定软件状态中显露 考虑资源依赖性，内存、网络、硬件共享的相互作用 关注硬件的失效问题，硬件可能不按照预定方式工作 关注软件的失效问题，对缺陷的修改可能会引发新的缺陷 从阅读缺陷报告入手，提高编写缺陷报告的能力 怎样有效记录缺陷 保证重现缺陷 判断一个缺陷报告撰写好坏的简单方法：让非缺陷报告撰写者（技术人员）依据缺陷报告重现缺陷，如果能简单、迅速的重现缺陷，表明缺陷报告较好。 怎样有效记录缺陷 分析故障——使用最少步骤重现缺陷 减少开发人员重现缺陷的时间 使开发人员更准确的定位缺陷 怎样有效记录缺陷 包含所有重现缺陷的必要步骤 测试人员假定常用的操作步骤开发人员不一定熟悉，省略了必要的步骤常常造成开发人员无法重现缺陷。 怎样有效记录缺陷 方便阅读 举例： 概述：使用“记事本”仅保存“联通”二字后再打开该文件，出现乱码。 描述步骤： 点击“开始”-“程序” -“附件” -“记事本”打开记事本软件； 仅输入“联通”二字后，点击“文件”-“保存”； 在打开的“另存为”对话框中保存文件后退出（文件名、保存位置任意）； 打开保存的文件，出现乱码，不是“联通”二字。 怎样有效记录缺陷 一个缺陷一个报告，为什么呢？ 举例（一个缺陷报告中两个缺陷）： 概述：使用“记事本”仅保存“联通”二字后再打开该文件，出现乱码，而且“另存为”对话框中默认文件后缀写成了“.txk”。 描述步骤： 点击“开始”-“程序” -“附件” -“记事本”打开记事本软件； 仅输入“联通”二字后，点击“文件”-“保存”； 在打开的“另存为”对话框中保存文件后退出（文件名、保存位置任意），默认文件后缀应该是“.txt”，实际写成了“.txk” ；（假设） 打开保存的文件，出现乱码，不是“联通”二字。 这样有什么不良后果？ 答案：步骤3出现的缺陷对于开发人员而言容易修复，而步骤4出现的缺陷可能很难修复，那么如果开发人员修复了步骤3出现的缺陷而没有修复步骤4出现的缺陷，这个缺陷报告是解决了还是没解决？ 怎样有效记录缺陷 注意自己的语气 举例： 概述： “记事本”中“另存为”对话框中默认文件后缀写成了“.txk”。 描述步骤： 点击“开始”-“程序” -“附件” -“记事本”打开记事本软件； 仅输入“联通”二字后，点击“文件”-“保存”； 在打开的“另存为”对话框中，默认文件后缀应该是“.txt”，你们开发人员是不是用脚后跟考虑问题的，居然写成了“.txk” ； 怎样有效记录缺陷小结 保证重现缺陷 分析故障——使用最少步骤复现故障 包含所有重现缺陷的必要步骤 方便阅读 尽量简单——一个缺陷一个报告 注意自己的语气 值得注意的经验 缺陷报告的用途 缺陷报告的用途是什么？ 记录缺陷 缺陷分类（为解决缺陷分配资源） 缺陷跟踪 为什么要尽早的