소프트웨어 버그의 고향은 어디라고 생각하십니까? 올바른,소프트웨어. 그러나 정확히 어디?
프로그램이 제대로 작동하지 않는 이유는 무엇입니까? 그것은 매우 간단합니다–그들은 사람들에 의해 만들어지고 사용됩니다. 사용자가 실수를하는 경우,이 프로그램의 작동에 문제가 발생할 수 있습니다-그것은 예상대로 작동하지 않을 수 있음을 의미 잘못 사용됩니다.
인적 오류
오류-잘못된 결과를 생성하는 인적 작업입니다.
그러나 소프트웨어는 실수를 할 수있는(그리고 할 수있는)사람들에 의해 설계되고 만들어집니다. 이 소프트웨어 자체에 결함이 있다는 것을 의미한다. 결함 또는 버그라고합니다(두 지정 모두 동일). 기억-소프트웨어는 단지 코드 이상입니다.
소프트웨어 결함 또는 버그
결함,버그-특정 기능의 실패로 이어질 수있는 구성 요소 또는 시스템의 결핍. 프로그램 실행 중에 발견 된 결함은 개별 구성 요소 또는 전체 시스템의 오류를 유발할 수 있습니다.
프로그램 코드를 실행하는 동안에도 쓰기 중에 포함 된 결함이 나타날 수 있습니다:프로그램이 해야 할 일을하지 않거나 그 반대의 경우도 마찬가지입니다.
소프트웨어 오류 또는 충돌
오류 또는 충돌은 구성 요소 또는 시스템 작동의 실제 결과와 예상 결과 간의 불일치입니다.
프로그램의 실패는 결함의 존재를 나타내는 지표가 될 수 있습니다.
따라서 세 가지 조건이 동시에 충족 될 때 버그가 존재합니다:
- 예상 결과가 알려져 있고
- 실제 결과가 알려져 있으며
- 실제 결과가 예상 결과와 다릅니다.
모든 버그가 충돌을 일으키는 것은 아니라는 것을 이해하는 것이 중요합니다.
고장은 결함뿐만 아니라 환경 조건에 의해서도 발생할 수 있습니다:예를 들어 방사선,전자기장 또는 오염은 소프트웨어와 하드웨어의 작동에도 영향을 줄 수 있습니다.
전체적으로 몇 가지 결함 및 그에 따른 실패 원인이 있습니다.:
- 소프트웨어 시스템의 사양,설계 또는 구현의 오류;
- 시스템 사용 오류;
- 불리한 환경 조건;
- 고의적 인 피해;
- 이전 오류,조건 또는 의도적 인 행동의 잠재적 인 결과.
결함은 다른 수준에서 발생할 수 있으며 시스템의 품질은 수정 여부 및시기에 따라 직접 달라집니다.
품질-고유 한 특성 세트가 요구 사항을 충족하는 정도.
소프트웨어 품질은 명시적이고 묵시적인 요구를 충족시키는 능력을 반영하는 소프트웨어의 특성 모음입니다. 요구 사항은 확립 된 필요 또는 기대입니다. 일반적으로 가정 또는 필수.
첫 번째 경우에는 모든 것이 올바르게 수행되었으며 고객의 기대에 완전히 부합하고 품질 기준을 충족하는 제품을 받았습니다.
두 번째 경우에는 코딩 중에 이미 오류가 발생하여 완성 된 제품에 결함이 나타났습니다. 우리가 비 준수를 참조하지만,이 수준에서,버그는 발견 및 수정하기가 매우 쉽다.
세 번째 옵션은 더 나쁩니다. 이는 사양에 대한 철저한 검사를 통해서만 알 수 있습니다. 이러한 결함을 수정하는 것은 쉬운 일이 아닙니다-당신은 제품 디자인을 재 설계 할 필요가있다.
네 번째 경우에는 요구 사항 형성 단계에서 결함을 규정했습니다; 모든 추가 개발 및 테스트조차도 처음에는 잘못된 길로 내려갔습니다. 테스트하는 동안 버그를 찾을 수 없습니다.이 프로그램은 모든 테스트를 통과하지만 고객이 거부 할 수 있습니다. 당신은 우리의 온라인 품질 보증 클래스 및 인증에 대한 자세한 내용을 배울 것입니다.
일반적으로 프로그램 코드에 결함이 나타나는 데는 다섯 가지 이유가 있습니다.
- 팀 커뮤니케이션 부족. 종종 비즈니스 요구 사항은 단순히 개발 팀에 도달하지 못합니다. 고객은 완성된 제품을 어떻게 보고 싶은지 이해하지만,개발자와 테스터에게 아이디어가 제대로 설명되지 않으면 결과가 예상대로 되지 않을 수 있습니다. 요구 사항은 소프트웨어 개발 프로세스의 모든 참가자가 사용할 수 있고 이해할 수 있어야합니다.
- 소프트웨어의 복잡성. 현대 소프트웨어는 복잡한 소프트웨어 시스템으로 결합 된 많은 구성 요소로 구성됩니다. 멀티 스레드 응용 프로그램,클라이언트-서버 및 분산 아키텍처,다중 계층 데이터베이스-프로그램은 작성 및 유지 관리가 어려워지고 프로그래머의 작업이 더 어려워집니다. 그리고 작업이 더 어려워 질수록 그것을 수행하는 사람이 더 많은 실수를 할 수 있습니다.
- 요구 사항 변경. 개발 후반의 요구 사항에 대한 사소한 변경조차도 시스템을 변경하기 위해 많은 작업이 필요합니다. 응용 프로그램의 설계 및 아키텍처가 변경되고 있으며,이는 소스 코드 및 소프트웨어 모듈의 상호 작용 원칙을 변경해야합니다. 이러한 지속적인 변화는 종종 미묘한 결함의 원인입니다. 그럼에도 불구하고 현대 비즈니스에서 자주 변화하는 요구 사항은 예외보다 더 많은 규칙이므로 이러한 조건에서의 지속적인 테스트 및 위험 관리는 품질 보증 부서의 직접적인 책임입니다.
- 제대로 문서화 된 코드. 잘못 작성되고 잘못 문서화 된 코드를 유지 관리하고 수정하는 것은 어렵습니다. 많은 회사는 프로그래머가 코드를 작성하고 문서화하는 특별한 규칙을 가지고 있습니다. 실제로 개발자가 처음에 프로그램을 신속하게 작성하도록 강요당하는 경우가 종종 있으며 이는 제품의 품질에 영향을 미칩니다.
- 소프트웨어 개발 도구. 렌더러,라이브러리,컴파일러,스크립트 생성기 및 기타 개발 보조 도구는 종종 완제품의 결함의 원인이 될 수있는 성능이 저조하고 문서화되지 않은 프로그램입니다.
