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

헤이 하브르!

제 이름은 Maxim Ponomarenko이고 Sportmaster의 개발자입니다. 저는 IT 분야에서 10년의 경력을 갖고 있습니다. 그는 수동 테스트 분야에서 경력을 시작한 후 데이터베이스 개발로 전환했습니다. 지난 4년간 테스트와 개발을 하면서 쌓은 지식을 바탕으로 DBMS 레벨에서 테스트를 자동화해왔습니다.

저는 Sportmaster 팀에 합류한 지 XNUMX년이 조금 넘었고 주요 프로젝트 중 하나에 대한 자동화된 테스트를 개발하고 있습니다. XNUMX월에 Sportmaster Lab의 사람들과 저는 크라스노다르에서 열린 컨퍼런스에서 "DBMS의 단위 테스트"라는 보고서를 발표했으며 이제 이를 여러분과 공유하고 싶습니다. 글이 너무 많아서 보고서를 두 개의 게시물로 나누기로 결정했습니다. 첫 번째에서는 자동 테스트와 일반적인 테스트에 대해 이야기하고, 두 번째에서는 단위 테스트 시스템과 그 적용 결과에 대해 더 자세히 설명하겠습니다.

첫째, 약간 지루한 이론입니다. 자동화된 테스트란 무엇입니까? 이는 소프트웨어를 사용하여 수행되는 테스트이며 현대 IT에서는 소프트웨어 개발에 점점 더 많이 사용되고 있습니다. 이는 기업이 성장하고 정보 시스템이 성장하며 이에 따라 테스트해야 할 기능의 양이 늘어나고 있기 때문입니다. 수동 테스트를 수행하는 데 점점 더 많은 비용이 들고 있습니다.

저는 두 달에 한 번씩 제품이 출시되는 대기업에서 근무했습니다. 동시에 2명의 테스터가 수동으로 기능을 확인하도록 하는 데 한 달이 소요되었습니다. 소규모 개발자 팀의 자동화 구현 덕분에 테스트 시간을 XNUMX년 반 만에 XNUMX주로 단축할 수 있었습니다. 우리는 테스트 속도를 높였을 뿐만 아니라 품질도 향상시켰습니다. 자동화된 테스트는 정기적으로 시작되며 항상 포함된 전체 검사 과정을 수행합니다. 즉, 인적 요소는 제외됩니다.

현대 IT의 특징은 개발자가 제품 코드를 작성하는 것뿐만 아니라 이 코드를 확인하는 단위 테스트도 작성해야 한다는 것입니다.

하지만 시스템이 주로 서버 로직을 기반으로 한다면 어떻게 될까요? 시장에는 보편적인 솔루션이나 모범 사례가 없습니다. 일반적으로 기업은 자체 작성 테스트 시스템을 만들어 이 문제를 해결합니다. 이것은 우리 프로젝트에서 생성된 자체 작성 자동화 테스트 시스템이며 보고서에서 이에 대해 이야기하겠습니다.

충성도 테스트

먼저 자동화된 테스트 시스템을 배포한 프로젝트에 대해 이야기해 보겠습니다. 우리 프로젝트는 Sportmaster 충성도 시스템입니다. (그런데 우리는 이미 이에 대해 썼습니다. 이 게시물).

회사 규모가 충분히 큰 경우 충성도 시스템에는 세 가지 표준 속성이 있습니다.

• 귀하의 시스템에 과부하가 걸릴 것입니다
• 귀하의 시스템에는 복잡한 컴퓨팅 프로세스가 포함되어 있습니다.
• 귀하의 시스템이 적극적으로 개선될 것입니다.

순서대로 가자... 모든 Sportmaster 브랜드를 종합적으로 고려하면 러시아, 우크라이나, 중국, 카자흐스탄 및 벨로루시에 1000개 이상의 매장이 있습니다. 이 매장에서는 매일 약 300건의 구매가 이루어집니다. 즉, 매초마다 000-3개의 검사가 시스템에 입력됩니다. 당연히 우리의 충성도 시스템은 높은 부하를 받습니다. 그리고 소프트웨어가 적극적으로 사용되기 때문에 최고 수준의 품질을 제공해야 합니다. 소프트웨어에 오류가 발생하면 막대한 금전적, 평판 및 기타 손실이 발생하기 때문입니다.

동시에 Sportmaster는 XNUMX개 이상의 다양한 프로모션을 진행합니다. 다양한 프로모션이 있습니다. 제품 프로모션이 있고, 요일 전용 프로모션이 있으며, 특정 매장과 관련된 프로모션이 있고, 영수증 금액에 대한 프로모션이 있고, 상품 수에 대한 프로모션이 있습니다. 일반적으로 나쁘지 않습니다. 고객에게는 구매 시 사용되는 보너스와 프로모션 코드가 있습니다. 이 모든 것은 주문을 계산하는 것이 매우 사소한 작업이라는 사실로 이어집니다.

주문 처리를 구현하는 알고리즘은 정말 끔찍하고 복잡합니다. 그리고 이 알고리즘을 변경하는 것은 매우 위험합니다. 겉보기에는 사소해 보이는 변화가 전혀 예측할 수 없는 결과를 초래할 수 있는 것처럼 보였습니다. 그러나 자동화를 위한 최고의 후보는 바로 이러한 복잡한 컴퓨팅 프로세스, 특히 중요한 기능을 구현하는 프로세스입니다. 수십 개의 유사한 사례를 직접 확인하는 것은 시간이 많이 걸립니다. 그리고 프로세스의 진입점은 변경되지 않으므로 한 번만 설명하면 자동 테스트를 신속하게 생성하고 기능이 작동할 것이라는 확신을 가질 수 있습니다.

우리 시스템이 적극적으로 사용되기 때문에 비즈니스는 귀하에게 새로운 것을 원하고 시대에 부응하며 고객 지향적이 될 것입니다. 우리 로열티 시스템에서는 XNUMX개월마다 릴리스가 출시됩니다. 이는 두 달에 한 번씩 전체 시스템에 대한 완전한 회귀 작업을 수행해야 함을 의미합니다. 동시에 현대 IT와 마찬가지로 당연히 개발이 개발자에서 프로덕션으로 즉시 진행되지는 않습니다. 이는 개발자의 회로에서 시작되어 테스트 벤치, 릴리스, 승인을 차례로 통과한 다음 생산에 들어갑니다. 최소한 테스트 및 릴리스 회로에서는 전체 시스템에 대한 완전한 회귀를 수행해야 합니다.

설명된 속성은 거의 모든 로열티 시스템의 표준입니다. 우리 프로젝트의 특징에 대해 이야기 해 봅시다.

기술적으로 우리 충성도 시스템 논리의 90%는 서버 기반이며 Oracle에서 구현됩니다. Delphi에는 자동화된 작업장 관리자 기능을 수행하는 클라이언트가 노출되어 있습니다. 외부 애플리케이션(예: 웹 사이트)에 대한 웹 서비스가 노출되어 있습니다. 따라서 자동화된 테스트 시스템을 배포한다면 Oracle에서 배포하는 것이 매우 논리적입니다.

Sportmaster의 충성도 시스템은 7년 넘게 존재해 왔으며 단일 개발자에 의해 만들어졌습니다. 이 7년 동안 우리 프로젝트에 참여한 평균 개발자 수는 3-4명이었습니다. 하지만 지난 10년 동안 우리 팀은 크게 성장했고 현재는 XNUMX명이 프로젝트에 참여하고 있습니다. 즉, 일반적인 작업, 프로세스, 아키텍처에 익숙하지 않은 사람들이 프로젝트에 참여합니다. 그리고 실수를 놓칠 위험도 증가합니다.

이 프로젝트는 직원 단위로 전담 테스터가 없다는 것이 특징입니다. 물론 테스트도 있지만 비즈니스 고객, 사용자와의 커뮤니케이션, 시스템 요구 사항 개발 등과 같은 다른 주요 책임 외에도 분석가가 테스트를 수행합니다. 기타... 테스트가 매우 높은 품질로 수행된다는 사실에도 불구하고(일부 분석가가 이 보고서의 시선을 사로잡을 수 있으므로 특히 언급하는 것이 적절함) 전문화 및 한 가지에 대한 집중의 효과는 취소되지 않았습니다. .

위의 모든 사항을 고려하면, 제공되는 제품의 품질을 향상하고 개발 시간을 단축하기 위해 프로젝트에 대한 테스트를 자동화한다는 아이디어는 매우 논리적으로 보입니다. 그리고 충성도 시스템이 존재하는 여러 단계에서 개별 개발자는 단위 테스트를 통해 코드를 다루려고 노력했습니다. 전반적으로 모든 사람이 자신의 아키텍처와 방법을 사용하는 상당히 분리된 프로세스였습니다. 최종 결과는 단위 테스트에 공통적이었습니다. 테스트가 개발되고 한동안 사용되었으며 버전이 지정된 파일 저장소에 저장되었지만 어느 시점에서 실행이 중지되고 잊혀졌습니다. 우선, 이는 테스트가 프로젝트가 아닌 특정 수행자에게 더 많이 묶여 있다는 사실 때문이었습니다.

utPLSQL이 구출됩니다

스티븐 포이어스타인(Stephen Feuerstein)에 대해 아는 것이 있나요?

그는 자신의 경력 중 오랜 시간을 Oracle 및 PL/SQL 작업에 바쳤으며 이 주제에 관해 상당히 많은 저작물을 작성한 똑똑한 사람입니다. 그의 유명한 책 중 하나는 “Oracle PL/SQL. 전문가용." utPLSQL 솔루션, 즉 Oracle PL/SQL용 유닛 테스트 프레임워크를 개발한 사람은 Stephen이었습니다. utPLSQL 솔루션은 2016년에 만들어졌지만 계속해서 활발하게 작업되고 있으며 새 버전이 출시되고 있습니다. 보고 시점 기준 최신 버전은 24년 2019월 XNUMX일로 거슬러 올라갑니다.
그것은 무엇입니까? 이것은 별도의 오픈 소스 프로젝트입니다. 예제와 문서를 포함하여 무게는 몇 메가바이트입니다. 물리적으로 이는 단위 테스트를 구성하기 위한 패키지 및 테이블 세트가 있는 ORACLE 데이터베이스의 별도 스키마입니다. 설치에는 몇 초 정도 걸립니다. utPLSQL의 특징은 사용 용이성입니다.
전체적으로 utPLSQL은 단위 테스트를 실행하기 위한 메커니즘입니다. 여기서 단위 테스트는 특정 규칙을 따르는 조직의 일반적인 Oracle 배치 프로시저로 이해됩니다. 실행 외에도 utPLSQL은 모든 테스트 실행에 대한 로그를 저장하고 내부 보고 시스템도 갖추고 있습니다.

이 기술을 사용하여 구현된 단위 테스트 코드의 예를 살펴보겠습니다.

따라서 화면에는 단위 테스트를 통해 일반적인 패키지 사양에 대한 코드가 표시됩니다. 필수 요구 사항은 무엇입니까? 패킷 앞에는 "utp_"가 붙어야 합니다. 테스트가 포함된 모든 프로시저에는 정확히 동일한 접두사가 있어야 합니다. 패키지에는 "utp_setup" 및 "utp_teardown"이라는 두 가지 표준 프로시저가 포함되어야 합니다. 첫 번째 절차는 각 단위 테스트를 다시 시작하여 호출되고, 두 번째 절차는 실행 후 호출됩니다.

"utp_setup"은 일반적으로 테스트 데이터 생성과 같은 단위 테스트를 실행하기 위해 시스템을 준비합니다. "utp_teardown" - 반대로 모든 것이 원래 설정으로 돌아가고 실행 결과가 재설정됩니다.

다음은 입력된 고객 전화번호가 로열티 시스템의 표준 형식으로 정규화되었는지 확인하는 가장 간단한 단위 테스트의 예입니다. 단위 테스트를 사용하여 프로시저를 작성하는 방법에 대한 필수 표준은 없습니다. 일반적으로 테스트 중인 시스템의 메서드를 호출하고 이 메서드에서 반환된 결과를 참조 결과와 비교합니다. 표준 utPLSQL 방법을 통해 참조 결과와 얻은 결과를 비교하는 것이 중요합니다.

단위 테스트에는 여러 개의 검사가 포함될 수 있습니다. 예제에서 볼 수 있듯이 우리는 전화번호를 정규화하고 각 호출 후 결과를 평가하기 위해 테스트된 메서드를 XNUMX번 연속 호출합니다. 단위 테스트를 개발할 때 어떤 방식으로든 시스템에 영향을 주지 않는 검사가 있다는 점을 고려해야 하며, 일부 검사 후에는 시스템의 원래 상태로 롤백해야 합니다.
예를 들어 제시된 단위 테스트에서는 입력 전화번호의 형식을 간단히 지정하며 이는 충성도 시스템에 어떤 영향도 미치지 않습니다.

그리고 새 클라이언트를 생성하는 방법을 사용하여 단위 테스트를 작성하면 각 테스트 후에 시스템에 새 클라이언트가 생성되어 이후 테스트 실행에 영향을 미칠 수 있습니다.

이것이 단위 테스트가 실행되는 방식입니다. 가능한 시작 옵션에는 두 가지가 있습니다. 특정 패키지에서 모든 단위 테스트를 실행하거나 특정 패키지에서 특정 단위 테스트를 실행하는 것입니다.

내부 보고 시스템의 예는 다음과 같습니다. 단위 테스트 결과에 따라 utPLSQL은 작은 보고서를 작성합니다. 여기에는 각 특정 검사에 대한 결과와 단위 테스트의 전체 결과가 표시됩니다.

자동 테스트의 6가지 규칙

충성도 시스템의 자동화된 테스트를 위한 새로운 시스템을 만들기 전에 경영진과 함께 향후 자동화된 테스트가 준수해야 하는 원칙을 결정했습니다.

1. 자동 테스트는 효과적이어야 하며 유용해야 합니다. 우리에게는 분명히 언급할 필요가 있는 훌륭한 개발자들이 있습니다. 그들 중 일부는 아마도 이 보고서를 보고 훌륭한 코드를 작성할 것이기 때문입니다. 그러나 그들의 훌륭한 코드조차도 완벽하지 않으며 오류를 계속해서 포함하고 있으며 앞으로도 계속 오류를 포함할 것입니다. 이러한 오류를 찾으려면 자동 테스트가 필요합니다. 그렇지 않다면 잘못된 자동 테스트를 작성하고 있거나 원칙적으로 개발되지 않는 사각지대에 도달한 것입니다. 두 경우 모두 우리는 뭔가 잘못하고 있으며 우리의 접근 방식은 전혀 의미가 없습니다.
2. 자동 테스트를 사용해야 합니다. 소프트웨어 제품을 작성하는 데 많은 시간과 노력을 들이고 이를 저장소에 저장한 다음 잊어버리는 것은 의미가 없습니다. 테스트는 가능한 한 정기적으로 실행되어야 합니다.
3. 자동 테스트는 안정적으로 작동해야 합니다. 시간, 발사대 및 기타 시스템 설정에 관계없이 테스트 실행은 동일한 결과로 이어져야 합니다. 일반적으로 이는 자동 테스트가 고정된 시스템 설정을 사용하여 특수 테스트 데이터로 작동한다는 사실에 의해 보장됩니다.
4. 자동 테스트는 프로젝트에 허용되는 속도로 작동해야 합니다. 이 시간은 각 시스템마다 개별적으로 결정됩니다. 어떤 사람들은 하루 종일 일할 여유가 있는 반면, 어떤 사람들은 단 몇 초 만에 일을 하는 것이 중요하다고 생각합니다. 우리 프로젝트에서 우리가 달성한 속도 표준은 조금 후에 말씀드리겠습니다.
5. 자동 테스트 개발은 유연해야 합니다. 단순히 이전에 테스트를 수행하지 않았다는 이유나 다른 이유로 인해 기능 테스트를 거부하는 것은 바람직하지 않습니다. utPLSQL은 개발에 어떠한 제한도 두지 않으며, Oracle은 원칙적으로 다양한 구현을 허용합니다. 대부분의 문제에는 해결책이 있습니다. 단지 시간과 노력의 문제일 뿐입니다.
6. 배포 가능성. 테스트를 실행해야 하는 여러 스탠드가 있습니다. 각 스탠드에서 데이터 덤프는 언제든지 업데이트될 수 있습니다. 전체 또는 부분 설치를 어려움 없이 수행할 수 있도록 자동 테스트를 통해 프로젝트를 수행해야 합니다.

그리고 며칠 후 두 번째 게시물에서는 우리가 무엇을 했고 어떤 결과를 얻었는지 말씀드리겠습니다.

출처 : habr.com