돌연변이 테스트란 무엇입니까? (예)

돌연변이 테스트란 무엇입니까?

돌연변이 테스트 뮤테이션 테스트는 소스 코드의 특정 구문을 변경(변형)하여 테스트 케이스가 소스 코드에서 오류를 찾아낼 수 있는지 확인하는 소프트웨어 테스트 유형입니다. 뮤테이션 테스트의 목표는 변형된 소스 코드에 대해 테스트 케이스가 실패하도록 하여 테스트 케이스의 견고성을 보장하는 것입니다.

돌연변이 프로그램에서 변경되는 부분은 프로그램의 전체적인 목표에 영향을 미치지 않도록 극히 작아야 합니다. 돌연변이 테스트는 프로그램에 의도적으로 결함을 만들어내는 방식이기 때문에 결함 기반 테스트 전략이라고도 합니다. 이는 일종의 테스트 방법입니다. 백 Box 지원 주로 다음과 같은 경우에 적용됩니다. 단위 테스트.

돌연변이 테스트는 1971년 리처드 립턴이 학생 논문에서 제안했고, 1978년 드밀로, 립턴, 세이워드가 발표한 논문 "테스트 데이터 선택에 대한 힌트(Hints on Test Data Selection)"에서 공식화되었습니다. 당시 컴퓨팅 비용 문제로 인해 활용도가 떨어졌으나, 이후 특정 언어에서 다시 주목받고 있습니다. Java, C#, Python, Java스크립트 및 XML.

돌연변이 테스트를 실행하는 방법은 무엇입니까?

다음은 돌연변이 검사(돌연변이 분석)를 수행하는 단계입니다.

1 단계 : 프로그램의 소스 코드에 오류를 도입하기 위해 뮤턴트라고 불리는 여러 버전을 생성합니다. 각 뮤턴트에는 하나의 오류만 포함되어야 하며, 목표는 뮤턴트 버전이 실패하도록 만들어 테스트 케이스의 효율성을 입증하는 것입니다.

2 단계 : 테스트 케이스는 원래 프로그램과 변형된 프로그램 모두에 적용됩니다. 테스트 케이스 적절해야 하며 프로그램의 결함을 감지하기 위해 조정됩니다.

3 단계 : 원래 프로그램과 변형 프로그램의 결과를 비교하십시오.

4 단계 : 원래 프로그램과 변형 프로그램이 서로 다른 출력을 생성한다면, 변형 프로그램은 테스트 케이스에 의해 실패한 것입니다. 따라서 해당 테스트 케이스는 원래 프로그램과 변형 프로그램 간의 변경 사항을 감지하기에 충분합니다.

5 단계 : 원래 프로그램과 변형 프로그램이 동일한 출력을 생성하는 경우, 변형 프로그램은 계속 실행됩니다. 이러한 경우에는 모든 변형 프로그램을 종료시키는 더욱 효과적인 테스트 케이스를 만들어야 합니다.

아래 그림 trac최초 프로그램부터 돌연변이 생성, 그리고 사살 또는 생존 판정에 이르기까지 동일한 5단계를 거칩니다.

돌연변이 프로그램을 만드는 방법은 무엇입니까?

돌연변이란 프로그램 명령문에 가해지는 단 하나의 구문적 변경일 뿐입니다. 각 돌연변이 프로그램은 원본 프로그램과 정확히 하나의 돌연변이만 달라야 합니다.

오리지널 프로그램	돌연변이 프로그램
(x>y)인 경우 "안녕하세요"를 인쇄하세요 다른 "안녕"을 인쇄하세요	만약 (x "안녕하세요"를 인쇄하세요 다른 "안녕"을 인쇄하세요

위 두 예시에서는 비교 연산자만 변경되었지만, x가 y보다 큰 경우 테스트 케이스에서 "Hello" 대신 "Hi"가 출력됩니다. 이 그림은 단 하나의 구문 수정만으로도 이러한 변화가 발생함을 보여줍니다.

돌연변이 프로그램에서 무엇을 변경해야 합니까?

변형 프로그램을 생성하는 데 사용할 수 있는 기술은 여러 가지가 있습니다. 아래 세 가지 유형은 대부분의 도구에 기본적으로 포함된 변형 연산자를 포괄합니다.

Operand 대체 연산자	표현식 수정 연산자	문장 수정 연산자
피연산자를 다른 피연산자(x를 y로, 또는 y를 x로) 또는 상수 값으로 바꿉니다.	프로그램 명령문에서 연산자를 바꾸거나 새 연산자를 삽입합니다.	프로그래밍 문을 수정하여 돌연변이 프로그램을 만듭니다.
예: If(x>y) x 및 y 값 바꾸기 If(5>y) x를 상수 5로 대체	예: 만약(x==y) ==를 >=로 바꾸면 다음과 같은 변형 프로그램을 얻을 수 있습니다. If(x>=y) 및 명령문에 ++ 삽입 만약(x==++y)	예: if-else 문에서 else 부분 삭제 if-else 문 전체를 삭제하여 프로그램의 동작 방식을 확인해 보세요.

몇 가지 예시 변이 연산자:

• GOTO 라벨 교체
• 반품 명세서 교체
• 명세서 삭제
• 단항 연산자 삽입(예: – 및 ++)
• 논리 커넥터 교체
• 비교 가능한 배열 이름 교체
• if-else 문에서 else 부분을 제거하는 것
• 연산자 추가 또는 교체
• 데이터를 변경하여 명령문 교체
• 변수에 대한 데이터 수정
• 프로그램의 데이터 유형 수정

Opera경계 조건에 닿는 부분이 가장 자주 살아남으므로 돌연변이 결과는 종종 경계 조건의 빈틈을 가리킵니다. 경계값 분석.

돌연변이 테스트의 유형

In 소프트웨어 공학뮤테이션 테스트는 기본적으로 문장 뮤테이션, 값 뮤테이션, 결정 뮤테이션의 세 가지 유형으로 분류됩니다.

• 명령문 돌연변이 문장이 잘리거나, 붙여넣기되거나, 삭제될 수 있으므로 결과적으로 코드의 일부 줄이 제거될 수 있습니다.
• 값 변이 - 기본 매개변수 및 상수의 값이 수정됩니다. 예를 들어 루프 범위나 임계값을 변경할 수 있습니다.
• 결정 돌연변이 - 제어문이 변경됩니다. 예를 들어, flip과 같은 경우입니다.ping 관계 연산자 또는 조건 부정.

툴은 연산자를 이 세 가지 범주로 그룹화하므로, 살아남은 변이체를 생성한 패밀리를 통해 테스터는 어떤 유형의 어설션이 누락되었는지 알 수 있습니다. 살아남은 결정 변이체는 일반적으로 테스트되지 않은 분기를 표시하며, 이는 다음과 겹칩니다. 루프 테스트.

돌연변이 테스트 자동화

돌연변이 테스트는 수동으로 실행하기에는 시간이 매우 많이 소요되고 복잡하므로 자동화 도구를 사용하는 것이 좋습니다. 자동화 도구는 비용 절감에도 도움이 됩니다. 돌연변이 테스트 도구는 돌연변이체를 생성하고, 실행 일정을 예약하고, 각 테스트 실패 시 어떤 돌연변이체가 제거되었는지 기록하고, 점수를 보고합니다.

사용 가능한 도구 목록:

• 스트라이커 — 다양한 버전을 지원하는 오픈 소스 변이 테스트 프레임워크 Java스크립트와 TypeScript (StrykerJS), C# 및 .NET(Stryker.NET), 그리고 Scala(Stryker4s).
• PITPITest라고도 표기되는 돌연변이 테스트 시스템입니다. Java 컴파일된 바이트코드를 변형하고 Maven에 연결되는 JVM도 있습니다. Gradle 함께 건설됩니다 JUnit.

둘 다 빌드 단계에서 실행되므로 같은 위치에 있어야 합니다. 지속적인 통합 파이프라인은 나머지 부분과 같습니다. 자동화 테스트 모음곡.

돌연변이 점수

돌연변이 점수는 전체 돌연변이 수 대비 사멸한 돌연변이의 비율로 정의됩니다.

돌연변이 점수 = (죽은 돌연변이 / 총 돌연변이 수) * 100

공식은 대부분의 도구에서 보고하는 형식으로 아래에 나와 있습니다.

테스트 케이스는 점수가 100%에 도달하면 변이 적합성 테스트로 간주됩니다. 실제로 분모에는 특정 항목이 제외되어야 합니다. 동등한 돌연변이체 — 변경된 구문이 원본과 완전히 동일하게 동작하는 돌연변이체이므로 어떤 테스트로도 제거할 수 없습니다. 따라서 도구는 제거된 돌연변이체의 수를 제거된 돌연변이체 수와 살아남은 비동등 돌연변이체의 수를 합한 값으로 나누어 보고하고, 테스터가 동등한 돌연변이체를 표시할 수 있도록 합니다.

실험 결과에 따르면 돌연변이 테스트는 테스트 케이스의 적합성을 측정하는 효과적인 방법입니다. 하지만 주요 단점은 돌연변이체를 생성하고 각 돌연변이체에 대해 모든 테스트 케이스를 실행하는 데 드는 비용입니다.

돌연변이 검사 vs Code 적용 범위

높음 테스트 범위 라인 및 분기 커버리지는 강력한 테스트를 입증하지 못합니다. 라인 및 분기 커버리지는 어떤 명령문이 실행되었는지 기록할 뿐, 이후에 검증이 이루어졌는지 여부는 기록하지 않습니다. 따라서 메서드를 호출하고 아무것도 검증하지 않는 테스트도 커버된 것으로 간주됩니다. 뮤테이션 테스트는 이러한 격차를 해소합니다. 뮤테이션은 검증이 실제로 실패할 때만 종료되기 때문입니다.

아래	Code 적용 범위	돌연변이 점수
측정 대상	테스트가 실행된 라인 또는 분기는 무엇입니까?	어떤 주입된 결함이 테스트에서 감지되었습니까?
주장에 민감함	아니요, 어설션이 하나도 없는 테스트도 코드 커버리지 증가에 기여합니다.	네, 어떤 주장도 실패하지 않으면 돌연변이는 살아남습니다.
한 번 운행 비용	계측 장비를 사용한 테스트 실행 1회	지금까지는 생존한 돌연변이체 하나당 한 번의 테스트 실행만 가능하며, 속도가 훨씬 느립니다.
일반적인 사용	모든 커밋에 대한 빠른 게이트	핵심 모듈에 대한 보다 심층적인 주기적 점검
실패 모드	실질적인 검증 없이 100% 보장	절대 죽일 수 없는 동등한 돌연변이체

두 지표는 상호 보완적입니다. 코드 커버리지는 한 번도 도달하지 않은 코드를 나타내고, 뮤테이션 점수는 도달했지만 한 번도 검사되지 않은 코드를 나타냅니다. 둘 다 동일한 정보를 제공합니다. 결함 관리 프로세스다음과 같은 조치들과 함께 결함 밀도.

돌연변이 테스트의 장점

돌연변이 테스트의 장점은 다음과 같습니다.

• 이는 소스 프로그램의 높은 커버리지를 달성하기 위한 강력한 접근 방식입니다.
• 이것은 다른 어떤 것도 하지 않는 테스트 스위트 자체를 테스트합니다. 소프트웨어 테스트 기법 직접적으로 그렇습니다.
• 뮤테이션 테스트는 소프트웨어 개발자에게 상당한 수준의 오류 탐지 기능을 제공합니다.
• 이 방법은 소스 코드의 모호한 부분을 밝혀내고 일반적인 실행으로는 절대 발견할 수 없는 오류를 드러낼 수 있는 잠재력을 가지고 있습니다.
• 살아남은 돌연변이는 조치가 필요합니다. 각 돌연변이는 해당 소프트웨어 제품군이 알아차리지 못한 특정 코드 라인과 특정 변경 사항을 나타냅니다.
• 고객은 이러한 테스트를 통해 더욱 안정적이고 신뢰할 수 있는 시스템을 제공받는 이점을 얻습니다.

돌연변이 테스트의 단점

반면, 돌연변이 검사의 단점은 다음과 같습니다.

• 돌연변이 테스트는 수많은 돌연변이 프로그램을 생성하고 컴파일해야 하므로 매우 비용이 많이 들고 시간이 오래 걸립니다.
• 시간이 많이 소요되기 때문에 자동화 도구 없이는 이러한 테스트를 수행할 수 없다고 말하는 것이 타당합니다.
• 모든 변이체는 원래 프로그램과 동일한 수의 테스트 케이스로 테스트되므로, 대규모 변이체 집단을 전체 테스트 스위트에 대해 실행해야 합니다.
• 동일한 돌연변이체는 어떤 검사로도 제거할 수 없으며, 진짜 생존자와 구분하려면 일반적으로 수동 검토가 필요합니다.
• 해당 방법은 소스 코드를 변경하기 때문에 적용할 수 없습니다. 검정 Box 지원.

돌연변이 테스트는 언제 사용해야 할까요?

위의 비용 프로필을 보면, 뮤테이션 테스트는 모든 커밋마다 전체 코드베이스에 대해 실행되는 경우는 드뭅니다. 탐지되지 않은 결함으로 인한 비용이 크고 테스트 대상 코드가 충분히 작아서 빠르게 변경될 수 있는 경우에 뮤테이션 테스트가 비용 대비 효과를 발휘합니다.

• 안전 필수 요소 또는 재정적 논리 — 지불액 계산, 세금 규정 및 승인 확인과 같이, 잘못된 답변이 묵묵히 묵묵부답으로 처리될 경우 시스템 오류보다 더 심각한 결과를 초래할 수 있는 상황입니다.
• 보장 범위가 의심스러울 정도로 높은 스위트룸 — 커버리지가 거의 100%에 가깝지만 결함이 여전히 발견되는 경우.
• 기존 코드 리팩토링 중 — 돌연변이 분석 결과는 기존 검사가 회귀 현상을 감지할 수 있는지 여부를 보여줍니다.
• 라이브러리 및 공유 구성 요소 — 재사용된 것의 결함 구성 요소 발신자 한 명 한 명에게 영향을 미칩니다.
• 팀 연습 중 테스트 중심 개발 — 점수 검증을 통해 먼저 작성된 시험이 실제로 효과가 있는지 확인합니다.

일반적으로 일회용 프로토타입, 허술한 연결 코드 또는 분기 로직이 없는 생성된 코드, 또는 느린 테스트가 대부분을 차지하는 테스트 스위트에서 테스트를 실행하는 것은 가치가 없습니다. 통합 테스트 한 번 통과하는 데 이미 몇 시간이 걸립니다.

따라서 대부분의 팀은 변경된 파일로 실행 범위를 제한하고, 중요한 모듈에 대한 임계값을 설정한 다음, 더 넓은 범위의 모듈을 검사하도록 합니다. 회귀 테스트 스위트룸은 나머지 부분을 운반합니다. 소프트웨어 테스팅 수명주기.

자주 묻는 질문