基于ISO 26262功能安全标准的测试系统测试方法(上)

　　⒋测试案例需要按照表8中的方法进行分析设计。

　　⒌对于软件架构级别的需求测试覆盖度，可以用来衡量测试的完整性，以及用于证明没有设计之外的功能实现。如果有需要，可以增加新的测试案例，或者提供一个合理的理由说明。

　　⒍为了评估测试案例的完整性，同时确保没有多余的功能，根据表9列出的指标需要衡量出其结构覆盖率。如果覆盖率不够高，要么需要添加额外的测试案例，或者提供一个合理的理由说明。例如，结构覆盖率的分析可以用于发现测试案例的不足、无用代码、无效代码或者多余功能等。

　　● 结构覆盖率可以利用工具计算出来。
　　● 如果是基于模型的开发，结构覆盖率可以通过模型级别的模型结构覆盖率来统一计算。

　　⒎作为产品发布的一部分，嵌入式软件需要被验证其包含设计的所有功能。如果嵌入式软件包含了设计之外的功能(比如用于调试的代码)，则这些功能需要被验证是不影响软件的安全需求的。如果这些设计之外的功能在真实产品中保证不会被激活执行，那也是符合这个要求的;否则删除这些功能，也需要按照需求变更流程来统一处理。

　　⒏软件集成测试需要尽可能地在真实环境中运行，如果不行，则需要评估测试环境与真实环境的差异性，并针对这些差异，在后续的阶段的真实环境的测试中设计专门的案例来执行。

　　● 测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。
　　● 针对各种测试，需要建立合适的测试环境。比如目标处理器的测试环境、仿真处理器的测试环境、开发测试环境等。
　　● 软件集成测试可以利用模型在环测试(MIL)、软件在环测试(SIL)、处理器在环测试(PIL)、硬件在环测试(HIL)等测试手段进行测试。

　　软件安全需求验证

　　本阶段的目标是验证嵌入式软件符合软件安全需求，其所规定的要求和建议如下：

　　⒈软件安全需求的验证需要制定计划，定义再执行。

　　⒉为了验证嵌入式软件实现了软件安全需求，表10列了所需的测试环境。注意：已有的测试案例，例如在软件集成测试阶段使用的可以重用。

　　⒊对于软件安全需求实现的测试需要在目标硬件平台上完成。

　　⒋软件安全需求验证的结果需要考虑下面这些因素来评估：

　　● 和预期结果一致;
　　● 软件安全需求的覆盖率;
　　● 成功或失败的标准。

　　(未完待续)

　　参考文献：

　　[1]IEC 61508: Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems[S/OL].http://zh.wikipedia.org/wiki/IEC_61508
　　[2] ISO 26262-1:2011, Road vehicles -- Functional safety-Part1: Vocabulary[S]
　　[3]ISO 26262-8:2011, Road vehicles -- Functional safety-Part8: Supporting processes[S]
　　[4]ISO 26262-2:2011, Road vehicles -- Functional safety-Part2: Management of functional safety[S]
　　[5]ISO 26262-9:2011, Road vehicles -- Functional safety-Part9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses[S]