문제

나는 회귀 테스트가 전체 테스트 중 작은(변경 사항이나 새 모듈 도입으로 인해 문제가 발생하지 않았다는 것을 증명할 만큼만) 샘플이라고 배웠습니다.하지만, 이 기사 Ron Morrison과 Grady Booch가 저를 다르게 생각하게 만듭니다.

원하는 전략은 각 단위를 한 번에 하나씩 가져오고 광범위한 회귀 테스트를 수행하고 결함을 수정한 후 다음 단위로 진행하는 것입니다.

같은 문서에는 다음과 같은 내용도 나와 있습니다.

소수의 장치가 추가되자마자 테스트 버전이 생성되고 "연기 테스트"를 거칩니다. 여기서는 통합된 제품이 예상대로 작동할 것이라는 확신을 얻기 위해 소수의 테스트를 실행합니다.의도는 새 장치를 철저히 테스트하거나 전체 시스템을 완전히 회귀 테스트하는 것이 아닙니다.

연기 테스트를 설명할 때 저자는 다음과 같이 말합니다.

스모크 테스트에서는 새로운 구성 요소뿐만 아니라 전체 시스템을 빠르게 검사하는 것도 중요합니다.

나는 "광범위"와 "회귀 테스트"가 함께 사용되는 것을 본 적이 없으며 "전체 시스템에 대한 완전한 회귀 테스트"라고 설명되는 회귀 테스트도 본 적이 없습니다.회귀 테스트는 가능한 한 가볍고 빨라야 합니다.그리고 연기 테스트의 정의는 제가 배운 회귀 테스트였습니다.

제가 배운 내용을 잘못 이해한 걸까요?내가 잘못 가르쳤던 걸까?아니면 "회귀 테스트"에 대한 다양한 해석이 있습니까?

도움이 되었습니까?

해결책

여러 해석이 있습니다. 시스템의 작은 부분에 영향을 미치는 버그 만 수정하는 경우 회귀 테스트에는 해당 클래스 또는 패키지를 행사하는 작은 테스트 스위트 만 포함될 수 있습니다. 버그를 수정하거나 범위가 넓은 기능을 추가하는 경우 회귀 테스트가 더 넓은 범위를 가져야합니다.

"그것이 깨질 수 있다면, 테스트 할 수 있다면"경험 규칙이 여기에 적용됩니다. 변화가 있다면 Foo 영향을 줄 수 있습니다 Bar, 그런 다음 두 가지 모두에 대한 회귀를 실행하십시오.

회귀 테스트는 변경으로 인해 이전에 통과 된 테스트가 실패했는지 확인합니다. 어느 수준 (단위, 통합, 시스템)에서 실행할 수 있습니다. 참조.

다른 팁

나는 항상 새로운 변화에 의해 기존 기능이 깨지지 않도록하는 목적을 의미하는 모든 테스트를 의미하기 위해 회귀 테스트를 수행했습니다. 그것은 테스트 스위트의 크기에 대한 제약을 암시하지 않습니다.

회귀는 일반적으로 전체 테스트 제품군을 참조하는 데 사용됩니다. QA가 릴리스 전에 마지막으로하는 일입니다. 그것은 작동했던 모든 것이 여전히 작동한다는 것을 보여주는 데 사용됩니다. 내 경험에 따르면, 그것은 일반적으로 변화가 얼마나 작은 지에 관계없이 시스템 전체의 테스트 세트입니다 (작은 변화가 회귀 테스트를 유발하지는 않지만).

내가 작업하는 경우 각 릴리스가 끝날 때 각 응용 프로그램에 대해 회귀 테스트가 표준화됩니다. 그들은 모든 기능을 테스트하기위한 것이지만 미묘한 버그를 포착하도록 설계되지는 않았습니다. 따라서 다양한 종류의 검증이 수행되는 양식이있는 경우, 예를 들어 해당 양식의 회귀 제품군은 각 유형의 유효성 검사가 완료되고 (필드 레벨 및 양식 수준) 정확한 정보를 제출할 수 있음을 확인하는 것입니다. . 그것은 모든 단일 케이스를 다루도록 설계되지 않았습니다 (즉, 필드에 공백을 떠나면 어떻게 될까요? 필드 B는 어떻습니까? 그 중 하나를 테스트하고 다른 것이 작동한다고 가정합니다).

그러나 현재 진행중인 프로젝트에서 회귀 테스트는 훨씬 더 철저하며 테스트 중에 발생하는 결함 수가 줄어드는 것을 보았습니다. 그 두 사람은 반드시 관련이있는 것은 아니지만 우리는 그것을 상당히 일관되게 알 수 있습니다.

'회귀 테스트'라는 용어에 대한 나의 이해는 다음과 같습니다.

  • 단위 테스트는 시스템이 생성 될 때 기능 테스트 기능을 위해 작성됩니다.
  • 버그가 발견되면 버그를 재현하고 수정되었는지 확인하기 위해 더 많은 단위 테스트가 작성됩니다.
  • 회귀 테스트는 전체 테스트 세트를 실행하여 오래된 버그가 다시 나타나지 않았다는 것을 포함하여 모든 것이 여전히 작동한다는 것을 증명합니다.

실제로, 변경 될 때 항상 기존 단위 테스트를 항상 실행하는 것이 가장 좋습니다. 테스트의 하위 집합으로 귀찮게하는 유일한 시간은 전체 장치 테스트 스위트가 "너무 길다"가 실행하는 데 "너무 길다"는 경우입니다.

성취하려는 것부터 시작하십시오.그런 다음 그 목표를 달성하기 위해 해야 할 일을 하십시오.그런 다음 유행어 빙고를 사용하여 실제로 하는 일에 단어를 할당하세요.다른 사람들과 마찬가지로 :-) 정확성은 그다지 중요하지 않습니다.

... 회귀 테스트는 작은 (변경 또는 새로운 모듈의 도입으로 아무것도 깨지지 않았다는 것을 증명하기에 충분 함) 전체 테스트의 샘플이었습니다.

작은 테스트 샘플이 시스템이 작동한다는 것을 증명하기에 충분하다면 왜 나머지 테스트가 존재합니까? 그리고 당신이 당신의 변화가 기능의 하위 집합에만 영향을 미쳤다는 것을 알고 있다면, 왜 변경 후 무엇이든 테스트해야합니까? 인간은 오류가 많고, 무언가를 바꾸는 것이 다른 것을 깨뜨리는 지 아무도 모릅니다. IMO, 테스트가 자동화되면 모두 재회하십시오. 자동화되지 않으면 자동화하십시오. 그 동안 자동화 된 것을 다시 실행하십시오.

일반적으로 제품의 버전 X에 도입 된 새로운 기능에 대한 기능 테스트의 하위 집합은 버전 X+1, X+2 등의 회귀 테스트의 기초가됩니다. 시간이 지남에 따라 회귀로 어려움을 겪지 않은 안정적인 기능의 기능/회귀 테스트로 취한 시간을 줄일 수 있습니다. 기능이 많은 회귀로 고통 받으면 기능에 대한 강조를 높이는 것이 도움이 될 수 있습니다.

'광범위한 회귀 테스트'를 언급하는 기사는 광범위한 (개별적으로 간단한) 회귀 테스트 세트를 실행하는 것을 의미한다고 생각합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top