软件工程上课用书中文课件内容

1、2022/9/61软件测试的报告和分析62022/9/62议题使软件缺陷得以修复 分离和再现软件缺陷对软件缺陷分等级软件缺陷的生命周期软件缺陷的跟踪测试的评价和分析2022/9/63使软件缺陷得以修复 软件缺陷可能不能修复没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复审查软件缺陷，判定是否可以修复判定依据是软件测试的缺陷报告2022/9/64软件缺陷报告的基本原则尽快报告软件缺陷，因为缺陷会放大有效描述软件缺陷短小：只解释事实和演示，描述软件缺陷必要的细节单一：报告的每一项只针对一个缺陷明显通用：使用易懂的展示通用性的简单易行步骤描述的软件缺陷，比较容易修复再现：按照预定步骤可以使软

2、件达到缺陷再次出现的相同状况在报告软件缺陷时不做评价补充完善软件缺陷报告，不能遗漏每一个缺陷2022/9/65分离和再现软件缺陷不要想当然地接受任何假设（确保细节的记录）查找时间依赖和竞争条件的问题与压迫和负荷相关的边界条件软件缺陷、内存泄露和数据溢出等问题也许慢慢自己显现出来状态缺陷仅在特定软件状态中显露出来考虑资源依赖性和内存、网络、硬件共享的相互作用不要忽视硬件2022/9/66软件缺陷分等级软件缺陷分出严重性和优先级严重性表示软件缺陷的恶劣程度，反映其对产品和用户的影响(致命、严重、一般、较小)优先级表示修复缺陷的重要程度和应该何时修复(立即解决、高优先级、正常排队、低优先级)等级严重

3、性优先级1系统崩溃、数据丢失、数据毁坏立即修复，阻止进一步测试2操作性错误、错误结果、遗漏功能在产品发布之前必须修复3小问题、错别字、UI布局如果时间允许应该修复4建议可能会修复，也可能会发布严重性与优先级的关系严重程度高说明缺陷对软件造成的质量危害性大，是需要优先处理，而严重程度低的缺陷可能只是软件不太尽善尽美，可以稍后处理。（对软件质量的影响程度和处理方式）一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。（如公司名称写错了）2022/9

4、/672022/9/68软件缺陷的生命周期开发组完成代码,打包交给测试组配置管理对软件包基线控制测试组测试问题跟踪与变更申请打开(open)问题测试结束, 评估开发组处理问题处理问题测试组确认问题已改正开发组重新打包对软件包基线控制软件开发流程控制从实现开始, 给此项目创建新版本关闭(close)问题2022/9/69建立缺陷与产品的追踪矩阵产品的目录结构可以分层管理,比如三层系统产品的目录结构子系统产品的目录结构构件产品的目录结构产品的管理由配置管理决定测试的缺陷要和产品的层次级别、测试用例、变更请求建立连接，用来分析产品质量2022/9/610比如： 2022/9/611缺陷报告与跟踪可以

5、手动记录：参见文件testreport.doc可以自动自动记录，数据库用于存放产品测试信息，一般包含四种角色：“测试组长”、“测试员”、“开发人员” 、“项目经理”。在使用数据库时，首先由具有“测试组长”角色的用户创建项目中的产品的描述文档。此后，测试人员应创建产品测试信息文档，并开始对产品进行测试。如果发现此产品存在问题，则填写一份产品测试跟踪报告，利用邮件通知给开发人员，由开发人员决定是否进行修改。如果开发人员和测试人员发生争议，可以提交给“测试组长”组长作出决定。在整个流程中共有八个可能的状态：草案，提交，拒绝，接受，终止，推迟，审定，解决。 2022/9/6122022/9/613测试结果的评价分析评估测试的目的是生成并交付测试评估报告。这是通过复审并评估测试结果、确定并记录变更请求，以及计算主要测试评测方法来完成的。测试评估摘要以组织有序的格式提供测试结果和主要测试评测方法，用于评估测试对象和测试流程的质量。2022/9/614测试分析的步骤步骤 分析测试结果并提交变更请求 评估基于需求的测试覆盖 评估基于代码的测试覆盖 分析缺陷 确定是否达