what is infrastructure testing
이 종합적인 인프라 테스트 가이드에서는 장점, 과제, 인프라 테스트 도구 및 방법론을 다룹니다.
인프라는 많은 프로젝트에서 공유됩니다. 인프라 테스트는 소프트웨어 제품을 실행하는 데 필요한 하드웨어 및 소프트웨어 종속성을 테스트하는 것입니다. 대상 인프라와 관련된 제품 위험을 처리하는 데 도움이됩니다.
이 자습서는 인프라 테스트를 처음부터 배우는 데 도움이됩니다. 이점과 과제, 수행 할 수있는 사람, 수행 할시기 및이 테스트를 수행하는 기술과 같은 전체 세부 정보를 다룹니다. 이 자습서에서는 인프라 테스트 도구도 다룹니다.
학습 내용 :
인프라 란?
IT 인프라 에코 시스템에는 운영 체제 플랫폼 (예 : Windows, UNIX, Linux, macOS), 컴퓨터 하드웨어 플랫폼 (예 : Dell, IBM, Sun, HP, Apple), 인터넷 플랫폼 (예 : Apache, Cisco, Microsoft IIS, .NET)이 포함됩니다. ), 데이터 관리 및 스토리지 (예 : IBM DB2, Oracle, SQL Server, MySQL) 및 엔터프라이즈 소프트웨어 애플리케이션 (예 : SAP, Oracle, Microsoft).
인프라 테스트 란 무엇입니까?
모든 소프트웨어에는 작업을 수행하기위한 인프라가 필요합니다. 인프라 테스트는 하드웨어, 소프트웨어 및 네트워크를 다루는 테스트 프로세스입니다. 여기에는 IT 프레임 워크의 여러 항목에서 구성 값을 읽고 의도 한 결과와 비교하는 코드 테스트가 포함됩니다.
실패의 위험을 줄여줍니다. 이 테스트는 테스트 연습, 절차를 통합하여 IT 애플리케이션과 기본 인프라가 실행, 적응성, 흔들리지 않는 품질, 접근성, 성능 및 확장 성을 제공하도록 조정되었는지 확인합니다. 목표는 테스트 환경, 테스트 도구 및 사무실 환경 간의 인프라를 테스트하는 것입니다.
인프라 테스트가 필요한 이유는 무엇입니까?
조직은 비즈니스 애플리케이션이 완벽하게 테스트되었는지 확인하기 위해 많은 비용을 지출합니다. 그러나 이러한 애플리케이션을 호스팅하고 전달하는 인프라와 같은 기본 기반은 가끔씩 테스트되고 일반적으로 과소 평가됩니다.
셀레늄 웹 드라이버 예제의 데이터 기반 프레임 워크
하드웨어 또는 소프트웨어 구성 요소의 오류 위험을 완화하려면 인프라 테스트가 필요합니다. 소프트웨어에 대한 새로운 인프라 설계가 준비되면이 테스트를 수행해야합니다. 새로운 인프라 기능이 의도 한대로 작동하는지 확인해야합니다. 새로운 인프라 모듈이 프로젝트에 통합되면 문제가 발생할 가능성이 더 높습니다.
확장 가능한 인프라에 대한 테스트가 계획되지 않은 경우 인프라 오류가 발생합니다. 따라서 중단 및 마지막 순간 문제를 방지하려면이 테스트를 수행해야합니다.
이 테스트는 여러 테스트 프로세스에서 효율적으로 발견되지 않은 결함을 식별하는 데 필요합니다. 하드웨어 및 소프트웨어 리소스가 변경 될 때마다 소프트웨어 응용 프로그램을 분석하는 것이 중요합니다. 시스템 효율성과 성능을 분석하기 위해 수행됩니다.
프로젝트에는 인프라 비용이 많이 들기 때문에이 테스트 유형을 적시에 구현해야합니다. 따라서 프로젝트 위험과 관련된 비용을 최소화하려면이 테스트에 대한 충분한 지식이 필요합니다. 실패를 방지하기 위해이 테스트는 산업 표준으로 필요합니다.
인프라 테스트의 이점은 무엇입니까?
인프라 테스트의 계획되고 철저한 접근 방식은 소프트웨어 제품과 조직에 많은 이점을 제공합니다.
다음과 같은 몇 가지 혜택이 있습니다.
- 생산 실패 감소.
- 생산 실행 전 결함 식별 개선. 생산에 결함이 전혀 없도록 인프라 품질을 업그레이드하십시오.
- 테스트 실행이 빨라져 조기에 라이브로 전환 할 수 있습니다.
- 운영 및 비즈니스에서 연간 비용 절감에 도움이됩니다.
- 소프트웨어가 체계적이고 통제 된 절차로 작동하는지 확인합니다.
- 다운 타임 감소.
- 서비스 품질 향상.
- 안정적인 환경의 가용성.
- 위험과 관련된 비용 감소.
- 더 나은 사용자 경험.
인프라 테스트의 과제
기업이 인프라 테스트를 채택하려고 할 때 직면하게되는 몇 가지 과제를 살펴 보겠습니다.
# 1) 원격 환경
테스트 환경 또는 리소스는 지형적으로 먼 로케일에 위치하므로 테스트 팀은 해당 영역의 지원 그룹에 의존하여 장비, 하드웨어 구성 요소, 소프트웨어 구성 요소, 네트워킹 등과 관련된 문제를 관리합니다.이 경우 시간 및 원인과 관련하여 약간의 투자가 필요한 경우가 많습니다. 지연, 특히 팀이 다른 시간대에있는 경우.
# 2) 전담 팀 부재
팀 간의 지식 부족은이 테스트를 수행하는 데있어 주요 과제입니다. 일정, 계획, 적용 범위, 상태 보고서를 포함한 모든 활동과 관련된 정보를 유지하려면 전담 팀이 필요합니다.
# 3) 테스트 환경 문제 조사
여러 번 테스트 환경 문제를 해결할 수 없으며 조사가 필요합니다. 문제가 해결 될 때까지 관련 팀과의 조정이 필요합니다.
# 4) 한곳에서 환경 유지
테스트 환경의 공통 저장소, 이전 호환성 및 최신 버전을 유지하는 것은이 테스트를 수행하는 동안 큰 문제가됩니다. 모든 버전의 연결 세부 정보 및 구성은 유지되지 않습니다.
# 5) 수작업
이 테스트와 관련된 활동은 도구를 사용할 수 없으므로 수동 작업이 필요하지 않습니다. 이로 인해 인적 오류가 발생하고 프로세스가 지연됩니다.
# 6) 인프라 테스트에 대한 표준 정의 부족
대부분의 사람들은 여전히 구현 및 프로세스를 인식하지 못합니다. 부적절한 지식과 이해는 종종 구현에 어려움을 초래합니다. 프로세스가 안정되는 데 영향을 미칠 수있는 많은 새로운 문제가 발생합니다.
# 7) 고립 된 팀
팀 위치간에 큰 격차가 있습니다. 이것은 일반적으로 투명성과 팀워크 부족으로 이어집니다.
누가 인프라 테스트를 수행 할 수 있습니까?
이 테스트 유형에는 다양한 팀이 참여합니다. 아래에 설명되어 있습니다.
# 1) 인프라 테스트 팀
인프라 테스트 팀은이 테스트와 관련된 많은 지식을 가지고 있습니다. 그들은 또한 품질 보증 팀과 관련되어 있습니다. 이 팀은 IT 인프라를 테스트하는 방법을 알고 있습니다. 이 팀은 이러한 유형의 테스트를위한 테스트 케이스를 설계하는 방법을 알고 있습니다.
# 2) 시스템 관리자 팀
시스템 관리자 팀은 종종 네트워크 수준 인프라를 테스트합니다. 경험을 바탕으로 팀을 설계하고 테스트 사례를 문서화합니다. 네트워크 변경 후 애플리케이션이 영향을받지 않도록 할 책임이 있습니다.
# 3) 인프라 유지 관리팀
이 팀은 매우 중요한 역할을합니다. 그들은 초기 단계에 참여하고 요구 사항에 따라 테스트 환경을 설정하는 책임이 있습니다. 그들은 테스트 계획 및 인프라 환경 유지 관리에 참여합니다.
# 4) 품질 보증팀
QA 팀은 회귀 테스트를 실행합니다. 또한 통합 테스트에도 참여합니다. 그들은 서로 다른 인프라에 따라 생성 된 서로 다른 테스트 환경에서 테스트를 수행합니다.
# 5) 프로젝트 매니저
프로젝트 관리자는 프로젝트를 처리 할 책임이 있습니다. 이들은이 테스트 유형에 필요한 테스트 케이스의 계획, 설계, 문서화에 관여합니다. 프로젝트 관리자는 모든 팀과 동기화됩니다.
인프라 테스트를 언제 수행해야합니까?
인프라 관련 변경 사항이 도입 될 때마다이 테스트를 시급하게 수행해야합니다.
이러한 변경의 예는 다음과 같습니다.
- 시스템의 모든 새 패치가 개발됩니다.
- 새로운 시스템 업데이트가 발생합니다.
- 운영 체제의 모든 업데이트.
- 데이터베이스 버전 / 구조가 업그레이드됩니다.
- 서버에 대한 메모리 업그레이드가있는 경우.
- 새로운 도구의 구현.
- 보안 수정.
- 소프트웨어 업데이트.
때때로이 테스트 유형은 데이터베이스 또는 데이터 센터 마이그레이션이 발생할 때 더 중요해집니다. 애플리케이션에 다양하고 빠른 변화가있을 때와 인프라 마이그레이션이 관련 될 때 더 많은 초점이 필요합니다.
소프트웨어에 대한 새로운 장치 지원이 도입 될 때도 수행됩니다.
예:
- 새로운 노트북 / 데스크톱
- 새로운 모바일 장치
- 새로운 타사 도구
인프라 테스트 방법론
여기에는 다른 모듈이 있습니다. 그 중 몇 가지가 아래에 나열되어 있습니다.
- 서버 / 클라이언트 인프라
- 데이터 마이그레이션
- 클라우드의 인프라 테스트
- 네트워크 수준 테스트
- 설치 / 제거 / 배포
- 테스트 환경 인프라
- TDD 접근법
# 1) 서버 / 클라이언트 인프라
서버에는 웹 서버, 파일 서버, 메일 서버, 프록시 서버, 가상 서버 및 하드웨어의 물리적 서버가 포함됩니다. 클라이언트에는 OS, 애플리케이션, 사용자 설정 등이 포함됩니다. 서버는 서로 다른 서비스를 실행하며 이러한 서비스는 클라이언트에서 사용할 수 있습니다.
주요 목표는 서버, 데스크톱, 운영 체제 및 하드웨어의 품질을 테스트하는 것입니다. 서버 / 클라이언트 구성 요소를 테스트하여 프로덕션 환경에서 인프라의 성능이 향상되었는지 확인합니다. 또한 응용 프로그램의 설치 또는 제거 테스트, 브라우저 호환성 테스트, 다양한 버전의 OS 및 사용자 설정을 사용한 통합 테스트가 포함됩니다.
순서:
- 가장 중요한 것은 이해 관계자의 요구 사항을 수집하는 것입니다.
- 필요한 인프라의 이해에 따라 테스트 계획을 설계하십시오.
- 그런 다음 운영 체제 지원, 업그레이드 시나리오, 서버 / 클라이언트 인프라 테스트 범위 및 기능 테스트를 포괄하는 테스트 사례를 설계합니다.
- 테스트 케이스 승인 후 QA 팀은 각 시나리오와 해당 테스트 케이스를 실행합니다.
업그레이드, 구성 변경과 같은 모든 서버 / 클라이언트 관련 변경 사항은 이미 QA 설정에서 테스트되었으므로 프로덕션 환경에서 가능한 영향을 최소화 할 수 있습니다. 또한 프로덕션에 배포하기 전에 다양한 OS 버전을 테스트합니다. 또한 프로덕션에서 실패한 경우 백업을 보장하기 위해 사전에 폴백 절차를 테스트합니다.
# 2) 데이터 마이그레이션
데이터 마이그레이션에는 이전 버전에서 새 버전으로 마이그레이션 된 데이터, 한 서버에서 다른 서버로 마이그레이션 된 데이터 및 다른 구성으로 마이그레이션 된 데이터가 포함됩니다.
데이터 마이그레이션 테스트의 주요 목표는 다양한 버전, 서버, 새 빌드에서 데이터 마이그레이션을 테스트하는 것입니다. 마이그레이션으로 인한 영향이 없음을 확인하기 위해 애플리케이션을 테스트하십시오. 데이터 마이그레이션 테스트는 응용 프로그램의 성능과 대기 시간을 확인하기 위해 수행됩니다.
순서:
- 마이그레이션 전후에 응용 프로그램을 테스트합니다.
- 데이터 마이그레이션 전후에 서버를 테스트하여 변경 사항이 없는지 확인하십시오.
- 데이터 마이그레이션 후 애플리케이션 성능에 변화가 없는지 테스트합니다.
- 다른 버전의 데이터베이스로 애플리케이션 테스트
- 새 빌드가 모든 버전의 데이터베이스와 호환되는지 테스트합니다.
- 다른 데이터베이스 버전으로 서버의 다른 구성 설정 테스트
데이터 마이그레이션 테스트를 통해 서버 구성이 일치하지 않는 것을 발견 할 수 있습니다. 데이터 마이그레이션을 수행하는 동안 존재하는 모든 서버 빌드 문제는 프로덕션 배포 전에 해결할 수 있습니다. 데이터 마이그레이션 테스트는 제품의 품질과 안정성을 향상시킵니다. 이 테스트는 나중에 프로덕션 환경에 애플리케이션을 배포하는 동안 설치 테스트에 도움이됩니다.
# 3) 클라우드에서 인프라 테스트
정보와 데이터는 대부분 가상 서버에 저장되며 이러한 서버는 AWS와 같은 클라우드 컴퓨팅 공급 업체에서 유지 및 관리합니다.
주요 목표는 다양한 버전의 애플리케이션에 대해 클라우드 서비스를 인증하는 것입니다. 클라우드에서 애플리케이션 아키텍처를 테스트합니다. 실제 애플리케이션이 클라우드에서 시뮬레이션되고 애플리케이션의 성능과 확장 성이 테스트됩니다.
순서:
- 다른 구성으로 애플리케이션의 부하를 테스트합니다.
- 회귀 테스트를 수행하고 애플리케이션이 부하 테스트에 영향을주지 않는지 확인합니다.
- 애플리케이션이 클라우드 환경에서 호환되는 브라우저인지 테스트합니다.
- 클라우드에 애플리케이션 설치를 테스트합니다.
- 애플리케이션이 다양한 클라우드 환경에서 예상대로 작동하는지 테스트합니다.
클라우드의 인프라 테스트는 프로덕션 환경에서 오류없는 애플리케이션 구현을 보장합니다. 응용 프로그램의 성능, 확장 성 및 안정성을 파악하는 데 도움이됩니다. 하드웨어, 소프트웨어 및 인프라와 같이 클라우드에있는 리소스를 활용하는 데 도움이됩니다.
# 4) 네트워크 수준 테스트
네트워크는 애플리케이션 인프라의 가장 중요한 부분입니다. 네트워크는 서버, 클라이언트 및 기타 네트워크 간의 통신을 돕습니다. 네트워크에는 프록시 서버, 인터넷 연결을위한 인프라와 같은 다른 모듈이 있습니다.
주요 목표는 과도한 리소스 사용, 서버 다운 타임, 시스템 구성, 운영에 필요한 인프라, 운영 체제 패치와 같은 네트워크 수준 문제를 제어하고 관리하는 것입니다.
순서:
- 향후 애플리케이션 업데이트를 위해 네트워크 계층을 테스트합니다.
- 프로덕션 환경에서 오류가 발생한 경우 대체 절차를 테스트합니다.
- 시스템 테스트, UAT 테스트, 보안 테스트를 수행합니다.
- 테스트 케이스를 설계하고 테스트 데이터를 준비합니다.
- 새 릴리스 이후 서버 / 네트워크 수준 서비스가 영향을받지 않는지 확인합니다.
- 격리 된 네트워크를 테스트합니다.
- VPN, Wi-Fi, LAN 등과 같은 다양한 네트워크에서 애플리케이션 성능에 미치는 영향을 테스트합니다.
네트워크 수준 인프라 테스트는 복구 시간을 개선합니다. 백업을 보장하고 메커니즘을 복원합니다. 응용 프로그램의 보안에도 도움이됩니다.
# 5) 설치 / 제거 / 배포
설치를 수행하는 동안 인프라 테스트의 주요 목적은 새 클라이언트가 응용 프로그램을 사용할 때마다 응용 프로그램을 처음 설치할 때 문제가 발생하지 않도록하는 것입니다. 애플리케이션 제거는 애플리케이션의 종료 프로세스를 테스트하기 위해 수행됩니다.
순서:
- 응용 프로그램을 설치하는 데 필요한 설치 프로그램 패키지를 테스트합니다.
- 추가 라이브러리를 테스트하고 패키지를 빌드하십시오.
- 응용 프로그램을 설치하고 제거하는 데 필요한 시간을 테스트하십시오.
- 다른 운영 체제에 응용 프로그램을 설치합니다.
- 필요한 디스크 공간을 테스트하십시오.
- 응용 프로그램 제거 후 모든 파일이 제거되었는지 테스트합니다.
설치 / 제거 / 배포 중에 인프라를 테스트하면 특정 시간에 네트워크를 통해 애플리케이션을 설치할 수 있습니다. 나중에 패치를 설치할 수 있는지 여부를 확인합니다. 애플리케이션에 필요한 스토리지를 개선하는 데 도움이됩니다.
# 6) 테스트 환경 인프라
테스트 환경은 하드웨어, 소프트웨어, 도구 및 프로세스의 모음입니다. 테스트를 정확하고 효율적으로 수행하려면 테스트 환경이 필요합니다. 테스트 환경에는 테스터가 작업을 수행 할 수 있도록 양호한 네트워크, PC 및 전원 공급 장치가 제공되는 작업장도 포함됩니다.
주요 목표는 소프트웨어 설치, 애플리케이션 구성 설정을 확인하고 테스트 계획, 테스트 실행을 지원하는 올바른 테스트 도구를 선택하는 것입니다. 또한 테스트 실행의 연속성을 보장합니다.
순서:
- 프로젝트의 정기 릴리스를위한 테스트 환경을 설정하십시오.
- 핫픽스 릴리스를위한 테스트 환경을 만듭니다.
- 서버 및 클라이언트 환경 문제를 관리하기위한 솔루션을 만듭니다.
- 테스트 계획, 테스트 설계 및 실행을위한 테스트 도구를 완성합니다.
- 버그를 디버깅하고보고하기위한 도구를 결정합니다.
- 테스트 환경 설정을위한 문서를 만듭니다.
도구 및 테스트 환경을 사용하면 여러 가지 이점이 있습니다. 더 높은 품질이 관찰됩니다. 도구를 사용하면 생산성이 향상됩니다. 테스트 활동은 처리 된 방식으로 수행됩니다. 테스트 환경의 문서화는 팀의 새로운 구성원이 더 잘 이해하는 데 도움이됩니다.
# 7) TDD 접근법
Test-Driven Development 또는 TDD 프레임 워크는 먼저 요구 사항 문서를 기반으로 테스트 케이스를 작성한 다음 테스트에 따라 기능을 구현하는 방법입니다.
주요 목표는 프로젝트에 필요한 인프라 리소스를 아는 것입니다. 목적은 보안, 운영 및 생산을위한 인프라를 정의하고 구성하는 것입니다.
순서:
- 인프라 요구 사항에 대한 설계 문서.
- 애플리케이션에 필요한 인프라를 포함하는 테스트 계획을 설계합니다.
- 인프라 테스트와 관련된 테스트 케이스를 설계합니다.
- 다른 구성을 테스트합니다.
TDD 접근 방식은 프로젝트의 복잡성을 개선하는 데 도움이됩니다. 인프라에 대한 모든 변경 사항은 프로덕션으로 푸시하기 전에 테스트됩니다. 테스트가 이미 설계되었으므로 다른 가능한 구성을 구현할 수 있습니다.
인프라 테스트 도구
요리사, 과 Ansible 동일한 목적을 제공하는 다른 도구입니다. 이러한 도구는 응용 프로그램에 필요한 여러 서버를 배포하고 구성하는 데 사용됩니다. 이러한 도구는 인프라와 관련된 복잡한 작업이있을 때 큰 도움이됩니다. 팀은 이러한 도구를 사용하여 여러 서버에서 함께 작업을 쉽게 실행할 수 있습니다.
이러한 도구를 사용하는 팀은 여러 응용 프로그램, 종속성 및 라이브러리를 빠르게 배포합니다. 기타 활동에는 서버, 바이너리, 로그 파일, 복구 메커니즘, 버전 업그레이드, 데이터베이스 관리가 포함됩니다.
# 1) 요리사
풍모: Chef는 Ruby 도메인 특정 언어를 지원합니다. 따라서 개발자가 아닌 사람은이 도구를 배우기가 어려워집니다. 언어 지원이 어렵지만이 도구는 가용성이 높습니다. Chef는 마스터-슬레이브 구성을 따릅니다. 마스터-슬레이브 메커니즘에서 기본 서버, 즉 chef-server는 어떤 경우 에든 오류가 발생하면 백업 서버로 대체 될 수 있습니다.
Chef를 사용하여 애플리케이션을 배포하고, 인프라를 구성하고, 네트워크를 구성 할 수도 있습니다. 보안 수준이 높지 않습니다.
테스트 케이스와 테스트 시나리오의 차이
가격: Puppet보다 저렴하지만 Ansible보다 비쌉니다. 가격은 최대 100 개 노드까지 연간 약 $ 13.5k입니다.
웹 사이트 : 주요한
# 2) 꼭두각시
풍모: Puppet은 Ruby로 빌드되었으며 DSL 및 Embedded Ruby를 지원합니다. 프로그래머는 Puppet을 사용하도록 선택한 경우에만 구성을 관리 할 수 있습니다. 시스템 관리자 팀은이 도구의 구성도 알고 있습니다. 마스터-마스터 아키텍처를 따릅니다. 활성 마스터에 오류가 발생하면 다른 마스터가이를 교체 할 수 있습니다.
Puppet은 모든 호스트에 대해 서로 다른 구성을 설정할 때 시스템의 확장성에 유용합니다. 구성이 변경된 경우이 도구는 전역 적으로 변경하는 데 도움이됩니다. 또한 보안 수준이 높은 도구도 아닙니다.
가격: 가격은 최대 100 개 노드에 대해 연간 약 $ 11,000 ~ $ 20,000로 가장 높습니다.
웹 사이트 : 인형
# 3) Ansible
풍모: Ansible은 Python으로 작성되었으며 YAML 명령 스크립트도 지원합니다. Python은 사람이 읽을 수 있으므로이 도구는 시스템 관리자에게 이상적입니다. 단일 활성 노드로 실행되지만 오류가 발생하는 경우 보조 노드도 있습니다.
Ansible은 확장 성이 뛰어납니다. 즉, 문제없이 많은 수의 노드를 관리 할 수 있습니다. Puppet에 비해 Ansible은 확장 성 측면에서 더 편리합니다. Chef 및 Puppet과 달리 SSH를 사용하는 매우 안전한 도구입니다.
가격: 가격은 최대 100 개의 노드에 대해 연간 약 $ 10k 인 Puppet 및 Chef보다 훨씬 저렴합니다.
웹 사이트 : Ansible
결론
기업은 인프라에 높은 비용을 부담하므로 소프트웨어 개발 수명주기에 인프라 테스트가 필요합니다. 이 자습서에서는 이점, 과제, 기술 및이 테스트 유형에 관련된 사람들과 같은 다양한 주제를 다룹니다. 인프라 테스트 도구에 대해서도 간략히 설명합니다.