LambdaTest를 사용하여 브라우저 간 테스트를 더 효율적으로 만드는 방법

이 기사는 실제 브라우저 및 장치에서 무료로 자동화된 실시간 대화형 브라우저 간 테스트를 수행할 수 있는 브라우저 간 호환성 테스트 도구인 LambdaTest의 친애하는 친구의 지원을 받았습니다. 감사합니다!

소비자가 매일 몇 시간 동안 모바일 장치 앞에 앉아 있기 전에는 웹 디자이너가 싸워야 하는 수많은 브라우저와 운영 체제가 있었습니다. 따라서 브라우저 간 테스트의 개념이 새로운 것은 아닙니다.

웹 브라우저가 항상 웹 사이트를 동일한 방식으로 렌더링하거나 원래 의도한 방식으로 데이터를 처리하는 것은 아니기 때문에 브라우저 간 테스트는 오랫동안 웹 디자인 및 개발의 중요한 부분이었습니다. 그것은 배후에서 구축된 것이 웹사이트의 프론트엔드에서 적절하게 구현되도록 하는 유일한 방법입니다.

그러나 모든 브라우저, OS 및 장치를 직접 검토하려고 하면 빠르게 지루한 작업이 될 수 있습니다.

다행스럽게도 우리는 자동화가 왕인 시대에 살고 있으며 이제는 브라우저 간 테스트를 더 자주 수행할 수 있는 더 나은 방법이 있습니다. 따라서 이 프로세스를 자동화해야 하는 이유와 LambdaTest를 사용하여 자동화하는 방법에 대해 이야기해 보겠습니다.

브라우저 간 테스트를 처리하는 향상된 방법

사용자를 위한 웹사이트 구축을 시작할 때 사용자가 누구인지, 무엇을 필요로 하는지, 여행 과정에서 무엇에 응답할 것인지 설명합니다. 그러나 브라우저 선택으로 인해 사용자가 경험할 수 있는 다양한 결과를 언제 어떻게 해결합니까?

반응형 디자인은 이러한 차이점 중 일부를 완화하는 데 도움이 될 수 있지만 브라우저와 장치 간의 고유한 디스플레이 문제에 대한 만병통치약은 아닙니다.

웹 사이트에 대해 선택한 코드와 디자인이 사용자에게 부정적인 영향을 미치지 않도록 하려면 웹 디자인 프로세스 전반에 걸쳐 브라우저 간 테스트가 필수적입니다.

"

그리고 광범위한 브라우저 간 테스트가 수익에 부정적인 영향을 미치지 않도록 하려면 자동화가 올바른 방법입니다.

다음은 자동화된 테스트를 프로세스에 구축하는 데 도움이 되는 몇 가지 팁입니다.

브라우저 지원 차이점 숙지

다음은 시장 점유율에 따른 상위 웹 브라우저의 Statista에서 요약한 것입니다.

이제 여기에서 문제는 모든 브라우저가 웹사이트 데이터를 다르게 처리한다는 것이 아닙니다. 실제로 문제를 해결하는 것은 배후에서 브라우저에 전력을 공급하는 엔진입니다.

예를 들어 다음은 주요 웹 브라우저에서 사용하는 엔진입니다.

• Chrome은 Blink + V8을 사용합니다.
• Edge는 Blink를 사용합니다.
• Firefox는 Quantum/Gecko + SpiderMonkey를 사용합니다.
• Safari는 WebKit + Nitro를 사용합니다.
• Internet Explorer는 Trident + Chakra를 사용합니다.

이러한 엔진 중 다수는 동일한 코드를 다르게 렌더링합니다. 예를 들어 LambdaTest에서 생성한 이 실험을 살펴보세요.

date HTML 태그는 가장 많이 사용되는 태그 중 하나이지만 Chrome, Firefox 및 Opera는 테스트 영역 위의 상단 파란색 막대에 표시된 대로 완전히 지원하는 유일한 태그입니다. 그럼에도 불구하고 이러한 브라우저는 매우 다른 사용자 경험을 제공합니다.

예를 들어 위의 이미지는 Chrome에서 날짜 태그가 어떻게 보이는지 보여줍니다. 동일한 코드가 Edge에 표시되는 방식은 다음과 같습니다.

글꼴 스타일과 크기가 약간 다를 뿐만 아니라 날짜 선택 드롭다운이 표시되는 방식도 크게 다릅니다.

따라서 브라우저 간 테스트에 대해 생각하고 이러한 브라우저와 엔진 간의 꼬임을 해결하기 전에 주요 차이점을 숙지하십시오.

참고로 사용할 수 있는 도구는 Can I use…입니다.

가장 일반적으로 사용되는 구성 요소 및 기술에서 불일치를 찾을 수 있습니다. 예를 들어 CSS 그리드 레이아웃을 살펴보겠습니다.

대부분의 주요(그리고 일부는 그렇지 않은) 브라우저는 CSS 그리드 레이아웃(녹색)을 지원합니다. Internet Explorer(파란색)는 부분 지원을 제공하고 Opera Mini(보라색)는 전혀 지원하지 않습니다.

또는 성능과 해상도 면에서 훨씬 더 나은 WebP 이미지를 디자인에 더 많이 사용하려고 한다고 가정해 보겠습니다. 사용할 수 있는 것은 다음과 같습니다. 이미지 형식에 대한 브라우저 지원에 대해 알려줍니다.

최신 버전의 Internet Explorer 및 Safari(웹 및 모바일)는 이에 대한 지원을 제공하지 않습니다 . 따라서 WebP 이미지로 디자인하려는 경우 이러한 브라우저에 대한 해결 방법을 만들어야 합니다.

결론: 지금 시간을 내어 어떤 종류의 콘텐츠 또는 코드가 지원되는지 이해하면 처음부터 웹 사이트를 보다 효과적으로 구축할 수 있습니다.

전문가 팁: 참조용 브라우저 매트릭스 만들기

브라우저 렌더링과 지원 간의 차이점을 이해하는 것이 왜 그렇게 중요한지 알 수 있습니다. 그것들에 익숙해질수록 새로운 불일치가 발견되었을 때 해야 할 혼란이 줄어듭니다.

자신을 더 쉽게 만들려면 지금 이러한 모든 차이점에 대한 브라우저 매트릭스를 만드는 것이 좋습니다.

다음은 LambdaTest가 설계한 간단한 것입니다.

나만의 것을 만드는 것이 좋습니다. Can I use… 의 데이터를 활용할 수 있을 뿐만 아니라 자신의 프로젝트에서 발생한 지원 문제를 문서화할 수 있습니다.

이것은 또한 디자인할 때 우선 순위를 설정하는 데 도움이 됩니다. 예를 들어 지원되지 않는 기능이 웹사이트의 목표에 미치는 영향에 따라 사용할 가치가 있는 기능을 결정할 수 있습니다.

사이트가 활성화되면 이 스프레드시트를 준비하는 것도 유용할 것입니다. Google Analytics의 데이터를 사용하여 사용자가 주로 사용하는 웹 브라우저를 기반으로 디자인 선택의 우선 순위를 정할 수 있습니다.

모든 것을 수행하는 크로스 브라우저 테스트 도구를 얻으십시오.

구축하는 웹 사이트의 크기는 중요하지 않습니다. 모든 공개 사이트는 자동화된 브라우저 간 테스트 도구의 이점을 누릴 수 있습니다.

LambdaTest로 자동화할 때 특히 좋은 점은 사용자에게 옵션을 제공한다는 것입니다. 코드가 프론트엔드에 어떤 영향을 미치는지 확인하는 완전 자동화된 테스트에서 업데이트 및 버그 관리 작업을 용이하게 하는 반자동 작업에 이르기까지 프로세스를 자동화하고 최적화 하는 방법은 많습니다.

다음은 알아야 할 몇 가지 주요 기능입니다.

실시간 테스트: 버그 추적에 가장 적합

실시간 테스트는 두 눈으로 확인해야 하는 대상이 있을 때 유용합니다. 검토를 위해 클라이언트에게 디자인을 배송했는데 고객이 무언가가 옳지 않다고 주장하는 경우와 마찬가지로 정확한 구성을 사용하여 웹사이트를 검토할 수 있습니다. 또한 버그를 확인하고 영향을 받는 브라우저를 파악하는 데 도움이 됩니다.

Real-Time Testing 패널에서 사이트 URL을 입력한 다음 보기 사양을 선택합니다.

다음 중에서 선택하여 매우 구체적으로 지정할 수 있습니다.

• 맥 대 안드로이드,
• 기기 종류,
• 기기 버전,
• 운영 체제,
• 웹 브라우저.

테스트가 시작되면 다음과 같이 표시됩니다(물론 선택한 장치 유형에 따라 다름).

위에서 사이드바의 첫 번째 옵션을 통해 장치 보기를 빠르게 전환할 수 있습니다. 그렇게 하면 오류를 비교하거나 확인하려는 브라우저 보기가 몇 개 있는 경우 역추적할 필요가 없습니다.

다른 실시간 테스트 옵션은 대부분 실제로 발생한 컨텍스트 내에서 문제를 식별하고 보고하는 데 유용합니다.

위의 버그 추적 도구에서 페이지에서 오류가 발생한 지점을 정확히 찾아낼 수 있습니다. 그런 다음 사이드바에서 여러 도구를 사용하여 표시할 수 있습니다.

사용자는 스크린샷 및 비디오 옵션을 사용하여 더 큰 오류, 특히 사이트를 이동하거나 사이트에 참여할 때 발생하는 오류를 캡처할 수도 있습니다.

스크린샷 테스트: 수동 테스트 속도를 높이는 데 가장 적합

귀하 또는 귀하의 QA가 귀하의 웹사이트를 스스로 검토하지 못할 이유가 없습니다. 즉, 왜 프로세스를 필요 이상으로 오래 걸리게 합니까? LambdaTest의 Visual UI Testing 도구로 프로세스 속도를 높일 수 있습니다.

예를 들어 스크린샷 도구를 사용하면 비교할 모든 장치와 브라우저를 한 번에 선택할 수 있습니다.

테스트가 완료되면 요청된 모든 스크린샷이 한 곳에 표시됩니다.

여기에서 보거나 컴퓨터에 다운로드하거나 다른 사람과 공유할 수 있습니다.

프로젝트 및 버전/라운드별로 스크린샷을 구성할 수도 있습니다. 그렇게 하면 여러 번 수정 작업을 하고 이전 버전을 다시 참조하려는 경우 이전 반복의 모든 복사본이 여기에 존재합니다. (곧 설명할 회귀 테스트에서 스크린샷을 사용할 수도 있습니다.)

반응형 테스트: 모바일 우선 경험을 확인하는 데 가장 적합

정적 화면 캡처 이상을 확인해야 하는 경우 반응형 테스트를 통해 해결할 수 있습니다. 비교할 OS와 장치를 선택하기만 하면 도구가 모바일 브라우저에서 사이트의 전체 작동 버전을 채웁니다.

가능한 모든 브라우저에서 웹사이트의 디자인과 상호 작용을 검토할 수 있을 뿐만 아니라 사이트의 방향도 변경할 수 있습니다(가로로 전환할 때 문제가 나타나는 경우).

이 테스트 도구의 좋은 점은 뭔가 이상해 보이는 경우 버그를 발견하는 즉시 버그를 표시할 수 있다는 것입니다. 대화형 모바일 브라우저 바로 위에 이를 수행할 수 있는 버튼이 있습니다. 그러면 비용이 많이 드는 모바일 오류가 보고되고 더 빨리 해결됩니다.

스마트 테스트: 회귀 테스트에 가장 적합

눈은 많은 것을 감지할 수 있습니다. 특히 몇 주 동안 웹 페이지의 동일한 섹션을 보고 있을 때 그렇습니다.

따라서 사이트에서 변경 사항을 구현하기 시작할 때(개발 중, 출시 직전, 심지어 이후에도) 회귀 테스트는 잠재적으로 발견하기 어려운 문제를 포착하는 데 중요합니다.

이것은 무언가가 변경될 때마다 발생해야 합니다.

• 디자인의 일부를 수동으로 업데이트합니다.
• 코드는 백엔드에서 조정됩니다.
• 누군가 버그를 보고하고 수정 사항이 구현되었습니다.
• 소프트웨어가 업데이트됩니다.
• API가 다시 연결됩니다.

어떤 페이지와 해당 페이지의 어느 부분이 직접적인 영향을 받는지 알고 있다면 스마트 테스트를 통해 모든 것이 정상인지 확인하는 간단한 작업을 수행할 수 있습니다.

영향을 받는 페이지의 원본 스크린샷을 업로드한 다음 변경이 이루어지면 비교 이미지를 추가하기만 하면 됩니다. (여기서 스크린샷 도구가 정말 유용합니다.)

참고: Smashing Magazine 웹사이트에는 분명히 아무 문제가 없습니다. 그러나 위의 예에서 내가 한 것은 iPhone의 다른 버전에 대한 렌더링을 사용하는 것입니다. 분명히 회귀 테스트가 작동하는 방식은 아니지만 뭔가 잘못되었을 때 이 비교 기능이 어떻게 보이는지 보여주고 싶었습니다.

이제 이 기능이 멋진 이유는 다음과 같습니다.

이 단일 스크린샷을 통해 페이지의 두 버전이 더 이상 정렬되지 않는 위치를 확인할 수 있습니다. 따라서 스크린샷이 원래 동일한 브라우저 보기에서 가져온 것이라면 모든 요소를 ​​재정렬할 계획이 없었다면 문제가 될 수 있습니다.

나란히 비교 테스트를 사용하여 동일한 것을 확인할 수도 있습니다.

다시 말하지만, 스마트 테스트는 회귀 테스트 중에 문제를 빠르게 찾고 보고하는 데 도움이 됩니다. 당신에게 가장 적합한 방법을 찾으면 지금부터 가능한 한 빨리 이러한 문제를 해결할 수 있습니다.

자동화된 테스트: 대규모 문제 감지에 가장 적합

기술적으로, 우리가 지금까지 살펴본 모든 것에는 20개의 다른 브라우저 스크린샷을 동시에 처리하거나 모든 iOS 및 Android 장치에 대한 모바일 테스트 인터페이스를 한 번에 즉시 볼 수 있도록 하는 것과 같이 일종의 자동화가 내장되어 있습니다.

즉, LambdaTest 플랫폼에는 "자동화"라는 도구도 함께 제공됩니다. 그리고 이것이 하는 일은 2,000개 이상의 브라우저에서 클라우드에서 Selenium 테스트를 수행할 수 있도록 하는 것입니다. 새로운 기능인 "Lambda Tunnel"을 사용하여 로컬 호스트에서도 Selenium 테스트를 수행할 수 있습니다. 그렇게 하면 코드 변경 사항이 실제 적용되기 전에 어떻게 나타나는지 확인할 수 있습니다.

LambdaTest와 Selenium 테스트를 결합하면 많은 이점이 있습니다.

• 이는 브라우저 간 테스트를 대량으로 수행하여 브라우저 적용 범위를 늘리는 매우 효율적인 방법입니다(수동으로 수행할 수 없는 작업).
• 병렬 크로스 브라우저 테스트를 사용하면 자동화 테스트를 전체적으로 실행하는 데 소요되는 시간을 줄일 수 있습니다.
• Selenium 테스트는 선호하는 코딩 언어를 식별하는 것으로 시작하기 때문에 브라우저에 나타날 오류를 보다 지능적으로 감지할 수 있습니다.

물론 LambdaTest Selenium Automation Grid를 사용할 때의 가장 큰 이점은 LambdaTest가 테스트의 통과 여부를 평가하는 데 도움이 된다는 것입니다.

여전히 결과를 검토하여 모든 오류가 진정한 실패인지 확인해야 하지만 그 반대의 경우도 마찬가지입니다. 그러나 LambdaTest가 초기 작업을 수행하도록 하면 많은 시간과 골칫거리를 절약할 수 있습니다.

마무리

브라우저 간 테스트는 웹사이트가 모바일 반응형인지 확인하는 것만이 아닙니다. 우리가 여기서 궁극적으로 하고자 하는 것은 웹 디자인에서 추측을 없애는 것입니다. 12개 이상의 가능한 브라우저와 수백 개의 브라우저/장치 구성이 있을 수 있지만 자동화된 브라우저 간 테스트를 통해 이러한 가능성을 모두 확인하고 오류를 훨씬 쉽게 찾을 수 있습니다.