TestRail

TestRail은 gurock( is an Idera, Inc. ) 에서 만든 테스트케이스 도구로 이번에 사용 결정되어 빠르게 파악하고자 정리해본다.

테스트 레일 제품 페이지, 유저 가이드,  그리고 주요 기능(들) - 한눈에 들어오는 FastTrack, 실시간 추적, 리소스관리(리포팅), JIra연동, 그리고 Customizable 까지

 

테스트케이스는 어떻게 만들어야 효과적일까? 테스트레일은 테스트 슈트. 테스트 케이스, 섹션 등으로 테스트케이스를 관리한다.
테스트 용어집 Jon Reynolds   라이브데모 바로가기 매주 화요일 오전 11시(EST) 인데 한국 시간으로 수요일 자정이네
                                                                                                 (11:00 AM (11:00) EDT = 0:00 AM (0:00) Next Day GMT +09)

일단 영상에서는 테스트케이스(의미), 생성과 조직화, 필드와 템플릿, 테스트 스텝과 공유, 삭제, 등등을 다룬다.

테스트케이스 종류 (싱글, ) 섹션은 테스트케이스의 모음(a collection of test cases)으로 프로젝트 모듈이나 영역에 따라 생성한다.  [Sections and sub-sections are often created for specific project modules or areas of your product) 참고 ] 
단, 프로젝트 크기나 성격에 따라 다를 수 있다. 실례로 아래와 같이 조건>설치>업데이트>튜토리얼 등등으로 세션을 구성했다.

출처 테스트레일

 테스트케이스는 3가지 옵션인데 프로젝트별 1개를 권장하지만 케이스가 다양하므로 적절히 사용하라고 하는데... 관련영상(0:23~)

권고하는 테스트케이스(Use a single repository for all cases (recommended)는 단일레파지토리내 모든 케이스이며 세션으로 조직화 가능 TC는 버전닝을 할수 있어 일반적으로 좋은 듯 하며 한 번 실행하는 테스트에 적용 멀티 브랜치 사용하는 경우 Use a single repository with baseline support 멀티플 버전을 동시에 실행하는 경우, 단일 레파지토리에서 베이스라인외 여러 옵션을 테스트하는 경우, 다수 프로젝트에서 다수 버전 테스트를 진행하여 배포가 이루어지는 경우 BaseLine   use a single repository with the additional option of creating baselines these baselines can be used to manage multiple versions of your test cases at same time  멀티 테스트 슈트를 사용하는 경우  Use multiple test suites to manage cases 기능과 어플리케이션 모듈별 케이스에 유용 로 나누는 경우, 큰 프로젝트 경우 (샘플을 못봐서 ...)

 

TestRail’s Project Types  Full Script

TestRail’s Project Types

welcome back in this video you will learn all about test rails different project types as discussed in the previous video in this series projects are an important aspect of test rail whenever you add a new project in test rail you can always choose between three different project types a single repository for all cases a single repository with baseline support and multiple test Suites. the type of project you use will define how you organize and manage your test cases within that project. for most teams a single test repository for all cases is recommended due to its simplicity with this project type. you will have a single area in which all of your cases for that project are stored and you can further divide them into sections and subsections using a single repository keeps things simple and allows for full end-to-end testing within a single run while also maintaining flexibility around concurrent testing with versioning using milestones and test plans You can also use a single repository with the additional option of creating baselines. these baselines can be used to manage multiple versions of your test cases at the same time. this is ideal if you need additional version controls to test multiple product releases in parallel. with this type you create a master set of test cases then can split them into different baselines which allow you to make changes to the test cases. in the baselines without affecting the master test cases in earlier versions of test rail the multiple Suites project type was the only project type available . this option is still available but should be reserved for teams that require much stricter divisions between different testing areas in their system . multiple Suites gives you another logical division point within a project for splitting your tests into separate project branches features or testing areas. this approach works well for many teams but does have limitations when creating runs that would be larger in scope beyond the cases included in a single suite. users can always change the project type when editing an existing project or adding a new one in this video series . we will primarily demonstrate the basics of test rail with the default single repository type. you can find more detailed information on the different project types and how they can be used in the documentation links in the video description below that is all for now keep watching our videos to learn more on how to use test rail

다시 오신 것을 환영합니다 이 비디오에서는 다양한 프로젝트 유형의 테스트 레일에 대해 모두 배울 것입니다. 이 시리즈의 이전 비디오에서 논의된 것처럼 프로젝트는 테스트 레일의 중요한 측면입니다. 테스트 레일에 새 프로젝트를 추가할 때마다 항상 세 가지 프로젝트 유형 중에서 선택할 수 있습니다. 모든 경우에 대한 단일 리포지토리 기준선 지원 및 여러 테스트 제품군이 있는 단일 리포지토리. 사용하는 프로젝트 유형은 해당 프로젝트 내에서 테스트 케이스를 구성하고 관리하는 방법을 정의합니다. 대부분의 팀의 경우 이 프로젝트 유형의 단순성으로 인해 모든 경우에 대해 단일 테스트 리포지토리가 권장됩니다. 해당 프로젝트에 대한 모든 사례가 저장되는 단일 영역이 있으며 이를 섹션과 하위 섹션으로 더 나눌 수 있습니다. 단일 리포지토리를 사용하면 작업을 단순하게 유지하고 이정표 및 테스트 계획를 이용하는 단일 실행으로 완전한 종단 간 테스트를 진행할 수 있다 기준선을 생성하는 추가 옵션과 함께 단일 리포지토리를 사용할 수도 있습니다. 이러한 기준선을 사용하여 동시에 여러 버전의 테스트 사례를 관리할 수 있습니다. 여러 제품 릴리스를 병렬로 테스트하기 위해 추가 버전 제어가 필요한 경우에 이상적입니다. 이 유형을 사용하면 테스트 케이스의 마스터 세트를 생성한 다음 테스트 케이스를 변경할 수 있는 다른 기준선으로 분할할 수 있습니다. 테스트 레일의 이전 버전에서 마스터 테스트 케이스에 영향을 주지 않고 베이스라인에서 다중 스위트 프로젝트 유형이 사용 가능한 유일한 프로젝트 유형이었습니다. 이 옵션은 계속 사용할 수 있지만 시스템의 여러 테스트 영역 간에 훨씬 더 엄격한 구분이 필요한 팀을 위해 예약해야 합니다. 다중 제품군은 테스트를 별도의 프로젝트 분기 기능 또는 테스트 영역으로 분할하기 위해 프로젝트 내에서 또 다른 논리적 분할 지점을 제공합니다. 이 접근 방식은 많은 팀에서 잘 작동하지만 에 포함된 사례를 넘어 범위가 더 큰 실행을 생성할 때 제한이 있습니다. 싱글 스위트. 사용자는 이 비디오 시리즈에서 기존 프로젝트를 편집하거나 새 프로젝트를 추가할 때 항상 프로젝트 유형을 변경할 수 있습니다. 기본 단일 저장소 유형을 사용하여 테스트 레일의 기본 사항을 주로 보여줍니다. 다양한 프로젝트 유형과 사용 방법에 대한 자세한 정보를 찾을 수 있습니다. 아래 비디오 설명의 문서 링크에서 지금은 전부입니다. 테스트 레일 사용 방법에 대해 자세히 알아보려면 비디오를 계속 시청하십시오.

 

테스트케이스는 비교적 쉽게 생성할 수 있다.
테스트 섹션 만들고 아래에 쭉 테스트케이스(타이틀)을 쭉 넣어준다. 그리고 중간에 섹션을 추가한 후 이전 작성한 테스트케이스를 가지고 올수도 복사할 수도 있다. 
이후 세션 하위 테스트 케이스로 들어가서 타이틀외 템플릿 등 채운다. (간단해서..생략.)

그런데 테스트할 때 브라우저별 모바일 디바이스별 선택은 어디서 하는지 맹붕이 왔다. 어디냐. 분명 Test Plan이였는데

 

 

실제로  기존 테스트케이스를 불러오려면 양식을 맞추면 되는데