개발자를위한 개발 환경을 신속하게 설정하기 위해 docker 및 여객선 또는 다른 컨테이너 화 기술을 사용합니다. 그러나 이것을 테스트에 적용 할 수 있습니까? 나는 각 테스터의 기계에 대한 환경을 설정하여 자신의 기계에서 테스트 할 수 있습니다. 자동화가 포함되거나 자동화 테스팅이 포함되지 않을 수 있습니다. 이것이 관리자가 원하는 것입니다. "릴리스 빌드"를 프로덕션 복제본에서 테스트해야한다는 것에 개인적으로 동의하지 않습니다. 이는 호스팅 서버가 Amazon EC2에서와 같은 스테이징 환경을 의미합니다. 우리는 일반적으로 이것을 좋아하지만 현재 관리자는 Vagrant를 사용하여 환경을 만들어 로컬 시스템에서 테스트해야합니다.웹 응용 프로그램의 QA 테스트를 위해 Vagrant 또는 Docker를 사용하는 것이 좋습니다.
의견을주십시오.
테스트 할 때 다르게 접근해야 할 이유는 없습니다. 개발자를 위해 자동화 된 개발 환경을 사용한다는 아이디어에 매우 익숙해 보입니다. 그렇다면 QA 팀은 왜 다른 점이 있습니까?
내가 내 QA 과정에서 원하는 키 몇 가지가 있습니다 : 내 프로젝트에 대한
나는 개인적으로 경로를 아래로 갈 것 QA 팀에 자동화 된 개발 환경 제공 그것은 :
위의 목적은 새로운 기능을 작성할 때 개발자 팀이 생산성을 높이는 것과 완전히 같은 방식으로 테스트 스위트를 작성할 때 QA 팀을 생산적으로 만드는 것입니다 .
개발자가 새로운 기능에 대한 끌어 오기 요청을 제기하는 것과 같은 방식으로 QA 제품군에 추가 할 때도 QA를 동일하게 적용합니다. QA 회원은 새로운 테스트가 준비되었다고 생각하면 풀 테스트 요청을 제기하고 테스트 및 테스트 프로세스를 거쳐 주 테스트 스위트에 병합됩니다.
기본 테스트 제품군은 변경 내용이 배포 될 때마다 기본 빌드 파이프 라인과 준비 및 프로덕션 환경의 일부로 실행됩니다. 예를 들어 사용자가 편안하게 사용할 수있는 기술 스택에서 실행되기 때문에 Docker 또는 Vagrant를 빌드 파이프 라인과 쉽게 통합 할 수 있어야합니다.
간단히 말하자면 QA 제품군을 작성하고 유지 관리하려는 소프트웨어 개발에 동일한 원칙을 적용하십시오.
예, 컨테이너를 로컬 테스트에 사용하는 것은 실제로 매우 좋은 아이디어입니다. 테스트를 실행하는 것이 CI 서버보다 빠르며 개발자가 기능/패치가 완료 될 때까지 기다리지 않고 실제로 테스트 할 것을 권장합니다. – max
1. 로컬 컴퓨터가 무거워지지 않습니다. 2. –
하지만 실제로 개발 컨테이너와 별도의 컨테이너 여야하는지 궁금 할 것입니다. Rails 나 Django와 같은 프레임 워크를 사용하는 일반적인 웹 개발의 경우 매우 과도한 것처럼 보입니다. – max