DBMS의 단위 테스트 - Sportmaster에서 수행하는 방법, XNUMX부

첫 번째 부분 - 여기에.

상황을 상상해보십시오. 새로운 기능을 개발하는 작업에 직면해 있습니다. 선배들의 경험이 있습니다. 도덕적 의무가 없다고 가정하면 어떻게 하시겠습니까?

대부분의 경우 이전 개발은 모두 잊혀지고 모든 것이 다시 시작됩니다. 다른 사람의 코드를 파헤치는 것을 좋아하는 사람은 없습니다. 시간이 있다면 자신만의 시스템을 만들어 보는 것은 어떨까요? 이것은 일반적인 접근 방식이며 많은 측면에서 정확합니다. 그러나 우리 프로젝트에서 우리는 다르게 행동했습니다. 우리는 이전 제품의 utPLSQL에 대한 단위 테스트 개발을 기반으로 미래의 자동화된 테스트 시스템을 기반으로 여러 병렬 방향으로 작업했습니다.

1. 이전 단위 테스트를 복원합니다. 복구는 충성도 시스템의 기존 상태에 대한 테스트 적응 및 utPLSQL 표준에 대한 테스트 적응을 의미합니다.
2. 이해를 통해 문제를 해결하고 정확히 어떤 방법과 프로세스를 자동 테스트로 다뤘습니다. 이 정보를 머릿속에 저장하거나 자동 테스트 코드를 기반으로 직접 결론을 도출해야 합니다. 그래서 카탈로그를 만들기로 했습니다. 각 자동 테스트에 고유한 니모닉 코드를 할당하고, 설명을 만들고, 설정을 수정했습니다(예: 어떤 조건에서 실행해야 하는지 또는 테스트 실행이 실패할 경우 어떻게 해야 하는지). 본질적으로 자동 테스트에 대한 메타데이터를 채우고 이 메타데이터를 utPLSQL 스키마의 표준 테이블에 배치했습니다.
3. 확장 전략의 정의, 즉 자동 테스트를 통해 확인해야 하는 기능 선택. 우리는 세 가지에 주목하기로 결정했습니다. 시스템의 새로운 개선 사항, 생산에서 발생하는 사고, 시스템의 핵심 프로세스입니다. 따라서 우리는 릴리스와 동시에 개발하여 더 높은 품질을 보장하고 동시에 회귀 범위를 확장하며 중요한 위치에서 시스템의 안정성을 보장합니다. 첫 번째 병목 현상은 수표로 할인 및 보너스를 분배하는 과정이었습니다.
4. 당연히 우리는 새로운 자동 테스트를 개발하기 시작했습니다. 첫 번째 릴리스 작업 중 하나는 충성도 시스템의 미리 정의된 샘플의 성능을 평가하는 것이었습니다. 우리 프로젝트에는 조건에 따라 클라이언트를 선택하는 엄격하게 고정된 SQL 쿼리 블록이 있습니다. 예를 들어, 특정 도시에서 마지막으로 구매한 모든 고객 목록 또는 평균 구매 금액이 특정 값 이상인 고객 목록을 가져옵니다. 자동 테스트를 작성하고 미리 정의된 샘플을 확인하고 벤치마크 성능 매개변수를 수정했으며 추가로 로드 테스트를 받았습니다.
5. 자동 테스트 작업은 편리해야 합니다.. 가장 일반적인 두 가지 작업은 자동 테스트 실행과 테스트 데이터 생성입니다. 이것이 우리 시스템에 두 개의 보조 모듈인 발사 모듈과 데이터 생성 모듈이 나타난 방식입니다.

   시작 프로그램은 하나의 입력 텍스트 매개변수가 있는 하나의 일반 프로시저로 표시됩니다. 매개변수로 자동 테스트 니모닉 코드, 패키지 이름, 테스트 이름, 자동 테스트 설정 또는 예약어를 전달할 수 있습니다. 절차는 조건을 충족하는 모든 자동 테스트를 선택하고 실행합니다.

   데이터 생성 모듈은 테스트 중인 시스템의 각 개체(데이터베이스의 테이블)에 대해 데이터를 삽입하는 특수 절차가 생성된 패키지로 제공됩니다. 이 절차에서 기본값은 최대로 채워져 문자 그대로 손가락 클릭으로 객체를 생성합니다. 그리고 사용 편의성을 위해 생성된 데이터에 대한 템플릿이 생성되었습니다. 예를 들어 테스트 전화와 완료된 구매로 특정 연령의 클라이언트를 생성합니다.

6. 자동 테스트는 시스템에 적합한 시간 내에 실행되어야 합니다. 따라서 결과에 대한 보고서가 생성되어 회사 메일로 전체 개발 팀에 전송되는 결과를 기반으로 매일 밤 발사가 조직되었습니다. 이전 자동 테스트를 복원하고 새 테스트를 만든 후 총 실행 시간은 30분이었습니다. 출시가 업무 외 시간에 이루어 졌기 때문에 이러한 성능은 모든 사람에게 적합했습니다.

   하지만 작업 속도를 최적화하기 위해 노력해야 했습니다. 생산 로열티 시스템은 밤에 업데이트됩니다. 릴리스 중 하나의 일부로 밤에 긴급하게 변경해야 했습니다. 오전 5시에 자동 테스트 결과를 XNUMX 분 동안 기다려도 릴리스 책임자가 행복해지지 않았고 (Alexei Vasyukov에게 열렬한 인사를 전합니다!) 다음날 아침 우리 시스템에 대해 따뜻한 말을 많이했습니다. 하지만 결과적으로 XNUMX분 작업 기준이 정해졌습니다.

   성능 속도를 높이기 위해 두 가지 방법을 사용했습니다. 충성도 시스템의 아키텍처로 인해 매우 편리하기 때문에 세 개의 병렬 스레드에서 자동 테스트를 실행하기 시작했습니다. 그리고 자동 테스트가 자체 테스트 데이터를 생성하지 않고 시스템에 적합한 것을 찾으려고 할 때 접근 방식을 포기했습니다. 변경 후 총 작동 시간이 3-4분으로 단축되었습니다.

7. 자동 테스트가 있는 프로젝트는 다양한 스탠드에 배포할 수 있어야 합니다. 여정 초기에 자체 배치 파일을 작성하려는 시도가 있었지만 자체 작성 자동 설치가 완전히 공포라는 것이 분명해졌고 우리는 산업용 솔루션으로 전환했습니다. 프로젝트에 직접 많은 코드가 있고(우선 자동 테스트 코드를 저장함) 데이터가 매우 적기 때문에(메인 데이터는 자동 테스트에 대한 메타데이터임) 프로젝트에 통합하기가 매우 쉬운 것으로 나타났습니다. 리퀴베이스 프로젝트.

   데이터베이스 스키마 변경 사항을 추적, 관리 및 적용하기 위한 오픈 소스 데이터베이스 독립 라이브러리입니다. 명령줄 또는 Apache Maven과 같은 프레임워크를 통해 관리됩니다. Liquibase의 작동 원리는 매우 간단합니다. 대상 서버에 롤업해야 하는 변경 사항 또는 스크립트와 이러한 변경 사항을 설치해야 하는 순서와 매개 변수를 결정하는 제어 파일로 구성된 특정 방식으로 구성된 프로젝트가 있습니다.

   DBMS 수준에서 Liquibase가 롤백 로그를 저장하는 특수 테이블이 생성됩니다. 각 변경에는 프로젝트와 데이터베이스의 상태 간에 매번 비교되는 계산된 해시가 있습니다. Liquibase 덕분에 시스템 변경 사항을 모든 회로에 쉽게 롤아웃할 수 있습니다. 자동 테스트는 이제 테스트 및 릴리스 회로와 컨테이너(개발자의 개인 회로)에서 실행됩니다.

그럼, 단위 테스트 시스템을 적용한 결과에 대해 이야기해 봅시다.

1. 물론 우선 우리는 더 나은 소프트웨어를 개발하기 시작했다고 확신합니다. 자동 테스트는 매일 실행되며 릴리스마다 수십 개의 버그를 찾습니다. 또한 이러한 오류 중 일부는 우리가 실제로 변경하고자 하는 기능과 간접적으로만 관련되어 있습니다. 이러한 오류가 수동 테스트에서 발견되었다는 강한 의심이 있습니다.
2. 팀은 특정 기능이 올바르게 작동한다는 확신을 얻었습니다. 우선 이것은 우리의 중요한 프로세스와 관련이 있습니다. 예를 들어, 지난 XNUMX개월 동안 수표로 할인 및 보너스를 배포하는 데 문제가 없었습니다.
3. 테스트 반복 횟수를 줄이는 데 성공했습니다. 새로운 기능에 대한 자동 테스트가 작성되었기 때문에 분석가와 시간제 테스터는 더 높은 품질의 코드를 얻습니다. 이미 확인되었습니다.
4. 자동화 테스트 개발의 일부는 개발자가 사용합니다. 예를 들어 컨테이너의 테스트 데이터는 개체 생성 모듈을 사용하여 생성됩니다.
5. 개발자가 자동 ​​테스트 시스템을 "수용"하도록 개발하는 것이 중요합니다. 이것이 중요하고 유용하다는 이해가 있습니다. 그리고 내 자신의 경험에 비추어 볼 때 이것은 사실과 거리가 멀다고 말할 수 있습니다. 자동 테스트를 작성하고 유지 관리 및 개발하고 결과를 분석해야 하며 종종 이러한 시간 비용은 그만한 가치가 없습니다. 프로덕션으로 이동하여 문제를 처리하는 것이 훨씬 쉽습니다. 우리나라에서는 개발자가 줄을 서서 자동 테스트로 기능을 커버하도록 요청합니다.

다음 단계

자동화된 테스트 프로젝트의 개발 계획에 대해 이야기해 봅시다.

물론 Sportmaster 로열티 시스템이 살아 있고 계속 발전하는 한 자동 테스트도 거의 끝없이 발전할 수 있습니다. 따라서 개발의 주요 방향은 커버리지 영역의 확장입니다.

자동 테스트의 수가 증가함에 따라 작업의 총 시간은 꾸준히 증가할 것이며 다시 성능 문제로 돌아가야 합니다. 아마도 솔루션은 병렬 스레드 수를 늘리는 것입니다.

그러나 이것은 명백한 개발 방법입니다. 보다 사소하지 않은 것에 대해 이야기하는 경우 다음을 강조합니다.

1. 이제 자동 테스트는 DBMS 수준에서 관리됩니다. 성공적인 작업을 위해서는 PL/SQL에 대한 지식이 필요합니다. 필요한 경우 시스템 관리(예: 메타데이터 시작 또는 생성)는 Jenkins 또는 이와 유사한 것을 사용하는 일종의 관리자 패널에서 수행할 수 있습니다.
2. 모두가 양적 및 질적 지표를 좋아합니다. 자동 테스트의 경우 이러한 범용 지표는 코드 적용 범위 또는 코드 적용 메트릭입니다. 이 표시기를 사용하여 테스트 중인 시스템 코드의 몇 퍼센트가 자동 테스트에 포함되는지 확인할 수 있습니다. 버전 12.2부터 Oracle은 이 메트릭을 계산하는 기능을 제공하고 표준 DBMS_PLSQL_CODE_COVERAGE 패키지 사용을 제안합니다.

   당사의 자동 테스트 시스템은 출시된 지 1년이 조금 넘었으며 이제 적용 범위를 평가할 때가 되었습니다. 내 마지막 프로젝트(Sportmaster가 아닌 프로젝트)에서 이런 일이 일어났습니다. 자동 테스트 작업 10년 후 경영진은 우리가 다루는 코드의 몇 퍼센트를 평가하는 작업을 설정했습니다. 적용 범위가 20% 이상이면 경영진이 만족할 것입니다. 저희 개발자들은 XNUMX% 정도의 결과를 예상했습니다. 우리는 코드 커버리지를 엉망으로 만들고, 그것을 측정했고, XNUMX%를 얻었습니다. 축하하기 위해 상을 받으러 갔지만 어떻게 갔는지, 나중에 어디로 갔는지는 전혀 다른 얘기다.

3. 자동 테스트는 노출된 웹 서비스를 테스트할 수 있습니다. 오라클은 당신이 이것을 할 수 있도록 허용하며, 우리는 더 이상 많은 문제에 직면하지 않을 것입니다.
4. 물론 자동화 테스트 시스템을 다른 프로젝트에 적용할 수도 있습니다. 우리가 받은 솔루션은 보편적이며 Oracle만 사용하면 됩니다. 다른 Sportmaster 프로젝트에 대한 자동 테스트에 관심이 있다고 들었습니다.

조사 결과

요약해보자. Sportmaster의 로열티 시스템 프로젝트에서 우리는 자동 테스트 시스템을 구현했습니다. 그 기반은 Stephen Feuerstein의 utPLSQL 솔루션입니다. utPLSQL 주변에는 자동 테스트 및 자체 작성 보조 모듈(런처, 데이터 생성 모듈 등)을 위한 코드가 있습니다. 자동 테스트는 매일 실행되며 가장 중요한 것은 작업과 이점입니다. 우리는 더 높은 품질의 소프트웨어를 출시하기 시작했다고 확신합니다. 동시에 결과 솔루션은 보편적이며 Oracle DBMS에서 자동화된 테스트를 구성해야 하는 모든 프로젝트에 자유롭게 적용할 수 있습니다.

PS 이 기사는 그다지 구체적이지 않은 것으로 판명되었습니다. 텍스트가 많고 기술적인 예가 거의 없습니다. 주제가 전 세계적으로 흥미롭다면 계속할 준비가 되어 있고 지난 XNUMX개월 동안 변경된 사항을 알려주고 코드 예제를 제공하는 연속으로 돌아올 준비가 되었습니다.

앞으로 강조해야 할 사항이나 공개가 필요한 질문이 있으면 의견을 작성하십시오.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

이에 대해 더 써볼까요?

• 예 물론

• 고맙지 만 사양 할게

12명의 사용자가 투표했습니다. 4명의 사용자가 기권했습니다.

출처 : habr.com