使用动态软件分析为医疗设备通过审批提供支持

，它根据故障可能对病人、操作员或其他人员造成的伤害程度规定了安全等级。这些等级与FDA的医疗设备等级类似，即：不会损害健康、可能轻微损害健康和可能严重损害健康甚至导致死亡。

　　在大多数情况下，从IEC 61508演化而来的标准与其类似，因为他们都确实规定了软件生命周期的流程(包括风险管理过程)、活动和任务，并指出该周期不应随着产品的发布而结束，只要软件还在运行，这个流程就必须贯穿于产品维护和问题解决的全过程。因此，不管他们如何定义可接受和不可接受风险，IEC 62304、IEC 61508和其它类似的标准提供了证实系统符合安全要求必须使用的指导和方法。

　　图2 IEC 62304标准从IEC 61508标准演化而来，因此与其它行业标准一样，有同样的起源。要注意的是，IEC 62304清楚说明了它并不依赖于IEC 61508，但是可参考IEC 61508的工具和方法

　　动态分析

　　动态分析用于检验编译源代码的执行情况，可以整体检验，也可以分开进行。由于动态分析执行代码，它不仅测试源代码，也测试编译器、链接器、开发环境，甚至有可能是目标硬件。通常来说，动态分析包括结构(代码)覆盖分析和单元测试，这两者的结合不仅可以提供非常有效的检测软件故障的方法，还可以为证明执行了哪些软件以及如何执行提供证据。

　　结构覆盖分析是航空行业标准DO-178B/C的基础。航空事故往往较为重大和悲惨，因此新闻报道往往比医疗设备事故报道频繁，而航空业也有一个安全记录模范。从前一里到下一里，航空是最安全的交通工具之一。

　　结构覆盖分析

　　动态分析工具使用介入式探针或非介入式探针。介入式探针系统将软件探针(计数或程序呼叫)放置在即将被分析的代码里(高级语言或者汇编器)。这些探针会记录流程执行的相关信息，并生成执行历史。

　　介入式探针和非介入式探针

　　使用介入式探针时，证明探针不会改变测量代码的功能对于分析的有效性非常重要。除了证明介入式探针不会影响源代码，这样的演示通常还要求探针本身不会带入可能导致编译器出现漏洞的事物。这可以通过使用Compiler Validation Suite(一套源代码，用于证明编译器履行正确的计算功能)来展示编译器的有效性并未受到加载进程的影响。

　　非介入式探针系统拥有与介入式探针系统一样或类似的信息，但直接来自于处理器，并且动态分析工具会将这个低层信息连接至原始表示方法(高层语言或者汇编器)。但是，出于各种原因(比如编译器优化的影响)，不能总是明确地建立这种联系。

　　请注意，与所有测试一样，在一个复杂的软件系统，我们同样无法证明结构覆盖分析所用的探针绝对不会影响代码表现。举例来说，从定义上看，Heisenbugs为不可再现的错误，通常被认为由微妙的时间条件导致，他们可能会因代码的任何改变而校正(甚至是带入)，包括加载检测探针。

　　图3 LDRA代码覆盖工具的截图，彩色的图形信息清晰说明了未被执行的代码

　　可靠性判断的证明

　　关键不是为了证明故障不存在(不可能性)，而是为了收集证据，供我们用于软件可靠性判断。特别是如果我们的系统使用SOUP(第三方的软件)，结构覆盖分析可以帮助证明系统没有未使用的或者多余的代码。

　　单元测试

　　单元测试验证小单元，使得观察到不正确的表现更为简易，以便检测故障。在单元测试里，程序或程序串都独立于完整的系统进行隔离测试，以确定他们满足特定的要求。

　　通常情况下，这些要求比项目的要求更加全面，因此，举例来说，可以对界面条件进行测试：对一个像素为750 x 1000的显示的着色测试可能需要针对像素为1200 x 1600的显示进行。每一个程序的界面都进行输入值测试，这可能被更高级程序排除在外，来探索普遍性——该程序的表现一直符合要求。

　　单元测试使得测试通常无法触及的内务代码成为可能，保护性代码元件可以同样被测试。一些偶然纠错的情况可以被移除;举例说，在较大型的系统中，可能引入了一个不必要的程序，或者与之相反，并让观察者以为一切正常。因为我们处理的是较小的元件，就较为容易观察到不正确的行为，并检测错误。

　　如何处理被测试的单元内的子程序取决于测试的目标。传统上，单元测试会引入一个从细节到总体的测试战略(有时候被称为模块或者集成测试)。在这样的方法里，首先对单元进行测试，接着再将其与其他单元整合测试。在这样的测试中子程序并不包括在测试里，它们可以被"存根"取代。

　　图4 在整个系统或某个子系统进行结构覆盖测试提供极大的灵活性

当与结构覆盖分析相结合，在测试里可以随意添加呼叫树的数量的灵