Summary - SW결함 분석기법, 소프트웨어 테스트의 종류, 단위테스트의 유형

 

SW결함 분석기법-결함 리포팅

테스트 중 발견된 결함은 다음과 같은 항목에 의해 저장하여 관리합니다.

항목	설명
Number (번호)	·       결함의 고유 번호이다.
Title (제목)	·       결함의 내용을 간단하게 한줄로 기록한다.
Description (설명)	·       결함에 대한 자세한 내용을 서술한다. ·       구체적으로 어떤 결함인지, 그리고 결함을 재현하는 절차와 분석 내용들을 서술한다.
Module (모듈)	·       전체 시스템 중에서 결함이 발견된 컴포넌트나 모듈명을 명시한다.
Version & Fixed Version (발견 버전과 수정 버전)	·       Version은 결함이 발견된 버전, Fixed Version은 해당 결함이 해결된 버전이다. 결함은 버전에 따라서 다르게 발생할 수 있기 때문에 반드시 이 항목이 정의되어야 한다.
Servirty, Priority (시급도와 우선순위)	·       시간적으로 빨리 처리해야 하는 경우 시급도가 높은 것을 의미하고, 결함의 우선순위는 위중도(위험도)를 의미한다. 결함의 우선순위가 높을수록 중결함이 되고, 낮을수록 경결함이 된다. 시급도가 높은 결함중 우선순위가 높은 결함을 우선적으로 처리한다. 시급도와 우선순위는 각각 5단계 정도로 나눠서 정의하는 것이 바람직하며, 일반적인 결함은 중간 단계인 3단계 정도로 하며, 시급도와 우선순위가 가장 높은 결함의 경우에는 최우선적으로 처리해야 하기 때문에 긴급하게 개발팀과 테스트 자원을 투여해야 한다.
Status (결함 처리 상태)	·       현재 결함이 처리되고 있는 상태를 기록한다.
Fixed code (코드 수정 내용)	·       결함을 수정하였을 경우에는 수정 내용을 기록해야 한다. ·       결함 내용 수정은 소스 코드 수정인 경우가 많은데, 이때는 소스 코드 수정 내용을 기록한다. ·       별도로 소스 코드 내용을 기록하는 것보다는 소스코드 관리 시스템(SCM)에 수정코드를 반영한 버전(Revision Number)을 기록해 놓으면 된다.
Attachment (첨부 파일)	·       결함을 기록할때는 첨부 파일을 사용하는데, 이 첨부 파일은 결함 발생 당시의 로그나 데이터 (CPU 사용률, 네트워크 상황), 결함을 추적하는 데 사용된 코드나 샘플, 결함이 해결되었을 경우 패치 같은 것을 첨부한다.

 

http://codedragon.tistory.com/6053

 

 

 

소프트웨어 테스트의 종류

·       화이트 박스 테스트

·       블랙 박스 테스트

http://codedragon.tistory.com/8180

 

 

 

단위테스트의 유형

http://codedragon.tistory.com/8192

 

 

 

SW결함 분석기법 - 결함 상태

항목	설명
New	·       테스트 과정에서 새로운 결함이 발견되어 결함 관리 시스템에 등록된 상태입니다.
Opened	·       등록된 결함이 개발팀에게 넘어갔을 때의 상태를 Opened라고 합니다. ·       결함이 발생한 모듈을 개발한 개발팀에게 결함이 전달된 상태로, 아직 담당자는 정해지지 않은 상태입니다.
Asigned	·       결함을 수정할 개발자에게 결함이 할당된 상태입니다.
NMI (Need More Information)	·       "추가 정보가 필요함" 상태 ·       개발팀에서 결함의 내용을 검토했을 때, 결함의 원인과 정확한 증상들을 확인할 수 없을 때, 추가적인 로그나 재현절차를 테스트 팀에 다시 요구 하는 상태입니다. ·       개발팀은 자료가 부족한 결함에 대해서 NMI 상태로 바꾼 후에, 결함을 보고한 테스트 엔지니어에게 다시 배당합니다.
In Progres	·       개발자가 결함을 확인하고, 수정 작업 중인 단계입니다.
Postponed	·       결함 처리 과정에서 결함의 중요도가 낮거나 다른 결함 수정 일정 또는 개발일정에 따라서 우선순위 조정이 필요할 때, 결함의 처리를 미뤄놓은(지연시킨) 상태입니다.
Resolved	·       결함이 해결된 상태이다. 해결은 되었으나, 개발팀 차원에서 결함이 해결된 것이고, 아직 테스트팀으로 부터 결함에 대한 재 테스트를 통한 확인을 받지 못한 상태입니다. ·       결함이 Resolved 상태로 바뀌면 개발팀은 확인테스트를 요청하기 위해서 테스트 팀에 다시 해당 결함을 Asign합니다.
Closed	·       테스트팀에 의해 결함의 수정 내용이 확인되고 제품의 소스코드에 반영된 상태로, 결함 처리의 최종 단계입니다.
Attachment (첨부 파일)	·       결함을 기록할 때는 첨부 파일을 사용합니다 ·       첨부 파일에는 결함 발생 당시의 로그나 데이터(CPU 사용률, 네트워크 상황), 결함을 추적하는데 사용된 코드나 샘플, 결함이 해결되었을 경우 패치 같은 것을 첨부합니다.

 

http://codedragon.tistory.com/6053