수동 QA (품질 보증)QA 엔지니어 (수동 테스트, 액세스 권한)

어떻게 애플리케이션에서 사용자 액세스 권한과 역할에 대한 수동 테스트를 효율적으로 조직할 수 있습니까?

Hintsage AI 어시스턴트로 면접 통과

답변.

수동 테스트는 다양한 유형의 사용자가 애플리케이션의 기능 및 데이터에 대한 적절한 액세스 레벨을 가지고 있는지 확인할 수 있게 해줍니다.

질문의 역사

사용자의 수와 작업 시나리오가 증가함에 따라 심지어 간단한 애플리케이션도 역할 모델을 갖추게 되었습니다. 권한 오류는 종종 심각한 데이터 유출이나 비즈니스 운영의 제한으로 이어졌습니다. 이로 인해 역할을 철저히 수동으로 테스트할 필요성이 생겼습니다.

문제

  • 민감한 데이터에 대한 액세스 제한에서 오류가 발생하는 경우;
  • 일반 사용자가 허용되지 않은 작업(예: 관리 기능에 대한 액세스)을 수행할 수 있게 만드는 잘못된 역할 설정;
  • 조합 역할이나 비표준 액세스 시나리오를 검사하는 데 어려움이 있음.

해결책

  • 모든 기존 역할과 각 역할에 해당하는 작업을 문서화합니다;
  • 조건부 역할 교차를 포함한 각 역할에 대한 테스트 세트를 생성합니다;
  • 기능뿐만 아니라 데이터의 다양한 부분(CRUD)에 대한 액세스를 확인합니다;
  • UI를 통한 직접 액세스와 직접 링크 또는 API를 통한 액세스 시도를 모두 유효성 검사합니다.

주요 특징:

  • 시나리오에 대한 포괄적 커버리지: 각 유형의 사용자는 가능한 모든 역할과 작업에서 검토되어야 합니다;
  • 경계 및 조합 역할 테스트: 종종 다른 역할의 권한이 겹칠 때 오류가 발생합니다;
  • 표준 인터페이스 우회 검사: 사용자가 공식적으로 권한이 없는 페이지/작업에 대한 직접 액세스 테스트.

함정 질문.

주요 역할(예: "관리자" 및 "사용자")만 테스트하면 충분합니까?

아닙니다. 중간 역할, 드물게 사용되는 역할 및 조합 역할에 결함이 숨겨져 있는 경우가 많습니다.

UI 제한(숨겨진 버튼 및 요소)이 보안에 충분합니까?

아닙니다. UI 제어는 주소나 API를 통한 직접 액세스 시도로부터 보호하지 않으므로 서버 로직 수준에서 권한을 제한해야 합니다.

애플리케이션의 다양한 채널(예: 웹과 모바일 애플리케이션 모두)을 통한 액세스 권한을 테스트해야 합니까?

필수입니다. 구현의 차이는 행동의 차이와 권한 제한 오류를 초래합니다.

일반적인 오류 및 안티 패턴

  • 표준 역할만 검사함
  • 서버 제한 검증 없이 외부 인터페이스만 의존함
  • 비표준 및 조합 역할 무시

실생활 사례

부정적인 사례

UI만 검사했으며 단지 세 가지 주요 역할만 확인했습니다. 결과적으로 비표준 역할 조합을 가진 사용자들이 직접 링크를 통해 관리 기능에 접근할 수 있었습니다.

장점:

  • 빠른 테스트
  • 프로세스의 간단함

단점:

  • 프로덕션에서 발견된 심각한 취약점
  • 보안 및 사용자 신뢰의 위반

긍정적인 사례

테스트를 위해 다양한 역할 조합을 가진 테스트 사용자가 생성되었으며, API 및 직접 액세스에 대한 감사가 진행되었습니다. 오류는 발견되어 릴리스 전에 수정되었습니다.

장점:

  • 높은 품질 및 보안
  • 내부 및 외부 데이터 유출 위험 감소

단점:

  • 여러 테스트 계정을 생성하는 데 시간 소모
  • 문서량 증가 및 개발과의 조정 필요