개발자와 프로그래머도 알았으면 하는 것들.

테스트 디자인 기술자를 내버려두면 절대 잘 되지 않으니 가능한 한 개발 디자이너와 프로그래머에게 알고 싶은 것을 간결하게 설명해 주세요.
원인 결과 도표법와 시험을 볼 때의 사고방식을 줄이다는 테스트를 줄일 때의'사고방식'이 같다.
이 때문에 한 책의 원인 결과 그래프를 설명한 장에는'이 방법으로 생성된 테스트 사례 중 MCC 커버율은 100%'라고 기재돼 있지만, 그건 좀 불친절하고 단순하지도 않은 말이다.
테스트 디자인에서 의사결정표를 압축할 때 설치 측 조건의 처리 순서와 일치해야 한다는 것을 회상해 보자.
원인 결과 도표법도 마찬가지다.따라서 "설치 측과 일치하는 방식으로 도표를 제작하면 생성된 테스트 상황에서 MC/DC 범위는 100%가 됩니다."나는 이런 표현이야말로 적절하다고 생각한다.
디자인표의 압축과 마찬가지로 테스트 디자인과 개발 디자인, 실장 분야의 협력이 없어서는 안 된다는 점을 이해해 주시기 바랍니다.
그리고 번거로운 일이라고 생각하지 마세요.이 통합과 심사 과정을 확인해야만 테스트보다 품질을 향상시키는 데 기여할 수 있다.실장측과 검증측의 입장이 다른 사람들 사이에서 오류가 발생하기 쉬운 요점을 서로 확인하기 때문에 오류를 방지하는 데 효과가 있을 수밖에 없다.

어떻게 도표와 실제 부호를 일치시킬 것인가

그렇다면'실장방과 어울리도록 도표를 만들면 좋겠다'는 것은 어떻게 된 것일까. 다음 사례를 생각해 보자.
설치 코드 예 1

if (16 <= age) or (12 <= age and parentalConsent):
    print("ワクチン接種できます")
else:
    print("ワクチン接種できません)

다른 언어도 가능하지만 무엇을 선택해야 하는지 설명하기 위해 파이톤을 선택했다.age에서 대상의 나이,parental Consient에 부모의 동의가 있는지 여부는 볼치로 들어간다.
이걸 설치하고 원인 결과 그래프를 만들면 어떨까요?
방법으로는 "참석자의 나이가 16세 이상이면 백신을 접종할 수 있다"며 "또 12세 이상이면 보호자의 동의가 있으면 백신을 접종할 수 있다"고 말했다.이런 정보가 있는 물건으로 도표를 그려 보세요.
우선, 아래와 같이 명제 표현으로 바꾼다.
P1
참관자 연령이 16세 이상이다
P2
참관자 연령이 12세 이상이다
P3
참관자 학부모의 동의가 있다
이 명제를 이용하여 만든 도표는 아래와 같다.MC/DC(Modified Condition/Decision Coverage)의 경우를 사용하여 생성합니다.
CEGTool
최대한 간결하게 하려고 하기 때문에 백신을 접종할 수 있는 사람만 노드명을 논리적인'P1 훅(P2 τP3)'으로 표시한다.
물론 명제 표현을 수정하는 방법도 그렇고 도표의 모양도 그렇고 다른 것을 고려하는 사람도 있을 텐데, "여기서 보여준 것을 만드는 것이 가능할 것 같다"고 생각한다면 앞으로의 설명은 이해할 수 있을 것이다.
도구로 생성된 의사결정표는 #1~#3 세 가지 테스트 용례를 보여 줍니다.이렇게 하면 MC/DC 커버율이 100%에 이를 수 있습니까?
사실상 달성할 수 없는 사례다.왜냐하면, 실제 장비와 일치하는 도표가 그려지지 않았기 때문이다.
나는 이 도표가 비교적 직접적이라고 생각한다. 자세히 보면 논리적 축적 P2∧P3의 결과를 참조하여 그와 P1의 논리를 합쳐서 결과를 도출한다.
즉, 도표와 일치하는 설치는 처음에 표시된 것과 달리 다음과 같은 코드이다.
설치 코드 예 2

if (12 <= age and parentalConsent) or (16 <= age):
    print("ワクチン接種できます")
else:
    print("ワクチン接種できません)

나는 아래의 흐름도를 보면 더욱 이해하기 쉽다고 생각한다.

여기에 생략도 압축도 없는 결정표는 다음과 같다.위 프로세스가 통과하는 경로의 화살표는 색상이 있지만 Desion 테이블의 공백은 같은 색상입니다.또한 CEGtool에서 생성한 테스트 용례의 번호는 맨 위에 기재되어 있습니다.

이것을 보시면 #1~#3의 세 가지 테스트 용례 중 모든 색의 화살표를 통해 MC/DC 커버가 100% 달성되었음을 알 수 있습니다.
이렇게 하면 문제가 해결된다.최초의'실크 코드 예 1'을 멈추고 뒤에 표시된 도표와 일치하는'실크 코드 예 2'로 바꾸면 된다.

이전의 설명과 반대로 도표를 실제 설치에 맞추면

하지만 받아들일 수 없는 사람도 있을 것 같다.
"16세 이상은 많을 텐데 최초 설치 효율이 더 좋지 않나요?"그렇게 생각하는 사람도 있겠지.(글쎄, 이 사례는 그렇게 어색하지는 않겠지만, 실제 작업에서도 어색해야 할 상황이 나타날 것이다.)
그러면 이번에 우리는 도표를 첫 번째'실크 코드 예시 1'과 일치시키는 것을 거꾸로 고려했다.즉, 흐름도는 다음과 같다.

P1의 결과를 보고 논리적 축적을 얻으면 된다.즉 도표는 P1의 결과를 참조하여 다음과 같이 수정할 수 있다.

이에 대해 생략과 압축이 없는 결정표는 다음과 같다.마찬가지로 위 절차를 통과하는 경로 화살표는 색상이 있고 Desion 테이블에 해당하는 공백은 같은 색상이 있습니다.또한 CEGtool에서 생성한 테스트 용례의 번호는 맨 위에 기재되어 있습니다.

이번 CEGTEST에서 생성된 테스트 사례는 4개로 MC/DC 커버율이 100%에 이르렀음을 확인할 수 있다.

쓸데없는 표현은 잘 고려한 후에 방침을 결정해야 한다

그러나 이전 프로그램의 표현이 도표 표현에 지나치게 부합되면 다른 문제가 발생할 수 있다.
앞서 언급한'P1격(P1∧P3)'의 골동품 P1 부분을 다시 실장에 담으려면 불필요한 표현이 된다(통합이 됐으니 위의 기술을 반복해야 한다).
주식회사 DENSO의 시모토 수미가 소프트웨어 품질 세미나 2015에 보고한 그림5의 불필요한 논리 사례를 토대로 한 결과다.
이렇게 되면 가독성을 높이는 경우와 불필요한 표현이 있어 MC/DC 커버를 방해할 수 있다.
논리적 통합, 처리(행동거지)적 통합, 표현적 통합은 앞에서 보듯이 조금씩 다르다.이를 충분히 이해한 바탕에 코딩 규약 등을 결합해 사전에 일치된 방침을 정하는 것이 좋다.
이해하기 쉽도록 불필요한 표현을 리뷰로 출력한다는 방침도 있다.
같은 일이지만 열거한 사례 중 1행을 다음과 같이 기술하는 것도 고려할 만하다.
설치 코드 예 3

if (16 <= age) or (12 <= age and age < 16 and parentalConsent):

더 나아가 말하면 다음과 같이 기술할 수도 있다.
설치 코드 예 4

if (12 <= age and age < 16 and parentalConsent) or (16 <= age) :

MC/DC 커버로 인해 이 변경이 어떤 영향을 미칠지 고민해보면 좀 더 이해가 깊어질 것 같습니다.

추가: 논리식과 프로그램의 조건식이 다르다

논리적인 교환율(commutative law)로서 성립된 것이기 때문에 P1 갈고리(P2τP3)와 (P2τP3) 갈고리 P1은 같아야 하지만 프로그래밍 언어의 처리 시스템이 반드시 이런 것은 아니다.계산이 필요 없을 수도 있어요.
초보자를 제외하고 프로그래머들은 모두 이 일을 알고 있다. 일반적으로 말하면 알았다고는 말할 것도 없고 이 일을 이용한 코드도 쓸 줄 안다.
그러나 다른 한편에서는 상담과 교육 측면에서 이뤄지는 곳마다 이번처럼 설명하면 괄호(雘號)로 묶으면 그 부분을 먼저 계산해내는 사람을 자주 만난다.
넷째, 연산에서 곱셈과 나누는 연산자가 가감 연산자보다 우선순위가 높고, 괄호()에서 우선순위를 명확히 할 수 있으며, 심지어는 ()에서 먼저 계산하는 것이 좋다는 등 가르친 지식이 방해가 된다.(참고로 프로그래밍 언어에서 and는 우선순위가 높은 연산자로 포지셔닝되었지만 논리식에 특별한 규정이 없다.)
주의해야 할 것은 괄호()는 합병의 우선순위(강도)를 표시하는 것이지 시간적으로 먼저 평가(계산)를 요구하는 것이 아니다.
Python 3이면 다음 입력을 통해 기술한 왼쪽부터 처리할 수 있습니다.

$ python
Python 3.8.5 (default, Sep  4 2020, 07:30:14)
[GCC 7.3.0] :: Anaconda, Inc. on linux
>>> age=16
>>> (16 <= age) or (12 <= age and parentalConsent)
True
>>> (12 <= age and parentalConsent) or (16 <= age)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'parentalConsent' is not defined
>>> age=10
>>> (16 <= age) or (12 <= age and parentalConsent)
False
>>> (12 <= age and parentalConsent)or(16 <= age)
False
>>> age=12
>>> (16 <= age) or (12 <= age and parentalConsent)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'parentalConsent' is not defined
>>> (12 <= age and parentalConsent)or(16 <= age)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'parentalConsent' is not defined
>>>

즉, parental Consient를 의도적으로 정의되지 않은 상태로 만든 것입니다.parental Consient를 참조하기 전에 결과를 확정하는 계산이 완료되면 오류가 발생하지 않기 때문에 어디에서 먼저 계산했는지 알 수 있습니다.