Embedded Files
약어 정리
SRET
Software Reliability Engineered Testing
Introduction
시험(Test)는 제품 품질 평가, 향상 및 결함/문제 식별을 위해 수행하는 활동.
시험의 구성은 유한(Finite) 개의 테스트케이스을 기반으로 프로그램 행동에 대한 동적(Dynamic) 검증(verification)을 통해 이루어지며, 테스트케이스는 기대되는(Expected) 행동에 대한 무한 실행 영역(infinite executions domain)에서 알맞게 선택(select)됨. 여기서굵은 글씨는 시험의 핵심 특성을 나타냄.
동적(Dynamic) : 시험은 언제나 입력 값에 대한 실행임을 암시. 이에 대비되는 것은 S/W 품질 KA에 기술된 정적(static)기술
유한(Finite) : 단순한 프로그램에서 조차도 이론적으로는 매우 많은 테스트케이스를 만들 수 있어, 극단적으로 하자면시험에 수개월 또는 수년을 소비할 수도. 따라서 시험은 언제나 제한된 자원과 일정, 무제한 시험 요구사항 간의 trade-off가 있어야.
선택(Selected) : 시험집합(test set)을 어떻게 선택하느냐에 따라서 테스트 기술이 나뉘기에, 선택 기준(criteria)을 식별하는 것이 핵심. 가장 적절한 선택 기준 설정이란 복잡한 문제로서, 실전에서는 이를 위해 위험 분석 기술과 시험 공학 기술(test engineering expertise)를 적용함.
기대(Expected) : 프로그램 실행 결과에 대한 수용 가능 여부를 판단할 수 있어야. 사용자의 기대(확인을 위한 시험; testing for validation) 또는 명세(검증을 위한 시험; testing for verification), 암시적 요구사항에 기반한 예상된 행동에 비추어 검사되어야 함. S/W 요구사항 KA의 6.4. 인수 테스트와 연계
시험의 목적은 더 이상 단순히 코딩 후 결함 검출(detecting failure)에 머무르지 않고, 개발/유지보수 전 영역에 걸친 제품 구현의 일부로 인지됨. 실제로 시험 계획 및 설계 활동은 S/W 설계자의 잠재적 약점(설계에서의 간과, 모순, 누락 등)을 보완하는데 유용.
품질에 대한 고려는 위험/문제 예방의 한 방법임(문제의 수정보다는 회피가 더 났다는 점에 기반하여)에 비추어 볼 때, 시험은 해당 예방의 유효성 확인을 위한 수단임. 전 영역에 걸친 시험의 성공에도 불구하고 S/W는 장애(fault)를 가질 수 있는데, 배포 이후 발생된S/W 결함에 대한 해결은 유지보수 활동을 통해 해결함.
S/W 품질 관리 기술은 정적 기법(비 코드 실행)과 동적 기법(코드 실행)으로 나뉘며, 시험은 동적 기법에 중점을 둠(S/W 품질 KA의3.3. S/W 품질 관리 기법 참조).
S/W 시험은 S/W 작성 KA(3.4. 작성 시험 참조)과도 연계되어, 단위 및 통합 시험은 특히나 그러함.
Breakdown of topic
1. S/W 시험 기본(Software Testing Fundamentals)
1.1.
1.2.
1.3.
시험 관련 용어(Testing related Terminology) - IEEE610.12-90
S/W 오류(error) : 인간이 만들어 낸 문법적/논리적 실수로 인한 부분 또는 전체적으로 부정확(incorrect)한 코드영역.
S/W 결함(Fault, Defect)이란 S/W 실패의 원인이며, S/W 실패(Failure)는 관찰된 원치 않은 결과임. 시험은 실패를 드러내는 반면, 결함은 제거 대상.
핵심 이슈(Key Issues)
시험 선택 기준 / 시험 적합 기준(또는 중지 규칙) (Test selection criteria / Test adequacy criteria)
시험 선택 기준은 적합한 테스트케이스를 결정하기 위한 수단임과 동시에, 선택된 테스트 수트가 적합한지 여부를 검사하는 데 사용(즉, 시험이 중지될 수 있는지 여부에 대한 결정)
시험 유효성 / 시험 목적(Testing effectiveness / Objectives for testing)
시험은 프로그램 실행 예에 대한 관찰임. 선택된 동일 시험은 각기 다른 목적으로 사용 가능
결함 식별을 위한 시험(Testing for defect identification)
결함 식별을 위한 시험의 성공 요소는 해당 시험이 시스템을 실패시킬 수 있는지 여부. 이는 S/W가 명세와 타설계 속성을 S/W가 준수하는지 여부를 보여주기 위한 시험과는 달라, 여기서는 실패가 나타나지 않아야 성공임.
오라클(oracle) 문제
오라클이란 프로그램이 주어진 시험에서 올바르게 동작하는지 여부를 결정하는 (인간 또는 기계적) agent로서, 통과(pass), 실패(fail)이란 용어를 사용. 다양한 종류가 있음.
시험의 이론적/실제적 한계(Theoretical and practical limitations of testing)
통과된 시험에 대한 신뢰성 수준 문제. 시험은 문제를 드러낼 뿐이지 S/W의 완전성을 증명할 수는 없음. 이는실제 S/W에 대한 완전한 시험이란 불가능하기 때문으로, 시험은 위험에 기반하여 수행되어야 하며, 따라서 위험 관리 전략의 한 방법으로도 볼 수 있음.
실행 불가능 경로 문제(The problem of infeasible paths)
어떤 입력 데이터로도 실행 불가능한 제어 흐름 경로는 경로 기반 시험, 특히 코드 기반 시험 기법에 기반한 자동적 시험에서의 주요 문제임.
시험 가능성(Testability)
S/W 시험 가능성의 뜻은 두 가지. 하나는 주어진 시험 범위 기준에 대한 시험 수행의 용이성이며, 다른 하나는시험을 통해 S/W 실패를 일으킬 가능성임.
시험과 타 활동 간 관계(Relationships of Testing to Other Activities)
S/W 시험은 정적 S/W 품질 관리 기법, 정확성(correctness)의 증명, 디버깅, 프로그래밍에 관련이 있지만 다름. S/W 품질 분석가의 관점으로 바라보는 편이 좋음.
2. 시험 수준(Test Levels)
2.1.
2.2.
시험 대상(The Target of the Test)
S/W 시험은 개발 및 유지보수 공정 전체의 각기 다른 수준에서 수행되기에 대상 역시 다양해짐(모듈, 모듈 그룹, 전체 시스템 등). 이는 세 개의 대단위 시험 단계, 즉 단위, 통합, 시스템 시험으로 개념적 구분을 이룰 수 있음.
단위 시험(unit testing; IEEE1008-87) : 분리하여 시험 가능한 S/W 조각의 기능을 확인하는 활동. 이는 각각의 부 프로그램 또는 강결합된 단위로 묶인 더 큰 컴포넌트 역시 이에 포함된다는 의미임. 본 시험은 종종 대상코드에 대해 프로그래머가 디버깅 도구를 사용하여 이룸.
통합 시험(Integration testing) : S/W 컴포넌트간 상호작용을 확인하는 과정. 고전적 통합 시험 전략인 상/하향식 전략은 전통적 계층 구조의 S/W에 적용하는 반면, 현대적 시스템 통합 전략은 아키텍처 주도(Architecture-driven) 방식으로서, 식별된 기능적 분류(functional threads)에 따라 S/W 컴포넌트 또는 부시스템을 통합하는 방식임.
통합 시험은 연속적 활동으로서, 각 단계에서 S/W 기술자는 하위(lower-level)가 아닌 현재 통합하는 수준에 눈높이를 맞춤. 작은 S/W가 아니라면, '빅뱅' 전략보다는 체계적/점증적 통합 시험이 많이 쓰임
시스템 시험(System testing) : 시스템 시험은 전체 시스템의 행동에 관계하여, 주요 기능적 실패는 단위 및통합 시험에서 이미 식별되어야 함. 본 시험은 주로 보안, 속도, 정확성, 신뢰성 등의 비기능적 요구사항 준수여부와 외부 모듈(운용 환경, 타 응용프로그램 등)과의 연동을 위한 외부 인터페이스에 대한 검사에 초점을 둠.
시험 목적(Objectives of Testing)
시험은 다양한 목적을 갖고 수행되며, 목적이 정확성을 요구할 경우 정량적 수단을 통해 이룸.시험은 여러 속성을 검증(verify)하는 데 목적을 둠. 기능 요구사항의 구현 정확성 검사(conformance/correctness/functional test)를 위해 테스트케이스가 설계되기도 하지만, 비기능 요구사항(성능, 신뢰성, 사용성 등)의 속성 역시 검사 대상임. 시험 목적은 시험 대상에 따라 달라짐.
인수(Acceptance)/자격(qualification) 시험
인수 시험은 고객의 요구사항에 시스템이 부합하는지를 검사. 고객이 본 시험에 해당하는 특정 작업을 지정/수행할 수도. 시험 활동에는 개발자가 결부될 수도 있음.
설치(installation) 시험
보통 인수 시험이 완료된 후 수행되어 대상 환경으로의 설치에 대한 검증(verify)임. H/W 형상 요구사항에 따라 시스템 시험이 한번 더 수행되는 것으로 볼 수도 있어. 설치 절차 역시 검증 대상.
알파(alpha) / 베타(beta) 시험
S/W를 풀기(release) 전에 소규모의 잠재적 사용자 대표 집단에 트라이얼(trial)로 사용케 하는 것으로, 해당사용자가 내부(in-house) 멤버일 경우 알파, 외부일 경우에는 베타 시험임. 이들 사용자는 사용 후 문제를 보고함. 본 시험은 종종 통제 밖으로 벋어나 시험 계획에 반드시 포함되지는 않음
부합(conformance) / 기능(Functional) / 정확성(Correctness) 시험
S/W가 자신의 명세에 맞게 동작하는지 여부를 검증하는데 목적을 둠.
신뢰도 성취 및 평가(Reliability achievement and evaluation)
결함을 식별하는 수단으로서 시험은 신뢰도 향상을 위한 한 수단임. 반면, 운영 프로파일(operational profile),신뢰도에 대한 통계적 측정기준을 따라 무작위로 생성한 테스트케이스를 도출할 수도. 신뢰도 증대 모델을통해 위 두 목적을 동시에 성취 가능함(4.1.4. 생명 시험(Life test), 신뢰도 평가 절 참조)
회귀(regression) 시험
수정이 의도하지 않은 영향을 미치는지 여부를 검증하기 위한 시스템 또는 컴포넌트에 대한 선택적 재시험임(IEEE10.12-90), 실제에서의 본 시험은 이전에 통과한 시험이 여전히 유효한지 여부에 대한 판단.
회귀 시험의 수준과 이에 필요한 자원 간에는 언제나 trade-off가 요구됨.
'2.1. 시험 대상'의 모든 시험 수준에서 수행될 수 있으며, 기능/비기능 요구사항 모두에 적용됨.
성능(performance) 시험
용량 및 반응 시간 등의 지정된 성능 요구사항에 부합하는지 여부에 대한 검증. 내부 프로그램 및 시스템 한계에 대한 시험인 부피 시험(volume testing; 일정량의 데이터를 갖고 성능을 시험)은 성능 시험의 일종.
스트레스(stress) 시험
S/W를 설계 부하(design load)의 최고치 또는 그 이상에서 수행
Back-to-back 시험
단일 시험집합을 단일 S/W 제품의 두 버전에 수행하여 그 결과를 비교
복구(recovery) 시험
본 시험의 목적은 재해(disaster) 이후의 S/W 재시작 능력에 대한 검증임
형상(configuration) 시험
S/W가 다양한 사용자를 위해 만들어졌을 경우, 다양한 특정 형상에서의 S/W 수행 능력을 분석함.
사용성(usability) 시험
S/W 및 해당 문서에 대해, 최종 사용자의 사용/학습이 얼마나 용이한지 여부를 평가. 또한 S/W의 기능이 사용자 작업에 대한 지원에 얼마나 유효한지 여부와 사용자의 오류에 대한 복구 능력 역시 평가 대상
시험 주도 개발(TDD; Test-driven development)
TDD 그 자체로는 시험 기법은 아니지만, 시험을 요구사항 명세 문서의 대용으로 하여 S/W가 요구사항을 정확히 구현하는지 여부를 검증하는 수단으로 사용.
3. 시험 기법(Test Techniques)
시험의 목적 중 하나는 잠재적 실패(failure)를 최대한 많이 발견함에 있어, 많은 기법이 이를 위해 개발됨. 이러한 기법의 기반 원칙은프로그램 행동의 대표적 집합 식별을 최대한 조직적(systematic)으로 이루는 것이나, 모든 기법을 분류할 공통된 기반은 찾기 어려움.
S/W 설계 및 코드가 어떻게 이루어졌는지에 대한 정보에 의존하는 시험을 가리켜 White-box(또는 glassbox) 시험이라 부르는 반면,입/출력 행동에 기반할 경우에는 Black-box 시험이라 칭함.
4. 시험 관련 측정기준(Test related measures)
종종 시험 기법과 목적을 혼동하는 경우가 있는데, 시험 '기법'은 시험 목적 성취를 위한 조력자임. 예를 들어 분기 커버러지는 '기법'으로, 특정 분기 커버리지 측정기준이 시험 자체의 목적으로 받아들여져서는 안됨. 명시적으로 구분되어야 할 것은 관찰된 시험 결과를기반으로 프로그램 평가를 가능케 하는 시험 관련 측정기준과, 시험 집합에 대한 완전성을 평가하는 것임. 관련 토픽은 SWE 관리KA의 부영역인 6-SWE 측정기준과 SWE 공정 KA의 부영역인 4-공정 및 제품 측정기준.
4.1.
4.2.
시험 하의 프로그램 평가(Evaluation of the Program Under Test)
시험 계획과 설계를 위한 프로그램 측정(Program measurements to aid in planning and designing testing)
프로그램 크기, 구조에 기반한 측정기준은 시험 안내를 위해 사용됨. 또한 구조적 측정기준은 프로그램 모듈간 측정기준(모듈간 호출 회수를 통한)을 포함함.
장애 유형, 분류, 통계(Fault types, classification, and statistics)
어떤 유형의 결함이 시험 중 발견되는지 및 이전에 발생했던 결함에 비한 상대적 회수를 아는 것이 중요하여,이를 통해 품질 예측 및 공정 향상(process improvement)를 이룰 수 있음. S/W 품질 KA의 3.2 결함 특성화 참조.
결함 밀도(density)
유형 기반의 결함 분류 및 회수 측정을 통해 시험 중의 프로그램을 평가할 수 있어. 각각의 결함 군에 대해, 발견된 결함 개수 및 프로그램의 크기 간 결함 밀도는 비율(ratio)로 측정됨.
생명 시험(Life test), 신뢰도 평가
신뢰도 성취 및 평가(2.2.5)를 통한 S/W 신뢰도의 통계적 측정기준은 제품 및 시험의 중지 여부에 대한 평가에사용 가능.
신뢰도 성장 모형(Reliability growth models)
신뢰도 성장 모형은 신뢰도 성취 및 평가(2.2.5)하에 관찰한 실패에 기반하여 신뢰도 예측을 가능케 함. 일반적으로 본 모형은 결함이 고쳐졌음(fix)을 가정하는데, 따라서 보통 제품의 신뢰도는 증가하는 경향을 보임. 본 모형 종류는 실패 회수(failure-count) 모형과 실패 간 시간(time-between-failure) 모형이 있음.
수행된 시험의 평가(Evaluation of the Tests Performed)
커버리지/완전도(thoroughness) 측정
여러 시험 적합성 기준은 테스트케이스가 프로그램 또는 명세에서 식별된 요소 집합을 시스템적으로 수행해야함을 요구함. 실행된 시험의 완전성을 평가하기 위해 시험자는 전체 요소에 대한 다뤄진 요소 비율을 동적으로측정함으로 다뤄진(coverage) 요소를 감시(monitor)할 수 있음. 프로그램 흐름도 내의 다뤄진 분기에 대한 비율을 측정하거나, 명세 문서에 나열된 기능 요구사항 비율에 대한 측정기준은 이에 대한 한 예. 코드 기반 적합성기준은 시험 중의 프로그램에 대한 적절한 도구(instrumentation)을 요구.
결함 뿌리기(seeding)
일부 결함은 시험 전에 인위적으로 삽입되기도. 이를 통해 시험이 수행될 때 삽입된 이들 결함 뿐 아니라 이미있었던 결함 역시 발견될 수 있음. 이론적으로 어느, 그리고 얼마나 많이 인위적 결함이 발견되었는지에 따라서, 시험 유효성이 평가되고 남겨진 순수 결함이 추정될 수 있음. 여기서 중요한 것은 결함이 분산되어 뿌려지고 대표성을 지녀야 한다는 것. 또한 결함이 후에 남겨져 위험을 유발할 수 있으므로 조심스럽게 본 기법을 사용해야 한다는 점임.
변이 점수(Mutation score)
변이 시험에서 생성된 변이에 대한 죽은 변이의 비율은 수행된 시험 집합의 효과성 측정에 이용됨.
기법간 비교 및 상대적 효과
여러 문건에서 시험 기법 간 상대적 효과성을 비교하는데, 여기서 중요한 것은 평가 속성에 대해 정확히 인식해야 한다는 것. 예를 들어 '효과성'의 정확한 의미는, 첫 실패를 발견하기까지의 수행된 시험 회수, 시험을 통해 발견된 결함 개수, 신뢰도 향상 정도 로 해석될 수 있음. 분석 및 경험적 기법 비교는 위 효과성 기준에 따라이루어짐.
5. 시험 공정
시험 개념, 전략, 기법, 측정기준은 기 정의/제어된, 인간에 의해 수행되는 공정으로 통합될 필요가 있음. 또한 시험 공정은 시험 활동을 지원하고, 시험 팀에게 시험 전 과정에 대해 비용 효과적인 목적 달성 가능하도록 안내하는 역할을 함.
5.1.
5.2.
실제적 고려사항(Practical Considerations)
태도/비이기적 프로그래밍(attitudes and egoless programming)
시험을 성공적으로 이끄는 매우 중요한 요소는 협력적 태도임. 관리자에게는 개발/유지보수 중의 실패 발견에대해 우호적인 분위기를 만들 임무가 있음. 코드에 대한 소유 개념을 갖지 않도록 하여, 그들의 코드로 인한 실패의 책임감을 느끼지 않도록 하는 것은 한 예.
시험 안내(Test guides)
다양한 목적에서 시험 공정이 안내될 수 있음. 예를 들어 위험 기반 시험의 경우, 시험 전략의 우선순위화 및집중화를 위해 제품 위험이 이용되고, 시나리오 기반 시험에서는 테스트 케이스가 특정 S/W 시나리오에 기반하여 정의됨.
시험 공정 관리(Test process management)
각기 다른 수준의 시험 활동은 생명주기의 주요 일부가 되는 잘 정의된 프로세스로 구성해야(사람, 도구, 정책,측정기준과 함께). IEEE12207에서 시험은 독립적 프로세스로 기술되지는 않지만 시험 활동에 대한 원칙은 타주요 생명주기 및 지원 프로세스에 포함됨. IEEE 1074에서 시험은 전체 생명 주기의 핵심으로서 타 평가 활동과 함께 묶임.
시험 문서화 및 작업 제품(work products)
문서화는 시험 공정 정형화의 핵심 부분으로, IEEE829-98은 시험 문서와 문서 간 또는 시험 공정 간 관계를 기술. 시험 문서는 시험 계획, 시험 설계 명세, 시험 절차(procedure) 명세, 테스트케이스 명세, 시험 로그, 시험사건 및 문제 보고를 포함. 시험 하의 S/W는 시험 항목으로서 문서화되어야 하며, SWE의 타 문서와 동일한수준의 품질로 지속적으로 갱신되어야.
내부 vs 독립적 시험 팀(Internal vs independent test team)
시험 공정의 정형화는 시험 팀 조직의 정형화를 수반함. 시험 팀은 프로젝트 팀의 내부 멤버, 외부 멤버 모두가될 수 있어. 비용, 일정, 조직의 성숙도 수준, 응용프로그램의 중대성이 (멤버 결정에 대한) 결정의 고려 요소.
비용/노력 추정 및 타 공정 측정(Cost/effort estimation and other process measures)
시험이 요구하는 자원에 관계된 여러 측정 요소 및 다양한 시험 단계(test phase)의 상대적 결함 발견 효과성이시험 공정의 제어 및 향상을 위해 사용될 수 있어. 이들 시험의 측정기준은 지정된/수행된/통과한/실패한 테스트케이스의 개수와 같은 면을 다룰 수 있어. 시험 단계 보고서 평가는 근원 분석과 결합하여 결함 발견에 대한시험 공정의 효과성을 초기에 평가할 수 있으며, 이러한 평가는 위험 분석과 연계됨 게다가 시험에 사용할만한자원은 응용프로그램의 사용/중대성과 비례하여야. 각기 다른 기법은 각기 다른 비용을 요구하고 제품 신뢰성의 각기 다른 수준을 만들어냄.
종료(Termination)
완료된 코드 커버리지나 기능적 완전성, 예상 결함 밀도, 운영 신뢰도와 같은 완전성(Thoroughness) 측정기준은 유용하기는 하지만 충분하지는 않음. 종료 결정은 잠재적 실패로 인한 비용과 위험에 대한 고려를 요구함. 1.2.1 시험 선택 기준 및 시험 적합성 기준 참조.
시험 재사용 및 시험 패턴(Test reuse and test patterns)
조직적이고 비용 효과적인 방법으로 시험 또는 유지보수를 수행하기 위해, 각종 시험 수단은 시스템적으로 재사용되어야. 이러한 시험 문건의 저장소는 S/W 형상 관리의 통제하에 있어야 S/W 요구사항/설계의 변경이 시험의 영역에 반영될 수 있음.
특정 환경 하의 특정 응용프로그램 유형을 시험하기 위한 시험 솔루션이 도입되는데, 여기에는 비슷한 프로젝트에서 재사용하기 위해 문서화를 이루는 시험 패턴을 형성.
시험 활동(Test Activities)
시험 활동에 대한 성공적 관리는 S/W 형상 관리 프로세스에 달림.
계획(Planning)
타 프로젝트 관리 측면과 마찬가지로 시험 활동 역시 계획되어야. 시험 계획의 주요 측면에는 인력 배치, 시험도구 관리, 원치 않은 결과에 대한 계획이 포함됨. 하나 이상의 S/W 기준선이 설정될 경우 주요 계획 고려 사항으로, 시험 환경이 적절한 구성을 이루는지를 검증하기 위한 시간과 노력임.
테스트케이스 생성(Test-case generation)
테스트케이스의 생성은 수행될 시험 수준 및 특정 시험 기법에 기반함. 테스트케이스는 S/W 형상 관리의 통제하에 있어야 하며 각 시험에 대한 기대 결과를 포함하여야.
시험 환경 개발(Test environment development)
시험 환경은 SWE 도구와 호환성을 이루어야. 이는 테스트케이스를 개발 및 제어할 뿐 아니라 로깅 및 기대 결과, 스크립트 및 타 시험관련 자료를 복구 가능하여야.
실행(Execution)
시험 수행에는 과학적 실험의 기본 원칙을 지켜야. 시험 중의 모든 것들은 타인이 해당 결과를 재현 가능하기에 충분하도록 수행 및 문서화되어야. 따라서 시험은 명확히 정의된 버전을 사용한 문서화된 절차에 따라 수행되어야.
시험 결과 평가(Test results evaluation)
시험 결과는 해당 시험이 성공적인지 여부를 판별할 수 있도록 평가되어야. 대부분의 경우에서 '성공적'이란S/W가 의도한 대로 수행되고 무시할 수 없는 예기지 않은 결과(major unexpected outcomes)도 보이지 않음을뜻함. 모든 예기치 않은 결과가 반드시 결함인 것은 아니어 단순 잡음으로 판명할 수도. 실패를 제거에는 격리,식별,기술을 통한 분석과 디버깅 노력이 요구됨. 시험결과가 특히 중요할 경우 정형 검토 위원회(formal review board)가 소집되어 이를 평가할 수도.
문제 보고/시험 로그(Problem reporting/Test log)
시험 활동은 시험 수행 시기, 시험 수행 주체, 시험 때의 S/W 형상 형태를 식별하기 위해 테스트 로그로 남겨질 수도. 예기지 않은/부정확한 시험 결과는 문제 보고 시스템에 기록되고, 해당 데이터는 이후 디버깅 및 문제해결을 위한 기반을 이룸. 또한 결함으로 분류되지 않은 비정상 요소(anomaly) 역시 이후를 위해 문서화될 수도. 시험 보고서는 변경 관리 요구 공정의 입력 요소임(S/W 형상 관리 KA, 3 S/W 형상 통제 참조).
결함 추적(Defect tracking)
실패를 통해 얻은 결함은 해당 S/W에 언제 발생했는지, 어떤 오류(error)가 결함을 야기했는지(미약하게 정의된 요구사항, 부정확한 변수 선언, 메모리 누수, 프로그래밍 구문 오류 등), 언제 처음 발견되었는지를 결정하기 위한 분석 소스가 됨. 결함 추적 정보는 SWE의 어떤 측면이 향상되어야 하고 얼마나 이전 분석과 시험이효과적이었는지를 결정하기 위해 사용.
Page updated
Google Sites
Report abuse