임팩트가 높고 최소한의 노력으로 크로스 브라우저 테스트

브라우저 간 테스트는 시간과 노력이 많이 듭니다. 그러나 개발자는 본질적으로 게으릅니다. DRY 원칙을 고수하고, 그렇지 않으면 손으로 해야 할 일을 자동화하는 스크립트를 작성하고, 타사 라이브러리를 사용합니다. 게으른 것이 우리를 훌륭한 개발자 로 만드는 것입니다.

브라우저 간 테스트에 대한 전통적인 접근 방식은 '적절하게' 청중이 사용하는 모든 주요 브라우저에서 테스트하고 점차적으로 이전 브라우저나 더 모호한 브라우저로 이동하여 테스트했음을 알리는 것입니다. 또는 시간과 리소스가 부족한 경우 임시 브라우저의 작은 하위 집합을 테스트하고 버그가 없기를 바라면 애플리케이션의 무결성에 대한 확신이 생깁니다. 첫 번째 접근 방식은 '좋은' 개발을 구현하지만 비효율적인 반면, 두 번째 접근 방식은 게으름을 구현하지만 신뢰할 수 없습니다.

SmashingMag에 대한 추가 정보:

• Noah의 모바일 사용성 테스트로의 전환
• 앱, 게임 및 모바일 웹용 테스트 자동화의 기초
• 자신의 프런트 엔드 웹 사이트 테스트 계획을 만드는 방법
• 세계 최고의 개방형 장치 연구소는 어디에 있습니까?

다음 15분 동안 덜 노동 집약적 일 뿐만 아니라 버그를 잡는 데 더 효과적인 테스트 전략을 설명함으로써 낭비되는 노력을 절약할 수 있기를 바랍니다. 저는 BBC Visual Journalism의 테스트 개발자로서의 경험을 바탕으로 단순히 "모든 것을 테스트!"하는 것보다 더 적절하고 가치 있는 현실적인 테스트 전략을 문서화하고 싶습니다.

문맥

제쳐두고, 우리는 우리 팀에서 수동 테스트 이상을 수행한다는 점을 지적할 가치가 있습니다. 브라우저 간 테스트는 단위 테스트(Jasmine/QUnit), 기능 테스트(Cucumber) 및 해당되는 경우 자동화된 시각적 회귀 테스트(Wraith)를 대체하지 않습니다. 실제로 자동화된 테스트는 장기적으로 더 저렴하며 애플리케이션이 특정 크기에 도달할 때 필수적입니다.

그러나 일부 버그는 특정 브라우저에서만 나타나며 테스트 자동화는 아직 브라우저 간 테스트 영역에 안정적으로 진입하지 못했습니다. iPhone 4에서 볼 때 자동화된 스크롤 이벤트가 제목의 절반을 가렸다는 것을 컴퓨터가 어떻게 알 수 있습니까? 그것이 문제라는 것을 어떻게 알겠습니까? 인공 지능이 컴퓨터가 여러분이 구축한 것을 이해 하고 여러분이 시연하려는 내러티브와 예술성 에 감사 할 정도로 성장할 때까지는 항상 수동 테스트가 필요합니다. 수동으로 수행해야 하는 작업으로, 브라우저 간 테스트 프로세스를 최대한 효율적으로 만드는 것은 우리 스스로에게 빚지고 있습니다.

당신의 목표는 무엇입니까?

브라우저 간 테스트에 맹목적으로 뛰어들기 전에 무엇을 얻고자 하는지 결정하십시오. 브라우저 간 테스트는 두 가지 주요 목표로 요약할 수 있습니다.

1. 버그 발견 수정해야 할 버그를 찾기 위해 애플리케이션을 중단시키려는 시도가 수반됩니다.
2. 온전성 확인 여기에는 대다수의 청중이 예상한 경험을 제공하는지 확인하는 작업이 포함됩니다.

이 기사에서 가장 먼저 지적하고 싶은 것은 이 두 가지 목표가 서로 충돌 한다는 것입니다.

한편으로는 Chrome(데스크톱), Chrome(Android) 및 Safari(iOS 9)에서 테스트하는 것만으로 거의 50%의 영국 사용자의 경험을 확인할 수 있다는 것을 알고 있습니다. 반면에 내 목표가 버그를 찾는 것이라면 적극적으로 지원해야 하는 가장 문제가 많은 브라우저(우리의 경우 IE8 및 기본 Android 브라우저 2)에 웹 앱을 던지고 싶습니다.

이 두 브라우저의 사용자는 점점 줄어들고 있는 우리 청중의 비율(현재 약 1.5%)을 차지하므로 우리의 목표가 정상인지 확인하는 것이라면 이러한 브라우저에서 테스트하는 것은 시간을 제대로 사용하지 못합니다. 그러나 잘 엔지니어링된 응용 프로그램이 모호한 렌더링 엔진에 던져질 때 얼마나 엉망이 될 수 있는지 확인하려는 경우 테스트할 수 있는 훌륭한 브라우저입니다.

기존의 테스트 전략은 당연히 인기 있는 브라우저에서의 테스트에 더 중점을 둡니다. 그러나 불균형적인 수의 버그는 더 모호한 브라우저에만 존재하며 전통적인 테스트 모델에서는 테스트가 끝날 때까지 밝혀지지 않습니다. 그러다 딜레마에 빠지게 되는데...

롱테일 테스트 단계에서 늦게 버그를 발견하면 어떻게 합니까?

1. 버그를 무시하십시오.
2. 버그를 수정하고 아무 것도 손상되지 않았으면 합니다.
3. 버그를 수정하고 이전에 테스트한 모든 브라우저에서 다시 테스트하세요.

이상적인 세상에서 마지막 옵션은 모든 브라우저가 여전히 예상대로 작동한다고 진정으로 확신할 수 있는 유일한 방법이기 때문에 가장 좋은 옵션입니다. 그러나 그것은 또한 엄청나게 비효율적이며 여러 번 수행해야 할 것입니다. 버블 정렬과 동일한 수동 테스트입니다.

따라서 우리는 Catch-22 상황에 처하게 됩니다. 최대 효율성을 위해 브라우저 간 테스트를 시작하기 전에 모든 버그를 수정하고 싶지만 테스트를 시작할 때까지 어떤 버그가 있는지 알 수 없습니다.

답은 우리가 3단계 공격 이라고 부르는 방식으로 점진적인 테스트를 통해 버그 찾기 및 온전성 검사라는 우리의 목표를 달성하는 테스트 방법에 대해 현명하게 대처하는 것입니다.

삼상 공격

당신이 전쟁터에 있다고 상상해보십시오. 나쁜 놈들이 도시 반대편에 있는 HQ에 웅크리고 있다는 것을 알고 있습니다. 당신은 특수 요원, 전투로 단련된 게릴라로 구성된 균열 팀, 그리고 가벼운 무장을 한 대규모 지역 민병대를 마음대로 사용할 수 있습니다. 당신은 도시를 탈환하기 위해 3단계 공격을 시작합니다:

1. 정찰 당신의 스파이를 적 본부로 보내 악당이 어디에 숨어 있는지, 얼마나 많은 악당이 있는지, 전장의 전반적인 상황을 파악하십시오.
2. 습격 당신의 크랙 팀을 적의 심장부로 보내 한 번의 맹렬한 기습 공격으로 대부분의 악당을 제거하십시오.
3. 지역 민병대 를 보내 남아 있는 악당들을 제거하고 지역을 확보하십시오.

브라우저 간 테스트에 동일한 군사 전략과 규율을 적용할 수 있습니다.

1. 정찰 개발 머신의 인기 있는 브라우저에서 탐색 테스트를 수행합니다. 버그가 숨어 있을 수 있는 위치에 대한 느낌을 얻으십시오. 발생한 버그를 수정합니다.
2. Raid 가장 많은 버그를 보여줄 가능성이 있는 소수의 문제가 있는 브라우저에서 수동으로 테스트합니다. 발생한 버그를 수정합니다.
3. Clearance Sanity는 청중들 사이에서 가장 인기 있는 브라우저가 예상 경험을 얻을 수 있도록 지워졌는지 확인합니다.

전장에 있든 장치를 테스트 중이든 관계없이 단계는 최소 소요 시간으로 시작하여 작업이 더 안정적으로 될수록 커집니다. 당신이 할 수 있는 정찰은 아주 많습니다. 아주 짧은 시간 안에 몇몇 버그를 발견할 수 있을 것입니다. 습격은 더 강렬하고 시간이 많이 걸리지만 매우 가치 있는 결과를 제공하고 전장을 상당히 안정시킵니다. 정리 단계는 가장 힘든 단계이며, 발견하지 못한 악당이 갑자기 나타나 당신에게 해를 입히는 경우에 대비하여 지혜를 유지해야 합니다. 이제 안전합니다.

3단계 공격의 처음 두 단계는 첫 번째 목표인 버그 발견 을 달성합니다. 애플리케이션이 강력하다고 확신하면 공격의 3단계로 이동하여 대부분의 청중의 탐색 행동과 일치하는 최소 수의 브라우저에서 테스트하여 목표 2 번인 온전성 검사를 달성하고 싶을 것입니다. 그런 다음 귀하의 애플리케이션이 청중의 X%에게 효과가 있다고 정량적으로 뒷받침되는 확신을 가지고 말할 수 있습니다.

설정: 적을 알자

가볍게 전쟁에 참여하지 마십시오. 테스트를 시작하기 전에 사용자가 콘텐츠에 액세스하는 방법을 알고 싶을 것입니다.

잠재고객 통계(Google Analytics 또는 사용하는 모든 도구에서)를 찾고 읽고 이해할 수 있는 형식의 스프레드시트로 데이터를 가져옵니다. 총 시장 점유율의 관련 비율과 함께 각 브라우저 및 운영 체제 조합을 볼 수 있기를 원할 것입니다.

브라우저 사용 통계는 쉽게 사용할 수 있는 경우에만 유용합니다. 테스트해야 할 브라우저/OS/장치 조합의 길고 벅찬 목록이 표시되는 것을 원하지 않습니다. 게다가 가능한 모든 조합을 테스트하는 것은 낭비입니다. 웹 개발자 지식을 사용하여 통계를 경험적으로 통합할 수 있습니다.

브라우저 사용 통계 간소화

웹 개발자로서 우리는 데스크톱 브라우저가 실행되는 OS에 대해 특별히 신경 쓰지 않습니다. 브라우저 버그가 한 OS에만 적용되고 다른 OS에는 적용되지 않는 경우는 매우 드뭅니다. 따라서 모든 운영 체제의 데스크톱 브라우저에 대한 통계를 병합합니다.

우리는 또한 누군가가 Firefox 40 또는 Firefox 39를 사용하는지 여부를 특별히 신경 쓰지 않습니다. 버전 간의 차이는 무시할 수 있고 버전 업데이트는 무료이며 종종 자동입니다. 브라우저 통계를 쉽게 이해할 수 있도록 IE를 제외한 모든 데스크톱 브라우저 버전을 병합합니다. 이전 버전의 IE는 문제가 있고 널리 퍼져 있으므로 사용 수치를 추적해야 합니다.

유사한 주장이 휴대용 OS 브라우저에도 적용됩니다. 모바일 Chrome 또는 Firefox 버전은 정기적으로 쉽게 업데이트되므로 특별히 신경 쓰지 않고 버전을 병합합니다. 그러나 다시 말하지만, 우리는 IE의 다른 버전에 관심이 있으므로 해당 버전을 별도로 기록합니다.

Android에 대해 이야기하는 경우 기기의 OS 버전은 관련이 없습니다. 중요한 것은 사용되는 기본 Android 브라우저의 버전입니다. 이 브라우저는 문제가 많은 것으로 악명 높기 때문입니다. 반면에 Safari 버전은 본질적으로 OS에 연결되어 있기 때문에 장치에서 실행 중인 iOS 버전은 매우 관련이 있습니다. 그런 다음 다른 장치용 기본 브라우저의 전체 호스트가 있습니다. 이러한 브라우저는 전체 사용자 중 아주 작은 비율을 차지하므로 버전 번호도 병합됩니다.

마지막으로, 빠르게 인기를 얻고 있는 새로운 브라우저 물결이 있습니다. 주로 소셜 미디어 플랫폼에서 구현되는 인앱 브라우저입니다. 이것은 우리에게 여전히 새로운 영역이므로 모든 인앱 브라우저 플랫폼과 해당 OS를 나열하는 데 열심입니다.

관련 통계를 병합하기 위해 도메인 전문 지식을 사용한 후에는 잠재고객의 0.05% 미만을 구성하는 모든 브라우저를 제거하여 목록을 더욱 좁힙니다(자신의 요구 사항에 따라 이 임계값을 자유롭게 조정할 수 있음).

데스크탑 브라우저

휴대용 브라우저

인앱 브라우저

완료되면 스프레드시트가 다음과 같이 보일 것입니다(지금은 "우선순위" 열을 무시하십시오. 나중에 다루겠습니다).

이제 웹 개발자의 관점에서 각각 총 시장 점유율 비율과 관련된 주요 브라우저를 보여주는 단순화된 스프레드시트가 생겼습니다. 이 스프레드시트를 최신 상태로 유지해야 합니다. 한 달에 한 번 업데이트하면 충분합니다.

이제 3단계 공격을 시작할 준비가 되었습니다.

1. 정찰: 브라우저 불가지론적 버그 찾기

테스트할 장치를 준비하기 훨씬 전에 가능한 가장 쉬운 일을 하십시오. 즐겨 사용하는 브라우저에서 웹 앱을 여는 것입니다. 당신이 완전한 마조히스트가 아니라면 이것은 Chrome이나 Firefox일 가능성이 높으며 둘 다 안정적이고 최신 기능을 지원합니다. 이 첫 번째 단계의 목표는 브라우저에 구애받지 않는 버그 를 찾는 것입니다.

브라우저에 구애받지 않는 버그는 애플리케이션에 액세스하는 데 사용되는 브라우저 또는 하드웨어와 관련이 없는 구현 오류입니다. 예를 들어 웹 페이지가 활성화되고 가로 모드의 HTC One에서 페이지가 쓰레기처럼 보인다고 불평하는 사람들로부터 모호한 버그 보고서를 받기 시작했다고 가정해 보겠습니다. Android의 USB 디버그 모드를 사용하고 StackOverflow에서 도움말을 검색하여 사용된 브라우저의 버전을 결정하는 데 많은 시간을 낭비하고 도대체 이 문제를 어떻게 고칠 것인지 궁금합니다. 당신도 모르는 사이에 이 버그는 장치와 아무 관련이 없습니다. 오히려 페이지가 특정 표시 영역 너비에서 버그가 있는 것처럼 보입니다. 이 너비는 문제의 장치의 화면 너비와 같습니다.

이것은 브라우저에 특정한 버그 또는 장치에 특정한 버그로 잘못 나타난 브라우저에 구애받지 않는 버그의 예입니다. 버그 보고서가 문제의 근본 원인을 난독화하는 소음으로 작용하면서 길고 낭비적인 길로 인도되었습니다. 자신에게 호의를 베풀고 훨씬 적은 노력과 약간의 예측으로 처음부터 이러한 종류의 버그를 잡으십시오.

브라우저 간 테스트를 시작하기 전에 브라우저에 구애받지 않는 버그를 수정하면 전반적으로 더 적은 수의 버그에 직면하게 됩니다. 나는 이것을 녹는 빙산 효과 라고 부르고 싶습니다. 우리는 수면 아래에 숨어 있는 벌레를 녹여서 바다에 추락하거나 익사하는 것을 방지하고 있습니다. 그리고 우리는 우리가 그렇게 하고 있다는 사실조차 깨닫지 못합니다.

다음은 브라우저에 구애받지 않는 버그를 발견하기 위해 개발 브라우저에서 수행할 수 있는 작업의 짧은 목록입니다.

• 응답성을 보려면 크기를 조정하십시오. 어딘가에 펑키한 중단점이 있었나요?
• 확대 및 축소합니다. 이미지 스프라이트의 배경 위치가 비뚤어졌습니까?
• JavaScript가 꺼진 상태에서 애플리케이션이 어떻게 작동하는지 확인하십시오. 여전히 핵심 콘텐츠를 받고 있습니까?
• CSS를 끈 상태에서 애플리케이션이 어떻게 보이는지 확인하십시오. 마크업의 의미가 여전히 의미가 있습니까?
• JavaScript와 CSS를 모두 끄십시오. 만족스러운 경험을 하고 있습니까?
• 키보드만 사용하여 응용 프로그램과 상호 작용해 보십시오. 모든 콘텐츠를 탐색하고 볼 수 있습니까?
• 연결을 조절하고 애플리케이션이 얼마나 빨리 로드되는지 확인하십시오. 페이지 로드가 얼마나 무거운가요?

2단계로 넘어가기 전에 발생한 버그를 수정해야 합니다. 브라우저에 구애받지 않는 버그를 수정하지 않으면 나중에 많은 잘못된 브라우저 관련 버그만 보고하게 됩니다.

게을러 라. 브라우저에 구애받지 않는 버그를 수정합니다. 그런 다음 공격의 두 번째 단계로 이동할 수 있습니다.

2. Raid: 먼저 고위험 브라우저에서 테스트

버그를 수정할 때 수정 사항으로 인해 더 많은 버그가 발생하지 않도록 주의해야 합니다. Safari에서 패딩을 수정하기 위해 CSS를 조정하면 Firefox에서 패딩이 깨질 수 있습니다. Chrome에서 더 원활하게 실행되도록 JavaScript를 최적화하면 IE에서 완전히 중단될 수 있습니다. 우리가 만드는 모든 변경에는 위험이 따릅니다.

새로운 변경 사항이 우리가 이미 테스트한 모든 브라우저의 경험을 손상시키지 않았다는 것을 진정으로 확신하려면 돌아가서 동일한 브라우저에서 다시 테스트해야 합니다. 따라서 노력의 중복을 최소화하려면 테스트 방법에 대해 현명해야 합니다.

버그 분포 통계 분석

다음 표에서 십자 아이콘은 브라우저에 버그가 있음을 의미합니다.

낮은 위험도 브라우저, 중간 위험도 브라우저, 높은 위험도 브라우저와 같이 위험도의 오름차순으로 콘텐츠를 테스트한다고 가정해 보겠습니다. 이것을 시각화하는 데 도움이된다면 이러한 브라우저는 각각 Google Chrome, IE 9 및 IE 6에 매핑될 수 있습니다.

저위험 브라우저(Chrome)를 먼저 테스트하고 버그 #2를 찾아 수정합니다. 중간 위험 브라우저로 이동할 때 버그 #2는 이미 수정되었지만 새로운 버그 #4를 발견했습니다. 버그를 수정하기 위해 코드를 변경했지만 이제 저위험 브라우저에서 문제가 발생하지 않았는지 어떻게 확신할 수 있습니까? 우리는 완전히 확신할 수 없으므로 모든 것이 여전히 예상대로 작동하는지 확인하기 위해 돌아가서 해당 브라우저에서 다시 테스트해야 합니다.

이제 고위험 브라우저로 이동하여 버그 #1, #3, #5를 찾았습니다. 수정하려면 상당한 재작업이 필요합니다. 이러한 문제가 해결되면 우리는 무엇을 해야 합니까? 돌아가서 중간 및 낮음 위험 브라우저를 다시 테스트하십시오. 이것은 많은 노력의 중복입니다. 우리는 3개의 브라우저를 총 6번 테스트해야 했습니다.

이제 위험의 내림차순 으로 콘텐츠를 테스트했다면 어떤 일이 일어났을지 생각해 봅시다.

즉시 고위험 브라우저에서 버그 #1, #3, #4 및 #5를 찾을 수 있습니다. 이러한 버그를 수정한 후 중간 위험 브라우저로 바로 이동하여 버그 #2를 발견했습니다. 이전과 마찬가지로 이 수정 사항으로 인해 간접적으로 손상되었을 수 있으므로 고위험 브라우저로 돌아가 다시 테스트해야 합니다. 마지막으로 저위험 브라우저에서 테스트하고 새로운 버그를 발견하지 못했습니다. 이 경우, 우리는 총 4번의 다른 경우에 3개의 브라우저를 테스트했는데, 이는 동일한 수의 버그를 효과적으로 발견 및 수정하고 동일한 수의 브라우저 의 동작을 검증하는 데 필요한 시간을 크게 단축한 것입니다. .

개발자는 가장 널리 사용되는 브라우저에서 먼저 테스트하고 테스트가 끝날 때 덜 널리 사용되는 브라우저로 작업해야 한다는 압력을 받을 수 있습니다. 그러나 인기 있는 브라우저는 위험도가 낮은 브라우저일 가능성이 높습니다.

주어진 고위험 브라우저를 지원해야 한다는 것을 알고 있으므로 처음부터 해당 브라우저를 방해하지 않도록 하십시오. 버그를 생성할 가능성이 적은 브라우저를 테스트하는 데 노력을 낭비 하지 마십시오. 더 많은 버그를 생성하는 브라우저로 전환할 때 돌아가서 위험도가 낮은 브라우저만 다시 확인하면 되기 때문입니다.

나쁜 브라우저에서 버그를 수정하면 좋은 브라우저에서 코드가 더 탄력적입니다.

종종 이러한 문제가 있는 브라우저에서 발생하는 버그는 잘못된 코드로 인한 예기치 않은 결과라는 것을 알게 될 것입니다. 버튼처럼 보이도록 div에 어색한 스타일을 지정했거나 임의의 동작을 트리거하기 전에 setTimeout을 해킹했을 수 있습니다. 이 두 가지 문제에 대해 더 나은 솔루션이 존재합니다. 잘못된 코드의 증상인 버그를 수정하면 다른 브라우저에서 버그를 보기도 전에 수정할 수 있습니다. 다시 녹는 빙산 효과가 있습니다.

브라우저가 무언가를 지원한다고 가정하기 보다는 기능 지원을 확인함으로써 IE8에서 그 고통스러운 버그를 수정하는 것이지만 다른 가혹한 환경에 대해 코드를 더욱 강력하게 만드는 것이기도 합니다. Opera Mini에 해당 이미지 폴백을 제공함으로써 점진적 향상의 사용을 권장하고 부산물로 겨자색을 뺀 브라우저 사용자를 위해 제품을 개선하고 있습니다. 예를 들어, 모바일 장치는 애플리케이션 자산의 절반만 다운로드한 상태에서 3G 연결을 잃을 수 있습니다. 사용자는 이제 이전에는 가질 수 없었던 의미 있는 경험을 얻게 됩니다.

하지만 조심하세요. 조심하지 않으면 모호한 브라우저에서 버그를 수정하면 코드가 더 나빠질 수 있습니다. 예를 들어 특정 브라우저에 조건부로 콘텐츠를 전달하기 위해 사용자 에이전트 문자열을 스니핑하려는 유혹을 물리치십시오. 그것은 버그를 고칠 수 있지만 완전히 지속 불가능한 관행입니다. 어색한 브라우저를 지원하기 위해 좋은 코드의 무결성을 손상시키지 마십시오.

문제가 있는 브라우저 식별

그렇다면 고위험 브라우저 는 무엇입니까? 대답은 약간 엉성하며 응용 프로그램에서 사용하는 브라우저 기능에 따라 다릅니다. JavaScript가 indexOf 를 사용하는 경우 IE 8에서 중단될 수 있습니다. 앱이 position: fixed 를 사용하는 경우 iOS 7의 Safari에서 확인하고 싶을 것입니다.

Can I Use는 귀중한 리소스이자 시작하기에 좋은 곳이지만, 이것은 다시 경험과 개발자 직관에서 나오는 영역 중 하나입니다. 웹 앱을 정기적으로 출시하면 어떤 브라우저에서 문제를 몇 번이고 표시하는지 알게 되며 이를 수용하기 위해 테스트 전략을 구체화할 수 있습니다.

문제가 있는 브라우저에서 발견한 버그에 대한 유용한 점은 버그가 자주 전파된다는 것입니다. IE9에 버그가 있으면 IE8에도 버그가 있을 가능성이 있습니다. iOS 7의 Safari에서 뭔가 펑키해 보인다면 iOS 6에서 훨씬 더 뚜렷하게 보일 것입니다. 여기에서 패턴이 보이시나요? 오래된 브라우저는 문제가 있는 경향이 있습니다. 그러면 문제가 있는 브라우저의 꽤 좋은 목록을 찾는 데 도움이 될 것입니다.

즉 , 사용 통계로 백업하십시오. 예를 들어, IE 6은 매우 문제가 많은 브라우저이지만 전체 시장 점유율이 너무 낮기 때문에 테스트하지 않습니다. IE6 관련 버그를 수정하는 데 소비한 시간은 경험이 개선될 소수의 사용자에게는 노력할 가치가 없습니다.

습격 단계에서 테스트하고 싶은 것이 항상 오래된 브라우저는 아닙니다. 예를 들어, 이미지 폴백이 있는 실험적인 3D WebGL 캔버스 프로젝트가 있는 경우 이전 브라우저는 폴백 이미지만 가져오므로 많은 버그를 찾을 가능성이 없습니다. 대신 우리가 원하는 것은 현재 사용 중인 애플리케이션을 기반으로 문제가 있는 브라우저 선택을 변경하는 것입니다. 이 경우 IE9는 캔버스를 지원하는 IE의 첫 번째 버전이기 때문에 테스트하기에 좋은 브라우저일 수 있습니다.

최신 프록시 브라우저(예: Opera Mini)는 응용 프로그램이 그라디언트 또는 경계 반경과 같은 CSS3 기능을 사용하는 경우 급습 테스트에 좋은 선택일 수 있습니다. 일반적인 오류는 지원되지 않는 그라디언트에 흰색 텍스트를 렌더링하여 흰색 바탕에 흰색 텍스트를 읽을 수 없게 만드는 것입니다.

문제가 있는 브라우저를 선택할 때 직관을 사용하고 버그가 숨어 있을 수 있는 부분을 선점하십시오.

문제가 있는 브라우저 다양화

브라우저와 브라우저 버전은 방정식의 일부일 뿐입니다. 하드웨어도 중요한 고려 사항입니다. 다양한 화면 크기와 다양한 픽셀 밀도에서 애플리케이션을 테스트하고 세로 모드와 가로 모드 사이를 전환해 보십시오.

노력 비용에 대한 인지된 할인이 있기 때문에 관련 브라우저를 함께 그룹화하고 싶을 수 있습니다. IE8을 테스트하기 위해 이미 VirtualBox를 열어 두었다면 지금이 IE9, IE10 및 IE11에서도 테스트하기에 좋은 시기인 것 같습니다. 그러나 웹 앱 테스트의 초기 단계에 있다면 이러한 유혹에 맞서 싸우고 대신 서로 현저하게 다른 3~4개의 브라우저-하드웨어 조합을 선택하여 전체 범위에 대해 최대한 많은 적용 범위를 확보하고 싶을 것입니다. 가능한 한 버그 공간.

프로젝트마다 다를 수 있지만 현재 문제가 되는 브라우저는 다음과 같습니다.

• Windows XP VM의 IE 8
• 중급 Android 태블릿의 기본 Android 브라우저 2
• iOS 6을 실행하는 iPhone 4의 Safari
• Opera mini(datapics와 같이 JavaScript 없이 작동해야 하는 콘텐츠로만 테스트할 가치가 있음).

게을러 라. 가장 문제가 많은 지원되는 브라우저 및 장치에서 앱을 실행하여 최대한 많은 버그를 찾으십시오. 이 버그가 수정되면 공격의 마지막 단계로 이동할 수 있습니다.

3. 정리: 온전성 확인

이제 지원해야 하는 가장 가혹한 브라우저에서 앱을 테스트했으며 대부분의 버그를 잡을 수 있기를 바랍니다. 그러나 귀하의 애플리케이션은 아직 완전히 버그가 없습니다. 최신 버전의 Chrome과 Firefox에서도 동일한 콘텐츠를 렌더링하는 방식이 다르다는 사실에 끊임없이 놀라고 있습니다. 아직 테스트를 더 해야 합니다.

그것은 오래된 80:20 규칙입니다. 비유적으로, 브라우저의 20%를 테스트한 후 버그의 80%를 수정했습니다. 이제 다른 20%의 브라우저를 테스트하여 청중의 80% 경험을 확인하고 싶습니다.

브라우저 우선 순위 지정

이제 간단하고 분명한 접근 방식은 시장 점유율의 내림차순으로 각 브라우저를 처리하여 '전통적인' 브라우저 간 테스트로 다시 전환하는 것입니다. Chrome 데스크톱이 청중의 브라우저 점유율에서 가장 높은 비율을 차지하는 경우 iOS 8의 Safari, IE11이 그 뒤를 잇는다면 이 순서대로 테스트하는 것이 합리적이겠죠?

이는 대체로 공정한 시스템이며 리소스가 이미 확장된 경우 이 단계를 지나치게 복잡하게 만들고 싶지 않습니다. 그러나 문제의 사실은 모든 브라우저가 동일하게 생성되지는 않는다는 것입니다. 우리 팀에서는 브라우저 사용, 업그레이드 용이성, 브라우저가 OS 기본값인지 여부를 고려한 결정 트리 에 따라 브라우저를 그룹화합니다.

지금까지는 스프레드시트에 브라우저 열과 시장 점유율 열이 있어야 합니다. 이제 브라우저가 속하는 우선 순위를 지정하는 세 번째 열이 필요합니다. 사실, 이 우선 순위 지정 작업은 3단계 공격을 시작하기 전에 수행했어야 했지만 이 문서의 목적을 위해 우선 순위가 정리 단계까지 실제로 필요하지 않기 때문에 여기에서 설명하는 것이 더 합리적입니다.

다음은 의사 결정 트리입니다.

P1 브라우저가 청중의 약 70%를 차지하도록 의사 결정 트리를 설계했습니다. P1 및 P2 브라우저를 결합하여 사용자의 약 90%를 차지합니다. 마지막으로 P1, P2 및 P3 브라우저는 거의 완전한 청중 범위를 제공합니다. 우리는 시장 점유율의 내림차순으로 모든 P1 브라우저, P2, P3 순으로 테스트하는 것을 목표로 합니다.

이 기사 앞부분의 스프레드시트에서 볼 수 있듯이 P1 브라우저는 소수에 불과합니다. 70% 이상의 청중의 경험을 빠르게 확인할 수 있다는 사실은 코드베이스가 변경될 경우 해당 브라우저에서 다시 테스트하지 않을 이유가 거의 없음을 의미합니다. P2 및 P3 브라우저로 이동하면서 점점 줄어들고 있는 청중 규모의 경험을 확인하는 데 점점 더 많은 노력을 기울여야 하므로 우선 순위가 낮은 브라우저에 대해 보다 현실적인 테스트 이상을 설정해야 합니다. 지침으로:

• P1 . 애플리케이션에서 로그오프하기 전에 이러한 브라우저에서 온전한 상태를 확인해야 합니다. 코드를 약간 변경하면 이러한 브라우저에서 다시 정상 상태를 확인해야 합니다.
• P2 . 애플리케이션에서 로그오프하기 전에 이러한 브라우저에서 온전한 상태를 확인해야 합니다. 코드를 크게 변경하면 이러한 브라우저에서 다시 정상 상태를 확인해야 합니다.
• P3 . 시간이 있을 때만 이러한 브라우저에서 온전한 상태를 확인해야 합니다.

하드웨어를 다양화할 필요성을 잊지 마십시오. 이 목록을 따르는 동안 다양한 화면 크기와 다양한 하드웨어 기능을 가진 장치에서 테스트할 수 있다면 그렇게 하십시오.

요약: 3단계 공격

일단 적을 파악 하기 위해 노력하고 나면( 청중 통계를 단순화 하고 브라우저를 우선 순위로 그룹화 ) 세 단계로 공격할 수 있습니다.

1. 정찰 : 브라우저에 구애받지 않는 버그를 찾기 위해 즐겨 사용하는 브라우저에서 탐색 테스트 .
2. Raid : 대부분의 버그를 찾기 위해 다양한 하드웨어에서 지원되는 가장 문제가 많은 브라우저에서 테스트합니다.
3. Clearance : 가장 널리 사용되는 전략적으로 중요한 브라우저에서 애플리케이션 경험을 검증하는 것, 즉 애플리케이션이 작동한다는 양적으로 뒷받침되는 확신입니다 .