문제

저는 GUI를 테스트하는 문제를 해결하고 있는데 여기서 최선의 접근 방식이 무엇인지 완전히 확신할 수 없습니다.내 GUI는 전통적인 MVC 프레임워크를 사용하여 구축되었으므로 GUI 자체를 불러오지 않고도 GUI의 논리 부분을 쉽게 테스트할 수 있습니다.그러나 GUI 기능을 테스트할 때 GUI 구성 요소를 개별적으로 테스트해야 하는지 아니면 주로 시스템 기능 테스트에만 집중해야 하는지 잘 모르겠습니다.GUI 테스트에는 서버에 메시지를 보낸 다음 GUI에서 응답을 관찰하는 작업이 자주 포함되는 매우 복잡한 시스템입니다.처음에는 UI를 실제로 테스트하려면 전체 시스템을 실행해야 하기 때문에 기능 테스트가 여기로 가는 방법이라는 생각이 들었습니다.이 문제에 대한 의견을 보내주시면 감사하겠습니다.

감사합니다, Jeff

도움이 되었습니까?

해결책

환경(서버)의 복잡성과 GUI의 복잡성이라는 (적어도) 2가지 문제가 있습니다.

GUI 테스트를 자동화하기 위한 많은 도구가 있습니다.이들 모두는 다소 취약하며 레이아웃 변경에 직면하여 거의 지속적인 유지 관리가 필요합니다.이를 사용하면 얻을 수 있는 이점이 있지만 장기적인 이점입니다.

반면에 환경은 길들일 수 있는 영역이다.응용 프로그램이 종속성 주입/역전 기술(서버 구성 요소를 응용 프로그램에 '주입'하는 경우)을 사용하여 설계된 경우 관련 서버 인터페이스의 '모의'를 사용하여 테스트 사례를 스크립팅할 수 있습니다.

이 두 가지 기술을 결합하면 GUI 테스트를 자동화할 수 있습니다.

마지막 생각 - 행운을 빕니다!

다른 팁

제가 제공할 수 있는 기타 GUI 테스트 도구는 다음과 같습니다.소토웍스 화이트, 파이윈오토(PyWinAuto), 오토잇, 오토핫키.

GUI를 자동화하려고 할 때 염두에 두어야 할 한 가지 방법은 자동화를 염두에 두고 GUI를 구축하는 것뿐입니다.자신의 GUI가 프로젝트 초기에 테스트 가능성을 지원해서는 안 된다고 생각하고 테스트 요구 사항에 따라 자동화에 도움이 될 수 있는 모든 후크를 기꺼이 공개해야 한다고 생각하는 개발자를 크러시하세요.

MVC(남용되는 용어)의 스펙트럼 중 어디에 있는지에 따라 뷰 테스트는 뷰에 대한 올바른 입력에 대한 응답으로 올바른 모델 메서드가 호출되는지 확인하는 기계적 프로세스가 될 수 있습니다. 누가 알아.

MVC에서 발전된 많은 패턴이 있습니다. 소극적인 견해, 감독 컨트롤러)는 실제로는 사용자 입력을 발표자나 모델에 연결하기만 하면 되기 때문에(사용 중인 패턴의 정확한 변형에 따라) 테스트가 거의 필요하지 않은 뷰를 만들기 위해 노력하고 있습니다.

"GUI를 자주 테스트하려면 서버에 메시지를 보낸 다음 GUI의 응답을 관찰해야 합니다." 이 말은 나를 걱정하게 합니다.

나는 올바른 상호 작용이 발생하고 GUI가 적절하게 응답하는지 테스트하기 위해 서버의 모의 또는 스텁을 사용하여 GUI를 테스트해야 한다고 즉시 생각합니다.

서버의 자동화된 기능 테스트가 필요한 경우에는 이에 관련된 GUI가 필요하지 않습니다.

Mercury QuickTest Pro, Borland SilkTest 및 Ranorex Recorder는 일부 GUI 테스트 도구입니다.

애플리케이션이 웹 기반인 경우 다음과 같은 도구를 사용하여 테스트를 작성할 수 있습니다. 와틴 또는 셀렌.

응용 프로그램이 Windows .NET 기반인 경우 시도해 볼 수 있습니다. 하얀색.

나의 충고:전통적인 GUI 테스트는 잊어버리세요.너무 비싸요.테스트를 코딩하는 데는 많은 시간이 걸리고 도구는 실제로 안정적이지 않으므로 신뢰할 수 없는 테스트 결과를 얻을 수 있습니다.코드와 테스트 사이의 결합은 매우 강력하므로 유지 관리에 많은 시간을 소비하게 됩니다.

새로운 추세는 GUI 테스트를 무시하는 것입니다.Fowler의 ModelViewPresenter 패턴을 지침으로 참조하세요. 링크 텍스트

내가 말할 수 있는 가장 명확한 방법은 다음과 같습니다.

자동화된 GUI 테스트 작성에 시간을 낭비하지 마세요.

특히 MVC 앱으로 작업할 때 서버에 메시지를 보낼 때 올바른 메시지 번호가 돌아와 완료되었는지 확인할 수 있습니다.GUI가 메시지 ID를 올바른 문자열로 변환하는지 확인하기 위해 몇 가지 추가 사례 또는 다른 테스트를 완전히 추가할 수 있지만 해당 테스트를 한 번만 실행하면 됩니다.

우리는 프로젝트에 GUI 테스트를 통합했는데 부작용이 있습니다.그러나 개발자에게는 한 가지 중요한 설계 원칙이 있습니다. GUI 레이어를 최대한 얇게 유지하세요!

그 의미는 논리가 없다 GUI 클래스에서.입력 검증 등을 담당하는 프레젠테이션 모델에서 이를 분리합니다.

Unix 시스템에서 테스트하기 위해 테스트를 실행할 때 Xvfb 서버를 DISPLAY로 사용합니다.

시도해 보세요 복도 사용성 테스트.저렴하고 유용합니다.가장 가까운 복도로 가서 가장 먼저 지나가는 사람을 붙잡아 컴퓨터 앞에 앉히고 소프트웨어를 사용하게 하세요.그들의 어깨 너머로 지켜보면 그들이 무엇을 하려고 하는지, 무엇이 그들을 좌절시키는지 등을 알 수 있습니다.이 작업을 몇 번 수행하고 패턴을 확인하십시오.

당신이 찾고있는 것은 "수락 테스트"입니다. 당신이 사용하는 방법은 당신이 사용하고있는 프레임 워크, 어떤 응용 프로그램 유형을 만들고 어떤 언어로든 달라집니다.특정 기술과 위의 문구를 Google에 검색하면 사용할 수 있는 몇 가지 도구를 찾을 수 있습니다.

내가 발견했다 윈태스크 GUI 테스트를 수행하는 아주 좋은 방법입니다.OS가 UI의 각 요소를 참조하는 방식을 지속적으로 변경하지 않는 경우 WinTask는 UI 요소를 이름으로 처리하므로 레이아웃이 변경되더라도 UI 요소를 계속 누르거나 조정하거나 선택할 수 있습니다.

'GUI'의 'U'를 놓치지 마세요
내 말은:테스트하려는 것이 모두 제대로 작동하고 계획된 대로 작동한다면 다음을 따르십시오. 셉 로즈의 답변.

하지만 제발, 잊지 마세요 USER 인터페이스는 USERS를 생각해서 만들어야 합니다., 모든 사용자가 아니라 애플리케이션이 만들어진 대상 사용자입니다.따라서 모든 것이 제대로 작동하는지 확인한 후에는 애플리케이션을 사용할 수 있는 다양한 사용자 그룹을 대표하는 사용자로 구성된 팀과 함께 모든 단일 보기/화면/양식을 테스트에 넣으세요.고급 사용자, 관리자, MS Office 사용자, 낮은 컴퓨터 프로필 사용자, 높은 컴퓨터 프로필 사용자...그런 다음 모든 사용자의 비평을 듣고, 혼합하고, 필요한 경우 GUI를 다시 터치하고 GUI 사용자 테스트로 다시 돌아갑니다.

간단한 웹 기반 GUI 테스트를 위해서는 다음을 시도해 보세요. 아이매크로 (간단한 Firefox 플러그인은 전체 테스트를 다른 사람에게 보낼 수있는 멋진 기능이 있습니다.) Simple은 이니셜로 철자가 있습니다 ...

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top