데이터베이스(데이터) 테스트 튜토리얼

데이터베이스 테스트란 무엇입니까?

데이터베이스 테스트 테스트 중인 데이터베이스의 스키마, 테이블, 트리거 등을 검사하는 소프트웨어 테스트 유형입니다. 또한 데이터 무결성과 일관성을 검사합니다. 복잡한 쿼리를 만들어 데이터베이스를 로드/스트레스 테스트하고 응답성을 검사하는 것이 포함될 수 있습니다.

데이터베이스 테스트

데이터베이스 테스트가 중요한 이유는 무엇입니까?

데이터베이스 테스트가 중요합니다 in 소프트웨어 테스팅 데이터베이스에 수신되고 저장된 데이터 값과 정보가 유효한지 확인하기 때문입니다. 데이터베이스 테스트는 데이터 손실을 방지하고 중단된 트랜잭션 데이터를 저장하며 정보에 대한 무단 액세스를 방지하는 데 도움이 됩니다. 데이터베이스는 모든 소프트웨어 애플리케이션에 중요하므로 테스터는 데이터베이스 테스트를 위해 SQL에 대한 지식이 있어야 합니다.

GUI는 일반적으로 그래픽 사용자 인터페이스가 응용 프로그램에서 가장 눈에 띄는 부분이기 때문에 테스트 및 개발 팀 구성원이 가장 강조합니다. 그러나 또한 중요한 것은 애플리케이션의 핵심인 DATABASE라는 정보를 검증하는 것입니다.

사용자가 거래를 하는 은행 애플리케이션을 고려해 보겠습니다. 이제 데이터베이스 테스트 또는 DB 테스트 관점에서 다음과 같은 사항이 중요합니다.

  1. 애플리케이션은 트랜잭션 정보를 애플리케이션 데이터베이스에 저장하고 이를 사용자에게 올바르게 표시합니다.
  2. 이 과정에서 정보가 손실되지 않습니다.
  3. 부분적으로 수행되거나 중단된 작업 정보는 애플리케이션에 저장되지 않습니다.
  4. 승인되지 않은 개인은 사용자의 정보에 접근할 수 없습니다.

위의 모든 목표를 보장하려면 데이터 검증 또는 데이터 테스트를 사용해야 합니다.

사용자 인터페이스 테스트와 데이터 테스트의 차이점

사용자 인터페이스 테스트와 데이터 테스트

사용자 인터페이스 테스트 데이터베이스 또는 데이터 테스트
이러한 유형의 테스트를 그래픽 사용자 인터페이스 테스트 또는 프런트엔드 테스트라고도 합니다. 이러한 유형의 테스트를 백엔드 테스트 또는 데이터 테스트라고도 합니다.
이러한 유형의 테스트는 주로 양식, 프리젠테이션, 그래프, 메뉴 및 보고서 등과 같은 시청 및 상호 작용을 위해 사용자에게 공개된 모든 테스트 가능한 항목을 다룹니다(VB, VB.net, V를 통해 생성됨).C++, Delphi – 프런트엔드 도구) 이러한 유형의 테스트는 시청을 위해 일반적으로 사용자에게 숨겨지는 테스트 가능한 모든 항목을 주로 다룹니다. 여기에는 다음과 같은 내부 프로세스와 스토리지가 포함됩니다. Assembly, DBMS와 같은 Oracle, SQL 서버, MYSQL 등

이러한 유형의 테스트에는

  • 텍스트 상자
  • 드롭다운 선택
  • 달력과 버튼
  • 페이지 탐색
  • 이미지 표시
  • 전체 애플리케이션의 모양과 느낌

이러한 유형의 테스트에는 다음 사항을 검증하는 작업이 포함됩니다.

  • 스키마
  • 데이터베이스 테이블
  • 키와 인덱스
  • 저장 프로시저 트리거
  • 데이터베이스 서버 검증
  • 데이터 중복 유효성 검사
테스터는 비즈니스 요구 사항은 물론 개발 도구 사용, 자동화 프레임워크 및 도구 사용에 대해 철저하게 지식을 갖추고 있어야 합니다. 백엔드 테스트를 수행하려면 테스터는 데이터베이스 서버와 구조화 쿼리 언어 개념에 대한 강력한 배경 지식을 가져야 합니다.

데이터베이스 테스트 유형

데이터베이스 테스트 유형

데이터베이스 테스트의 3가지 유형은 다음과 같습니다.

  1. 구조 테스트
  2. 기능 테스트
  3. 비기능 테스트

이 데이터베이스 테스트 튜토리얼에서는 각 유형과 해당 하위 유형을 하나씩 살펴보겠습니다.

구조적 데이터베이스 테스트

구조적 데이터베이스 테스트 주로 데이터 저장에 사용되며 최종 사용자가 직접 조작할 수 없는 데이터 저장소 내부의 모든 요소를 ​​검증하는 데이터베이스 테스트 기술입니다. 데이터베이스 서버의 유효성 검사는 구조적 데이터베이스 테스트에서도 중요한 고려 사항입니다. 이 테스트를 성공적으로 완료하려면 SQL 쿼리에 대한 숙달이 필요합니다.

스키마 테스트란 무엇입니까?

스키마 테스트 데이터베이스 테스트에서는 데이터베이스와 관련된 다양한 스키마 형식을 검증하고 테이블/뷰/열의 매핑 형식이 사용자 인터페이스의 매핑 형식과 호환되는지 확인합니다. 스키마 테스트의 주요 목적은 프런트엔드와 백엔드 간의 스키마 매핑이 유사한지 확인하는 것입니다. 따라서 이를 매핑 테스트라고도 합니다.

스키마 테스트에서 가장 중요한 체크포인트에 대해 논의해 보겠습니다.

  1. 데이터베이스와 관련된 다양한 스키마 형식의 유효성을 검사합니다. 테이블의 매핑 형식은 애플리케이션의 사용자 인터페이스 수준에 있는 매핑 형식과 호환되지 않는 경우가 많습니다.
  2. 매핑되지 않은 테이블/뷰/컬럼의 경우 확인이 필요합니다.
  3. 또한 환경 내의 이기종 데이터베이스가 전체 애플리케이션 매핑과 일관성이 있는지 확인할 필요도 있습니다.

또한 데이터베이스 스키마 유효성을 검사하기 위한 몇 가지 흥미로운 데이터베이스 테스트 도구를 살펴보겠습니다.

  • Ant와 통합된 DBUnit은 매핑 테스트에 매우 적합합니다.
  • SQL Server를 사용하면 테스터는 코드가 아닌 간단한 쿼리를 작성하여 데이터베이스의 스키마를 확인하고 쿼리할 수 있습니다.

예를 들어 개발자가 테이블 구조를 변경하거나 삭제하려는 경우 테스터는 해당 테이블을 사용하는 모든 저장 프로시저 및 뷰가 특정 변경 사항과 호환되는지 확인하려고 합니다. 또 다른 예는 테스터가 두 데이터베이스 간의 스키마 변경 사항을 확인하려는 경우 간단한 쿼리를 사용하여 이를 수행할 수 있다는 것입니다.

데이터베이스 테이블, 열 테스트

데이터베이스 및 컬럼 테스트를 위한 다양한 검사에 대해 살펴보겠습니다.

  1. 백엔드의 데이터베이스 필드 및 열 매핑이 프런트엔드의 매핑과 호환되는지 여부
  2. 요구 사항에 지정된 대로 데이터베이스 필드와 열의 길이와 명명 규칙을 검증합니다.
  3. 사용되지 않거나 매핑되지 않은 데이터베이스 테이블/열이 있는지 확인합니다.
  4. 호환성 검증
  • 데이터 형식
  • 필드 길이

애플리케이션의 프런트엔드에 있는 것과 백엔드 데이터베이스 열을 비교합니다.

  1. 데이터베이스 필드를 통해 사용자가 비즈니스 요구 사항 사양 문서에서 요구하는 대로 원하는 사용자 입력을 제공할 수 있는지 여부.

키 및 인덱스 테스트

키와 인덱스에 대한 중요 점검 –

  1. 필수인지 확인하세요
  • 기본 키
  • 외래 키

필수 테이블에 제약 조건이 생성되었습니다.

  1. 외래 키에 대한 참조가 유효한지 확인하십시오.
  2. 두 테이블의 기본 키와 해당 외래 키의 데이터 유형이 동일한지 확인합니다.
  3. 모든 키와 인덱스에 대해 필수 명명 규칙을 준수했는지 확인하세요.
  4. 필수 필드와 인덱스의 크기와 길이를 확인하세요.
  5. 필수 여부
  • Cluster에드 인덱스
  • 비 Cluster에드 인덱스

비즈니스 요구 사항에 지정된 대로 필수 테이블에 생성되었습니다.

저장 프로시저 테스트

저장 프로시저를 확인하는 중요한 테스트는 다음과 같습니다.

  1. 개발팀이 필수 A) 코딩 표준 규칙, B) 예외 및 오류 처리를 채택했는지 여부. 테스트 중인 애플리케이션의 모든 모듈에 대한 모든 저장 프로시저에 사용됩니다.
  2. 개발팀이 테스트 중인 애플리케이션에 필수 입력 데이터를 적용하여 모든 조건/루프를 처리했는지 여부
  3. 개발팀이 데이터베이스의 필수 테이블에서 데이터를 가져올 때마다 TRIM 작업을 올바르게 적용했는지 여부
  4. 저장 프로시저를 수동으로 실행하면 최종 사용자에게 필요한 결과가 제공됩니까?
  5. 저장 프로시저를 수동으로 실행하면 테스트 중인 애플리케이션의 요구에 따라 테이블 필드가 업데이트되는지 여부?
  6. 저장 프로시저를 실행하면 필요한 트리거를 암시적으로 호출할 수 있습니까?
  7. 사용되지 않은 저장 프로시저가 있는지 확인합니다.
  8. 데이터베이스 수준에서 수행할 수 있는 Null 허용 조건에 대한 유효성 검사입니다.
  9. 테스트 중인 데이터베이스가 비어 있을 때 모든 저장 프로시저 및 함수가 성공적으로 실행되었다는 사실을 검증합니다.
  10. 테스트 중인 애플리케이션의 요구 사항에 따라 저장 프로시저 모듈의 전체 통합을 검증합니다.

저장 프로시저를 테스트하는 데 유용한 데이터베이스 테스트 도구로는 LINQ, SP 테스트 도구 등이 있습니다.

트리거 테스트

  1. 트리거의 코딩 단계에서 필요한 코딩 규칙을 준수했는지 여부
  2. 각 DML 트랜잭션에 대해 실행된 트리거가 필수 조건을 충족했는지 확인합니다.
  3. 트리거가 실행된 후 데이터를 올바르게 업데이트하는지 여부
  4. 필요한 업데이트/삽입/삭제의 유효성 검사는 테스트 중인 애플리케이션 영역에서 기능을 트리거합니다.

데이터베이스 서버 검증

데이터베이스 서버 검증

  1. 비즈니스 요구 사항에 지정된 대로 데이터베이스 서버 구성을 확인합니다.
  2. 애플리케이션에 필요한 작업 수준만 수행하려면 필요한 사용자의 권한을 확인하세요.
  3. 데이터베이스 서버가 비즈니스 요구 사항 사양에 지정된 최대 허용 사용자 트랜잭션 수의 요구 사항을 충족할 수 있는지 확인하십시오.

기능적 데이터베이스 테스트

기능적 데이터베이스 테스트 최종 사용자 관점에서 데이터베이스의 기능적 요구 사항을 검증하는 데 사용되는 데이터베이스 테스트 유형입니다. 기능적 데이터베이스 테스트의 주요 목표는 데이터베이스와 관련된 최종 사용자가 수행한 트랜잭션 및 작업이 예상대로 작동하는지 여부를 테스트하는 것입니다.

데이터베이스 검증을 위해 준수해야 할 기본 조건은 다음과 같습니다.

  • 해당 필드에 NULL 값을 허용하는 반면 해당 필드는 필수입니까?
  • 각 필드의 길이가 충분한지 여부
  • 모든 유사한 필드가 테이블 전체에서 동일한 이름을 가지고 있습니까?
  • 데이터베이스에 계산된 필드가 있습니까?

이 특정 프로세스는 최종 사용자 관점에서 필드 매핑을 검증하는 것입니다. 이 특정 시나리오에서 테스터는 데이터베이스 수준에서 작업을 수행한 다음 관련 사용자 인터페이스 항목으로 이동하여 적절한 필드 검증이 수행되었는지 여부를 관찰하고 검증합니다.

그 반대의 조건, 즉, 먼저 테스터가 사용자 인터페이스에서 작업을 수행한 다음, 동일한 작업이 백엔드에서 검증되는 것도 수행해야 합니다.

데이터 무결성 및 일관성 확인

다음 확인이 중요합니다

  1. 데이터가 논리적으로 잘 정리되어 있는지?
  2. 테이블에 저장된 데이터가 올바른지, 비즈니스 요구 사항에 맞는지 여부
  3. 테스트 중인 애플리케이션에 불필요한 데이터가 존재합니까?
  4. 사용자 인터페이스에서 업데이트된 데이터에 대한 요구 사항에 따라 데이터가 저장되었는지 여부
  5. 테스트 중인 데이터베이스에 데이터를 삽입하기 전에 데이터에 TRIM 작업을 수행했습니까?
  6. 비즈니스 요구사항 사양에 따라 거래가 수행되었는지, 그 결과가 올바른지 여부
  7. 트랜잭션이 성공적으로 수행되었다면 데이터가 제대로 커밋되었는지 여부
  8. 최종 사용자가 트랜잭션을 성공적으로 실행하지 못한 경우 데이터가 성공적으로 롤백되었는지 여부
  9. 트랜잭션이 성공적으로 실행되지 않았고 해당 트랜잭션에 여러 개의 이기종 데이터베이스가 관련된 경우 데이터가 롤백되었는지 여부는 무엇입니까?
  10. 시스템 비즈니스 요구사항에 명시된 필수 설계 절차를 사용하여 모든 트랜잭션이 실행되었는지 여부

로그인 및 사용자 보안

로그인 및 사용자 보안 자격 증명의 유효성 검사에서는 다음 사항을 고려해야 합니다.

  1. 애플리케이션이 다음과 같은 경우 사용자가 애플리케이션을 더 이상 진행하지 못하도록 방해하는지 여부
  • 사용자 이름은 유효하지 않지만 비밀번호는 유효합니다.
  • 사용자 이름은 유효하지만 비밀번호는 유효하지 않습니다.
  • 잘못된 사용자 이름과 잘못된 비밀번호입니다.
  1. 사용자가 비즈니스 요구 사항에 따라 지정된 특정 작업만 수행할 수 있는지 여부
  2. 데이터가 무단 접근으로부터 보호되는지 여부
  3. 서로 다른 권한으로 생성된 서로 다른 사용자 역할이 있습니까?
  4. 모든 사용자가 비즈니스 사양에서 요구하는 대로 특정 데이터베이스에 대해 필요한 수준의 액세스 권한을 갖고 있는지 여부
  5. 비밀번호, 신용카드 번호와 같은 민감한 데이터가 암호화되어 있고 데이터베이스에 일반 텍스트로 저장되지 않았는지 확인하십시오. 모든 계정에는 복잡하고 쉽게 추측할 수 없는 비밀번호를 사용하는 것이 좋습니다.

비기능 테스트

비기능 테스트 데이터베이스 테스트의 맥락에서 비즈니스 요구 사항에 따라 다양한 범주로 분류될 수 있습니다. 부하 테스트, 스트레스 테스트, 보안 테스트, 사용성 테스트호환성 테스트, 등등. 성능 테스트 영역으로 그룹화할 수 있는 부하 테스트와 스트레스 테스트는 비기능 테스트 역할과 관련하여 두 가지 특정 목적을 제공합니다.

위험 정량화– 위험의 정량화는 이해관계자가 필요한 부하 수준에서 다양한 시스템 응답 시간 요구 사항을 확인하는 데 도움이 됩니다. 이것이 원래 의도이다. 품질 보증 일. 부하 테스트는 위험을 직접적으로 완화하지는 않지만 위험 식별 및 위험 정량화 프로세스를 통해 위험을 완화할 수정 기회와 수정 자극을 제공한다는 점에 유의해야 합니다.

최소 시스템 장비 요구 사항– 시스템이 이해관계자의 공식적으로 명시된 성능 기대치를 충족할 수 있도록 하는 최소 시스템 구성입니다. 이를 통해 불필요한 하드웨어, 소프트웨어 및 관련 소유 비용을 최소화할 수 있습니다. 이 특정 요구 사항은 전체 비즈니스 최적화 요구 사항으로 분류할 수 있습니다.

부하 테스트

모든 부하 테스트의 목적은 명확하게 이해되고 문서화되어야 합니다. 다음 유형의 구성은 필수입니다. 부하 테스트.

  1. 가장 자주 사용되는 사용자 트랜잭션은 효율적이지 않을 경우 다른 모든 트랜잭션의 성능에 영향을 미칠 가능성이 있습니다.
  2. 최소한 하나의 편집하지 않는 사용자 트랜잭션이 최종 테스트 모음에 포함되어야 하며, 이를 통해 해당 트랜잭션의 성능을 다른 보다 복잡한 트랜잭션과 차별화할 수 있습니다.
  3. 시스템의 핵심 목표를 촉진하는 더 중요한 트랜잭션이 포함되어야 합니다. 정의에 따라 이러한 트랜잭션 부하로 인한 오류가 가장 큰 영향을 미치기 때문입니다.
  4. 편집 가능한 거래가 하나 이상 포함되어야 합니다. 성능 이러한 거래는 다른 거래와 구별될 수 있습니다.
  5. 모든 예상 요구 사항에 대해 엄청난 수의 가상 사용자 하에서 최적의 응답 시간입니다.
  6. 다양한 기록을 가져오는 데 효과적인 시간입니다.

중요한 부하 테스트 도구는 다음과 같습니다. LoadRunner 전문가, 주자 승리 및 JMeter.

데이터베이스 스트레스 테스트란 무엇입니까?

데이터베이스 스트레스 테스트 부하가 큰 데이터베이스 시스템을 스트레스 테스트하여 어느 시점에서 오류가 발생하는 데 사용되는 테스트 방법입니다. 이는 데이터베이스 시스템의 고장 지점을 식별하는 데 도움이 됩니다. 자원의 과도한 사용을 방지하려면 적절한 계획과 노력이 필요합니다. 데이터 스트레스 테스트 고문 테스트 또는 피로 테스트라고도 합니다.

중요한 스트레스 테스트 도구는 다음과 같습니다. LoadRunner 전문가 그리고 JMeter.

데이터베이스 테스트 중 가장 일반적으로 발생하는 문제

A significant amount of overhead could be involved to determine the state of the database transactions

해결 방법 : 시간과 비용에 따른 문제가 나타나지 않도록 전반적인 프로세스 계획과 타이밍을 구성해야 합니다.

New test data have to be designed after cleaning up of the old test data.

해결 방법 : 테스트 데이터 생성을 위한 사전 계획과 방법론이 준비되어 있어야 합니다.

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

해결 방법 : SQL 쿼리의 유지 관리 및 지속적인 업데이트는 전체 테스트 프로세스의 일부가 되어야 하는 전체 테스트 프로세스의 중요한 부분입니다. 테스트 전략.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

해결 방법 : 품질과 전체 프로젝트 일정 기간 사이에 적절한 균형이 이루어져야 합니다.

데이터베이스 테스트와 관련된 신화 또는 오해

신화

Database Testing requires plenty of expertise and it is a very tedious job

현실: 소프트웨어 테스팅의 효과적이고 효율적인 데이터베이스 테스팅은 전체 애플리케이션에 장기적인 기능적 안정성을 제공하므로 이를 뒷받침하는 노력이 필요합니다.

Database testing adds extra work bottleneck

현실: 반대로 데이터베이스 테스트는 숨겨진 문제를 찾아 전체 애플리케이션 개선에 적극적으로 도움을 줌으로써 전체 작업에 더 많은 가치를 더합니다.

Database testing slows down the overall development process

현실: 상당한 양의 데이터베이스 테스트는 데이터베이스 애플리케이션의 전반적인 품질 향상에 도움이 됩니다.

Database testing could be excessively costly

현실: 데이터베이스 테스트에 대한 모든 지출은 애플리케이션의 장기적인 안정성과 견고성을 보장하는 장기 투자입니다. 따라서 데이터베이스 테스트에 대한 지출 또는 SQL 테스트가 필요합니다.

모범 사례

  • 메타데이터와 기능 데이터를 포함한 모든 데이터는 요구 사항 사양 문서의 매핑에 따라 유효성을 검사해야 합니다.
  • 검증 테스트 데이터 개발팀에 의해/개발팀과 협의하여 생성된 것은 검증되어야 합니다.
  • 수동 절차와 자동화 절차를 모두 사용하여 출력 데이터의 유효성을 검사합니다.
  • 요구되는 테스트 데이터 조건 생성을 위해 원인효과 그래프 기법, 등가분할 기법, 경계값 분석 기법 등 다양한 기법을 활용합니다.
  • 필수 데이터베이스 테이블에 대한 참조 무결성 검증 규칙도 검증해야 합니다.
  • 데이터베이스 일관성 검증을 위한 기본 테이블 값 선택은 매우 중요한 개념입니다. 필요한 모든 로그인 이벤트에 대해 로그 이벤트가 데이터베이스에 성공적으로 추가되었는지 여부
  • 예약된 작업이 적시에 실행됩니까?
  • 데이터베이스를 시기적절하게 백업합니다.

또한 확인- 데이터베이스 테스트 인터뷰 질문 및 답변