프로젝트의 % 코드 커버리지는 무엇입니까? 이유가 궁금 해서요.프로젝트의 코드 커버리지 백분율은 얼마입니까?
개발자 팀이 만족하고 있습니까? 그렇지 않다면, 그걸 늘리는 데 방해가되는 것은 무엇입니까?
스튜어트 할로 웨이 (Stuart Halloway)는 100 % 프로젝트를 목표로하는 프로젝트입니다. 그 수준에있는 사람 있습니까?
우리는 고통스러운 25 %이지만 새로운 코드에 대해서는 80-90 %를 갈망합니다. 우리는 증발 할 때 혼자 남겨두기로 결정한 레거시 코드를 가지고 있습니다 (우리는 적극적으로 다시 쓰고 있습니다).
우리는 85 % 코드 커버리지에서 실행되지만 그 아래로 떨어지면 빌드가 손상되지 않습니다. 나는 코드 커버리지를 중요한 척도로 사용하는 것이 위험한 방법이라고 생각한다. 테스트에서 커버 된 것이 커버리지가 좋다고 말하는 것은 아닙니다. 우리는 약점으로 다루어 진 분야에 대한 지침으로 사용하려고 노력합니다.
80 %는 이정표의 종료 기준입니다. 우리가 스프린트를 쓰러 뜨리지 않으면 (비록 우리가 앞에서 계획을 세우더라도) 안정화를 통해 추가합니다. 특정 구성 요소 나 기능에 대해서는 예외가있을 수 있지만 다음 단계를 위해 Pri 1 항목을 엽니 다.
코딩하는 동안 코드 범위가 매일 빌드에서 자동으로 측정되고 보고서가 전체 팀에 전송됩니다. 70 % 미만은 노란색, 50 % 미만은 빨간색입니다. 우리는 현재 빌드를 실패하지는 않지만 다음 단계에 추가 할 계획입니다.
dev 테스트가 단위 테스트와 관련이 있는지 잘 모릅니다. 개발자는 고급 제품을 만들기 위해 고용되며 최소 품질을 측정하고이를 측정 할 수있는 방법이 있어야합니다. 누군가가 프로세스에 만족하지 않는다면 나머지 코드와 통합되기 전에 코드 검증 방법을 자유롭게 제안 할 수 있습니다.
Btw, 우리는 자동 시나리오 테스트에서도 코드 적용 범위를 측정합니다. 따라서 단위, 시나리오 및 결합 된 3 개의 unmbers가 있습니다.
Franci님께 감사드립니다. 재 : 행복, 나는 dev 팀과 경영진 사이의 긴장에 대해 물어 보려고했습니다. 즉, 종종 개발자는 자신의 서비스 범위가 더 높기를 바랍니다. –
@Michael Easter : 경영진이 제품에 대한 더 나은 품질 관리를 요구하는 곳에서 아직 일하고 있지 않습니다. 그리고 나는 그런 곳에서 실제로 일하고 싶지 않을 것입니다. –
자주 자동화 테스트 스위트에서 코드 커버리지를 사용하지만, 주로 테스트되지 않은 영역을 찾아야합니다. 우리는 대부분 70 % 커버리지를 얻으며 두 가지 이유로 100 %를 맞출 수 없습니다.
1) 일반적으로 이후에 새로운 기능 이 자동으로 자동화됩니다.이 릴리즈는 수동 릴리스 테스트이므로 릴리스 분석에 포함되지 않습니다. 자동화는 주로 우리의 경우 기능적 회귀를위한 것이며 코드 범위를 실행하고 조정할 수있는 가장 좋은 장소입니다.
2) 실행 핸들러 내부에 들어가야하기 때문에 오류를 주입해야 100 % 적용 범위를 확보 할 수 있습니다. 이것은 자동화하기 어렵고 시간이 오래 걸립니다. 우리는 현재 이것을하지 않으며 따라서 100 %를 얻지 못할 것입니다. 제임스의 휘태커 즈 (Whittakers) 책 breaking software에 관심있는 사람들에게이 주제를 잘 설명합니다.
SQAforums 이상으로 this 및 this과 같은 스레드에서 정기적으로 논의되는 것처럼 코드 적용 범위가 테스트 적용 범위와 동일하지 않음을 기억해야합니다. 따라서 100 % 코드 커버리지는 잘못된 측정 기준이 될 수 있습니다.
100 % 코드 커버리지는 달성 한 오해의 소지가있는 측정 항목 일뿐입니다. 일단 거기에 있으면 테스트 범위를 더 향상시킬 수 있습니다. – quamrana
감사합니다 smacl과 quamrana ...이 답변은 왜 투표가 종료 되었습니까? –
오신 것을 환영합니다. 아마도 빌드 승인을 위해 코드 커버리지를 사용하지 않을 수도 있습니다. 코드 커버리지는 유용하지만, 테스트 또는 QA 전략의 기초가되는 것은 아닙니다. –
2 세 전에 I measured Perl's test coverage. 250 개의 테스트 케이스가 끝나면 코드의 70 %와 완전히 테스트 된 분기의 33 %에 도달했습니다.
회사 목표는 예외 처리 코드를 포함하여 80 %의 명세서 범위입니다. 개인적으로, 나는 내가 체크인 한 모든 것들에 대해 90 % 이상이되는 것을 좋아한다.
일반적으로 누락 된 20 %는 무엇입니까? 그냥 궁금해서. –
정말 좋은 질문입니다. 나는 다른 사람들의 암호를 말할 수 없다. 자체적으로 다루지 않은 유일한 설명은 사용자가 강제로 넘겨주는 방법이며 주로 로깅 목적으로 사용됩니다. – moffdub
아직 직장에서 슬프게도 0 %입니다. 개선을 목표로 할 것이지만 상사에게 우리가 필요로한다고 말하면서 테스트를 보니 쉽지 않습니다!
re : 보스. 그것은 어려운 판매입니다, Forser. 물론 당신과 나는 테스트가 == 버그를 일찍 잡는다는 것을 알고 있습니다. == 문제를 다루는 데 드는 비용이 적습니다. 그것이 "3-way"방정식이기 때문에, 종종 비 기술과 관련되는 것은 어렵습니다. –
프로젝트 저는 몇 년 전에 100 % 라인 적용 범위를 달성했지만 목표를 집행 할 수 있도록 전체 제어권을 가졌습니다.
이제 우리는 새로운 코드의 50 %를 커버하는 목표를 잡았습니다. 가까운 장래에 증가 할 것으로 보이지만 측정 할 방법은 없습니다. 단위 테스트가 매일 밤마다 실행될 때마다 코드 적용 범위를 측정 할 수있는 도구가 곧 제공 될 예정이므로 Google의 입장이 개선 될 것으로 확신합니다.
re : 적용 범위 보장하지 않습니다. 사실, 이것은 사실입니다. IMO, 회신을 보내 주셔서 감사합니다. –