R&D 효율성 인증 학생 작품: DevSecOps 테스트에서 왼쪽으로 이동하는 방법丨IDCF

저자: Zhao Lurun(현재 Saiyi Information Technology Co., Ltd.에서 근무)

R&D 효과성(DevOps) 엔지니어 인증 학생, PMP 인증, ITIL4 인증

머리말

자체 개발한 ITDevOps 시스템은 제품 정보 트리 관리, 민첩한 협업 관리, 개발 서비스 관리, 테스트 장비 관리, 보안 운영 및 유지 관리의 주요 기능을 수행합니다.개발 서비스 관리는 회사의 다른 프로젝트에 대해 엔드 투 엔드 통합 자동 구성 및 자동 배포 기능과 패키지 관리 기능을 제공하는 것을 목표로 합니다.많은 사용자가 플랫폼을 자주 사용합니다.프로젝트 테스트 관리를 더 잘 시작하여 온라인 결함을 줄이고 사용자 부정적인 리뷰를 줄이고 사용자 만족도를 높이는 것이 더 어려운 작업입니다.

문제점

팀 운영을 더 잘 조정하고, R&D 효율성을 개선하고, 테스트와 개발 간의 민첩한 협업을 실현하고, 커뮤니케이션 비용을 줄이고, 온라인 변경의 성공률을 향상시키기 위해 우리는 프로젝트 문제점을 해결하고 하나씩 해결하기 시작했습니다.

1. 플랫폼 제품에 대한 수요, 많은 디자인 변경 및 어려운 기본 관리: 플랫폼 제품은 업계의 비즈니스 변화에 신속하게 대응해야 하며 버전 제공에 대한 고객의 요구 사항이 크게 변경되었습니다.

2. 팀의 API 자산이 모호하다: 프로젝트에 많은 마이크로 서비스가 있고 API 자산 기능의 전체 목록이 누락되었습니다.새로 온 사람들은 기존 API 기능으로 시작할 방법이 없습니다.

3. 빈번한 시작 및 짧은 테스트 및 승인 시간: 현재 프로젝트는 2주마다 정기적으로 시작되며 개발자의 자체 테스트 및 공동 디버깅은 테스터의 승인 시간을 차지하고 시작 시간이 촉박하면 인적 오류 비율이 높아집니다.

 수동 테스트 및 온라인 신뢰할 수 있는 테스트 왼쪽으로 이동

테스트 관리자로서 현재 프로젝트 운영의 테스트 결과 및 현재 상태에서 나는 프로젝트가 여전히 전통적인 소프트웨어 개발 주기, 즉 "폭포 모드"에 있음을 분명히 느낄 수 있습니다.이 모드에서 프로젝트 주기는 명확하게 여러 단계로 구분됩니다: 6가지 기본 활동: 계획-요구 사항 분석-소프트웨어 설계-프로그램 코딩-소프트웨어 테스트-운영 및 유지 관리, 그림 1과 같이:

위의 그림에서 보듯이 소프트웨어 테스트 단계는 소프트웨어 수명 주기의 다섯 번째 단계인 오른쪽 단계에 있습니다.

프로젝트가 2주마다 일상적으로 시작되기 때문에 "올바른" 단계에서 발견된 결함을 수리하는 비용은 매우 높을 것입니다.이러한 결함의 대부분은 코딩 중에 발견되지 않고 재테스트 후 또는 온라인에 접속한 후에도 온라인에 연결되지 않습니다.다음날 계속 온라인에 접속하면 나타납니다.개발자는 결함을 수정하느라 바쁘고 반복 개발을 지연시킵니다.변경 성공률은 점점 낮아지고 있습니다.

이 상황을 해결하기 위해 프로젝트 관리자와 소통한 후 팀에서 수동 테스트 좌교대 및 API 자동 테스트 좌교대 개념을 도입할 것을 제안했습니다.

수동 테스트 왼쪽 교대 근무는 어떻게 이루어지나요? 즉, 연구개발 완료 후 테스트에 개입하는 방식부터 계획 및 요구사항 분석을 구체화하는 단계까지 테스터가 참여하기 시작한다.

1. 미리보기 미팅

• 조직에 설명 회의가 필요함

  BA, 개발, 테스트가 모두 관련되어 있습니다. 회의에서 BA는 개발 및 테스트에 대한 요구 사항을 하나씩 명확히 하고 개발자와 테스터 모두 스스로 질문해야 합니다. BA는 PM 및 사용자와 사업 계획을 소통하고 선임 개발자와 기술 솔루션을 계속 논의합니다. 이 기간 동안 테스터는 전체 프로세스에 참여하고 요구 사항의 변경 사항을 기록하는 프로세스에 주의를 기울입니다.

• 혼선 방지 세션 구성 및 개발

  개발자는 개발에 대한 잡담 검토를 실시하고 각 개발은 자체 개발 요구에 따라 개발 디자인 아이디어와 흐름도를 출력합니다.테스트는 비즈니스 포인트에 따라 해당 질문을 제기하고 개발과 합의에 도달한 후 개발자는 개발 작업에 계속 투자합니다.

• 테스트 계획 검토 회의 구성

  테스터는 테스트 계획 문서를 작성하고 개발자가 협업에 참여하도록 구성하고 개발자는 계획의 부정확하거나 모호한 부분에 대한 개선 제안을 제안하고 개발에서 테스트까지 요구 사항의 최종 폐쇄 루프 데모를 완료합니다.

2. 플랫폼에 의존

1. 테스트 설계 개발

   테스터는 테스트 설계를 소개하고 프로젝트 계획 및 설계에서는 플랫폼의 프로젝트 관리 계획을 통해 요구 사항을 계획하고 설계합니다. 프로젝트 관리는 일반적으로 사용되는 계획 방법을 기반으로 마인드 맵을 제공합니다. 이 반복의 테스트 설계에 IR을 도입하고 해당 US를 추가하고 테스트 책임자 필드를 유지합니다.

2. 테스트 전략 개발

   테스트 설계가 완료된 후 각 미국에 대해 하위 노드를 추가한 다음 테스트 범위, 테스트 수준, 테스트 유형, 검증 환경, 위험 및 처리 계획을 포함하는 테스트 전략을 추가합니다. 원본 문서 설명에서 하위 노드를 통한 온라인 추가, 요구 사항 도입에서 기능 노드 전달에 이르기까지 테스트 완료를 추적할 수 있습니다.

3. 테스트 계획 개발

   테스트 전략이 완성된 후 테스트 계획의 로컬 작성은 점차 온라인 관리로 이어지며 xmind를 통해 로컬에서 직접 테스트 계획을 작성하는 대신 로컬 직접 가져오기 또는 온라인 작성을 통해 테스트 계획의 백업 관리를 실현합니다.

4. 테스트 케이스 개발

   온라인 테스트 케이스는 반복적으로 진행하고 유즈케이스는 베이스라인을 통해 전체적으로 관리하며, 현재 반복에 변화가 있을 경우 자동으로 베이스라인에 동기화되고 선택적 유스케이스 간의 관계는 온라인 테스트 계획에서 실현될 수 있으며 테스트 설계, 테스트 전략 및 테스트 계획으로부터 온라인 추적이 완료될 수 있다.

예비 작업을 여러 번 반복한 후 온라인에서 테스트 사례 실행을 완전히 추적할 수 있고 테스트 누락 현상이 점차 감소하며 결함 발견 시기도 반복 종료 시 발견에서 초기 비즈니스 요구 사항 조기 회피로 앞당겨집니다.

현재 매뉴얼 테스팅의 표준화를 완료하고 테스트를 왼쪽으로 옮기는 1단계를 완료했다.

그렇다면 API 자동화 테스트의 왼쪽 이동을 실현하는 방법은 무엇입니까?

API 자동화 테스트 왼쪽으로 이동

우리는 일반적으로 테스트 자동화 피라미드라고도 하는 테스트 피라미드가 기본적으로 개발 및 QA 팀이 자동화된 테스트 스위트에 통합해야 하는 테스트 유형을 설명한다는 것을 알고 있습니다. 또한 이러한 평가의 순서와 빈도를 정의하며, 그 목적은 코드 변경이 기존 기능에 영향을 미치지 않도록 빠른 피드백을 제공하는 것입니다. 그림 2:

1. 단위 테스트(UnitTest)

단위 테스팅은 코드 단위(주로 클래스/메소드)에 대한 테스트로, 가장 빠른 피드백을 제공할 수 있고 개발 과정에서 논리 단위를 검증할 수 있다는 것이 단위 테스트의 가치입니다.

2. 인터페이스 테스트(서비스/서비스/API 테스트)

인터페이스 테스트는 비즈니스 인터페이스에 대한 테스트로, 주로 주요 비즈니스 흐름이 통과할 수 있는지, 예외가 올바르게 처리되는지, 데이터가 비어있는 시간 검증 등 내부 인터페이스 기능이 완전한지 테스트합니다. 인터페이스 테스트의 주요 가치는 인터페이스 정의가 상대적으로 안정적이고 인터페이스 또는 기본 코드가 변경되지 않으므로 인터페이스 테스트가 작성하기 쉽고 사용 사례의 유지 관리 비용이 상대적으로 낮으며 인터페이스 수준에서 테스트를 준비하는 비용 성능이 상대적으로 높다는 것입니다.

3. 통합 테스트(UI 테스트)

통합 테스트는 사용자 관점에서 제품 기능의 정확성을 검증합니다.종단 프로세스를 테스트하고 사용자 시나리오와 데이터를 추가하여 전체 비즈니스 흐름을 검증합니다.통합 테스트는 비즈니스 가치가 가장 높으며 전체 프로세스를 검증해야 합니다.그러나 완전한 프로세스를 검증해야 하기 때문에 환경 배치, 사용 사례 준비 및 구현 비용이 높고 구현하기가 쉽지 않습니다.

현재 프로젝트의 경우 API 자산 관리, 무선 작업 및 개발 후 테스트 단계에 대한 액세스 권한이 없습니다. 따라서 첫 번째 단계에서 자동화된 파이프라인에 API 자동화 테스트를 장착하여 타이밍 및 정량 실행을 완료하고 환경 및 인터페이스 불안정과 같은 요소를 사전에 발견해야 합니다. 다음 두 가지 측면에서 시작해야 합니다.

1. API 온라인 관리

   1. 온라인 기준 버전: 온라인 API 기준 버전을 통해 버전 전달 과정에서 변경이 필요하지 않으며, 변경이 필요한 경우 기본 버전을 기준으로 공수를 산정하여 동일한 공수로 교체할 수 있습니다.

2. API 자산 관리

   1. API 기능 목록: API 기능 자산 목록이 온라인으로 반환, 계층적 디자인, 명확한 목록 디렉토리 구조

   2. API 사용 사례 목록: API는 비즈니스 설명 + 코드 용어의 조합을 명확하게 사용하므로 개발자와 테스터가 API 기본 정보와 자동화된 테스트 사례 정보를 신속하게 결정할 수 있습니다.

   3. 프로젝트 진입 필수과목: 프로젝트 진입, 프로젝트의 API 기능 목록 이해를 위한 신규 이민자를 위한 필수 과정

위의 두 단계를 거쳐 프로젝트의 API 자산이 정리되고, API 자산의 온라인, 통합, 일관된 관리가 완료됩니다. 그리고 프로젝트에 진입하는 신규 사용자를 위한 학습 목록 항목 중 하나로 프로젝트 구성 프로세스 자산의 침전을 완료했을 뿐만 아니라 프로젝트 API의 온라인 운영을 완료했습니다.마지막으로 조립 라인에서 자동 구성, 자동 배치 및 API 자동 테스트를 통해 API의 자동 타이밍 실행을 완료하고 수동 테스트 사례와 연결하여 자동 테스트 결과의 자동 쓰기를 완료하고 자동으로 발견된 문제 및 결함의 수를 증가시켰습니다.

현재 API 자동화 테스트는 정상적으로 진행되어 초기 시운전은 성공적이었지만, 테스터가 API 자동화 테스트를 처음 접한 후 API 자동화 테스트 케이스를 작성할 때 이해할 수 없는 파라미터가 많고, 더 나아가서 개발과 소통하고 연결해야 하는데, 이런 현상을 볼 때 왜 이 커뮤니케이션을 처음부터 진행하지 못하는 것일까? 따라서 이때 API 자동화 테스트 개념을 도입하여 API를 개발하고 설계할 때 테스터가 참여하여 API 설계가 완료되면 테스터가 자동 테스트 케이스를 작성하기 시작하며 크게 4단계로 나뉩니다.

• API 설계 우선: API 설계 우선, API를 검토하고 확인한 후 테스터는 온라인에서 API 사용 사례 시나리오를 자동으로 생성할 수 있습니다.

• 요구사항 전송 테스트 전: 전송 테스트 전에 개발자는 API 사용 사례 시나리오를 사용하여 자체 테스트를 수행합니다.

• 요구사항 전송 테스트 후: 전송 테스트 후 테스터는 회귀를 위해 API 사용 사례 시나리오를 사용합니다.

• 결함 분석: API 사용 사례 시나리오가 정기적으로 실행되고 매일 문제가 해결되고 해결됩니다.

API 자동화의 작은 단계를 통해 테스터는 요구 사항 분석 및 API 설계가 완료된 후 API 자동화 테스트 사례 작성을 시작하여 자동화 테스트를 실현하고 코딩의 잠재적인 문제를 해결할 수 있습니다.

가치 이득

왼쪽으로 테스트 시프트를 구현하면 프로젝트의 가치가 다음과 같이 향상됩니다.

품질

1. 작년 월평균 미량 불량률은 11.82%, 연평균 감소폭은 전년 대비 70%

2. 수요 적시 배송률 20% 증가, 미국 일회성 합격률 5% 증가

능률

1. API 공용 기능 재사용, 창고 중복 코드 감소

2. 개발자는 인터페이스를 빠르게 찾고 API 사용 사례 시나리오를 사용할 수 있습니다.

프로젝트 운영

1. API 사용 사례 시나리오 재사용, 개발은 자체 테스트에 사용, 수락은 회귀에 사용하여 개발, 테스트 및 온라인 프로세스 시간 단축

2. 매주 그레이스케일에서 반복되는 온라인 문제를 줄이고, 일주일에 한 번 온라인으로 루틴에 최적화

3. 개발자가 온라인에서 담당하는 추가 작업 감소

프로젝트에서 테스트 왼쪽 교대를 실제 구현하면 프로젝트가 개발 효율성을 향상시키고 개발 에너지를 절약하며 프로젝트 운영을 개선하는 데 중요한 역할을 합니다.물이 떨어지는 돌은 하루아침에 달성되지 않습니다.나는 각 프로젝트의 실제 실행을 통해 프로젝트 수입이 증가함에 따라 모두가 각자의 프로젝트의 선순환 발전을 완료할 것이라고 믿습니다.