자동화된 소프트웨어 테스트 및 테스트 범위

또한 일반적으로 자동화되지 않거나 반자동화되는 테스트 절차도 있습니다. 가장 잘 알려진 것은 아마도 다음과 같습니다.

1. 부하 테스트 – 인프라를 확인하는 데 사용됩니다. 예를 들어 여기에서는 10,000명의 다른 사용자가 1분 이내에 시스템에 액세스하려고 시도하는 경우 시스템이 얼마나 빨리 반응하는지 테스트합니다.
2. 침투 테스트 – 소프트웨어의 보안을 확인하는 데 사용됩니다. 여기에서 원칙적으로 전문 인력은 시스템에 대한 정보를 수집한 다음 알려진 보안 격차가 제거되지 않았는지 확인합니다.
3. 취약점 스캔 – 보안 격차가 발견되고 알려지면 가장 좋은 경우 알려진 취약점이 있는 데이터베이스에 해당 항목이 만들어집니다. 이렇게 하면 알려진 모든 보안 격차의 카탈로그가 점차 생성됩니다. 특수 소프트웨어를 사용하면 알려진 모든 보안 격차에 대해 이 카탈로그를 기반으로 하는 애플리케이션을 테스트할 수 있습니다.

자동화된 소프트웨어 테스트가 중요한 이유는 무엇입니까?

소프트웨어 테스팅은 그 자체로 전문 분야이며 수행할 수 있는 다른 모든 테스트가 있습니다. 그러나 이제 우리는 기본적으로 다양한 테스트 유형에 익숙해졌으므로 자연스럽게 질문이 생깁니다. 이 모든 것의 요점은 무엇입니까? 마지막 테스트 유형의 직접적인 이점은 직관적입니다. 특히 제품에 공개적으로 액세스할 수 있는 경우 알려진 공격에 대한 내성이 있는지, 해당 인프라가 예상되는 최대 사용자 러시를 견딜 수 있는지 확인해야 합니다.

하지만 테스트를 자동화하고 반복해서 실행하는 이유는 무엇입니까? 특히 입력 값이 고정된 테스트의 경우 출력이 항상 동일하게 유지되어야 합니다.

이는 사용하는 라이브러리를 포함하여 테스트할 소프트웨어 영역의 소스 코드가 변경되지 않는 경우에만 해당됩니다. 특히 소프트웨어 개발이 활발히 진행되는 동안 개별 영역은 지속적으로 변경될 수 있습니다. 기존 모듈에서 프로그래밍에서 이루어진 대부분의 변경 사항은 새로 추가되거나 삭제된 줄이 아니라 수정된 코드 줄로 구성됩니다. 이는 특히 소위 리팩토링, 즉 전체 코드 영역의 재설계에 적용됩니다. 리팩토링은 기술 부채를 줄이고 장기적인 유지 관리 및 확장성을 보장하는 데 유용할 수 있습니다.

기술적 부채

기술적 부채는 예를 들어 개발 중 시간 압박으로 인해 또는 완벽하게 해결되지 않은 구현으로 인해 미리 취해진 약어라고 종종 언급됩니다. 일반적으로 이것은 유지 관리가 점점 더 어려워지는 코드로 이어지며 추가 개발 중에 개발 시간이 늘어남에 따라 개발 비용이 증가합니다.

자동화된 테스트 및 소프트웨어 개발의 이점

프로젝트가 특정 수준의 성숙도와 완성도에 도달하더라도 시간이 지남에 따라 사용되는 라이브러리 버전을 늘려야 합니다. 예를 들어 사용된 라이브러리에서 보안 구멍이 발견되었기 때문에 이 작업이 필요할 수 있습니다.

이제 자동화된 테스트와 소프트웨어 개발 사이의 연결이 시작됩니다. 테스트는 변경 후 개발자가 쉽게 실행할 수 있으므로 검사된 모든 구성 요소가 테스트에 저장된 조건을 여전히 충족하는지 확인할 수 있습니다. 이는 소위 테스트 주도 개발(TDD)이라고 하는 개발 방법으로도 사용할 수 있습니다. 여기에서 추가할 각 새 구성 요소에 대해 동작에 대한 정확한 설명이 먼저 개별 테스트 형식으로 작성됩니다. 각 코드 변경 후 방금 구현한 동작에 대한 테스트가 수행됩니다. 모든 테스트가 오류 없이 통과되면 구성 요소가 계획대로 작동합니다.

TDD에 따라 개발하든 안 하든 기존의 모든 테스트는 개발자가 소스 코드 관리에 저장하는 즉시 소위 CI(연속 통합) 서버에서 항상 실행해야 합니다. 고품질 통합 및 승인 테스트와 관련하여 다른 개발자가 변경한 조합이 여전히 정의된 모든 기준을 충족하는지 확인할 수 있습니다. 실제로 시스템이 더 복잡해지고 수동 품질 보증이 매우 시간 소모적인 방식으로만 확인될 수 있는 경우에는 그렇지 않은 경우가 많습니다.

테스트 범위

이제 처음에 언급한 테스트 커버리지의 척도에 대해 살펴보겠습니다. 자동으로 실행되는 프로그램의 모든 영역은 명백한 구문 오류가 있는 경우 직접 적중합니다. 이런 점에서 높은 테스트 커버리지는 확실히 바람직합니다. 특히 TDD 방법론을 사용하면 테스트 범위가 매우 높아집니다. 테스트를 통해 각 구체적인 구현을 확인하는 것이 처음부터 보장됩니다. 그렇다면 TDD로 개발된 모든 프로젝트에는 “좋은 테스트”가 있으며 더 이상 버그가 포함되어 있지 않습니까? 불행하게도. 100% 테스트 범위는 실제로 구문 오류를 제외할 수 있지만 불행히도 콘텐츠 오류는 아닙니다. 테스트는 사전에 정의된 내용만 정확히 확인합니다. 따라서 아무도 생각하지 못한 상황에서 발생하는 콘텐츠 관련 오류는 기껏해야 실수로 테스트에서 오류를 유발합니다.

더 높은 품질의 소프트웨어를 위한 다양한 테스트 유형

이러한 “우연한 발견”의 가능성은 광범위한 승인 테스트를 통해 증가할 수 있습니다. 반면 광범위한 통합 테스트는 다른 소프트웨어 구성 요소의 변경 사항에 따른 부작용을 찾는 데 도움이 됩니다. 단위 테스트는 변경 후 구성 요소의 올바른 기능을 보장하는 데 필수적입니다.

따라서 더 높은 품질을 보장하기 위해 다양한 테스트 유형을 혼합하여 소프트웨어를 실행하는 것이 중요합니다. 그러나 테스트 범위는 개별 테스트의 품질과 유형에 대해 아무 것도 말해주지 않습니다. 구성 요소를 통해 실행되지만 상호 작용을 완전히 무시하는 각 구성 요소에 대한 단위 테스트를 작성하여 100% 테스트 범위를 달성할 수 있습니다.

우리의 결론

요약하면, 자동화된 소프트웨어 테스트의 품질은 프로젝트의 장기적인 실행 가능성과 유지 관리에 매우 중요하다고 말할 수 있습니다. 또한, 이는 단일 백분율로 표현할 수 없으며, 기존 테스트에 대한 차별화되고 세부적인 고려가 필요합니다.