수락 테스트 사례 작성

우리는 SCRUM 프로세스에 테스트 프로세스를 통합하고 있습니다. 나의 새로운 역할은 나중에 자동화하기 위해 웹 응용 프로그램의 승인 테스트를 작성하는 것입니다. 테스트 사례를 작성하는 방법에 대해 많이 읽었지만 복잡한 웹 응용 프로그램에 대한 테스트 사례를 작성하는 실질적인 조언은 없었으며 대신 적용하기 어려운 충돌 원칙을 던졌습니다.

• 테스트 사례는 짧아야합니다. CMS를 예로 들어 보겠습니다. 짧은 테스트 사례는 입력 및 출력을 쉽게 유지 관리하고 식별 할 수 있습니다. 그러나 일련의 긴 작업 (예 : 문서 추가, 다른 사용자에게 알림 보내기, 다른 사용자가 대답, 문서 상태 변경, 사용자에게 통지)을 테스트하려면 어떻게해야합니까? 오히려 테스트 사례가 완전한 시나리오를 나타내야한다고 생각합니다. 그러나 이것이 어떻게 지나치게 복잡한 테스트 문서를 생성하는지 알 수 있습니다.

• 테스트는 입력과 출력을 식별해야합니다. : 서로 다른 동작을하는 많은 상호 작용 필드가있는 긴 양식이있는 경우 어떻게해야합니까? 모든 것에 대해 하나 또는 하나에 대해 하나의 테스트를 작성합니까?

• 테스트 사례는 독립적이어야합니다. 그러나 업로드 작업을 테스트해야 연결 작업이 성공해야하는 경우 어떻게 적용 할 수 있습니까? 테스트 케이스 작성에 어떻게 적용됩니까? 각 작업에 대해 테스트를 작성해야하지만 각 테스트는 해당 종속성을 선언하거나 각 테스트에 대한 전체 시나리오를 다시 작성해야합니까?

• 테스트 사례는 가볍게 문서화되어야합니다. 이 원칙은 애자일 프로젝트에만 적용됩니다. 그렇다면이 원칙을 이행하는 방법에 대한 조언이 있습니까?

수용 테스트 사례를 작성하는 것이 간단 할 것이라고 생각했지만, 내가 결정해야 할 모든 결정 (FYI : 저는 전문 테스터가 아닌 개발자입니다)에 압도당했습니다. 따라서 제 주요 질문은 복잡한 응용 프로그램에 대해 유지 관리 가능한 승인 테스트 사례를 작성하기 위해 어떤 단계 또는 조언을 가지고 있는지입니다. 감사합니다.

편집 : 내 질문을 명확히하려면 : 합격 테스트는 요구 사항에서 시작하여 전체 응용 프로그램을 블랙 박스로 간주해야한다는 것을 알고 있습니다. 내 질문은 테스트 문서를 작성하고 테스트 사례를 식별하며 테스트 간의 종속성을 처리하는 복잡한 웹 응용 프로그램의 실제 단계와 관련이 있습니다.

내 수용 스위트에서 기술 특정 컨트롤을 사용하지 않았습니다. 즉 웹 응용 프로그램의 경우 CSS를 사용하지 마십시오 .html 요소를 사용하지 마십시오 양식을 작성 해야하는 경우 SUT을 실제 수락 테스트가 아닌 SUT 설정 단계로 설정하십시오.

나는 수용을 위해 오이를 사용하고 다음을 가지고 있습니다.

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

이 예제는 웹 애플리케이션으로 돌아 왔지만 수락 테스트가 아닌 SUT을 설정하는 단계가 사용되므로 테스트를 사용하여 데스크탑 애플리케이션에 대해 테스트 할 수 있습니다.

이 테스트는 구매가 끝난 후 진행됩니다.

생성-> 확인-> 지불-> 영수증 인쇄

위의 테스트는 지불 단계에 대한 것이고 다른 단계는 다른 테스트에서 설정됩니다. 응용 프로그램이 데이터 또는 http 작업을 사용하여 이러한 상태로 설정할 수 있기 때문에 지불에는 확인 단계를 수행하고 확인은 수행됩니다. 순간에 약간 부서지기 쉬운 단계를 생성합니다.

먼저 수락 테스트 를 정의해야합니다 .

당신이 설명하는 것은 통합 또는 시스템 테스트 입니다.

따라서 Wikipedia에 대한 정의에 100 % 동의하지는 않지만 여전히 유효합니다.

기본적으로 승인 테스트의 목적은 사용자가 구축 한 소프트웨어를 사용하는 '비즈니스'프로세스가 실제로 의도 한대로 작동하며 실제 데이터와 함께 목적에 부합하는지 확인하는 것입니다. 따라서 단위 테스트 또는 나머지 테스트와 같은 테스트 사례를 작성하지 마십시오. 같은 방식으로 제작해서는 안됩니다.

물어볼 질문은 "시스템은 어떻게 사용됩니까?"입니다. 사용 방법을 테스트 해 봅시다. 물론 이제 엔지니어링 모자를 다시 착용하고 비즈니스 요구 사항을 종교적으로 검토하여 테스트 사례를 도출합니다. 비즈니스 요구 사항을 잘 작성했다고 가정합니다.

그렇지 않은 경우, 너무 늦지 않은 경우 사용자 또는 해당 담당자 (및 비즈니스 분석가 및 기술 설계 담당자)와 함께 소프트웨어가 비즈니스 용어로 제공 할 것으로 예상되는 내용을 기록해야합니다 ( 너무 늦었다는 명백한 경고가 있지만, 결코 늦지 않게 시작하는 것이 좋습니다. 물론 새로운 기능을 도입하지는 않습니다. 이것이 테스트 사례가 될 것입니다.

그것에 관한 또 다른 방법은 (이러한 문서가있는 경우) 사용자 설명서를 읽는 것입니다. 이 단계는 실제 비즈니스 요구 사항에서 제거 된 단계이므로 다른 모든 것이 실패하는 경우에만 사용하십시오.

당신이 자동차를 사러 갈 때, 당신은 일반적으로 후드 아래에 깊숙이 가지 않습니다 (당신이 자동차 정비공이 아닌 한). 바퀴에 앉아서 편안함, 사용성, 외모, 소리 등을 확인하십시오. 당신은 일반적으로 차가 당신의 손에 있어야한다면 (적어도 새로운 차를 위해), 일반적으로 안전하고 잘 세워져 있습니다 (보증이 있습니다, 당신은 집에 일을했고 사양을 보았습니다 ...). 이제이 차가 앞으로 몇 년간 운전하고 싶은 차인지 확인합니다.

소프트웨어와 동일합니다.

상충되는 정보는 실망스럽고 특정 상황에 일반화하여 적용하기가 어려울 수 있습니다. Ergo, 상황에 가장 잘 맞는 것을해야 할 수도 있습니다.

나는 긴 테스트 문서를 좋아하는 팬이 아니며 소규모 프로젝트에 시각적 효과를 매우 효과적으로 사용했습니다. 해봐? 텍스트 만 사용하는 대신 플로우 차트 (또는 상태 다이어그램과 같은 다른 UML 다이어그램)처럼? 입력, 출력, 조건, 루프, 레인, 상태, 다른 구성 요소와의 상호 작용 등을 표시 한 다음 기준에 따라 성공, 실패, 전송, 기타 (?) 여부를 나타냅니다.

처음에는 약간의 작업이 될 수 있지만 장기적으로 제정신을 유지하는 데 도움이 될 수 있습니다. 어떤 방법을 선택하든 더 많은 방법으로 작업할수록 더 잘 얻을 수 있습니다.

HTH와 행운을 빕니다!

KM

좋은 기준을 이미 정했다고 생각합니다. 두 번째 요점은 테스트 범위를 정의하는 좋은 방법이며 오류 조건 및 버그 수정을 테스트하는 것이 좋습니다 (모든 버그 수정에는 적어도 하나의 새로운 단위 테스트가 포함됨). 그것은 지금 압도적으로 보일지 모르지만, 그냥 뛰어 들고 약간의 경험을 얻은 후에 좋은 시험을 만드는 것이 더 쉬워 질 것입니다.