연속 테스트

Continuous testing
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

지속적인 테스트는 소프트웨어 배포 파이프라인의 일부로 자동화된 테스트를 실행하여 소프트웨어 릴리스 [1][2]후보와 관련된 비즈니스 리스크에 대한 피드백을 즉시 얻는 프로세스입니다.원래 지속적인 테스트는 개발 환경 유발 테스트뿐만 아니라 기존의 개발자/테스터 [3]유발 테스트를 도입하여 개발자에게 피드백 대기 시간을 단축하는 방법으로 제안되었습니다.

지속적인 테스트의 경우 테스트의 범위는 상향식 요건 또는 사용자 사례 검증에서 비즈니스 [4]목표의 중요성과 관련된 시스템 요건 평가까지 다양합니다.

도입 추진 요인

2010년대에 소프트웨어는 비즈니스의 주요 차별화 [5]요소가 되었습니다.그 결과, 조직은 소프트웨어 개발 팀이 보다 짧은 제공 [6][7]사이클 내에 보다 많은 혁신적인 소프트웨어를 제공할 것으로 기대하고 있습니다.이러한 요구를 충족시키기 위해 팀은 신속한 변화를 위한, DevOps 및 연속 제공과 같은 린 접근 방식을 채택하여 시스템 개발 수명 주기(SDLC)[8]를 가속화하고 있습니다.딜리버리 파이프라인의 다른 측면을 가속화하면 일반적으로 팀은 테스트 프로세스가 SDLC 액셀러레이션 [9]이니셔티브의 기대 효과를 달성하는 데 방해가 된다는 것을 알게 됩니다.테스트 및 전반적인 품질 프로세스는 몇 가지 주요 [10]이유로 인해 여전히 문제가 있습니다.

  • 기존 테스트 프로세스는 너무 느립니다.Agile, DevOps 및 Continuous Delivery의 인기가 높아지면서 반복 기간이 몇 개월에서 몇 주 또는 며칠로 변경되었습니다.수동 테스트와 잦은 업데이트가 필요한 자동화된 GUI 테스트에 크게 의존하는 기존 테스트 방법으로는 보조를 [9][11]맞출 수 없습니다.이 시점에서 조직은 테스트 자동화 [1][12]작업을 확장할 필요성을 인식하는 경향이 있습니다.
  • 기존 테스트 프로세스에 자동화가 추가되더라도 관리자는 [2]특정 시점에 애플리케이션과 관련된 위험 수준을 제대로 파악하지 못합니다.이러한 리스크를 이해하는 것은 연속 제공 프로세스에 [13]관련된 신속한 성공/불합격 결정을 내리기 위해 매우 중요합니다.비즈니스가 허용할 수 있는 위험 수준을 파악하지 못한 상태에서 테스트를 개발하면 사용 가능한 모든 테스트를 통과하지만 비즈니스 리더가 [14]출시 준비가 되지 않았다고 간주하는 릴리스 후보를 확보할 수 있습니다.테스트 결과가 각 릴리스 후보가 비즈니스 기대치를 충족하는지 여부를 정확하게 나타내려면 보안, 퍼포먼스,[5] 신뢰성 및 컴플라이언스에 관련된 리스크에 대한 비즈니스 내성을 바탕으로 테스트를 설계해야 합니다.매우 세밀한 상향식 레벨에서 코드를 체크하는 유닛테스트를 실시하는 것 외에 릴리스 후보의 비즈니스 [4]리스크에 대한 하향식 평가를 실시하기 위한 광범위한 테스트스위트가 필요합니다.
  • 테스트가 자동화되고 테스트가 비즈니스 리스크 수준을 효과적으로 측정하더라도 엔드 투 엔드 품질 프로세스가 조정되지 않은 팀은 오늘날의 압축된 제공 [4]사이클 내에서 비즈니스 기대치를 충족하는 데 어려움을 겪을 수 있습니다.각 반복이 끝날 때마다 위험을 제거하려고 하는 것은 [15][16]개발 테스트 등의 결함 방지 전략을 통해 제품에 품질을 구축하는 것보다 훨씬 느리고 리소스 집약적인 것으로 나타났습니다.

조직은 이러한 문제로 인해 고품질의 소프트웨어를 원하는 속도로 제공할 수 없다는 것을 인식하기 때문에 연속 테스트를 채택하고 있습니다.소프트웨어 장애에 따른 비용 상승뿐만 아니라 소프트웨어의 중요성이 커지고 있음을 인식하고 있으며, 더 이상 시간, 범위 및 [2][17][18]품질 간에 균형을 맞추려 하지 않습니다.

목표와 이점

지속적인 테스트의 목표는 최신 빌드 또는 릴리스 [2]후보에서 비즈니스 리스크 수준에 대한 신속하고 지속적인 피드백을 제공하는 것입니다.그런 다음 이 정보를 사용하여 소프트웨어가 [1][5][13][19]언제든지 전송 파이프라인을 통해 진행할 수 있는지 여부를 판단할 수 있습니다.

테스트가 조기에 시작되어 지속적으로 실행되므로 애플리케이션 리스크가 도입된 [6]직후에 노출됩니다.그 후 개발팀은 이러한 문제가 SDLC의 다음 단계로 진행되는 것을 방지할 수 있습니다.이를 통해 결함을 찾고 수정하는 데 필요한 시간과 노력을 줄일 수 있습니다.그 결과 고품질 소프트웨어(허용 가능한 리스크 수준에 대한 기대를 충족시키는 소프트웨어)의 제공 속도와 빈도를 높이고 기술적 [4][10][20]부채를 줄일 수 있습니다.

또, 소프트웨어의 품질 노력과 테스트가 비즈니스의 기대와 일치하고 있는 경우, 테스트의 실행으로 실행 가능한 태스크의 우선순위가 높은 리스트가 작성됩니다(수동으로 확인할 필요가 있는 결과 수가 압도적으로 많아지는 것이 아니라).이를 통해 팀은 조직의 목표와 [2]우선순위에 따라 가장 큰 영향을 미치는 품질 작업에 집중할 수 있습니다.

또한 팀이 SDLC 전체에서 광범위한 테스트를 지속적으로 수행할 경우 프로세스의 품질과 소프트웨어 상태에 관한 지표를 수집합니다.결과 메트릭을 사용하여 테스트의 효과를 포함하여 프로세스 자체를 재검사하고 최적화할 수 있습니다.이 정보는 팀이 [4][10]프로세스를 점진적으로 개선하는 데 도움이 되는 피드백 루프를 확립하는 데 사용할 수 있습니다.잦은 측정, 엄격한 피드백 루프 및 지속적인 개선이 DevOps의 [21]핵심 원칙입니다.

테스트의 범위

지속적인 테스트에는 기능요건과 비기능요건의 검증이 포함됩니다.

기능요건 테스트(기능테스트)에서는 유닛 테스트, API 테스트, 통합 테스트 및 시스템테스트가 자주 실시됩니다.비기능 요건 테스트(비기능 테스트 - 애플리케이션이 퍼포먼스, 보안, 컴플라이언스 등에 관한 기대치를 충족하는지 판단)의 경우 정적 코드 분석, 보안 테스트, 퍼포먼스 테스트 [9][20]등의 실무가 수반됩니다.테스트는 소프트웨어를 [6]출시하는 기업 또는 조직에 가장 중요한 리스크를 가능한 한 빨리 검출(또는 예방)할 수 있도록 설계해야 합니다.

팀은 테스트 스위트를 지속적으로 실행하여 리스크 수준을 효과적으로 평가하려면 GUI 테스트에서 API 테스트로 초점을 전환해야 합니다.이는 1) API('트랜잭션 레이어')가 테스트 대상 시스템에 대한 가장 안정적인 인터페이스로 간주되며 2) GUI 테스트를 유지하기 위해서는 상당한 재작업이 필요하기 때문입니다.신속한 릴리스 프로세스의 일반적인 빈번한 변경에 대응합니다.API 계층에서의 테스트는 취약성이 낮고 [11][22][23]유지보수가 용이합니다.

테스트는 연속적인 통합 중에 또는 연속적인 통합과 함께 최소한 매일 [24]실행됩니다.연속 전달을 연습하는 팀에서는 일반적으로 애플리케이션이 버전 관리 [9]시스템에 업데이트될 때마다 하루에 여러 번 테스트가 실행됩니다.

이상적으로는 모든 테스트는 모든 비실가동 테스트 환경에서 실행됩니다.정확성과 일관성을 확보하기 위해 테스트는 가능한 한 완전한 실제 가동 환경에서 수행해야 합니다.테스트 환경의 안정성을 높이는 전략에는 가상화 소프트웨어(조직이 제어할 수 있는 의존관계와 이미지 작성에 적합하지 않은 의존관계용) 서비스 가상화 및 테스트 데이터 [1][4][10][25]관리 등이 있습니다.

일반적인 프랙티스

  • 테스트는 개발, QA 및 운영의 협업(LOB의 우선순위에 따라 조정된)이어야 하며, 조정된 엔드 투 엔드 품질 [1][4][10][17][26]프로세스 내에서 이루어져야 합니다.
  • 테스트는 논리적으로 구성되고 증분적이며 반복 가능해야 하며, 결과는 결정론적이고 [1][4]의미 있어야 합니다.
  • 빌드 파이프라인의 어느 시점에서 모든 테스트를 실행해야 하지만 일부 테스트에서는 다른 테스트(유닛 테스트)[1][9]보다 리소스가 많이 들기 때문에 모든 테스트를 항상 실행할 필요는 없습니다.
  • 테스트 데이터 및 환경의 제약을 해소하여 실제 가동 환경에서 테스트를 [1][4][9]지속적으로 일관성 있게 실행할 수 있도록 합니다.
  • 멀티계층 아키텍처를 사용하는 최신 시스템 전체에서 잘못된 긍정을 최소화하고 테스트 유지보수를 최소화하며 사용 사례를 보다 효과적으로 검증하려면 팀은 GUI [4][11][12]테스트보다 API 테스트를 강조해야 합니다.

과제/장애

최신 애플리케이션은 고도로 분산되어 있기 때문에 테스트 스위트를 실행하는 테스트 스위트에서는 일반적으로 테스트에 즉시 사용할 수 없는 종속성(예: 제한된 용량 또는 불편한 시간에만 테스트에 사용할 수 있는 서드파티 서비스, 메인프레임 등)에 대한 액세스가 필요합니다.또한 민첩하고 병렬적인 개발 프로세스의 채택이 증가함에 따라 엔드 투 엔드 기능 테스트에서는 아직 발전 중이거나 아직 구현되지 않은 종속성에 대한 액세스가 필요한 것이 일반적입니다.이 문제는 서비스 가상화를 사용하여 누락된 종속성 또는 사용할 수 없는 종속성과의 테스트 대상(AUT) 상호작용을 시뮬레이션함으로써 해결할 수 있습니다.또한 다양한 테스트 실행에서 데이터, 성능 [1][7][10]및 동작이 일관되게 유지되도록 하는 데도 사용할 수 있습니다.

팀이 지속적인 테스트를 기피하는 이유 중 하나는 테스트 스위트를 지속적으로 실행할 수 있을 만큼 인프라스트럭처가 확장성이 부족하기 때문입니다.이 문제는 테스트의 초점을 비즈니스 우선순위에 맞추고 테스트 기반을 분할하며 테스트와 애플리케이션 릴리스 자동화 [24]도구를 병행함으로써 해결할 수 있습니다.

연속 테스트와 자동 테스트

Continuous Testing(연속 테스트)의 목적은 안정적인 실가동형 테스트 환경에 "극도의 자동화"를 적용하는 것입니다.연속 테스트에는 [27]자동화가 필수적입니다.그러나 자동 테스트는 연속 [4]테스트와 다릅니다.

자동 테스트에는 팀이 [clarification needed]축적한 테스트 세트의 CI 기반 자동 실행이 포함됩니다.자동 테스트에서 연속 테스트로 이행하려면 릴리스 후보와 관련된 비즈니스 리스크를 평가하고 안정적인 운영 수준의 테스트 환경에서 이러한 테스트를 정기적으로 수행하도록 특별히 설계된 일련의 테스트를 수행해야 합니다.자동 테스트와 연속 테스트의 몇 가지 차이점은 다음과 같습니다.

  • 자동 테스트의 경우 테스트 실패는 중대한 문제에서 사소한 명명 기준 위반까지를 나타낼 수 있습니다.지속적인 테스트의 경우 테스트 실패는 항상 중요한 비즈니스 위험을 나타냅니다.
  • 지속적인 테스트를 통해 테스트 실패는 명확한 워크플로우를 통해 해결됩니다. 이 워크플로우는 결함 대 비즈니스 리스크의 우선순위를 정하고 가장 중요한 문제를 먼저 해결합니다.
  • 지속적인 테스트에서는 리스크가 특정될 때마다 이미 도입되었을 가능성이 있는 모든 유사한 결함을 밝혀내고 [2][5]향후 이와 같은 문제가 재발하지 않도록 하는 프로세스가 있습니다.

전임자

1990년대 이후 지속적인 테스트 주도 개발은 프로그래머에게 a) 추가한 코드가 제대로 기능하는지, b) 의도하지 않게 기존 기능을 변경 또는 파괴했는지에 대한 신속한 피드백을 제공하기 위해 사용되어 왔습니다.Extreme Programming의 핵심 구성 요소였던 이 테스트는 자동화 빌드의 일부로서 유닛 테스트(때로는 수용 테스트 또는 스모크 테스트)를 하루에 여러 번 자동으로 실행합니다.이러한 테스트는 구현 전에 작성됩니다.합격 테스트에 합격하면 구현이 [13][28]성공했음을 알 수 있습니다.

지속적인 테스트 도구

리서치 회사인 Forrester Research와 Gartner는 테스트 자동화 툴에 대한 연례 평가에서 Continuous Testing을 주요 고려 사항으로 삼았습니다.Gartner는 2019년에 최신 버전의 연구를 발표했습니다.

Gartner는 엔터프라이즈급 테스트 자동화 도구의 기준을 충족하는 10가지 도구를 평가했습니다.평가에는 Gartner 클라이언트에 대한 질문, 도구 사용자 조사, Gartner 질문에 대한 벤더 응답, 벤더 제품 데모 등이 포함됩니다.Gartner는 네이티브 Windows 데스크톱 애플리케이션 테스트 및 Android 또는 iOS 테스트 지원을 지원하는 툴과 응답성이 뛰어난 웹 애플리케이션, 모바일 애플리케이션, 패키지 애플리케이션, API/웹 서비스 중 3가지를 지원해야 했습니다.2019 Magic Quadrant 연구의 결과는 다음과 같습니다.[29]

Forrester Research는 2020년에 15개의 툴이 엔터프라이즈급 테스트 기능 자동화 [30]툴의 기준을 충족하는지 평가했습니다.Forrester는 과거 조사, 사용자 요구 및 전문가 인터뷰에 기초하여 26가지 기준을 결정하고 Forrester의 질문, 벤더 제품 데모 및 고객 인터뷰에 대한 벤더의 응답에 기초하여 제품과 그 기준을 비교 평가했습니다.Forrester는 크로스 브라우저, 모바일, UI 및 API 테스트 기능을 갖춘 툴이 필요했습니다.2020 Forrester 웨이브의 결과는 다음과 같습니다.[30]

  • 리더: ACELQ, 가지, Parasoft, Tricentis
  • 강력한 성능: Broadcom, IBM, Mabl, Micro Focus, Perforce, Source Labs, SmartBear Software
  • 후보: Cyara, Expirate test, Worksoft
  • 과제: Ranorex

「 」를 참조해 주세요.

추가 정보

  • Ariola, Wayne; Dunlop, Cynthia (2014). Continuous Testing. CreateSpace. ISBN 978-1494859756.
  • Gruver, Gary; Mouser, Tommy (2015). Leading the Transformation: Applying Agile and DevOps Principles at Scale. IT Revolution Press. ISBN 978-1942788010.
  • Whittaker, James; Arbon, Jason; Carollo, Jeff (2012). How Google Tests Software. Addison-Wesley Professional. ISBN 978-0321803023.
  • Humble, Jez; Farley, David (2010). Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation. Addison-Wesley Professional. ISBN 978-0-321-60191-9.
  • 로잘린드 래드클리프(2021년).엔터프라이즈 버그 버그 버스트 테스트부터 CI/CD까지 비즈니스 성과 제공.Accelerated Strategies 프레스.ISBN: 978-1-09838-149-3.

레퍼런스

  1. ^ a b c d e f g h i 파이프라인의 일부: 지속적인 테스트가 필수적인 이유, TechWell Insights의 Adam Auerbach, 2015년 8월
  2. ^ a b c d e f 리스크와 지속적인 테스트의 관계: 2015년 12월 Stickyminds Cameron Philip-Edmonds의 Wayne Ariola 인터뷰
  3. ^ Saff, D.; Ernst, M.D. (20 Nov 2003). Reducing wasted development time via continuous testing. 14th International Symposium on Software Reliability Engineering, 2003. Denver, CO, USA: IEEE. pp. 281–292. ISBN 0-7695-2007-3. ISSRE 2003. Archived from the original on 1 August 2016. doi: 10.1109/ISSRE.2003.1251050
  4. ^ a b c d e f g h i j k DevOps: Wayne Ariola와 Cynthia Dunlop, 2015년 10월 PNSQC의 고객에게 버그를 빠르게 전달하고 있습니까?
  5. ^ a b c d DevOps and QA: 품질의 실제 비용은 얼마나 됩니까? by Ericka Chickowski, DevOps.com, 2015년 6월
  6. ^ a b c 2014년 12월 CM Crossroad Bob Aiello의 DevOps 오른쪽 이동의 중요성
  7. ^ a b Lisa Morgan, SD Times, 2014년 9월, 연속 워크플로우에 문제가 지속됨
  8. ^ 연속 테스트: 다르게 생각하라, by Ian Davis, Visual Studio Magazine 2011년 9월
  9. ^ a b c d e f 지속적인 제공 환경에서 테스트, Rob Marvin, SD Times 2014년 6월
  10. ^ a b c d e f TechWell Insights, Adam Auerbach의 2014년 10월, Shift Left and Put Quality First
  11. ^ a b c Forrester Wave™의 기능 테스트 자동화 평가(FTA)가 발표되어 GUI 테스트를 넘어서는 것이 중요합니다.(Diego Lo Giudice, Forrester Research, 2015년 4월 23일)
  12. ^ a b Amy Reichert, Search Software Quality 2014년 9월, 지속적인 개발이 소프트웨어 테스터에 변화를 가져옵니다.
  13. ^ a b c Zeichick의 견해: '지속적인 통합'은 잊으십시오.유행어는 이제 '지속적인 테스트'가 되었습니다(Alan Zeichick, SD Times 2014년 2월).
  14. ^ 잘못된 소프트웨어를 구입하시겠습니까? CMS Wire의 Dom Nicastro, 2014년 10월, Voke의 Teresa Lanowitz와의 대화에 70만달러의 비용이 들 수 있습니다.
  15. ^ Jones, Capers; Bonsignour, Olivier (2011). The Economics of Software Quality. Addison-Wesley Professional. ISBN 978-0132582209.
  16. ^ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 73. ISBN 978-0-470-04212-0.
  17. ^ a b Teresa Lanowitz가 STARAST 2014에서 극한 테스트 자동화에 대해 발표, Beth Romanik, TechWell Insights, 2014년 5월
  18. ^ 게스트 표시: Continuous를 계속하지 못하는 이유는 무엇입니까?by Noel Wurst, SD Times 2015년 11월
  19. ^ 지속적인 테스트를 통해 애플리케이션 개발 비즈니스 리스크 관리, 2014년 9월 CM Crossroad Wayne Ariola씨
  20. ^ a b Stickyminds, Don Prather의 지속적인 성능 테스트의 힘 2015년 8월
  21. ^ DevOps 및 연속 전달 프랙티스, Ben Linders, InfoQ 2015년 7월
  22. ^ Sean Kenefick, Gartner, 2014년 1월 7일, 레이어드 테스트[dead link] 전략을 사용하여 더 나은 소프트웨어 제작
  23. ^ Cohn, Mike (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Professional. p. 312. ISBN 978-0321579362.
  24. ^ a b Siemens Healthcare에서 연속 테스트 경험, Ben Linders, InfoQ 2015년 2월
  25. ^ DevOps - 시장이 아니라 지속적인 딜리버리 가치사슬을 지원하는 도구 중심 철학, Laurie F.Wurster, Ronni J. Colville, Jim Duggan, Gartner, 2015년 2월
  26. ^ Adrian Bridgwater, Computer의 Agile Development 기간2013년 11월 주
  27. ^ Alexandra Weber Morales, SD Times 2014년 1월, 생산 전 라이프 사이클을 충족시키는 궁극의 자동화
  28. ^ Continuous Integration (오리지널 버전), Martin Fowler, DevOps.com, 2000년 9월
  29. ^ Magic Quadrant for Software Test Automation, Gartner, 2019년 11월 25일
  30. ^ a b "The Forrester Wave: Continuous Functional Test Automation Suites, Q2 2020". Forrester. 2020-06-18. Retrieved 2020-10-16.