KR102089284B1 - 클라우드 검증 및 테스트 자동화 - Google Patents

Abstract

다양한 통신 시스템들은 개선된 클라우드 검증 플랫폼으로부터 이득을 얻을 수 있다. 예컨대, 자동화되고 시스템적인 방식으로 클라우드 애플리케이션을 대신하여 기저 클라우드 인프라구조를 테스팅 및 검증할 수 있는 클라우드 검증 플랫폼이 도움이 될 수 있다. 방법은, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하는 단계를 포함할 수 있다. 방법은 또한, 클라우드 인프라구조 상에서의 가상 네트워크 기능의 실행을 트리거링하는 단계를 포함할 수 있다. 부가적으로, 방법은, 클라우드 검증 서비스를 사용하여, 실행된 가상 네트워크 기능으로 클라우드 인프라구조의 키 속성을 테스팅하는 단계를 포함할 수 있다. 추가로, 방법은 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 사용자 장비에 전송하는 단계를 포함할 수 있다.

Description

클라우드 검증 및 테스트 자동화

[0001] 본 출원은 2016년 2월 26일자로 출원된 미국 가출원 제 62/300,512호의 이점을 주장하고 그 가출원을 우선권으로 주장하며, 그로써 그 가출원은 그 전체가 인용에 의해 포함된다.

[0002] 다양한 통신 시스템들은 개선된 클라우드 인프라구조 테스팅으로부터 이득을 얻을 수 있다. 예컨대, 자동화되고 시스템적인 방식으로 클라우드 상에서 실행되는 애플리케이션을 대신하여 클라우드 인프라구조를 테스팅 및 검증할 수 있는 클라우드 검증 플랫폼이 도움이 될 수 있다.

[0003] 클라우드 컴퓨팅 시스템들은 정보 기술의 시대에서 점점 중요해지고 있다. 클라우드 컴퓨팅은 많은 상이한 산업들에서 많은 타입들의 애플리케이션들을 구동시키는 데 사용될 수 있는 설정된 및 성숙한(mature) 기술이다. 그러나, 원격통신 네트워크들에서, 클라우드 컴퓨팅은 여전히 신생 기술이며, 원격통신 네트워크들의 지속적인 발전에 중요한 역할을 할 가망이 있다.

[0004] 클라우드 컴퓨팅 인프라구조 상의 원격통신 애플리케이션들의 배치를 지원하기 위한 툴들 및 서비스들의 개발은 잘 확립되지 않았다. 클라우드 컴퓨팅 인프라구조는 유연하지만 복잡하며, 하드웨어, 운영 시스템들, 하이퍼바이저들, 컨테이너들, 애플리케이션들, 및 서비스들 모두가 클라우드의 기능을 지원하기 위해 함께 동작하게 한다. 클라우드 컴퓨터 인프라구조의 유연성에도 불구하고, 인프라구조 및 인프라구조 상에서 구동되는 애플리케이션들의 성능 및 상호작용은 가변적이고 예측가능하지 않을 수 있다. 따라서, 클라우드 컴퓨팅 인프라구조 상에서 구동되는 소프트웨어 애플리케이션들은 종종 예상되는 바와 같이 수행되지 않을 수 있다.

[0005] 예측불가능성은 원격통신 애플리케이션들에서 다양한 문제들을 야기할 수 있으며, 그들 중 일부는 엄격한 요건들, 이를테면 네트워킹을 위한 정밀한 레이턴시 및 대역폭 필요성들을 갖는다. 원격통신 애플리케이션을 클라우드 컴퓨팅 인프라구조 상에 성공적으로 배치시키기 위해, 인프라구조는 먼저 동작, 신뢰성, 및 성능에 대해 테스팅되어야 한다. 클라우드 거동의 동적 그리고 가변 속성이 주어지면, 클라우드 인프라구조 상에서의 이들 애플리케이션들의 실행을 테스팅하는 것은 어렵고 시간-소모적일 수 있다.

[0006] 클라우드 컴퓨팅 인프라구조 상에 다수의 원격통신 애플리케이션들을 배치하려고 시도하는 것은 이러한 문제를 악화시킬 수 있다. 애플리케이션들 각각은 그들이 클라우드에 부과하는 상이한 작업로드, 컴퓨팅, 저장, 및 네트워킹 요건들을 가질 수 있다. 클라우드 인프라구조를 테스팅하는 비용 및 시간은 특히, 통계적으로 상당한 양들의 데이터가 정확한 측정들을 제공하기 위해 수집되어야 하는 경우 클 수 있다.

[0007] 방법은, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하는 단계를 포함할 수 있다. 방법은 또한, 클라우드 인프라구조 상에서의 가상 네트워크 기능의 실행을 트리거링하는 단계를 포함할 수 있다. 클라우드 인프라구조의 키(key) 속성은 클라우드 검증 서비스를 사용하여, 실행된 가상 네트워크 기능으로 테스팅된다. 부가적으로, 방법은 사용자 장비에서 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하는 단계를 포함할 수 있다.

[0008] 특정한 실시예들에 따르면, 장치는 컴퓨터 프로그램 코드를 포함하는 적어도 하나의 메모리, 및 적어도 하나의 프로세서를 포함할 수 있다. 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하도록 구성될 수 있다. 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 클라우드 인프라구조 상에서의 가상 네트워크 기능의 실행을 트리거링하도록 또한 구성될 수 있다. 클라우드 인프라구조의 키 속성은 클라우드 검증 서비스를 사용하여, 실행된 가상 네트워크 기능으로 테스팅된다. 부가적으로, 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 사용자 장비에서 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하도록 구성될 수 있다.

[0009] 특정한 실시예들에서, 장치는, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하기 위한 수단을 포함할 수 있다. 장치는 또한, 클라우드 인프라구조 상에서의 가상 네트워크 기능의 실행을 트리거링하기 위한 수단을 포함할 수 있다. 클라우드 인프라구조의 키 속성은 클라우드 검증 서비스를 사용하여, 실행된 가상 네트워크 기능으로 테스팅된다. 부가적으로, 방법은 사용자 장비에서 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하는 단계를 포함할 수 있다.

[0010] 특정한 실시예들에 따르면, 비-일시적인 컴퓨터-판독가능 매체는, 하드웨어에서 실행될 경우 프로세스를 수행하는 인코딩한 명령들을 갖는다. 프로세스는, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하는 단계를 포함할 수 있다. 프로세스는 또한, 클라우드 인프라구조 상에서의 가상 네트워크 기능의 실행을 트리거링하는 단계를 포함할 수 있다. 클라우드 인프라구조의 키 속성은 클라우드 검증 서비스를 사용하여, 실행된 가상 네트워크 기능으로 테스팅된다. 부가적으로, 프로세스는 사용자 장비에서 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하는 단계를 포함할 수 있다.

[0011] 특정한 실시예들에 따르면, 컴퓨터 프로그램 제품은, 방법에 따라 프로세스를 수행하기 위한 인코딩한 명령들을 가지며, 그 방법은 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하는 단계를 포함한다. 방법은 또한, 클라우드 인프라구조 상에서의 가상 네트워크 기능의 실행을 트리거링하는 단계를 포함할 수 있다. 클라우드 인프라구조의 키 속성은 클라우드 검증 서비스를 사용하여, 실행된 가상 네트워크 기능으로 테스팅된다. 부가적으로, 방법은 사용자 장비에서 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하는 단계를 포함할 수 있다.

[0012] 방법은, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하는 단계를 포함할 수 있다. 방법은 또한, 플랫폼 디바이스에 의한 클라우드 인프라구조의 키 속성의 테스팅을 스케줄링하는 단계를 포함할 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 부가적으로, 방법은 스케줄을 테스트 에이전트에 전송하는 단계를 포함할 수 있다. 추가로, 방법은 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하는 단계를 포함할 수 있다.

[0013] 특정한 실시예들에 따르면, 장치는 컴퓨터 프로그램 코드를 포함하는 적어도 하나의 메모리, 및 적어도 하나의 프로세서를 포함할 수 있다. 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하도록 구성될 수 있다. 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 플랫폼 디바이스에 의한 클라우드 인프라구조의 키 속성의 테스팅을 스케줄링하도록 또한 구성될 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 부가적으로, 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 스케줄을 테스트 에이전트에 전송하도록 또한 구성될 수 있다. 추가로, 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하도록 구성될 수 있다.

[0014] 특정한 실시예들에서, 장치는, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하기 위한 수단을 포함할 수 있다. 장치는 또한, 플랫폼 디바이스에 의한 클라우드 인프라구조의 키 속성의 테스팅을 스케줄링하기 위한 수단을 포함할 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 부가적으로, 장치는 스케줄을 테스트 에이전트에 전송하기 위한 수단을 포함할 수 있다. 추가로, 방법은 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하기 위한 수단을 포함할 수 있다.

[0015] 특정한 실시예들에 따르면, 비-일시적인 컴퓨터-판독가능 매체는, 하드웨어에서 실행될 경우 프로세스를 수행하는 인코딩한 명령들을 갖는다. 프로세스는, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하는 단계를 포함할 수 있다. 프로세스는 또한, 플랫폼 디바이스에 의한 클라우드 인프라구조의 키 속성의 테스팅을 스케줄링하는 단계를 포함할 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 부가적으로, 프로세스는 스케줄을 테스트 에이전트에 전송하는 단계를 포함할 수 있다. 추가로, 프로세스는 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하는 단계를 포함할 수 있다.

[0016] 특정한 실시예들에 따르면, 컴퓨터 프로그램 제품은, 방법에 따라 프로세스를 수행하기 위한 인코딩한 명령들을 가지며, 그 방법은 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하는 단계를 포함한다. 방법은 또한, 플랫폼 디바이스에 의한 클라우드 인프라구조의 키 속성의 테스팅을 스케줄링하는 단계를 포함할 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 부가적으로, 방법은 스케줄을 테스트 에이전트에 전송하는 단계를 포함한다. 추가로, 방법은 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 수신하는 단계를 포함할 수 있다.

[0017] 방법은 클라우드 인프라구조의 키 속성에 대해 테스팅하기 위한 요청을 플랫폼 디바이스로부터 수신하는 단계를 포함할 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 방법은 또한, 가상 네트워크 기능 및 클라우드 인프라구조의 키 속성에 대해 테스팅하는 단계를 포함할 수 있다. 부가적으로, 방법은 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 플랫폼 디바이스에 전송하는 단계를 포함할 수 있다.

[0018] 특정한 실시예들에 따르면, 장치는 컴퓨터 프로그램 코드를 포함하는 적어도 하나의 메모리, 및 적어도 하나의 프로세서를 포함할 수 있다. 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 클라우드 인프라구조의 키 속성에 대해 테스팅하기 위한 요청을 플랫폼 디바이스로부터 수신하도록 구성될 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 가상 네트워크 기능 및 클라우드 인프라구조의 키 속성에 대해 테스팅하도록 또한 구성될 수 있다. 부가적으로, 적어도 하나의 메모리 및 컴퓨터 프로그램 코드는 적어도 하나의 프로세서와 함께, 적어도, 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 플랫폼 디바이스에 전송하도록 또한 구성될 수 있다.

[0019] 특정한 실시예들에서, 장치는 클라우드 인프라구조의 키 속성에 대해 테스팅하기 위한 요청을 플랫폼 디바이스로부터 수신하기 위한 수단을 포함할 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 장치는 또한, 가상 네트워크 기능 및 클라우드 인프라구조의 키 속성에 대해 테스팅하기 위한 수단을 포함할 수 있다. 부가적으로, 장치는 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 플랫폼 디바이스에 전송하기 위한 수단을 포함할 수 있다.

[0020] 특정한 실시예들에 따르면, 비-일시적인 컴퓨터-판독가능 매체는, 하드웨어에서 실행될 경우 프로세스를 수행하는 인코딩한 명령들을 갖는다. 프로세스는 클라우드 인프라구조의 키 속성에 대해 테스팅하기 위한 요청을 플랫폼 디바이스로부터 수신하는 단계를 포함할 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 프로세스는 또한, 가상 네트워크 기능 및 클라우드 인프라구조의 키 속성에 대해 테스팅하는 단계를 포함할 수 있다. 부가적으로, 프로세스는 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 플랫폼 디바이스에 전송하는 단계를 포함할 수 있다.

[0021] 특정한 실시예들에 따르면, 컴퓨터 프로그램 제품은, 방법에 따라 프로세스를 수행하기 위한 인코딩한 명령들을 가지며, 그 방법은 클라우드 인프라구조의 키 속성에 대해 테스팅하기 위한 요청을 플랫폼 디바이스로부터 수신하는 단계를 포함한다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 방법은 또한, 가상 네트워크 기능 및 클라우드 인프라구조의 키 속성에 대해 테스팅하는 단계를 포함할 수 있다. 부가적으로, 방법은 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭을 플랫폼 디바이스에 전송하는 단계를 포함할 수 있다.

[0022] 본 발명의 적절한 이해를 위해, 첨부한 도면들에 대한 참조가 행해져야 한다.
[0023] 도 1은 특정한 실시예들에 따른 시스템 아키텍처를 예시한다.
[0024] 도 2는 특정한 실시예들에 따른 흐름도를 예시한다.
[0025] 도 3은 특정한 실시예들에 따른 흐름도를 예시한다.
[0026] 도 4는 특정한 실시예들에 따른 시스템 아키텍처를 예시한다.
[0027] 도 5는 특정한 실시예들에 따른 시스템 아키텍처를 예시한다.
[0028] 도 6은 특정한 실시예들에 따른 사용자 인터페이스를 예시한다.
[0029] 도 7은 특정한 실시예들에 따른 흐름도를 예시한다.
[0030] 도 8은 특정한 실시예들에 따른 흐름도를 예시한다.
[0031] 도 9a는 특정한 실시예들에 따른 토폴로지를 예시한다.
[0032] 도 9b는 특정한 실시예들에 따른 토폴로지 다이어그램을 예시한다.
[0033] 도 9c는 특정한 실시예들에 따른 토폴로지를 예시한다.
[0034] 도 10은 특정한 실시예들에 따른 흐름도를 예시한다.
[0035] 도 11은 특정한 실시예들에 따른 시스템 아키텍처를 예시한다.
[0036] 도 12는 특정한 실시예들에 따른 흐름도를 예시한다.
[0037] 도 13은 특정한 실시예들에 따른 흐름도를 예시한다.
[0038] 도 14는 특정한 실시예들에 따른 사용자 인터페이스를 예시한다.
[0039] 도 15는 특정한 실시예들에 따른 사용자 인터페이스를 예시한다.
[0040] 도 16은 특정한 실시예들에 따른 흐름도를 예시한다.
[0041] 도 17은 특정한 실시예들에 따른 흐름도를 예시한다.
[0042] 도 18은 특정한 실시예들에 따른 흐름도를 예시한다.
[0043] 도 19a는 특정한 실시예들에 따른 흐름도를 예시한다.
[0044] 도 19b는 특정한 실시예들에 따른 흐름도를 예시한다.
[0045] 도 20은 특정한 실시예들에 따른 시스템을 예시한다.

[0046] 특정한 실시예들은, 클라우드 인프라구조 상에서 구동되는 원격통신 애플리케이션의 성능의 분석을 허용하는 일관된 테스트를 제공한다. 테스트는, 테스트들이 서로 비교될 수 있도록 다양한 원격통신 애플리케이션들에 대해 재생성될 수 있다.

[0047] 특정한 실시예들은 또한, 글로벌 서비스 조직들, 이를테면 시스템 통합, 네트워크 계획 및 최적화, 및 케어(care) 서비스들에 유익할 수 있다. 클라우드 컴퓨팅 인프라구조 상에서 구동할 애플리케이션들을 개발하고 있는 제품 개발 조직들이 또한 이득을 얻을 수 있다. 몇몇 실시예들은, 예컨대 IMS, TAS, 모빌리티 관리 엔티티, EPC, Flexi-NG, 및 클라우드 라디오 액세스 네트워크(RAN)를 포함하는 네트워크 코어 및 RAN 제품들에 적용된다. 자신들의 성능 요건들을 충족시키기 위해 안정적이고 고성능의 하드웨어 및 소프트웨어 플랫폼에 의존하는 다른 제품들이 또한 이득을 얻을 수 있다.

[0048] 테스팅 및 자동화를 위한 방법은, 애플리케이션이 실제 세계에서 클라우드 인프라구조에 의해 서비스되고 있었던 것처럼 그 애플리케이션이 테스팅되게 허용할 수 있는 주어진 모드에서 클라우드 환경의 성능을 평가하는 데 사용될 수 있다. 이러한 모드는 서비스 모드로 알려져 있을 수 있다. 특정한 실시예들에서, 다수의 클라우드들의 테스트들은 단일 로직 서비스로부터 편성(orchestrate)될 수 있다. 다수의 클라우드들은 변경될 수 있다. 몇몇 실시예들은 가변적인 인터넷 액세스를 이용한, 또는 심지어 인터넷 액세스 없는, 또는 프록시를 통한 인터넷 액세스를 이용한 클라우드들을 수반한다.

[0049] 특정한 실시예들은 서비스들의 자동화된 선택 및 재할당을 위해 테스트 노드들을 그들의 가용성 및 특정한 클라우드에 연결되기 위한 능력에 기반하여 클라우드에 제공할 수 있다. 몇몇 클라우드 환경이 방화벽들을 포함할 수 있으므로, 특정한 실시예들은 어떤 노드가 클라우드에 연결되는지를 서비스가 발견하게 허용할 수 있다. 몇몇 주어진 연결들은 방화벽에 의해 차단되지 않을 수 있으며, 그 연결들은 자동화된 방식으로 테스트들을 구동시키기 위해 선택될 수 있다.

[0050] 테스팅은 상이한 구성들 및 인자들을 이용하여 다수회 반복들로 구동함으로써 클라우드의 배치를 최적화시키는 데 사용될 수 있다. 테스팅의 결과들은 성능 및 비용들에 대한 최적의 클라우드 구성을 결정하는 것을 허용할 수 있다.

[0051] 몇몇 실시예들에서, 테스트 환경들을 프로비저닝(provision)하는 것은 클라우드의 타입과 독립적일 수 있다. 즉, 테스트 환경은 다양한 클라우드 타입들에 걸쳐 적용될 수 있는 단일 테스트 정의를 가질 수 있다. 상이한 클라우드 타입들이 런칭될 가상 인스턴스의 구성을 참조하기 위해 상이한 방식들을 사용하더라도, 단일 테스트 정의는 다양한 클라우드 타입들에 걸친 테스팅이 일관되게 허용할 수 있다.

[0052] 몇몇 인터넷 프로토콜(IP) 어드레스들만이 동적 호스트 구성 프로토콜에 의해 클라우드에 할당된 풀(pool)로부터 사용될 수 있는 경우라도, 다른 실시예들은 클라우드 환경에서 테스트들을 구동시킬 수 있다. 그러나, 다른 실시예들에서, 클라우드 서비스들에 대한 액세스를 갖지 않을 수 있는 가상 머신들은 클라우드 서비스들에 액세스하기 위해 프록시 요청들을 사용할 수 있다. 특정한 실시예들에서, 가상 머신들은 클라우드 내로부터 클라우드 서비스 테스트들을 구동시킬 수 있다.

[0053] 클라우드들에 걸친 테스트 결과들은 자동화된 방식으로 비교될 수 있다. 테스트 결과들은 클라우드 성능의 등급을 매기는 데 사용될 수 있다. 몇몇 실시예들에서, 등급은 다수의 테스트 결과들에 기반하여, 자동화된 임계치에 따라 조정될 수 있다. 다른 실시예들에서, 유연한 메커니즘이 새로운 테스트 플러그인 온-보딩(on-boarding)을 위해 제공될 수 있다. 플러그인 부가는, 가상 네트워크 기능 팀들이 종래의 제품들보다 더 빠르게 새로운 플러그인들에 기여하게 허용함으로써 간략화될 수 있다. 클라우드 인프라구조에 수반된 가능한 위험들 또는 갭들에 대한 임의의 권고들과 함께 클라우드 인프라구조 자산들의 평가를 포함하는 리포트가 생성될 수 있다.

[0054] 특정한 실시예들은 또한, 자동화된 테스트 벡터들의 포트폴리오를 이용하여, 이용가능한 클라우드 서비스들, 및 네트워킹, 컴퓨팅, 및 저장 메트릭들에 걸쳐 테스팅하는 플랫폼을 생성하기 위한 방법을 포함한다. 몇몇 실시예들에서, 포트폴리오는 천개 초과의 자동화된 테스트 벡터들을 포함할 수 있다. 텔레콤(telecom) 소프트웨어에 대해 할당된 클라우드의 구역들에서의 네트워킹, 컴퓨팅, 및 저장의 활성 성능의 테스트들을 포함하는 클라우드 컴퓨팅 검증 서비스가 또한 생성될 수 있다.

[0055] 몇몇 실시예들에서, 클라우드 테스팅은 단일 또는 멀티-테넌트(multi-tenant) 환경 상에서의 많은 수의 동시 테스트들에서 런칭, 구동, 및 모니터링될 수 있다. 결과들은 상세한 측정들 및 분석의 이해를 가속화시키기 위해 시각적인 형태로 제시될 수 있다. 사용자 인터페이스는 측정들 및 분석의 뷰잉을 허용하기 위해 생성되며, 뷰어가 분석을 이해하게 허용할 챠트, 테이블, 그래프의 형태, 또는 임의의 다른 시각적인 형태로 뷰어에게 제시될 수 있다.

[0056] 몇몇 테스트들은 클라우드 인프라구조 및 가상화된 애플리케이션들의 성능을 평가하는 데 도움을 줄 수 있다. 평가는, 가상화된 네트워크 기능 애플리케이션 소프트웨어 제품들에 대한 최소 성능 요건들을 보장하기 위해 클라우드 컴퓨팅 인프라구조를 체크하는 것을 포함할 수 있다. 테스팅은 클라우드 인프라구조에서 애플리케이션을 구동시키는 성능을 평가하기 위해 원격통신 소프트웨어 애플리케이션을 나타내는 작업로드를 에뮬레이팅(emulate)할 수 있다. 이러한 에뮬레이션은, 애플리케이션이 클라우드 인프라구조와 상호작용하는 실제 세계 시나리오의 가상 시뮬레이션을 허용할 수 있다.

[0057] 특정한 실시예들은, 가상 머신들 사이에서의, 송신 제어 프로토콜(TCP), 사용자 데이터그램 프로토콜(UDP), 및 스트림 제어 송신 프로토콜(SCTP)과 같은 상이한 프로토콜들의 전달의 네트워크 성능을 테스팅하는 것을 수반한다. 하나의 가상 스위치 내에서 또는 가상 스위치 경계들에 걸쳐 전달되는 범위 패킷 사이즈들은 테스팅 동안 클라우드를 벤치마킹(benchmark)하고 결과들을 기준 요건들과 비교하는 데 사용될 수 있다. 몇몇 실시예들에서, 요건들은 미리 결정될 수 있다. 특정한 실시예들에서, 블랙 해싱(Black Hashing) 알고리즘이 클라우드 인프라구조의 계산 능력을 테스팅하기 위해 사용될 수 있다.

[0058] 대안적으로, 몇몇 실시예들은 가상 머신들과 외부 게이트웨이 경계 사이에서의 TCP, UDP, 및 SCTP와 같은 상이한 프로토콜들의 전달의 네트워크 성능을 테스팅하는 것을 수반할 수 있다. 네트워크 성능은 테스팅되는 클라우드에 대한 벤치마크로서 사용될 수 있으며, 그 후, 결과들은 기준 요건과 비교될 수 있다.

[0059] 위에서 논의된 테스팅 실시예들은 애플리케이션의 설계 및 개발 페이즈에서 애플리케이션들의 연속적인 테스팅을 허용할 수 있다. 따라서, 테스팅은 클라우드 인프라구조의 최소 성능 요건들과 애플리케이션의 완전한 기능 사이의 매치를 검증하는 데 사용될 수 있으며, 이는 애플리케이션이 적절히 기능하는 데 필요할 수 있다.

[0060] 특정한 실시예들은 인프라구조의 클라우드 테스팅으로부터 수집된 데이터에 머신 및 딥 러닝(deep learning)을 적용할 수 있다. 벤치마크들 및 키 성능 표시자(KPI)들은 비교 애플리케이션 테스팅을 위해 저장될 수 있다. 시스템은, 클라우드의 편차들, 비정상들 및 정상적인 거동의 복잡한 상관관계들 및 표시들을 제공하기 위해 머신 러닝을 이용할 수 있다. 수집된 데이터는 동일한 인프라구조의 이전의 테스트들 뿐만 아니라 비교를 위한 다른 클라우드들로부터의 테스트들과 비교될 수 있다. 비교를 위해 사용된 이전의 데이터는 단일 테스트로부터의 것일 수 있거나, 또는 다수의 순차적인 또는 병렬 테스트들에 걸쳐 누산될 수 있고, 이는 이전의 테스트들의 통계적인 유효성을 개선시킬 수 있다. 테스트는 또한, 클라우드 및 그의 거동의 특정한 시간 및 콘텍스트-변형 특징들을 캡처할 수 있다.

[0061] 클라우드 테스팅으로부터 수집된 데이터의 실시간 및 후속 분석이 또한 발생할 수 있다. 특정한 실시예들은 또한, 클라우드 인프라구조에서 또는 애플리케이션 레벨에서 기능 또는 성능 문제들을 야기할 수 있는 미래의 잠재적인 조건들에 기반하여 모니터링될 필요가 있을 수 있는 추세들 및 미래의 비정상들, 또는 특정한 파라미터들을 예측하는 데 사용될 수 있다.

[0062] 몇몇 실시예들에서, 클라우드에서 적소에 놓여진 보안 조치들의 정확한 기능의 평가가 수행될 수 있다. 보안 특성들의 존재 및 검증된 기능이 수행될 수 있고, 리포트가 생성될 수 있다. 클라우드는 또한, 자동화된 위협 공격에 의해, 그러한 공격들에 대한 클라우드의 탄력성 및 견고성을 평가하도록 분산 서비스 거부 및 피싱과 같은 보안 위협들에 대해 테스팅될 수 있다. 다른 실시예들은 다양한 결함 조건들을 사용함으로써 클라우드에서 구동되는 애플리케이션의 높은 가용성을 테스팅할 수 있다. 결함 조건들은 다양한 타입들의 실제 세계 결함들을 에뮬레이팅할 수 있다. 결함들 뿐만 아니라 결함 조건들에 대한 클라우드의 응답이 모니터링될 수 있다.

[0063] 클라우드 성능 인덱스 및 랭킹은 다수의 인프라구조 테스팅 KPI들로부터 생성되고, 비교를 위해 사용되는 기준선 또는 벤치마크에 대해 계산될 수 있다. 잠재적인 클라우드 용량 문제들이 발생되기 전에 그들을 예측하기 위해, 성능 데이터가 사용될 수 있으며, 메트릭들이 모니터링되어 통신 네트워크의 트래픽 패턴들과 상관될 수 있다. 동일한 클라우드 또는 상이한 클라우드들로부터의 다수의 테스트 결과들은 사용자 인터페이스에서 시각적으로 표현될 수 있다. 이것은 현재의 결과들과 기준선 사이의 차이들의 평가 및 결과들의 오버레이(overlay)를 허용할 수 있다.

[0064] 특정한 실시예들에서, 테스팅된 클라우드들의 데이터베이스, 및 클라우드에 관한 정보, 이를테면 그의 하드웨어, 소프트웨어, 하이퍼바이저, 및 구성들이 관리될 수 있다. 정보 및 테스트 결과들은 어그리게이팅, 동기화, 아카이빙(archive), 클러스터링, 또는 그룹화될 수 있다. 이것은, 테스트들이 하나의 장소로부터 구동되기보다는 구역적으로 또는 현장에서 행해지더라도, 결과들의 논리적 중앙화를 허용할 수 있다. 테스트 결과들의 관리는 또한, 기준 클라우드와의 비교를 포함하여, 현재 테스팅된 데이터의 이전의 테스트들과의 비교를 허용할 수 있다. 한편, 다른 실시예들은 다수의 클라우드들의 결과들의 분석 및 클라우드들 및 구성들의 변동성을 디스플레이하는 것을 허용한다.

[0065] 몇몇 실시예들은 원-클릭 접근법을 이용할 수 있다. 원-클릭 접근법에서, 버튼의 누름 또는 클릭과 같은 사용자에 의한 단일 개시 액션은 테스트들을 개시할 수 있다. 테스트들은 테스트 메뉴를 통해 이전에 정의되거나 스케줄링될 수 있으며, 그에 의해, 테스트들이 단일 버튼의 누름 또는 클릭을 이용하여 자동적으로 진행하게 허용한다.

[0066] 애플리케이션 및 클라우드 인프라구조의 테스팅은 또한, 클라우드에서 트래픽의 스케일링 업 및/또는 스케일링 다운을 평가하는 것을 수반할 수 있다. 예컨대, 클라우드는 클라우드 인프라구조의 급격한 수요 변화들에 대한 응답으로 부가적인 가상 머신들을 생성하기 위한 능력을 가질 수 있다. 그러한 평가는, 인프라구조 및 애플리케이션이 트래픽의 스케일링 업을 따라 잡는 것을 보장하고, 인프라구조가 트래픽 변화들에 대처할 수 없는 임의의 특정 제한들 또는 실패 포인트들을 표시하는 데 유용할 수 있다.

[0067] 특정한 실시예는 하나 또는 다수의 벤더들로부터의 핑거프린팅 애플리케이션 또는 가상화된 네트워크 기능을 이용할 수 있다. 핑거프린팅은 사용자가 KPI들을 분석하게 하고 애플리케이션을 실제 성능과 상관시키게 허용할 수 있다. 몇몇 실시예들에서, 머신 러닝은 성능 KPI들을 예측하는 데 사용될 수 있다. 예컨대, 클라우드에서 애플리케이션을 구현하기 전에 애플리케이션의 구성 및 하드웨어/소프트웨어 모델 거동들의 what-if 변경들이 행해질 수 있다.

[0068] 특정한 실시예들에서, 성능 검증은 높은 신뢰도 레벨을 유지할 수 있으면서, 필요한 시간의 일부에서 수행될 수 있다. 이러한 검증 접근법은 주어진 클라우드에서 매우 양호하게 구동되는 통상적인 핑거프린트들 및/또는 패턴들과 비교 및 매칭될 수 있는 애플리케이션의 핑거프린트들 및/또는 패턴들을 생성하기 위한 능력을 포함할 수 있다.

[0069] 특정한 실시예들에서, 핑거 프린팅 접근법은 가상 네트워크 기능 모델을 생성하기 위해 학습하는 머신을 사용하는 것을 포함할 수 있다. 그 후, 머신은 타겟 클라우드의 인프라구조 성능을 측정하고, 성능 데이터 및/또는 의도된 트래픽 모델을 가상 네트워크 기능 모델에 적용하여, 신뢰도 레벨을 결정할 수 있다. 그 후, 성능 데이터의 피드백 루프가 배치될 수 있으며, 이는 데이터를 가상 네트워크 기능 모델에 역으로 전송할 수 있다.

[0070] 하나의 특정 실시예에서, 검증될 가상 네트워크 기능은 IP 멀티미디어 시스템(IMS)의 콜(call) 세션 제어 기능(CSCF) 서브시스템일 수 있다. IMS CSCF 모델은 이전에 수집된 성능 데이터, 예컨대 고객 클라우드 또는 랩(lab) 테스팅에서의 기존의 배치들로부터 생성될 수 있다. 그 후, 이러한 성능 데이터는 IMS 모델을 생성할 수 있는 머신 러닝 프레임워크를 통해 프로세싱될 수 있으며, 그 후, 이는 핑거프린트를 생성할 수 있다. 성능 데이터의 타입은, 예컨대 IMS 성능 KPI들 또는 인프라구조 성능 KPI들을 포함할 수 있다.

[0071] 그 후, 타겟 클라우드 인프라구조 성능 데이터가 수집 및 측정될 수 있다. 그 후, 예상되는 트래픽 모델과 함께 인프라구조 성능 데이터는 타겟 클라우드에서 의도되는 바와 같이 IMS가 구동되는 신뢰도 레벨 또는 가능성을 결정하기 위해 IMS 모델에 제공될 수 있다. 일단 IMS가 생산에서 사용될 수 있다면, 성능 데이터는 모델을 개선시키기 위해 머신 러닝 프레임워크에 대한 피드백 루프로서 이용될 수 있다.

[0072] 특정한 실시예들에서, 잔여 가상 머신들 및 자산들이 클라우드에 남아있을 수 있다. 특정한 실시예들에서, 이들 남겨진 가상 머신들 및 자산들은 자체-활성화될 수 있으며, 테스트들을 자동적으로 수행할 뿐만 아니라 임의의 외부 개입 없이 결과들을 리포팅할 수 있다. 그 후, 더 면밀한 테스트 레짐(regime)을 트리거링하기에 충분한 변화들이 검출되면, 가상 머신들 및 자산들은 경고를 리포팅 및 전송할 수 있다. 그 후, 감독 오퍼레이터는 면밀한 테스팅을 수행할 시간 및 방식을 결정할 수 있다.

[0073] 몇몇 실시예들은 분해된 모듈들을 클라우드에 삽입하는 것을 수반하는 애플리케이션들의 기능 분해를 허용할 수 있다. 그 후, 분해된 모듈들의 성능은 모듈 레벨에서 뿐만 아니라 전체 애플리케이션 레벨에서 테스팅될 수 있다. 잡음있는 이웃을 수반하는 조건이 또한 평가될 수 있다. 동일한 클라우드에서 다른 작업부하들의 존재 시에 클라우드 성능에 대한 잡음있는 이웃의 영향이 평가될 수 있다.

[0074] 위의 실시예들은 클라우드 인프라구조 상의 원격통신 애플리케이션의 테스팅을 수반할 수 있다. 다양한 결과들은, 네트워크 제공자가 동적 콜을 어떻게 할당할지 및 클라우드 메트릭들에 기반하여 트래픽을 어떻게 핸들링할지를 결정하게 허용할 수 있다.

[0075] 도 1은 특정한 실시예들에 따른 시스템 아키텍처를 예시한다. 예컨대, 시스템 아키텍처는 플랫폼(110)을 포함할 수 있다. 플랫폼(110)의 각각의 부분은 그 자체로 프로세서 및 메모리를 갖는 디바이스일 수 있다. 플랫폼의 제어기 부분은 클라우드 내부에 배치될 수 있다. 다른 실시예들에서, 플랫폼은 다수의 클라우드들이 동시에 테스팅되는 것을 지원하는 중앙 위치에 배치될 수 있다. 플랫폼(110)은 또한, 여전히 하나의 클러스터로서 논리적으로 볼 수 있는 멀티-노드 배치를 지원할 수 있다.

[0076] 스케쥴러(111)는 플랫폼의 코어 부분에 제공될 수 있다. 스케줄러는 특정한 테스트의 라이프사이클을 관리하는 주요 컴포넌트일 수 있다. 테스트의 라이프사이클은 수개의 페이즈들을 포함할 수 있다. 예컨대, 하나의 페이즈는, 테스트 인스턴스가 테스트 템플릿들의 리스트로부터 생성되고 특정 클라우드에 할당될 테스트 계획 페이즈일 수 있다. 그 후, 테스트는 스케줄링된 시간으로 구동되도록 구성 및 셋팅될 수 있다. 예컨대, 제2 페이즈는 테스트 인스턴스가 실행될 수 있는 테스트 실행 페이즈일 수 있다. 테스트의 진행 및 결과적인 테스트 메트릭들은 테스트의 지속기간의 적어도 일부 또는 테스트의 전체 지속기간 동안 모니터링될 수 있다.

[0077] 플랫폼(110)은 또한 수집기(112)를 포함할 수 있다. 수집기(112)는 중요한 테스트 관련 데이터의 수집을 수행할 수 있다. 예컨대, 테스트 진행, 테스트 결과들, 및 테스트 로그들이 수집기(112)에 의해 수집될 수 있다. 몇몇 실시예들에서, 데이터의 수집은 메시징 인터페이스, 이를테면 메시지 브로커 소프트웨어, 예컨대 RabbitMQ(113)를 통해 실시간으로 행해질 수 있다. 수집된 데이터 모두는 MongoDB와 같은 선택 데이터베이스(114)에 저장될 수 있다.

[0078] 특정한 실시예들에서, 플랫폼(110)은 편성기(orchestrator)(115)를 포함한다. 편성기(115)는 테스팅이 시작되기 전에 클라우드에서 하나 또는 그 초과의 테스트 클러스터들을 생성하는 것을 담당할 수 있다. 편성기(115)는 가상 머신 인스턴스들을 생성하고, 인스턴스들 사이의 네트워킹을 구성하며, 그 인스턴스들 상에 필요한 소프트웨어 패키지들을 설치할 수 있다. 플랫폼(110)은 아파치 2(Apache 2), 립클라우드(LibCloud) 및 앤서블(Ansible)과 같은 외부 서버들 또는 소프트웨어에 의해 보조될 수 있는 그 자신의 내부 편성기(115)를 가질 수 있다. 다른 실시예들에서, CAM과 같은 외부 편성 엘리먼트가 플랫폼(110)에 제공될 수 있다. 이러한 외부 편성 엘리먼트에서, 모든 동작들은 다양한 상이한 구현들 전반에 걸쳐 사용될 수 있는 단일 편성 인터페이스를 거칠 수 있다.

[0079] 분석기 및 리포터(116)는 또한 플랫폼(110)에 포함될 수 있다. 분석기 및 리포터(116)는 수집된 테스트 데이터를 분석하고, 클라우드 리소스 인덱스 및/또는 등급들을 생성하며, 최종 클라우드 리포트를 생성할 수 있다. 부가적으로, 이러한 컴포넌트는, 예컨대 클라우드의 지속적인 낮은 오버헤드 테스팅에 기반하여 클라우드 용량 문제들을 예측하기 위해 사용되는 머신 러닝 특성을 포함할 수 있다. 몇몇 실시예들에서, 스케줄러(111), 수집기(112), 편성기(115), 및 분석기 및 리포터(116)는 플랫폼(110)의 코어 기능의 일부일 수 있다.

[0080] 특정한 실시예들에서, 플랫폼(110)은 최종 리포트 생성기(117)를 포함할 수 있다. 다른 REST(representational state transfer) 컴포넌트들과 동일한 노드 상에 설치될 수 있는 일련의 커맨드-라인 툴들이 또한 포함될 수 있다. 최종 리포트 생성기는 사용자 인터페이스 상에 디스플레이된 그래프들을 포함하여, 테스팅된 결과들로부터 리포트를 생성하기 위해 필요한 기능을 제공할 수 있다. 리포트는 임의의 워드 프로세싱 소프트웨어와 호환가능할 수 있다. REST 애플리케이션 프로그램 인터페이스(API)가 또한 제공된다. REST API(118)는 클라우드 인프라구조 및 테스트 메타데이터를 노출시킬 수 있다. 그 후, REST API(118)는 테스팅된 메타데이터를 리포팅하고, 클라우드 동작들, 예컨대 테스트 클라우드 연결을 외부 애플리케이션들에 노출시킬 수 있다. 몇몇 실시예들에서, REST API는 외부 애플리케이션으로서 사용자 인터페이스(119)를 뷰잉할 수 있다.

[0081] 사용자 인터페이스(UI)(119)는 플랫폼(110)과 상호작용하기 위한 인터페이스를 제공할 수 있다. 특정한 실시예들에서, UI(119)는 웹 기반일 수 있다. UI(119)는 사용자들이 클라우드의 테스트들을 계획하게 하고, 테스트의 진행을 모니터링하게 하며, 생성된 리포트를 뷰잉 및/또는 다운로딩하게 허용할 수 있다.

[0082] 도 1에 도시된 실시예는 또한 테스트 에이전트(120)를 포함한다. 테스트 에이전트(120)는 플랫폼(110)에 의해 스케줄링된 테스트들을 실행하는 데에 도움을 준다. 테스트 에이전트(120)는 구동되는 테스트 경우들의 하나 또는 그 초과의 가상 머신 인스턴스들에 배치될 수 있다. 하트비트(heartbeat)(HBeat)(121)는 테스트 에이전트(120)에 포함될 수 있다. HBeat는 플랫폼(110)에 IsAlive 신호를 전송하는 것을 담당할 수 있다. 신호는, 에이전트가 스케줄링된 테스트를 수행할 준비가 되었다는 표시로서 플랫폼(110)에 의해 해석될 수 있다.

[0083] 리포터(122)가 또한 포함될 수 있다. 리포터(122)는 테스트 진행 업데이트들 및 테스트 결과들을 메시징 인터페이스를 통해 플랫폼(110)에 전송할 수 있다. 테스트 진행 업데이트들 및 결과들은 플랫폼(110)의 수집기(112)에 전송될 수 있다. 테스트 에이전트(120)는 또한, 테스트 에이전트의 로깅 동작들을 핸들링하는 로거(logger)(123)를 포함할 수 있다. 로거(123)는 테스트의 실행 페이즈 동안 플러그인들을 핸들링할 수 있다. 로거(123)에 의해 수집된 로그들은 메시징 인터페이스(113)를 통해 플랫폼(110)에 전송될 수 있다.

[0084] 특정한 실시예들에서, 플러깅가능한 실행기가 또한 제공된다. 플러깅가능한 실행기(124)는 플랫폼(110)에 의해 전송된 테스트 인스턴스에서 정의된 모든 테스트 경우들을 실행할 수 있다. 실행기(124)는 테스트 에이전트(120)의 플러그인 능력들을 통해 부가적인 새로운 테스트 경우 타입, 예컨대 SPECCPU20xx 테스트를 지원할 수 있다. 즉, 새로운 테스트 경우는 테스트 에이전트(120)의 코어 부분을 터치할 필요 없이 새로운 테스트 플러그인으로서 간단하게 개발될 수 있다.

[0085] 적어도 하나의 플러그인(125)이 테스트 에이전트(120)에 포함될 수 있다. 플러그인들(125)은 개별 테스트 경우 실행을 담당하는 개별 컴포넌트들일 수 있다. 그러한 개별 테스트 경우 실행은 실행 전 준비, 테스트 경우 실행, 및/또는 테스트 경우 결과들의 수집 및 리포팅을 포함할 수 있다.

[0086] 도 1에 도시된 실시예는 또한 모니터링 클라이언트(130)를 포함한다. 모니터링 클라이언트(130)는 테스트 클러스터들을 수반하는 몇몇 또는 모든 인스턴스들에 포함될 수 있다. 모니터링 클라이언트(130)는 클라우드 인프라구조의 하드웨어에 대한 리소스 사용도들을 수집하고, 테스트 모니터링 목적들을 위해 주기적으로 KPI들을 수집할 수 있다. 테스트 에이전트 및 플랫폼은 주로 시스템 메트릭 수집 및 전달을 위해, 수집된 라이브러리를 사용한다.

[0087] 도 2는 특정한 실시예들에 따른 흐름도를 예시한다. 단계(201)는 클라우드 검증 서비스의 제1 단계일 수 있다. 단계(201)는, 테스트 플랫폼이 클라우드 관리 계층에 대한 연결 및 액세스 권리들을 갖는 것을 보장하도록 작동하는 클라우드 연결을 셋업하는 단계를 포함할 수 있다. 이러한 스테이지에서 문제들이 발생하면, 관리자는 통지받을 수 있다.

[0088] 특정한 실시예들에서, 단계(202)는 클라우드 인프라구조 상에서 원격통신 애플리케이션과 같은 애플리케이션의 성능을 테스팅하기 위해 인프라구조 테스팅을 실행하는 단계를 포함한다. 이러한 테스팅은 클라우드 인프라구조 상에서의 애플리케이션의 구동을 시뮬레이팅하기 위한 가상 머신들의 사용을 수반할 수 있다. 클라우드 검증 서비스는 클라우드 인프라구조의 컴퓨터, 저장소 및 네트워크 서비스들의 성능을 평가할 뿐만 아니라 클라우드 서비스의 가용성을 모니터링할 수 있다. 클라우드 성능의 변화를 고려하기 위해, 각각의 테스트가 다수회 구동될 수 있다. 테스트들의 최종 등급은 종종, 적어도 3개의 연속하는 유효 렁(rung)들이 존재하는 경우에만 생성될 수 있으며, 이는 생성된 데이터가 통계적으로 중요하다는 것을 보장하는 데에 도움을 준다.

[0089] 몇몇 실시예들에서, 클라우드 검증 서비스는, 그것이 가상 머신들을 생성하고, 그 가상 머신들을 프로비저닝하고, 그들 상에서 테스트들을 구동시키고, 테스트들의 결과들을 수집하며, 모든 할당된 리소스들을 종료할 수 있도록 테스팅의 전체 사이클을 관리한다.

[0090] 단계(203)는 가상화된 네트워크 기능(VNF) 테스팅 페이즈일 수 있다. VNF 테스팅 페이즈에서, 클라우드 검증 서비스는 설치된 애플리케이션들의 성능을 평가하기 위해 VNF-특정 KPI들을 측정하는 테스트들을 구동시킨다. 그 후, 인프라구조 및 VNF 테스트들의 결과들이 제시되고, 기준 포인트와 비교된다. 기준은 이전에 테스팅된 클라우드 또는 VNF 동작에 대한 벤치마크 참조로서 미리정의되었던 표준화된 클라우드일 수 있다. 그 후, 단계(204)에 도시된 바와 같이, 테스트들의 결과들이 분석될 수 있으며, 그 결과들에 기반하여 리포트가 생성될 수 있다.

[0091] 도 2에서, 단계(201)는 테스팅 서비스에 액세스하기 위한 셋업 클라우드 연결을 포함할 수 있다. 클라우드 검증 서비스는 다수의 사용자들을 서빙하고 병렬로 다수의 클라우드들을 테스팅할 수 있는 멀티테넌트 서비스일 수 있다. 사용자가 클라우드 인프라구조를 테스팅하게 허용할 수 있는 테스팅 서비스에 액세스하기 위해, 사용자는 사용자 이름과 패스워드를 사용할 수 있다. 일단 사용자가 성공적으로 로깅 온하거나 또는 서비스에 액세스하면, 사용자는 이전에 부가된 클라우드를 선택할지 여부 또는 새로운 클라우드를 선택할지 여부를 선정할 수 있다.

[0092] 특정한 실시예들에서, 사용자가, 예컨대 오픈스택(openstack) 키스톤 서비스 URL을 포함하는 새로운 클라우드를 부가하기로 선정할 경우, 사용자가 적절한 액세스 크리덴셜들을 갖기 위한 요청이 이루어질 수 있다. 액세스 크리덴셜들은 테넌트 이름, 사용자 이름, 및/또는 패스워드를 포함할 수 있다. 일단 적절한 크리덴셜들이 제공되면, 서비스는 클라우드에 초기 REST 요청을 전송할 수 있다. 사용자들은 실패된 또는 성공적인 연결 시도에 대한 피드백을 수신할 수 있다. 연결 시도가 성공적이면, 클라우드 REST API 콜이 성공적이었다는 것을 표시할 수 있는 체크박스가 제공될 수 있다. 연결 시도가 실패하면, 실패 이유가 제공될 수 있다. 그 후, 몇몇 실시예들에서, 세션 토큰이 제공될 수 있다.

[0093] 클라우드 검증 서비스는 호스팅된 배치 모델들에서 구동될 수 있다. 이러한 실시예는, 서비스의 관리의 중앙화된 뷰를 유지하면서 다양한 클라우드 연결 시나리오들에 대한 지원을 포함할 수 있다. 몇몇 실시예들에서, 서비스의 몇몇 노드들만이 타겟 클라우드에 도달할 수 있다. 이것은, 특정한 IP 풀 또는 심지어 단일 IP 어드레스로부터의 트래픽만을 허용할 수 있는 방화벽이 제공되는 경우 발생할 수 있다.

[0094] 다른 실시예는 가상 사설 네트워크(VPN)를 통해 클라우드에 연결하는 것을 포함할 수 있으며, 이는 또한 타겟 클라우드에 도달할 수 있는 서비스의 노드들을 제한하도록 작동할 수 있다. 클라우드에 대한 VPN 링크는 하나 또는 그 초과의 특정 노드들에 대해 셋업될 수 있다. VPN 연결은 VPN 터널의 엔드포인트 노드의 외부로부터의 패킷 라우팅을 허용하지 않을 수 있다. VPN 또는 방화벽에 의해 야기되는 제한된 액세스를 갖는 클라우드에 대한 연결을 핸들링하기 위해, 클라우드 검증 서비스 REST는 도 3에 도시된 바와 같이 라우터 REST 요청을 포함할 수 있다.

[0095] 도 3은 특정한 실시예들에 따른 흐름도를 예시한다. 특히, 도 3은 클라우드 검증 서비스의 REST 인터페이스를 예시한다. REST 인터페이스는 통합을 위한 다른 시스템들 뿐만 아니라 사용자 인터페이스(310)에 의해 사용될 수 있다. 특정한 실시예들은, 특정 클라우드에 대한 이미지들 또는 네트워크들의 리스트를 요청하는 것과 같이 클라우드 API들에 직접적인 콜들을 행하는 것을 포함할 수 있다. REST 라우터 컴포넌트는, 클라우드에 도달할 수 있는 적어도 하나의 REST 응답기에 그러한 API 콜들을 라우팅하여, 클라우드에 직접적인 요청을 행하고, 후속하여 응답을 역으로 전송하는 것을 담당할 수 있다. 메시지 브로커는 REST 응답기와 라우터 사이의 통신을 용이하게 하기 위해 사용될 수 있다.

[0096] 도 3의 실시예에서, 사용자 인터페이스(310)는 HTTP로드 밸런서(320)를 통해 하이퍼텍스트 전달 프로토콜(HTTP) 요청을 전송할 수 있다. 요청은 클라우드 API를 호출할 수 있으며, 적어도 하나의 REST 라우터(330)에 도달할 수 있다. 그 후, REST 라우터(330)는, 클라우드 API가 요청을 행한 모든 등록된 REST 응답기 노드들(340)에 브로드캐스팅할 수 있다. 그 후, REST 응답기는, VPN 또는 방화벽을 통해 종종 잠금될 수 있는 클라우드(350)에 연결되기 위해 사용될 수 있다. 제1 REST 응답기 노드(340)로부터의 응답은 사용자 인터페이스에 역으로 전송될 수 있다. 몇몇 실시예들에서, 클라우드 식별은 최신 응답기 노드 정보로 스케줄러 할당 구성을 업데이트하므로, 노드는 클라우드 테스팅을 핸들링하기 위한 지정된 스케줄러일 수 있다.

[0097] 특정한 실시예들에서, 활성적으로 작동하는 1개 초과의 라우터가 존재해야 한다. 모든 응답기 노드들이 라우터들에 등록될 수 있다. 응답기 노드들은 자동적으로 그들 자체를 등록할 수 있다. 몇몇 실시예들에서, 라우터 노드는 또한 응답기 노드일 수 있는데, 이는 노드들 둘 모두의 기능이 하나의 물리적 노드로 결합될 수 있다는 것을 의미한다. 후속 요청들은 사용자 인터페이스로부터 모든 응답기들에 요청을 브로드캐스팅하기 보다는, 알려진 양호한 응답기들로 라우팅될 수 있다. 응답기들은 또한, 주기적으로 업데이트되고, 연결 체크업을 가질 수 있다. 부가적으로, 응답기는 화이트리스트로서 알려질 수 있는 호스트들의 지원 리스트를 가질 수 있다. 화이트리스트는, 응답기가 배타적으로 서빙할 수 있는 적어도 하나의 정의된 클라우드를 포함할 수 있다.

[0098] 도 4는 특정한 실시예들에 따른 시스템 아키텍처를 예시한다. 도 4는 또한 특정한 실시예들에 따른 클라우드 REST API의 상세도를 예시한다. 도 4의 실시예에서, 하나의 REST 라우터(410) 및 3개의 REST 응답기들(REST 응답기 A(420), REST 응답기 B(430) 및 Rest 응답기 C(440))가 존재한다. 라우터(410)는 2개의 클라우드 API REST 요청들을 클라우드 A(450)로 라우팅할 수 있다. 제1 API 콜은 네트워크들의 리스트를 획득하는 것을 수반할 수 있는 반면, 제2 API 콜은 이미지들의 리스트를 획득하는 것을 수반할 수 있다. 제1 콜을 핸들링하는 것에 관련된 동작들이 단계들 1, 2, 3, 4, 5, 및 6을 수반하는 반면, 제2 콜에 관련된 동작들이 단계들 7, 8, 9, 10, 및 11을 수반함을 유의한다. 흐름의 각각의 단계는 도면에 넘버링되고 아래에서 설명된다.

[0099] 단계(0)에서, REST 라우터(410)는 데이터베이스(470), 예컨대 MongoDB에 연결함으로써 시작할 수 있다. 그 후, REST 라우터(410)는 클라우드 A(450) 및 클라우드 B(460)에 대한 REST 응답기들(420, 430, 및 440)의 맵핑을 데이터베이스(470)로부터 획득할 수 있다. REST 응답기 A(420)는 클라우드 B(460)로의 요청들을 핸들링하도록 할당될 수 있고, REST 응답기 B(430)는 클라우드 A(450) 및 클라우드 B(460)에 할당될 수 있으며, REST 응답기 C(440)는 클라우드 A(450)에 할당될 수 있다. 일단 라우팅이 시작되면, REST 라우터(410)는 응답기들로부터 하트비트 메시지들을 수신하기 시작할 수 있다. REST 응답기들(420, 430, 및 440)은 메시지 큐를 통해 하트비트들을 브로드캐스팅하고 있을 수 있다.

[0100] 단계(1)에서, 검증 서비스 REST API는 클라우드 A(450)에서 네트워크들을 리스팅하라는 요청과 함께 콜될 수 있다. REST 라우터(410)는 요청을 전송받을 수 있다. 단계(2)에서, REST 라우터(410)는 응답기들로부터 전송된 하트비트 메시지들을 사용하여, 클라우드 A에 할당된 응답기들 중 어느 것이 얼라이브(alive)인지를 체크할 수 있다. REST 응답기 B(430)가 활성이 아닐 수 있기 때문에, 리스트 네트워크 요청은 REST 라우터(410)에 하트비트들을 전송하는 모든 활성 응답기들에 전송될 수 있다.

[0101] 단계(3)에서, 응답기 A(420) 및 응답기 C(440)는 클라우드 A(450)로의 요청들을 행할 수 있다. 특정한 실시예들에서, 응답기 A(420)는 성공적인 콜을 행할 수 있는 반면, 방화벽 제약으로 인해 클라우드에 도달가능하지 않으므로, 응답기 C(440)로부터 행해진 요청은 실패한다. 단계(4)에서, 응답기 A(420) 및 응답기 B(430)는 그들의 결과들을 역으로 전송할 수 있다. 그 후, 단계(5)에서, REST 라우터(410)는 데이터베이스(470)에 저장된 응답기 A(420)의 클라우드 할당들에 클라우드 A(450)를 부가한다. 그 후, 응답기 A(420)로부터의 성공적인 응답은 라우터(410)에 의해 리턴될 수 있다. 이러한 응답은 성공적인 연결이 클라우드 A(450)에 대해 설정되었다는 것을 표시했으며, 이는 클라우드 A(450)가 성공적으로 부가되었다는 것을 의미한다.

[0102] 그 후, 단계(7)에서, 클라우드 A(450)에 대한 제2 콜은 이미지들의 리스트를 요청하기 위해 개시될 수 있다. 응답기 A(420)가 이미 클라우드 A(450)에 할당되었으므로, 요청은 단계(8)에서 클라우드 A(450)로 포워딩된다. 클라우드 A(450)에 할당된 1개 초과의 응답기가 존재한다면, 요청은 다른 할당된 응답기들에게 또한 전송될 수 있다. 단계(9)에서, 콜은 응답기 A(420)에 의해 행해지고, 단계(10)에서, 응답기 A(420)는 요청을 역으로 REST 라우터(410)에 전송할 수 있다. 단계(11)에서, 응답기 A(420)로부터의 성공적인 응답은 REST 라우터(410)에 의해 리턴된다. 위의 실시예들은, 할당된 응답기들의 리스트 뿐만 아니라 계류중인 요청들의 리스트를 리트리브함으로써, 노출된 REST 엔드포인트들을 모니터링하도록 작동할 수 있다.

[0103] 도 4에 도시된 바와 같이, 일단 클라우드에 대한 크리덴셜들이 제공되고 클라우드에 대한 연결이 설정되면, 사용자들은 클라우드 구성의 부가적인 파라미터들을 제공할 수 있다. 이들 파라미터들은 테스팅될 클라우드의 구성을 결정하는 데 사용될 수 있다. 파라미터들은 인스턴스 구성, 플레이버(flavor) 맵핑 및 연결 구성을 포함하는 수개의 카테고리들로 분할될 수 있다. 구성 프로세스를 간략화하기 위해, 특정한 실시예들에서, 클라우드 검증 서비스는 이용가능한 이미지들, 네트워크들, 구역들, 키 쌍들, 또는 플레이버들 중 적어도 하나에 관한 데이터를 획득하기 위해 REST 인터페이스를 노출시킨다.

[0104] 특정한 실시예들에서, 인스턴스 구성은 가상 머신의 테스트를 런칭하는 것에 관련된 디폴트 값을 제공하는 것을 포함할 수 있다. 인스턴스 구성 파라미터들의 리스트는, 가상 머신들의 테스트가 런칭될 수 있는 디폴트 위치일 수 있는 가용성 구역들 또는 가상 데이터센터를 포함할 수 있다. 인스턴스 구성 파라미터들은 또한, 클라우드에서 런칭된 가상 머신들의 테스팅을 위해 사용될 이미지의 이름일 수 있는 이미지 이름 및 가상 애플리케이션 이름을 포함할 수 있다. 몇몇 실시예들에서, 클라우드 검증 서비스는 또한, 이미지들이 아직 클라우드에 존재하지 않으면 타겟 클라우드에 이미지들을 업로딩할 수 있다. 이것은 클라우드 테스팅 프로세스를 간략화하는 데에 도움을 줄 수 있다. 다른 인스턴스 구성 파라미터는 유동 IP 프로토콜 또는 외부 네트워크일 수 있다. 이러한 파라미터에 따르면, 가상 머신은 네트워크로부터 라우팅가능한 IP 어드레스를 수신할 것이다.

[0105] 도 5는 특정한 실시예들에 따른 흐름도를 예시한다. 흐름도는 클라우드로의 이미지 업로드 흐름을 표현할 수 있다. 단계(1)에서, 이미지를 클라우드 A(540)에 업로딩하기 위한 REST API 요청은 REST 라우터(510)에 도달한다. 그 후, 단계(2)에서, REST 라우터(510)는 이미지가 업로딩될 수 있는지를 체크하기 위해 클라우드 A(540)에 할당된 응답기에게 질의를 전송할 수 있다. 단계(3)에서, REST 응답기 Z(520) 및 REST 응답기 A(530)는 그들이 이미지를 업로딩하기 위해 사용될 수 있는지를 체크할 수 있으며, 이는, 액세스될 수 있는 디스크 상에 이미지 파일이 존재하는지를 응답기들이 체크할 수 있다는 것을 의미한다. 도 5의 실시예에서, REST 라우터(510)는 단계(5)에서, 업로드를 핸들링하기 위해 REST 응답기 A(530)를 선택한다. 다른 실시예들에서, REST 응답기 Z(520)가 선택될 수 있다.

[0106] REST 응답기 A(530)는 데이터베이스(550)로부터 업로드의 상태를 체크할 수 있다. 기존의 엔트리가 존재하고, 예컨대 마지막 1분 내에서 마지막 업데이트가 새로운 것이면, 데이터베이스는 업로드 요청을 무시하며, HTTP 업로드가 이미 진행중이라는 것을 나타내는 메시지를 리턴할 수 있다. 대안적으로, 어떠한 엔트리도 존재하지 않거나 또는 엔트리가 오래된 것이라면, 단계(5)에 도시된 바와 같이, REST 응답기 A(530)는 클라우드(540)로의 업로드 절차를 시작할 수 있다. 단계(6)에서, REST 응답기 A(530)는 업로드 절차를 시작할 수 있다. 그 후, 그것은 마지막으로 업데이트된 필드를 포함하여, 데이터베이스의 업로드 태스크 엔트리를 일관되게 업데이트할 수 있다.

[0107] 그 후, 단계(7)에서, 이미지 업로드 상태에 관한 질의가 REST 라우터에 도달할 수 있다. 단계(8)에서, 요청은 이미지 업로드 상태를 문의하는 REST 라우터에 의해 브로드캐스팅된다. 이미지 업로드 상태 요청은 REST 응답기 Z(520) 및 REST 응답기 A(530)를 포함하는 모든 응답기들에게 전송될 수 있다. 단계(9)에서, 응답기들은 업로드 상태를 체크하고, 업로드 상태를 REST 라우터(510)에 전송할 수 있다. 몇몇 실시예들에서, 이미지를 업로딩하고 있는 응답기들만이 이미지 업로드 상태 획득 요청에 응답할 수 있다. 단계(10)은 데이터베이스(550)로부터 이미지 업로드 작업 상태를 페칭(fetch)하는 REST 응답기 A를 예시한다. 작업자 식별이 환경 식별과 동일한 값을 갖는다면, 데이터베이스(550)는 업로드 작업 상태로 응답할 수 있다. 작업자 식별이 환경 식별과 동일한 값이 아니라면, 데이터베이스(550)는 불량한 요청을 표시하는 메시지로 응답할 수 있다.

[0108] 특정한 실시예에서, 클라우드 플레이버는 가상 CPU들, 메모리, 및 저장소의 특정 조합에 놓일 수 있는 라벨을 포함할 수 있다. 공개 및 사설 클라우드들 둘 모두는 클라우드 플레이버들을 사용할 수 있다. 그러나, 특정 플레이버가 무엇을 의미하는지에 대한 어떠한 고정된 표준도 존재하지 않을 수 있다. 예컨대, 하나의 클라우드 플레이버에서, 'm1.tiny'는 하나의 가상 CPU를 갖는 가상 머신을 의미할 수 있는 반면, 다른 클라우드에서, 그러한 플레이버는 심지어 정의되지 않을 수 있다. 테스트 정의가 특정 클라우드 환경에 구속되지 않을 수 있게 하기 위해, 유니버설 인덱스들이 가상 머신들의 플레이버로서 사용될 수 있다. 따라서 각각의 클라우드는 테스트들에서 사용된 유니버설 인덱스들로의 내부 플레이버들의 그 자신의 맵핑을 가질 수 있다. 플레이버 맵핑 구성 단계는 사용자가 이러한 구성을 설정하게 허용할 수 있다.

[0109] 도 6은 특정한 실시예들에 따른 사용자 인터페이스를 예시한다. 구체적으로, 도 6은 사용자가 플레이버 맵핑 구성을 선정하게 허용할 수 있는 사용자 인터페이스를 예시한다. 사용자는 테스트를 위해 사용될 수 있는 플레이버들의 인덱싱된 리스트(620)에 클라우드의 플레이버의 리스트(610)를 맵핑할 수 있다. 테스트는 도 6에 도시된 인덱스를 사용하는 플레이버를 지칭할 수 있으므로, 테스트는 클라우드 독립적(agnostic)이고, 특정 플레이버를 갖는 특정 클라우드에 구속되지 않을 수 있다. 테스트 인스턴스를 런칭하기 위해 사용될 수 있는 디폴트 플레이버가 또한 정의될 수 있다.

[0110] 특정한 실시예들에서, 클라우드 구성의 부가적인 단계는 도메인 이름 서버 및 프록시 세팅들을 특정하는 것일 수 있다. 그 후, 그 구성들은 테스트 프로비저닝 단계들의 일부로서 가상 머신들을 테스팅하도록 주입될 수 있다.

[0111] 몇몇 실시예들에서, 각각의 클라우드는 계획 페이즈 동안 그것에 할당된 다수의 테스트들을 가질 수 있다. 예컨대, 테스팅은 클라우드 API 성능 테스팅, 컴퓨팅 인프라구조 테스팅, 네트워크 인프라구조 스케일링 테스팅, 및/또는 네트워크 인프라구조 테스팅을 포함할 수 있다. 도 7은 특정한 실시예들에 따른 흐름도를 예시한다. 도 7의 실시예에서, 사용자들에 의해 선택될 수 있는, 데이터베이스에 저장된 테스트 템플릿들(710)이 존재할 수 있다. 테스트 템플릿들은 테스트가 실행되어야 할 경우 어떤 테스트 경우들이 구동되어야 하는지, 및/또는 테스팅될 타겟 환경의 토폴로지, 예컨대 가상 머신 또는 후단 저장소의 구성을 설명할 수 있다.

[0112] 단계(720)에 도시된 바와 같이, 테스트 템플릿의 사본이 생성되어 클라우드와 연관될 수 있다. 테스트 템플릿의 이러한 사본은 테스트 인스턴스 문서(730)로 알려져 있을 수 있다. 특정한 실시예들에서, 테스트 인스턴스는 도 1에 도시된 바와 같이, 플랫폼(110)의 스케줄러(111)로 그것을 스케줄링하기 전에 단계(730)에서 맞춤화(customize)될 수 있다. 테스트 인스턴스 문서를 맞춤화하는 것은 상이한 테스트 경우들의 몇몇 구성들을 변경시키는 것 및/또는 테스트 경우들 중 몇몇을 디스에이블링 또는 제거하는 것을 포함할 수 있다.

[0113] 특정한 실시예들에서, 스케줄링된 테스트 실행들(750) 각각에 대해, 테스트 구동 문서가 생성될 수 있다. 테스트 구동(760)은 원래의 실행이 스케줄링되었던 테스트 인스턴스 문서의 사본일 수 있다. 따라서, 테스트 구동(760)은, 이전의 테스트 구동을 감사(audit)할 필요가 존재할 때마다 이력 목적들을 위해 사용될 수 있는 실행 시에 중요한 테스트 구성 및 환경 정보의 스냅샷들을 또한 포함할 수 있다. 각각의 테스트 구동 실행은 단일 테스트의 실행을 위해 테스트 구동 문서와 관련되는 다수의 테스트 결과 문서들(770) 및 테스트 로그 문서들(780)을 생성할 수 있다.

[0114] 몇몇 실시예들에서, 테스트는 크론(Cron) 표현을 통해 런칭될 수 있다. 예컨대, 각각의 테스트 인스턴스는 하나 또는 그 초과의 미래의 실행 시간들에 대해 특정된 하나의 크론 표현을 가질 수 있다. 크론 스케줄링은 또한, 그러한 기간이 특정되는 경우, 유효 기간을 지원할 수 있다. 스케줄링된 구동이 주어진 유효 기간 외부에 있는 경우, 테스트가 실행되지 않을 수 있다. 사용자는 사용자 인터페이스에서 유효 기간을 특정할 수 있다. 사용자는 유효 기간의 날짜, 시간, 및 길이를 특정할 수 있다. 또한, 특정한 실시예들에서, 사용자는 테스트 경우가 병렬로 구동될 수 있다는 것 또는 모든 테스트 경우들이 실패에 관계없이 실행되어야 한다는 것을 특정할 수 있다.

[0115] 특정한 실시예들에서, 테스트는 애드-혹 1회 실행을 통해 런칭될 수 있다. 스케줄러가 테스트 인스턴스 스케줄을 수신한 이후, 테스트가 간단히 실행될 수 있다. 부가적으로, 몇몇 실시예는 "원-클릭" 접근법을 이용할 수 있다. "원-클릭" 접근법에서, 버튼의 누름 또는 클릭과 같은 사용자에 의한 단일 개시 액션은 테스트들을 개시할 수 있다. 위에서 논의된 바와 같이, 테스트들은 테스트 메뉴를 통해 이전에 정의되거나 스케줄링될 수 있으며, 그에 의해, 테스트들이 단일 버튼의 누름 또는 클릭을 이용하여 자동적으로 진행하게 허용한다.

[0116] 도 8은 특정한 실시예들에 따른 흐름도를 예시한다. 도 8의 실시예는 플랫폼 관점으로부터의 테스트 실행 흐름을 표현한다. 단계(801)에서, 사용자는 사용자 이름 및 패스워드와 같은 특정 요건들을 입력함으로써 테스팅 서비스에 로깅할 수 있다. 단계(802)에서, 사용자 인터페이스는 테스팅할 새로운 클라우드를 결정하기 위해 사용될 수 있다. 몇몇 실시예들에서, 사용자는 인가 URL, 테넌트, 사용자 이름, 및/또는 패스워드를 포함하는 클라우드의 크리덴셜들을 입력하도록 요구될 수 있다. 그 후, 테스팅된 클라우드는 입력된 크리덴셜들을 사용하여 원격 위치를 통해 액세스될 수 있다.

[0117] 특정한 실시예들에서, 테스트는 단계(803)에 도시된 바와 같이 계획될 수 있다. 테스트의 계획은 클라우드의 다양한 양상들의 테스팅을 허용하는 테스트 템플릿들을 사용하는 것을 포함할 수 있다. 테스트들은, 클라우드, 컴퓨팅, 네트워크, 저장소, 및 애플리케이션들에서 구동되는 클라우드 서비스들, 이를테면 가상화된 원격통신 네트워크 기능들, 예컨대 IMS에 대해 계획될 수 있다. 그 후, 템플릿들은 테스팅을 위해 구성에 넣어질 수 있다. 단계(804)에서, 사용자는 수집된 데이터를 저장할 선택 데이터베이스를 선택할 수 있다. 몇몇 실시예들에서, 사용자는 또한, 현재 테스팅을 비교할 경우 사용하기 위해 데이터베이스로부터 기준들 또는 벤치마크들을 인출할 수 있다.

[0118] 단계(805)에서, 사용자는 테스트를 스케줄링할 수 있다. 그 후, 단계(806)에서, 스케줄 테스트 매니페스트(manifest)가 사용자 인터페이스를 통해 나타날 수 있다. 매니페스트를 검토한 이후, 사용자는 테스트를 개시할지 여부를 선정할 수 있다. 사용자가 매니페스트에서 나타낸 테스트 구성을 변경시키기로 선정하면, 사용자는 되돌아가서 단계들(802, 803, 804, 및 805)을 재구성할 수 있다. 그렇지 않으면, 사용자는 단계(807)에서 테스트를 개시할 수 있다. 몇몇 실시예들에서, 클라우드는 완전한 자동화를 사용하여 테스팅될 수 있다. 일단 테스트가 개시되면, 808에서 도시된 바와 같이, 실제 테스팅이 행해지기 전에 수개의 셋업 단계들이 준비될 수 있다. 예컨대, 가상 머신들이 생성될 수 있고, 도 1에 예시된 테스트 에이전트가 배치될 수 있다.

[0119] 단계(809)에서, 에이전트들이 얼라이브인지 여부에 대한 결정이 행해질 수 있다. 이러한 결정은 도 1에 도시된 바와 같이, 하트비트들(121)이 에이전트로부터 테스팅 플랫폼으로 전송되는지 여부에 기반할 수 있다. 특정한 실시예들에서, 하나의 에이전트는 얼라이브이지 않을 수 있고, 그 하나의 에이전트에서의 테스트 수집 및 모니터링은 에이전트들이 얼라이브하다는 표시가 수신될 때까지 지연될 수 있다. 다른 실시예들에서, 에이전트들은 모니터 테스트 실행 단계(810)에서 도시된 바와 같이, 그들이 활성이고 테스트가 플랫폼에 의해 모니터링될 수 있다는 것을 표시할 수 있다. 특정한 실시예들에서, 최종 리포트가 생성될 수 있기 전에 테스트가 발생하는 동안, 사용자들은 테스팅의 진행 뿐만 아니라 상세한 로그들 둘 모두를 검토할 수 있다. 그 후, 테스트 결과들은 단계(811)에서 수집될 수 있다.

[0120] 단계(812)에서, 테스팅이 완료되었는지 여부에 대한 결정이 행해질 수 있다. 완료되지 않았다면, 테스팅 뿐만 아니라 단계들(810 및 811)의 데이터의 모니터링 및 수집이 계속될 수 있다. 테스팅이 완료되는 경우, 단계(813)에 도시된 바와 같이, 테스팅이 이어서 완료될 수 있으며, 가상 머신들이 파괴될 수 있다. 그 후, 단계(814)에 도시된 바와 같이, 리포트는 플랫폼에 의해 생성될 수 있으며, 이는, 사용자들이 테스트들의 결과들을 용이하게 검토하게 허용할 수 있다. 리포트는 서비스의 사용자 인터페이스 내에서 제시될 수 있다.

[0121] 도 8의 단계(803)에서 설명된 바와 같이, 네트워킹 테스팅은 상이한 네트워크 토폴로지들, 예컨대, 인터-가용성 구역 토폴로지, 인트라-가용성 구역 토폴로지, 또는 외부 게이트웨이 토폴로지에 대해 행해질 수 있다. 도 9a는 특정한 실시예들에 따른 토폴로지를 도시한다. 도 9a의 실시예들에서, 성능은 현재의 클라우드 내부의 노드와 클라우드 환경 외부의 노드 사이에서 테스팅될 수 있다. 구체적으로, 클라우드의 구역 1(901)에 로케이팅된 가상 머신 1(903)과 외부 노드(906) 사이의 성능이 테스팅될 수 있다. 게이트웨이(905)는 가상 머신(903)과 외부 노드(906) 사이의 상호작용을 용이하게 하기 위해 사용될 수 있다.

[0122] 다른 실시예들에서, 도 9b에 도시된 바와 같이, 성능은 상이한 이용가능한 구역들 내의 2개의 노드들 사이에서 테스팅될 수 있으며, 이는 인터-가용성 구역 토폴로지를 유도한다. 구역 1(901)에 로케이팅된 가상 머신 1(903)은 구역 2(902)에 로케이팅된 가상 머신 2(904)와 상호작용할 수 있다. 도 9c에 도시된 또 다른 실시예에서, 성능은 동일한 가용성 구역(901) 내의 2개의 가상 노드들(903, 904) 사이의 상호작용에 대해 테스팅될 수 있다. 테스팅은 도 9a, 도 9b, 및 도 9c에 나타낸 네트워크 토폴로지들을 사용하여 반복적으로 구동될 수 있다.

[0123] 특정한 실시예들에서, 트래픽은 이들 상이한 토폴로지들을 통해 구동될 수 있다. 트래픽은 상이한 패킷 사이즈들을 갖고, 상이한 네트워크 프로토콜들, 예컨대 TCP, UDP, 및 SCTP를 사용할 수 있다. 이것은, 네트워크 관점으로부터 레이턴시 및 대역폭의 평가를 허용할 수 있다.

[0124] 도 10은 특정한 실시예들에 따른 흐름도를 예시한다. 특히, 흐름도는 테스트 에이전트의 관점으로부터 도시된다. 단계(1010)에서, 에이전트가 설치되고 구성된다. 에이전트는 애플리케이션의 구동 동안 클라우드 인프라구조의 테스팅에서 플랫폼을 보조하는 데 사용될 수 있다. 에이전트 서비스는 단계(1020)에 도시된 바와 같이 시작되거나 또는 배치될 수 있다. 단계(1030)에서, 에이전트는, 그것이 테스팅을 실행할 수 있다는 것을 플랫폼에 표시하기 위해, "IsAlive" 신호를 플랫폼에 전송할 수 있다. 단계(1040)에서, 에이전트는 테스팅을 실행하기로 시작하기 위해 스케줄러로부터의 명령을 대기할 수 있다. 몇몇 실시예들에서, 사용자가 에이전트에게 진행하기 위한 허가를 제공하지 않으면, 테스팅이 실행되지 않을 수 있다. 그 후, 에이전트는, 그것이 테스팅을 시작할 수 있다는 것을 표시하기 위해 "IsAlive" 또는 하트비트 메시지들을 플랫폼에 계속 전송할 수 있다. 다른 실시예들에서, 스케줄러는 프로그램을 실행하기 위한 요청을 전송할 수 있으며, 그 요청은 에이전트가 테스팅을 실행하게 허용할 수 있다. 에이전트는, 단계(1050)에서 플랫폼으로부터 테스트 명령들을 수신하고, 단계(1060)에서 테스트를 실행하기 시작할 수 있다. 그 후, 단계(1070)에서 테스트 결과들은 플랫폼에 전송될 수 있다.

[0125] 도 11은 특정한 실시예들에 따른 시스템 아키텍처를 예시한다. 구체적으로, 도 11은 테스트 실행 동안 도 1에 도시된 플랫폼(110)과 테스트 에이전트(120) 사이의 상호 작용을 예시한다. 스케줄러는 그 시간 동안 시작될 수 있는 새로운 테스트들에 대해 주기적으로 폴링될 수 있다. 단계(1)에서, 스케줄러(1101)가 시작될 테스트를 발견할 경우, 그것은 단계(2)에 도시된 바와 같이, 테스트 라이프 사이클을 관리할 수 있는 스케줄러 테스트 인스턴스(1104)를 생성한다.

[0126] 스케줄러 테스트 인스턴스(1104) 내에서, 상이한 테스트들을 프로세싱할 수 있는 상이한 타입들의 다수의 인스턴스들이 단계(3)에서 생성될 수 있다. 예컨대, 인스턴스 타입들은 테스트 에이전트(1108)와의 주요 상호작용을 핸들링할 수 있는 테스트 에이전트 중재기(1103)를 포함할 수 있다. 클라우드 프로비저닝 및 테스트 툴링 구성을 담당할 수 있는 편성기(1102)가 또한 생성될 수 있다. 부가적으로, 테스팅으로부터 테스트 결과들을 수집할 수 있는 테스트 결과 수집기(1105) 및 라이브 테스트 진행 업데이트들을 수집할 수 있는 테스트 진행 수집기(1106)가 제공될 수 있다.

[0127] 단계(4)에서, 일단 스케줄러 테스트 인스턴스(1104)가 초기화되면, 그것은 먼저, 하나 또는 그 초과의 가상 머신들을 런칭하도록 편성기(1102)에게 명령할 수 있다. 가상 머신은 테스팅 소프트웨어 및 테스트 에이전트(1108)의 설치 및 구성을 포함할 수 있다. 특정한 실시예에서, 테스트 에이전트(1108)는 단계(5)에서 얼라이브하게 되며, 메시징 인터페이스 또는 버스, 예컨대 RabbitMQ를 통해 테스트 에이전트 중재기(1103)를 통하여 하트비트를 전송하기 시작한다. 단계(6)에서, 테스트 에이전트 중재기(1103)는 하트비트를 인식하며, 메시징 버스를 통해 에이전트(1108)에 테스트 스위트(suite) 문서를 전송할 수 있다. 테스트 에이전트(1108)에 의해 수신된 테스트 스위트 문서에 기반하여, 단계(7)에서, 테스트 에이전트(1108)는 테스트 스위트 실행을 시작하기 위해 적어도 하나의 테스트 스위트 실행기(1109)를 생성할 수 있다.

[0128] 몇몇 실시예들에서, 테스트 스위트 실행기(1109)는 단계(8)에 도시된 바와 같이, 각각의 테스트 경우를 테스트 경우 실행기(1110)에 추가로 위임할 수 있다. 테스트 경우 실행기(1110)는 테스트 경우 규격에 기반하여 로딩될 필요가 있는 플러그인을 결정할 수 있고, 단계(9)에서 실행기 플러그인을 동적으로 로딩할 수 있다. 몇몇 실시예들에서, 테스트 경우 실행기(1110)는 테스트 경우 진행 업데이트들을 콜백 메카니즘을 통해 테스트 스위트 실행기(1109)에 즉시 전송할 수 있으며, 그 후, 그 테스트 스위트 실행기(1109)는 단계(10)에서 메시징 버스를 통해 테스트 진행 수집기(1106)에 업데이트를 전송할 수 있다. 일단 테스트 진행 업데이트들이 테스트 진행 수집기(1106)에 의해 수집되면, 업데이트가 전송되어 데이터베이스(1113)에 저장될 수 있다.

[0129] 특정한 실시예들에서, 테스트 경우에 의존하여, 단계(11)에서, 실행기 플러그인(1111)은 편성기 프록시(1112)를 통해 추가적인 편성을 수행할 수 있다. 단계(12)에서, 편성기 프록시(1112)는 콜백 메카니즘을 통해 편성 요청에 즉시 응답할 수 있다. 몇몇 실시예들에서, 단계(13)에서, 편성기 프록시(1112)는 메시징 버스를 통해 편성기 프록시 후단(1107)에 요청을 캡슐화하고, 그 후단은 새로운 편성 인스턴스를 생성할 수 있다. 단계(14)에서, 생성된 편성기 인스턴스는 명령받은 바와 같이 클라우드에 대한 편성 프로세스를 시작할 수 있다.

[0130] 실행기 플러그인(1111)이 테스트 경우 실행을 완료한 이후, 단계(15)에서, 그것은 테스트 경우 실행기(1110)에 테스트 결과들을 전송할 수 있으며, 그 후, 그 테스트 경우 실행기는 결과들을 테스트 스위트 실행기(1109)에 전송할 수 있다. 그 후, 테스트 스위트 실행기(1109)는 메시징 인터페이스 또는 버스를 통해 에이전트로부터 플랫폼에 로케이팅된 테스트 결과 수집기(1105)에 테스트 결과들을 전송할 수 있다. 그 후, 결과들은 데이터베이스(1113)에 저장될 수 있다.

[0131] 도 12는 특정한 실시예들에 따른 흐름도를 예시한다. 테스트의 실행 동안, 사용자는 클라우드 리소스들 및 기본적인 KPI들의 이용도, 이를테면 CPU, 사용도, 또는 메모리 사용도를 모니터링할 수 있다. 이것은, 사용자가 로그들을 분석 및 디버깅할 필요 없이, 테스트 및/또는 클라우드 인프라구조에 대한 몇몇 기본적인 문제들을 신속하게 발견하게 허용한다. 즉, 사용자는 테스트 동안 라이브 메트릭들을 뷰잉 및/또는 수집할 수 있다.

[0132] 도 12는, 사용자가 다양한 테스트 메트릭들을 라이브로 모니터링할 수 있는 실시예를 예시한다. 사용자 인터페이스(1201)는 플랫폼 내의 편성기와 통신했던 HTTP 서버일 수 있는 "아파치2"(1202)에 모니터링 요청을 전송하기 위해 사용될 수 있다. "아파치2"는 플랫폼의 편성기에 포함될 수 있다. 모니터링 요청은 클라우드 인프라구조에 로케이팅된 그래파이트(graphite)(1203) 및 카본(1204)을 통해 포워딩될 수 있다. 그 후, 수집된 데이터는 테스트 가상 머신의 수집된 플러그인들(1205)로부터 클라우드 인프라구조를 통해 역으로 "아파치 2"(1202)에 전송될 수 있다. 그 후, 데이터는 사용자에 의해 뷰잉하기 위해 사용자 인터페이스(1201)로 포워딩될 수 있다. 일 실시예에서, CPU 로드 및 메모리 사용도는 테스트의 실행을 모니터링하기 위해 사용될 수 있는 라이브 메트릭들로서 도시될 수 있다.

[0133] 도 13은 특정한 실시예들에 따른 흐름도를 예시한다. 테스트 실행의 모니터링을 용이하게 하기 위해, 클라우드 검증 서비스가 분산형 로깅을 구현할 수 있다. 분산형 로깅은 테스트 가상 머신들 각각에 로깅하는 것을 피하는 데 도움을 줄 수 있고, 단일 뷰 하에서 모든 로그들을 제공할 수 있다.

[0134] 특정한 실시예들에서, 단계(1)에서, 플랫폼 내의 테스트 스케줄러 인스턴스(1301)는 테스팅의 개시 동안 로그 수집기(1302)를 생성하며, 그 로그 수집기는 다수의 소스들로부터의 스트리밍 로그들의 수신 말단으로서 작동할 수 있다. 단계(2)에서, 에이전트 내의 테스트 에이전트(1303)는 로그들을 플랫폼으로 스트리밍하기 위해 하나 또는 그 초과의 분산형 로거 클라이언트(1304) 인스턴스들을 생성한다. 그 후, 단계(3)에서, 분산형 로거 클라이언트(1304)는 측정 인터페이스를 통해 로그들을 플랫폼으로 스트리밍하기 시작할 수 있다. 플랫폼 말단에서, 로그 수집기(1302)는 스트리밍된 로그들을 수신하고, 그들을 데이터베이스(1305)에 저장할 수 있다. 특정한 실시예들에서, 로그들은 수신 시에 즉시 저장될 수 있다. 로그들은 또한 다수의 배치(batch)들에 저장될 수 있다.

[0135] 도 14는 특정한 실시예들에 따른 사용자 인터페이스(1401)를 예시한다. 사용자 인터페이스는 테스팅이 시작되었던 이래로 경과된 시간의 양을 포함하는 진행 개요를 포함할 수 있다. 사용자 인터페이스(1401)는 또한, 각각의 실행된 네트워크 테스트에 대한 진행의 양을 포함하는 진행 세부사항들을 예시할 수 있다. 몇몇 실시예들에서, 테스팅된 진행 로그들을 나타내는 특정된 코드가 도시될 수 있다. 데이터베이스에 저장된 로그들은 사용자 인터페이스에서의 로그들의 제시를 허용할 수 있는 REST 인터페이스를 통해 노출될 수 있다.

[0136] 도 15는 특정한 실시예들에 따른 사용자 인터페이스를 예시한다. 구체적으로, 도 15에 도시된 사용자 인터페이스(1501)는 클라우드들 사이의 결과들의 비교를 허용할 수 있는 고 레벨 결과 뷰를 예시할 수 있다. 위에서 논의된 바와 같이, 검증 서비스는 결과들을 뷰잉할 경우 벤치 마크로서 사용될 수 있는 기준 클라우드를 포함한다. 각각의 테스팅된 클라우드는 기준 클라우드 결과들에 대한 클라우드의 상대적인 성능에 기반하여 등급이 매겨질 수 있다. 초기 출력은, 도 15에 도시된 실시예에서 0 내지 5의 이산 스코어를 갖는 단일 수치인 클라우드 등급일 수 있다. 인프라구조 및 애플리케이션 테스트들 각각에 대해 스코어들이 제공될 수 있다.

[0137] 이러한 최상위 레벨 뷰는 테스트들의 각각의 카테고리에 대한 특정 결과들로 분해될 수 있다. 예컨대, 클라우드의 전체 성능은 서비스들(1520), 컴퓨팅(1530), 네트워크(1540), 저장소(1550), 또는 애플리케이션(1560) 중 적어도 하나로 분할될 수 있다. 사용자는 클라우드 인프라구조의 전체 성능을 설명하는 0 내지 5의 스코어를 제공받을 수 있다. 추가로, 위의 카테고리들 각각은, 0 내지 5의 스케일로 등급이 또한 매겨질 수 있는 추가적인 카테고리들로 분할될 수 있다.

[0138] 현재의 테스트의 편집(compilation) 스코어는 각각의 카테고리 내의 수평선들에 의해 도시될 수 있다. 예컨대, 서비스들(1520) 하의 서비스 가용성은 대략 5 중 4등급을 갖는 것으로 테스팅되었다. 부가적으로, 특정한 실시예들은 기준 클라우드에 대한 동일한 테스트에 대한 기준 스코어들을 나타내는 수직 바 또는 화살표를 포함할 수 있다. 이것은 클라우드들이 다른 클라우드들과 또는 대안적으로는 동일한 클라우드로부터의 이전의 결과들과 비교되게 허용할 수 있다. 예컨대, 서비스들(1520) 하의 서비스 가용성 카테고리는 대략 5의 기준 클라우드 스코어를 갖는다. 사용자는 아카이브(archive)들로부터 특정 기준 클라우드를 선택할 수 있다.

[0139] 클라우드 등급 계산은 상이한 방법들을 사용하여 컴퓨팅될 수 있다. 예컨대, 몇몇 실시예들은 플레이버 당 테스트 경우 등급, 예컨대, 7-Zip 테스트를 생성한다. 각각의 플레이버에 대해, 각각의 KIP의 평균 테스트 측정 값이 계산될 수 있다. 부가적으로, KPI 등급은 이전에 계산된 평균 값들을 임계치 범위의 우측에 맵핑함으로써 계산될 수 있다. 계산된 테스트 경우 등급은 또한, 계산된 모든 KPI 등급들의 가중된 등급 평균을 사용하여 계산될 수 있다.

[0140] 다른 실시예들에서, 테스트 그룹 등급은 클라우드 리소스, 예컨대 압축 테스트마다 계산될 수 있다. 클라우드 리소스의 테스트 그룹들 각각에 대해, 테스트 경우 등급 평균은 모든 플레이버들로부터 테스트 경우 등급들을 평균함으로써 테스트 그룹의 모든 플레이버들에 대해 계산될 수 있다. 부가적으로, 테스트 그룹 등급은 모든 플레이버들에 대한 계산된 테스트 등급의 가중된 평균을 수행함으로써 계산될 수 있다.

[0141] 특정한 실시예들에서, 클라우드 리소스 등급이 생성될 수 있다. 클라우드 리소스 등급은 컴퓨팅(1530) 카테고리에서 사용될 수 있다. 클라우드 리소스 등급은 모든 테스트 그룹 등급들을 평균함으로써 계산될 수 있다. 테스트 그룹 가중치가 미리 결정되는 경우, 가중된 평균이 이어서 계산될 수 있다. 그렇지 않으면, 가중치는 균등하게 분할될 수 있다. 몇몇 실시예들에서, 클라우드 등급은 클라우드 리소스 등급들 중 몇몇 또는 모두를 평균함으로써 생성될 수 있다.

[0142] 몇몇 실시예들에서, 각각의 카테고리 내의 결과들을 뷰잉하는 것은 기준 클라우드 스코어의 콘텍스트로 제시될 수 있다. 도 15에 도시된 바와 같이, 카테고리들은 서비스들(1520), 컴퓨팅(1530), 네트워크(1540), 및 저장소(1550), 또는 애플리케이션(1560) 중 적어도 하나일 수 있다. 도 15에 도시된 바와 같이, 사용자 인터페이스에 도시된 수직 화살표들은 기준 클라우드 스코어를 표현할 수 있다. 각각의 테스팅된 메트릭은 기준 클라우드 스코어와 비교하여 예시될 수 있다.

[0143] 몇몇 실시예들에서, 도 15에 도시된 수직선 대신에, 클라우드 스코어들은 수평 축에서 퍼센티지들을 갖는 수직 히스토그램으로서 도시될 수 있다. 기준 클라우드 스코어는 히스토그램의 제로 퍼센테일(percentile) 마크일 수 있으며, 히스토그램에 도시된 바들은 제로 마크의 좌측인 네거티브 퍼센테일로부터 제로 마크의 우측인 포지티브 퍼센테일까지의 범위에 있다. 네거티브 퍼센테일은, 현재의 테스팅된 메트릭이 기준 클라우드 스코어보다 낮은 스코어를 가졌었다는 것을 표시할 수 있다. 한편, 포지티브 퍼센테일은, 현재의 테스팅된 메트릭이 기준 클라우드 스코어보다 높은 스코어를 가졌었다는 것을 표시할 수 있다. 퍼센테일이 높을수록, 현재의 테스트의 성능이 더 양호하다.

[0144] 다른 실시예에서, 수평 성능 히스토그램 또는 바 차트는 현재의 테스트의 메트릭들을 리포팅하기 위해 사용될 수 있다. 이것은, 예컨대 상이한 머신 타입들에서 GZIP 압축을 위한 레이턴시를 갖는 상이한 파일 사이즈들의 성능을 포함하는 메트릭들의 더 특정한 평가를 허용할 수 있다. 이것은 위에서 설명된 클라우드 등급 계산보다 메트릭들의 더 상세한 파라미터 뷰를 허용할 수 있다. 다른 예에서, 네트워킹 카테고리(1540)에서, 인터-가용성 구역 토폴로지에서의 스루풋은 SCTP, TCP, 또는 UDP 프로토콜들에 기반하여 초당 메가비트 단위로 측정될 수 있다.

[0145] 도 15에 도시된 바와 같이, 원격통신 네트워크 애플리케이션이 테스팅될 수 있다. 예컨대, IMS가 테스팅될 수 있다. 사용자 인터페이스는 네트워크 가입자 로드, 트래픽 로드, 및/또는 트래픽 패턴들을 입력하기 위해 사용될 수 있다. 특정한 실시예들에서, 애플리케이션 성능의 시간적 뷰가 뷰잉될 수 있다.

[0146] 다른 실시예들에서, 임의의 타입의 테스팅된 메트릭들은, 그것이 분산형 차트, 테이블, 그래프, 리스트, 스크립트, 또는 사용자 인터페이스와 호환가능할 수 있는 임의의 다른 형태와 같은 차트로 존재하는지에 관계없이 임의의 형태로 제시될 수 있다.

[0147] 특정한 실시예들에서, 새로운 테스트 툴의 온-보딩을 간략화하기 위해, 클라우드 검증 서비스는 사용자 인터페이스 측 상에서 위젯 개념을 구현할 수 있다. 이러한 위젯 개념은 JSON(javascript object notation) 형태로 정의된 대시보드에서의 결과들의 뷰잉을 허용할 수 있다. 특정한 실시예들에서, 대시보드 규격은 JSON을 통해 리트리브 및 프로세싱될 수 있다. 그 후, 테스트 결과 데이터가 리트리브되고, 위젯이 생성될 수 있다.

[0148] 도 16은 특정한 실시예들에 따른 흐름도를 예시한다. 단계(1601)에서, 사용자는 대시보드를 요청한다. 그 후, 사용자 인터페이스 대시보드 모듈은 단계(1602)에 도시된 바와 같이, REST API를 통해 대시보드 규격을 요청한다. 그 후, 단계(1603)에서, 대시보드 규격은 MongoDC와 같은 데이터베이스로부터 REST API로 전송될 수 있다. 단계(1604)에서, 사용자 인터페이스로 리턴된 대시보드 규격에 기반하여, 사용자 인터페이스 대시보드 모듈은 단계(1605)에서 REST API를 통해 테스트 데이터를 요청할 수 있다. 그 후, 단계(1606)에서, 테스트 결과들은 데이터베이스로부터 REST API로 전송될 수 있고, 결과들은 단계(1607)에 도시된 바와 같이 사용자 인터페이스로 포워딩될 수 있다.

[0149] 그 후, 특정한 실시예들에서, 사용자 인터페이스 대시보드 모듈은 단계(1608)에서, 대시보드 규격에 따라 하나 또는 그 초과의 대시보드 위젯들을 생성할 수 있다. 대시보드 위젯은 위젯 규격에 특정된 바와 같이, 필터링된 테스트 결과 데이터를 포함할 수 있다. 단계(1609)에서, 대시보드 위젯은 필터링된 테스트 결과 데이터를 프로세싱하고, 위젯을 시각화하기 위해 예상되는 형태로 대시보드 데이터 생성기를 통해 변환한다. 특정한 실시예들에서, 대시보드 데이터 생성기는 위젯 규격에 존재하는 임의의 표현을 파싱(parse)하기 위해 AST(abstract syntax tree) 표현 파스 유틸리티를 이용할 수 있다. 결과들은 대시보드 위젯 데이터 생성기로 포워딩될 수 있으며, 그 후, 그 생성기는 위젯 데이터를 대시보드 위젯에 전송할 수 있다.

[0150] 최종 리포트는 클라우드 검증 서비스에 의해 생성될 수 있으며, 테스트 활동을 요약하는 최종 리포트 문서를 포함할 수 있다. 몇몇 실시예들에서, 최종 리포트 생성 프로세스는 데이터베이스로부터의 클라우드 데이터의 리트리벌, 및 미리 정의된 템플릿 디스크립터를 사용하는 것을 포함할 수 있으며, 이는, 문서들이 어떻게 어셈블리될지 및/또는 어떤 그래프들이 생성되어 리포트에 포함될지를 정의하는 데에 도움을 줄 수 있다. 그 후, 리포트 데이터베이스 플러그인들이 프로세싱될 수 있고, 리포트 변수가 생성될 수 있다. 궁극적으로, 임의의 형태의 문서가 생성될 수 있다. 몇몇 실시예들에서, 생성된 문서는 암호화 또는 인코딩될 수 있다. 또한, 문서는 HTTP 프로토콜을 통해 사용자의 웹 브라우저로 스트리밍될 수 있다.

[0151] 도 17은 특정한 실시예들에 따른 흐름도를 예시한다. 단계(1701)에서, 사용자는 최종 리포트를 요청할 수 있다. 문서는 미리 정의된 템플릿, JSON 리포트 변수, 및/또는 JSON 리포터 디스크립터들 중 적어도 하나에 따라 어셈블리될 수 있다. 그 후, 단계(1702)에서, 이러한 문서 어셈블리 정보는 데이터소스 플러그인으로 포워딩될 수 있다. 그 후, 데이터소스 플러그인은 데이터베이스로부터 데이터를 수집하고 그리고/또는 그래픽 사용자 인터페이스로부터 정보를 도출할 수 있다. 그 후, 플러그인은 그래프들을 생성하고 부가적인 데이터소스들을 프로세싱하여, 최종 리포트에서 제시되게 할 수 있다.

[0152] 그 후, 데이터소스 플러그인은, 단계(1703)에서 문서를 생성하고, 단계(1704)에서 문서를 사용자에게 전송할 수 있다. 그러나, 문서가 사용자에게 도달하기 전에, 특정한 실시예에서, 문서는 단계 1704에서 예컨대 docxencryptor 툴을 사용하여 패스워드로 암호화될 수 있다. 따라서, 특정한 실시예들에서, 문서는 HTTP를 통해 암호화되고, 사용자의 브라우저로 전송될 수 있다. 다른 실시예에서, 암호화보다는, 리포트는 단지, 암호화 없는 문서, 예컨대 PDF 문서로서 HTTP를 통해 전송될 수 있다.

[0153] 도 18은 특정한 실시예들에 따른 흐름도를 예시한다. 단계(1810)에 도시된 바와 같이, 사용자는 먼저 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결할 수 있다. 단계(1820)에서, 사용자 장비는 클라우드 인프라구조 상에서의 가상 네트워크 기능의 실행을 트리거링할 수 있다. 그 후, 실행된 가상 네트워크 기능을 갖는 클라우드 인프라구조의 키 속성이 클라우드 검증 서비스를 사용하여 테스팅될 수 있다. 키 속성들은 서비스들, 컴퓨팅, 네트워킹, 또는 저장소와 같은 클라우드 인프라구조의 카테고리들을 포함할 수 있다. 단계(1830)에 도시된 바와 같이, 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭이 사용자 장비에서 수신될 수 있다. 메트릭은 사용자 장비에 의해 디스플레이되고, 사용자에 의해 평가될 수 있다. 사용자 장비는 프로세서, 메모리, 및/또는 트랜시버를 포함하는 도 20에 설명된 하드웨어 및/또는 소프트웨어 모두를 포함할 수 있다.

[0154] 도 19a는 특정한 실시예들에 따른 흐름도를 예시한다. 구체적으로, 도 19a는 플랫폼 디바이스에 따른 흐름도를 예시한다. 단계(1901)는, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하는 단계를 포함한다. 단계(1902)에서, 플랫폼 디바이스는 클라우드 인프라구조의 키 속성의 테스트를 스케줄링할 수 있다. 가상 네트워크 기능은 클라우드 인프라구조 상에서 실행될 수 있다. 단계(1903)에서, 스케줄은 플랫폼 디바이스로부터 테스트 에이전트로 전송될 수 있다. 일단 테스트 에이전트가 테스팅을 시작하면, 플랫폼 디바이스는 단계(1904)에 도시된 바와 같이, 가상 네트워크 기능 또는 클라우드 인프라구조의 키 속성의 메트릭들을 수신할 수 있다. 플랫폼 디바이스는, 사용자 인터페이스 상에 메트릭을 디스플레이할 수 있는 사용자 장비에 메트릭들을 전송할 수 있다.

[0155] 도 19b는 특정한 실시예들에 따른 흐름도를 예시한다. 구체적으로, 도 19b는 테스트 에이전트에 따른 흐름도를 예시한다. 단계(1911)에 도시된 바와 같이, 테스트 에이전트는 클라우드 인프라구조의 키 속성에 대해 테스팅하기 위한 요청을 플랫폼 디바이스로부터 수신한다. 단계(1912)에서, 테스트 에이전트는 가상 네트워크 기능 및 클라우드 인프라구조의 키 속성에 대해 테스팅할 수 있다. 그 후, 단계(1913)에 도시된 바와 같이, 테스트 에이전트는 가상 네트워크 또는 클라우드 인프라구조의 키 속성의 메트릭을 플랫폼 디바이스에 전송할 수 있다.

[0156] 도 20은 특정한 실시예들에 따른 시스템을 예시한다. 도 1 내지 도 18, 도 19a, 및 도 19b의 흐름도의 각각의 블록 및 이들의 임의의 조합이 하드웨어, 소프트웨어, 펌웨어, 하나 또는 그 초과의 프로세서들 및/또는 회로와 같은 다양한 수단들 또는 이들의 조합들에 의해 구현될 수 있다는 것이 이해되어야 한다. 일 실시예에서, 시스템은 수개의 디바이스들, 이를테면, 예컨대 플랫폼 디바이스(2010) 및 테스트 에이전트 디바이스(2020)를 포함할 수 있다. 플랫폼 디바이스는 스케줄러, 수집기, 편성기, 분석기 및 리포터, 최종 리포트 생성기, 또는 사용자 인터페이스일 수 있다. 예컨대, 테스트 에이전트 디바이스는 리포터, 로거, 또는 플러깅가능한 실행기일 수 있다.

[0157] 이들 디바이스들 각각은 2021 및 2011로서 각각 표시된 적어도 하나의 프로세서 또는 제어 유닛 또는 모듈을 포함할 수 있다. 적어도 하나의 메모리는 각각의 디바이스에서 제공되고, 2022 및 2012로서 각각 표시될 수 있다. 메모리는 컴퓨터 프로그램 명령들 또는 그 내부에 포함된 컴퓨터 코드를 포함할 수 있다. 하나 또는 그 초과의 트랜시버(2023 및 2013)가 제공될 수 있고, 각각의 디바이스는 또한, 2024 및 2014로 각각 예시된 안테나를 포함할 수 있다. 각각 하나의 안테나만이 도시되었지만, 다수의 안테나들 및 다수의 안테나 엘리먼트들이 디바이스들 각각에 제공될 수 있다. 예컨대, 이들 디바이스들의 다른 구성들이 제공될 수 있다. 예컨대, 플랫폼 디바이스(2010) 및 테스트 에이전트 디바이스(2020)는 무선 통신에 부가하여 유선 통신을 위해 부가적으로 구성될 수 있으며, 그러한 경우, 안테나들(2024 및 2014)은 안테나로만 제한되지 않으면서 임의의 형태의 통신 하드웨어를 예시할 수 있다.

[0158] 트랜시버들(2023 및 2013)은 각각 독립적으로, 송신기, 수신기, 또는 송신기 및 수신기 둘 모두, 또는 송신 및 수신 둘 모두를 위해 구성될 수 있는 유닛 또는 디바이스일 수 있다. 동작들 및 기능들은 다른 엔티티들에서 수행될 수 있다. 또한, 하나 또는 그 초과의 기능들은 서버에서 구동될 수 있는 소프트웨어의 가상 애플리케이션(들)으로서 구현될 수 있다.

[0159] 사용자 인터페이스는 무선 통신 능력들을 갖춘 사용자 디바이스 또는 사용자 장비, 이를테면 모바일 폰 또는 스마트 폰 또는 멀티미디어 디바이스, 컴퓨터, 이를테면 태블릿, 무선 통신 능력들을 갖춘 개인 데이터 또는 휴대 정보 단말(PDA) 또는 이들의 임의의 조합들 상에 로케이팅될 수 있다. 사용자 장비는 또한, 적어도 프로세서, 메모리, 및 트랜시버를 포함할 수 있다.

[0160] 몇몇 실시예에서, 장치, 이를테면 노드 또는 사용자 디바이스는 도 1 내지 도 18, 도 19a, 및 도 19b와 관련하여 위에서 설명된 실시예들을 수행하기 위한 수단을 포함할 수 있다. 특정한 실시예들에서, 컴퓨터 프로그램 코드를 포함하는 적어도 하나의 메모리는 적어도 하나의 프로세서와 함께, 장치로 하여금, 적어도, 본 명세서에 설명된 프로세스들 중 임의의 프로세스를 수행하게 하도록 구성될 수 있다.

[0161] 프로세서들(2011 및 2021)은 임의의 계산 또는 데이터 프로세싱 디바이스, 이를테면 중앙 프로세싱 유닛(CPU), 디지털 신호 프로세서(DSP), 주문형 집적 회로(ASIC), 프로그래밍가능 로직 디바이스(PLD)들, 필드 프로그래밍가능 게이트 어레이(FPGA)들, 디지털적으로 향상된 회로들, 또는 유사한 디바이스 또는 이들의 조합에 의해 구현될 수 있다. 프로세서들은 단일 제어기 또는 복수의 제어기들 또는 프로세서들로서 구현될 수 있다.

[0162] 펌웨어 또는 소프트웨어에 대해, 구현은 적어도 하나의 칩셋의 모듈들 또는 유닛(예컨대, 절차들, 함수들 등)을 포함할 수 있다. 메모리들(2012 및 2022)은 독립적으로 비-일시적인 컴퓨터-판독가능 매체와 같은 임의의 적합한 저장 디바이스일 수 있다. 하드 디스크 드라이브(HDD), 랜덤 액세스 메모리(RAM), 플래시 메모리, 또는 다른 적합한 메모리가 사용될 수 있다. 메모리들은 프로세서와 같은 단일 집적 회로 상에서 결합될 수 있거나, 또는 단일 집적 회로와 분리될 수 있다. 또한, 컴퓨터 프로그램 명령들은 메모리에 저장될 수 있으며, 프로세서들에 의해 프로세싱될 수 있는 그 명령들은 임의의 적합한 형태의 컴퓨터 프로그램 코드, 예컨대, 임의의 적합한 프로그래밍 언어로 쓰여진 컴파일링된 또는 해석된 컴퓨터 프로그램일 수 있다. 메모리 또는 데이터 저장 엔티티는 통상적으로 내장되지만, 또한, 부가적인 메모리 용량이 서비스 제공자로부터 획득되는 경우에서와 같이 외장될 수 있거나, 또는 그들의 조합일 수 있다. 메모리는 고정되거나 제거가능할 수 있다.

[0163] 메모리 및 컴퓨터 프로그램 명령들은, 특정 디바이스에 대한 프로세서와 함께, 플랫폼 디바이스(2010) 및/또는 테스트 에이전트 디바이스(2020)와 같은 하드웨어 장치로 하여금 위에서 설명된 각각의 프로세스들 중 임의의 프로세스를 수행하게 하도록 구성될 수 있다(예컨대, 도 1 내지 도 18, 도 19a 및 도 19b 참조). 따라서, 특정한 실시예들에서, 비-일시적인 컴퓨터-판독가능 매체는, 하드웨어에서 실행될 경우 본 명세서에서 설명된 프로세스들 중 하나와 같은 프로세스를 수행할 수 있는 컴퓨터 명령들 또는 하나 또는 그 초과의 컴퓨터 프로그램(이를테면, 부가된 또는 업데이트된 소프트웨어 루틴, 애플릿 또는 매크로)으로 인코딩될 수 있다. 컴퓨터 프로그램들은 고레벨 프로그래밍 언어, 이를테면 오브젝티브-C, C, C++, C#, 자바 등, 또는 저레벨 프로그래밍 언어, 이를테면 기계어 또는 어셈블러일 수 있는 프로그래밍 언어에 의해 코딩될 수 있다. 대안적으로, 특정한 실시예들은 전체적으로 하드웨어로 수행될 수 있다.

[0164] 위의 실시예들은 클라우드 인프라구조에서의 원격통신 소프트웨어 애플리케이션의 테스팅을 허용한다. 테스팅은 가상 네트워크 기능들과 같은 클라우드 애플리케이션들을 대신하여, 완전히 자동화되고 시스템적인 기능으로 기저 클라우드 인프라구조를 검증하는 데 사용될 수 있다. 위의 실시예들은 또한, 테스트 하에 있는 클라우드 내의 많은 컴퓨팅 노드들에 걸쳐 테스트 및 및 모니터 에이전트들을 갖는 분산형 아키텍처를 배치할 수 있다. 이들 에이전트들은 실제 세계에서 배치될 때 클라우드 애플리케이션들의 거동을 근사할 수 있으며, 기저 컴퓨팅, 네트워크 및 저장소 능력들의 키 속성들을 테스팅할 수 있다.

[0165] 본 명세서 전반에 걸쳐 설명된 특정한 실시예들의 특성들, 구조들, 또는 특징들은 하나 또는 그 초과의 실시예들에서 임의의 적합한 방식으로 결합될 수 있다. 예컨대, 본 명세서 전반에 걸쳐, 어구들 "특정한 실시예들", "몇몇 실시예들", "다른 실시예들", 또는 다른 유사한 언어의 사용은, 실시예와 관련하여 설명된 특정한 특성, 구조, 또는 특징이 본 발명의 적어도 하나의 실시예에 포함될 수 있다는 사실을 지칭한다. 따라서, 본 명세서 전반에 걸쳐, 어구들 "특정한 실시예들에서", "몇몇 실시예들에서", "다른 실시예들에서" 또는 다른 유사한 언어의 등장은 반드시 실시예들의 동일한 그룹을 지칭할 필요는 없으며, 설명된 특성들, 구조들, 또는 특징들은 하나 또는 그 초과의 실시예들에서 임의의 적합한 방식으로 결합될 수 있다.

[0166] 당업자는, 위에서 논의된 바와 같은 본 발명이 상이한 순서의 단계들로 그리고/또는 개시된 것들과 상이한 구성들의 하드웨어 엘리먼트들로 실시될 수 있음을 용이하게 이해할 것이다. 따라서, 본 발명이 이들 바람직한 실시예들에 기반하여 설명되었지만, 특정한 수정들, 변경들, 및 대안적인 구성들이 본 발명의 사상 및 범위 내에서 유지되면서 명백할 것이라는 것은 당업자들에게 명백할 것이다.

[0167] 부분적인 용어사전

[0168] RAN 라디오 액세스 네트워크

[0169] IP 인터넷 프로토콜

[0170] TCP 송신 제어 프로토콜

[0171] UDP 사용자 데이터그램 프로토콜

[0172] SCTP 스트림 제어 송신 프로토콜

[0173] KPIs 키 성능 표시자들

[0174] CSCF 콜 세션 제어 기능

[0175] IMS IP 멀티미디어 시스템

[0176] REST 표현 상태 전달

[0177] API 애플리케이션 프로그램 인터페이스

[0178] UI 사용자 인터페이스

[0179] HBeat 하트비트

[0180] VNF 가상화된 네트워크 기능

[0181] VPN 가상 사설 네트워크

[0182] JSON 자바스크립트 오브젝트 표기

Claims (21)

1. 방법으로서,
   사용자 장비에서, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하는 단계;
   상기 클라우드 인프라구조 상에서의 가상 시뮬레이션을 위한 가상 네트워크 기능의 실행을 트리거링하는 단계 － 상기 클라우드 인프라구조의 키(key) 속성은 상기 클라우드 검증 서비스를 사용하여, 실행된 가상 네트워크 기능으로 테스팅됨 －; 및
   상기 사용자 장비에서, 상기 가상 네트워크 기능 또는 상기 클라우드 인프라구조의 키 속성의 메트릭을 수신하는 단계를 포함하고,
   상기 클라우드 검증 서비스는 핑거프린팅 기술에 추가로 기초하는, 방법.
2. 제1항에 있어서,
   상기 가상 네트워크 기능 또는 상기 클라우드 인프라구조의 키 속성의 메트릭은, 기준 키 속성 또는 이전에 테스팅되었던 가상 네트워크 기능과 비교되고,
   상기 기준 키 속성은 동일한 클라우드 또는 상이한 클라우드로부터의 것인, 방법.
3. 제1항에 있어서,
   상기 메트릭은, 상기 클라우드 인프라구조 또는 상기 가상 네트워크 기능이 송신 제어 프로토콜, 사용자 데이터그램 프로토콜, 또는 스트림 제어 송신 프로토콜 중 적어도 하나를 사용하고 있는지를 테스팅하는 것을 수반하는, 방법.
4. 제1항에 있어서,
   상기 사용자 장비의 사용자 인터페이스 상에 상기 메트릭을 디스플레이하는 단계를 더 포함하는, 방법.
5. 제1항에 있어서,
   상기 가상 네트워크 기능 또는 상기 클라우드 인프라구조의 키 속성의 테스팅 동안 분산형 아키텍처가 사용되고, 상기 분산형 아키텍처는 상기 클라우드 인프라구조에서 복수의 컴퓨팅 노드들에 걸쳐있는 아키텍처를 포함하는, 방법.
6. 제1항에 있어서,
   상기 클라우드 인프라구조의 적어도 2개의 컴퓨팅 노드들에서 상기 키 속성의 테스팅을 모니터링하는 단계를 더 포함하는, 방법.
7. 제1항에 있어서,
   상기 키 속성들은 상기 클라우드 인프라구조의 컴퓨팅, 네트워킹, 저장, 또는 서비스 능력들 중 적어도 하나를 포함하는, 방법.
8. 제1항에 있어서,
   상기 테스팅하는 것은 상기 클라우드 내부의 상이한 네트워크 경로들 또는 토폴로지를 평가하는 것을 포함하는, 방법.
9. 제1항에 있어서,
   상기 메트릭은 상기 키 속성을 기준 클라우드 인프라구조와 비교하기 위한 등급을 포함하는, 방법.
10. 제1항에 있어서,
    상기 메트릭의 생성된 리포트를 수신하는 단계; 및
    상기 사용자 장비에서 상기 리포트를 디스플레이하는 단계를 더 포함하는, 방법.
11. 장치로서,
    컴퓨터 프로그램 코드를 포함하는 적어도 하나의 메모리; 및
    적어도 하나의 프로세서를 포함하며,
    상기 적어도 하나의 메모리 및 상기 컴퓨터 프로그램 코드는 상기 적어도 하나의 프로세서와 함께, 상기 장치로 하여금, 적어도,
    플랫폼 디바이스에 의해, 클라우드 인프라구조를 테스팅하기 위해 클라우드 검증 서비스에 연결하게 하고;
    상기 플랫폼 디바이스에 의해, 상기 클라우드 인프라구조의 키 속성의 테스팅을 스케줄링하게 하고 － 가상 시뮬레이션을 위한 가상 네트워크 기능이 상기 클라우드 인프라구조 상에서 실행됨 －;
    상기 플랫폼 디바이스에 의해, 상기 스케줄링을 테스트 에이전트에 전송하게 하며; 그리고
    상기 플랫폼 디바이스에 의해, 상기 가상 네트워크 기능 또는 상기 클라우드 인프라구조의 키 속성의 메트릭을 수신하게 하도록
    구성되고,
    상기 클라우드 검증 서비스는 핑거프린팅 기술에 추가로 기초하는, 장치.
12. 제11항에 있어서,
    상기 장치는, 상기 메트릭을 사용자 장비에 전송하도록 추가로 구성되는, 장치.
13. 제11항에 있어서,
    상기 장치는, 상기 메트릭을 데이터베이스에 저장하도록 추가로 구성되는, 장치.
14. 제11항에 있어서,
    상기 장치는, 상기 가상 네트워크 기능 또는 상기 클라우드 인프라구조의 키 속성의 테스팅의 진행을 모니터링하도록 추가로 구성되는, 장치.
15. 명령들을 인코딩한, 클라우드 검증 서비스를 위한 비-일시적인 컴퓨터-판독가능 매체로서,
    상기 명령들은, 하드웨어에서 실행될 경우,
    클라우드 인프라구조의 키 속성에 대해 테스팅하기 위한 요청을 플랫폼 디바이스로부터 수신하고 － 가상 시뮬레이션을 위한 가상 네트워크 기능이 상기 클라우드 인프라구조 상에서 실행됨 －;
    상기 가상 네트워크 기능 및 상기 클라우드 인프라구조의 키 속성에 대해 테스팅하며; 그리고
    상기 가상 네트워크 기능 또는 상기 클라우드 인프라구조의 키 속성의 메트릭을 상기 플랫폼 디바이스에 전송하도록
    구성되고,
    상기 클라우드 검증 서비스는 핑거프린팅 기술에 추가로 기초하는, 비-일시적인 컴퓨터-판독가능 매체.
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제

Images