how effectively prepare test bed
테스트 베드 / 테스트 환경 설정 과제 및 모범 사례 :
여러 경우 테스터는 환경 문제로 인해 결함이 거부되거나 유사한 이유로 결함을 지속적으로 복제하는 것을 발견합니다. 가장 많은 수의 결함을 여는 것은 확실히 모든 테스터의 개인적인 벤치 마크 중 하나 여야하지만 대부분의 테스터는 유효한 결함의 수가 가장 많음을 강조해야합니다.
이것이 어떻게 달성됩니까?
다양한 테스트 시나리오를 계획하고 광고 항목을 철저히 이해하는 것과 같은 다른 측면 외에도 테스트 베드 또는 테스트 환경 설정에 많은 시간을 투자해야합니다. . 둘째, 테스트 케이스 계획을위한 예상 금액이 있음에도 불구하고 테스터는 에너지를 집중하다 효과적인 테스트 데이터 생성 .
개인적으로 감사 프로세스의 일부이기 때문에 올바른 방식으로 테스트 베드 또는 테스트 환경을 만드는 데 많은 노력을 기울이고 테스터가 철저한 작업을 수행 할 때 유효한 결함이 가장 많이 발견되는 것을 확인했습니다. 필요한 환경의 종류에 대한 이해.
또한 테스트 환경에 제공되는 테스트 데이터의 종류는 테스트중인 코드 / 기능에 매우 심각한 결함을 노출시켜 제품의 품질에 심각한 영향을 미칠 수 있습니다.
이 기사에서는 테스트 베드가 정확히 무엇을 수반하는지에 대해 설명합니다. 테스트 환경 설정 및 테스트 데이터 설정의 두 단계 프로세스입니다.
1 부) 이 기사의 앞부분에서는 테스트 환경 설정의 일반적인 프로세스 , 이러한 문제 대신 테스트 베드를 만드는 동안 염두에 두어야 할 테스트 및 포인터가 직면하는 가장 일반적으로 직면하는 설정 문제입니다.
2 부) 이 기사에서 테스트 베드와 관련하여 많은 것을 말 했으므로 테스트 환경 유지 관리 측면도 있습니다. 기사의 후반부에서는 테스트 데이터와 관련된 테스트 베드 설정의 두 번째 부분에 대해 설명합니다. 테스트 데이터 관리 기술 .
소프트웨어 개발 및 테스트의 지속적인 '빅뱅'으로 인해 전반적인 품질 보증 프로세스를 투명하고 효율적이며 적절하게 만들기 위해 다양한 방법론을 채택하는 데 점점 더 많은 초점이 맞춰지고 있습니다.
테스트 팀의 성과가 적절하게 평가 될 수 있고 테스트주기의 초기화에서 식별 된 메트릭으로 측정 가능한 결과가 있는지 확인하기 위해 조직 전체에서 다양한 품질 감사가 수행됩니다. 이러한 결과를 통해 테스트하는 소프트웨어의 최적 품질을 보장하는 측면에서 특정 팀이 어디에 있는지 식별 할 수 있습니다.
이 보고서는 또한 팀이 감사 중에 이루어진 관찰을 기반으로 개선 기회를 이해하는 데 도움이됩니다.
말할 필요도없이 모든 테스트 팀에 대한 매우 명확한 메트릭은 열린 총 결함 수와 유효한 결함 수 . 따라서 당연히 떠오르는 질문 중 하나는 – 결함을 발견하기위한 기초가 무엇입니까? 달리 말하면, 결함을 찾을 수있는 기반은 무엇입니까?
대답은 만장일치입니다 – 테스트 베드 및 / 또는 테스트 환경 설정. 팀 내에서 설정된 품질 벤치 마크가 있습니다. 거부되는 결함을 줄입니다. 테스트 설정 오류 / 사용자 오류, 잘못된 구성 또는 일부 경우 사용할 수없는 구성, 테스트되지 않은 구성으로 인해 특정 팀에서 탈출하여 발생하는 결함.
먼저 테스트 베드 또는 테스트 환경이 무엇인지 정의하는 것을 자세히 살펴 보겠습니다.
학습 내용 :
테스트 베드 및 테스트 환경이란 무엇입니까?
매우 일반적인 의미에서 테스트 베드는 코드 또는 모듈 구현자가 테스트 팀의 방해없이 모듈을 테스트 할 수있는 일종의 개발 환경으로 정의 될 수 있습니다.
그러나 테스트 베드는 개발 팀에만 국한된 것이 아닙니다. 테스트 팀 또는 테스터의 관점에서 테스트 베드는 소프트웨어 / 제품 테스트를 위해 식별 된 플랫폼 일 뿐이므로 테스트 환경이라고도합니다.
모든 테스트 베드 또는 테스트 환경은 테스트중인 애플리케이션 / 제품 / 소프트웨어에 대해 확인 된 테스트 목표를 충족하도록 구성되어야합니다. 특정 상황에서 테스트 베드는 테스트 환경과 함께 작동하는 테스트 데이터의 조합이됩니다.
테스트 환경의 구성 요소
모든 테스트에는 특정 테스트 환경 요구 사항이 있지만 매우 넓은 의미에서 모든 테스트 베드 / 테스트 환경은 하드웨어, 소프트웨어 및 네트워킹 부분으로 구성되어 특정 테스트를 수행하고 수행하는 데 필요한 최소한의 구성을 지원합니다. .
테스터의 합리적인 시간이 환경 문제로 인해 소비되고 결과적으로 생산성과 테스트 일정에 영향을 미친다는 것은 잘 알려진 사실입니다. 문제의 종류는 각 테스트 팀마다 다르지만 일부는 공통적 일 수 있습니다.
일반적으로 직면하는 몇 가지 주요 과제는 다음과 같습니다.
# 1) 원격 환경
테스트 자산 또는 환경은 대부분 지리적으로 팀에서 멀리 떨어진 사이트에 배치됩니다. 이것은 하드웨어, 펌웨어, 소프트웨어, 네트워킹 등과 관련하여 발생할 수있는 문제의 경우와 같이 테스트 팀이 가장 일반적으로 직면하는 과제 중 하나입니다.
자산을 소비하는 팀은 자산이있는 위치의 지원 팀에 크게 의존해야합니다.
동일한 라인에서 일부 자산에 펌웨어 업그레이드 또는 빌드 업그레이드가 필요한 경우 다시 테스트 팀은 지원 티켓을 열어 환경을 소유 한 지원 팀의 지원이 필요할 수 있습니다. 이로 인해 특히 시간대가 다른 경우 상당한 테스트 시간과 지연 일정이 발생할 수 있습니다.
# 2) 팀 간 결합 사용
대부분의 경우 개발 및 테스트 팀은 동일한 환경 자산을 사용합니다. 일반적인 표준은 개발, 테스트 및 프로덕션 환경이 분리되어야한다고 정의하지만 실제로이 이상적인 시나리오는 거의 달성되지 않습니다. 조직이 각 팀에 대해 별도의 리소스를 조달하는 것은 매우 비용이 많이 듭니다.
따라서 대부분의 조직은 개발과 테스트 사이에 환경의 일반적인 사용을 요구합니다. 여기에 추가로 개발 및 테스트 리소스가 동일한 자산을 동시에 사용하기 위해 경쟁하면 구성원 내에서 혼란과 불일치로 이어집니다.
# 3) 통합을위한 자원 사용에 대한 비효율적 인 계획
필요한 시나리오의 경우 종단 간 테스트 두 개 이상의 구성 요소가 함께 작동하도록 통합해야하며, 테스트 팀간에 리소스를 공통적으로 사용해야하는 요구 사항이있을 수 있습니다. 사용과 관련하여 비효율적 인 계획은 팀 간의 갈등 외에도 환경이 불안정 해지는 데 크게 기여합니다.
이것의 가장 분명한 효과는 특정 한두 번 발견 된 문제가 동일한 시나리오에 대한 다음 실행에서 완전히 다른 동작을 생성 할 수 있다는 것입니다. 이에 대한 결함이 이미 열려있는 경우 개발에서 수정을위한 유효한 후보로 받아 들여지지 않을 가능성이 높습니다.
# 4) 복잡한 테스트 구성
테스트 베드 또는 테스트 환경 구성이 때때로 너무 복잡합니다. 이는 테스트 팀이 필요한 구성을 이해하는 데 필요한 기술을 필요로하기 때문에 몇 가지 문제를 야기합니다. 테스터가 필요한 구성을 제시 할 수있는 지식 기반이 부족한 경우가 있습니다.
이러한 경우 테스터는 테스트 베드를 잘못 구성하여 스스로 오류를 유발할 수 있습니다. 이것은 테스트 케이스와 생성되는 결과에 큰 영향을 미칩니다.
# 5) 정교한 설정 시간
다른 경우에는 각 테스트 케이스에 대해 식별 된 각 테스트 케이스에 대해 테스트 설정이 너무 정교 할 수 있습니다. 이는 함께 결합해야하는 다양한 공존 기술 또는 통합 테스트의 경우 함께 작동하기 위해 여러 구성 요소가 있기 때문일 수 있습니다.
이러한 경우 하나의 구성 요소가 다음 구성 요소에 대한 입력을 형성 할 수 있으므로 각 구성 요소는 일관된 결과를 보장하기 위해 완벽하게 작동해야합니다.
테스트 환경 설정을위한 모범 사례
테스트 실행을 시작하기 전이나 시작하는 동안 테스터가 직면 한 문제의 광범위한 개요를 살펴 보았습니다. 우리 대부분은 프로젝트 이정표 중 어느 시점에서 이러한 문제 중 하나 이상에 직면했습니다. 이상주의적인 상황이 존재하지 않기 때문에 이러한 도전은 존재했으며 다양한 수준으로 계속 존재할 것입니다.
설정 문제는 테스터 작업의 일부이며 필연적이므로 테스트를 위해 설정을 효과적으로 준비하는 방법에 대한 몇 가지 제안 사항이 있습니다. 이렇게하면 설정 문제로 인해 발생할 수있는 결함을 최소화하는 데 도움이 될 수 있습니다.
팁 # 1) 이해 철저한 테스트 요구 사항 자신을 교육하십시오
Windows 10을위한 최고의 무료 최적화 프로그램
항상 기본과 가장 분명한 것부터 시작하십시오! 개발 팀에서 사양 문서 또는 사용 사례 문서를 배포 할 때 테스트 팀의 변하지 않는 단계는 개별 항목 요구 사항을 이해 한 다음 테스트 사례를 자세히 설명하는 테스트 사례 문서를 준비하는 것입니다.
테스트 계획이 수행되는 동안 최고 테스트 케이스 문서에 자세한 테스트 환경 정보를 포함하도록 연습합니다. 테스터가 어떤 테스트 환경이 필요할 수 있고 그에 따라 필요한 구성을 분석하는 데 시간을 할애 할 것이라는 사실을 추측 할 수 없습니다.
이는 좋은 지식 기반을 구축하기 위해 개발 팀 / 아키텍트와 대화함으로써 달성 할 수 있습니다. 이렇게하면 실행주기의 시간을 절약 할 수있을뿐만 아니라 테스터가 간단한 테스트와 복잡한 테스트간에 실행 시간을 효과적으로 할당하는 데 도움이됩니다.
개인적으로, 이것의 좋은 결과는 우리 중 많은 사람들이주기의 맨 처음에 설정 문제 (본질적으로 일관된 테스트 실행을 방해 할 수 있음)를 발견했기 때문에 이러한 문제를 해결하는 데 필요한 도움을 채널 화하고 획득 할 시간이되었습니다. 허용되지 않는 기간을 초과하여 테스트주기를 연장하지 않습니다.
이로 인한 또 다른 긍정적 인 영향은 테스트 팀의 지식을 크게 향상시키고 불필요한 결함을 방지 할 수 있다는 것입니다. 이 방법에는 위에서 언급 한 테스트 설정 문제를 해결하는 데 본질적으로 필요한 거의 모든 방법이 요약되어 있지만 다른 팁에 대해 언급 할 가치가 있습니다.
팁 # 2) 연결 확인
또 다른 가장 중요한 체크 포인트는 테스트에 사용하려는 리소스 또는 자산에 도달 할 수 있는지 확인하는 것입니다. 시스템을 다른 시스템과 통합하여 실행해야하는 경우 ping 또는 telnet을 사용하여 서로 연결을 확인하십시오.
또한 시스템이 서로 상호 작용해야하고 방화벽 뒤에있는 경우 BSO (기본 보안 옵션)를 사용하여 이러한 방화벽을 통해 인증 할 수 있는지 확인하고 프록시도 확인하십시오. 일부 시스템에 연결할 수 없거나 BSO 인증이 필요한 경우 지원 팀에 대한 요구 사항을 충족하기 위해 적절한 서비스 요청을 제기 할 수 있습니다.
이는 환경이 원격 위치에있을 때 특히 유용하며 머신 및 시스템과 관련된 에스컬레이션을 방지합니다. 테스트 팀이 리소스 나 리포지토리에 액세스해야하는 경우이를 사전에 확인하는 데 도움이됩니다.
팁 # 3)네트워크 및 / 또는 저장소 확인
이것은 이전 팁의 거의 확장이며 더 큰 기술적 깊이로 더 많은 검사가 필요합니다. 필요한 테스트에 필요한 대역폭이 있고 테스트에 인터넷 연결이 필요한지 확인하십시오. 또한 시스템과 리소스 간의 네트워크 토폴로지가 올바른지 확인하는 방법을 찾아야합니다.
둘째, 테스트 목표가 스토리지의 필요성을 의미하는 경우 스토리지 및 네트워크 연결이 있는지 확인하십시오. 대부분의 경우이를 적용하는 것은 관리자의 책임이지만 동일한 작업 및 기능적 지식을 보유하는 것도 큰 부가가치입니다.
팁 # 4) 필요한 하드웨어 및 소프트웨어, 라이센스 확인
테스터가 필요한 하드웨어 및 소프트웨어를 확인하지 않고 시스템에서 실행을 시작하는 경우가 많습니다. 이러한 여러 번의 결과로 테스터는 테스트주기 동안 거의 특정 기능이 더 높은 수준의 하드웨어 또는 소프트웨어 / 펌웨어에서만 사용 가능하다는 것을 알게됩니다.
이때 테스터는 상당한 테스트 시간을 소모하는 테스트 노력에서 차단기를 표시합니다. 따라서 이전에 필요한 하드웨어와 소프트웨어를 기록 할 체크 포인트를 갖는 것은 귀중한 관행입니다.
하드웨어 / 소프트웨어 업그레이드와 관련된 다운 타임이 여러 번있을 수 있습니다. 팁 1 테스터가 하드웨어와 관련된 사전 계획에 참여해야하는 경우. 일부 소프트웨어에는 법률 팀의 승인 및 조치가 필요할 수있는 라이선스가 필요할 수 있습니다. 이것은 프로세스 중심의 조치이므로 다시 수행하는 데 며칠이 걸릴 수 있으며 계획해야합니다.
팁 # 5)브라우저 및 버전
당신이하는 테스트는 반영해야합니다 최종 사용자가 수행 할 작업 . 그는 모든 브라우저의 최신 버전에서 특정 브라우저를 테스트 할 수 있습니다. 따라서 테스트에 사용할 다양한 종류의 브라우저를 식별하고 자체 로컬 테스트 설정에 설치해야합니다.
둘째, 테스트에 사용해야하는 브라우저 버전도 확인합니다. 낮은 버전의 브라우저로 시작하여 이전 버전과의 호환성을 보장 한 다음 최신 버전으로 업그레이드하는 것이 좋습니다.
팁 # 6)테스트 환경 사용 계획.
테스트 팀이 자체 테스트 리소스, 시스템 및 자산을 보유하는 상황이 결코 발생하지 않는다는 사실을 감안할 때 테스트 리소스를 효과적으로 사용하기위한 테스트 계획의 주요 이정표 중 하나입니다.
Mac 용 최고의 무료 DVD 리퍼
이는 두 개 이상의 구성 요소가 함께 작동하는 종단 간 시나리오 또는 테스트 설정이 너무 정교하거나 복잡하여 복제 할 수없는 상황으로 인해 둘 이상의 팀이 동일한 리소스 세트에 액세스해야 할 때 특히 필요합니다. 매우 쉽게 동일한 설정으로 테스트 자체 목표를 가진 동일한 팀 내에 여러 구성원이있을 수 있습니다.
좋은 관행은 특정 팀이나 사람이 초반에는 사용하고 나머지는 후반에는 사용하는 시간 공유 방식을 만드는 것입니다. 그들 각각이 서로를 방해하지 않는 독립적 인 테스트를 실행할 수있는 공통점이있을 수 있습니다.
이렇게하면 구성원 내부의 혼란과 갈등을 줄일뿐만 아니라 더 오랜 기간 동안 환경의 행동 안정성을 보장 할 수 있습니다.
팁 # 7)자동화 도구 및 구성
아시다시피 테스트의 모든 광고 항목에는 자동화해야하는 회귀주기의 일부가 될 몇 가지 반복 테스트가 있습니다. 테스트 팀은 수행하고자하는 자동화의 종류와 이에 필요한 도구를 식별해야합니다.
이것이 환경 준비의 일부일 필요는 없지만 자동화 도구를 적절하게 식별하고 구성하기위한 모범 사례로 나열하겠습니다. 이는 테스트 준비를 보장하기위한 필수 요소가 아니므로이 작업을 수행하려는 테스터의 재량에 따라 완전히 달라집니다.
결론
이러한 팁과 요령은 테스트 환경의 테스트 준비 상태를 보장하는 좋은 기준과 풋 프린트를 형성 할 수 있습니다. 의심 할 여지없이 각 팀은 고유 한 과제에 직면 해 있으며 위의 팁은 각자의 필요에 맞게 조정하고 사용자 지정할 수 있습니다.
사실,이 팁의 전체 뼈대를 적어두기위한 소스는 내가 심각하게 복잡한 설정 문제에 직면하고 테스트를 시작하는 데 거의 1 년이 걸린 과제 중 하나에서 나옵니다!
테스트 환경의 한계는 내 통제를 벗어 났지만, 이러한 팁을 적용하면 이러한 문제가 더 일찍보고 될 수 있다고 느꼈습니다. 나는 그 이후로 오는 모든 과제에 적용 해 왔으며이 골격은 사전에 설정 문제를 찾고 해결하기위한 노력을 집중하는 데 많은 도움이되었습니다.
저자 정보 : 이 기사는 Sneha Nadig가 작성했습니다. 그녀는 수동 및 자동화 테스트 프로젝트에서 7 년 이상의 경험을 가진 테스트 리드로 일하고 있습니다.
이 기사의 2 부에서는 테스트 환경 설정 및 유지 관리 프로세스와 테스트 데이터 준비 및 관리 팁에 대해 설명합니다. 한편, 의견에 Test Bed 준비 쿼리를 자유롭게 게시하십시오.