Writign Web Form 테스트 케이스

Question

저는 소프트웨어 테스터가 아니지만 웹 애플리케이션에 대한 긴 고객 가입 양식에 대한 수동 사용자 승인 테스트 케이스를 작성해야합니다.

모든 양식 필드에 '양식'이 있다고 가정하고 테스트 케이스가 양식 기능을 확인하는 것으로 시작하는 출발점입니까? 입력 유효성 검사 등. 또는 각 폼 식별자가 올바른지 테스트 케이스를 작성해야합니까, 각 양식 필드가 존재하는지, 각 드롭 다운이 채워지는지 등 (새 빌드가 가능한 양식 요소/필드가 생성 될 때 추측 할 수 있습니다. 오류 있음 - 가능성은 없음).

많은 폼 요소에 대한 테스트 케이스를 작성하려는 경우 시간을 절약하기 위해 여러 가지 어설 션을 사용할 수 있습니다. "식별자 확인 : text1, text2, text3 등이 있으며 올바르다." 또는 폼의 모든 요소에 대해 하나의 테스트 케이스 여야합니다. 양식은 시간이 지남에 따라 많이 변하지 않을 것입니다.

여기에는 2 가지 유형의 테스트가 있다는 느낌이 들었습니다. 하나는 양식이 올바르게 작동하고 다른 하나는 실제로 기본적으로 올바르게 표시된다는 것입니다.

감사합니다.

Answer 1

모두 작업하는 요구 사항에 따라 다릅니다.

테스트 할 모든 필드가 있는지 (다른 사람이 테스트 중이기 때문에 이것이 테스트의 포인트가 아닌지) 확신 할 수 있으면 테스트를 거쳐야합니다.

a) 모든 것이 작동하고 b) 의도 한대로 작동한다는 것을 의미하는 모든 것을 테스트하는 경우 페이지의 양식, 내용 등을 검사하는 두 가지 부분으로 테스트를 분리하면됩니다. 요소와 모든 것을 고려하고 올바르게 작동하는지 테스트하는 파트 2가 있습니다. 2 부에는 "유효하지 않은 이메일 입력", "전화 번호 입력란에 글자 입력", "필수 입력란 비움"과 같은 필드 확인이 포함됩니다.

실용적인 이유 때문에 가능한 한 짧게 테스트 해 봅니다. 가능한 구체적으로 당신이 당신의 전체 테스트 케이스가 "실패"할 것이다 버그를 발견하면

• , 그것은 어떤 작업의 어떤 테스트 케이스가 많은 기능을 테스트하지 않습니다하지 않을 경우를 찾기 위해 나중에 명확입니다 : 여기에 몇 가지 이유입니다 단단히 연결되어 있지 않습니다. 예를 들어 필요성을 인식한다면 존재를 테스트하고 하나의 테스트 및 한 단계에서 필드의 기능이 작동하지 않으면 테스트가 "실패"하지만 테스트 캠페인을 쳐다 보면서 수행 할 수 없습니다 어떤 부분에 버그가 있는지 알지 못하고 실행을 자세히 검사하지 않아도됩니다.

• 수정 한 후에 다시 테스트해야하는 경우 수정을 확인하기 전에 수십 단계를 거치지 않아도됩니다.

• 사람들은

  물론

는이 손에 작업에 많이 의존 등, 그들은 무슨 일이 일어나고 있는지 잊어 버릴, 그들은 매우 긴 테스트 케이스를 실행해야하는 경우 초점을 잃게하는 경향이 어떤 것들은 훨씬 길거나 복잡한 테스트 케이스를 필요로하고, 다른 것들은 매우 간단 할 수 있습니다.

을하는 데 도움이

희망

Answer 2

UAT, IME, 응용 프로그램의 실제 최종 사용자가 TCS의 예상과 실제 결과를 포함하여도 처음부터 끝까지, 당신의 시나리오에 따라 수행 한 것이 전체 단계를 포함해야한다 , 예.

단계 1. 브라우저/브라우저가 시작됩니다 (단계 2). www.blah.com/blah.com으로 이동합니다. 단계 3. 로그인 필드를 클릭하고 (구체적으로 알아야 할 경우) 사용자 이름/필드가 선택되고 사용자 이름이 ..... 최종 경로까지 입력되어야 테스트 할 수 있습니다.

UAT 케이스를 실행하기 전에 기능 테스트를 수행 했으므로 반드시 UAT tcs의 각 필드의 유효성을 검사 할 필요는 없지만 UAT 전에 연기가 나거나 기능 테스트를 거쳤는지 확인하십시오.

필자는 테스트 케이스를 특정 부분으로 분할하는 것과 관련된 이전 포스터에 동의합니다. 물론 이는 정확히 무엇을하는지에 따라 다릅니다. TC1_Navigate to Page TC2_Login TC3 PersonalInfo 채우기 (또는 양식 섹션별로) TC4_Fill IncomeInfo ... blahblah.

첫 번째 이후의 각 tc에 대해 마지막 tc 단계부터 계속할 수 있습니다. "브라우저 열기"에서 # 1 후에 각 테스트 케이스를 시작할 필요가 없으며 모든 테스트를 하나의 테스트 세트로 함께 포함합니다 여러 테스트 케이스로 구성됩니다.

Answer 3

이 작업에는 Min P와 Dobromir Manchev가 제안한 두 가지 유형의 테스트를 작성할 수 있으며 세부 테스트 사례의 수는 테스트 수행자에 따라 다릅니다.

개인적으로 각 사례를 개별적으로 확인하는 것이 좋으며 문제를 찾아 내고 결국 다시 테스트하는 것이 더 쉽습니다.

시나리오 1 :
은 시험 01 - 사용자 이름 필드 - 설명 - 예상
- 아이디 잘못된 데이터 - - 설명 - 예상
- 그
시험 02처럼 테스트 위치, 크기, 색상, 뭔가이 있는지 확인 아이디 빈 입력 - - 필드가 지원되지 않는 데이터의 종류 (긴, 짧은, 특수 문자 등)
테스트 03을 받아 설명 - 예상
- 아이디 정확한 - - 정보 - 예상 필드 지원 빈 제출이
가 시험 04되었는지 확인,453,210 - 결국 어떤 데이터가 정확한지 그리고
시험 05 작동 방식을 경우 - 이메일 필드 - 설명 - 예상을
- 이메일 올바른 양식 - - 그
시험 06처럼 테스트 위치, 크기, 색상, 뭔가 설명 - 예상
- 필드가 name@mail.com과 같은 올바른 전자 메일 양식 만 지원하고 name @ mail, name @ mail을 올바르게 처리하는지 확인합니다. 등
시험 07 - ...

시나리오 2 :
시험 01 - 사용자 이름 필드 - 설명 - 예상 - 피드백
시험 02 - 이메일 필드 - 설명 - 예상 - 피드백
시험 03 - .. .

설명에 대한 설명은 테스트 사례의 목적 또는 매우 철저한 설명이 포함 된 간단한 설명으로이 필드를 채우는 데 달려 있습니다.예상 분야에서는 특정 테스트의 결과가 될 것으로 기대되는 것을 작성해야합니다. 시나리오 1에서는 간단한 작업이어야하며 (결과를 확인하십시오.) 시나리오 2에서 필드가 어떤 방식 으로든 올바른지 일반적으로 테스트하고 문제를 해결하기 위해 적절한 피드백을 기대합니다.

두 번째 시나리오는 작성하기가 더 쉽지만 결함은 다른 사람으로부터 정확한 정보와 피드백을 받기를 원합니다 (불만족 스럽거나 불충분하거나 결과가 다를 수 있음).

희망이 조금 더 도움이됩니다.