테스트 가능한 요구 사항을 정의하기 위한 BP 사례는 Lewis 책에서 제공됩니다.
속성 설명 테스트 관점은 일반적으로 완전하고 포괄적입니다. 사용자 작업 또는 시스템 세부 정보에 중점을 둡니다. 테스터는 테스트 목표, 테스트 단계 및 예상 결과를 포함하는 테스트 사례를 작성하고 시스템을 테스트하고 통과 여부를 확인해야 합니다. 다른 상위 또는 세부 요구 사항과 충돌해서는 안 됩니다. 테스터는 일관된 요구 사항을 기반으로 테스트 사례를 작성해야 합니다. 수정할 수 있습니다1. 요구 사항을 찾고 수정할 수 있어야 합니다. 즉, 독립형이어야 합니다. 2. 요구 사항 관리 도구에 한 번만 표시되어야 합니다. 즉, 반복되지 않아야 합니다. 3. 기록에 대한 고유 식별자가 있어야 합니다. 테스터는 요구 사항이 변경될 때 테스트 사례를 수정할 수 있어야 합니다. 추적 가능 1. 각 요구 사항은 원본에 다시 연결되어 테스트, 설계 및 결함 요소로 전달되어야 합니다. 2. 각 요구 사항은 여러 요구 사항을 포함하지 않아야 합니다. 테스터는 관련 테스트 사례, 테스트 실행 및 기록된 결함에 대한 요구 사항을 추적해야 합니다. 정확성 (1) 빌드할 기능을 정확하게 설명해야 하고, (2) 비기능 속성을 설명하고 측정해야 하며, (3) 시스템 요구 사항 또는 요구 사항을 참조해야 하고, (4) 검토하고 승인해야 합니다. 제약 조건 테스터는 올바른 요구 사항으로 테스트 사례를 작성해야 합니다. 실행 가능은 리소스와 시간 내에서 달성 가능해야 합니다. 테스터는 현실적인 요구 사항에 대한 테스트 사례를 작성해야 합니다. 필수는 알려진 기관에서 가져와야 합니다. 비즈니스, 사용자, 컴플라이언스, 표준, 정부 규정 테스터는 필수 요구 사항(예: “원하지 않음”)에 대한 테스트 사례를 작성해야 합니다. 높음 – 다음 릴리스에 포함되어야 함, 중간 – 향후 릴리스(필요한 경우)를 기다릴 수 있음, 낮음 – 테스터가 요구 사항에 따라 테스트 사례 작성의 우선 순위를 지정할 수 있도록 하는 것이 가장 좋습니다. 검증 가능은 테스트, 검사, 시연을 통해 올바른 구현을 검증할 수 있어야 합니다. 테스터는 실제로 테스트할 수 있는 테스트 케이스를 작성해야 합니다.
속성 설명 테스트 관점 예제 더 나은 예제 구조 요구 사항은 클라이언트가 이해할 수 있는 간단하고 명확하며 간결한 언어로 작성되어야 합니다. 독자는 설명에 도달할 수 있어야 합니다. 테스터는 요구 사항을 하나 이상의 테스트 사례로 변환할 수 있어야 합니다. 요구 사항이 명확하지 않으면 테스트 사례도 명확하지 않습니다. 자명하다 자명하다1. 그렇지 않으면 비워두고 조건의 모든 잘못된 결과에 대한 결과를 지정해야 합니다. 테스터는 양수 및 음수 조건을 지정해야 합니다. 주문에는 배송 주소가 포함되어야 합니다. 주소가 누락된 경우 어떻게 합니까? 주문에는 배송 주소가 포함되어야 합니다. 배송 주소가 누락된 경우 “배송 주소를 지정해야 합니다.”라는 메시지가 표시됩니다. 2. 참조의 모호성 모든 참조는 명확하게 정의되어야 합니다(약어 포함). 테스터는 알려진 참조 및 컨텍스트를 기반으로 테스트 사례를 작성할 수 있어야 합니다. 계정 잔액에 구매 금액을 추가합니다. 이 숫자는 양수여야 합니다. 어떤 번호? – 구매 금액 또는 계정 잔액(또는 둘 다)? 계정 잔액에 구매 금액을 추가합니다. 구매 금액은 양수여야 합니다. 3. 행동의 범위는 조건으로부터 발생하는 모든 행동을 명확하게 정의해야 합니다. 테스터는 모든 작업을 테스트하기 위해 테스트 케이스를 작성해야 합니다. 회원 치과 의사 또는 보장 = 1인 경우 제출된 금액을 지불하고 치과 의사 기록을 업데이트하고 환자 기록을 업데이트하고 메시지 1을 인쇄합니다. 그러나 재정의 코드 = 2이면 메시지 2를 인쇄합니다. 마지막 문장은 메시지 2만 인쇄하라는 의미입니까? Member Dentist 또는 Coverage = 1인 경우 제출된 금액을 지불하고 메시지 2를 업데이트합니다. 치과 의사 기록, 환자 기록 업데이트 및 메시지 인쇄 1. 범위 코드 = 2이면 메시지 2만 인쇄됩니다. 4. 생략 모든 조건 및 요구 사항 세부 사항을 지정해야 합니다. – 영향이 없는 원인 모든 원인에는 잘 정의된 결과가 있어야 합니다. 테스터는 원인에 따라 결과가 발생해야 하는 테스트 작업에 대한 테스트 사례를 작성할 수 있어야 합니다. 코드 1~4는 메시지를 생성합니다. 코드는 5일 수도 있습니다. 마지막 문장이 이유입니다. 효과는 무엇입니까? 코드 1~4는 “메시지 A”를 생성합니다. 코드 5는 “메시지 B”를 생성합니다. – 원인 없는 결과 모든 결과에는 원인이 있어야 합니다. 테스터는 잘 정의된 조건을 기반으로 테스트 사례를 작성할 수 있어야 합니다. 이 메시지가 가끔 나타납니다. 이것은 효과입니다. 이유가 무엇입니까? 사용자가 지난 30분 동안 애플리케이션에 액세스하지 않으면 “시간 초과” 메시지가 나타납니다. – 결석 사유 모든 사유가 명확하게 정의되어야 합니다. 테스터는 테스트에 대한 모든 이유를 포함하는 테스트 케이스를 작성할 수 있어야 합니다. 빨간불을 달리면 티켓이 나옵니다. 또 다른 부분은 당신도 잡혀야 한다는 것입니다. 빨간불을 달리다가 잡히면 티켓을 받게 됩니다. – 누락된 영향 모든 원인에는 명확하게 정의된 영향이 있어야 합니다. 테스터는 원인과 관련된 모든 작업을 포함하는 테스트 사례를 작성할 수 있어야 합니다. 거부는 계정이 초과 인출되었는지 확인합니다. 누락된 역할 중 하나는 클라이언트에 알리는 것입니다. 계정이 초과 인출된 경우 수표를 거부하고 고객에게 알립니다. – 완전히 생략 모든 요구 사항 세부 정보를 지정해야 합니다. 자명하다 자명하다 5. 모호한 연산자 모든 연산자(or, and)는 명확하게 정의되어야 합니다. – 또는 “또는”의 사용과 일치합니다. 또한 포괄(inclusive), 배타(exclusive), 유일(unique)의 세 가지 의미를 갖는 “or”의 의미를 명확하게 정의한다. 테스터는 “또는”이 실제로 무엇을 의미하는지에 대한 테스트 사례를 작성해야 합니다. 요구 사항이 일관되게 작성되면 A 또는 B가 C를 생성하는 것이 더 쉽습니다. A 또는 B이면 C입니다. – 그리고 “and”의 사용과 일치합니다. 테스터는 “and”를 테스트하기 위해 테스트 케이스를 작성해야 합니다. A와 B가 모두 참일 때 C를 생성하도록 요구 사항을 일관되게 작성하면 더 쉬울 것입니다. A와 B라면 C. – 복합 연산자 연산자가 복합 연산자, 즉 “and”와 “or”의 조합인 경우 의미가 명확하게 정의됩니다. 테스터는 복합 연산자를 테스트하기 위해 테스트 케이스를 작성해야 합니다. 요구 사항이 명확하지 않으면 테스트 사례도 명확하지 않습니다. A 또는 B와 C가 D를 생산하는 경우. “만약 (A 또는 B) 및 C가 D를 생성한다면? 또는 A 또는 (B 및 C)가 D를 생성한다면? If (A 또는 B) 및 C가 D를 생성한다면? 6. 부정 조건에 부정이 있을 때 명시적으로 정의하십시오. C?” 또는 B이거나 A가 아니면 C? A가 참이 아니거나 B가 참이면 C입니다. – 불필요한 부정 불필요한 부정을 피하십시오. 불필요한 네거티브는 혼란을 야기하고 불분명/불완전한 테스트 사례를 초래할 수 있습니다. 금액이 $75 이상인 경우 무단 게시가 허용되지 않습니다. 금액이 $75 이상인 경우 게시하기 전에 승인을 받아야 합니다. – 이중 부정 이중 부정을 피하십시오. 즉, 혼동을 일으킬 수 있습니다. 가능할 때마다 문서화를 위해 긍정적인 진술을 사용하십시오. 이중 부정은 혼란스럽고 불분명하거나 불완전한 테스트 케이스로 이어질 수 있습니다. John이 결석하거나 지각하지 않으면 개근 상을 받게 됩니다. John이 항상 거기에 있고 항상 제시간에 있다면, 그는 개근 상을 받을 것입니다. 7. 모호한 진술 – 동사는 모든 동사의 진정한 의미를 명확하게 정의합니다. 모호한 동사, 즉 특정 동작이나 알고리즘은 모호하고 불완전한 테스트 사례로 이어질 수 있습니다. “월말이면 벌어들인 이자를 계산하라” 이자는 어떻게 계산되는가, 즉 알고리즘은 무엇인가? 월말일 경우에는 단리 5%를 적용하여 이자를 계산합니다. – 변수는 모든 변수의 의미를 정의합니다. 모호한 변수는 모호하고 불완전한 테스트 사례로 이어질 수 있습니다. 이자 금액이 $100보다 크면 고객에게 알림을 보냅니다. 어떤 종류의 관심? 발생이자? 이자를 얻었습니까? 발생한 이자 금액이 $100보다 크면 고객에게 알림을 보냅니다. – 형용사는 형용사를 명확하게 정의합니다. GUI 이미지가 큽니다. GUI 이미지는 “2×3″이어야 하며 주문 창의 오른쪽 상단 모서리에 있어야 합니다. – 부사는 모든 부사를 수량화합니다. 모호한 부사는 모호하고 불완전한 테스트 사례로 이어질 수 있습니다. 트랜잭션 삭제는 신속하게 처리되어야 합니다. 빠름의 의미 삭제 트랜잭션 처리 시간은 3초 미만이어야 함 8. 빌트인 가정은 작성자가 가정하는 정보를 피함 정보가 요구 사항 작성자의 헤드에 있으면 테스터가 테스트 케이스를 작성할 수 없음 예외는 버전 1.0과 동일한 방식으로 처리됨 $10,000 자동차, (2) $3,200 스테레오, (3) $6,300 보트 John이 $10,000를 상속받는 경우, 즉, 어떤 순서로 John이 돈이 충분하면 $3,200 스테레오와 $6,300 보트를 구입하고 나머지는 저장합니다. 10. 기타 명확하지 않습니다. 테스터는 기타를 테스트할 수 없습니다. 거래 1인 경우 고객의 기록을 업데이트하고, 고객의 명세서를 인쇄하는 등 기타 요점은 무엇입니까? 거래 1인 경우 다음 처리가 발생합니다. – 고객의 기록을 업데이트합니다. – 고객의 명세서를 인쇄합니다. 테스터는 무엇이 예시이고 요구 사항이 무엇인지 알아야 합니다. 개인 데이터(예: 이름, 주소, 직업)는 가석방자 모니터링 시스템에 의해 유지되어야 합니다. 가석방 모니터링 시스템은 개인 데이터(예: 이름, 주소, 직업)를 유지해야 함 12. 일시적 모호성 시간에 대한 모호한 참조를 피함 시간이 필요할 때 테스터는 테스트 시 이를 설명할 수 있어야 함 수락된 트랜잭션은 나중에 데이터베이스에 게시됨 화면은 최대 15개의 비행기를 처리할 수 있습니다. 15번째 비행기는 어떻습니까? 참고: Bender RBT, Inc. #포트폴리오2020 #요 구사항