기본 테스트

테스트는 기본적으로 4개의 사전 정의된 정규화된 레시피에서 활성화됩니다. 테스트 이름: boot, login, packages 및 network. 이들은 작은 손님이다 수표는 완전한 승인 세트가 아닙니다. 레시피는 테스트를 비활성화하거나 목록을 대체하고 일부 아티팩트 유형은 더 좁은 계약을 사용합니다.

기본값이 실제로 증명하는 것

Ubuntu 24.04 CIS 경로는 일반 네트워크 검사를 제거하고 해당 검사를 사용합니다. 대신 준비 상태에 따른 기능 어설션을 사용하세요. 예상외의 레시피 인터넷 경로에서는 실패한 일반 네트워크 검사가 경고로 변환될 수 있습니다.

기능 및 성능 확인

또한 실행기는 활성화된 기능 메타데이터, 레거시에서 제공하는 검사를 병합합니다. 후크 테스트 파일, 동결된 기능 계획, 명시적 사용자 정의 테스트 등 벤치마크 테스트. 중복된 어설션이 제거됩니다. 알려진 어설션 누락된 매개변수는 서버 경고와 함께 삭제됩니다. 결과를 검토 테스트 계획을 세워 수표를 떨어뜨려도 합격으로 착각하지 않도록 합니다.

예를 들어 구성된 SSH 포트, 서비스 상태, 요청된 포트 확인 등이 있습니다. 패키지 또는 레시피별 아티팩트. 적용 범위는 활성화된 항목에 따라 다릅니다. 기능: 기능을 포함한다고 해서 기능이 다음과 같이 보장되는 것은 아닙니다. 완전한 주장 세트.

결과 읽기

집계 배지뿐만 아니라 주장 행과 증거를 사용합니다.

• passed는 실행 가능한 검사가 예상한 결과를 반환했음을 의미합니다.
• failed는 검사가 실행되어 예상과 ​​모순되었음을 의미합니다.
• error는 하네스가 판정을 내릴 수 없음을 의미합니다.
• skipped는 검사가 실행되지 않았음을 의미합니다. 예를 들어 대상 VM이 결석.

오류와 건너뛰기는 통과가 아닙니다. 완성된 이미지와 통과된 테스트 실행은 다음과 같습니다. 별도의 주; 인증은 세 번째 관문입니다.

더 강력한 승인 기준 정의

실제 워크로드의 경우 프롬프트 관련 어설션을 추가하세요. 예를 들면:

{
  "description": "Nginx serves the local health endpoint",
  "assertions": [
    {
      "type": "service_running",
      "description": "Nginx is active",
      "params": { "service": "nginx" }
    },
    {
      "type": "http_responds",
      "description": "Health endpoint returns 200",
      "params": { "url": "http://localhost/health", "status": 200 }
    }
  ]
}

그런 다음 콘솔에서 빌드된 이미지를 검사하고 하드웨어 바인딩 클레임의 경우 대표적인 하드웨어에서 테스트해 보세요. Custom assertions 참조 및 Assertion types.