소프트웨어 테스팅에서 동시성 테스트란 무엇입니까?
⚡ 스마트 요약
동시성 테스트는 여러 사용자가 동시에 동일한 애플리케이션에서 작업할 때만 발생하는 결함을 감지하여 순차적인 기능 검사로는 절대 드러낼 수 없는 교착 상태, 업데이트 손실 및 잠금 문제를 밝혀냅니다.
동시성 테스트란 무엇입니까?
동시성 테스트 이는 여러 사용자가 로그인한 상태에서 애플리케이션의 결함을 감지하는 데 사용되는 테스트 기법입니다. 다시 말해, 여러 사용자가 동시에 동일한 작업을 수행할 때 발생하는 영향을 모니터링하는 것입니다.
동시성 테스트는 다음과 같이 불리기도 합니다. 다중 사용자 테스트동시 실행 프로그램을 테스트하는 것은 비결정성과 동기화 문제 때문에 순차 실행 프로그램을 테스트하는 것보다 더 어렵습니다. 즉, 코드 한 줄도 변경하지 않고도 동일한 테스트가 한 번 실행에서는 통과하고 다음 실행에서는 실패할 수 있습니다.
아래 다이어그램은 여러 사용자가 동시에 동일한 애플리케이션 리소스에 접근할 때, 애플리케이션이 이러한 중복 상황을 어떻게 처리하는지 관찰하는 개념을 보여줍니다.
동시성 테스트를 해야 하는 이유는 무엇일까요?
두 가지 질문이 이러한 노력을 정당화하며, 두 질문 모두 단일 사용자 기능 실행에서는 보이지 않습니다.
- 이는 동일한 데이터베이스 레코드, 모듈 또는 애플리케이션 코드에 동시에 접근할 때 발생하는 영향을 파악합니다.
- 이 도구는 교착 상태, 잠금, 단일 스레드 코드 사용 및 공유 리소스에 대한 제한된 액세스 수준을 식별하고 측정합니다.
어떤 기능이 한 사용자에게는 완벽하게 정확하더라도, 단 1밀리초 후에 접속하는 다른 사용자에게는 데이터가 손실될 수 있습니다. 바로 이러한 이유 때문에 이 기술은 다른 기술과 함께 사용됩니다. 성능 시험 기능 테스트 내부가 아니라.
동시성 테스트를 수행하는 방법
동시성 테스트는 반복 가능한 순서를 따릅니다. 아래 단계는 sco에서 시작합니다.ping 해상도까지.
- 1단계) 동시성 문제가 발생하기 쉬운 흐름을 식별합니다. 공유 상태를 찾아보세요. 동시 로그인, 좌석 또는 주식 예약, 잔액 업데이트, 동일한 테이블에 기록하는 배치 작업 및 경로에 있는 모든 단일 스레드 구성 요소가 여기에 해당합니다.
- 2단계) 동시 접속 목표를 설정합니다. 동시에 행동해야 하는 사용자 수를 결정할 때는 단순히 정수가 아닌 실제 사용량 최고치를 기준으로 해야 합니다.
- 3단계) 테스트 케이스를 설계합니다. 각각의 테스트 사례 공유 리소스, 경쟁하는 작업 및 예상되는 최종 상태를 쌍으로 나타냅니다. 예를 들어, 하나의 계정에서 두 세션이 동시에 출금하는 것은 성공해서는 안 됩니다.
- 4단계) 스크립트를 작성하고 도구를 선택합니다. 설정 가능한 가상 사용자를 생성하는 부하 발생기가 필요합니다. JMeter 이는 일반적으로 많이 사용되는 오픈 소스 라이브러리이며, 스레드 그룹 설정이 동시성 시나리오에 직접적으로 적용됩니다.
- 단계 5) Ramp 점차적으로. 동시 접속 사용자 수를 한 번에 늘리지 말고 단계적으로 늘리세요.ping 목표 지점까지 도달하므로, 논쟁이 시작되는 수준을 확인할 수 있습니다.
- 6단계) 모니터링 및 분석. 락 대기 시간, 응답 시간 분산, 오류율 및 데이터베이스 블로킹을 함께 관찰하십시오. 동시성 결함은 오류로 나타나기 전에 타이밍 이상으로 나타나는 경우가 많습니다.
- 7단계) 문제를 해결하고 다시 실행합니다. 동기화, 인덱싱 또는 잠금 문제의 원인을 해결한 다음 동일한 실행을 반복하여 동작이 이동된 것이 아니라 변경되었는지 확인하십시오.
일반적인 동시성 결함
동시성 관련 결함은 몇 가지 식별 가능한 유형으로 분류되며, 해당 유형의 이름을 정확하게 지정하면 수정 방법을 바로 찾을 수 있습니다.
| 결함 | 무슨 일이 | 전형적인 증상 |
| 레이스 조건 | 결과는 어느 세션이 먼저 끝났는지에 따라 달라집니다. | 일부 실행에서는 총합이 정확하고, 다른 실행에서는 잘못되었습니다. |
| 이중 자물쇠 | 두 세션은 각각 상대방에게 필요한 자물쇠를 하나씩 쥐고 있습니다. | 오류가 발생하는 대신 트랜잭션이 중단됩니다. |
| 업데이트가 손실되었습니다 | 두 번째 쓰기 작업은 첫 번째 쓰기 작업을 읽지 않고 덮어씁니다. | 저장된 변경 사항이 조용히 사라집니다 |
| 데이터 손상 | 공유 구조는 부분적으로만 작성됩니다. | 유효한 거래로 생성할 수 없는 상태의 기록 |
| 굶주림 | 한 세션이 기다리는 리소스를 전혀 얻지 못했습니다. | 시스템이 정상적으로 보이는 동안에도 특정 사용자 경로에서 시간 초과 오류가 발생했습니다. |
이러한 오류는 간헐적으로 발생하므로 모든 실행에 대한 로그와 타임스탬프를 기록해야 합니다. 그렇지 않으면 해당 결함을 신뢰할 수 있게 보고할 수 없습니다. 결함 관리 프로세스.
동시성 테스트 예시
온라인 쇼핑몰에 재고가 마지막 하나 남은 상품이 있다고 가정해 보겠습니다. 두 명의 쇼핑객이 동시에 상품 페이지를 열고 결제 버튼을 누릅니다. 구매하다.
- 시나리오 : 두 세션 모두 재고를 1로 읽고, 가용성 검사를 통과했으며, 두 세션 모두 재고를 0으로 기록했습니다.
- 예상 결과: 한 주문은 확정되고, 다른 주문은 재고 부족 메시지를 받으며, 재고량이 마이너스가 되는 경우는 절대 없습니다.
- 결함 표시기: 두 주문 모두 확정되거나 재고가 -1이 되면 재고 확인과 재고 감소가 하나의 단계로 실행되지 않았음을 나타냅니다.
- 시도해볼 만한 변형: 두 세션이 하나의 프로필 레코드를 편집하고, 동일한 요청을 두 번 승인하고, 사용자가 저장하는 동안 배치 작업이 테이블을 업데이트하는 경우입니다.
동일한 패턴이 일반화됩니다. 리소스 하나, 작성자 두 명, 순서 보장 없음. 시나리오 실행 중 시스템 테스트부하가 추가되기 전에 진단을 깔끔하게 유지합니다.
동시성 테스트의 장점
- 이는 동시 상호 작용 범위를 널리 사용되고 충분히 테스트된 몇 가지 구성 요소로 제한함으로써 애플리케이션 테스트에 필요한 노력을 상대적으로 줄여줍니다.
- 캡슐화를 통해 프로그램 전체 코드베이스를 검토하지 않고도 프로그램의 일부 동작을 분석할 수 있습니다.
- 이는 동시 실행 프로그램의 신뢰성과 견고성을 향상시키는 데 도움이 됩니다.
- 이를 통해 잠금 및 차단 한계를 조기에 파악할 수 있으므로 용량 결정은 추정치가 아닌 측정된 경쟁 상황에 기반합니다.
동시성 테스트의 단점
아래와 같은 단점들은 동시성 테스트를 수행하는 동안 테스터들이 흔히 겪는 문제점들입니다.
- 해당 애플리케이션은 여러 플랫폼에서 테스트되어야 합니다.
- 동시 실행 시나리오는 순차 실행 시나리오보다 더 집중적인 테스트가 필요합니다.
- 함수는 호출자에게 결과를 즉시 반환하지 않고, 알림, 블록, 콜백 함수 또는 이와 유사한 메커니즘을 통해 나중에 결과를 전달하므로 테스트가 더 어려워집니다.
- 정보나 프로그램 흐름은 호출 스택에 반영되지 않습니다.
- 동시 실행 시스템에서는 프로세스들이 실행되는 동안 서로 상호 작용하기 때문에 시스템 내 실행 경로의 수가 매우 많을 수 있습니다.
- 동시 실행 프로그램은 순차 실행 프로그램보다 실패율이 더 높습니다.
- 동시 실행 프로그램을 디버깅하는 것은 어렵습니다. 디버거를 연결하면 오류가 발생한 시점이 바뀌기 때문입니다.

