software test estimation techniques
프로젝트 테스트의 성공을 위해 추정 및 적절한 실행은 개발주기만큼이나 중요합니다. 고객과 좋은 평판을 얻으려면 추정치를 고수하는 것이 매우 중요합니다.
경험은 '소프트웨어 테스트 노력'을 추정하는 데 중요한 역할을합니다. 다양한 프로젝트에서 작업하면 테스트주기의 정확한 추정을 준비하는 데 도움이됩니다. 분명히 테스트 작업에 며칠을 맹목적으로 넣을 수는 없습니다. 테스트 추정은 현실적이고 정확해야합니다.
이 기사에서는 정확한 테스트 추정을 준비하는 데 도움이되는 매우 간단한 방법으로 몇 가지 요점을 입력하려고합니다.
학습 내용 :
테스트 추정 프로세스에 대한 간략한 설명
'추정은 입력 데이터가 불완전하거나 불확실하거나 불안정한 경우에도 어떤 목적으로 사용할 수있는 값인 추정 또는 근사치를 찾는 프로세스입니다.' (참고: 위키 백과 )
우리 모두는 전문가로서 일생 동안 서로 다른 작업과 의무와 마감일을 마주하게되며, 이제 문제에 대한 해결책을 찾는 두 가지 접근 방식이 있습니다.
첫 번째 접근 방식은 문제가 도착한 후에 만 당면한 문제에 대한 해결책을 찾으려고하는 사후 접근 방식입니다.
Proactive Approach라고 할 수있는 두 번째 접근법에서 문제가 우리의 과거 경험과 함께 도착하기 훨씬 전에, 그리고 우리의 과거 경험을 통해 우리는 도전에 대한 해결책을 찾으려고 노력합니다.
따라서 추정은 문제에 대한 사전 접근 방식을 취할 때 적용되는 기술로 간주 될 수 있습니다.
따라서 추정을 사용하여 정의 된 작업을 완료하는 데 필요한 시간 및 비용의 노력을 예측할 수 있습니다.
테스트 팀이 당면한 문제를 추정 할 수있게되면 당면한 문제에 최적 인 솔루션을 쉽게 찾을 수 있습니다.
추정의 관행은 작업의 예상 비용에 대한 대략적인 계산으로보다 공식적으로 정의 될 수 있습니다.
깊이 우선 검색 C ++
또한 읽기=> 셀레늄 자동화 프로젝트의 테스트 추정에 영향을 미치는 7 가지 요소
테스트 추정 프로세스의 기본 전제 조건
# 1) 과거 경험으로 작업하여 얻은 통찰력 : 현재의 노력과 유사한 도전을 제기 한 과거 프로젝트를 회상하면서 시간을 보내는 것은 항상 좋은 습관입니다.
# 2) 사용 가능한 문서 또는 아티팩트 : 그만큼 테스트 관리 저장소 도구가 제공됩니다. 요구 사항 및 설명 문서를 저장하므로 이러한 유형의 시나리오에서 편리합니다. 이러한 문서는 프로젝트의 범위를 명확하게 정의하기 위해 테스트 팀에서 참조 할 수 있습니다.
# 3) 작업 유형에 대한 가정 : 과거의 업무 경험은 프로젝트에 대한 가정을하는 데 도움이됩니다. 경험 많은 전문가를 고용하는 것이 가장 중요합니다.
테스트 관리자는 원하는 결과를 제공하기 위해 이러한 사람들의 두뇌를 선택할 수 있습니다.
# 4) 잠재적 인 위험 및 위협 계산 : 테스트 팀은 또한 미래에 팀에 속할 수있는 잠재적 인 위험과 위협 및 함정을 시각화해야합니다.
# 5) 문서의 기준선이 설정되었는지 확인 : 테스트 팀은 또한 요구 사항이 기준이되었는지 여부를 결정해야합니다. 문서의베이스 라인이 지정되지 않은 경우 변경 빈도를 결정하는 것이 중요합니다.
# 6) 모든 책임과 종속성이 명확해야합니다. 조직은 평가 프로세스를 수행 할 모든 사람의 역할과 책임을 명확하게 정의해야합니다.
# 7) 추정 기록의 문서화 및 추적 : 추정 프로세스와 관련된 모든 정보를 문서화해야합니다.
# 8) 테스트 추정 과정에서 수행해야하는 활동
- 견적을 수행 할 팀 구성
- 프로젝트를 프로젝트 단계 및 후속 구성 활동으로 분해
- 이전 프로젝트 및 전문적인 경험을 기반으로 추정치를 계산합니다.
- 가능한 위협의 우선 순위를 정하고 이러한 위험을 완화하기위한 접근 방식을 마련합니다.
- 작업의 관련 부분 검토 및 문서화
- 관련 이해 관계자에게 작품 제출
가장 눈에 띄는 테스트 추정 기법
테스트 추정을위한 가장 중요한 기술은 다음과 같습니다.
- 테스트 포인트 추정
- 작업 단계 기반 추정
- 사용 사례 포인트 추정
이러한 기술을 사용하는 방법과 장소 :
# 1) 테스트 포인트 추정 소프트웨어 테스트 스펙트럼에서 널리 사용되는 간단하고 이해하기 쉬운 추정 기술입니다. 반복 단계와 단순성은이 특정 기술의 가장 중요한 기능입니다.
# 2) 작업 단계 기반 추정 특정 단계 (일반적으로 가장 짧고 가장 간단한 단계)에 대해 추측 추정을 한 다음 테스트 팀이 초기 추정에 다른 단계를 점진적으로 추가하고 마지막으로 적절한 추정을내는 데 사용되는 추정 기법입니다.
# 3) Use-Case Point 추정 기법 조정되지 않은 액터 가중치 및 조정되지 않은 사용 사례 가중치를 사용하여 소프트웨어 테스트 추정치를 결정하는 사용 사례에 대한 추정치입니다.
테스트 포인트 추정 기법의 세부 사항
테스트 포인트 추정 기술은 나열된 단계에 따라 수행됩니다.
(프로젝트마다 다를 수있는 다음 가중치는이 패러다임에서 고려할 수 있습니다. 이러한 가중치 중 일부는 코드의 복잡성에 기반한 프로그래밍 언어의 가중치, 애플리케이션 유형에 따른 애플리케이션 가중치 및 테스트 가중치입니다. 소프트웨어 테스트의 여러 단계에 따라 할당됩니다.)
처리되지 않은 테스트 포인트에 CWF를 곱하여 테스트 포인트의 크기에서 테스트 크기를 얻습니다.
생산성 계수는 테스트 엔지니어가 하나의 테스트 포인트에 대한 테스트를 완료하는 데 걸리는 시간을 나타냅니다.
사람 시간의 테스트 노력은 테스트 포인트 크기에 생산성 요소를 곱하여 계산됩니다.
테스트 포인트 추정 기법의 계산을 위해 다음 변수를 고려합니다.
- 테스트 요구 사항 복잡성
- 다른 요구 사항과의 인터페이스
- 총 검증 포인트 수
- 기준 테스트 데이터
그런 다음 각 데이터 변수에 대한 가중치 벡터를 고려하고 다음과 같은 방식으로 구성해야합니다.
조정 계수 = 평균 (복잡도 가중치 및 계수 가중치의 곱) / 30
테스트 케이스 설계에 대한 조정 테스트 포인트 = 총 테스트 포인트 X (1 + 테스트 케이스 설계에 대한 조정 계수)
테스트 케이스 실행을위한 조정 된 테스트 포인트 = 총 테스트 포인트 X (1 + 테스트 케이스 실행을위한 조정 계수)
총 테스트 포인트 (정규화) X (1 + 테스트 케이스 설계 / 실행을위한 조정 계수) = 테스트 케이스 설계 / 실행을위한 조정 된 테스트 포인트
총 작업 시간 (PH) = 정규화 된 테스트 포인트 수 / 생산성 (인간 시간당 정규화 된 테스트 포인트)
테스트 추정 예
위의 공식을 다른 실제 용도에 적용 해 보겠습니다.
테스트 할 5 개의 테스트 시나리오가있는 테스트 요구 사항이 있다고 가정합니다.
이제 테스트 시나리오 1에 5 개의 예상 테스트 결과, 테스트 시나리오 2 6 개의 테스트 예상 결과, 테스트 시나리오 3에는 2 개의 테스트 예상 결과, 테스트 시나리오 4 9 개의 테스트 예상 결과, 테스트 시나리오 5에는 9 개의 테스트 예상 결과가 각각 있다고 가정 해 보겠습니다.
따라서 테스트 시나리오를 세 가지 클래스 즉,이 세 가지 클래스에 존재하는 예상 결과의 총 수를 기반으로 복잡, 단순 및 보통으로 분류합니다.
복잡한 클래스는 7 개 이상의 예상 결과를 가지지 만 단순한 클래스는 5 개 미만의 예상 결과로 구성되고 중간 시나리오는 4 ~ 7 개의 예상 결과로 구성됩니다.
따라서 테스트 시나리오 1과 테스트 시나리오 2를 중간 시나리오로, 시나리오 5와 시나리오 6을 복잡한 시나리오로, 테스트 시나리오 3을 단순하게 분류합니다.
이제 이러한 모든 시나리오에 테스트 포인트를 적용합니다. 복잡한 클래스에는 5 개의 테스트 포인트를 적용하고, 중간 클래스에는 3 개, 간단한 시나리오에는 2 개를 적용합니다.
이러한 모든 테스트 시나리오에서 가정 된 테스트 포인트에 예상 결과의 총 수를 곱합니다. 그래서 우리는 다음과 같은 근사치로 끝납니다.
시나리오 1 : 3 개의 테스트 포인트 * 5 개의 테스트 예상 결과 = 조정 된 테스트 포인트 = 25
시나리오 2 : 3 개의 테스트 포인트 * 6 개의 테스트 예상 결과 = 조정 된 테스트 포인트 = 30
시나리오 3 : 2 개의 테스트 포인트 * 2 개의 테스트 예상 결과 = 조정 된 테스트 포인트 = 4
시나리오 4 : 5 개의 테스트 포인트 * 9 개의 테스트 예상 결과 = 조정 된 테스트 포인트 = 45
시나리오 5 : 5 개의 테스트 포인트 * 9 개의 테스트 예상 결과 = 조정 된 테스트 포인트 = 45
따라서 조정 된 각 테스트 포인트에 대해 5 인 시간을 신청해야한다는 점을 고려하면 다음과 같은 대략적인 결과를 얻게됩니다.
테스트 시나리오 1 : 조정 된 테스트 포인트 25 개 * 5 인 시간 = 125 인 시간
테스트 시나리오 2 : 조정 된 테스트 포인트 30 개 * 5 인 시간 = 150 인 시간
테스트 시나리오 3 : 조정 된 테스트 포인트 4 개 * 5 인 시간 = 20 인 시간
테스트 시나리오 4 : 45 개의 조정 된 테스트 포인트 * 5 인 시간 = 225 인 시간
테스트 시나리오 5 : 45 개의 조정 된 테스트 포인트 * 5 인 시간 = 225 인 시간
따라서 총 대략적인 사람 시간은 다음과 같습니다. 745 사람 시간
사용 사례 포인트 추정 방법
사용 사례 포인트 방법은 사용 사례 또는 요구 사항을 기반으로 전체 테스트 추정 노력을 계산하는 사용 사례를 기반으로합니다.
사용 사례 포인트 추정 방법의 세부 프로세스는 다음과 같습니다.
동일한 예는 특정 요구 사항에서 각각 5 개의 사용 사례, 사용 사례 1, 사용 사례 2,…, 사용 사례 5가 있다고 말하는 것입니다. 이제 사용 사례 1은 6 명의 행위자로 구성되고 사용 사례 2는 15 명의 행위자로 구성되며 사용 사례 3, 4, 5, 3, 4, 5 명의 행위자로 구성됩니다.
총 액터 수가 5 명 미만인 유스 케이스는 음수로, 총 액터 수가 5 명 이상 10 명 이하인 유스 케이스는 긍정적으로, 10 명 이상의 배우가 예외입니다.
우리는 예외적 인 사용 사례에 2 점, 긍정적 인 경우에 1 점, 부정적인 경우에 -1 점을 할당하기로 결정했습니다.
따라서 위에서 언급 한 가정을 기반으로 사용 사례 1과 5를 각각 긍정적으로, 사용 사례 2를 예외로, 사용 사례 3, 4를 부정적으로 분류합니다.
따라서 처리되지 않은 액터 가중치 = 사용 사례 1 = (총 액터 수) 5 * 1 (할당 된 포인트) = 5
사용 사례 2 = 15 * 2 = 30.
나머지 사용 사례에 대해 프로세스를 반복하면 처리되지 않은 액터 가중치 = 33이 수신됩니다.
처리되지 않은 사용 사례 가중치 = 총 개수 사용 사례 수 = 5
처리되지 않은 사용 사례 포인트 = 조정되지 않은 액터 가중치 + 조정되지 않은 사용 사례 가중치 = 33 + 5 = 38
처리 된 사용 사례 포인트 = 38 * (0.65+ (0.01 * 50) = 약 26.7 또는 28 인 시간
작업 단계 분석 기법
작업 단계 분석 기술은 다음 단계에서 설명 할 수 있습니다.
- 전체 작업을 단계로 나눕니다.
- 가장 간단한 단계부터 시작하여 대략적인 추정값을 할당합니다.
- 그런 다음이 단계가 완료되면 시작할 수있는 다음 가능한 단계를 식별합니다.
- 이 단계에 적용 할 수있는 가능한 근사값 집합을 도출하고 파생 된 모든 근사값 중에서 최대 값을 선택합니다.
- 이미 존재하는 값에 현재 단계 노력 추정 값을 더하여 대략적인 추정 값을 합산하십시오.
- 첫 번째 단계에서 식별 된 모든 단계가 소진 될 때까지 3 ~ 5 단계를 계속합니다.
- 최종 대략적인 추정값을 최종 값으로 받아들입니다.
요구 사항에 5 개의 필수 단계가 있다고 가정합니다. 따라서 초기 1 단계에서는 필요한 총 노력이 35 인 시간이라고 가정하고 각각 35, 45, 55 및 65라는 4 개의 비교 가정이있는 다음 2 단계를 시작합니다.
그래서 우리는 여기서 최대 값 인 65 인시를 고려합니다. 3 단계, 4 단계, 5 단계에서 각각 (12, 33, 43, 54), (15, 10, 7, 8) 및 (2, 16, 5, 13) 추정치를 얻습니다. 상기 원칙을 적용함으로써 우리는 각각 185 인의 시간으로 끝납니다.
나는 다음과 같은 정보를 제공하고 있습니다 – 테스트 작업에 대한 테스트 노력을 추정하는 방법. 경험을 통해 배웠습니다.
테스트 시간을 정확하게 예측하는 방법에 대한 9 가지 일반적인 팁
소프트웨어 테스트 추정에 영향을 미치는 요인 및 정확한 추정을위한 일반적인 팁 :
# 1) 약간의 버퍼 시간 생각
추정에는 일부 버퍼가 포함되어야합니다. 그러나 현실적이지 않은 버퍼를 추가하지 마십시오. 추정에 버퍼가 있으면 발생할 수있는 모든 지연에 대처할 수 있습니다. 버퍼가 있으면 테스트 범위를 극대화하는 데 도움이됩니다.
# 2) 버그주기 고려
테스트 추정에는 버그 주기도 포함됩니다. 실제 테스트주기는 예상보다 더 오래 걸릴 수 있습니다. 이를 방지하려면 테스트주기가 빌드의 안정성에 달려 있다는 사실을 고려해야합니다. 빌드가 안정적이지 않은 경우 개발자는 수정하는 데 더 많은 시간이 필요할 수 있으며 분명히 테스트주기가 자동으로 연장됩니다.
# 3) 예상 기간 동안 모든 리소스의 가용성
테스트 평가에서는 다음 몇 주 또는 다음 몇 개월 동안 팀 구성원이 계획 한 모든 휴가 (일반적으로 긴 휴가)를 고려해야합니다. 이것은 추정이 현실적임을 보장합니다.
추정은 테스트주기 동안 고정 된 수의 리소스를 고려해야합니다. 자원의 수가 감소하면 추정치를 재검토하고 그에 따라 업데이트해야합니다.
# 4) 병렬 테스트를 할 수 있습니까?
출력을 비교할 수 있도록 동일한 제품의 이전 버전이 있습니까? 그렇다면 테스트 작업을 좀 더 쉽게 할 수 있습니다. 제품 버전을 기준으로 추정치를 고려해야합니다.
# 5) 추정치가 잘못 될 수 있습니다. 따라서 추정하기 전에 초기 단계에서 자주 추정치를 재검토하십시오.
초기 단계에서는 테스트 견적을 자주 다시 확인하고 필요한 경우 수정해야합니다. 우리는 요구 사항에 큰 변화가없는 한 추정치를 동결 한 후에는 연장해서는 안됩니다.
# 6) 과거의 경험을 생각하여 판단하세요!
과거 프로젝트의 경험은 예상 시간을 준비하는 동안 중요한 역할을합니다. 우리는 과거 프로젝트에서 직면했던 모든 어려움이나 문제를 피하기 위해 노력할 수 있습니다. 이전 추정치가 어땠는지, 제품을 제 시간에 제공하는 데 얼마나 도움이되었는지 분석 할 수 있습니다.
# 7) 프로젝트 범위 고려
프로젝트의 최종 목표와 모든 최종 결과물 목록을 파악합니다. 크고 작은 프로젝트에서 고려해야 할 요소는 많이 다릅니다.
대규모 프로젝트에는 일반적으로 테스트 베드 설정, 테스트 데이터 생성, 테스트 스크립트 등이 포함됩니다. 따라서 추정은 이러한 모든 요소를 기반으로해야합니다. 소규모 프로젝트에서는 일반적으로 테스트주기에 테스트 사례 작성, 실행 및 회귀가 포함됩니다.
# 8) 부하 테스트를 수행 할 예정입니까?
성능 테스트에 상당한 시간을 투자해야하는 경우 그에 따라 예상하십시오. 부하 테스트를 포함하는 프로젝트에 대한 추정은 다르게 고려해야합니다.
# 9) 당신의 팀을 알고 계십니까?
팀에서 일하는 개인의 강점과 약점을 알고 있다면 테스트 작업을보다 정확하게 추정 할 수 있습니다. 추정하는 동안 모든 자원이 동일한 생산성 수준을 산출하지 못할 수 있다는 사실을 고려해야합니다. 어떤 사람들은 다른 사람들에 비해 더 빨리 실행할 수 있습니다. 이것이 주요 요인은 아니지만 결과물의 총 지연을 더합니다.
결론
소프트웨어 테스트 추정은 숙련 된 전문가의 참여뿐만 아니라 테스트 사례 포인트 및 사례 포인트 방법 사용과 같은 업계 전반의 모범 사례를 도입해야하는 관행입니다.
필요한 프로세스를 사용자 정의하기 위해 열린 마음을 채택하는 것도 중요합니다. 이러한 프로세스의 성공적인 구현은 테스트 프로세스의 전반적인 개선으로 이어집니다.
저자“N. Sandhya Rani”.