Microsoft PowerPoint - CAST-10解説及びMC／DC関連技術解説(MT-0763A).ppt [互換モード]

(1)

http://www.masc.co.jp

CAST-10解説及びMC/DC関連技術解説

What is a “Decision” in Application of Modified Condition/Decision

Coverage (MC/DC) and Decision Coverage (DC)?

平成25年10月

(2)

CAST-10とは

2002年6月に発行されたCAST-10では、DO-178Bで定義されている

MC/DC、DCを適用する際、デシジョンとは何かについて追究している。

1.1 概要

DO-178B/ED-12Bのデシジョンの定義に関して混乱が生じている。

レベルB,AのソフトウェアにはDC、レベルAのソフトウェアにはMC/DCのデ

シジョンの定義が影響するため、明らかにする必要がある。

<<参考>>

DO-178B Table A-7 Verification of Verification Process Results

1.2 背景

Objective

Description

Applicability by Software Level

A

B

C

D

MC/DC

● Decision Coverage

●

● Statement Coverage

●

● 〇

(3)

Verification of verification

3 -DO178Cにおける構造カバレッジの位置づけ

Verification

要求ベーステスト生成

Software Requirements Based

Test Generation

ソフトウェア

下位要求テスト

Low-Level Tests

ソフトウェア統合テスト

Software Integration

Tests

ハードウェア／

ソフトウェア統合テスト

Hardware/Software

Integration Tests

ソフトウェア要求カバレッジ解析

Software Requirements

Coverage Analysis

ソフトウェア構造カバレッジ解析

Software Structure Coverage

Analysis

追加検証

Additional

Verification

Verificationが正しいことを確認するためのもの（Verification of verification）

カバレッジ100％にすることを目的とするのではなく、Verificationの妥当性の指標

(4)

DO-178B/ED-12Bでの定義

Boolean演算子を含まないBoolean式

（

A Boolean expression containing no Boolean operators.）

<<参考>>

bool A = ( B == C )

If ( D < E)

Condition

• Conditionと0個以上のBoolean演算子で構成されるBoolean式

（

A boolean expression composed of conditions and zero or more Boolean

operators. ）

• Boolean演算子がないDecisionはCondition

A decision without a Boolean operator is a condition.

• １つのDecisionで１つのConditionが1回より多く現れたら、それぞ

れの存在はまったく別の

Conditionである

If a condition appears more than once in a decision, each

occurrence is

a distinct condition

.

<<参考>>

bool a = ( b && c )

if ( A and B) or (A and C))

Decision

Boolean演算子： or and not

Condition

Decision

１つめのAと２つめのAは

Coupled Conditionである。

（別々のConditionとして考える）

(5)

DO-178B/ED-12Bでの定義

• プログラム内のすべてのエントリポイント、エグジットポイントが最

低

1回は呼び出される

（

Every point of entry and exit in the program has been invoked at least

once .）

• プログラム内のすべてのDecisionは可能な出力をすべてとる

（

Every decision in the program has taken on all possible outcomes at least

once. ）

<<参考>>

bool a = ( b && c )

If (( d || (e && d) )

Decision Coverage

outcome

b

c

True

False

－

outcome

d

e

e&&d

True

False

－

False

A or B

A

B

False

True

A and B

A

B

False

True

(6)

DO-178B/ED-12Bでの定義

• プログラム内のすべてのエントリポイント、エグジットポイントが最

低

1回は呼び出される

• プログラム内のすべてのDecisionは可能な出力をすべてとる

• プログラム内の1つのDecisionにあるすべてのConditionは可能な

出力をすべてとる

（

Every condition in a decision in the program has taken all possible

outcomes at least once.）

• 1つのDecisionにあるそれぞれのConditionはDecisionの結果に独

立的に影響することをあらわしている

（

Each condition in a decision has been shown to independently affect that

decision‘s outcome.）

Modified Condition/Decision Coverage

A or B

A

B

Fal

se

False

True

False

True

False

A and B

A

B

False

True

False

True

False

Tr

ue

True

(7)

Branch

A)

If 文、Case文、Go to文

（

A computer program construct in which one of two or more alternative sets of

programs statements is selected for execution. case; jump; go to; if-then-else.）

B)

If文などの分岐点（ブランチポイント）

（

A point in a computer program at which one of two or more alternative sets of

program statements is selected for execution. Syn: branchpoint.）

(8)

• MC/DCチュートリアルはDO-178B/ED-12Bの”literal”定義を支持する。

The MC/DC tutorial supports the “literal” definition of decision in DO-178B/ED-12B.

• チュートリアルでは、「Decisionはブランチポイントの同意語ではない。MCDC

はブランチポイントにある

Decisionだけではなく、すべてのDecisionに適用す

る」と述べている。

The tutorial states “a decision is not synonymous with a branch point. MC/DC applies to all decisions – not just those within a branch point”.

• チュートリアルではdecisionは古典的なブランチポイントに加え、代入文、実

際のパラメータ、インデクサ、集約などに現れる

Boolean演算子を含むことを

示す。

The tutorial indicates that a decision includes the traditional branch points plus Boolean operations that appear in assignment statements, actual parameters, indexers, aggregates, etc.

• DO-178B/ED-12Bはentry and exit point coverageも要求しているが、一般的

な

Branch Coverageにはそれらが含まれていない

It should also be noted that DO-178B/ED-12B also asks for entry and exit point coverage, which is also not part of the “traditional” branch coverage.

<<参考>>

例

A := B or C; E := A and D;

e = Function( a || b , c &&d );

MC/DC tutorial：

a joint effort between NASA, FAA, and several industry participants.

(9)

DO-178B

“literal”な定義

1. Structural coverage guidelines are:

a. プログラム内の全てのステートメントが最低1回は呼び出される

Every statement in the program has been invoked at least once.

b. プログラム内の全てのエントリポイント、エグジットポイントが最低1回は呼

び出される

Every point of entry and exit in the program has been invoked at least once.

c. プログラム内の全てのコントロールステートメントが最低1回は可能な出力

をすべてとる

Every control statement in the program has taken all possible outcomes at least once.

d. プログラム内の全ての定数でないBoolean式はTrue/False結果の両方を評

価している

Every non-constant Boolean expression in the program has evaluated to both a True and a False result.

e. プログラム内のBoolean式にある全ての定数でないConditionはTrue/False

結果の両方を評価している

Every non-constant condition in a Boolean expression in the program has evaluated to both a True and a False result.

f. プログラム内のBoolean式にある全ての定数でないConditionは独立的に

式の出力に影響していることをあらわしている

Every non-constant condition in a Boolean expression in the program has been shown to independently affect that expression's outcome.

(10)

2. Based upon these definitions:

a. Statement Coverage requires (a) only

b. DC requires (b, c, d)

c. MC/DC requires (b, c, d, e, f)

The “literal” definition of decision

(11)

問題点とその理由

問題点

• いくつかの産業関係者はこの“literal” definition of decisionを適用していない

Some industry participants are not applying this “literal” definition of decision.

• 彼らはBranch coverageとDecision Coverageを同一にし、MC/DC,DCの解釈

に矛盾を導いている

They are equating branch coverage and decision coverage, leading to inconsistency in the interpretation and application of DC and MC/DC in the industry.

• 特にツール開発者は、航空の背景よりむしろ古典的な(IEEEの定義を使用し

た

)試験の背景からきて以来、そのアプローチにおいて矛盾している傾向に

ある

Tool manufacturers, in particular, tend to be inconsistent in the approach, since many of them come from a “traditional” testing background (using the IEEE definitions), rather than an aviation

background.

矛盾に対する潜在的な理由

• DO-178B/ED-12Bの説明不足、練習材料の欠如

Lack of clarification and training materials on DO-178B/ED-12B.

• 古典的なソフトウェア試験コミュニティと航空コミュニティの違い

The difference from the aviation community and the traditional software testing community.

• DO-178B/ED-12Bの著者たち自身の間での同意の欠如

Lack of agreement among the authors of DO-178B/ED-12B themselves

• 航空産業の外側で開発された工業用検証ツールの使用

(12)

• DO-178B/ED-12BのDecision Coverageの定義として“literal”定義を支持すると

いう人もいる

Some support the “literal” definition of DO-178B/ED-12B definition for decision coverage. (i.e., a decision is more than a branch point).

• DO-178B/ED-12Bの“intended”定義は“literal”定義とは違うと信じている人もい

る

Some believe that the “intended” definition of DO-178B/ED-12B is different than the “literal” definition (i.e., branch coverage is equal to decision coverage).

• MC/DCには“literal”定義を適用し、DCには“relaxed”定義を適用する人もいる

Some apply the “literal” definition of decision for MC/DC and the “relaxed” definition for DC.

“literal” Decision

(13)

“literal” Decision

A := B or C;

E := A and D;

if E then …

“literal” 定義と“branch point” の違い

Branch

Point

DO-178B/ED-12B’s

“literal” Definition of Decision

以下の３つのステートメントを使用して、それぞれのケーススタディを行う

• ”literal”定義のDecisionでMC/DC、DCを適用する

(14)

A := B or C

E := A and D

if E then …

ケーススタディ

MC/DCに“literal”定義を使用した場合

A(outcome)

B

C

True

False

True

False

E(outcome)

A

D

True

False

True

False

True

E

B

C

D

True

False

True

False

True

False

True

False

True

(item “c”)

(item “e” and “f”) (item “e” and “f”) (item “d”) (item “d”)

E(outcome)

A

D

True

False

True

False

(15)

ケーススタディ

• assignments （Boolean式）がif-then文として同じコードコンポーネントに

含まれていようと、違うコードコンポーネントだろうと、これはその

assignments （Boolean式）に適用する。

This applies whether the assignments (Boolean expressions) are contained in the same code component as the if-then statement, or in a different code component.

• システムのコンピュータプログラムとモジュールがどのように分配され

ようが問題なく、

_{MC/DCはそれを処理する。}

No matter how the logic is distributed across the system’s computer program and modules, MC/DC will address it.

(16)

A := B or C

E := A and D

if E then …

ケーススタディ

MC/DCの “decision” を“branch point”と同等にした場合

E

A

B

C

D

True

－

True

False

－

False

• この解釈は論理演算において著しく弱い検証が実行されることを許し

てしまう

This interpretation allows significantly weaker verification to be performed on logic.

• 事実、ロジックにテンポラリを使うと、DCとMC/DCの間に違いがなくな

るようなコードを書くことができる

In fact, one can now write code using temporaries for logic so that there would be no difference between DC and MC/DC.

欠点

(item “c”)

(Branch pointではないので、Don’t care)

E(outcome)

A

D

True

False

－

False

(17)

A := B or C

E := A and D

if E then …

ケーススタディ

DCに“literal”定義を使用した場合

(item “c”) (item “d”) (item “d”)

A(outcome)

B

C

True

False

E(outcome)

A

D

True

False

最終的に必要なテストケース

E

A

B

C

D

True

False

E(outcome)

A

D

True

(18)

ケーススタディ

DCの “decision” を“branch point”と同等にした場合

A := B or C

E := A and D

if E then …

(item “c”)

(Branch pointではないので、Don’t care)

• この解釈は論理演算において弱い検証が実行されることを許してしまう

This interpretation allows weaker verification to be performed on logic.

• その弱体化は、その式がどれだけ多くのコンポーネントに分配されてい

ても、またカバレッジ分析が完全に統合されたコンポーネントもしはスタ

ンドアロンコンポーネントで実行されようと、最終的に

Branch Pointで使

われる

_{Boolean式の数に比例するということである。}

The weakening is proportional to the number of Boolean expressions flowing into the branch point, how many components the expressions are distributed across, and whether coverage analysis is performed with fully integrated components or stand-alone components.

欠点

E(outcome)

A

D

True

False

－

False

E

A

B

C

D

True

－

True

False

－

False

(19)

“literal”を推奨する理由

• DC,MC/DCのDecisionには“literal“定義を推奨する

The certification authorities recommend the "literal" definition of decision for DC and

MC/DC.

• ブランチポイントにあろうとなかろうと、レベル

A,Bのソフトウェアでは論理演

算と制御構造がくまなく実行されるべきである

The logic and control structure in Levels A and B software must be thoroughly

exercised, whether it occurs at a branch point or not.

• DecisionとBranch Pointを同等にすることは、レベルA,Bのソフトウェアにコン

ポーネントのコード制御構造の外側における

Boolean式のコード化を招く。

To equate decision and branch point could allow Levels A and B software to be coded

with all Boolean expressions outside of the components’ code-control constructs.

(20)

DO-178Bでは代替手段を認めている

• DCの代わりにBranch Coverageを使用することを提案している製造者がいる

some manufacturers have proposed branch coverage as an alternative to decision

coverage (not for MC/DC).

• 代替方法のアプリケーションはそれぞれ評価されるために少し違うニュアン

スをもっている

Each application of an alternative means have slightly different nuances to be

evaluated.

• Decision Coverageの代わりにBranch Coverageが提案される場合、考慮すべ

き典型的な事項がある

Some typical things to consider if branch coverage is proposed as an alternate means

for decision coverage are listed below.

(21)

代替手段に必要なこと（1/2）

• 要求からテストケースを生成すべき

The developer should generate the test cases from the requirements.

• 正しい変数の使用法と、すべてのソフトウェア要求が論理演算子で表される

Boolean演算子が正しいことを確かめるために、正常範囲とロバストネスなテ

ストケースを使用すべき

The developer should use normal range and robustness test cases to verify the correct variable usage and Boolean operators for all software requirements expressed by logical expressions (per 6.4.2.1d of DO- 178B/ED-12B).

• 正しい

Loop演算と正しい論理判定を確かめるべき

The developer should verify correct loop operations and correct logic decisions (per 6.4.3 of DO-178B/ED-12B).

• 代替手段が乱用されないことを確かめるためのプロセスとスタンダードを確

立、施行すべき

The developer should establish and enforce standards and processes to make sure that the alternative method or means is not being abused (i.e., using Boolean expressions outside of the components’ code-control constructs to reduce the structural coverage effort).

(22)

代替手段に必要なこと（2/2）

• 設計者とプログラマが確認テストや構造カバレッジ解析の努力を減らすため

にコンポーネントのコード制御構造の外側で故意または一貫して

_Boolean式

を使用しないことを保証するために、スタンダードが確立されるべきで、レ

ビューが実行されるべき

Standards should be established and reviews should be performed to ensure that the designer and/or programmer (either human or machine) is not intentionally nor consistently using Boolean

expressions outside of the components’ code-control constructs to reduce the verification testing and structural coverage analysis efforts (i.e., abusing the relaxation).

• 代替手段が充分でない場合は、

追加のテストや構造カバレッジ解析を実行

すべき

The developer should perform additional testing and structural coverage analysis, if the alternative method or means is not adequate (i.e., additional test cases and manual structural coverage analysis may be needed to address specific instances of violations discovered within the code).

(23)

• MC/DCの定義が変更された。DO-178BのMC/DCの解釈（ユニー

クコーズ

MC/DC）ばかりでなく、マスキングMC/DCとショートサー

キットが許可された。

（

_{The “Modified Condition/Decision Coverage”(MC/DC) definition}

changed. Masking MC/DC and Short Circuit, as well as DO-178B’s

interpretation of MC/DC (often termed Unique-Cause MC/DC), are now

allowed (see Glossary).）

DO-178C Glossary Modified condition/decision coverageに、以下の

一文が追加されている

• A condition is shown to independently affect a decision’s outcome

by: (1) varying just that condition while holding fixed all other

possible conditions, or (2) varying just that condition while holding

fixed all other possible conditions that could affect the outcome.

DO-178CではMC/DCの定義が追加

マスキングMC/DCについて

DO-178C では、

(24)

DO-248でも、MC/DCは以下によって達成されるべきと記載されている

• 可能な他のConditionをすべて固定して保持し、Conditionの値

を変えること（ユニークコーズ

MC/DCとして知られている）

• 結果に影響する可能な他のConditionをすべて固定して保持し、

Conditionの値を変えること（マスキングMC/DC、ショートサー

キット

_{MC/DCとして知られている）}

Modified Condition/Decision Coverage may be accomplished by:

• Varying just that condition while holding fixed all other possible

conditions (known as unique cause MC/DC), or by

• Varying just that condition while holding fixed all other possible

conditions that could affect the outcome (known as masking MC/DC

and short-circuit MC/DC).

DO-248BでのMC/DCの定義

(25)

Z = ( A or B ) and ( C or D )

“literal”な定義のDecisionの場合（1/3）

MC/DCケーススタディ

#

Z

A

B AorB C

D CorD

1 F

F

2 F

F

T

3 F

F

T

F

T

4 F

F

T

5 F

F

T

F

6 T

F

T

F

T

7 T

F

T

F

T

8 T

F

T

9 F

T

F

T

F

10 T

T

F

T

F

T

11 T

T

F

T

F

T

12 T

T

F

T

13 F

T

F

14 T

T

F

T

15 T

T

F

T

16 T

T

C=True, D=Trueのとき、

C, DはC or D（”literal”な定義のDecision）

の結果に独立的に影響しない

orのConditionが

True, Trueの組み合わせは必要ない

A or B

A

B

False

True

False

True

False

True

MC/DCの定義

DecisionをLiteralな定義とするなら、Decisionは３つあるため、

(26)

Z = ( A or B ) and ( C or D )

“literal”な定義のDecisionの場合（2/3）

#

Z

A

B AorB C

D CorD

1 F

F

2 F

F

T

3 F

F

T

F

T

4 F

F

T

5 F

F

T

F

6 T

F

T

F

T

7 T

F

T

F

T

8 T

F

T

9 F

T

F

T

F

10 T

T

F

T

F

T

11 T

T

F

T

F

T

12 T

T

F

T

13 F

T

F

14 T

T

F

T

15 T

T

F

T

16 T

T

A and B A B False False False

False False True

False True False True True True

A or B A B

False False False True False True

True True False True True True

OrはTrue, True以外、

and はFalse, False以外を

それぞれの

Conditionに適用する

それぞれの

_{Decisionの結果に影響するConditionに限定させる}

ために、全ての

DecisionにMC/DC

の定義を使用する

(27)

MC/DCケーススタディ

#

Z A B AorB C D CorD

2 F

F

F T

T

5 F F

T

F

6 T F

T

F

T

9 F T

F

T

F

10 T

T

F

T

F T

T

11 T T

F

T

F

T

#

Z

A

B AorB C

D CorD

1 F F F F F F F

2 F

F

T

3 F

F

T

F

T

4 F F F F T T T

5 F

F

T

F

6 T

F

T

F

T

7 T

F

T

F

T

8 T F T T T T T

9 F

T

F

T

F

10 T

T

F

T

F

T

11 T

T

F

T

F

T

12 T T F T T T T 13 F T T T F F F 14 T T T T F T T 15 T T T T T F T 16 T T T T T T T

 すべてのDecision（=Z、AorB、CorD）が

T/Fをとっている

 すべてのCondition（=A,B,C,D）が

T/Fをとっている

 ConditionのT/FがDecisionの結果に

独立的に影響している

“literal”な定義のDecisionの場合（3/3）

(28)

ユニークコーズ

MC/DCでは、

ひとつの組み合わせにおいて

、

Decisionの結果が変化す

る

1つのConditionの値だけを変化させることができる（他の全てのConditionは固定さ

せてなければならない）。

In the unique-cause approach, only the values of the condition of interest and the decision’s outcome can change between the two test cases in an independence pair –everything else must remain the same.

MC/DCケーススタディ

#

Z A B AorB C D CorD

2 F

F

F T

T

5 F F

T

F

6 T F

T

F

T

7 T F

T

F

T

10 T

T

F

T

F T

T

#

Z

A

B AorB C

D CorD

1 F F F F F F F

2 F

F

T

3 F

F

T

F

T

4 F F F F T T T

5 F

F

T

F

6 T

F

T

F

T

7 T

F

T

F

T

8 T F T T T T T

9 F

T

F

T

F

10 T

T

F

T

F

T

11 T

T

F

T

F

T

12 T T F T T T T 13 F T T T F F F 14 T T T T F T T 15 T T T T T F T 16 T T T T T T T  すべてのDecision（=Z、AorB、CorD）が T/Fをとっている  すべてのCondition（=A,B,C,D）が T/Fをとっている  ConditionのT/FがDecisionの結果に独立的に影響している  組み合わせがユニークになっている

ユニークコーズMC/DC

Cの組み合わせで#9,#11をとってしまうと、

#9,#10でDの組み合わせができてしまう

参考:CAST-06

(29)

マスキング

MC/DCでは、独立したペアの中で、関心のあるConditionが、

Decisionの結果の値に影響する唯一のConditionだと示される限り、

１つ以上

の入力を変えることを許している

The masking approach to MC/DC allows more than one input to change in an

independence pair, as long as the condition of interest is shown to be the only condition that affects the value of the decision outcome.

Z = ( A or B ) and ( C or D )

#

Z

A B C D

2 F

F

F T

5 F

F T

F

6 T

F

T

F

T

7 T

F

T

F

10 T

T

F

F T

マスキングMC/DCケーススタディ

# Z A B A or B C D C or D 2 F F F F F T T 10 T T F T F T T 2 F F F F F T T 11 T T F T T F T 3 F F F F T F T 10 T T F T F T T 3 F F F F T F T 11 T T F T T F T For A

Y（CorD）がTrueであれば、Aの値によって

結果

(Z)に影響することがわかるため、Aの

他に

_{C,Dの値を変えている}

Aに着目した時、BがFalseであれば

Aの値がXに独立的に影響する

さらに、

YがTrueであれば

（

C, Dの値は問わない）

Aの値がZに独立的に影響する

A

B

C

D

Z

X

Y＝True

B＝False

Y

参考:CAST-06

(30)

Z = (A and B) or (A and C)

1つのDecisionにある

それぞれの

Condition

は

Decisionの結果に独立

的に影響することをあらわしている（

MC/DCの定義）

AがDecisionの結果に独立的に影響するテストケースを探す。

→#4、#8では、左（ひとつめ）のAが結果に影響したのか、

右（ふたつめ）の

_{Aが結果に影響したのかがわからない}

Coupled Condition

Coupled Conditionを含むDecision

# Z A B AandB A C AandC 1 F F F F F F F 2 F F F F F T F 3 F F T F F F F 4 F F T F F T F 5 F T F F T F F 6 T T F F T T T 7 T T T T T F F 8 T T T T T T T

１つのDecisionで同じConditionが2回以上現れたら、

それらは別のCondition（Distinct Condition）とする（Decisionの定義）

(31)

http://www.masc.co.jp 31

-Z = (A and B) or (A and C)

• １つのDecisionで１つのConditionが1回より多く現れたら、それぞ

れの存在はまったく別の

Conditionである（Decisionの定義より）

• ひとつめのAに着目したとき、他のCondition（ふたつめのA)を固

定して結果が変化する組み合わせができない

Coupled Conditionを含むDecisionのユニークコーズMC/DC

Coupled Conditionを含むDecision

# Z A B A C 1 F F F F F 2 F F F F T 3 F F F T F 4 T F F T T 5 F F T F F 6 F F T F T 7 F F T T F 8 T F T T T 9 F T F F F 10 F T F F T 11 F T F T F 12 T T F T T 13 T T T F F 14 T T T F T 15 T T T T F

<<参考>>

# Z A B A C 6 F F T F T 14 T T T F T 7 F F T T F 15 T T T T F

どちらの組み合わせも

１つめのAと２つめのAが

矛盾してしまう

For A

他の全てのConditionを固定しなければならない

ユニークコーズMC/DCでは解決することができない

が、

マスキングMC/DCで解決できる

(32)

DO-178関連文書での定義

#

Z

A B

A

C

6 F

F

T

F

T

11 F

T

F

T

F

12 T

T

F

T

15 T

T

F

Z = (A and B) or (A and C)

• ひとつめのAに着目したとき、（A and C）の結果がFalseである限り

AとCは結果に影響しないので、他のCondition（ふたつめのA）を

固定して結果が変化する組み合わせができる

Coupled Conditionを含むDecisionのマスキングMC/DC

#

Z

A

B A and B A C A and C

6 F

F

T

F

T

F

14 T

T

F

T

F

6 F

F

T

F

T

F

15 T

T

F

7 F

F

T

F

T

F

14 T

T

F

T

F

7 F

F

T

F

T

F

15 T

T

F

For A

１つめのAと２つめのAが矛盾しない

組み合わせを選ぶことができる

4通りのテストケースでMC/DC100％が得られる

(33)

• マスキングMC/DCもユニークコーズMC/DCと同様に、これらの意図の３つを

すべて満たしている。

Masking MC/DC, as well as unique-cause MC/DC, satisfies all three of these “intents”. Structural coverage analysis complements requirements-based tests by:

1. “適切なソフトウェアレベルに対し必要とされた度合で、コード構造が妥当である”というエビデンスを提供すること（Providing “evidence that the code structure was verified to the degree required for the applicable software level”;）

2. “意図された機能の欠乏の論証をサポートする方法”を提供すること（Providing “a means to support demonstration of absence of intended functions”; ）and

3. “要求ベーステストの徹底”を確立すること（Establishing “the thoroughness of requirements-based testing”.）

（RTCA/DO-248A SC-190/WG-52, FAQ #43）

• マスキングもユニークコーズも共に、Decisionにある論理演算子の最小のテ

ストを提供する。

Both the unique-cause and masking approaches to MC/DC provide the same minimum tests of a logical operator in a decision.

• 最小のテストはそれぞれのConditionが独立してDecisionの結果に影響する

ことを裏付ける

These minimum tests confirm that each condition independently affects the decision’s outcome.