기능 테스트란?
이 섹션에서는 파이프라인을 위한 기능 테스트를 정의하기 위해 Tailspin 팀에 참여합니다. 기능 테스트는 소프트웨어의 각 기능이 해당 기능을 수행하는지 확인합니다.
팀은 먼저 기능 테스트가 다루는 기능을 정의하고 몇 가지 기능 테스트 유형을 살펴봅니다. 그런 다음 파이프라인에 추가할 첫 번째 테스트를 결정합니다.
주간 회의
팀이 주간 회의를 하고 있습니다. Andy는 릴리스 파이프라인을 시연하는 중입니다. 팀은 성공적인 빌드가 파이프라인에서 한 단계에서 다른 단계로 이동하는 것을 보고 있습니다. 마지막으로 웹앱이 ‘스테이징’으로 승격됩니다.
Amita: 파이프라인이 아주 마음에 드네요. 덕분에 부담을 많이 덜겠어요. 먼저, 테스트 환경에 배포된 릴리스를 자동으로 가져온다는 점입니다. 즉, 테스트 서버에서 빌드 아티팩트를 수동으로 다운로드하여 설치할 필요가 없어 시간을 상당히 절약할 수 있습니다.
또한 Mara 님과 Andy 님이 작성한 단위 테스트가 릴리스를 받기 전에 모든 회귀 버그를 없애죠. 단위 테스트가 문제의 주요 원인을 없애기 때문입니다. 회귀 버그를 찾고 문서화하는 데 시간이 걸리지 않습니다.
하지만 모든 테스트를 여전히 수동으로 수행해야 할지 염려됩니다. 그렇게 되면 프로세스 속도가 느려지고 제가 마칠 때까지는 경영진에게 아무것도 보여줄 수가 없어요. 테스트가 중요하기 때문에 어려울 수 있습니다. 테스트해야 사용자가 적절한 환경에서 사용하도록 보장할 수 있습니다. 하지만 전달 기간을 단축해야 해요.
Andy: 우리가 도움을 드릴 수 있어요. 시간이 가장 오래 걸리는 테스트는 무엇이죠?
Amita: UI 테스트인 것 같아요. 저는 올바른 결과를 얻기 위해 단계마다 클릭해야 하고 지원하는 모든 브라우저에서 똑같은 작업을 해야 합니다. 시간이 정말 오래 걸려요. 웹 사이트가 점점 복잡해 지면서 장기적으로 UI 테스트는 현실적이지 않아요.
Mara: UI 테스트는 기능 테스트로 간주하죠.
Tim:비 기능 테스트란 기능 테스트와 반대 개념인가요?
Mara: 정확해요. 그리고 비 기능 테스트는 Tim이 특별히 신경 쓰는 부분이기도 하죠.
Tim: 그래요, 헷갈리는데요.
기능 테스트와 비 기능 테스트란?
Mara: 기능 테스트는 소프트웨어의 각 기능이 해당 기능을 수행하는지 확인합니다. 해당 테스트에서는 소프트웨어의 각 기능을 구현하는 방법이 중요하지 않습니다. 중요한 점은 소프트웨어가 제대로 작동하느냐는 것입니다. 입력값을 제공하고 결과가 기대치를 충족하는지 확인합니다. 이것이 바로 Amita가 UI를 테스트하는 방법입니다. 예를 들어 순위표에서 성과가 가장 뛰어난 사람을 선택하면 해당 사람의 프로필이 표시되어야 합니다.
비 기능 테스트는 성능과 안정성 등과 같은 특징을 확인합니다. 비 기능 테스트의 예에는 앱에 동시에 등록할 수 있는 사용자 수를 확인하는 테스트가 있습니다. 부하 테스트는 비 기능 테스트의 또 다른 예입니다. 성능과 안정성 문제는 Tim이 신경 쓰는 부분이기도 하죠.
Tim: 맞아요. 이 부분에 대해서는 잠시 생각해 봐야 해요. 파이프라인에 몇 가지 자동화도 추가하고 싶은데 무엇을 할지 모르겠어요. 어떤 종류의 자동화된 테스트를 실행할 수 있을까요?
Mara: 지금은 기능 테스트에 집중할게요. 기능 테스트는 Amita가 수행하는 종류의 테스트입니다. 우리가 개선하려고 하는 영역처럼 들리네요.
어떤 종류의 기능 테스트를 실행할 수 있나요?
기능 테스트에는 여러 종류가 있는데, 테스트해야 할 기능과 테스트를 실행하는 데 일반적으로 필요한 시간 또는 노력에 따라 달라집니다.
다음 섹션에서는 몇 가지 일반적으로 사용되는 기능 테스트를 제시합니다.
스모크 테스트
“스모크 테스트”는 애플리케이션 또는 서비스의 가장 기본적인 기능을 확인합니다. 스모크 테스트는 더 완전하고 철저한 테스트 전에 실행되는 경우가 많으며 신속하게 실행해야 합니다.
예를 들어 웹 사이트를 개발하는 경우를 가정해 보겠습니다. 스모크 테스트는 curl을 사용하여 사이트에 연결할 수 있는지, 홈페이지를 페치하면 200(OK) HTTP 상태가 생성되는지 확인합니다. 홈페이지를 페치할 때 404(찾을 수 없음) 또는 500(내부 서버 오류) 등과 같은 다른 상태 코드가 생성되는 경우 웹 사이트가 작동하지 않음을 알 수 있습니다. 또한 이와 같은 경우에는 다른 테스트를 실행할 필요가 없습니다. 대신 오류를 진단해 수정하고 테스트를 다시 시작합니다.
단위 테스트
Azure Pipelines를 사용하여 빌드 파이프라인에서 품질 테스트 실행 모듈에서 단위 테스트에 대해 살펴보았습니다.
간단히 말해, ‘단위 테스트’는 개별 함수 또는 메서드와 같은 프로그램 또는 라이브러리의 가장 기본적인 구성 요소를 검사합니다. 예상 결과와 함께 하나 이상의 입력을 지정합니다. 테스트 실행 담당자는 각 테스트를 수행하고 실제 결과와 예상 결과가 일치하는지 확인합니다.
예를 들어 나누기가 포함된 산술 연산을 수행하는 함수가 있는 경우 사용자가 입력할 것으로 생각되는 몇 가지 값을 지정할 수 있습니다. 또한 0과 -1처럼 예외 값도 지정합니다. 특정 입력값이 오류 또는 예외를 생성하면 해당 함수가 이와 같은 오류를 생성하는지 확인할 수 있습니다.
이 모듈에서 나중에 실행할 UI 테스트는 단위 테스트입니다.
통합 테스트
“통합 테스트”는 여러 소프트웨어 구성 요소가 함께 작동하여 전체 시스템을 구성하는지 확인합니다. 예를 들어 전자상거래 시스템에는 웹 사이트, 제품 데이터베이스와 결제 시스템이 포함될 수 있습니다. 쇼핑 카트에 품목을 추가한 다음 구입하는 통합 테스트를 작성할 수 있습니다. 해당 테스트는 웹 애플리케이션이 제품 데이터베이스에 연결한 다음 주문을 이행할 수 있는지 확인합니다.
단위 테스트와 통합 테스트를 결합하여 계층화된 테스트 전략을 세울 수 있습니다. 예를 들어 통합 테스트를 실행하기 전에 각 구성 요소에 대해 단위 테스트를 실행할 수 있습니다. 모든 단위 테스트에 통과하면 더 큰 확신을 하고 통합 테스트로 진행할 수 있습니다.
회귀 테스트
“재발”은 기능을 추가하거나 변경한 후 기존 동작이 변경되거나 중단되는 경우 발생합니다. 회귀 테스트는 코드, 구성 또는 기타 변경 내용이 소프트웨어의 전반적인 동작에 영향을 주는지 여부를 확인하는 데 도움이 됩니다.
한 구성 요소를 변경하면 다른 구성 요소의 동작에 영향을 줄 수 있음으로 회귀 테스트가 중요합니다. 예를 들어 쓰기 성능을 위해 데이터베이스를 최적화한다고 가정해 보겠습니다. 다른 구성 요소에서 처리하는 해당 데이터베이스의 읽기 성능이 예기치 않게 저하될 수 있습니다. 읽기 성능의 저하는 회귀입니다.
다양한 전략을 사용하여 회귀가 발생하는지 테스트할 수 있습니다. 이와 같은 전략은 일반적으로 새 기능 또는 버그 수정으로 인해 기존 기능이 중단되지 않는지 확인하기 위해 실행하는 테스트 수에 따라 달라집니다. 그러나 테스트를 자동화하는 경우 회귀 테스트는 소프트웨어가 변경될 때마다 단위 테스트와 통합 테스트를 모두 실행하는 것일 수 있습니다.
온전성 테스트
“온전성 테스트”에는 소프트웨어가 작동 중인 것으로 표시되고 더욱 철저한 테스트를 거칠 수 있는지 확인하기 위해 소프트웨어의 주요 구성 요소를 테스트하는 것이 포함됩니다. 회귀 테스트나 단위 테스트보다 덜 깐깐한 작업인 온전성 테스트를 생각해 볼 수 있지만 온전성 테스트의 범위는 스모크 테스트보다 넓습니다.
온전성 테스트는 자동화할 수 있지만 종종 기능 변경 또는 버그 수정에 대한 대응으로 테스터가 직접 수행합니다. 예를 들어 버그 수정의 유효성을 검사하는 소프트웨어 테스터가 일반적인 값을 일부 입력하여 다른 기능이 제대로 작동하는지 확인할 수도 있습니다. 소프트웨어가 예상대로 작동하는 것으로 나타나는 경우 해당 소프트웨어는 더욱 철저한 테스트를 통과할 수 있습니다.
사용자 인터페이스 테스트
“UI(사용자 인터페이스) 테스트”는 애플리케이션의 사용자 인터페이스 동작을 확인합니다. UI 테스트는 사용자 상호 작용의 시퀀스, 즉 순서가 예상된 결과로 이어질 수 있는지 확인하는 데 도움이 됩니다. 해당 테스트는 키보드 또는 마우스와 같은 입력 디바이스가 사용자 인터페이스에 올바르게 영향을 주는지 확인하는 데도 도움이 됩니다. UI 테스트를 실행하여 네이티브 Windows, macOS 또는 Linux 애플리케이션의 동작을 확인할 수 있습니다. 또한 UI 테스트를 사용하여 웹 브라우저에서 UI가 예상대로 작동하는지 확인할 수 있습니다.
단위 테스트 또는 통합 테스트에서는 UI가 데이터를 올바르게 “수신”하는지 확인할 수 있고, UI 테스트에서는 사용자 인터페이스가 올바르게 ‘표시’되고 결과가 사용자에 대해 예상대로 작동하는지 확인합니다.
예를 들어 UI 테스트는 단추 클릭에 대한 응답으로 올바른 애니메이션이 나타나는지 확인할 수 있습니다. 두 번째 테스트에서는 창의 크기를 조정했을 때에도 동일한 애니메이션이 올바르게 나타나는지 확인할 수 있습니다.
이 모듈에서는 직접 코딩한 UI 테스트를 실행합니다. 그러나 캡처 및 재생 시스템을 사용하여 UI 테스트를 자동으로 빌드할 수도 있습니다.
유용성 테스트
“유용성 테스트”는 사용자 관점에서 애플리케이션의 동작을 확인하는 수동 테스트의 한 가지 형태입니다. 유용성 테스트는 일반적으로 소프트웨어를 빌드하는 팀에서 수행합니다.
UI 테스트는 기능이 예상대로 작동하는지 여부에 초점을 맞춘 반면, 유용성 테스트는 소프트웨어가 직관적이고 사용자의 요구를 충족하는지 확인하는 데 도움이 됩니다. 즉, 유용성 테스트는 소프트웨어의 “사용 가능” 여부를 확인하는 데 도움이 됩니다.
예를 들어 사용자의 프로필 링크가 포함된 웹 사이트가 있다고 가정해 보겠습니다. UI 테스트는 해당 링크가 있고 링크를 클릭하면 사용자의 프로필이 표시되는지 확인할 수 있습니다. 그러나 사용자가 이 링크를 쉽게 찾을 수 없다면 자신의 프로필에 액세스하려고 할 때 불만을 느낄 수 있습니다.
사용자 승인 테스트
‘UAT(사용자 승인 테스트)’는 유용성 테스트와 같이 사용자 관점에서 애플리케이션의 동작을 중점적으로 살펴봅니다. 유용성 테스트와 달리 UAT는 일반적으로 실제 최종 사용자가 수행합니다.
소프트웨어에 따라 최종 사용자에게 특정 작업을 완료하라는 메시지가 표시될 수 있습니다. 또는 특정 지침을 따르지 않고 소프트웨어를 살펴볼 수도 있습니다. 사용자 지정 소프트웨어의 경우 UAT는 일반적으로 고객이 직접 수행합니다. 더 일반적인 용도의 소프트웨어의 경우에는 팀에서 “베타” 테스트를 실행할 수 있습니다. 베타 테스트에서는 여러 지역의 사용자 또는 특정 관심사를 가진 사용자가 소프트웨어에 대한 조기 액세스 권한을 받게 됩니다.
테스터의 피드백은 직접이거나 간접적일 수 있습니다. 직접 피드백은 음성을 통한 의사 표현의 형태로 제공될 수 있습니다. 간접 피드백은 테스터의 바디 랭귀지, 눈의 움직임 또는 특정 작업을 완료하는 데 걸린 시간을 측정하는 형태로 제공될 수 있습니다.
테스트 작성의 중요성은 이미 살펴보았지만 다시 한번 강조하기 위해 다음 짧은 비디오에서는 Microsoft의 Cloud Advocate인 Abel Wang이 DevOps 플랜에서 품질을 보장하는 방법을 설명합니다.
Abel에게 질문하기
팀에서 선택하는 작업은?
Tim: 테스트는 모두 다 중요해 보이는데 어떤 테스트를 먼저 수행해야 할까요?
Andy: 단위 테스트는 이미 진행 중이에요. 하지만 아직 사용자 승인 테스트는 진행할 준비가 되지 않았어요. 들은 내용을 바탕으로 생각하면 UI 테스트에 집중해야 할 것 같아요. 현재 우리 프로세스 중 가장 느린 부분이죠. Amita 님, 어떻게 생각하세요?
Amita: 예, 맞아요. 아직 모임 시간이 좀 남아 있으니까, Andy 님이나 Mara 님 중 한 분이 자동화된 UI 테스트를 계획하도록 도와주시겠어요?
Mara: 물론이죠. 하지만 몇 가지 준비 절차는 건너뛸게요. 사용해야 할 도구와 테스트를 실행할 방법에 관해 이야기해 보고 싶어요.
어떤 도구를 사용하여 UI 테스트를 작성할 수 있나요?
Mara: UI 테스트를 작성할 때 우리가 선택할 수 있는 옵션에는 무엇이 있나요? 매우 많은 옵션이 있다고 알고 있는데요. 일부 도구는 오픈 소스이고 상업적 지원을 유료로 제공하는 도구도 있습니다. 다음과 같은 몇 가지 옵션이 떠오르네요.
- Windows Application Driver(WinAppDriver): WinAppDriver를 사용하면 Windows 앱에서 UI 테스트를 자동화할 수 있습니다. 해당 앱은 UWP(유니버설 Windows 플랫폼) 또는 Windows Forms(WinForms)로 작성할 수 있습니다. 브라우저에서 작동하는 솔루션이 필요합니다.
- Selenium: Selenium은 웹 애플리케이션을 위한 이식 가능한 오픈 소스 소프트웨어 테스트 프레임워크입니다. 대부분의 운영 체제에서 실행되고 최신 브라우저를 모두 지원합니다. C#을 비롯한 여러 프로그래밍 언어로 Selenium 테스트를 작성할 수 있습니다. 실제로 Selenium을 NUnit 테스트로 쉽게 실행할 수 있게 하는 NuGet 패키지가 있는데, 단위 테스트에 NUnit을 이미 사용하고 있습니다.
- SpecFlow: SpecFlow는 .NET 프로젝트용으로, Cucumber라는 도구에서 아이디어를 얻었습니다. SpecFlow와 Cucumber는 둘 다 BDD(동작 기반 개발)를 지원합니다. BDD는 Gherkin이라는 자연어 파서를 사용하여 기술 팀과 비기술 팀이 비즈니스 규칙 및 요구 사항을 정의하도록 지원합니다. SpecFlow 또는 Cucumber를 Selenium과 결합하여 UI 테스트를 빌드할 수 있습니다.
Andy가 Amita를 쳐다봅니다.
Andy: 이와 같은 옵션이 생소하시죠. 그럼 Selenium을 선택해도 괜찮을까요? Selenium을 사용해 본 적이 있고 Selenium은 제가 이미 알고 있는 언어를 지원하거든요. 또한 Selenium은 여러 브라우저를 자동으로 지원합니다.
Amita: 그럼요. 우리 중 한 명이라도 경험이 있다면 더 낫겠죠.
파이프라인에서 어떻게 기능 테스트를 실행하나요?
Azure Pipelines에서는 다른 프로세스나 테스트를 실행하는 것처럼 기능 테스트를 실행합니다. 확인할 사항:
- 테스트는 어떤 단계에서 실행되나요?
- 테스트는 어떤 시스템에서 실행되나요? 애플리케이션을 호스트하는 에이전트 또는 인프라에서 실행되나요?
팀과 함께 해당 질문에 관한 답을 찾아볼까요.
Mara: 한 가지 중요한 점은 이제 앱이 실제로 실행되는 프로덕션과 같은 환경에서 테스트할 수 있다는 사실입니다. UI 테스트와 같은 기능 테스트는 해당 컨텍스트 내에서 의미가 있습니다. 테스트는 파이프라인의 ‘테스트’ 단계에서 실행할 수 있습니다.
Amita: 맞아요. 수동 테스트를 실행하는 것과 동일한 단계에서 자동화된 UI 테스트를 실행하는 경우 동일한 워크플로를 유지 관리할 수 있어요. 테스트를 자동화하면 시간을 절약하고 유용성에 집중할 수 있죠.
Tim: 대부분의 사용자가 Windows 노트북에서 사이트를 방문하므로 Amita는 Windows 노트북에서 웹 사이트를 테스트합니다. 하지만 우리는 Linux에서 빌드한 다음 Azure App Service on Linux를 배포했습니다. 이 문제를 어떻게 처리해야 할까요?
Mara: 좋은 질문이네요. 우리는 테스트를 실행하는 위치를 선택할 수 있어요. 다음 위치에서 테스트를 실행할 수 있죠.
- 에이전트에서: Microsoft 에이전트 또는 우리가 호스트하는 에이전트.
- 테스트 인프라에서: 온-프레미스 또는 클라우드 중 하나.
기존 ‘테스트’ 단계에는 작업이 하나 포함되어 있습니다. 해당 작업은 Linux 에이전트에서 App Service로 웹 사이트를 배포합니다. Windows 에이전트에서 UI 테스트를 실행하는 두 번째 작업을 추가할 수 있습니다. Microsoft 호스팅 Windows 에이전트는 이미 Selenium 테스트를 실행하도록 설정되어 있어요.
Andy: 다시, 알고 있는 내용을 살펴볼게요. Microsoft 호스팅 Windows 에이전트를 사용해 보겠습니다. 나중에 추가 테스트 검사가 필요한 경우 macOS와 Linux를 실행하는 에이전트에서 동일한 테스트를 실행할 수 있습니다.
계획
Mara: 좋아요. 우리가 할 일은 다음과 같습니다.
- Microsoft 호스팅 Windows 에이전트에서 Selenium UI 테스트를 실행합니다.
- 테스트 단계에서 해당 테스트가 App Service에서 실행 중인 앱에서 웹 콘텐츠를 가져오도록 합니다.
- 지원되는 모든 브라우저에서 테스트를 실행합니다.
Andy: 이 지점에서 Amita 님과 함께 작업할 것입니다. Amita 님, 내일 오전에 봬요. 그 전에 연구를 좀 해야겠네요.
Amita: 좋아요! 내일 오전에 봬요.
기능 테스트 계획 세우기
팀에서 첫 번째 기능 테스트 구현 방식을 결정하는 것을 보았습니다. 팀에서는 이제 막 파이프라인에 기능 테스트를 통합하기 시작한 경우(이미 통합 중이더라도) 항상 계획이 필요합니다.
많은 경우, 팀원에게 성능 테스트 계획에 관해 물어보면 사용하려는 도구 목록을 보여 주는 경우가 일반적입니다. 하지만 도구 목록은 계획이 아닙니다. 또한 테스트 환경을 구성하는 방법을 알아내야 합니다. 사용할 프로세스를 결정하고 어떤 경우가 성공이고 실패인지 결정해야 합니다.
계획은 다음과 같아야 합니다.
- 회사의 기대치를 고려해야 합니다.
- 대상 사용자의 기대치를 고려해야 합니다.
- 사용할 메트릭을 정의합니다.
- 사용할 KPI를 정의합니다.
성능 테스트는 처음부터 계획에 포함해야 합니다. 스토리 또는 Kanban 보드를 사용하는 경우 그 근처에서 테스트 전략을 계획할 수 있는 영역을 둘 것을 고려할 수 있습니다. 반복 계획의 일부로 테스트 전략의 차이를 강조해야 합니다. 릴리스 전에 성능을 측정하는 것이 아니라 애플리케이션이 배포된 후 성능을 모니터링하는 방법을 파악하는 것도 중요합니다.