Fiddler로 API의 응답 데이터를 조작해 UI를 검증하기

안녕하세요 원티드랩 QA팀 김명관 입니다. Fiddler는 클라이언트와 서버 간의 http, https 패킷을 캡쳐할 수 있는 툴입니다.
Fiddler로 캡쳐한 패킷을 이용해 API의 응답 데이터 조작과 분석, 모니터링에 사용할 수 있습니다.

그 밖에도 API를 반복하여 요청하거나, 네트워크 속도를 조절 할 수도 있고 테스트 데이터를 임의로 조작하여 UI를 검증할 수 있습니다.

이번에는 Fiddler를 이용해 API의 응답 데이터를 조작하며 UI를 검증하는 몇 가지 방법에 대해 소개해 보겠습니다.

Fiddler의 기본적인 구조는 크게 2가지로 나뉘어 집니다.
왼쪽 영역은 Fiddler 실행 후 캡쳐된 HTTP, HTTPS 리스트가 쌓이는 곳으로 여기서 원하는 패킷을 선택하여 우측 메뉴에서 조작, 분석, 모니터링 합니다.

오른쪽 영역은 왼쪽 영역에서 선택한 패킷의 정보를 확인할 수 있으며 상단의 다양한 메뉴를 이용해 API의 응답 데이터를 조작할 수도 있습니다.

1. Composer

Composer 메뉴에서는 이전에 캡쳐했던 요청을 가져와 다시 서버로 요청할 수 있는 기능을 제공합니다.

원티드 커뮤니티에 댓글을 작성하면 Fiddler에 댓글을 작성했던 요청이 캡쳐되어 있습니다.

Fiddler의 Composer 메뉴로 이동한 뒤 해당 패킷을 Composer 메뉴로 드래그 해보겠습니다.

해당 패킷이 서버로 보냈던 요청 전문이 자동으로 입력됩니다.
위쪽 영역에서는 헤더나 쿠키값을 수정할 수 있고 아래쪽 영역에서는 요청 시 사용된 파라미터를 수정할 수도 있습니다.

원하는 값을 세팅한 뒤 우측 상단의 Execute 버튼을 클릭하면 댓글 작성 요청이 반복됩니다.

UI에서 확인해 보면, Execute를 클릭한 횟수 만큼 댓글이 작성된 것을 볼 수 있습니다.
저는 파라미터의 content를 수정하여 댓글달기1~4를 작성해 보았습니다.

원티드 커뮤니티를 QA 하다보면, 댓글 카운터에 대한 기능을 자주 검증하게 됩니다.
[게시글에 댓글이 1000개 이상인 경우 댓글의 개수가 999+로 노출된다.]
같은 케이스인데요.
위에서 소개해드린 Composer를 이용할 경우 댓글 1000개를 작성하기 위해서 Execute를 1000번 클릭해야 하는 번거로움이 있습니다.

2. Replay

댓글 1000개를 작성하기 위해 제가 처음 시도했던 방법은 클릭 매크로를 만들어 Execute 버튼을 1000번 클릭하는 방법이었습니다.
문제점으로는 0.1초에 한 번씩 클릭한다 해도 100초가 걸린다는 점이었습니다.
해당 케이스를 여러 번 재현해야 한다면?
댓글을 2000개 5000개 10000개 작성해야 한다면?
이런 극단적인 상황에서는 Composer를 이용하는 것은 비효율 적일 수도 있습니다.
더 나은 방법을 찾아본 결과 Fiddler의 Replay 기능을 알게 되었습니다.
Replay 기능은 원하는 패킷을 선택하여 입력한 횟수만큼 해당 요청을 반복하는 기능입니다.

댓글 작성 요청을 선택한 뒤 Shift+R 입력 시 Replay 기능을 사용할 수 있습니다.

댓글 작성 요청을 1000번 실행한 결과, 모든 댓글이 작성되는데 걸린 시간은 약 47초 였습니다.
Execute 버튼을 직접 클릭하는 매크로와 비교하여 약 50%의 시간을 줄일 수 있었습니다.

UI에서 확인해 보면 실제로 댓글이 1000개 이상 작성되자 댓글 개수가 999+로 노출되는 것을 확인할 수 있었습니다.

수동으로는 불가능 할 정도로 많은 횟수를 반복해야 하는 케이스에 이렇게 Composer와 Replay를 사용할 수 있었습니다.

3. Breakpoints

Breakpoints 기능을 사용하면 서버로 요청하는 패킷과 서버에서 응답하는 패킷을 붙잡아 두고 이후의 진행을 멈출 수 있습니다.
그리고 Inspectors 메뉴에서 요청과 응답이 도착하기 전에 멈춰있는 패킷의 데이터를 조작, 분석할 수 있습니다.

Breakpoints 기능은 Rules > Automatic Breakpoints 메뉴에서 확인할 수 있습니다.
Before Requests(F11) : 요청을 서버에 도착하기 전에 붙잡아 둠.
After Response(Alt+F11) : 응답이 클라이언트에 도착하기 전에 붙잡아 둠.

After Response 기능을 이용해 응답 데이터를 조작하여 UI 요구사항을 검증할 수도 있습니다.

이번에는 [게시글의 좋아요가 1000개 이상인 경우 999+로 노출된다.] 라는 케이스를 Breakpoints 기능을 이용하여 검증해 보겠습니다.

Alt+F11을 입력해 After Response를 설정한 뒤 임의의 게시글로 진입하였습니다.

게시글에 대한 요청은 처리되었고, 서버에서 내려주는 응답값은 모두 멈춰있습니다.
그 중 게시글의 정보를 담고있는 posts API를 클릭합니다.

Inspector 메뉴에서는 선택한 패킷이 담고있는 정보를 다양한 형태로 확인할 수 있습니다.

색깔로 데이터 종류가 구분되어 있는 SyntaxView를 통해 수정해야 할 값을 찾았습니다.
좋아요 개수에 대한 정보를 가지고 있는 like_count 값은 현재 0으로 응답 받았습니다.

like_count 값을 1000으로 변경한 뒤 After Response를 해제하고 Run to Completion을 클릭하면 이후 패킷들은 멈추지 않고 정상적으로 진행됩니다.

UI에서 확인한 결과 좋아요 개수가 999+로 노출되는 것을 확인할 수 있었습니다.
좋아요의 경우 댓글처럼 하나의 계정에서 반복하여 개수를 올릴 수 없는 구조이기 때문에 Breakpoints 기능으로 서버의 응답 데이터를 조작하는 방법으로 확인할 수 있었습니다.

물론 응답 데이터를 조작한 값은 실제 DB에 영향을 주지 않기 때문에, Refresh가 발생할 경우 해당 값은 다시 DB에 저장된 값인 0으로 돌아올 것입니다.

그외에도 발생시키기 어려운 까다로운 예외케이스에 대한 UI 검증도 Breakpoints 기능을 이용한다면 보다 쉽게 진행할 수 있습니다.

크레딧잡의 메인에서는 주간 조회수 TOP이라는 메뉴를 제공합니다.
주간 조회수가 가장 높았던 기업과 그 기업의 평균연봉 정보를 제공하고 있는데요, 평균연봉의 경우 “만원” 단위로 제공되고 있습니다.

[평균연봉이 1만원 이하가 된다면 어떻게 처리될까?] 라는 예외케이스에 대해 검증해 보겠습니다.

다시 After Response를 설정한 뒤 해당 요청을 발생시킵니다.
Inspectors 메뉴에서 해당 요청에 대한 응답값을 분석한 결과 salary 라는 항목을 확인할 수 있었습니다.

평균연봉이기 때문에 1만자리 아래로도 값은 있지만 “만원” 단위로 보여지는 것을 알 수 있습니다.

salary의 값을 100으로 변경해 보았습니다.

이후에는 아까와 같이 After Response를 해제하고 Run to Completion을 클릭하면 평균연봉 값을 100원으로 받아온 상태로 노출됩니다.

UI에서 확인한 결과 평균연봉이 1만원 이하인 경우에는 0만원으로 노출되는 것을 알 수 있었습니다.

100원 이하 뿐 아니라 큰 값을 입력해 볼수도 있었습니다.
평균연봉 영역의 데이터가 길어질 경우 UI에 이슈가 발생하지 않는지 등을 검증할 수도 있습니다.

그 외에도 salary에 입력될 수 없는 값을 입력해 보기도 하였습니다.
위 사진은 salary에 “백원” 이라는 텍스트를 입력한 결과로, 주간 조회수 TOP의 기준 날짜와 기업 데이터가 노출되지 않았습니다.

Breakpoints 기능을 이용하면 서버 응답에 대한 HTTP Code를 조작해 결과를 확인할 수 있습니다.

위와 같이 After Response 기능을 이용해 서버의 응답을 잡아둔 상태에서 우측 영역을 확인해 보겠습니다.

Breakpoints를 설정한 상태에서 멈춰 있는 임의의 패킷을 선택하면 Choose Response… 라는 메뉴를 확인할 수 있습니다.
해당 메뉴의 드랍박스를 클릭해 보면 200 ~ 502 까지 다양한 HTTP Code를 선택할 수 있습니다.

이 중 404_Plain.dat을 선택하여 서버의 응답을 404로 받을 수 있습니다.

정상적인 응답을 조작하여 커뮤니티 게시물 조회에 대한 Result가 404로 떨어진 상태입니다.

이 때 UI를 확인해 보면 위 페이지로 이동해 있습니다.

위 페이지로 이동하는 이유는 Fiddler 홈페이지에서 확인할 수 있습니다.

응답을 멈추고 선택했던 Response인 404_Plain.dat 파일은 아래 내용을 담고 있기 때문에 이와 같은 페이지로 이동하게 됩니다.

HTTP/1.1 404 Not Found
FiddlerTemplate: True
Date: Fri, 25 Jan 2013 16:49:29 GMT
Content-Type: text/html
Content-Length: 520

Fiddler: HTTP/404 Not Found

그 외의 Response들에 대한 내용 또한 아래 URL에서 확인하실 수 있습니다. https://docs.telerik.com/fiddler-everywhere/knowledge-base/using-ar-predefined-actions

4. Autoresponder

Autoresponder 는 임의로 Rule을 만들어 특정 요청이 발생하면 직접 세팅한 Rule을 따르도록 하는 기능을 제공합니다.

커뮤니티의 게시글을 조회하는 요청을 발생시킨 뒤 Autoresponder 메뉴로 드래그 합니다.
Rule Editor에는 드래그한 요청 URL이 입력됩니다.
최초 입력시에는 EXACT:URL 형태로 입력되기 때문에 입력한 요청과 정확히 똑같은 요청이 발생되지 않으면 Autoresponder는 동작하지 않습니다.

따라서 저는 아래와 같이 Rule을 수정하였습니다.
EXACT: 를 제거하였고 API 명 뒤의 요청값을 제거하였습니다.
따라서 해당 API 요청 발생 시 제가 만들 Rule대로 동작하게 됩니다.

Rule을 실행하기 위해서는 상단의 Enable rules를 체크합니다.

API의 응답 구조를 가진 txt파일입니다.
해당 파일의 속성값들을 임의로 입력하여 세팅해 둔 상태입니다.

Fiddler의 Autoresponder 메뉴로 돌아와 Rule Editor의 두번째 드롭박스에서 최하단 “Find a file…”을 선택하여 세팅해 둔 파일을 선택합니다.

이후 오른쪽 Save 버튼을 클릭하면 Rule 세팅이 완료됩니다.

세팅한 Rule이 실행되는 상태에서 동작을 확인해 보겠습니다.
어떤 게시물을 조회해도 제가 응답값을 세팅한 파일의 내용대로 떨어집니다.

Autoresponder 기능을 이용한다면 Fiddler를 테스트 스텁으로도 활용할 수 있습니다.
API와 UI는 개발되었으나 아직 연동되지 않은 상황에서 API 요청 발생 시 API의 응답 구조를 가지고 있는 파일의 내용대로 응답 하라는 Rule을 만들어 실행한다면 아직 연동되지 않은 API임에도 UI 상에서 결과를 검증해 볼 수 있습니다.

5. Autoresponder — Latency

Autoresponder 메뉴에서는 위와 비슷한 방법으로 요청에 대한 Latency를 줄 수도 있습니다.
위와 동일하게 Latency를 주려고 하는 요청을 Autoresponder로 드래그 합니다.

해당 요청과 동일한 종류의 요청에 Latency를 주기위해 요청 URL을 수정합니다. 이후 상단의 Enable Latency를 체크하면 Rule Editor에 Latency라는 항목이 생깁니다.

해당 요청을 우클릭 시 Set Latency 메뉴가 노출되고 해당 메뉴에서 ms 단위로 요청에 대한 Latency를 설정할 수 있습니다.

게시글을 조회하는 요청에 대해 5000ms Latency를 설정한 상태입니다. 다른 메뉴로의 이동, 조회는 정상적으로 진행되지만 Latency가 적용된 게시글 조회 시에는 5초의 지연이 발생합니다.

이를 이용해 네트워크 상태가 좋지않은 상태를 재현할 수 있고, 타임아웃 시 동작을 확인할 수도 있습니다.

6. Mobile App Debugging

Fiddler는 웹을 디버깅 하는 툴로 알려져 있지만 모바일 기기와 연동하여 모바일 웹과 앱 또한 디버깅이 가능합니다.
자세한 연동 방법에 대해서는 아래 링크로 소개하겠습니다.
https://donbada.tistory.com/339
https://docs.telerik.com/fiddler/configure-fiddler/tasks/configureforios

위에서 소개해 드린 방법대로 단말기와 Fiddler가 연동되었다면, PC와 동일한 방법으로 모바일 디버깅을 할 수 있습니다.

모바일 브라우저에 Composer 기능을 이용하여 댓글 작성 요청을 반복하였습니다.
새로고침 시 PC와 동일하게 댓글이 작성되어 있는 것을 확인할 수 있습니다.

크레딧잡의 평균 연봉정보 또한 Breakpoints 기능을 이용해 조작이 가능합니다.

Fiddler를 이용하여 PC 뿐 아니라 모바일 웹과 앱의 검증도 해 보았습니다.

마무리

이렇게 간단히 Fiddler의 기능을 활용하는 사례를 공유해 드렸습니다.

원티드랩의 QA팀에서 일하는 것의 좋은 점 중 하나는 제가 해보고 싶은 활동을 할 수 있는 기회가 있다는 점입니다.

다양한 툴을 이용해 어떻게 더 서비스를 분석해보고 괴롭혀(?) 볼 수 있을까 고민할 수 있고 단순한 매크로에서 모니터링 스크립트, 테스트 자동화 스크립트 까지 관심있는 영역에 대한 활동을 해볼 수 있는 기회가 주어진 덕분에 원티드랩에서는 좀 더 깊이있는 QA가 될 수 있을 것 같습니다.

아직 저도 Fiddler의 많은 기능들을 사용해 보지 못했지만, 앞으로 QA에 도움이 될 수 있는 좋은 기능들을 사용하는 사례를 만들어 보도록 하겠습니다.

이 글이 Fiddler를 사용하시는 많은 분들께 도움이 되었으면 좋겠습니다. 감사합니다.