받아 들여진 대답은 좋은 지적입니다. 모든 프로젝트에 표준으로 적합한 단일 숫자는 없습니다. 그러한 표준이 필요없는 프로젝트가 있습니다. 제 생각에 수용 된 답변이 부족한 부분은 주어진 프로젝트에 대해 어떻게 결정을 내릴 수 있는지 설명하는 것입니다.

그렇게하겠습니다. 저는 테스트 엔지니어링 전문가가 아니며 더 많은 정보에 대한 답변을 보게되어 기쁩니다.

코드 범위 요구 사항을 설정하는시기

첫째, 왜 그러한 표준을 먼저 적용하고 싶습니까? 일반적으로 프로세스에 경험적 신뢰를 도입하려고 할 때. “경험적 확신”이란 ​​무엇입니까? 글쎄, 진짜 목표 정확성 . 대부분의 소프트웨어의 경우 모든 입력에서이를 알 수 없으므로 코드가 잘 테스트 되었다고 말합니다 . 이것은 더 잘 알려져 있지만 여전히 주관적인 표준입니다. 표준을 충족했는지 여부에 대해 항상 논의 할 수 있습니다. 이러한 토론은 유용하고 발생해야하지만 불확실성을 드러냅니다.

코드 적용 범위 는 객관적인 측정입니다. 일단 적용 범위 보고서를 보면 표준을 충족했는지 여부에 대한 모호성이 없습니다. 정확성을 증명합니까? 전혀 그렇지는 않지만 코드가 얼마나 잘 테스트되었는지와 분명한 관계가 있으며, 이는 정확성에 대한 신뢰를 높이는 가장 좋은 방법입니다. 코드 적용 범위는 우리가 관심을 갖는 측정 할 수없는 특성에 대한 측정 가능한 근사치입니다.

경험적 표준이 가치를 추가 할 수있는 몇 가지 구체적인 사례 :

• 이해 관계자 만족 많은 프로젝트의 경우, 소프트웨어 개발에 관여하지 않을 수있는 소프트웨어 품질에 관심이있는 다양한 행위자가 있습니다 (매니저, 기술 책임자 등). 우리가 정말로 필요로하는 시험 “은 설득력이 없습니다 : 그들은 전적으로 신뢰하거나 지속적으로 긴밀한 감독으로 검증해야합니다 (기술적 인 이해가 있다고 가정하더라도).
• 팀 행동을 정상화합니다. 이해 관계자 여러분, 여러 사람이 코드와 테스트를 작성하는 팀에서 일하는 경우 “잘 테스트 된”자격을 갖추기위한 모호성이 있습니다. 모든 동료가 어느 수준의 테스트가 충분한 지에 대한 동일한 아이디어를 가지고 있습니까? 아마 아닙니다. 이것을 어떻게 조정합니까? 모두 동의 할 수있는 측정 항목을 찾고 합리적인 근사값으로 수락하십시오. 예를 들어 리드가 주니어 개발자를 직접 감독하지 않는 대규모 팀에 특히 유용합니다. 신뢰 네트워크도 중요하지만 객관적인 측정이 없으면 모든 사람이 선의로 행동하더라도 그룹 행동이 일관성이 없어지기 쉽습니다.
• 자신을 정직하게 유지하십시오. 프로젝트의 유일한 개발자이자 유일한 이해 관계자 인 경우에도 소프트웨어의 특정 특성을 염두에 둘 수 있습니다. 소프트웨어의 성능에 대해 지속적으로 주관적인 평가를 수행하는 대신 (작업이 필요한) 코드 적용 범위를 합리적인 근사치로 사용하여 기계가이를 대신 할 수 있습니다.

사용할 측정 항목

코드 적용 범위는 단일 메트릭이 아닙니다. 적용 범위를 측정하는 방법에는 여러 가지가 있습니다. 표준을 설정할 수있는 것은 어느 표준을 만족시키기 위해 사용하고 있는지에 따라 다릅니다.

표준을 설정하는 데 사용할 수있는 두 가지 일반적인 측정 항목을 예로 사용하겠습니다.

• 명세서 범위 : 테스트 중에 실행 된 명세서의 몇 퍼센트입니까? 코드 의 실제 적용 범위 를 이해하는 데 유용합니다 . 실제로 작성한 코드의 양은 실제로 테스트 했습니까?
  • 이러한 종류의 적용 범위는 더 약한 정확성 주장을 지원하지만 달성하기도 더 쉽습니다. 방금 확인하기 위해 코드 커버리지를 사용하는 경우 있음 일들이 (그 이상 시험 품질의 지표로하지) 테스트를받을 다음 문 범위 아마 충분합니다.
• 분기 범위 : 분기 논리 (예 🙂 if가있는 경우 두 분기를 모두 평가 했습니까? 이렇게하면 코드 의 논리적 적용 범위 를 더 잘 이해할 수 있습니다. 코드에서 가능한 경로 중 몇 개를 테스트 했습니까?
  • 이러한 종류의 적용 범위는 프로그램이 포괄적 인 입력 세트에서 테스트되었음을 ​​훨씬 더 잘 나타내는 지표입니다. 정확성을 확신하기 위해 코드 적용 범위를 최상의 경험적 근사법으로 사용하는 경우 지점 적용 범위 또는 이와 유사한 기준에 따라 표준을 설정해야합니다.

다른 측정 항목이 있습니다 (줄 적용 범위는 명령문 적용 범위와 유사하지만 예를 들어, 여러 줄 명령문에 대해 다른 숫자 결과를 생성합니다. 조건부 적용 범위 및 경로 적용 범위는 분기 적용 범위와 유사하지만, 프로그램 실행이 발생할 수 있습니다.)

필요한 비율

마지막으로, 원래 질문으로 돌아갑니다. 코드 적용 표준을 설정하면 그 숫자는 무엇입니까?

이 시점에서 우리가 시작할 근사치에 대해 이야기하고 있음을 분명히 알기 때문에 우리가 선택한 숫자는 본질적으로 근사치입니다.

어떤 숫자를 선택할 수 있습니다 :

• 100 % . 모든 것이 테스트되었는지 확인하기 위해 이것을 선택할 수 있습니다. 이것은 테스트 품질에 대한 통찰력을 제공하지는 않지만 일부 품질 테스트가 모든 진술 (또는 지점 등)에 영향을 미쳤다는 것을 다시 말해줍니다. , 당신은 알고 코드의 어떤 부분 집합이 안된 것입니다.
  • 일부는 이것이 어리석은 것이라고 주장 할 수 있으며, 실제로 중요한 코드 부분 만 테스트해야합니다. 코드의 일부만 유지해야한다고 주장합니다. 테스트되지 않은 코드를 제거하여 코드 적용 범위를 향상시킬 수 있습니다.
• 99 % (또는 95 %, 90 년대의 다른 숫자) 100 % 와 비슷한 수준의 신뢰를 전달하고자 하지만 때때로 테스트하기 어려운 코너에 대해 걱정하지 않으려면 약간의 여유를 두십시오. 암호.
• 80 % . 이 숫자를 몇 번 사용하는 것을 보았으며 그것이 어디에서 왔는지 완전히 알지 못합니다. 나는 생각 이 80-20 규칙의 이상한 남용 수 있습니다; 일반적으로 여기서 의도는 대부분 의 코드가 테스트 되었음을 보여주기위한 것입니다 . (예, 51 %는 “가장 많음”이지만 80 %는 대부분의 사람들 이 가장 의미 하는 바를 더 잘 반영 합니다. 이는 “잘 테스트 된”이 우선 순위가 아닌 중간 사례에 적합합니다 ( 낮은 가치의 테스트에 노력을 낭비하고 싶지는 않지만 여전히 표준을 정하고 싶은 우선 순위로 충분합니다.

실제로 80 % 미만의 숫자는 보지 못했고 숫자를 설정할 사례를 상상하기가 어렵습니다. 이러한 표준의 역할은 정확성에 대한 신뢰를 높이는 것이며 80 % 미만의 숫자는 특히 자신감을 불러 일으키지는 않습니다. (예, 이것은 주관적이지만 다시 한 번 표준을 설정할 때 주관적인 선택을 한 다음 앞으로 객관적인 측정을 사용하는 것이 좋습니다.)

기타 노트

위의 내용은 정확성이 목표라고 가정합니다. 코드 범위는 정보 일뿐입니다. 다른 목표와 관련이있을 수 있습니다. 예를 들어, 유지 보수성에 관심이있는 경우 느슨한 결합에 관심이있을 수 있습니다. 느슨한 결합은 테스트 가능성에 의해 입증 될 수 있으며, 코드 커버리지에 의해 (특정 방식으로) 측정 될 수 있습니다. 따라서 코드 커버리지 표준은 “유지 보수성”의 품질을 근사화하기위한 경험적 기초를 제공합니다.

---

답변