Amazon CodeCatalyst는 더 이상 신규 고객에게 공개되지 않습니다. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 마이그레이션하는 방법](migration.md) 단원을 참조하십시오.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 워크플로를 사용한 테스트
CodeCatalyst에서 빌드 및 테스트와 같은 다양한 워크플로 작업의 일부로 테스트를 실행할 수 있습니다. 이러한 워크플로 작업은 모두 품질 보고서를 생성할 수 있습니다. *테스트 작업*은 테스트, 코드 적용 범위, 소프트웨어 구성 분석 및 정적 분석 보고서를 생성하는 워크플로 작업입니다. 이러한 보고서는 CodeCatalyst 콘솔에 표시됩니다.
**Topics**
+ [품질 보고서 유형](#test-reporting)
+ [테스트 작업 추가](test-add-action.md)
+ [테스트 작업 결과 보기](test-view-results.md)
+ [작업에서 실패한 테스트 건너뛰기](test.error-handling.md)
+ [universal-test-runner와 통합](test.universal-test-runner.md)
+ [작업에서 품질 보고서 구성](test-config-action.md)
+ [테스트 모범 사례](test-best-practices.md)
+ [지원되는 SARIF 속성](test.sarif.md)
## 품질 보고서 유형
Amazon CodeCatalyst 테스트 작업은 다음과 같은 유형의 품질 보고서를 지원합니다. YAML에서 이러한 보고서를 포맷하는 방법에 대한 예시는 [품질 보고서 YAML 예시](test-config-action.md#test.success-criteria-example) 섹션을 참조하세요.
**Topics**
+ [테스트 보고서](#test-reports)
+ [코드 적용 범위 보고서](#test-code-coverage-reports)
+ [소프트웨어 구성 분석 보고서](#test-sca-reports)
+ [정적 분석 보고서](#test-static-analysis-reports)
### 테스트 보고서
CodeCatalyst에서 빌드 중에 실행되는 단위 테스트, 통합 테스트 및 시스템 테스트를 구성할 수 있습니다. 그런 다음 CodeCatalyst는 테스트 결과를 포함하는 보고서를 생성할 수 있습니다.
테스트 보고서를 사용하여 테스트 문제를 해결할 수 있습니다. 빌드 프로젝트의 여러 빌드에 많은 테스트 보고서가 있는 경우 테스트 보고서를 사용하여 추세와 테스트 및 실패율을 보고 빌드를 쉽게 최적화할 수 있습니다.
다음 테스트 보고서 파일 형식을 사용할 수 있습니다.
+ Cucumber JSON(.json)
+ JUnit XML(.xml)
+ NUnit XML(.xml)
+ NUnit3 XML(.xml)
+ TestNG XML(.xml)
+ Visual Studio TRX (.trx, .xml)
### 코드 적용 범위 보고서
CodeCatalyst에서는 테스트에 대한 코드 적용 범위 보고서를 생성할 수 있습니다. CodeCatalyst는 다음과 같은 코드 적용 범위 지표를 제공합니다.
행 범위
행 범위는 테스트에서 다루는 명령문 수를 측정합니다. 문은 설명이 포함되지 않은 단일 명령어입니다.
`line coverage = (total lines covered)/(total number of lines)`
브랜치 적용 범위
또는 문과 같은 제어 구조의 가능한 모든 브랜치 중 테스트에서 다루는 분기 수(`if` 또는 `case`)를 측정합니다.
`branch coverage = (total branches covered)/(total number of branches)`
다음 코드 적용 범위 보고서 파일 형식이 지원됩니다.
+ JaCoCo XML(.xml)
+ SimpleCov JSON([simplecov-json](https://github.com/vicentllongo/simplecov-json), .json이 아닌 [simplecov](https://github.com/simplecov-ruby/simplecov)에서 생성됨)
+ Clover XML(버전 3, .xml)
+ Cobertura XML(.xml)
+ LCOV(.info)
### 소프트웨어 구성 분석 보고서
CodeCatalyst에서 소프트웨어 구성 분석(SCA) 도구를 사용하여 애플리케이션의 구성 요소를 분석하고 알려진 보안 취약성을 확인할 수 있습니다. 심각도가 다양한 취약성과 이를 수정하는 방법을 자세히 설명하는 SARIF 보고서를 검색하고 구문 분석할 수 있습니다. 최대부터 최소 심각도까지 유효한 심각도 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, `INFORMATIONAL`입니다.
지원되는 SCA 보고서 파일 형식은 다음과 같습니다.
+ SARIF(.sarif, .json)
### 정적 분석 보고서
정적 분석(SA) 보고서를 사용하여 소스 수준 코드 결함을 식별할 수 있습니다. CodeCatalyst에서 SA 보고서를 생성하여 코드를 배포하기 전에 코드 문제를 해결할 수 있습니다. 이러한 문제에는 버그, 보안 취약성, 품질 문제 및 기타 취약성이 포함됩니다. 최대부터 최소 심각도까지 유효한 심각도 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
CodeCatalyst는 다음과 같은 SA 지표를 제공합니다.
버그
소스 코드에서 발견된 가능한 버그 수를 식별합니다. 이러한 버그에는 메모리 안전성에 관한 문제가 포함될 수 있습니다. 다음은 버그의 예시입니다.
```
// The while loop will inadvertently index into array x out-of-bounds
int x[64];
while (int n = 0; n <= 64; n++) {
x[n] = 0;
}
```
보안 취약성
소스 코드에서 발견된 여러 가지 가능한 보안 취약성을 식별합니다. 이러한 보안 취약성에는 보안 암호 토큰을 일반 텍스트로 저장하는 등의 문제가 포함될 수 있습니다.
품질 문제
소스 코드에서 발견된 여러 가지 가능한 품질 문제를 식별합니다. 이러한 품질 문제에는 스타일 규칙과 관련된 문제가 포함될 수 있습니다. 다음은 품질 문제의 예입니다.
```
// The function name doesn't adhere to the style convention of camelCase
int SUBTRACT(int x, int y) {
return x-y
}
```
기타 취약성
소스 코드에서 발견된 여러 가지 가능한 보안 취약성을 식별합니다.
CodeCatalyst에서 지원되는 코드 적용 범위 보고서 파일 형식은 다음과 같습니다.
+ PyLint(.py)
+ ESLint(.js, .jsx, .ts, .tsx)
+ SARIF(.sarif, .json)
# 테스트 작업 추가
다음 절차에 따라 CodeCatalyst 워크플로에 테스트 작업을 추가합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 테스트 작업 추가**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **테스트**를 선택합니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 빌드 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **테스트**를 선택합니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 [빌드 및 테스트 작업 YAML](build-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
## 작업 정의 테스트
테스트 작업은 워크플로 정의 파일 내의 YAML 속성 집합으로 정의됩니다. 이러한 속성에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요.
# 테스트 작업 결과 보기
다음 지침에 따라 생성된 로그, 보고서 및 변수를 포함한 테스트 작업의 결과를 확인합니다.
**테스트 작업 결과 보기**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 워크플로 다이어그램에서 테스트 작업의 이름(예시: **테스트**)을 선택합니다.
1. 작업에서 생성된 로그를 보려면 **로그**를 선택합니다. 다양한 작업 단계의 로그가 표시됩니다. 필요에 따라 로그를 확장하거나 축소할 수 있습니다.
1. 테스트 작업에서 생성된 테스트 보고서를 보려면 **보고서**를 선택하거나 탐색 창에서 **보고서**를 선택합니다. 자세한 내용은 [품질 보고서 유형](test-workflow-actions.md#test-reporting) 섹션을 참조하세요.
1. 빌드 작업에 사용되는 구성을 보려면 **구성**을 선택합니다. 자세한 내용은 [테스트 작업 추가](test-add-action.md) 섹션을 참조하세요.
1. 테스트 작업에 사용되는 변수를 보려면 **변수**를 선택합니다. 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
# 작업에서 실패한 테스트 건너뛰기
작업에 테스트 명령이 두 개 이상 있는 경우 이전 명령이 실패하더라도 작업의 후속 테스트 명령이 실행되도록 허용할 수 있습니다. 예를 들어, 다음 명령에서는 `test1`이 실패하더라도 `test2`가 항상 실행되도록 할 수 있습니다.
```
Steps:
- Run: npm install
- Run: npm run test1
- Run: npm run test2
```
일반적으로 단계가 오류를 반환하면 Amazon CodeCatalyst는 워크플로 작업을 중지하고 실패로 표시합니다. 오류 출력을 `null`로 리디렉션하여 작업 단계가 계속 실행되도록 허용할 수 있습니다. 명령에 `2>/dev/null`을 추가하면 이 작업을 수행할 수 있습니다. 이렇게 수정하면 앞의 예시는 다음과 같이 표시됩니다.
```
Steps:
- Run: npm install
- Run: npm run test1 2>/dev/null
- Run: npm run test2
```
두 번째 코드 조각에서는 `npm install` 명령의 상태가 그대로 유지되지만 `npm run test1` 명령에서 반환된 오류는 무시됩니다. 결과적으로 `npm run test2` 명령이 실행됩니다. 이렇게 하면 오류 발생 여부에 관계없이 두 보고서를 한 번에 볼 수 있습니다.
# universal-test-runner와 통합
테스트 작업은 오픈 소스 명령줄 도구인 `universal-test-runner`와 통합됩니다. `universal-test-runner`는 [테스트 실행 프로토콜](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md)을 사용하여 주어진 프레임워크에서 모든 언어에 대한 테스트를 실행합니다. `universal-test-runner`는 다음 프레임워크를 지원합니다.
+ [Gradle](https://gradle.org/)
+ [Jest](https://jestjs.io/)
+ [Maven](https://maven.apache.org/)
+ [pytest](https://pytest.org)
+ [.NET](https://learn.microsoft.com/en-us/dotnet/core/tools/)
`universal-test-runner`는 테스트 동작을 위해 큐레이팅된 이미지에만 설치됩니다. 용자 지정 Docker Hub 또는 Amazon ECR을 사용하도록 테스트 동작을 구성하는 경우 고급 테스트 특성을 사용하려면 `universal-test-runner`를 수동으로 설치해야 합니다. 이렇게 하려면 이미지에 Node.js(14 이상)를 설치한 후 다음 쉘 명령 `- Run: npm install -g @aws/universal-test-runner`을 사용하여 `npm`을 통해 `universal-test-runner`를 설치합니다. 쉘 명령을 통해 컨테이너에 Node.js를 설치하는 방법에 대한 자세한 내용은 [Installing and Updating Node Version Manager](https://github.com/nvm-sh/nvm#install--update-script)를 참조하세요.
`universal-test-runner`에 대한 자세한 내용은 [What is universal-test-runner?](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner) 섹션을 참조하세요.
------
#### [ Visual ]
**시각적 편집기에서 universal-test-runner 사용**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **테스트**를 선택합니다.
1. **구성** 탭에서 지원되는 프레임워크를 선택하여 샘플 코드를 업데이트하여 **쉘 명령** 필드를 완료합니다. 예를 들어 지원되는 프레임워크를 사용하려면 다음과 유사한 `Run` 명령을 사용합니다.
```
- Run: run-tests
```
원하는 프레임워크가 지원되지 않는 경우 사용자 지정 어댑터 또는 러너를 제공하는 것이 좋습니다. **쉘 명령** 필드에 대한 설명은 [Steps](build-action-ref.md#build.configuration.steps) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기에서 universal-test-runner 사용**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **테스트**를 선택합니다.
1. 필요에 따라 YAML 코드를 수정합니다. 예를 들어 지원되는 프레임워크를 사용하려면 다음과 유사한 `Run` 명령을 사용합니다.
```
Configuration:
Steps:
- Run: run-tests
```
원하는 프레임워크가 지원되지 않는 경우 사용자 지정 어댑터 또는 러너를 제공하는 것이 좋습니다. **Steps** 속성에 대한 설명은 [Steps](build-action-ref.md#build.configuration.steps) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 작업에서 품질 보고서 구성
이 섹션에서는 작업에서 품질 보고서를 구성하는 방법을 설명합니다.
**Topics**
+ [자동 검색 및 수동 보고서](#test.auto-discovery)
+ [보고서의 성공 기준 구성](#test.success-criteria)
+ [품질 보고서 YAML 예시](#test.success-criteria-example)
## 자동 검색 및 수동 보고서
자동 검색이 활성화되면 CodeCatalyst는 작업에 전달된 모든 입력과 작업 자체에서 생성된 모든 파일을 검색하여 테스트, 코드 적용 범위, 소프트웨어 구성 분석(SCA) 및 정적 분석(SA) 보고서를 찾습니다. CodeCatalyst에서 이러한 각 보고서를 보고 조작할 수 있습니다.
생성되는 보고서를 수동으로 구성할 수도 있습니다. 생성하려는 보고서 유형과 파일 형식을 지정할 수 있습니다. 자세한 내용은 [품질 보고서 유형](test-workflow-actions.md#test-reporting) 섹션을 참조하세요.
## 보고서의 성공 기준 구성
테스트, 코드 적용 범위, 소프트웨어 구성 분석(SCA) 또는 정적 분석(SA) 보고서의 성공 기준을 결정하는 값을 설정할 수 있습니다.
성공 기준은 보고서가 통과 또는 실패하는지 여부를 결정하는 임계값입니다. CodeCatalyst는 먼저 테스트, 코드 적용 범위, SCA 또는 SA 보고서일 수 있는 보고서를 생성한 다음 생성된 보고서에 성공 기준을 적용합니다. 그런 다음 성공 기준이 충족되었는지 여부와 어느 정도까지 충족되었는지 보여줍니다. 지정된 성공 기준을 충족하지 않는 보고서가 있으면 성공 기준을 지정한 CodeCatalyst 작업이 실패합니다.
예를 들어 SCA 보고서의 성공 기준을 설정할 때 가장 심각함에서 가장 덜 심각함까지의 유효한 취약성 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, `INFORMATIONAL`입니다. `HIGH` 심각도에서 하나의 취약성을 스캔하도록 기준을 설정하면 `HIGH` 심각도에서 하나 이상의 취약성이 있거나 심각도에서 취약성이 없지만 `HIGH` 심각도에서 하나의 취약성과 같이 `CRITICAL` 심각도가 더 높은 수준에서 하나 이상의 취약성이 있는 경우 보고서가 실패합니다.
성공 기준을 지정하지 않으면 다음을 수행합니다.
+ 원시 보고서를 기반으로 생성된 CodeCatalyst 보고서에는 성공 기준이 표시되지 않습니다.
+ 성공 기준은 연결된 워크플로 작업이 통과 또는 실패하는지 여부를 결정하는 데 사용되지 않습니다.
------
#### [ Visual ]
**성공 기준 구성**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 보고서를 생성하는 작업이 포함된 워크플로를 선택합니다. 성공 기준을 적용하려는 보고서입니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 CodeCatalyst 보고서를 생성하도록 구성한 작업을 선택합니다.
1. **출력** 탭을 선택합니다.
1. **보고서 자동 검색** 또는 **보고서 수동 구성**에서 **성공 기준**을 선택합니다.
성공 기준이 나타납니다. 이전 선택에 따라 다음 옵션 중 일부 또는 전부가 표시될 수 있습니다.
**통과율**
관련 CodeCatalyst 보고서를 통과로 표시하기 위해 통과해야 하는 테스트 보고서의 테스트 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 통과율 기준은 테스트 보고서에만 적용됩니다. 테스트 보고서에 대한 자세한 내용은 [테스트 보고서](test-workflow-actions.md#test-reports)의 내용을 참조하세요.
**행 범위**
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 줄 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 라인 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
**브랜치 적용 범위**
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 브랜치 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 브랜치 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
**취약성(SCA)**
SCA 보고서에서 허용되는 취약성의 최대 수와 심각도를 지정하여 관련 CodeCatalyst 보고서를 통과로 표시합니다. 취약성을 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 취약성의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 취약성이 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 취약성 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
취약성 기준은 SCA 보고서에만 적용됩니다. SCA 보고서에 대한 자세한 내용은 [소프트웨어 구성 분석 보고서](test-workflow-actions.md#test-sca-reports)의 내용을 참조하세요.
**bugs**
관련 CodeCatalyst 보고서에 대해 SA 보고서에 허용되는 최대 버그 수와 심각도를 전달된 것으로 표시합니다. 버그를 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 버그의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 버그가 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 버그 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
버그 기준은 PyLint 및 ESLint SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
**보안 취약성**
관련 CodeCatalyst 보고서에 대해 SA 보고서에서 허용되는 보안 취약성의 최대 수와 심각도를 전달된 것으로 표시합니다. 보안 취약성을 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 보안 취약성의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 취약성이 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 보안 취약성 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
보안 취약성 기준은 PyLint 및 ESLint SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
**품질 문제**
관련 CodeCatalyst 보고서에 대해 SA 보고서에서 통과로 표시할 수 있는 품질 문제의 최대 수와 심각도를 지정합니다. 품질 문제를 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 품질 문제의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 품질 문제가 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 품질 문제 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
품질 문제 기준은 PyLint 및 ESLint SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
1. **커밋**을 선택합니다.
1. 워크플로를 실행하여 CodeCatalyst가 원시 보고서에 성공 기준을 적용하도록 하고, 성공 기준 정보가 포함된 관련 CodeCatalyst 보고서를 다시 생성합니다. 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
------
#### [ YAML ]
**성공 기준 구성**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 보고서를 생성하는 작업이 포함된 워크플로를 선택합니다. 성공 기준을 적용하려는 보고서입니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 워크플로 다이어그램에서 CodeCatalyst 보고서를 생성하도록 구성한 작업을 선택합니다.
1. 세부 정보 창에서 **출력** 탭을 선택합니다.
1. 작업의 `AutoDiscoverReports` 섹션 또는 `Reports` 섹션에서 **SuccessCriteria** 속성을 `PassRate`, `LineCoverage`, `BranchCoverage`, `Vulnerabilities`, `StaticAnalysisBug`, `StaticAnalysisSecurity`, `StaticAnalysisQuality` 속성과 함께 추가합니다.
이러한 각 속성에 대한 설명은 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요.
1. **커밋**을 선택합니다.
1. 워크플로를 실행하여 CodeCatalyst가 원시 보고서에 성공 기준을 적용하도록 하고 성공 기준 정보가 포함된 관련 CodeCatalyst 보고서를 다시 생성합니다. 배치 워크플로우에 대한 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
------
## 품질 보고서 YAML 예시
다음 예시에서는 테스트 보고서, 코드 적용 범위 보고서, 소프트웨어 구성 분석 보고서, 정적 분석 보고서 등 4개의 보고서를 수동으로 구성하는 방법을 보여줍니다.
```
Reports:
MyTestReport:
Format: JUNITXML
IncludePaths:
- "*.xml"
ExcludePaths:
- report1.xml
SuccessCriteria:
PassRate: 90
MyCoverageReport:
Format: CLOVERXML
IncludePaths:
- output/coverage/jest/clover.xml
SuccessCriteria:
LineCoverage: 75
BranchCoverage: 75
MySCAReport:
Format: SARIFSCA
IncludePaths:
- output/sca/reports.xml
SuccessCriteria:
Vulnerabilities:
Number: 5
Severity: HIGH
MySAReport:
Format: ESLINTJSON
IncludePaths:
- output/static/eslint.xml
SuccessCriteria:
StaticAnalysisBug:
Number: 10
Severity: MEDIUM
StaticAnalysisSecurity:
Number: 5
Severity: CRITICAL
StaticAnalysisQuality:
Number: 0
Severity: INFORMATIONAL
```
# 테스트 모범 사례
CodeCatalyst에서 제공하는 테스트 기능을 사용할 때는 다음 모범 사례를 따르는 것이 좋습니다.
**Topics**
+ [자동 검색](#test.best-auto-discovery)
+ [성공 기준](#test.best-success-criteria)
+ [경로 포함/제외](#test.best-include-exclude)
## 자동 검색
CodeCatalyst에서 작업을 구성할 때 자동 검색을 사용하면 JUnit 테스트 보고서와 같은 다양한 도구의 출력을 자동으로 검색하고 해당 도구에서 관련 CodeCatalyst 보고서를 생성할 수 있습니다. 자동 검색은 검색된 출력의 이름이나 경로가 변경되더라도 보고서가 계속 생성되도록 하는 데 도움이 됩니다. 새 파일이 추가되면 CodeCatalyst는 자동으로 파일을 검색하고 관련 보고서를 생성합니다. 그러나 자동 검색을 사용하는 경우 이 기능의 다음 측면 중 일부를 고려해야 합니다.
+ 작업에서 자동 검색을 활성화하면 동일한 유형의 자동으로 검색된 모든 보고서가 동일한 성공 기준을 공유합니다. 예를 들어 최소 통과율과 같은 공유 기준이 모든 자동 검색된 테스트 보고서에 적용됩니다. 동일한 유형의 보고서에 대해 다른 기준이 필요한 경우 이러한 각 보고서를 명시적으로 구성해야 합니다.
+ 자동 검색은 종속성에서 생성된 보고서를 찾을 수도 있으며 성공 기준이 구성된 경우 이러한 보고서에 대한 작업에 실패할 수 있습니다. 이 문제는 제외 경로 구성을 업데이트하여 해결할 수 있습니다.
+ 자동 검색은 런타임에 작업을 스캔하기 때문에 매번 동일한 보고서 목록을 생성하지는 않습니다. 특정 보고서를 항상 생성하려면 보고서를 명시적으로 구성해야 합니다. 예를 들어 빌드의 일부로 테스트 실행을 중지해야 하는 경우 테스트 프레임워크는 출력을 생성하지 않으며, 결과적으로 테스트 보고서가 생성되지 않고 작업이 성공할 수 있습니다. 작업의 성공이 특정 테스트에 따라 달라지도록 하려면 해당 보고서를 명시적으로 구성해야 합니다.
**작은 정보**
새 프로젝트 또는 기존 프로젝트를 시작할 때 전체 프로젝트 디렉터리(`**/*` 포함)에 대해 자동 검색을 사용합니다. 이렇게 하면 하위 디렉터리 내의 파일을 포함하여 프로젝트의 모든 파일에서 보고서 생성이 간접 호출됩니다.
자세한 내용은 [작업에서 품질 보고서 구성](test-config-action.md) 섹션을 참조하세요.
## 성공 기준
성공 기준을 구성하여 보고서에 품질 임계값을 적용할 수 있습니다. 예를 들어 두 개의 코드 적용 범위 보고서가 자동으로 검색된 경우, 하나는 80%의 행 적용 범위이고 다른 하나는 60%의 행 적용 범위인 경우 다음 옵션이 있습니다.
+ 행 적용 범위에 대한 자동 검색 성공 기준을 80%로 설정합니다. 이로 인해 첫 번째 보고서가 통과하고 두 번째 보고서가 실패하여 전체 작업이 실패합니다. 워크플로의 차단을 해제하려면 두 번째 보고서의 행 적용 범위가 80%를 초과할 때까지 프로젝트에 새 테스트를 추가합니다.
+ 행 적용 범위에 대한 자동 검색 성공 기준을 60%로 설정합니다. 이렇게 하면 두 보고서가 모두 전달되어 작업이 성공합니다. 그런 다음 두 번째 보고서에서 코드 적용 범위를 늘리는 작업을 수행할 수 있습니다. 그러나 이 접근 방식을 사용하면 첫 번째 보고서의 적용 범위가 80% 미만으로 떨어지지 않는다고 보장할 수 없습니다.
+ 시각적 편집기를 사용하거나 각 보고서에 대해 명시적 YAML 섹션 및 경로를 추가하여 하나 또는 두 개의 보고서를 명시적으로 구성합니다. 이렇게 하면 각 보고서에 대해 별도의 성공 기준과 사용자 지정 이름을 구성할 수 있습니다. 그러나 이 접근 방식을 사용하면 보고서 경로가 변경되면 작업이 실패할 수 있습니다.
자세한 내용은 [보고서의 성공 기준 구성](test-config-action.md#test.success-criteria) 섹션을 참조하세요.
## 경로 포함/제외
작업 결과를 검토할 때 `IncludePaths` 및 `ExcludePaths`를 구성하여 CodeCatalyst에서 생성한 보고서 목록을 조정할 수 있습니다.
+ `IncludePaths`는 보고서를 검색할 때 CodeCatalyst가 포함할 파일 및 파일 경로를 지정하는 데 사용합니다. 예를 들어 `"/test/report/*"` 지정 시 CodeCatalyst는 작업에서 `/test/report/` 디렉터리를 찾는 데 사용되는 전체 빌드 이미지를 검색합니다. 해당 디렉터리를 찾으면 CodeCatalyst는 해당 디렉터리에서 보고서를 찾습니다.
**참고**
수동으로 구성된 보고서의 경우 `IncludePaths`는 단일 파일과 일치하는 글로브 패턴이어야 합니다.
+ `ExcludePaths`는 보고서를 검색할 때 CodeCatalyst가 제외할 파일 및 파일 경로를 지정하는 데 사용합니다. 예를 들어 `"/test/reports/**/*"` 지정 시 CodeCatalyst는 `/test/reports/` 디렉터리의 파일을 검색하지 않습니다. 디렉터리의 모든 파일을 무시하려면 `**/*` glob 패턴을 사용합니다.
다음은 가능한 glob 패턴의 몇 가지 예입니다.
| 패턴 | 설명 |
| --- | --- |
| `*.*` | 점을 포함한 모든 객체 이름과 해당합니다. |
| `*.xml` | `.xml`로 끝나는 현재 디렉터리의 모든 객체 이름과 일치 |
| `*.{xml,txt}` | `.xml` 또는 `.txt`로 끝나는 현재 디렉터리의 모든 객체 이름과 일치 |
| `**/*.xml` | `.xml`로 끝나는 모든 디렉터리의 객체 이름과 일치 |
| `testFolder` | 파일로 취급하여 `testFolder` 객체와 일치 |
| `testFolder/*` | `testFolder/file.xml`와 같은 `testFolder`에서 하위 폴더의 한 수준의 객체와 일치 |
| `testFolder/*/*` | `testFolder/reportsFolder/file.xml`와 같은 `testFolder`에서 하위 폴더의 두 가지 수준의 객체와 일치 |
| `testFolder/**` | `testFolder` 아래 파일뿐만 아니라 하위 폴더 `testFolder`도 일치시킵니다(예: `testFolder/file.xml`와 `testFolder/otherFolder/file.xml`). |
CodeCatalyst는 다음과 같이 glob 패턴을 해석합니다.
+ 슬래시(`/`) 문자는 파일 경로의 디렉터리를 구분합니다.
+ 별표(`*`) 문자는 폴더의 경계를 넘지 않고 0개 이상의 이름 구성 요소 문자와 해당합니다.
+ 이중 별표(`**`)는 모든 디렉터리에서 이름 구성 요소의 0개 이상 문자와 일치합니다.
**참고**
`ExcludePaths`가 `IncludePaths`보다 우선합니다. `IncludePaths` 및 `ExcludePaths`에 모두 동일한 폴더가 포함된 경우 해당 폴더는 보고서에 대해 스캔되지 않습니다.
# 지원되는 SARIF 속성
정적 분석 결과 교환 형식(SARIF)은 Amazon CodeCatalyst의 소프트웨어 구성 분석(SCA) 및 정적 분석 보고서에서 사용할 수 있는 출력 파일 형식입니다. 다음 예시는 정적 분석 보고서에서 SARIF를 수동으로 구성하는 방법을 보여줍니다.
```
Reports:
MySAReport:
Format: SARIFSA
IncludePaths:
- output/sa_report.json
SuccessCriteria:
StaticAnalysisFinding:
Number: 25
Severity: HIGH
```
CodeCatalyst는 다음과 같은 SARIF 속성을 지원하며, 이를 사용하여 분석 결과가 보고서에 표시되는 방식을 최적화할 수 있습니다.
**Topics**
+ [`sarifLog` 객체](#test.sarif.sarifLog)
+ [`run` 객체](#test.sarif.run)
+ [`toolComponent` 객체](#test.sarif.toolComponent)
+ [`reportingDescriptor` 객체](#test.sarif.reportingDescriptor)
+ [`result` 객체](#test.sarif.result)
+ [`location` 객체](#test.sarif.location)
+ [`physicalLocation` 객체](#test.sarif.physicalLocation)
+ [`logicalLocation` 객체](#test.sarif.logicalLocation)
+ [`fix` 객체](#test.sarif.fix)
## `sarifLog` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `$schema` | 예 | 버전 [2.1.0](https://json.schemastore.org/sarif-2.1.0.json)에 대한 SARIF JSON 스키마의 URI입니다. |
| `version` | 예 | CodeCatalyst는 SARIF 버전 2.1.0만 지원합니다. |
| `runs[]` | 예 | SARIF 파일에는 하나 이상의 실행 배열이 포함되며, 각 실행은 분석 도구의 단일 실행을 나타냅니다. |
## `run` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `tool.driver` | 예 | 분석 도구를 설명하는 `toolComponent` 객체입니다. |
| `tool.name` | 아니요 | 분석을 수행하는 데 사용되는 도구의 이름을 나타내는 속성입니다. |
| `results[]` | 예 | CodeCatalyst에 표시되는 분석 도구의 결과입니다. |
## `toolComponent` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `name` | 예 | 분석 도구의 이름입니다. |
| `properties.artifactScanned` | 아니요 | 도구에서 분석한 총 아티팩트 수입니다. |
| `rules[]` | 예 | 규칙을 나타내는 `reportingDescriptor` 객체의 배열입니다. 이러한 규칙을 기반으로 분석 도구는 분석되는 코드에서 문제를 찾습니다. |
## `reportingDescriptor` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `id` | 예 | 조사 결과를 참조하는 데 사용되는 규칙의 고유 식별자입니다. 최대 길이: 1,024자 |
| `name` | 아니요 | 규칙의 디스플레이 이름입니다. 최대 길이: 1,024자 |
| `shortDescription.text` | 아니요 | 규칙에 대한 짧은 설명입니다. 최대 길이: 3,000자 |
| `fullDescription.text` | 아니요 | 규칙에 대한 전체 설명입니다. 최대 길이: 3,000자 |
| `helpUri` | 아니요 | 규칙에 대한 기본 설명서의 절대 URI를 포함하도록 현지화할 수 있는 문자열입니다. 최대 길이: 3,000자 |
| `properties.unscore` | 아니요 | 스캔 조사 결과의 점수가 매겨졌는지 여부를 나타내는 플래그입니다. |
| `properties.score.severity` | 아니요 | 조사 결과의 심각도 수준을 지정하는 고정된 문자열 세트입니다. 최대 길이: 1,024자 |
| `properties.cvssv3_baseSeverity` | 아니요 | [일반 취약성 점수 체계 v3.1](https://www.first.org/cvss/v3.1/specification-document)의 정성적 심각도 등급입니다. |
| `properties.cvssv3_baseScore` | 아니요 | CVSS v3 기본 점수 범위는 [0.0\$110.0](https://nvd.nist.gov/vuln-metrics/cvss)입니다. |
| `properties.cvssv2_severity` | 아니요 | CVSS v3 값을 사용할 수 없는 경우 CodeCatalyst는 CVSS v2 값을 검색합니다. |
| `properties.cvssv2_score` | 아니요 | CVSS v2 기본 점수 범위는 [0.0\$110.0](https://nvd.nist.gov/vuln-metrics/cvss)입니다. |
| `properties.severity` | 아니요 | 조사 결과의 심각도 수준을 지정하는 고정된 문자열 세트입니다. 최대 길이: 1,024자 |
| `defaultConfiguration.level` | 아니요 | 규칙의 기본 심각도입니다. |
## `result` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `ruleId` | 예 | 조사 결과를 참조하는 데 사용되는 규칙의 고유 식별자입니다. 최대 길이: 1,024자 |
| `ruleIndex` | 예 | 도구 구성 요소 `rules[]`에서 연결된 규칙의 인덱스입니다. |
| `message.text` | 예 | 결과를 설명하고 각 조사 결과에 대한 메시지를 표시하는 메시지입니다. 최대 길이: 3,000자 |
| `rank` | 아니요 | 결과의 우선 순위 또는 중요도를 나타내는 0.0\$1100.0 사이의 값입니다. 이 규모의 값은 0.0이 가장 낮은 우선 순위이고 100.0이 가장 높은 우선 순위입니다. |
| `level` | 아니요 | 결과의 심각도입니다. 최대 길이: 1,024자 |
| `properties.unscore` | 아니요 | 스캔 조사 결과의 점수가 매겨졌는지 여부를 나타내는 플래그입니다. |
| `properties.score.severity` | 아니요 | 조사 결과의 심각도 수준을 지정하는 고정된 문자열 세트입니다. 최대 길이: 1,024자 |
| `properties.cvssv3_baseSeverity` | 아니요 | [일반 취약성 점수 체계 v3.1](https://www.first.org/cvss/v3.1/specification-document)의 정성적 심각도 등급입니다. |
| `properties.cvssv3_baseScore` | 아니요 | CVSS v3 기본 점수 범위는 [0.0\$110.0](https://nvd.nist.gov/vuln-metrics/cvss)입니다. |
| `properties.cvssv2_severity` | 아니요 | CVSS v3 값을 사용할 수 없는 경우 CodeCatalyst는 CVSS v2 값을 검색합니다. |
| `properties.cvssv2_score` | 아니요 | CVSS v2 기본 점수 범위는 [0.0\$110.0](https://nvd.nist.gov/vuln-metrics/cvss)입니다. |
| `properties.severity` | 아니요 | 조사 결과의 심각도 수준을 지정하는 고정된 문자열 세트입니다. 최대 길이: 1,024자 |
| `locations[]` | 예 | 결과가 감지된 위치 집합입니다. 지정된 모든 위치에서 변경해야만 문제를 해결할 수 있는 경우가 아니라면 한 위치만 포함해야 합니다. CodeCatalyst는 위치 배열의 첫 번째 값을 사용하여 결과에 주석을 지정합니다. 최대 `location` 객체 개수: 10 |
| `relatedLocations[]` | 아니요 | 조사 결과에서 참조하는 추가 위치 목록입니다. 최대 `location` 객체 개수: 50 |
| `fixes[]` | 아니요 | 스캔 도구에서 제공하는 권장 사항을 나타내는 `fix` 객체 배열입니다. CodeCatalyst는 `fixes` 배열에서 첫 번째 권장 사항을 사용합니다. |
## `location` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `physicalLocation` | 예 | 아티팩트와 리전을 식별합니다. |
| `logicalLocations[]` | 아니요 | 아티팩트를 참조하지 않고 이름으로 설명하는 위치 집합입니다. |
## `physicalLocation` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `artifactLocation.uri` | 예 | 아티팩트의 위치를 나타내는 URI로, 일반적으로 리포지토리에 있거나 빌드 중에 생성된 파일입니다. |
| `fileLocation.uri` | 아니요 | 파일 위치를 나타내는 대체 URI입니다. `artifactLocation.uri`가 빈 상태를 반환하는 경우 사용됩니다. |
| `region.startLine` | 예 | 리전의 첫 번째 문자의 행 번호입니다. |
| `region.startColumn` | 예 | 리전의 첫 번째 문자의 열 번호입니다. |
| `region.endLine` | 예 | 리전의 마지막 문자의 행 번호입니다. |
| `region.endColumn` | 예 | 리전의 마지막 문자의 열 번호입니다. |
## `logicalLocation` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `fullyQualifiedName` | 아니요 | 결과의 위치를 설명하는 추가 정보입니다. 최대 길이: 1,024자 |
## `fix` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `description.text` | 아니요 | 각 조사 결과에 대한 권장 사항을 표시하는 메시지입니다. 최대 길이: 3,000자 |
| `artifactChanges.[0].artifactLocation.uri` | 아니요 | 업데이트해야 하는 아티팩트의 위치를 나타내는 URI입니다. |