자동화 된 단위 테스트, 통합 테스트 또는 승인 테스트 [닫기]

TDD와 단위 테스트는 현재 큰 격찬으로 보입니다. 그러나 다른 형태의 자동 테스트와 비교할 때 정말 유용합니까?

직관적으로 자동화 통합 테스트가 단위 테스트보다 훨씬 유용하다고 생각합니다. 내 경험상 가장 많은 버그는 모듈 간의 상호 작용에 있으며 각 장치의 실제 (일반적으로 제한적) 논리는 아닙니다. 또한 모듈 간의 인터페이스가 변경되어 사전 및 사후 조건이 변경되어 회귀가 자주 발생했습니다.

내가 잘못 이해하고 있거나 통합 테스트에 비해 왜 단위 테스트가 많은 관심을 받고 있습니까? 통합 테스팅은 여러분이 가지고 있다고 가정하기 때문입니다. 단위 테스팅은 개발자로서 적용하기 위해 배워야 할 다음 것입니까?

아니면 단위 테스트가 단순히 자동화의 복잡성과 비교하여 가장 높은 이득을 얻는 것일까 요?

자동화 된 단위 테스트, 자동화 된 통합 테스트 및 자동화 된 승인 테스트에 대한 경험은 무엇이며 경험상 ROI가 가장 높은 것은 무엇입니까? 그리고 왜?

다음 프로젝트에서 자동화하기 위해 한 가지 형태의 테스트 만 선택해야한다면 어떤 것입니까?

미리 감사드립니다.

단위 테스트를 매우 유용하게 만드는 중요한 요소 중 하나는 빠른 피드백 입니다.

앱이 통합 / 시스템 / 기능 테스트 (대부분의 개발 상점에서 현실과는 거리가 먼 이상적인 상황)로 완전히 커버 될 때 발생하는 상황을 고려하십시오. 이들은 종종 전담 테스트 팀이 운영합니다.

• SCM 리포지토리에 변경 사항을 적용하면
• 언젠가 (아마 며칠 후) 테스트 담당자는 새로운 내부 릴리스를 받고 테스트를 시작합니다.
• 그들은 버그를 발견하고 버그 보고서를 제출합니다.
• (이상적인 경우) 누군가가 버그 보고서를 다시 할당합니다.

이 작업에는 며칠 또는 몇 주가 걸릴 수 있습니다. 지금까지는 이미 다른 작업을 수행하고 있으므로 미리 작성된 코드에 대한 세부 정보가 없습니다. 또한 일반적으로 버그의 실제 위치에 대한 직접적인 증거조차 없으므로 버그를 찾아 수정하는 데 상당한 시간이 걸립니다.

단위 테스트 (TDD)

• 당신은 테스트를 작성
• 테스트를 만족시키기 위해 코드를 작성합니다.
• 테스트는 여전히 실패합니다.
• 코드를보고 일반적으로 몇 초 안에 "oops"경험이 있습니다 (예 : "oops, 해당 조건을 확인하는 것을 잊어 버렸습니다!").
• 즉시 버그를 수정하십시오.

이 모든 것은 몇 분 안에 일어난다 .

통합 / 시스템 테스트가 유용하지 않다는 것은 아닙니다. 그들은 단지 다른 목적을 수행합니다. 잘 작성된 단위 테스트 를 사용하면 통합 단계에 도달 하기 전에 코드에서 버그의 상당 부분 을 발견 할 수 있습니다. 여기서 버그 를 찾아 수정하는 데 훨씬 더 많은 비용이 듭니다. 단위 테스트로는 잡기가 어렵거나 불가능한 이러한 유형의 버그를 잡으려면 통합 테스트가 필요합니다. 그러나 내 경험상 그것들은 좀 더 드물다. 내가 본 대부분의 버그는 메소드 내부의 어딘가에 단순하거나 사소한 누락으로 인해 발생합니다.

또한 단위 테스트는 인터페이스의 유용성 / 안전성 등을 테스트하므로 설계 및 API를 개선하는 데 매우 중요한 피드백을 제공합니다. 어떤 IMHO가 모듈 / 서브 시스템 통합 버그의 가능성을 상당히 줄일 수 있는가 : API가 더 쉽고 깨끗할수록 오해 나 누락의 가능성이 줄어 듭니다.

자동화 된 단위 테스트, 자동화 된 통합 테스트 및 자동화 된 승인 테스트에 대한 경험은 무엇이며 경험상 ROI가 가장 높은 것은 무엇입니까? 그리고 왜?

ROI는 많은 요인에 따라 결정되며, 그 중 가장 중요한 것은 프로젝트가 그린 필드인지 레거시인지에 달려 있습니다. 그린 필드 개발을 통해 저의 조언 (그리고 지금까지 경험)은 처음부터 TDD 스타일을 단위 테스트하는 것입니다. 이 경우 가장 비용 효율적인 방법이라고 확신합니다.

그러나 레거시 프로젝트에서 충분한 단위 테스트 적용 범위를 구축하는 것은 큰 과제이며 혜택을 얻는 데 매우 느립니다. 가능한 경우 UI를 통해 시스템 / 기능 테스트를 통해 가장 중요한 기능을 다루는 것이 더 효율적입니다. 자동화 된 테스트 지원 도구가 점차 향상되고 있지만 데스크톱 GUI 앱은 GUI를 통해 자동 테스트하기가 어려울 수 있습니다. 이는 조잡하지만 효과적인 안전망을 신속하게 제공합니다. 그런 다음 앱의 가장 중요한 부분에 대해 단위 테스트를 점차적으로 구축 할 수 있습니다.

다음 프로젝트에서 자동화를 위해 한 가지 형태의 테스트 만 골라야한다면 어떤 것입니까?

그것은 이론적 인 질문이며 무의미합니다. 모든 종류의 테스트는 우수한 SW 엔지니어의 도구 상자에서 사용되며, 대체 할 수없는 시나리오가 있습니다.

모든 유형의 테스트는 매우 중요하며 시스템의 다른 측면이 사양에 맞는지 확인하십시오. 따라서 한 가지 유형의 테스트를 선택해야한다면 ... 단위 테스트는 개인의 통합 테스트 또는 대화식 테스트와는 다른 피드백을 제공합니다.

테스트의 유형 / 이점은 다음과 같습니다.

• 장치 테스트-장치가 예상대로 작업을 수행하고 있는지 확인합니다. 모든 인터페이스에 대해 공급자 및 소비자 계약을 테스트하며 자동화하기가 매우 쉽습니다. 경계 조건 등도 확인합니다.
• 통합 테스트-장치가 함께 작동하는지 확인합니다. 이것은 주로 디자인을 테스트하기위한 것입니다. 여기서 문제가 발생하면 단위 테스트를 조정하여 다시 발생하지 않도록해야합니다.
• 시스템 테스트-시스템이 요구 사항 / 사양을 충족하는지 확인합니다. 일반적으로 사람들은 이러한 유형의 테스트를 수행합니다.
• 승인 테스트-고객은 최종 제품이 광고 된 내용을 수행하는지 확인하기 위해이를 수행합니다.

선택적이지만 권장되는 테스트 :

• 사용자 경험 테스트 : 시스템 테스트에서 적절한 피드백을받는 동안 클라이언트의 사람들이 특정 시험판을 미리 보는 것은 너무 늦기 전에 변경해야하는지 여부를 결정하는 데 실제로 도움이 될 수 있습니다.

단위 테스팅이 통합 테스팅보다 유리한 이유를 이해하기 위해서는 포괄적이어야하는 추가 테스트의 순서를 이해해야합니다. 유닛 A에 대한 모든 가능한 결과에 대해 테스트가 필요합니다. 유닛 B의 경우와 동일합니다. 이제 두 솔루션이보다 완벽한 솔루션을 위해 함께 작동하는 경우 여러 테스트가 조합됩니다. 즉, 단위 A와 단위 B 사이의 모든 상호 작용 순열을 테스트하려면 A * B 테스트가 필요합니다. 단위 C를 추가하면 트리오에 대한 테스트 수는 A * B * C입니다.

인터페이스와 객체 경계의 개념이 매우 중요합니다. 인터페이스는 특정 계약을 나타냅니다. 인터페이스 의 구현 자는 특정 방식으로 작동한다는 데 동의합니다. 마찬가지로 인터페이스 소비자 는 특정 방식으로 구현을 사용한다는 데 동의합니다. 인터페이스를 구현하는 모든 클래스를 수집하는 테스트를 작성하면 각 구현이 인터페이스 계약을 준수하는지 쉽게 테스트 할 수 있습니다. 그것은 방정식의 절반입니다. 나머지 절반은 모의 객체가 재생되는 소비자 측을 테스트하는 것입니다. 모의는 상호 작용이 항상 사양에 맞게 구성됩니다. 이 시점에서 필요한 것은 구현 자 / 소비자 계약이 올바른지 확인하기위한 몇 가지 통합 테스트입니다.

목표가 다른 도구는 다음과 같습니다.

• 단위 테스트는 설계 도구 (TDD)이며 리팩토링을위한 거의 전제 조건입니다.

• 통합 테스트는 프로젝트의 진행 상황을 시각화하고 회귀 버그를 피하는 데 좋습니다.

기억해야 할 점은 실제로 통합 테스트로 설계 할 수 없으며 단위 테스트로 회귀를 찾을 수 없다는 것입니다.

나는 위생 검사를 위해 셀레늄을 광범위하게 사용 했습니다.

대규모 웹 출판 회사에서 새로운 릴리스가 출시되면 일반적으로 테스트 스크립트에 따라 모든 사이트 제품군을 방문하고 모든 것이 정상인지 확인하는 데 약 1 ~ 2 시간 정도의 테스터가 필요했습니다. Selenium을 통해 테스트를 자동화하고 여러 시스템과 브라우저에 테스트를 배포 할 수있었습니다. 현재 테스트 스크립트가 실행될 때 자동으로 동일한 작업을 수행하고 예쁜 보고서를 내기 위해서는 약 3 분이 소요됩니다.

셀레늄의 가장 큰 장점은 XUnit, TestNG 또는 MSTest와 같은 단위 테스트 프레임 워크와 연결할 수 있다는 것입니다.

내 경험상, 그것은 매우 귀중한 것이었지만, 이와 같은 설정은 실제로 프로젝트와 팀에 달려 있으므로 ROI는 확실히 달라질 것입니다.

최상의 ROI는 일반적으로 해당 유형의 버그를 찾을 수있는 가장 빠른 테스트입니다.

단위 테스트는 한 가지 방법 또는 하나의 구성 요소에있는 대부분의 버그를 찾아야합니다. 일반적으로 1 분 미만의 총 처리 시간으로 몇 분 안에 수정 될 수있는 버그를 찾습니다. 매우 저렴한 테스트, 매우 저렴한 버그 찾기 및 수정! 이러한 버그로 인해 통합 테스트를 수행 한 경우 다른 버그로 버그가 차단되지 않는다고 가정하면 처리 시간은 하루와 비슷할 수 있습니다 (테스트는 야간에 자주 발생 함). 또한 다른 코드가 초기 버그 코드에 대해 작성되었으므로 더 많은 버그가 발생할 가능성이 있습니다. 또한 모든 재 설계는 더 많은 코드에 영향을 미칩니다. 또한 더 많은 버그를 허용한다는 것은 통합 테스트를 완료하기 전에 더 많은 테스트를 수행해야한다는 것을 의미합니다. 빈약 한 단위 테스트는 종종 길고 번거롭고 비싸다.테스트 통합주기. 단위 테스트를 건너 뛰면 개발 시간이 절반으로 줄어들지 만 테스트 시간은 최소 3-4 배가 걸리고 전체 프로젝트 길이는 두 배가 걸리며 IME를 단위 테스트 한 경우보다 여전히 품질이 떨어집니다.

통합 테스트는 일반적으로 통합 버그를 찾을 수있는 최초의 실제 테스트입니다 (소프트웨어를 작성하기 전에 또는 코드를 테스트하기 전에 검토 프로세스에서 일부 버그를 찾을 수 있음). 마지막 순간에 버그를 수정 (또는 핫픽스!)하는 데 비용이 많이 들기 때문에 소프트웨어를 사용자에게 공개하거나 릴리스하기 전에 이러한 버그를 찾아야합니다. (정의 적으로) 통합하기 위해 여러 개의 작동하는 구성 요소가 필요하기 때문에 수정하기에 더 저렴한 버그를 더 일찍 찾을 수 없습니다. 사소한 오타와 같은 상호 작용하는 부분과 관련이없는 버그를 먼저 해결해야보다 흥미로운 테스트를 시작할 수있을 때 통합 테스트 속도가 느려집니다.

사용자 승인 테스트는 소프트웨어가 고객이 원하는 것을 수행하는지 확인합니다 (고객이 전체적으로 참여 했음에도 불구하고 프로젝트가 끝날 때 기대와 실제 소프트웨어 사이의 큰 차이를 발견 할 위험을 낮추기 위해 매우 비쌉니다) !). 이 테스트 단계에 도달 할 때까지는 최소한 사양과 비교하여 제품의 대부분의 버그가 이미 발견되었다고 생각해야합니다. 사용자 승인 테스트는 사양과 비교하여 버그가 없는지 확인하는 것보다 제품이 고객의 요구에 맞는지 확인하는 것입니다.

한 가지 유형의 테스트 만 자동화하려는 경우 단위 테스트입니다. 통합 테스트는 수동으로 수행 할 수 있으며 수년 동안 많은 주요 회사에서 수행했습니다. 지루하고 오류가 발생하기 쉬운 것은 말할 것도없고 대부분의 프로젝트에서 컴퓨터로 반복해서 수행 할 수있는 작업을 수동으로 수행하는 데 시간이 더 많이 걸리지 만 훨씬 더 비쌉니다. 사용자 승인 테스트는 종종 수동으로 이루어집니다. 사용자는 종종 관심있는 것을 테스트하면서 테스트를 자동화하는 방법을 모릅니다. 단위 테스트는 반드시 자동화되어야합니다. 요청시 몇 초마다 몇 초마다 모든 단위 테스트를 실행할 수 있어야합니다. 인간은 수동 테스트조차도 할 수 없습니다. 단위 테스트는 코드에 포함되어 있으며 코드를 통해 호출하지 않고 (예 : 자동화) 실행할 수 없습니다.

명심해야 할 것은 테스터가 아닌 개발자를위한 포럼이라는 것입니다. 통합 테스팅은 주로 테스터에 의해 구현됩니다. 단위 테스트는 개발자가 구현합니다. 당연히 개발자는 다른 유형의 테스트보다 단위 테스트에 대해 더 많이 이야기합니다. 그렇다고 다른 테스트가 중요하다고 생각하지는 않습니다. 그것은 단지 그들이 실제로하지 않는 것을 의미 할 (이하 자주 할)를.

이 시나리오에서 합격 시험이 왕인 것 같습니다.

커밋이 승인 테스트를 중단하면 정렬해야합니다.

승인 테스트는 소프트웨어가 어디에 있는지, 유닛 테스트는 그렇지 않은지를 알려줍니다.

따라서 단위 테스트는 매우 잘못된 보안 감각을 제공 할 수 있습니다.

문제는 자동화되고 빠르게 실행될 수있는 것만 큼 중요한 것이 아닙니다.

단위 테스트는 작은 구성 요소가 특정 방식으로 목적에 적합하고 일반적으로 작고 빠르게 실행되는지를 보여줍니다. 작기 때문에 일반적으로 자동화하기가 쉽습니다.

통합 테스트는 구성 요소가 함께 작동하는지 여부를 보여줍니다. 그것들은 일반적으로 훨씬 크며 자동화하기 쉽지 않을 수 있습니다. 실행하는 데 시간이 더 걸릴 수 있습니다. 자동으로 실행할 수 있다는 점에서 가치가 있지만 더 큰 작업이므로 어쨌든 자주 실행되지 않습니다.

승인 테스트는 프로젝트의 수용 가능 여부를 보여줍니다. 소스 코드 자체보다 덜 복잡한 공식적인 문제에서 정확하고 완전한 요구 사항을 해결하는 것은 일반적으로 불가능하기 때문에 일반적으로 완전히 자동화하는 것은 불가능합니다 (자동 테스트는 일부 기능을 수행 할 수 있음). 승인 테스트에는 일반적으로 잠재적 인 사용자가 시스템에서 작업을 수행하고 모든 측면에서 결과가 만족 스러운지 관찰하는 것이 포함되며, 이는 일반적으로 부분적인 주관적입니다. 수락 테스트는 일반적으로 한 번만 수행되므로 (다른 고객은 일반적으로 별도의 수락 테스트를 원할 것이므로) 자동화 할 가치가 없습니다.