6-1健壮性与正确性

• 本博客为哈工大计算机科学与技术学院大二软件构造课程的课件翻译。同时记录了部分本人上课时的学习笔记和感悟
• 该博客3700字左右，主题为6-2 错误与异常处理，基本更新完成
• 由于水平有限，翻译可能不是特别流畅、通顺，并且存在一定错误，观点、笔记不一定完全正确，敬请各位批评指正！
  大纲
  什么是健壮性和正确性
  如何度量健壮性和正确性
  本章目标

什么是健壮性和正确性

健壮性

• 健壮性：“在无效输入或有压力的环境条件下，系统或组件能够正确工作的程度”
• 面向健壮性的编程：
  • 一种侧重于处理意外终止和意外操作的编程风格。
  • 它需要代码通过显示准确无误的错误消息来优雅地处理这些终止和操作。
  • 这些错误消息允许用户更容易地调试程序。

健壮性的原则

• 偏执(偏执狂)——程序员假定用户想要破坏他们的代码，并假设自己编写的代码可能失败或不正确工作。（错误消息应该尽量准确，而不误导用户，这样问题就可以很容易地得到修复。）
• 愚蠢——程序员假定用户将尝试不正确的、伪造的和格式错误的输入。（ 把用户想象成白痴，可能输入任何东西）
  • 因此，程序员返回给用户一个明确的、直观的错误消息，不需要查找错误代码。
  • 错误消息应该尽量准确，而不误导用户，这样问题就可以很容易地得到修复。（返回给 用户的错误提示信息要详细、准确、无歧义）
• 健壮性原则：对别人宽容点，对自己狠一点
• 做事要保守;接受别人的东西要大方。
• “发送的要保守，接受的要自由"

对自己的代码要保守，对用户的行为要开放

在你做的事情上要保守，在你从别人那里接受的事情上要自由(经常被改写成“在你送的东西上要保守，在你接受的东西上要自由”)。

健壮性编程的原理

• 危险的实现——用户不应该访问库、数据结构或指向数据结构的指针。（封闭实现细节，限定 用户的恶意行为 ）
• 这些信息应该对用户隐藏，这样用户就不会意外地修改它们并在代码中引入错误。
• 当这些接口被正确构建时，用户可以使用它们，而不会发现漏洞来修改接口。
• 因此，用户只关注他或她自己的代码。
• 不可能发生——代码被修改，可能会导致出现“不可能”的情况。（ 考虑极端情况，没有“不可能” ）
• 因此，不可能的情况被认为是极不可能的。
• 开发人员考虑如何处理极不可能的情况，并相应地实现处理。

正确性

• 正确性定义为软件根据其规范执行的能力。（ 正确性：程序按照spec加以执行的能力，是最重要 的质量指标！ ）
• 健壮性与正确性:在天平的两端
  • 正确性意味着从不返回不准确的结果;没有比不准确的结果更好的结果。( 正确性：永不给用户错误的结果 )
  • 健壮性意味着总是尝试做一些事情来允许软件继续运行，即使有时会导致不准确的结果。(健壮性：尽可能保持软件运行而不是总是退出)
• 健壮性增加了对常见和非关键错误的内置容忍度，而正确性在遇到任何不完美的输入时抛出错误。
  • 正确性倾向于直接报错(error)，健壮性则倾向于容错(fault-tolerance)

健壮性和正确性的比较

问题	健壮性方法	正确性方法
在HTTP头文件中添加尾随空格的恶意web浏览器 （ 浏览器发出包含 空格的URL）	带空白，处理请求正常	返回HTTP 400坏请求错误状态给客户端
具有损坏帧的视频文件。	跳过损坏区域到下一个可播放区域。	停止播放，引发“损坏的视频文件”错误。
配置文件，用错误的字符注释掉了行。	在内部识别最常见的注释前缀，忽略它们。	启动时终止，配置错误。
以奇怪格式输入日期的用户。	尝试根据许多不同的日期格式解析字符串。将正确的格式返回给用户。	无效的日期错误。

没有破折号或空格

• 信用卡号码总是四位数一组打印并大声读出。
• 计算机非常擅长文本处理，因此强迫用户以奇怪的格式重新输入信用卡号是在浪费用户的时间，这完全是开发人员的懒惰。
• 在谷歌地图中，你可以在搜索框中输入任何东西，它会指出街道地址。
• 健壮性 ：避免给用户太大压力， 帮助用户承担一些麻烦
  • 健壮性使用户和第三方开发人员的工作更轻松。
• 通过构建一些经过深思熟虑的灵活性，它将为用户提供第二次机会，而不是将他们踢出去。
• 正确性会让你的开发人员的生活更容易。
  • 他们可以专注于一个单一的模型，在这个模型中所有的假设都得到了保证，而不是陷入检查/固定参数和处理奇怪的边界情况的泥潭。
  • 因此，任何在主要成功路径之外的状态都可以被忽略——生成更简短、更容易理解和更容易维护的代码

• 健壮性： 让用户变得更容易：出错也可 以容忍，程序内部已有容错机制
  让用户变得更容易：出错也可 以容忍，程序内部已有容错机 制
• 正确性： 让开发者变得更容易：用户输 入错误，直接结束。 （不满足precondition的调用）

外部和内部：
- 外部接口(UI、输入文件、配置、API等)的存在主要是为了服务于用户和第三方。让它们变得健壮，并尽可能地适应，同时期望人们会输入垃圾。
- 应用程序的内部模型(即域模型)应该尽可能简单，并且始终处于100%有效的状态。使用不变量和断言做出安全的假设，并在遇到任何不正确的情况时抛出一个大的异常。
- 在将内部模型传递给内部模型之前，使用一个反腐败层来保护内部模型不受外部接口的影响，该层将映射并在可能的情况下纠正无效的输入。（在内外部之间做好隔离，防止“错误”扩散 ）

• 使您的外部接口健壮，并使您的内部模型正确（对外的接口，倾向于健壮；对内的实现，倾向于正确 ）
  • 如果你忽视了用户的需求，没有人会想要使用你的软件。
  • 如果忽略了程序员的需求，就不会有任何软件。
• 安全批评的应用有利于对鲁棒性的纠正
  • 最好不返回结果，而不要返回错误的结果。
• 消费者倾向于稳健而非正确。
  • 任何结果都比关闭软件要好。
• 可靠性(可靠性)。无论何时需要，系统在规定的条件下执行其所需功能的能力——故障之间的平均间隔时间很长。
• 可靠性=健壮性+正确性

表示软件问题的术语

• error：是在软件系统开发过程中做出的错误决策。（(error≈ mistake) 程序员犯的错误 ）
• defect：是软件系统的一种属性，它可能导致系统偏离其预期的行为。（ 缺陷，bug的根源 ）
• fault：代码中错误的或缺失的函数。(defect≈ fault, bug)
• failure：是执行过程中故障的表现形式，是软件系统在一次执行过程中偏离其预期行为的事件。（失效，运行时的外在表现）
• 因果关系：error --> defect/fault/bug --> failure
• 程序员犯错导致软件存在缺陷，导致软件运行时失效

error --> defect/fault/bug --> failure

• The error: write “+” to “-”
• The fault/defect/bug : the wrong result of statement
• The execution will show a failure.
• 程序员犯了一个error(mistake)，导致了软件源代码的defect(fault, bug)。
• 如果执行此缺陷，在某些情况下系统将产生错误的结果，从而导致失败。

改进健壮性和正确性的步骤

• 第0步:使用断言、防御性编程、代码复查、形式化验证等方法来编写具有健壮性和正确性目标的代码
• 步骤1:观察故障症状(内存转储、堆栈跟踪、执行日志、测试)
• 步骤2:识别潜在错误(错误定位、调试)
• 步骤3:修复错误(代码修订)

如何度量健壮性和正确性

平均故障间隔时间（MTBF）外部观察角度

• 平均故障间隔时间(MTBF,平均失效间隔时间)之间的运行时间预测系统在操作过程中固有的失败
  • MTBF是系统故障间隔时间的算术平均值(平均)。
• MTBF的定义取决于系统故障的定义。
  • 对于复杂的、可修复的系统，故障被认为是那些超出设计条件的故障，使系统停止使用并进入维修状态。
  • 在此定义下，发生的故障不能被认为是故障，这些故障可以在未修复的状态下保留或维护，并且不能使系统停止服务。
• 平均故障间隔时间(MTBF)描述可修系统的期望故障间隔时间，而平均故障间隔时间(MTTF)表示不可修系统的期望故障间隔时间。

Residual defect rates 内部观察角度（间接）

• 残余缺陷率：每千行代码中遗留的bug的数量
• 1 - 10 defects/kloc: Typical industry software.
• 0.1 - 1 defects/kloc: High-quality validation. The Java libraries might achieve this level of correctness.
• 0.1 - 1 defects/kloc: High-quality validation. The Java libraries might achieve this level of correctness.
• 对于大型系统来说，这可能是令人沮丧的。
• 例如，如果您已经发布了一百万行典型的行业源代码(1个 defect/kloc)，这意味着您遗漏了1000个bug !

回顾可维护性

• Halstead Volume:基于源代码中(不同的)操作符和操作数的数量的复合度量。