저희 회사는 테스트 중심 개발을 시행하려고 노력하고 있으며 개발 매니저로서 그 수용 기준이 실제로 무엇을 의미하는지 정의하려고합니다. 우리는 대부분 민첩한 방법론을 따르고 테스트 할 각 스토리에는 단위 테스트 적용 범위에 대한 일정 수준의 보증 (출입 기준)이 필요합니다. 귀사가 귀사에서 어떻게 게이팅 수준에서 효과적으로 시행하는지에 대해 관심이 있습니다.수량 단위 테스트 커버리지
당신은 이 아니며은 코드 커버리지 요구 사항을 설정하기를 원합니다. 그런 요구 사항은 도박을 당할 수 있고 도박을 당할 수 있습니다.
대신 RTF : Running, Tested Features를 측정 해 보겠습니다. http://xprogramming.com/articles/jatrtsmetric/
Ruby on Rails 앱의 경우 코드 메트릭 젬 SimpleCov을 사용합니다. 회사에서 사용하는 언어가 확실하지 않지만 코드 메트릭이 있다고 확신합니다. SimpleCov는 광범위한 GUI를 제공하기 때문에 Ruby에 적합합니다. 코드가 덮여 있는지, 건너 뛴지 (필터링 됨) 또는 누락되었는지 여부를 강조 표시합니다.
이제 우리는 2 개월 동안 코드 커버리지를 추적하기 시작했습니다. 우리는 30 %에서 시작하여 현재 60 % 가까이에 있습니다. 회사 응용 프로그램의 나이에 따라 서비스 기대치를 80 % 이상으로 높이는 것이 좋습니다. SimpleCov에 따르면 91 % 이상은 "녹색", 80 % 미만은 "빨간색 "(훌륭한 색상 유추를 위해).
필자는 중요한 기능을 테스트했는지 확인하는 것이 좋다고 생각합니다. 이러한 기능에는 테스트 할 코드가 대부분있을 수 있습니다. 이러한 작업을 먼저 수행하면 적용 범위가 크게 확대됩니다.
SimpleCov와 같은 라이브러리를 사용하는 경우 주목할만한 또 다른 사항은 기존 코드라고 생각되는 전체 코드 또는 코드 줄을 건너 뛰거나 필터링 할 수 있습니다. 이것이 우리 보험이 2 개월 만에 거의 두 배가 된 또 다른 이유입니다.
우리는 코드 커버리지를 처음 접했지만 현재의 테스트 제품군 및 응용 프로그램 개발에 대한 이점을 강하게 믿습니다.
여전히 응용 프로그램을 테스트하는 방법을 결정하려고합니까? 아래 답변을 확인할 수 있습니다. – onebree