제 질문이 약간 어리 석을 수 있습니다.여러 사용자 역할 테스트
우리 팀은 3 가지 다른 User Roles에 의해 사용되는 웹 응용 프로그램을 테스트해야합니다. 먼저 사용자 스토리를 기반으로 테스트 사례를 작성합니다. 내 문제는 각 사용자 역할에 대해 3 가지 테스트 사례를 만들고 싶지 않다는 것이다. 테스트 케이스를 작성하고 나중에 테스트 할 때 많은 시간이 필요하다고 생각합니다.
Total Test Cases Number = User Stories x Test Cases Per User Story x User Roles Number.
또한 새로운 사용자 역할이 약간의 차이점을 제외하고는 중복되기 때문에 나중에 새로운 사용자 역할을 만들면 새로운 테스트 사례를 만들고 싶지 않습니다.
이 상황을 더 효과적으로 관리 할 수있는 방법이 있습니까? 사전에
감사합니다.
Single Responsibility Principle?
역할에 따라 완전히 다른 이야기를 얻지 않는 한 사용자 스토리를 별도로 코드화하고 테스트하십시오.이 경우에는 뚜렷한 스펙이 있으며 자체 테스트가 필요합니다.
코드 전선 (상황이 무엇이며 코드가 구현되는 방법에 따라 다름)에 대해서는 확신 할 수 없지만 테스트 관점에서 대답 할 수 있습니다 (2 년 전까지는 전통적인 폭포 시스템에서 절반 이상이 기민한).
우리가 테스트하는 웹 응용 프로그램은 3 가지 사용자 유형 (전역)과 3 가지 사용자 역할 (사이트의 버킷, 즉 이미지의 버킷으로 사용되는 사이트, "Lookup"EyeQ if 이상한). 따라서 가능한 9 개의 콤보 중 8 개는 사이트를 만들 수 있습니다. 현재의 회귀 절차 doc은 100 개 이상의 테스트 케이스를 가지고 있으며, 20 개 정도가 편집/생성/삭제 사이트입니다. 전체적으로 500 개 이상의 테스트 사례가 수동으로 실행됩니다 (자동화를위한 지속적인 노력이지만 UI 재부팅을 통해 시간이 걸립니다).
어쨌든 UI 변경으로 인해 수작업 절차 중 일부를 다시 작성해야했고 필자가 이전에 작성한 실수 (예 : 반복적 인 반복적 인 테스트 3 번 사용)를 피하려고 노력했습니다. 약간의 변화가있는 시간).
사례를 작성하는 전략에 충실하기보다는 반복적으로 (코딩에서 같은 용어가 적용됨) - 즉 패스마다 하나의 역할 유형 콤보를 사용하는 테스트 사례를 사용합니다. 동일한 테스트 케이스를 3 번 이상 작성하지 않고 각 역할/유형에 대해 개별적으로 실행하는 대신 프로 시저를 한 번 사용하고 끝에 몇 단계를 추가하십시오.
예를 들어, 테스트 케이스 : 테스트 케이스 1 SYS 관리자 : 사용자는 사이트 나에 오기 전에 그들이 무슨 짓을했는지
(내 응용 프로그램에서이 작업을 수행 할 수 있습니다 유형-역할 콤보의 8/9)을 만들 수 있습니다 프로젝트에 묶여 있지 않아 사이트를 만들 수 있습니다 (10 단계). 테스트 케이스 2 - 프로젝트 관리자가있는 sys admin이 사이트를 만들 수 있습니다 (같은 10 단계); 테스트 사례 3 - 계정 관리자가 사이트에 연결할 수 없음 (첫 번째 사례와 동일한 10 단계). 테스트 케이스 4- 계정 관리자가 proj 역할을 수행하면 site (동일 사이트)를 만들 수 있습니다. 테스트 케이스 5 ... 등
에내가 뭘 : 테스트 케이스 1 : 콤보 1 사용자로 10 단계를 수행을 단계 11 - 그 콤보로 로그 아웃 콤보 2 사용자로 로그인 1-10, 12 단계 - 콤보 3을 사용하는 사용자로 11 단계에서 다시 로그 아웃하고 1-10, ...을 반복하십시오.
차이 : 3+ 테스트 케이스 또는 30+ 단계 1 개 테스트 케이스 대 (100,이 경우) 실행될 20 단계
비록 걸러서 이것을 가지고 이하, 그것이 의존 당신의 문제 유형. 실제로 반복적 인 경우 (예와 같이) 최대한 많이 반복하십시오.
자동 테스트 프레임 워크를 얻을 때 이점은 입력을 위해 배열 객체 또는 구조체가있는 테스트 케이스 내에서 간단한 for 루프를 사용한다는 것입니다. 단점은 모듈화가되지 않는다는 것입니다 (고장이 났을 때 문제의 원인을 발견하는 데 30 초가 더 걸리지 만 제 의견입니다).
그런데 EyeQ는 위성 및 공중 이미지의 웹 보급을위한 도구이며 내 의견은 일반적으로 테스트 사례를 작성하는 데 더 적합합니다 (필자의 경우 수동 테스트를위한 워드 문서). 코드 테스트 (단위, 통합 등)는 다음과 같습니다. 벌레의 다른 양동이. – DYezek
혼동하지 않아도됩니다. 접근 권한 대 매트릭스를 만들기 만하면됩니다. 사용자 역할. 예 : - 원시 : 사용자 모듈 (사용자 권한) 칼럼 : 사용자 역할
어떤 사용자가 어떤 권한 유형이나 액세스 권한을 갖고 있는지 엑셀 시트에 표시하십시오. 이 유형의 순열 및 조합을 생성 할 수있는 도구를 다운로드 할 수도 있습니다.
여기에서 다운로드 할 수 있습니다.
https://testcasegenerator.codeplex.com/
은 정확한 방법으로 측정 permutaiion 및 조합에 대한 greate 도구입니다.
그래서 유사한 테스트 케이스를 여러 개 작성하는 것을 피할 방법이 없습니까? '응용 프로그램에 로그인 (Login to Application)'과 같은 사용자 스토리에서 사용자 역할별로 테스트 케이스가 필요합니까? 그 이유는 피하고 싶지만 이미 어렵다는 것을 알고 있습니다. 감사합니다. – Schaliasos
자동화 된 UAT 테스트와 당신은 소프트웨어의 디자인을 테스트하고있는 각기 다른 사용자 역할 (또는 TDD)으로 로그인 할 것인가? 이전처럼 들린다.이 경우 잘못된 방향으로 갈 수있다. 클릭 테스트 레코더, 폼에 대한 입력을 코드화 할 수있는 watin/selenium과 같은 브라우저 테스트 에이전트가 있습니다.이 작업은 롤 목록을 만들고 루프하고 롤 (또는 로그인/역할)을 일부 로그인 메소드로 전달하는 경우입니다. –