소프트웨어 결함
소프트웨어 결함: "버그"라고도 합니다. 제대로 작동하는 능력을 손상시키는 컴퓨터 소프트웨어 또는 프로그램의 문제, 버그 또는 숨겨진 기능적 결함입니다.
A형
소프트웨어는 제품 사양에서 요구하는 기능 모듈을 구현하지 않습니다.
발현 B
제품 사양에서 발생해서는 안 되는 오류가 소프트웨어에서 발생했습니다.
C형
소프트웨어는 제품 사양에 언급되지 않은 기능적 요구 사항을 구현합니다.
표현의 형식
소프트웨어는 제품 사양에서 명시적으로 언급하지 않았지만 해야 할 일을 달성하지 못합니다.
표현의 형식
이 소프트웨어는 이해하기 어렵고 사용하기 어려우며 느리고 사용자 친화적이지 않습니다.
결함 정의
1. 소프트웨어 사용 중 발생하는 모든 문제를 소프트웨어 결함이라고 합니다.
2. 결함은 버그와 다릅니다.
3. 결함의 존재로 인해 소프트웨어 제품이 사용자의 요구를 어느 정도 충족시킬 수 없습니다.
4. 귀하의 소프트웨어가 사용자를 불편하게 만드는 한
불량판정기준
소프트웨어가 요구사항(사양) 명세에서 명확하게 요구되는 기능을 구현하지 않음 – 기능이 적음
소프트웨어에 요구사항(명세) 명세에 나타나지 않아야 하는 오류가 있음 – 기능적 오류
소프트웨어에 의해 구현된 기능이 요구사항에 지정된 범위를 초과함 (사양) 사양 – 다기능
소프트웨어가 사양에 명확하게 지정되지 않았지만 충족되어야 하는 요구 사항(사양)을 인식하지 못함 – 숨겨진 기능 오류 소프트웨어가
이해하기 어렵고, 사용하기 어렵고, 실행 속도가 느리고, 사용자 경험이 좋지 않고 사용하기 어렵습니다.
결함의 원인
요구사항 단계: 요구사항 설명이 이해하기 쉽지 않거나 모호하거나 잘못됨 등
디자인 단계: 설계 문서의 오류 또는 결함
코딩 단계: 코드에 오류가 발생함
운영 단계: 소프트웨어 및 하드웨어 시스템 장애로 인한 소프트웨어 결함
소프트웨어 결함 유형
1. 기능 오류: 소프트웨어가 요구 사항 문서의 기능 요구 사항을 충족하지 않거나 기능이 비정상입니다
2. 인터페이스 오류: 소프트웨어 기능은 정상이지만 인터페이스가 보기에 좋지 않거나 요구 사항을 충족하지 않습니다. 3. 호환성
오류: 시스템의 소프트웨어 및 기타
오류 4. 사용 편의성 오류: 소프트웨어가 사용하기 쉽지 않음
5. 개선 제안: 변경하는 것이 좋고 변경하지 않아도 됨
결핍 속성(Zen Tao에서 학습)
1. 결함 ID(ID): 결함 ID는 결함을 표시하는 일련의 기호입니다. 각 결함에는 고유 식별자가 있어야 합니다.
2. 결함 유형: 결함 유형은 결함의 자연적 속성에 따라 분류된 결함 유형입니다. 기능적인 인터페이스는 사용의 용이성을 요구합니다..
3. 결함 심각도: 결함 심각도는 결함으로 인한 결함이 소프트웨어 제품에 영향을 미치는 정도를 의미합니다. 치명적/치명적/보통/권고
4. 결함 우선 순위: 결함의 우선 순위는 결함을 수정해야 하는 긴급성을 나타냅니다. 긴급/보통/비긴급
5. 양수인: 이 버그를 수정하기 위해 전달되는 사람을 말합니다.
6. 결함 상태: 결함 상태는 추적된 수리 프로세스를 통해 결함의 진행 상황을 나타냅니다.
New(Open): 테스터 또는 다른 사람이 새로 제출된 버그와 같은 제출된 버그를 발견하고 확인합니다.
Deprecated: 확인 후 제출된 버그가 버그가 아닌 것으로 확인됩니다.
수정 예정: 개발팀에서 버그의 유효성을 확인하고 처리합니다.
처리: 개발자가 버그의 유효성을 확인하고 처리합니다.
수정됨: 개발자가 원인을 찾아 수정한 결함입니다.
닫힘(최종 상태): 테스터는 수정된 버전에서 문제가 실제로 수정되었는지 확인합니다.
다시 열기: 테스터는 수정된 버전에서 버그가 여전히 존재하는지 확인합니다.
추적 대상: 버그를 재현할 수 없으며 개발팀에서 문제의 원인을 찾을 수 없습니다.
결함 보고서의 중요 구성 요소
(1) 아니요.
버그 제출 순서
(2) 제목
결함을 간략히 설명하십시오.
(3) 발견자
작업 번호, 사용자 이름, 이름 등과 같은 결함을 발견한 사람
(4) 발견 연월일
결함을 제출하기 위한 시스템 날짜, 일반적으로 같은 날
(5) 소속 모듈
결함을 발견한 기능 모듈 (개발 관리자가 모듈에 따라 결함 담당자를 찾는 것이 편리함)
(6) 버전
결함이 발견된 소프트웨어 버전(예: XX 시스템 vYYYY-MM-DD 또는 XX 시스템 버전 XXX)
(7) 누구에게
테스터는 결함을 개발 관리자에게 할당하고 개발 관리자는 결함이 있는 모듈에 따라 특정 개발자에게 다시 할당합니다.
(8) 불량현황
생성 후 기본적으로 활성화(열림)
(9) 심각도
버그의 심각도를 정확하게 평가하기 위해 심사 기준은 회사의 정의 사양을 참조합니다.
(10) 우선 순위
버그의 우선 순위 수준을 정확하게 평가합니다. 자세한 내용은 회사 손실 및 우선 순위 정의를 참조하십시오. 일반적으로 테스트 프로세스를 차단하는 문제는 시급하며 상황에 따라 다릅니다.
(11) 결함 설명
개발자가 설명을 통해 버그를 재현할 수 있도록 결함 발견 프로세스, 단계, 사용된 데이터 등을 기록합니다.
알아야 할 문제:
① 결점별로 따로 기록하고, 결점을 2개 이상 함께 기록하지 않는다.
② 결함 설명은 명확하고 정확하며 읽기 쉬워야 하며 결함의 재발을 보장하기 위해 필요하고 작은 단계를 사용해야 합니다.
③ 결함의 정도와 우선순위는 정확하고 객관적으로 분류되어야 한다.
④ 접수된 하자가 유효한 하자인지 하자신고서 제출 전 주의 깊게 확인
⑤ 개발자의 관심을 끌기 위해 결함을 과장하지 마십시오.
⑥ 경미한 결함도 결함 보고서를 기록해야 함
⑦ 결함을 적시에 보고(개발자가 수정할 수 있는 충분한 시간을 남겨두기)
⑧ 발견된 결함에 대해 어떠한 평가도 하지 않음(결함을 마음대로 평가, 개발자의 마음을 아프게 하기 쉬움)
⑨ 랜덤불량도 보고하여야 함(랜덤불량은 재현이 용이하지 않고 정해진 단계에 따라 사라지는 경우도 있으므로 랜덤불량임을 표시하고 발생단계 및 발생빈도를 구체적으로 기재할 필요가 있으며, 등.)
실제 사례
광학 이론은 쓸모없고 따라하는 법을 배워야하고 스스로해야하므로 배운 것을 실습에 적용 할 수 있습니다.이때 몇 가지 실제 사례에서 배울 수 있습니다.
도움이 되셨다면 좋아요와 모아 작가님에게 힘이 되어주세요. 다음에도 빠르게 찾을 수 있어 편리합니다.
이해가 되지 않으면 아래의 작은 카드를 참조하십시오. 블로거도 같은 생각을 가진 테스터와 함께 배우고 발전하기를 희망합니다.
적절한 나이에 적절한 위치를 선택하고 자신의 이점을 최대한 활용하십시오.
내가 계획하고 요약하는 것을 좋아하기 때문에 자동화된 테스트 개발의 길은 각 단계의 계획과 분리할 수 없습니다.
비디오 튜토리얼을 테스트 및 개발하고, 노트를 공부하고, 포털을 받으세요! ! !