Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

소프트웨어 테스트 기본 원칙들과 필수 도서


Recommended Posts

Hagop Panosian의 "Software Testing Fundamentals & a Must-Have Book"를 번역했습니다. (원문 작성: 2023년 3월, 최종 번역: 2023년 12월)

소프트웨어 테스트는 소프트웨어 개발 라이프사이클, 즉 SDLC(계획-설계-구현-테스트-배포-유지관리)의 핵심 중 하나이다. SDLC의 목표는 개발자가 소프트웨어를 비용 효율적으로 구축하고 관련 위험을 최소화 하는 동시에 출시된 제품이 최종 사용자의 기대를 충족하도록 돕는 것이다.

소프트웨어 테스트의 부분과 유형

소프트웨어 개발자로서 코드를 게시하기 전에 코드를 테스트하는 것은 개발 과정에서 상당한 부분을 차지한다. 안정적이고 신뢰할 수 있으며, 기능적이고 안전한 소프트웨어는 고객 만족도를 높이고 비즈니스를 지탱하며 좋은 평판을 얻는데 도움이 된다. 

소프트웨어 테스트 프로젝트의 계획과 실행은 다소 어려울 수 있다.  소프트웨어 테스트에서 발생할 수 있는 문제를 해결하는 가장 좋은 방법은 효과적인 계획과 적절한 도구, 방법론의 선택이다.

소프트웨어 테스트에 대한 전략과 접근 방식은 언제나 테스트하는 대상에 따라 영향을 받겠지만, 모든 소프트웨어 테스트 프로젝트에는 공통된 측면이 존재한다. 성공적인 소프트웨어 테스트 프로젝트가 효과적으로 관리해야 하는 가장 중요한 다섯 가지 측면은 다음과 같다:

명확한 목표(들)

첫 번째 단계로 테스트 목표와 요구사항을 명확하게 정의하면 나머지 접근 방식이 정리된다. 여러분의 소프트웨어가 사용자에게 제공하는 목표는 무엇이며, 전달하려는 경험은 어떤 것인가? 명확한 목표는 성능, 기능, 보안과 같이 개선하려는 소프트웨어의 특정 영역에 중점을 둔 테스트 프로젝트를 사용자 정의하는 데 도움이 된다. 

올바른 접근 방식

소프트웨어 테스트에는 여러 가지 접근 방식이 있으며, 프로젝트에 맞는 적절한 테스트 접근 방식을 선택하면 예상한 결과를 얻을 수 있다. 소프트웨어 테스트는 수동, 자동, 혹은 이 둘의 조합일 수 있다. 소프트웨어의 복잡성, 보유한 도구, 그리고 테스트 팀의 기술을 통해 어떤 접근 방식이 가장 효과적인지 결정할 수 있다.

상세 계획

이제 어떤 접근 방식을 취할지 결정했다면, 다음 단계는 소프트웨어 테스트 프로젝트를 자세히 계획하는 것이다. 잘 준비된 계획에는 적합한 테스트 시나리오, 테스트 케이스 및 테스트 데이터뿐만 아니라 필요한 도구와 기술도 포함된다.

철저한 실행

실행에는 테스트 계획 구현, 문제 발생 시 추적, 결과 및 인사이트 문서화 등이 포함된다. 적절한 문서화의 중요성은 아무리 강조해도 지나치지 않는다. 이는 단일 테스트 프로젝트를 넘어서 시간이 지남에 따라 소프트웨어를 지속적으로 개선하려는 목표에 필수적이기 때문이다.

정기적인 회귀 테스트(Regression Testing)

소프트웨어 테스트 프로세스의 마지막 부분은 회귀 테스트(regression testing)이다.  회귀 테스트는 업데이트, 변경, 개선 사항이 적용된 후에도 애플리케이션이 여전히 예상대로 계속 작동하는지 확인하는 것이다.

회귀 테스트는 새로운 기능을 도입하거나 버그를 수정할 때  애플리케이션 기능의 안정성과 기능이 유지되도록 하는데 필수적인 요구 사항이다. 

궁극적인 목표-사용자에게 고품질 소프트웨어 제공

때로는 소프트웨어 테스트가 어려울 수 있지만, 위에 나열된 다섯 가지 구성 요소로 소프트웨어 테스트 프로세스를 나누면 훨씬 덜 복잡해지며, 고품질 서비스 제공이라는 궁극적인 목표에 훨씬 더 가까이 다가갈 수 있는 효과적인 테스트 전략을 개발하는 데 도움이 된다. 

이 기고 안에 있는 내용

이번 글에서는 소프트웨어 테스트의 기본 사항을 좀 더 자세히 살펴 볼 것이다. 또 MVP인 William Meyer의 훌륭한 저서와 이를 이용해 소프트웨어 게시, 마이그레이션 및 현대화 프로젝트에 대한 스트레스 없는 테스트를 구현하는 방법을 살펴 본다.

소프트웨어 테스트: 올바른 목표 설정

적절한 목표를 설정하는 것은 소프트웨어 테스트 프로젝트의 첫 번째 중요한 단계이며, 결과의 품질에 직접적인 영향을 미친다.  

고품질 소프트웨어를 출시하려면 개발 작업물이 최종 사용자에게 도달하기 전에 몇 가지 주요 목표에 대해 테스트 해야 하며, 첫 번째 목표는 개발한 애플리케이션이 예상대로 작동하는지 확인하는 것이다. 

즉, 테스트는 애플리케이션이 해야 하는 작업을 수행하는지 여부와 최종 사용자가 기대하는 작업을 수행하는지 확인하는 것으로 시작된다. 이 단계에서는 성능의 기술적 측면과 애플리케이션의 사용자 친화성을 살펴보고 애플리케이션이 실패할 수 있는 부분과 사용자가 불만족하는 부분을 식별한다.

다음으로, 애플리케이션이 보안면에서 안전한지 확인하는 소프트웨어 테스트를 구현한다. 보안은 장기적인 지속 가능성과 고객 만족에 가장 중요하며 개발자들에게는 항상 주요한 관심사이다.

소프트웨어 보안 테스트는 애플리케이션의 취약점에 집중하고 이를 수정하는 방법을 일컫는 것이다.  애플리케이션 구축의 다른 모든 측면과 마찬가지로 소프트웨어 보안의 안전성 개선은 진화하는 위협과 취약성을 대응하기 위한 지속적인 업데이트와 테스트 과정이다. 

신뢰성은 애플리케이션 테스트에서 세 번째 기준이 되겠다.  신뢰성이란 애플리케이션이 다양한 조건에서도 완벽하게 작동하는 것을 의미한다. 신뢰성 테스트는 애플리케이션이 충돌하거나 예상대로 수행되지 않는 조건을 식별하고 이러한 특정 조건에서 기능을 개선하기 위한 조치를 취하는 것을 목표로 한다.

그 다음은 확장성이다. 증가하는 사용량, 트래픽 및 작업 부하에 대한 테스트를 통해 애플리케이션이 부담을 느끼고 중단될 수 있는 지점을 신속하게 식별할 수 있다. 확장성 테스트와 이어지는 개선 작업은 최소한의 수용 가능한 기준에 대한 상황에서 사용 증가에 따른 성능을 측정하도록 설계되었다.

요약하면, 소프트웨어 테스트는 기능, 보안, 안정성, 확장성에 대한 기준과 비교하여 애플리케이션을 평가한다. 이는 기준이 설정되고 성능이 측정되는 네 가지 주요 영역이다.

올바른 테스트 접근 방식: 수동 및/또는 자동 테스트?

테스트 접근 방식은 일반적으로 수동 테스트와 자동 테스트라는 두 가지 주요 범주 중 하나에 속한다.

수동 테스트 (Manual Testing)

수동 소프트웨어 테스트에서는 개발자가 테스트 케이스를 수동으로 실행하여 애플리케이션의 동작을 관찰하고 결과에 대한 보고서를 작성한다.

수동 테스트는 소프트웨어 개발 라이프 사이클의 초기 단계에서 일반적으로 사용된다. 애플리케이션이 아직 프로토타입 단계에 있을 때 구현이 더 쉽기 때문이다. 수동 테스트는 사용자 상호작용, 특히 사용자 인터페이스가 관련된 경우에도 매우 관련성이 높다.

수동 테스트를 다른 옵션보다 선호하게 되는 중요한 이유 중 하나는 일부 시나리오에서는 애플리케이션의 동작에 대한 보다 포괄적인 분석을 가능하게 한다는 것이다. 또 유연성이 있어 수동 테스트는 임시 테스트에도 적합하다.

수동 소프트웨어 테스트는 개발자에게 다음과 같은 이점을 제공한다.

유연성: 수동 테스트는 자동화된 접근 방식에서 놓칠 수 있는 다양한 테스트 시나리오, 예외 상황, 사용자 흐름을 개발자가 탐색할 수 있게 한다. 자동화된 접근 방식에서 다루지 못하는 사례를 처리하는 것은 개발자의 작업에 있어 상당한 유연성을 제공 한다.

비용 효율성: 특히 규모가 비교적 작은 프로젝트의 경우에는 수동 테스트가 매우 경제적인 접근 방식이다. 값비싼 자동화 테스트 도구나 추가비용 없이 필요한 테스트를 수행할 수 있는  테스터, 즉 인적 자원인만 있으면 된다.

정확성: 수동 테스트는 자동화된 도구보다 특정 상황에서 더 정확한 결과를 제공한다고 여겨진다. 예를 들면 시각적 디자인, 사용자 인터페이스, 자동화된 도구에서 놓칠 수 있는 문제 등이 있다. 

단점은 수동 테스트는 특히 자동화된 테스트 접근 방식에 비해 시간이 많이 소요되며 높은 수준의 전문 지식과 세부 사항에 대해 극도의 주의가 필요하다는 것이다. 개발자들은 결과를 문서화하면서 단계적으로 진행해야 하므로 시간이 걸리고 소프트웨어 라이프사이클이 길어질 수 있다.

또 테스터는 테스트 프로세스 중에 결함을 놓치거나 자체적으로 실수를 할 수 있으므로 인적 오류가 발생하기 쉽다. 그럼에도 불구하고 많은 시나리오에서는 수동 테스트가 올바른 접근 방식이다.

수동 테스트는 사람인 테스터가 모든 가능한 시나리오와 테스트 케이스를 효율적으로 테스트 할 수 없기 때문에  범위가 제한될 수 있으며, 버그 및 기타 문제가 누락될 수 있다.

자동화된 테스트 (Automated Testing)

자동화된 소프트웨어 테스트는 맞춤형 도구를 사용하여 일련의 테스트 케이스를 실행하여 제품에서 버그와 오류를 식별하고 제거하는 과정을 말한다.

자동화된 테스트는 개발자에게 다음과 같은 이점을 제공한다.

속도: 전문 도구를 사용하여 소프트웨어 테스트 프로세스를 자동화하는 것의 가장 큰 장점은 속도이다. 자동화된 테스트는 빠르게 실행되며 짧은 기간에 많은 테스트를 수행할 수 있다.

테스트 케이스 커버리지: 자동화된 도구는 수동 테스트보다 더 많은 테스트를 다양한 시나리오에서 수행 가능하다. 이를 통해 개발자는 버그를 수정하고 애플리케이션의 모든 개별 구성 요소에 대한 안정성을 제공할 수 있다.

일관된 결과: 자동화된 도구를 사용하면 인적 오류의 위험이 제거되고 테스트가 구현될 때마다 일관된 결과가 생성된다.

재사용성: 테스트에서는 테스트 스크립트를 무한히 사용할 수 있으므로 수동 테스트가 필요 없어 시간과 노력이 절약된다.

확장성: 자동화된 테스트를 통해 매우 많은 양의 데이터를 쉽게 처리하고 여러 애플리케이션과 버전을 동시에 테스트할 수 있다. 이로써 테스터들은 필요에 따라 테스트 프로세스를 확장할 수 있다.

전반적으로 자동화된 테스트는 수동 테스트에 비해 훨씬 빠르고, 효율적이며, 수동 테스트에 비해 오류가 덜 발생하고, 사람의 개입과 노력에 대한 요구가 훨씬 낮다. 자동화는 반복 작업 및 회귀 테스트와 관련된 테스트뿐만 아니라 다양한 플랫폼과 다양한 구성에서 실행되는 애플리케이션을 테스트할 때 사용하는 전략이다. 자동화된 테스트는 필요한 테스트 환경에 쉽게 적용할 수 있고, 반복하기 쉽기 때문에 적절한 도구에 대한 초기 비용이 높더라도 장기적으로는 매우 경제적이기 때문이다. 

비용: 적절한 도구를 설치하고 해당 도구를 사용하는 데 필요한 인력의 교육이 필요하기 때문에 초기에 설치 비용이 높다. 이는 자동화된 소프트웨어의 단점 중 하나이다. 장기적으로는 유지 관리 및 업데이트 비용도 포함된다.

낮은 인간 상호 작용: 사람의 개입과 상호 작용에 대한 요구가 적으면 특정 유형의 오류와 버그를 놓칠 수 있다.

커버리지 제한: 자동화된 도구는 더 넓은 범위의 커버리지를 제공할 수 있지만 여전히 사용자 경험 및 사용자 인터페이스 디자인과 같은 일부분은 사람이  처리해야 한다.

수동, 자동, 아니면 둘 다?

소프트웨어 테스트에 대한 다양한 접근 방식의 이점, 커버리지 및 다양한 범위는 수동 및 자동화된 테스트의 조합이 최상의 결과를 생성하고 오류 및 버그 가능성을 최소화할 가능성이 있음을 시사한다.

수동 및 자동화된 접근 방식은 각각의 장단점이 있기 때문에 애플리케이션의 동작과 중단점에 대한 가장 포괄적인 분석을 제공하며 더 나은 품질의 제품으로 이어질 수 있는 두 접근 방식 간의 균형을 찾는 것은 개발자의 몫이다.

기능 및 비기능 테스트

기능(Functional) 테스트 와 유형

기능 테스트는 애플리케이션이나 소프트웨어 시스템이 클라이언트가 설정한 기능 사양 및 요구 사항에 대해 얼마나 잘 수행되는지 성능을 확인한다. 기능 테스트는  입력을 제공하고 출력을 설정된 요구 사항과 비교하여 애플리케이션의 구성 기능을 독립적으로 테스트한다.

기능 테스트는 일반적으로 비기능 테스트 이전에 실행된다. 기능 테스트 유형은 다음과 같다. 

단위 테스트 (Unit Testing)
통합 테스트 (Integration Testing)
사용자 승인 테스트 (User Acceptance Testing)
스모크 테스트 (Smoke Testing)
회귀 테스트 (Regression Testing)
새너티 테스트 (Sanity Testing)
화이트 박스 테스트 (White Box Testing)
블랙 박스 테스트 (Black Box testing)

각 기능 테스트 유형을 더 자세히 살펴보자.

단위 테스트 (Unit Testing)

단위 테스트는 더 큰 시스템의 개별 구성 요소 또는 더 넓은 시스템의 개별 부분에 중점을 둔다. 개발자는 애플리케이션의 전체 기능을 살펴보기 전에 독립적인 최소 단위의 코드에 집중하여 개별적으로 테스트한다.

단위 테스트는 개발자에게 개발 주기 초기에 버그와 오류를 포착할 수 있는 기회를 제공하고 수정 조치를 더 빠르고 쉽게 만들어 소프트웨어 개발 비용을 절감할 수 있다.

단위 테스트의 주요 단점은 엔터프라이즈 애플리케이션이 필연적으로 테스트 가능한 수많은 코드 단위로 구성된다는 것이다. 이는 철저한 테스트가 구현되는 데 많은 시간과 비용이 소요될 수 있음을 의미한다.

통합 테스트 (Integration Testing)

반면에 통합 테스트는 시스템의 다른 구성요소가 서로 상호 작용하는 방식을 테스트 한다. 이 유형의 테스트는 일반적으로 여러 단위 테스트를 한 후에 발생하며 테스트 된 장치가 함께 얼마나 잘 작동하는지 확인하도록 설계되었다. 

통합 테스트는 단위 테스트에서 나타나지 않는 버그를 잡아내고 소프트웨어 개발 주기 초기에 통합 문제를 식별할 수 있지만, 코드 베이스가 커질수록 더 복잡한 프로세스가 될 수 있다.

사용자 승인 테스트 (User Acceptance Testing)

이 유형의 테스트는 이름에서 알 수 있듯이 설정된 사용자 요구 사항에 대해 시스템 성능을 검증한다. 또 일반적으로 실제 사용자나 분석가에게 할당되며, 사용자 요구와 사용 패턴을 복제하는 실제 조건에서 시스템을 테스트하는 데 중점을 둔다. 

사용자 승인 테스트의 핵심 이점은 실제 사용 사례를 통해 실제 환경에서 시스템이 의도한 대로 작동하도록 보장한다는 것이다. 그러나 테스트해야 하는 사용자 페르소나와 사용 사례가 많으면 시간과 비용이 많이 들 수 있다.

스모크 테스트 (Smoke Testing)

스모크 테스트는 확신 테스트(confidence testing) 또는 빌드 검증 테스트(build verification testing)로도 알려져 있다. 이 방법은 개발자가 특정 빌드가 다음 테스트 단계를 위한 준비가 되었는지 확인하고 더 자세한 측면을 테스트하기 전에 애플리케이션의 핵심 기능에 중점을 둔다. 애플리케이션이 스모크 테스트에 실패하면 해당 애플리케이션은 개발팀으로 돌아간다.

회귀 테스트 (Regression Testing)

회귀 테스트의 역할은 시스템 변경으로 인해 새로운 버그가 발생하거나 충돌이 발생하지 않는지 확인하는 것이다. 회귀 테스트에는 변경 사항이 도입된 직후 시스템을 확인하여 새로운 버그나 결함이 나타나지 않았는지, 시스템이 손상될 위험이 없는지 확인하는 작업이 포함된다.

이 테스트의 목적은 개발 과정 중에 나타나는 오류를 잡아내는 것이며, 소프트웨어 업데이트와 업그레이드 또는 현대화에서 시스템 무결성을 확인하는 데 매우 유용하다.

새너티 테스트 (Sanity Testing)

새너티 테스트는 회귀 테스트의 하위 범주이며, 그 목적은 새로운 소프트웨어 빌드가 의도한 대로 작동하는지 테스트 하는 것이다. 일반적으로 범위가 제한되어 있으며, 시스템의 버그를 식별하는 것이 아니라 핵심 기능을 검증하는 데 더 중점을 둔다.

새너티 테스트는 애플리케이션이 변경된 후에 수행되는 첫 번째 테스트 중 하나이며, 그 결과에 따라 계획된 추가 테스트가 진행될 수 있는지 결정된다. 또 애플리케이션이 초기 스모크 테스트를 통과한 후에 구현되며 사용자 인터페이스 및 데이터 입출력과 같은 중요한 구성 요소의 유효성을 검사한다.

화이트 박스 테스트 (White Box Testing)

화이트 박스 테스트는 애플리케이션의 내부 구조와 코드에 중점을 두어 보안, 유용성, 디자인을 향상시킨다. 클리어 박스 테스트(Clear Box testing) 또는 글래스 박스 테스트(Glass Box testing)라고도 알려진 이 테스트는 내부 보안 문제와 경로의 무결성, 입력 흐름 및 조건 루프를 확인한다. 이 테스트는 개별 명령문, 객체, 기능을 테스트하며 시스템, 통합, 단위 수준에서 이루어질 수 있다. 이 프로세스에서는 테스터가 직접 코드를 볼 수 있다.

블랙 박스 테스트 (Black Box testing)

애플리케이션의 소스 코드와 내부 구조를 알지 못한 채 입력과 출력을 테스트하는 것을 블랙 박스 테스트라고 한다. 블랙 박스 테스트는 사용자 인터페이스, 데이터베이스 연결성, 유용성, 접근성, 보안, 클라이언트와 서버간 통신, 오류 조건과 같은 구성요소를 확인한다. 블랙 박스 테스트 및 기능 테스트는 수동 및 자동화로 둘 다 수행될 수 있다.

비기능(Non-Functional) 테스트 및 유형

비기능 테스트는 기능 테스트에 사용되지 않는 기준인 애플리케이션의 성능, 신뢰성, 유용성, 확장성, 유지 관리 가능성, 이식성 등과 같은 비기능적 특성을 평가한다.  이는 애플리케이션의 생산 위험을 줄이는 데 도움이 된다. 

비기능 테스트는 설정된 품질 표준에 대해 정량화 및 측정이 가능하도록 설계되었으며 소프트웨어의 원활한 설치, 구성, 실행, 관리, 모니터링에 대한 장애물을 제거하는 데 도움이 된다.

비기능 테스트는 기능 테스트의 뒤에 실행되는 경향이 있다. 비기능 테스트의 유형은 다음과 같다. 

성능 테스트 (Performance Testing)
부하 테스트 (Load Testing)
볼륨 테스트 (Volume Testing)
스트레스 테스트 (Stress Testing)
보안 테스트 (Security Testing)
설치 테스트 (Installation Testing)
호환성 테스트 (Compatibility Testing)
마이그레이션 테스트 (Migration Testing)

각 비기능 테스트 유형을 더 자세히 살펴보자.

성능 테스트 (Performance Testing)

이름에서 알 수 있듯이 성능 테스트는 다양한 부하 조건과 환경에서 애플리케이션이 어떻게 작동하는지 확인한다. 

성능 테스트의 목표는 애플리케이션이 필요한 대로 작동하고 사용 중에 예상 부하를 처리할 수 있는지 확인하는 것이다.

부하 테스트 (Load Testing)

부하 테스트는 여러 사용자가 동시에 애플리케이션에 액세스하는 것과 같은 상황을 시뮬레이션하는 등 애플리케이션의  예상 사용 패턴을 모델링하여 복원력과 용량을 결정한다. 따라서 부하 테스트는 다중 사용자 시스템이나 갑작스러운 부하 급증을 처리해야 하는 애플리케이션에 유용하다.

볼륨 테스트 (Volume Testing)

볼륨 테스트는 애플리케이션에 대량의 데이터를 적용하여 데이터 처리 한계와 능력을 확인하는 형태의 테스트이다.

볼륨 테스트는 확장성을 계획하고 애플리케이션의 안정성이 저하되기 시작하는 지점을 식별하는 데 유용하다.

스트레스 테스트 (Stress Testing)

스트레스 테스트는 애플리케이션에 최대 부하와 사용자 입력을 적용하여 중단점을 식별하고 유용성의 한계와 애플리케이션이 출시되기 전에 확장해야 하는지 그 여부를 결정한다. 또 개발자가 애플리케이션이 사용자의 기대와 사용 패턴을 처리하는지 확인하는 데 도움이 된다.

스트레스 테스트는 애플리케이션을 느리게 만들 수 있는 병목 현상을 식별하고 가동 중지 시간이나 오류를 방지하는 데에도 사용할 수 있다. 시스템에 대한 과도한 부하를 동시에 또는 일정 기간 동안 시뮬레이션 하여 확장성을 결정하는 데 도움이 될 수 있다. 이는 충돌이나 장애 후 복구 가능성을 측정하는 데 필수적인 테스트 방법이기도 하다.

보안 테스트 (Security Testing)

보안 테스트는 악의적인 사용자의 공격에 노출될 수 있는 어플리케이션의 취약성을 검사한다. 보안 테스트는 침투 테스트, 취약점 스캔, 코드 리뷰 등 다양한 형태로 진행된다.

보안 테스트와 관련된 위험은 리소스와 시간을 낭비할 수 있는 오탐(false positive)으로 이어질 수 있으며, 불완전한 커버리지로 인해 테스트가 완료된 후에도 취약점이 여전히 남을 수 있다. 게다가 시간이 많이 걸릴 수도 있다.

설치 테스트 (Installation Testing)

설치 테스트는 결함이나 오류 없이 특정 사용자의 요구 사항에 따라 올바른 기능, 구성 및 라이브러리를 사용하여 애플리케이션이 제대로 설치될 수 있는지 확인하도록 설계되었다. 일반적으로 애플리케이션이 완전히 개발되고, 다른 유형의 테스트가 완료되어, 사용자에게 제공할 준비가 거의 완료된 경우에 수행된다.

호환성 테스트 (Compatibility Testing)

호환성 테스트는 애플리케이션이 다양한 유형의 운영 체제, 플랫폼, 브라우저, 하드웨어, 네트워크 환경, 장치에서 작동할 수 있는지 확인한다.

이전 버전 호환성 테스트는 애플리케이션의 동작과 이전 버전과의 호환성을 확인하는 것이고, 최신버전 호환성 테스트는 애플리케이션의 동작과 최신버전과의 호환성을 확인하는 것이다.

마이그레이션 테스트 (Migration Testing)

마이그레이션 테스트는 기존 시스템을 새 시스템으로 마이그레이션하는 프로세스가 가동 중지 시간을 최소화하고 데이터 손실 없이 성공적으로 완료되었는지 확인 하는 것을 목표로 한다. 동시에 마이그레이션이 완료된 후에도 모든 기능 및 비기능 요구 사항이 여전히 충족되었는지 확인한다.

레거시 델파이 소프트웨어 현대화 프로젝트 테스트: 완벽한 참조 매뉴얼

Delphi-Legacy-1-4936633.png?resize=768,9

레거시 델파이 프로젝트를 업데이트하고 현대화 하는 것은 애플리케이션을 손상시키는 다양한 방법으로 가득 찬 위험한 프로세스처럼 느껴질 수 있다. 그러나 새로운 사용자 요구 사항과 기술 발전으로 인해 종종 리팩터링을 통해 레거시 프로젝트를 업데이트하고 현대화 해야 한다.

현대화 프로젝트를 어디서 시작하고 어떻게 계획할지를 결정하는 것이 가장 어려운 과제 중 하나다. 또 다른 하나는 올바른 전략과 접근 방식을 선택하는 것이다.

소프트웨어 현대화에 대한 명확하 잘 쓰여진 완벽한 가이드가 없다면 이 모든 것이 압도적으로 보일 수 있다. 이것이 바로 윌리엄 메이어(William Meyer)의 저서 "Delphi Legacy Projects: Strategies And Survival Guide”에서 얻을 수 있는 내용이다. 

저자 소개

윌리엄 메이어는 하드웨어 로직 설계 분야에서 커리어를 시작했으며 Z80 어셈블리 언어를 독학했다. 그는 나중에 Z80용 터보 파스칼1.0(Turbo Pascal 1.0)을 발견했으며 여전히 원본 매뉴얼을 가지고 있는 것으로 추측된다. 그는 수년간 터보 파스칼로 작업한 후 델파이에 대해 알게 되고 나서는 절대 뒤를 돌아보지 않았다. 

윌리엄 메이어는 경력을 거의 대부분 텔레비전 방송 산업에서 쌓았다. 델파이에서도 의료 사무실 실습 소프트웨어에 대한 짧은 경험이 있다. 

2019년에 윌리엄 메이어는 안식 기간동안 첫 번째 책인  “Delphi Legacy Projects: Strategies And Survival Guide”를 작업하기 시작했고 이 책은 2022년 7월에 출판되었다. 그는 현재 두 번째 책을 집필 중이다.

“Delphi Legacy Projects: Strategies And Survival Guide” 소개  

레거시 프로젝트를 리팩터링하고 현대화하는 것은 새로운 애플리케이션을 설계하고 코딩하는 것과는 많이 다른 작업이다. 이 책에서는 프로세스의 모든 측면을 검토하고 전략을 제공한다.

특히 테스트 가능성이라는 제목의 18장에는 현대화된 레거시 Delphi 애플리케이션 테스트 프로세스 탐색에 대한 광범위한 지침이 포함되어 있다.

Delphi-Legacy-2-7711289.png?resize=768,9

 

이 댓글 링크
다른 사이트에 공유하기

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.