软件故障性质的变迁-QNX.PDF

软软件故障性件故障性质的变迁质的变迁 Chris Hobbs QNX 软件系统公司安全系统高级开发工程师 可靠的软件 • 在设计任务关键型、商业关键型和安全 关 键型的应用程序时，我们越来越多地依 赖复杂的、以软件为基础的软件系统。 • 此类软件正在不断变化： 商家不再自己编写所有软件：商家不再自己编写所有软件： 他们开始购买现成的商业软件，或者 使用开源软件。 软件本身正变得日益复杂。 且慢，请先考虑：什么是软件？ 现场可编程门阵列 (FPGA)算不算软件？DSP 中的固件算不算软件？自动程序生成器生成的 软件又算不算呢？ 《Application Note 2: Software and EN 50128 from Railway Safety》 对硬件和软件做了如下区分： . . . 如果一个设备的内部状态有限，可以通过测试完全涵盖 最好是将其视为硬件并通过设计分析和最终产品的测试来证明其符合安全要求 （包括所有输入和状态组合的穷举测试）。 （如果100% 可测试，则其为硬件而非软件） 为什么软件不是 100% 可测试？ Bohrbug ：实际代码的错误。 与运行时间无关，只要输入值相同，始终会导致同样的错误。 Heisenbug ：时隐时现的幽灵—这些偶尔在测试中出现的粗 的故障往往会被贴上“不可再现”的标签。 可靠软件中出现 Heisenbug ？ 示例： • 缺陷：多线程程序在一个线程中释放共享内存，然后在另一个线程中读取内存。 • 错误：偶尔一次，被释放的内存给予了另一个线程并进行覆盖。 • 故障：线程读取无效的数据并出现崩溃。 缺陷很少会造成错误，而错误通常不会导致故障。故障可能在错误发生之后很长 间之后才会出现。 如何通过测试发现这种漏洞呢？ 100% 测试的不可行性 对于复杂系统而言，测试具有局限性： 观测局限：测试人员无法在测试期间 看到多个线程之间的相互作用。 重复局限：很难充分控制测试环境使 系统地再现问题。 测试采用的是统计技巧：测试只能运行非常少量的可能路径，并且必须以统计方式处理结果 。 打破平局 . . . 随着测试 效用的逐渐 减弱 ，静态 分析的作用 变得越来越 强大”。 打破平衡局面 可靠软件的进 除了最简单的系统之外 ，我们必须接受以下几项事实： • 系统会包含 Heisenbug。因此在设计中 用 Heisenbug 的特点来防范它们。 • 100%测试涵盖律是不可能的。因此，将测试作为统计 活动并通过静态分析支持统计结果。 • 不同安全级不同安全级别别的软件的软件需需要共存。要共存。 因此，要使用能够提供 内存和处理器时间分隔的操作系统。 • 系统会包含 SOUP ：原 出处未知软件。 因此要确保软件的大部分是“清爽的SOUP”： 带