FitNesse 및 soapUI를 사용한 웹 응용 프로그램 테스트 - 테스트 관리 및 유지 관리에 관한 모범 사례?

Question

모든 테스트 자동화 전문가에게 :-)! 다음 시나리오에 대한 의견을 듣고 싶습니다 :

테스트해야하는 웹 응용 프로그램이 있습니다. 클라이언트의 서버 및 프런트 엔드 테스트에서 백 엔드 테스트를 실행해야합니다. 또한 백 엔드와 프런트 엔드를 모두 포함하는 종단 간 테스트를 실행해야합니다.

서버는 웹 서비스 (SOAP)를 노출하고 프런트 엔드 클라이언트는 이러한 서비스의 데이터를 사용합니다. 웹 서비스에서 데이터를 소비하는 타사 클라이언트도 있습니다. 경우에 따라 테스트 시나리오에서는 엔드 - 투 - 엔드 테스트를 수행해야합니다. 즉, 프론트 엔드 GUI에서 일부 변경을 수행 한 다음 백엔드에서 웹 서비스를 사용하여 변경 사항의 성공 여부를 확인합니다.

내가 좋아하는 것 FitNesse - 나의 견해로는, WHAT과 WHY의 분리는 좋은 테스트를 설계하는 데 필수적입니다. Selenesse 모듈이 있으며, Selenium 테스트를 FitNesse wiki 페이지와 통합 할 수 있습니다. 이것은 내가 무엇을 원하는지를 (시나리오 테이블과 스크립트 테이블) 어떻게 테스트해야하는지 (wiki 텍스트)를 테스트해야하는 이유와 이유를 쉽게 설명 할 수있게 해줍니다.

FitNesse의 문제점은 SOAP 웹 서비스를 테스트하는 것이 다소 번거롭다는 것입니다. 어느 쪽이든, 특수 목적의 SOAP 클라이언트 Java fixture를 개발해야하거나 FIT 용으로 작성된 ServiceFixture 클래스를 확장하는 Java 픽스쳐를 작성해야합니다. 어쨌든,이 테스트를 soapUI에 구현하는 것보다 개발 노력이 훨씬 더 큽니다.

내 의견으로는, soapUI의 단점은 테스트의 내용과 이유를 (적어도 직관적 인 방식으로는) 설명 할 수있는 쉬운 방법이 없다는 것입니다.

따라서 전체 테스트를 위해 합리적인 개발 노력이 필요하다고 가정하고 FitNesse/Selenesse에서 GUI 테스트를 작성하고 soapUI에서 백엔드 테스트를 작성하는 방식으로 해결했습니다. 이제는 FitNesse에서 soapUI 테스트를 실행하거나, 모든 테스트를 관리하거나, soapUI에서 FitNesse 테스트를 실행하도록 선택할 수 있습니다. ...

테스트 관리와 관련하여 몇 가지 우려 사항이 있습니다. 하나의 견해), 그리고이 접근법의 유지 가능성 (서로 다른 시각을 지닌 두 가지 도구)을 유지해야한다. 이 문제와 관련하여 최선의/우수 사례에 대한 아이디어가 있습니까? 다른 두 가지를 관리하기위한 세 번째 도구를 제안 하시겠습니까?

Answer 1

당신은 hudson, bamboo와 같은 지속적인 통합 도구를 사용합니까?

커밋/빌드 후에 자동으로 응용 프로그램을 테스트 할 수있는 지속적인 통합 방법을 선호하기 때문에이 질문을드립니다.

즉, hudson이나 bamboo를 사용하면 개발자가 커밋 한 후에 테스트를 실행할 수 있습니다. 그리고 추가적으로 당신은 시험을 schedually 실행할 수 있습니다.

다른 장점은 테스트 스크립트를 로그 할 수 있고 실패/성공 (선택 사항)의 경우 이메일을 보낼 수 있다는 것입니다. 따라서 테스트를 쉽게 모니터링 할 수 있습니다.

또한 셀렌과 soapUI를 병렬 또는 연속으로 실행할 수있는 기회가 있습니다.

---

또한 soapUI 테스트에 대한 제안 사항이 있습니다.

테스트 사례가 많을수록 개발, 실행 및 유지 보수에 더 많은 시간이 소요됩니다. 중요한 점은 테스트를 설계하는 동안 유지 보수 가능성을 고려하는 것입니다.

응용 프로그램에서 여러 웹 서비스를 사용할 수있는 경우 WSDL이 변경되고 SoapUI에서 업데이트해야합니다. 하나의 soapUI 프로젝트에있는 모든 것을 사용하면 여러 프로젝트가 아닌 한 곳에서 WSDL을 업데이트하면됩니다. 따라서 한 응용 프로그램에 대해 하나의 soapUI 프로젝트 만 작성하십시오.

그런 다음 테스트 스위트 및 테스트 사례를 만들어야합니다.

하나의 회귀 테스트 스위트에서 모든 서비스의 주요 플로우 (성공 시나리오)를 포함하십시오. 웹 서비스의 요청은 논리적 인 비즈니스 흐름에 따라 정렬되어야합니다. 예를 들어 온라인 상점의 웹 서비스를 테스트하는 경우 먼저 항목을 검색 한 다음 구입해야합니다. soapUI 테스트 내에서 논리적 비즈니스 주문을 유지하면 각 테스트 단계마다 단일 전역 변수를 쉽게 설정할 수 있습니다. 즉, 첫 번째 단계에서 항목 X를 검색 한 다음 동일한 항목을 구매하면이 방법으로 항목 X의 전역 변수를 설정할 수 있습니다. 이러한 soapUI 프로젝트를 유지 관리하거나 확장하는 것이 더 쉽습니다. 데이터 소스를 작성하고 변수 (온라인 스토어 예제에서 다른 항목)를 수집하고 루프 내의 해당 항목에 대한 대소 문자를 구분할 수 있습니다.

Answer 2

soapui로 테스트 스위트를 만들고 젠킨스로 테스트 결과를보고하는 것이 좋습니다.

젠킨스와 genrate xml 테스트 결과 파일을 사용하여 soapui 테스트 및 fitnesse 테스트를 실행할 수 있습니다. 이 설정은 end2end 테스트를 빌드 할 때 정말 유용합니다. Jenkins와 함께 모든 테스트 세트 또는 테스트 스위트를 묶어서 테스트 결과를 제시하고 보존 할 수있는 좋은 방법이 있습니다.

작업 구성 요소에 집중할 때 스프린트 또는 전체 응용 프로그램에서 작업을 완료하는 것이 end2end 작업 테스트에 막대한 노력을 투자 할 정도로 안정적이지 않은 경우 이미 soapui 테스트를 별도로 수행하는 데 집중해야한다고 생각합니다.