흑백 박스 결함 보고 사례

   :
                        ,                    .
                   ,         .            .                    。
   :
                         ,                   ,             ,                 ,
                        ,                 。

결함 보고
1. 수공 테스트 인원 의 주요 업무 직책
1. 테스트 계획 작성 또는 읽 기 (3 편)
2. 테스트 용례 작성 및 실행 (> 1000 개)
3. 결함 보고서 제출 (> 50 개)
4. 테스트 요약 보고서 작성 (3 편)
5. 결함 관리 도구 사용 bug
 
2. 결함 보고서 의 구성
1. 결함 번호 (defect id）
버그 제출 순서 표시
설명:
(1) 결함 관리 도 구 를 사용 하면 번호 가 자동 으로 생 성 됩 니 다.
(2) 실제 적 으로 전체 프로젝트 팀 의 통일 번호 이다.
 
2. 결함 제목 (요약)
이 bug 를 간단명료 하 게 설명 하 세 요.
 
3. 결함 발견 자 / 제출 자 (detected) by）
보통 자기
 
4. 결함 발견 날짜 (detected)  on  date）
보통 그날.
 
5. 결함 이 속 한 모듈 (subject)
어떤 기능 모듈 을 테스트 할 때 발 견 된 bug
개발 매니저 는 bug 가 있 는 모듈 에 따라 bug 의 지정 담당 자 를 찾 습 니 다.
 
6. 결함 발견 버 전 (detected)  in  release）
테스트 프로그램의 어느 버 전 을 발 견 했 는 지 버그
 
7. 누구 에 게 할당 (assigned) to）
테스트 인원 은 일반적으로 개발 매니저 에 게 파견 되 고 개발 매니저 는 bug 가 있 는 모듈 에 따라 구체 적 인 개발 자 에 게 다시 파견 된다.
8. 결함 의 상태 (status)
결함 이 이때 처 한 상황 이나 처리 상황 을 나타 낸다.
상태의 수 치 는 회사 가 사용 하 는 결함 관리 도구 에 달 려 있다.
QC 를 예 로 들 면:
(1) 테스트 인원 이 버그 를 발견 하여 결함 보고 서 를 개발 매니저 에 게 제출 하고 결함 상 태 를 new (새로 제출) 로 작성 합 니 다.
(2) 개발 매니저 가 제출 한 bug 를 검증 하고 실제 bug 라면 결함 상 태 를 open (열 린 bug, 개발 팀 이 인정 한 bug) 으로 바 꾸 고 해당 개발 자 를 파견 하여 수정 합 니 다.bug 가 아니라면 결함 상 태 를 rejected (거부 bug) 로 변경 합 니 다.
(3) 개발 자 는 자신 에 게 파 견 된 bug 를 보고 bug 수정 을 하고 결함 의 상 태 를 fixed (수 정 된 bug, 재 테스트 를 기다 리 는 bug) 로 바 꿉 니 다.
(4) 테스트 인원 이 재 테스트 를 실시 하고 재 테스트 를 통과 하면 결함 의 상 태 를 closed (닫 힌 bug, 압축 파일 의 bug, 재 테스트 를 통과 한 bug) 로 바 꿉 니 다.리 턴 에 실패 하면 결함 상 태 를 reopen (다시 열 린 bug, 리 턴 에 실패 한 bug) 으로 바 꿉 니 다.
 
상기 과정 을 '결함 (보고) 처리 절차', '결함 추적 관리 과정', '결함 의 성명 주기' 라 고 부른다.
New->open->fixed->closed
 
9. 심각 도 (severity)
이 bug 가 얼마나 나 쁘 거나 소프트웨어 에 미 치 는 영향 이 얼마나 큰 지 나타 낸다.
QC 에서:
(1) urgent: 치 명 적 인 bug, 시스템 붕괴, 다운 문제 발생
（2）very 심각 한 버그
(3) high: 심각 한 bug
(4) medium: 중간 정도 bug
(5) low: 작은 bug
 
설명:
A. 각 단어 가 서로 다른 회사 에서 나타 내 는 의 미 는 약간 다 를 수 있 습 니 다.
B. 전문 문서 에서 각 단계 의 구체 적 인 상황 을 정의 하여 개발 과 테스트 인원 이 일치 하도록 하 는 것 이 좋 습 니 다.
Bug 레벨 (레벨) 정의 (정의). xls
성능: 성능
기능: 기능
 
10. 우선 순위 (priority)
테스트 인원 은 프로그래머 가 어느 버 전에 서 혹은 언제 이 버그 를 해결 하 기 를 원 합 니까?
QC 에서:
(1) urgent: 즉시 해결, 그렇지 않 으 면 개발 / 테스트 진도 에 영향 을 줍 니 다.
（2）very 하 이 버 전
(3) 하 이: 다음 버 전 해결
(4) medium: 발표 전 해결
(5) low: 게시 에 존재 하 는 bug 허용
 
우선 순위 에 영향 을 주 는 주요 요소:
(1) bug 의 심각 성:
일반적으로 심각 도가 높 을 수록 우선 순위 가 높다.
(2) bug 의 영향 범위:
일반적인 영향 범위 가 넓 을 수록 우선 순위 가 높다.
(3) 개발 팀 의 임무 스트레스: 진도 스트레스 가 적 을 수록 우선 순위 가 높다.
(4) bug 해결 비용:
원가 가 낮 을 수록 우선 순위 가 높다.
 
주의: 심각 도와 우선 순 위 를 혼동 하지 마 세 요.
 
11. 결함 설명 (description)
bug 를 발견 한 절차, 과정, 사용 한 데 이 터 를 기록 하여 프로그래머 가 설명 을 통 해 이 bug 를 재현 할 수 있 도록 합 니 다.
//==========================================================================
등가 류 구분 법 과 경계 값 법 디자인 테스트 사례 1, 기본 개념 1, 테스트 사례 (테스트 사례, test case / instance) 를 사용 하 는 것 은 테스트 수행 전 (또는 동시에) 테스트 인원 이 작성 한 것 으로 테스트 과정 을 지도 하 는 중요 한 문서 이다. 주로 예 번호, 테스트 목적, 테스트 절차, 예상 결과 등 2. 테스트 사례 의 방법 (1) 을 포함한다.등가 류 구분 법 (2) 경계 값 법 (3) 인과 도 법 (4) 판정 표 법 (5) 양 교 배열 법 (6) 테스트 대강 법 (7) 장면 법 3. 테스트 사례 를 작성 할 때 무엇 을 참고 해 야 하 는 지 (1) 관련 문서 (수요, 개발, 사용자 매 뉴 얼) (2) 는 이미 개 발 된 프로그램 (3) 과 관계자 의 소통 2. 등가 류 구분 법 1.응용 장소 에서 데 이 터 를 입력 하 는 곳 만 있 으 면 사용 할 수 있 습 니 다. 무한 한 데이터 중에서 소수의 대 표를 선택 하여 테스트 2. 테스트 사상 궁 거 테스트 (모든 가능 한 데 이 터 를 모두 테스트) 는 가장 전면적 인 테스트 이지 만 시간 원가 가 너무 높 기 때문에 실제 적 으로 각종 테스트 사례 방법 을 사용 할 수 없습니다. 가장 적은 비용 을 사용 하려 는 것 입 니 다.(시간, 데이터) 가장 큰 테스트 효 과 를 얻 으 면 궁 거 테스트 를 하지 않 고 bug 를 빠 뜨 릴 위험 이 있 기 때문에 시간 이 허락 된다 면 적당 한 보충 3, 등가 류 구분 사상 을 수요 에 따라 무한 한 데 이 터 를 분류 하여 어떤 것 이 효과 적 이 고 (합 법 적 이 며) 어떤 것 이 무효 (불법) 인지 구분 할 수 있다. (수요 에 따라 더욱 세분 화 될 수 있다)마지막 으로 모든 데이터 범위 에서 대 표를 선택 하여 테스트 4. 핵심 개념 (1) 유효 등가 류 가 프로그램의 규격 에 대한 설명 이 합 리 적 이 고 의미 있 는 데이터 집합 (합 법 적 데이터) 프로그램 에서 유효 등가 류 데 이 터 를 받 으 면 집행 (2) 무효 등 가격 류 가 프로그램의 규격 에 대한 설명 이 합 리 적 이지 않 고 의미 없 는 데이터 집합 (불법 데이터) 을 정확하게 계산 해 야 한다.프로그램 이 무효 등가 류 데 이 터 를 받 으 면 오류 알림 을 주거 나 입력 설명 을 허용 하지 않 아야 합 니 다. 우수한 소프트웨어 기본 특징: A, 기능 이 실현 되 어야 합 니 다. 유효 등가 류 데이터 B, 이상 처리 능력 (건장 성) 을 사용 해 야 합 니 다.- 무효 등가 류 데이터 사용 5, 사용 절차: 먼저 테스트 대상 을 명 확 히 한다. 첫 번 째 숫자 텍스트 상 자 는 두 번 째 숫자 텍스트 상자 가 정확 한 (1) 분석 수 요 를 작성 하도록 확보 해 야 한다. 등가 류 구분 ① 유효 등가 류 - 99 - 99 의 정수 ② 무효 등가 류 A, B, > 99 의 정수 C, 빈 D, 비 정수 (2)등가 류 의 근 거 를 세분 화 하 는 것 은 일반적으로 글자 의 수요 가 아니 라 데이터 의 유형 과 메모리, 데이터 베이스 에 있 는 저장 방식 ① 정 수 는 메모리 에 패 치 방식 으로 저장 되 고 양수 와 음수 로 패 치 를 계산 하 는 방식 이 다르다. 유효 등가 류 중의 양수, 음수 단독 테스트 를 통 해 - 99 - 99 의 정 수 를 A, - 99 - 1 의 정수 B, 0 - 99 의 정수 로 세분 화 한다.② 비정 수 는 소수 자모 한자 기호 (3) 로 세분 화 할 수 있다.    데이터 범위 1    -99 - 1 의 정수 2    0 - 99 의 정수 무효 등가 류 번호    데이터 범위
//==============================================================
요약:
1. 유효 등가 류 또는 유효 경계 치 를 사용 하 는 테스트 도 '정방 향 테스트', '테스트 통과' (정 사례) 라 고 부 르 는데 보통 수량 이 적지 않 고 수요 에서 직접 찾 을 수 있다.
2. 무효 등가 류 또는 무효 경계 값 을 사용 하 는 테스트 를 '역방향 테스트' 라 고 부 르 고 '실패 테스트' (반 사례) 는 보통 수량 이 많 으 며 무효 등가 류 의 수량 은 보통 유효 등가 류 수량의 2 - 6 배 이다.
3. 무효 등가 류 가 주로 고려 하 는 요소:
(1) 수 요 는 '빈 / 필수 항목 이 아 닙 니 다' - '빈' 상황 을 테스트 해 야 합 니 다.
(2) 수요 요구 "중복 불가" - 테스트 "중복" 상황
(3) 데 이 터 는 크기 범위 가 있 습 니 다. 테스트 는 범 위 를 초과 하고 최소 치보다 작 으 며 최대 치보다 큽 니 다.
나이 18 - 60
무효: < 18 ，>60
(4) 문 자 는 숫자 요구 가 있 습 니 다. 문자 의 개수 가 범 위 를 초과 하고 최소 개수 보다 적 으 며 최대 개수 보다 많 습 니 다.
이름 3 - 20 글자
무효: < 3 개, > 20 개
(5) 데이터 형식, 스타일, 유형 요구 - 테스트 형식, 스타일, 유형 불법
예:
'정수' 를 요구 하면 무효 가 '비정 수' 이다. 이 는 소수, 자모, 한자, 기호 등 을 포함한다.
'숫자' 를 요구 하면 무효 가 바로 '비 숫자' 이다. 이 는 자모, 한자, 기호 등 을 포함한다.
(6) 소수 보류 자리수 요구 - 보류 자리수 불법
예 를 들 어 임금 은 최소 소수점 후 2 위 를 유지 해 야 하 며 무효 2 위 이상 유지 하 는 상황 을 테스트 해 야 한다.