대기업 소프트웨어 개발자는 프로그램에서 버그를 어떻게 확인합니까?


15

대기업 소프트웨어 개발자가 프로그램에서 버그를 확인하는 방법이 궁금합니다.

그들은 단지 여러 컴퓨터에서 테스트합니까?


13
그들을 풀어 놓기. (주요 기관에서 나온 ....의 버그가 많은 더미로 판단)
Orbling

그들은 매우 공격적인 영업 및 마케팅 캠페인을 수행하고, 다른 국가에 개발을 아웃소싱하며, "예기치 못한"큰 시장 점유율을 잃을 때까지 가능한 모든 버그를 피할 수 있습니다.
Job

대기업의 경우 왜 대기업과 다른가?
JohnFx

답변:


30

다음은 Google이 사용하는 기술 중 일부입니다.

  1. 신뢰할 수있는 코드를 생성 할 가능성이있는 훌륭한 개발자를 고용하십시오.
  2. 단위 테스트 .
  3. 코드 검토 사용 .
  4. 통합 문제를 포착하기 위해 지속적인 빌드 를 설정하십시오 .
  5. 전담 QA 부서가 있습니다. 최종 사용자를 시뮬레이션하는 사람 테스트 및 자동화 된 프로그램 (예 : Selenium 사용)을 의미합니다.
  6. 오작동의 증거를 포착하기 위해 프로덕션 환경에서 모니터링하십시오.

나는 버그를 잡는 데 효과가 내림차순으로 의심됩니다.


2
나쁜 대답은 아니지만 "QA", "단위 테스트"및 "연속 빌드"와 같은 많은 용어를 사용하여 이와 같은 질문을하는 사람에게는 알려지지 않을 수 있습니다. 연결하거나 정의를 제공하면 더 좋습니다.
Gabe

@gabe : 사용 된 용어에 대한 포인터를 추가했습니다.
btilly

3
+1-실제로 버그를 잡는 것이 가장 좋을 때 (즉, 가장 저렴하고 시간과 복잡성이 가장 낮은)의 좋은 순서 (1-> 6)입니다.
ozz

1
워드 기능 요청의 리본 90 %가 이미 있었다 기능 단어되기 전에 아마 또한 사용성 테스트, 사용자는 단지 그들을 찾을 수 없습니다
JK합니다.

@ jk : 누구의 통계입니까? 인용하십시오.
JBR 윌킨슨

19

대기업에는 일반적으로 코드를 테스트하고 예상대로 작동하는지 확인하는 전체 Q / A 부서가 있습니다. 일반적으로 설명했듯이 많은 사람들이 많은 기계를 테스트합니다. 때로는 테스트가 자동화되고 그렇지 않은 경우도 있습니다. 품질 보증 참조 -Wikipedia

많은 경우 개발자는 개발 과정에서 버그를 발견하게됩니다. 또한 고객이 버그를 가장 먼저 찾는 경우가 많습니다.

내가 현재 일하고있는 것과 같은 소규모 회사는 애자일 테스트 방법을 사용합니다.


1
예, 품질 관리 담당자는 테스트 계획을 구성합니다.
직업

+1 : 정확히 우리가하는 방법입니다. 테스트 팀 (내가있는)은 테스트 단위를 작성하고 사소한 단위 테스트를 제외하고 모든 테스트 코드를 작성합니다. 필수는 아닙니다). 우리는 수용, 통합 및 회귀에 중점을 둡니다. 개발자가 버그를 발견하면이를 기록하고 수정 한 후 테스트하여 자동화를 작성합니다.
Steven Evers

18

나는 규모아니라 회사 의 성숙도 에 대해 말하고 싶다 .

일반적으로 성숙한 개발 팀은 다음 활동을 수행합니다. 시스템에 새로운 버그 도입 최소화 2 기존 시스템에서 버그를 찾으십시오.

단위 테스트 : 개별 메소드를위한 '미니 드라이버'로서 메소드가 수행하는 방식을 수행합니다. 이들은 항상 자동 테스트입니다.

통합 테스트 : 이 테스트는 시스템 내에서 더 큰 기능 단위가 작동하는지 확인합니다. 데이터베이스 통합 테스트 또는 타사 라이브러리와의 통합 테스트가 필요할 수 있습니다. 이것도 자동 테스트입니다.

수락 테스트 : 승인 테스트는 사용자 요구 사항을 테스트하기 위해 작성되었습니다. 이들은 보통 '행복한 길'을 테스트합니다. 우리 팀에서 이러한 테스트는 사용자가 사용하도록 설계된 기능을 사용하는 경우 아무런 문제가 없음을 보여주기 위해 고안되었습니다. 수동 또는 자동화 가능

기능 테스트 : 이 테스트는 합격 테스트와 유사하지만 '불행한 경로'도 테스트합니다. 이러한 테스트는 그리 명백하지 않은 시나리오를 테스트한다는 의미입니다. 수동 또는 자동화 가능

회귀 테스트 : 이 용어는 고객에게 출시되기 전에 시스템의 '전체 테스트'를 수행하는 데 사용됩니다. 수동 또는 자동.

고릴라 테스트 : (수동). 이것은 매우 똑똑한 사람들이 의도적으로 응용 프로그램을 중단하려고 시도 할 때 일종의 테스트입니다.

성능 테스트 성능이 만족스럽고 시간이 지나도 저하되지 않는지 확인합니다. 일반적으로 자동화됩니다.

안정성 테스트 : 이 테스트는 시스템이 시간이 지남에 따라 안정적으로 유지되도록 설계되었습니다. 자동화

지속적인 통합 : 코드를 자동으로 체크 아웃하고 컴파일하여 자동화 된 테스트를 수행하는 시스템입니다. 개발자가 코드를 커밋 할 때마다 더 빠른 테스트 (단위, 통합)가 실행됩니다. 다른 것들은 야간 (수용, 기능) 또는 매주 (성능, 안정성)로 운영됩니다.

코드 적용 범위 보고서 : 테스트 한 코드 양을 표시합니다. 테스트 범위가없는 코드는 더 깨질 수 있습니다.

코드를 분석하는 다양한 도구 : 일반적으로 잠재적 버그가 발생하지 않도록 코드를 리팩터링해야하는 위치를 보여줍니다.

페어 프로그래밍 : 기능을 제공하기 위해 두 명의 개발자가 협력합니다. "응집력있는 쌍이 부품의 합보다 낫습니다."

가장 중요한 것은 자동화지속적인 통합 입니다.


회사의 성숙도에 대한 의견 불일치-소프트웨어 개발 책임자도 소규모 / 소규모 기업의 품질에 관심을 갖고 메시지가 하향식으로 진행될 수 있습니다. 엔지니어의 성숙도는 가능합니다.
JBR 윌킨슨

1
@JBRWilkinson : 회사가 '성숙'하다는 것이 무엇을 의미하는지 이야기 할 수있을 것 같습니다. 나는 그것이 '지혜'와 같이 나이와 관련이 있다는 것을 의미하지는 않았다. 신생 기업은 1 년 또는 2 년 밖에되지 않더라도 성숙하고 현명 할 수 있습니다.
c_maker

4

회사와 개발하는 제품에 따라 다릅니다.

첫째, 많은 회사에서 코드 검토 및 필수 린트 (자동 버그 감지 도구)와 같은 코딩 방식을 시행하여 리포지토리로 들어오는 오류의 양을 줄입니다. 많은 회사들도 단위 테스트를 채택했습니다. 이것이 내가 일하는 경우입니다 (Google). 코드가 체크인되면 새로운 오류가 발생하지 않도록 모든 테스트를 수행합니다.

둘째, 많은 회사에는 행동을 검증하는 QA 부서가 있습니다. 이는 재무 (일반적으로 실수가 많고 검증 규칙이 복잡한 경우)에서 일반적이지만 리콜이 비싼 사용자에게 제품을 판매하는 회사 (예 : 인텔, Microsoft 등)에도 있습니다.

셋째, 가능하면 회사에서 Dogfooding을 수행하고 (자체 사용자가 내부적으로 제품을 사용하도록 함) 제한된 베타 버전을 출시합니다. 이 단계에서 많은 오류가 발생합니다. 예를 들어, Microsoft에서 일하는 사람들은 외부에있는 것보다 최신 내부 버전의 Office, Windows 및 DevStudio를 사용합니다. 그런 다음 제한된 사용자 그룹 또는 계약 회사가이를 샘플링합니다. 마찬가지로 Google에서는 출시 전에 내부 버전의 GMail 및 문서를 사용합니다. 게임 회사는 공개 베타를 구성하여 제품 및 서버의 부하 등을 테스트합니다.


1

물론 대답은 "종료"이지만, 지금까지 약 50 명의 개발자가 참여한 최대 규모의 프로젝트에서 샘플을 제공 할 것입니다.

기본 설정 : BizTalk로 대량의 데이터를 처리하기위한 백엔드 소프트웨어.

첫 번째 방어선은 단위 테스트입니다. 우리의 경우 소스 컨트롤에 체크인 된 모든 항목에 대해 매일 실행되었으며 일반적으로 일부는 체크인 전에 개발자가 수동으로 실행했습니다. 단위 테스트는 주로 개발자가 작성했지만 때때로 테스터의 추가 테스트로 수정되었습니다.

다음 단계는 매주 Virtual PC 빌드로, 테스터는 각 구성 요소의 사양 문서를 기반으로 데이터 흐름에 대해 일련의 주로 자동화 된 엔드-투-엔드 테스트를 실행했습니다.

그 후 동일한 가상 PC에 실제 비즈니스와 매우 가까운 일부 비즈니스 데이터가 풍부 해졌으며 특정 사용 사례로 다시 테스트되었습니다.

그런 다음 Virtual PC는 다른 부서의 다른 시스템 구성 요소 (주로 가상)와 함께 사용자가 데이터를 입력 한 후 데이터 흐름의 끝까지 엔드 투 엔드 테스트를 기반으로 통합 테스트 주기로 구성되었습니다.

다른 트랙에서 시스템 제공 업체가 설치 패킷을 테스트하여 프로덕션과 유사한 환경에 올바르게 설치되었는지 확인하고 무언가 실패한 경우 롤백 할 수 있는지 확인했습니다.

프로덕션 환경에 설치 한 후 전체 안정성을 테스트하기 위해로드 및 스트레스 테스트를 실행했습니다 (10 개의 BizTalk 서버, 8 개의 SQL Server 및 XML 가속기와 같은 기타 특수 하드웨어에서 실행할 때 가볍게 수행 할 사항은 없습니다) 전용 아카이브 (모두 클러스터 됨).

모든 테스트에 만족하면 코드가 프로덕션에 투입되었습니다. 코드의 버그를 수정하기 위해 대기 시간이 꽤 길며 (전체 테스트주기의 경우 4-6 주) 이러한 모든 테스트를 수행하는 데 비용이 많이 들지만 전체적인 안정성은 꽤 좋았습니다. 사실 내가 지금까지 본 것 중 최고입니다. 다시 말하지만 그것은 매일 수백만 달러 가치가있는 시스템에서 매우 중요합니다. 요구 사항은 다를 수 있지만 이것이 우리가 수행 한 방식입니다.


1

원래의 질문은 제공된 대부분의 자세한 답변보다 개념적으로 더 일반적으로 보입니다.

더 높은 수준 (더 자세하지 않음)에서 보도록하겠습니다. 소프트웨어는 누군가 (사람, 회사 등)의 특정 요구에 맞도록 개발되었습니다.

이러한 요구 사항은 최근에 (건설 단계에서) 소스 코드로 구현 될 개별 스토리 / 요구 사항에 매핑되어야합니다.

QA (Quality Assurance) 팀 (실제 소프트웨어 테스터)이 스토리 / 요구 사항을 올바르게 정의하는 것은 실행시 최종 코드를 검증하여 스토리 및 요구 사항의 요구에 부응하는 데 필수적입니다. 이를 위해 QA 팀은 해당 유효성 검사를 수행하기 위해 "테스트 사례"를 만듭니다.

QA 팀에 일단 릴리스 된 코드는 테스트되고 버그가 식별됩니다. 다른 유형과 심각도의 버그. 이러한 버그는 추적되고 개발자는 최종적으로 수정되도록 할당됩니다.

오늘날 가상 머신을 사용하면 한 명의 테스터가 동일한 실제 하드웨어에서 서로 다른 환경을 실행할 수 있습니다. 그러나 때로는 QA 단계 전용 컴퓨터가 필요할 수도 있습니다.

전반적인 프로세스를 이해하는 데 도움이되기를 바랍니다.


0

글쎄, 나는 냉소적 인 것을 싫어하지만 특정 '장치'운영 체제에서 열린 버그 수에 따라 회사가 더 크고 풍부할수록 더 많은 버그가 생성되어 최종 사용자에게 제공 할 수 있습니다. 소프트웨어가 작동하고 멋지게 보인다면 어쨌든 소프트웨어를 해제하면됩니다. 관리자가 준비가되었다고 생각하면 준비가 된 것입니다. 그때 정말 불쾌한 벌레가 목공에서 나오기 시작하고 최종 사용자가 기니피그가됩니다. 10 년 후, 대부분의 버그가 해결되었고 (몇몇은 추가 조치를 취하여) 다음 큰 아이디어로 넘어갈 준비가되었습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.