기술나눔

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

당신이소프트웨어 테스팅 엔지니어 , 당신이 매일 직면하는 것은 그 "까다로운" 벌레들입니다. 그들은 어둠 속에 숨어 있는 적들과 같아서 때때로 당신에게 "놀라움"을 주기 위해 튀어나옵니다. 그렇다면 이러한 버그를 효과적으로 분석 및 처리하고 테스트 작업을 효율적이고 흥미롭게 만들 수 있는 방법은 무엇일까요? 오늘 우리는 이 주제에 대해 이야기하겠습니다.

근본 원인부터 시작하십시오. 버그의 "진짜 범인"은 어디에 있습니까?

먼저 고전적인 사례를 살펴보겠습니다.Xiao Li는 경험이 풍부한 사람입니다.테스트 엔지니어 , 그는 최근 금융 시스템 테스트를 담당했습니다. 테스트 중에 Xiao Li는 심각한 버그를 발견했습니다. 사용자가 이체 작업을 수행할 때 금액에 오류가 있었습니다. 이 버그가 프로덕션 환경에 적용되면 그 결과는 비참할 것입니다.

그래서 Xiao Li는 그의 "탐정 여행"을 시작했습니다. 그는 근본 원인부터 시작하여 버그를 일으킬 수 있는 다양한 요인을 분석했습니다. 몇 가지 조사 끝에 Xiao Li는 문제가 불완전한 수요 분석과 프로그램 코드 문제에 있음을 발견했습니다. 일부 경계 조건은 요구 사항 문서에 지정되지 않아 특수 시나리오를 처리할 때 프로그램에 오류가 발생합니다.

이 경우 Xiao Li는 버그를 수정해야 할 뿐만 아니라 유사한 문제가 다시 발생하지 않도록 요구 사항 분석 및 코드 검토 프로세스를 개선해야 합니다.

사례 공유: 프로그램 코드 문제 뒤에

또 다른 사례를 살펴보겠습니다. Xiao Wang은 Xiao Li의 동료이며 전자상거래 프로젝트 테스트에 공동으로 참여했습니다. Xiao Wang은 버그를 발견했습니다: 장바구니에 있는 일부 품목의 재고 수량을 올바르게 표시할 수 없습니다. 이 버그는 간단해 보이지만 그 이유는 복잡합니다.

Xiao Wang은 상세한 분석을 통해 프로그래머들이 코딩 시 정상적인 시나리오만 고려하고 비정상적인 상황은 무시한다는 사실을 발견했습니다. 예를 들어, 재고 수량이 0인 경우 프로그램이 그에 따라 처리하지 않아 표시 오류가 발생합니다. 이 버그는 Xiao Wang에게 테스트 케이스를 작성할 때 정상적인 시나리오를 다룰 뿐만 아니라 다양한 비정상적인 상황도 고려해야 한다는 점을 상기시켜 줍니다.

모든 사람이 더 잘 이해할 수 있도록 돕기 위해 Xiao Wang은 특별히 샘플 코드도 작성했습니다.

def check_inventory(item_id):    inventory = get_inventory(item_id)    if inventory > 0:        return f"库存数量：{inventory}"    else:        return "商品已售罄"

# 测试用例assert check_inventory(101) == "库存数量：10"assert check_inventory(102) == "商品已售罄"

이 코드는 재고가 0인 경우에도 정보가 올바르게 표시될 수 있도록 간단한 조건부 판단을 사용합니다. Xiao Wang이 버그 분석을 통해 배운 내용입니다.

분석 결함 발견 단계: 소스부터 시작

버그를 분석할 때 개발 프로세스의 어느 단계에서 버그가 발견되었는지에도 주의를 기울여야 합니다. 일반적으로 버그 발견 단계는 테스트 분석 단계와 테스트 실행 단계로 나눌 수 있습니다.

테스트 분석 단계에서는 주로 요구사항 문서와 개요 설계 문서를 검토합니다. 이 단계에서 발견된 버그는 문서 문제 및 검토 문제와 관련된 경우가 많습니다. 스모크 테스트, 기능 테스트, 회귀 테스트 등을 포함한 테스트 실행 단계는 각 기능 모듈의 정상적인 작동을 보장하기 위해 소프트웨어를 종합적으로 검증하는 것입니다.

예를 들어, Xiao Li와 Xiao Wang은 프로젝트 초기 단계에서 많은 문서 문제를 발견했습니다. 이러한 문제가 제때 해결되지 않으면 후속 테스트에서 더 많은 버그가 발생할 가능성이 높습니다. 따라서 모든 문서와 코드가 완전히 검토되도록 모든 테스트 단계를 엄격하게 제어합니다.

결함 도입 시스템 분석: "발생률이 높은 영역" 찾기

때로는 버그 발생이 특정 시스템의 복잡성과 수정 정도와 관련되어 있는 경우도 있습니다. 여러 시스템이 포함된 대규모 프로젝트에서 일부 시스템은 과도한 수정으로 인해 버그가 발생하기 쉬운 "발생률이 높은 영역"이 될 수 있습니다. 예를 들어 Xiao Li와 Xiao Wang의 프로젝트에서는 시스템 2와 시스템 3이 가장 많은 수정을 가해 버그도 가장 많았습니다.

각 시스템의 결함 밀도(즉, 코드 1000줄당 결함 수)를 계산한 결과, 시스템 4의 수정 사항은 많았지만 결함 수가 상대적으로 적다는 사실을 발견했습니다. 이는 시스템 4의 코드 품질이 더 높고 시스템 2와 시스템 3에는 추가 최적화가 필요함을 나타냅니다.

테스트 중 누락된 탐지 분석: “그물을 빠져나가는 물고기” 방지

마지막으로 테스트 시 탐지 누락 문제에도 주의를 기울여야 합니다. 테스터가 아무리 주의를 기울여도 일부 버그는 테스트 단계에서 여전히 "누출"되어 프로덕션 환경에 들어갈 수 있습니다. 이러한 상황을 줄이기 위해 Xiao Li와 Xiao Wang은 정기적으로 테스트 프로세스를 검토하고 누락된 링크가 있는지 분석하여 시기적절하게 개선합니다.

예를 들어, 프로젝트가 시작된 후 프로덕션 환경에 일부 버그가 나타나는 것을 발견했는데, 그 중 1/3은 테스트 프로세스 중 누락된 감지로 인해 발생했습니다. 이러한 버그 중 일부는 테스트 사례 적용 범위가 충분하지 않기 때문에 발생하고 일부는 낮은 품질의 테스트 데이터로 인해 발생합니다.

마지막에 쓰세요

버그에 대한 종합적인 분석을 통해 문제의 근본 원인을 찾을 수 있을 뿐만 아니라 개선에 대한 영감도 얻을 수 있습니다. 요구 사항 분석, 코드 품질, 테스트 프로세스 등 모든 측면에 세심한 주의와 지속적인 최적화가 필요합니다. 그래야만 소프트웨어 품질이 향상되고 버그 발생이 줄어들 수 있습니다.

마지막으로 제 글을 꼼꼼히 읽어주시는 모든 분들께 감사의 인사를 전하고 싶습니다. 팬분들의 증가와 관심을 보면 항상 약간의 예의는 있습니다. 비록 아주 귀한 것은 아니지만, 직접 가져가셔도 됩니다! 

소프트웨어 테스팅 인터뷰 문서

우리는 고임금 직업을 찾기 위해 공부해야 합니다. 다음 인터뷰 질문은 Alibaba, Tencent, Byte 등 1급 인터넷 기업의 최신 인터뷰 자료이며 일부 Byte 상사는 이 세트를 마친 후 권위 있는 답변을 제공했습니다. 면접정보를 바탕으로 누구나 만족스러운 일자리를 찾을 수 있다고 믿습니다.