软件工程基础第5章.ppt

症状和原因 症状 原因 症状和起因可能是分开的 当修复了一个别的问题时，症状可能消失了 原因可能是非错误的结合 原因可能是由于系统错误或编译程序的错误 原因可能是由于每个人都相信的假设 症状可能是间歇性的 * 错误的后果 损坏程度 温和的 令人讨厌的 烦扰的 严重的 极端的 灾难性的 可传染的 错误类型 错误分类： 功能错误 系统错误, 数据错误, 代码错误 设计错误, 文档错误, 违反标准等 * 1. 调试的步骤 1）从错误的外部表现形式入手，确定程序中出错位置。 2）研究有关部分的程序，找出错误的内在原因。 3）修改设计和代码，以排除这个错误。 4）重复进行暴露了这个错误的原始测试或某些有关测试，以确认该错误是否被排除，是否引起了新的错误。 5）如果所做的修改无效，则撤销这次改动，重复上述过程，直到找到一个有效的解决办法为止。 * 2. 主要调试方法 （1） 强力法排错 1） 通过打印全部内存来排错。 2） 在程序特定部位设置打印语句。 3） 使用自动调试工具。 确定最先发现“症状”的位置，人工沿程序的控制流程，向回追踪源程序代码，直到找到错误根源或确定错误产生的范围。 （2） 回溯法排错 * （3） 归纳法排错 收集数据 组织数据 提出假设 证明假设 （4） 演绎法排错 1） 列举所有可能出错原因的假设。 2） 利用已有的测试数据，排除不正确的假设。 3） 改进余下的假设。 4） 证明余下的假设。 * 3. 调试原则 1） 分析思考与错误征兆有关的信息。 2）如果程序调试员无法解决当前问题，可留到第二天再去考虑，或者向其他人讲解这个问题。 3） 只把调试工具当做辅助手段来使用。 4） 避免用试探法，最多只能把它当做最后手段。 1） 出现错误越多的地方，存在错误的可能性就越多，应重点检查。 2） 如果提出的修改不能解释与这个错误有关的全部线索，那就表明只修改了错误的一部分，应当继续追踪和检查。 3） 在修改了错误之后，必须进行回归测试，以确认是否引进了新的错误。 4） 修改错误也是程序设计的一种形式，在程序设计阶段所使用的任何方法都可以应用到错误修正的过程中来。 5） 修改源代码程序，不要改变目标代码。 （1） 确定错误的性质和位置的原则 （2）修改错误的原则 * 5.3 面向对象的测试 5.3.1 测试策略 1. 单元测试（类测试） 2. 集成测试 3. 确认测试和系统测试 * 5.3.2 类测试方法 1. 基于状态的测试 （1） 类内测试 （2） 状态测试 1） 测试类中各个方法的正确性。 2） 测试各个方法功能的完备性。 3） 选择合适的测试用例，确保覆盖方法中的所有代码。 1） 类的实例化测试 2） 对象状态的测试 * 2. 数据流测试 第一阶段，检测和去除信息结果中的数据流异常。 第二阶段，从规则信息结果中产生类测试用例。 （1）测试标准 （2）数据流异常检测 （3）产生数据流测试用例 3. 继承层次的测试 （1） 继承图 （2） 测试方法 4. 自动测试 * 5.4 软件维护的基本原理 5.4.1 软件维护的分类 * S-系统 系统类型 真实世界 问题 系统 需求规格说明 信息 比较 变化的主题 * P-系统 系统类型 真实世界 问题 系统 需求规格说明 信息 比较 变化的主题 抽象 * E-系统 系统类型 问题 抽象 系统 需求规格说明 信息 比较 变化的主题 真实世界 * 1. 改正性维护 为了识别和纠正软件运行时的错误、改正软件性能上的缺陷、排除实施中的误使用所做的工作。 为了使开发出的软件适应硬件的更新或新的操作系统版本，或者将软件移植到新的环境中运行而对软件进行的修改。 2. 适应性维护 为满足用户不断增长的需求，而对软件进行相应的修改过程。 3. 完善性维护 为了改进软件未来的可维护性或可靠性，或者为了给未来的改进奠定更好的基础而对软件进行的修改过程。 4. 预防性维护 * 16 不同软件维护的工作量分布 适应性 完善性 改正性 预防性 * 可理解性 5.4.2 影响软件可维护性的特性 可测试性 可靠性 可修改性 可移植性 可使用性 效率 软件可维护性 1.可理解性 一个程序可以被毫无困难的理解的程度 2. 可测试性 一个程序可以被毫无困难的测试的程度 方法:“90-10 测试”. 可审计性 复杂性 自检性 模块化 自文档性 简单性 相关特性 * 3. 可修改性 N：一个程序中的模块数 n：一个程序中必须修改的模块数 Ci：第i个模块的复杂性 Aj：必须修改的第j个模块的复杂性 程序可以容易修改的程度。 一个程序中所有模块的平均复杂性 一个程序中必须修改的模块