문서요약 - 소프트웨어 테스팅을 위한 테스트 환경 by guru99

제목: 소프트웨어 테스팅을 위한 테스트 환경(Test Environment for Software Testing)

저자: guru99

문서유형: 웹 사이트 문서

출처: http://www.guru99.com/test-environment-software-testing.html

http://www.softwaretestinghelp.com/test-bed-test-environment-management-best-practices/

---

테스트 베드 또는 테스트 환경이란

• ‘테스트 베드’는 개발자/테스터가 라이브 생산 서버에 영향을 주지 않고 자신의 모듈을 테스트할 수 있도록 허용하는 소프트웨어 개발 환경을 의미하며, ‘테스트 환경’으로도 불려짐
• 테스팅 환경은 테스팅 팀이 테스트 케이스를 실행할 수 있도록 하는 소프트웨어와 하드웨어의 셋업. 즉, 테스트 실행을 지원하는 하드웨어, 소프트웨어, 그리고 네트워크의 구성이다.
• 테스트 베드(또는 테스트 환경)가 테스트 대상 애플리케이션의 필요에 따라 구성됨. 간혹 테스트 베드가 테스트 환경과 이 테스트 환경이 운용하는 테스트 데이터의 조합을 의미하기도 함

테스트 환경을 위해 셋업되어야 할 주요 영역

• 시스템과 애플리케이션
• 테스트 데이터
• 데이터베이스 서버
• 프론트엔드 가동 환경(Front end running environment)
• 클라이언트 운영체제
• 브라우저
• 서버 운영체제를 포함한 하드웨어
• 네트워크
• 요구되는 문서(예, 참고 문서, 구성 가이드, 설치 가이드, 사용자 매뉴얼)

소프트웨어 테스트 환경 셋업 프로세스

테스트 환경이 아래와 같은 다양한 분야의 셋업을 요구함 

• 테스트 서버 셋업: 로컬 머신 상에서 모든 테스트가 실행될 수 없는 경우도 있으므로, 애플리케이션을 지원할 수 있는 테스트 서버 설치가 필요. 예, PHP를 위한 Fedora 셋업, 메일 서버를 가진(또는 가지지 않은) Java 기반 애플리케이션, cron 셋업 등
• 네트워크: 테스트 요구사항에 따른 네트워크 셋업. 예, 인터넷 셋업, LAN Wifi 셋업, 사설망 셋업 등. 테스팅 동안 발생한 트래픽 폭주가 다른 구성원(개발자, 설계자, 콘텐츠 작성자 등)에게 영향을 주지 않도록 보장
• 테스트 PC 셋업: 웹 테스팅에서 여러 다른 테스터가 여러 다른 브라우저를 사용하도록 셋업하고, 데스크탑 애플리케이션에서는 여러 테스터 PC에 다양한 타입의 운영체제가 설치되도록 셋업할 필요가 있을 수 있음. 예, 윈도우 폰 앱 테스팅에서 Visual Studio 설치, 윈도우 폰 에뮬레이터, 또는 테스터에게 윈도우 폰을 할당하는 것이 요구됨
• 버그 보고: 버그 보고를 위한 툴이 테스터에게 제공되어야 함
• 테스트 환경을 위한 테스트 데이터 생성: 많은 조직이 소프트웨어 제품을 테스트 하기 위해 별개의 테스트 환경을 사용. 여기서 흔히 사용되는 방법이 생산 데이터(production data)를 테스트 환경에 복사하는 것이며, 이는 테스터가 생산 데이터를 훼손하지 않으면서 라이브 생산 서버에서 발생하는 것과 같은 동일한 이슈를 발견하도록 돕는다. 생산 데이터를 복사하는데 있어 주요 이슈가 프라이버시이며, 이 문제를 극복하기 위해 테스트 데이터를 난독화(obfuscation) 또는 익명화(anonymization) 처리함

테스트 환경 체크리스트

하드웨어	테스팅을 위해 필요한 장비가 가용한가? 그렇지 않은 경우 공급 시기 확인
	주변 장비(예, 스캐너, 특수 프린터, 초소형 컴퓨터 등)가 가용한가?
소프트웨어/커넥션	필요시되는 애플리케이션(예, 액셀, 워드, 드로잉 등)이 명세되었는가?
	신규 소프트웨어를 위한 테스트 환경이 조직에 존재하는가? 조직이 해당 소프트웨어의 사용과 유지보수 경험을 가지고 있는가?
환경 데이터	표준 테스트 데이터 셋이 가용한가?
	테스트 데이터 오너와 테스트 데이터에 대한 합의가 존재하는가?
유지보수 도구/프로세스	테스트 환경 유지보수를 위한 단일 접촉점(담당자)이 존재하는가? 그렇지 않은 경우 테스트 환경이 가동되도록 유지하는데 관여하는 모든 구성원들의 목록을 준비(그들의 연락처 정보도 포함)
	테스트 환경의 준비 정도(readiness)와 품질에 대한 합의에 도달했는가? 예, 승인 기준, 유지보수 요구사항 등
	유지보수 프로세스에 관련된 모든 구성원들이 알려져 있는가?
테스트 환경 수립 전에 확인할 사항	내부적으로 테스트 환경을 개발할 것인가 아니면 아웃소싱을 할 것인가?
	내부 회사 표준을 따를것인가 아니면 외부 표준(예, IEEE, ISO)을 따를 것인가?
	얼마나 오랫 동안 테스트 환경이 필요로 되는가?
	테스트 시스템과 생산 시스템 간의 차이가 무엇이고, 이것이 테스트 유효성(test validity)에 미치는 영향이 무엇인가?
	조직 내 다른 프로젝트를 위한 기존 셋업을 재사용할 수 있는가?

 

테스트 환경 관련 흔히 마주치는 어려움

• 원격 환경(Remote environment): 테스트 자산/환경이 테스트 팀과 지리적으로 떨어진 장소에 위치할 수 있으며, 이 경우 테스팅 팀이 해당 자산이 위치한 장소의 지원 팀에 크게 의존할 수 밖에 없음. 이런 상황이 테스팅 시간을 잡아 먹고 일정을 지연시키는 결과로 이어질 수도 있다.
• 여러 팀의 공동 사용(Combined usage between teams): 이론 상으로는 개발, 테스트, 생산 환경이 분리되어야 하지만 현실에서는 비용 등의 이유로 개발 팀과 테스팅 팀이 동시에 동일한 환경 자산을 사용하기도 함. 이 경우 테스트 결과가 변질되거나 구성원들 간의 다툼과 혼란이 생길 수도 있음
• 통합을 위한 리소스 사용에 대한 비효과적 계획(Ineffective planning for resource usage for integration): 단-대-단 테스팅을 필요로 하는 시나리오(즉, 두 개 또는 그 이상의 컴포넌트들이 통합되어 함께 동작해야 하는 경우)에서 테스트 팀들 간에 리소스를 공동으로 사용해야 할 필요가 생길 수 있음. 이런 사용에 관한 계획이 부적절한 경우 환경이 불안정해지거나(같은 시나리오를 실행시켰을 때 완전히 다른 동작이 결과로 나타남) 팀 간의 충돌이 생길 수 있다.
• 복잡한 테스트 구성(Complex test configuration): 특정 테스트가 아주 복잡한 테스트 베드 구성(테스트 환경 구성)을 요구할 수도 있는데, 이게 테스트 팀에게 여러 어려움을 줄 수 있음. 해당 구성을 이해할 수 있는 스킬/지식을 가진 테스터가 가용하지 않은 경우 테스터가 테스트 베드를 부정확하게 구성함으로써 테스트 베드 자체에 에러를 유발할 수 있으며, 여기서 나오는 테스트 케이스 결과가 크게 영향을 받게 됨
• 공들인 셋업 시간(Elaborate setup time): 특정 경우에 각 테스트 케이스를 위한 테스트 셋업에 지나치게 정성을 들여야 할 필요가 있음. 예를 들면, 통합 테스트에서 각양각색의 기술들이 함께 연결될 필요가 있거나 또는 다수의 컴포넌트들이 함께 동작되어야 하기 때문에 이런 상황이 됨. 이 경우 일관성 있는 결과를 보장하기 위해서는 컴포넌트들 각각이 완벽하게 동작해야만 함(한 컴포넌트가 다음 컴포넌트의 입력물을 만들어 낼 수도 있므므로)