데이터베이스 테스트
Database testing![]() | 이 글에는 여러 가지 문제가 있다. 이 문제를 개선하거나 대화 페이지에서 토의하십시오. (이러한 템플릿 메시지를 제거하는 방법 및 시기 알아보기)
|
데이터베이스 테스트는 일반적으로 사용자 인터페이스(UI) 계층, 비즈니스 계층, 데이터 액세스 계층 및 데이터베이스 자체를 포함하는 계층화된 프로세스로 구성된다. UI 계층은 데이터베이스의 인터페이스 설계를 다루는 반면, 비즈니스 계층은 비즈니스 전략을 지원하는 데이터베이스를 포함한다.
목적들
서버에 있는 상호연결된 파일의 모음인 데이터베이스는 정보를 저장하며 동일한 유형의 데이터를 처리하지 못할 수 있다. 즉, 데이터베이스가 이질적일 수 있다. 그 결과, 대형 데이터베이스 시스템에서 많은 종류의 구현 및 통합 오류가 발생할 수 있으며, 이는 시스템의 성능, 신뢰성, 일관성 및 보안에 부정적인 영향을 미친다. 따라서 데이터베이스 관리 시스템의 AID 속성(원자성, 일관성, 격리, 내구성)을 만족시키는 데이터베이스 시스템을 얻기 위해서는 테스트가 중요하다.[1]
가장 중요한 계층 중 하나는 데이터 액세스 계층으로, 통신 프로세스 중에 데이터베이스를 직접 다룬다. 데이터베이스 테스트는 주로 이 계층에서 수행되며 제품 데이터베이스의 품질 관리 및 품질 보증과 같은 테스트 전략을 포함한다.[2] 이러한 서로 다른 계층에서 테스트는 데이터베이스 시스템의 일관성을 유지하기 위해 자주 사용되며, 가장 일반적으로 다음 예에서 볼 수 있다.
- 비즈니스 관점에서 데이터는 매우 중요하다. 구글이나 시만텍과 같은 데이터 저장과 관련된 회사들은 내구성과 일관성이 있는 데이터베이스 시스템을 갖추어야 한다. 데이터베이스를 먼저 일관성 있게 테스트하지 않고 삽입, 삭제, 업데이트 등의 데이터베이스 작업을 수행할 경우 전체 시스템의 작동이 중단될 위험이 있다.
- 어떤 회사들은 다른 종류의 데이터베이스를 가지고 있고, 또한 다른 목표와 미션을 가지고 있다. 언급된 목표를 달성하기 위해, 그들은 데이터베이스 시스템을 테스트할 필요가 있다.
- 현재 시험 접근방식은 개발자들이 데이터베이스를 공식적으로 시험하는 데 충분하지 않을 수 있다. 단, 데이터베이스 개발자는 통신 공백으로 인해 시험 프로세스가 느려질 가능성이 높기 때문에 이 접근방식은 충분히 효과적이지 않다. 별도의 데이터베이스 테스트 팀이 권장되는 것 같다.
- 데이터베이스 테스트는 주로 오류를 제거하기 위해 데이터베이스에서 오류를 찾는 것을 다룬다. 이것은 데이터베이스나 웹 기반 시스템의 품질을 향상시킬 것이다.
- 데이터베이스 테스트는 데이터베이스 충돌, 손상된 삽입, 삭제 또는 업데이트와 같은 다른 문제에 대처하기 위한 전략과 구별되어야 한다. 여기서 데이터베이스 리팩터링은 적용 가능한 진화 기법이다.
테스트 및 프로세스의 유형
그림에는 블랙박스 시험과 화이트박스 시험과 같이 서로 다른 데이터베이스 시험 방법 동안에 관련된 시험 영역이 표시된다.
블랙박스
블랙박스 테스트에는 인터페이스 테스트와 데이터베이스 통합이 수반되며, 여기에는 다음이 포함된다.
이러한 기법의 도움으로 데이터베이스의 기능을 철저히 테스트할 수 있다.
블랙박스 테스트의 장단점은 다음과 같다. 블랙박스 테스트에서의 테스트 케이스 생성은 상당히 간단하다. 그들의 세대는 소프트웨어 개발과 완전히 독립되어 있으며 개발의 초기 단계에서 이루어질 수 있다. 결과적으로, 프로그래머는 데이터베이스 응용프로그램을 설계하는 방법에 대해 더 잘 알고 있으며 디버깅하는 데 더 적은 시간을 사용한다. 블랙박스 테스트 케이스 개발 비용이 화이트박스 테스트 케이스 개발 비용보다 낮다. 블랙박스 테스트의 주요 단점은 얼마나 많은 프로그램이 테스트되고 있는지 알 수 없다는 점이다. 또한 특정 오류를 감지할 수 없다.[3]
화이트박스
화이트 박스 테스트는 주로 데이터베이스의 내부 구조를 다룬다. 사양 세부 정보는 사용자로부터 숨겨져 있다.
- 그것은 데이터베이스 리팩터링을 지원할 데이터베이스 트리거와 논리적 뷰의 테스트를 포함한다.
- 데이터베이스 기능, 트리거, 보기, SQL 조회 등의 모듈 테스트를 수행한다.
- 데이터베이스 테이블, 데이터 모델, 데이터베이스 스키마 등을 검증한다.
- 참조 무결성 규칙을 점검한다.
- 데이터베이스 일관성을 확인하기 위해 기본 테이블 값을 선택한다.
- 화이트 박스 테스트에 사용되는 기법은 조건 범위, 의사결정 범위, 진술 범위, 사이클로믹 복잡성이다.
데이터베이스 테스트에서 화이트박스 테스트의 주요 장점은 코딩 오류가 감지되어 데이터베이스의 내부 버그를 제거할 수 있다는 것이다. 화이트박스 테스트의 한계는 SQL 문장이 적용되지 않는다는 점이다.
WHODATE 접근법
데이터베이스 테스트를 위한 테스트 케이스를 생성하는 동안 SQL 문장의 의미론을 테스트 케이스에 반영할 필요가 있다. 이를 위해 WHite bOx Database Application Technology(WHODATE)라는 기술이 사용된다. 그림에서 보듯이 SQL 문은 GPL 문으로 독립적으로 변환되며, SQL 의미론을 포함하는 테스트 케이스를 생성하기 위한 전통적인 화이트 박스 테스트가 뒤따른다.[4]
4단계
- 고정장치 설정
- 테스트 실행
- 결과검증
- 해체하다
세트 고정장치는 시험을 시작하기 전에 데이터베이스의 초기 상태를 설명한다. 고정장치를 설정한 후 데이터베이스 동작은 정의된 시험 케이스에 대해 시험한다. 결과에 따라 시험사례를 수정하거나 그대로 보관한다. "경고" 단계는 시험을 종료하거나 다른 시험 사례를 계속하는 결과를 초래한다.[5]
성공적인 데이터베이스 테스트를 위해 각 단일 테스트에 의해 실행된 다음과 같은 워크플로가 일반적으로 실행된다.
- 데이터베이스 정리: 테스트 가능한 데이터가 데이터베이스에 이미 있는 경우, 데이터베이스를 비워야 한다.
- 고정장치 설정: 그런 다음 PHPUnit와 같은 도구를 고정장치 위에 반복하고 데이터베이스에 삽입한다.
- 테스트 실행, 결과 확인 및 해체: 데이터베이스를 비우도록 재설정하고 고정장치를 나열한 후 테스트를 실행하고 출력을 확인하십시오. 출력이 예상대로라면 해체 프로세스가 뒤따르고, 그렇지 않으면 시험을 반복한다.[citation needed]
기본기법
- SQL Query Analyzer는 Microsoft SQL Server를 사용할 때 유용한 도구다.[citation needed]
- 일반적으로 사용되는 한 가지 함수,[vague]
create_input_dialog["label"]
는 사용자 입력으로 출력을 검증하는 데 사용된다. - 자동화된 데이터베이스 테스트를 위한 양식 설계는 프런트엔드와 백엔드를 형성하여 데이터베이스 유지관리 작업자에게 유용하다.
- 데이터 로드 테스트:
- 데이터베이스 테스트에서는 원자성, 일관성, 격리, 내구성, 무결성, 트리거 실행 및 복구와 같은 문제가 종종 고려된다.
- 데이터베이스 테스트 설정은 데이터베이스 시스템이 예상된 삽입, 삭제 및 업데이트 작업에 따라 지속적으로 변경되기 때문에 유지 보수 비용이 많이 들고 복잡하다.
- 데이터베이스 트랜잭션의 상태를 결정하기 위해 추가적인 오버헤드가 수반된다.
- 데이터베이스 정리가 끝나면 새로운 테스트 케이스를 설계해야 한다.[citation needed]
- SQL 의미론을 데이터베이스 테스트 사례로 포함시키기 위해 SQL 문을 변환하는 SQL 생성기가 필요하다.
참고 항목
참조
- ^ Korth, Henry (2010). Database System Concepts. Macgraw-Hill. ISBN 978-0-07-352332-3.
- ^ Ambler, Scott (2003). Agile database Techniques: effective strategies for the agile software developer. wiley. ISBN 978-0-471-20283-7.
- ^ Pressman, Roger (1994). Software Tester: A Practitioner's Approach. McGraw-Hill Education. ISBN 978-0-07-707732-7.
- ^ Zhang, Yanchun (1999). Cooperative databases and applications '99: the proceedings of the Second International Symposium on Cooperative Database Systems for Advanced Applications (CODAS '99), Wollongong, Australia, March 27–28, 1999. Springer. ISBN 978-981-4021-64-7.
- ^ Kan, Stephen. Metrics & Models in Software Quality Engineering. Pearson Education. ISBN 978-81-297-0175-6.
- ^ "InfoWorld". InfoWorld Media Group, Inc. 15 Jan 1996.
- Ambler, Scott W. (2006). "Database Testing: How to Regression Test a Relational Database". Agiledata.org. Retrieved December 4, 2011. 외부 링크 위치
publisher=
(도움말) - Zeichick, Alan; et al. (August 14, 1989). How We Tested Integrated Software Packages. InfoWorld. Retrieved December 4, 2011.
외부 링크
- 8장. PHPUnit 매뉴얼의 데이터베이스 테스트
- 관계형 데이터베이스 테스트를 위한 데이터셋 생성
- SQL 테스트 적용 범위
- 지속성 테스트를 위해 JDBC를 조롱하는 Acolyte Framework