우리는이 접근법도 사용하고 있습니다. 즉, 주어진 머신에서 정의 된로드 시나리오 하에서 런타임을 측정하는 테스트가 있습니다. 우리는 이것을 일반적인 단위 테스트에 포함시키지 않는다는 것을 지적하는 것이 중요 할 수 있습니다. 단위 테스트는 기본적으로 변경 사항을 커밋하기 전에 개발자 컴퓨터의 각 개발자가 실행합니다. 이것이 성능 테스트에 적합하지 않은 이유는 아래를 참조하십시오 (적어도 우리의 경우). 대신 통합 테스트의 일부로 성능 테스트를 실행합니다.

확인을 배제해서는 안된다는 것을 올바르게 지적했습니다. 우리는 테스트가 작동하지 않는 요구 사항에 대한 테스트라고 가정하지 않습니다. 대신, 우리는 그것을 단지 잠재적 인 문제 지표라고 생각합니다.

나는 당신의 제품에 대해 확신하지 못하지만, 우리의 경우, 성능이 불충분하다면, 그 “고정”에 많은 작업이 필요하다는 것을 의미합니다. 우리가 이것을 QA에 전적으로 맡기는 처리 시간은 끔찍합니다. 또한 성능 수정 사항은 코드 기반의 상당 부분에 심각한 영향을 미쳐 이전 QA 작업이 무효화됩니다. 대체로 매우 비효율적이고 만족스럽지 못한 워크 플로입니다.

다음은 각 문제에 대한 몇 가지 사항입니다.

• 개념적으로 : 이것은 단위 테스트에 관한 것이 아닙니다. 그러나 모든 사람이 알고있는 한, 테스트에서 QA가 수행해야 할 작업을 확인해서는 안된다는 것은 괜찮습니다.

• Visual Studio : VS의 단위 테스트 프레임 워크를 사용하지 않으므로 이에 대해 아무 것도 말할 수 없습니다.

• 기계 : 제품에 따라 다릅니다. 귀사의 제품이 개별 데스크탑 컴퓨터를 사용하여 최종 사용자를 위해 개발 된 제품인 경우에는 실제로 다른 개발자의 컴퓨터에서 테스트를 실행하는 것이 더 현실적입니다. 우리의 경우, 우리는 주어진 사양의 기계를 위해 제품을 제공하고 이러한 기계에서만 이러한 성능 테스트를 수행합니다. 실제로, 클라이언트가 궁극적으로 16 개 이상의 코어를 실행할 때 듀얼 코어 개발자 시스템의 성능을 측정하는 데 별다른 의미가 없습니다.

• TDD : 초기 고장이 일반적이지만 반드시 그럴 필요는 없습니다. 실제로 이러한 테스트를 조기에 작성하면 기존 단위 테스트가 아닌 회귀 테스트의 역할을합니다. 테스트가 일찍 성공한다는 것은 문제가되지 않습니다. 그러나 개발자가 기능을 저하시키는 기능을 추가 할 때마다 비 기능적 성능 요구 사항을 알지 못했기 때문에이 TDD 테스트가이를 발견 할 수 있다는 이점을 얻습니다. 많은 일이 일어나고 멋진 피드백입니다. 일상 업무에서 코드를 작성하고 커밋하고 점심 식사를하고 다시 돌아 왔을 때 빌드 시스템은로드가 많은 환경에서 실행될 때이 코드가 너무 느리다고 알려줍니다. 그것은 TDD 테스트가 처음에 실패하지 않았다는 것을 받아들이기에 충분합니다.

• 런타임 : 언급 한 바와 같이 개발자 시스템에서는 이러한 테스트를 실행하지 않고 일종의 통합 테스트에서 빌드 시스템의 일부로 실행합니다.

답변