자동 테스트의 단점은 무엇입니까?

이 사이트에는 자동화 된 테스트를 통해 얻을 수있는 이점에 대한 많은 정보가있는 여러 가지 질문이 있습니다. 그러나 나는 동전의 다른 쪽을 나타내는 것을 보지 못했습니다. 단점은 무엇입니까? 인생의 모든 것은 트레이드 오프이며은 총알이 없으므로 자동화 된 테스트를 수행하지 않는 몇 가지 정당한 이유가 있어야합니다. 그들은 무엇인가?

내가 생각해 낸 몇 가지가 있습니다.

• 특정 기능에 더 많은 초기 개발자 시간이 필요합니다
• 더 높은 기술 수준의 팀원 필요
• 툴링 요구 증가 (테스트 러너, 프레임 워크 등)
• 시험에 실패한 경우 복잡한 분석이 필요합니다.이 시험은 변경으로 인해 더 이상 사용되지 않습니까, 아니면 실수를 한 것입니까?

편집
나는 자동화 된 테스트의 큰 지지자라고 말해야한다고 확신하지는 않는다. 나는 회사에 가서 사건을 제기 할 때 단점이 무엇인지 이해하려고 노력하고 있습니다. 나는 상상의 은색 총알을 던지는 것처럼 보이지 않습니다.

또한 위의 예에 대해 이의를 제기 할 사람을 찾지 않고 있음을 분명히 합니다. 나는 몇 가지 단점 (모든 것이 상충 관계가 있음) 이 있어야 한다는 것을 사실로 생각하고 있으며 그것이 무엇인지 이해하고 싶습니다.

당신은 가장 중요한 것들을 거의 못 박았습니다. 몇 가지 사소한 추가 사항과 실제로 테스트의 단점이 있습니다. 실제로 원하지 않는 경우 (아래 참조).

• 개발 시간 : 테스트 중심 개발에서는 단위 테스트를 위해 이미 계산되었지만 통합 및 시스템 테스트가 여전히 필요하며 자동화 코드도 필요할 수 있습니다. 한 번 작성된 코드는 일반적으로 여러 단계에서 테스트됩니다.

• 기술 수준 : 물론 도구를 지원해야합니다. 그러나 그것은 당신 자신의 팀만이 아닙니다. 대규모 프로젝트에는 팀의 제품과 다른 제품 간의 인터페이스를 확인하기위한 테스트를 작성하는 별도의 테스트 팀이있을 수 있습니다. 더 많은 사람들이 더 많은 지식을 가져야합니다.

• 툴링 요구 사항 : 현장에 있습니다. 이것에 추가 할 것이 많지 않습니다.

• 실패한 테스트 : 이것은 실제 버거입니다 (어쨌든 저에게는). 여러 가지 다른 이유가 있으며, 그 이유는 각각 단점으로 볼 수 있습니다. 그리고 가장 큰 단점은 이러한 이유 중 어떤 것이 실패한 테스트에 실제로 적용되는지 결정하는 데 필요한 시간입니다.

  • 실제 버그로 인해 실패했습니다. (이것은 물론 유리하기 때문에 완전성을 위해)
  • 테스트 코드가 전통적인 버그로 작성 되었기 때문에 실패했습니다.
  • 테스트 코드가 이전 버전의 제품 용으로 작성되었으며 더 이상 호환되지 않기 때문에 실패했습니다.
  • 요구 사항이 변경되었고 테스트 된 동작이 이제 '정확한'것으로 간주되어 실패했습니다.

• 실패하지 않은 테스트 : 이것 역시 단점이며 상당히 나쁠 수 있습니다. 당신이 일을 바꾸고 아담이 대답 한 것에 가까워 질 때 주로 일어난다. 제품 코드에서 무언가를 변경했지만 테스트에서이를 설명하지 않는 경우이 "가상 보안 감각"을 제공합니다.

  실패하지 않은 테스트의 중요한 측면은 요구 사항 변경으로 인해 이전 동작이 무효화 될 수 있다는 것입니다. 적절한 추적 성을 보유한 경우 요구 사항 변경 사항을 테스트 코드와 일치시킬 수 있어야하며 해당 테스트를 더 이상 신뢰할 수 없습니다. 물론,이 추적 성을 유지하는 것은 또 다른 단점입니다. 당신이하지 않으면, 당신은 실패하지 않는 테스트와 끝까지, 실제로 제품이 작동하는지 확인합니다 잘못 . 길 어딘가에서 이것은 당신에게 타격을 줄 것입니다.

• 추가 배포 비용 : 자신의 컴퓨터에서 개발자로 단위 테스트를 실행하지는 않습니다. 자동화 된 테스트를 사용하면 누군가가 작업을 중단 한시기를 알아 내기 위해 중앙 위치에있는 다른 사람의 커밋에 대해 테스트를 실행하려고합니다. 이것은 좋지만 설정 및 유지 관리해야합니다.

우리 팀에서 자동화 테스트를 시작하기 시작한 가장 큰 단점은 자동화 테스트를 염두에두고 설계되지 않은 레거시 코드에는 적용하기가 매우 어렵다는 것입니다. 의심 할 여지없이 장기적으로 코드를 개선 할 것이지만, 안전성을 유지하면서 자동화 된 테스트에 필요한 리팩토링 수준은 단기적으로 진입하는 데 매우 높은 장벽이므로 자동화 된 도입에 대해 매우 선택적이어야합니다. 단기 약속을 충족시키기위한 단위 테스트. 다시 말해, 이미 기술 부채가 심할 때 신용 카드를 지불하기가 훨씬 더 어렵습니다.

아마도 가장 중요한 단점은 ... 테스트는 생산 코드 입니다. 작성하는 모든 테스트는 유지 관리 및 지원해야하는 코드를 코드베이스에 추가합니다. 그렇게하지 않으면 결과를 믿지 않는 테스트로 이어 지므로 다른 선택의 여지가 없습니다. 내가 틀리지 마라-나는 자동화 된 테스트를 대변하는 사람이다. 그러나 모든 것이 비용이 들며 이것은 큰 것입니다.

나는 이것이 완전히 적용 가능한 단점이라고 말하지는 않지만 가장 많이 타격을받는 것은 다음과 같습니다.

• 복잡한 엔터프라이즈 애플리케이션에서 테스트를 설정하는 데 걸린 시간입니다.
• 잘못 실패한 이전 테스트 처리, 즉 시스템이 발전했으며 이제 테스트가 잘못되었습니다.
• 불완전하거나 알려지지 않은 테스트 범위에 대한 잘못된 확신.

고르지 않은 테스트 범위는 잘못된 보안 감각으로 이어질 수 있습니다. 리팩토링을 수행하고 유효성을 검증하기 위해 테스트를 사용하는 경우 테스트에서이를 증명할 수있는 것으로 입증 된 것은 무엇입니까?

테스트를 만드는 데 걸리는 시간은 때때로 우리에게 문제가됩니다. 자동화 테스트에는 단위 테스트뿐만 아니라 사용 사례 테스트도 포함됩니다. 이것들은 더 넓고 맥락이 필요합니다.

물론 내 관점은 단위 테스트보다 오래된 응용 프로그램에서 비롯됩니다.

나는 그들에게 주된 문제는 그들이 잘못된 보안 감각을 제공 할 수 있다는 것이다 . 단위 테스트가 있다고해서 실제로 작업을 수행 한다는 의미는 아니며 요구 사항을 올바르게 테스트해야합니다.

또한 자동 테스트 에는 버그 자체도 포함될 수 있으므로 단위 테스트 자체 테스트가 필요한지 여부에 대한 의문이 생길 수 있습니다 .

자동화 테스트에는 많은 장점이 있지만 자체 단점도 있습니다. 단점 중 일부는 다음과 같습니다.

• 자동화 테스트 스크립트를 작성하려면 숙련이 필요합니다.
• 테스트 스크립트 디버깅은 중요한 문제입니다. 테스트 스크립트에 오류가 있으면 때로는 치명적인 결과를 초래할 수 있습니다.
• 재생 방법의 경우 테스트 유지 관리 비용이 많이 듭니다. GUI에서 사소한 변경이 발생하더라도 테스트 스크립트를 다시 기록하거나 새 테스트 스크립트로 바꿔야합니다.
• 테스트 스크립트가 더 많은 화면을 테스트하면 테스트 데이터 파일을 유지 관리하기가 어렵습니다.

위의 단점 중 일부는 자동화 된 스크립트를 통해 얻을 수있는 이점에서 종종 제외됩니다. 자동화 테스트에는 장단점이 있지만 전 세계적으로 광범위하게 적용됩니다.

최근 에 게임 개발 테스트에 대한 질문을했습니다. 이것이 BTW입니다. 거기에 대한 답은 호기심이 많고 특정한 단점을 지적했습니다.

1. 코드 를 고도로 결합 해야 할 때 비용이 많이 듭니다 .
2. 다양한 하드웨어 플랫폼을 알고 있어야 할 때, 사용자에 대한 출력을 분석해야하고 코드 결과가 더 넓은 상황에서만 의미가있을 때 수행하기가 어렵습니다 .
3. UI와 UX 테스트는 매우 어렵다 .
4. 특히 자동화 된 테스트는 매우 저렴한 (또는 무료) 베타 테스터보다 비싸고 덜 효과적 일 수 있습니다 .

네 번째 요점은 나의 경험을 기억하게 해줍니다. 단위 테스트가 강력하게 권장되는 XP 기반의 Scrum 관리 회사에서 일했습니다. 그러나 덜 관료적이고 덜 관료적 인 스타일로가는 길에 회사는 QA 팀 구성을 방치했습니다. 테스터는 없었습니다. 고객은 테스트 범위가 95 % 이상인 경우에도 일부 시스템을 사용하여 사소한 버그를 발견했습니다. 그래서 다른 요점을 추가하겠습니다.

• 자동화 된 테스트는 할 수 는 QA 및 테스트가 중요하지 않은 것을 느낄 수 있도록.

또한 그 당시 문서화에 대해 생각하고 테스트 2에 유효 할 수있는 가설을 세분화했습니다. 방금 코드가 너무 빨리 발전하여 그러한 속도를 따르는 문서를 작성하는 것이 매우 어렵다고 느꼈기 때문에 무겁고 오래된 문서를 작성하는 것보다 코드를 읽을 수있게 만드는 데 시간을 투자하는 것이 더 중요합니다. (물론 이것은 API 에는 적용되지 않고 내부 구현에만 적용 됩니다.) 테스트에는 동일한 문제가 약간 있습니다. 테스트 된 코드와 비교할 때 작성하기에는 너무 느릴 수 있습니다. OTOH, 테스트가 오래되었다고 경고하기 때문에 문제가 덜 발생하지만 문서를 매우주의 깊게 다시 읽지 않으면 문서가 자동으로 유지됩니다 .

마지막으로, 때때로 발견되는 문제 : 자동화 된 테스트는 도구에 따라 달라질 수 있으며 이러한 도구는 제대로 작성되지 않을 수 있습니다. 나는 얼마 전에 XUL을 사용하여 프로젝트를 시작했으며, 이런 플랫폼에 대한 단위 테스트를 작성하는 것은 고통 스럽습니다. Objective-C, Cocoa 및 Xcode 3을 사용하여 다른 응용 프로그램을 시작했으며 그에 대한 테스트 모델은 기본적으로 여러 가지 해결 방법이었습니다.

자동 테스트의 단점에 대한 다른 경험이 있지만 대부분 다른 답변에 나열되어 있습니다. 그럼에도 불구하고 저는 자동화 된 테스트를 강력히 옹호합니다. 이것은 많은 작업과 두통을 저장했으며 항상 기본적으로 권장합니다. 자동화 테스트의 이점과 비교할 때 이러한 단점은 단순한 세부 사항이라고 판단합니다. (자동 다페를 피하기 위해 이단을 언급 한 후에는 항상 믿음을 선포하는 것이 중요합니다.)

언급되지 않은 두 가지는 다음과 같습니다.

• 대규모 테스트 스위트를 실행하는 데 걸리는 클럭 시간

테스트가 느리기 때문에 테스트를 실행하는 데 반나절이 걸렸던 자동화 된 QA 노력의 일환이었습니다. 테스트 작성에주의하지 않으면 테스트 스위트가이 방법으로 나올 수도 있습니다. "오, 나는 방금 수정을했지만, 정확성을 입증하는 데 4 시간이 걸릴 것입니다."

• 테스트 작성 방법의 단점

UI 테스트와 같은 일부 테스트 방법은 돌아올 때마다 깨지는 것처럼 보입니다. 예를 들어, 스크립트가 버튼이 나타날 때까지 테스트 프로세스가 중단되는 경우 특히 고통 스럽지만 버튼 이름이 바뀌 었습니다.

테스트 실습을 통해 문제를 해결할 수 있습니다. 테스트 스위트를 빠르게 유지하는 방법을 찾으십시오 (시스템 / CPU에 테스트 실행을 분배하는 등의 트릭을 수행해야하는 경우에도). 마찬가지로, 시험을 작성하는 연약한 방법을 피하기 위해주의를 기울일 수 있습니다.

나는 잘못된 보안 감각을 하나 더 추가하고 싶습니다.

아주 잘 정의 된 문제 세트 이외에는 포괄적 인 테스트를 만들 수 없습니다. 자동화 된 테스트가 단순히 테스트하지 않는 버그가 Google 소프트웨어에있을 수 있습니다. 자동화 된 테스트를 통과하면 코드에 버그가 없다고 가정하는 경우가 많습니다.

경영 / 벤처 자본가를 설득하기 어렵다

• 테스트 자동화는 초기 비용을 증가시킵니다.
• testautomation은 출시 시간을 늘립니다.
• 테스트 자동화의 이점은 중기 및 로그 기간에 있습니다. 치열한 경쟁은 단기 혜택에 더 중점을 둡니다.

자세한 내용은 시장 주도 단위 테스트 를 참조하십시오.

자체 학습 테스트를 사용하면 주요 단점 중 하나를 극복 할 수 있습니다. 이 상황에서 예상 결과는 모두 데이터로 저장되고자가 학습 모드에서 테스트 스위트 사용자가 최소한의 검토로 업데이트 할 수 있습니다 (이전 예상 결과와 새로운 실제 결과 사이의 차이점 표시-y를 누르면 업데이트 예상). 이 테스트 스위트 학습 모드는주의해서 사용해야하므로 버그가있는 행동은 허용되는 것으로 학습되지 않습니다.