2. 캐시(Cache)

정의

• 자주 사용하는 데이터를 저장해두고 빠르게 불러오기 위한 기술

• 장점: 성능 향상, 서버 부하 감소

• 단점: 콘텐츠가 변경돼도 갱신 안 될 수 있음

2-1.캐시 제어를 위한 헤더들

• [Cache-Control / Pragma]

3. 쿠키(Cookie)

정의

• 사용자 상태(로그인, 장바구니 등)를 유지하기 위한 데이터

작동 방식

• 서버가 Set-Cookie 헤더로 브라우저에 저장
• 브라우저는 이후 요청마다 쿠키를 함께 전송

4. 프록시 서버(Proxy)

정의

• 클라이언트와 서버 사이에 위치한 중계 서버

역할

• 캐시 서버 역할

• 보안 필터링

• 로드 밸런싱 (부하 분산)

• 사용자 익명성 보장

5. 네트워크 모니터링 도구🔍

1. 브라우저 개발자 도구 (DevTools)

• F12 또는 Ctrl + Shift + I → Network 탭

• HTTP 요청/응답, 헤더, 상태 코드 확인 가능

2. 와이어샤크 (Wireshark)

• 강력한 네트워크 트래픽 분석 도구

• HTTP뿐만 아니라 모든 패킷 감시 가능

• 입문 난이도는 높지만, 능숙해지면 막강한 분석력 제공

1. Browser → 프록시: 사용자가 웹사이트 접속 시 요청을 보냄.

2. 프록시 → 캐시: 프록시는 해당 요청에 대해 캐시에 있는지 먼저 확인.

3. 캐시에 있으면 그대로 브라우저에 응답.

4. 없으면 → 웹 서버로 요청 전달.

5. 프록시 → 웹 서버: 캐시에 없으면 실제 서버로 요청 전달.

6. 웹 서버 ↔ HTTPS: 서버와 브라우저 간 통신은 HTTPS로 암호화.

7. network monitoring: 이 모든 과정은 네트워크 모니터링 도구로 관찰될 수 있음.

8. 쿠키 저장/읽기: 서버가 응답할 때 쿠키를 포함하면, 브라우저는 이를 저장합니다. 다음 요청 시 자동으로 포함해서 보냄.

응답 = 헤더(header) + 본문(body) 으로 구성됨.

상태 코드(Status Code): 응답 결과를 숫자로 알려줌

1xx: 정보 (거의 안 씀)

2xx: 성공 → 200 OK 가장 흔함

3xx: 리다이렉션 → 다른 주소로 이동하라는 의미 (301, 302)

4xx: 클라이언트 오류 → 404 Not Found, 403 Forbidden

5xx: 서버 오류 → 500 Internal Server Error

2.응답 헤더(Response Header)의 주요 항목

Content-Type: 응답 본문의 타입 [text/html, image/jpeg, application/json]

Content-Length: 응답 본문의 크기 (byte 단위)

Content-Encoding: 압축 방식 (예: gzip)

Last-Modified: 파일이 마지막으로 수정된 날짜

3. 본문(Body)의 역할

실제 사용자에게 보여줄 내용(html, 이미지 등)이 있음

브라우저는 이 내용을 해석해 화면에 표시함.

4. 요약 흐름

브라우저가 서버에 요청 보냄

서버는 상태 코드 + 헤더 + 본문으로 응답

브라우저는 응답 본문을 보고 화면에 출력함

사진의 내용 정리

1. 응답의 구성 요소

응답(Response) → 브라우저가 서버에 요청을 보내고, → 서버가 정상적으로 응답을 반환한 경우를 설명합니다.

브라우저 요청 → 서버가 OK함 → 서버가 요청을 정상적으로 처리했음을 의미합니다.

HTTP/1.1 200 OK → HTTP 프로토콜 버전 + 상태 코드 (여기서 200 OK는 정상 처리 상태를 의미)

헤더(Header) → 응답의 부가정보들이 담긴 부분으로, 주요 항목:

Content-Type: 본문의 형식 (예: text/html, application/json 등)

Content-Length: 본문의 길이 (바이트 단위)

본문(body) *: 실제 전달될 데이터(예: HTML) * 본문(Body) → 사용자가 브라우저에서 실제로 보게 되는 내용 (HTML 문서 등)

HTML: 웹페이지를 구성하는 마크업 언어

URL: 웹페이지에 접근할 수 있도록 도와주는 주소체계

웹 브라우저 & 웹 서버: HTML 파일을 주고받는 소프트웨어

HTTP: 브라우저와 서버가 통신할 때 사용하는 규칙

• HTML뿐만 아니라, 이미지, 오디오, 동영상 등 다양한 멀티미디어 파일을 전송하는 데 사용됨

• 웹이 정보를 받기위해 서로 알아듣는 메세지

• 요청: Request (요청 메시지) 응답: Response (응답 메시지)

HTTP 메세지의 구조

1. Request 메시지 (클라이언트 → 서버)

GET /index.html HTTP/2.0

2. /index.html이라는 파일을 GET 방식으로 요청

Host: example.com

3. 어떤 주소(도메인)에 요청한 것인지 명시

Response 메시지 (서버 → 클라이언트) HTTP/1.1 200 OK

4. 통신 성공, 요청한 파일을 보내주겠다는 뜻

Content-Type: text/html

5. 응답이 HTML 문서라는 의미

Content-Length: 5230

6. 응답 데이터의 크기

요청하는 친구들

메서드(Method)

GET, POST 등. 요청의 종류를 의미

종류

1. GET: 서버에서 데이터를 요청

2. POST: 서버에 데이터를 전송

요청 대상(Request-URI)

어떤 리소스를 요청하는가

HTTP 버전: 클라이언트가 사용하는 프로토콜 버전

헤더

클라이언트(웹브라우저)가 서버에 추가적인 정보를 제공

Host: 요청 대상 서버의 주소

여러 도메인을 하나의 서버에서 운영할 수 있도록 도와줌 (가상 호스트 지원)

User-Agent: 요청을 보낸 브라우저/운영체제 정보

Accept-Encoding: 브라우저가 처리할 수 있는 압축 방식 (gzip, deflate, br)

If-Modified-Since: 마지막으로 받은 시점 이후로 리소스가 변경되었는지 확인

변경되지 않았다면 서버는 데이터를 다시 보내지 않고 응답을 줄일 수 있음

바디

주로 POST 요청에서 사용됨

서버로 전송할 실제 데이터를 포함 (예: 로그인 폼 정보)

바디와 헤더는 빈 줄로 구분

웹 브라우저의 역할!

• 사용자의 요청을 서버에게 대신 요청
• 받은 응답 데이터를 기반으로 화면에 표시

  브라우저는 요청 메시지를 만들고, 서버는 응답 메시지를 생성해서 보냄

1. 웹 브라우저가 HTML을 받아와서 화면을 띄운다.

2. 사용자가 로그인 버튼을 누른다

3. 브라우저가 API 서버에 로그인 요청을 보낸다.

4. API 서버가 처리한 뒤, 로그인 성공 여부를 알려준다.

• 나의 이야기1.
• 수강 전 나의 상태...*

1. QA 관련 경험 X
2. 비전공자
3. 유사 경험 종사 경험 X

• 취업 목표 (게임, 웹 QA)

• 나의 이야기2. 엘리스트랙의 커리큘럼과 학습방식
• 1. 기간*: 약 5개월
• 2. 가장 좋았던 파트 *: Python 이라는 새로운 언어를 배우는 주차
• 3. 실무 프로젝트 진행 여부* : 실무 경험이 부족하지만 코치님들의 지도 아래 성공적으로 프로젝트를 진행했습니다.
• 4. 팀 프로젝트 방식 :* 협업은 노션으로 진행하였고, 디스코드나 기타 메신저를 이용해 소통해가며 완성했습니다.

• 중요 !
• 수업방식*
• 1. 이론 vs 실습 *= 물론 이론의 비중이 크긴 하지만 스스로 하고자 하면 충분히 실습과 연계해서 기량을 채울수 있음.
• 2. 과제, 프로젝트 난이도* = 처음하는 분들끼리 팀이 되는게 아닌 현업자, 경험자, 밸런스 있게 섞어서 팀을 짜기에 부담없이 배우고 진행할 수 있었습니다.
• 3. 코치님 멘토링* = 개인적으로 연락을 해서 물어보게 되어도 친절하게 답변해주시고 부족한 부분에 대해서는 추가 피드백을 해주기 때문에 부족한 부분을 스스로 이해하고 채워 나갈 수 있는 시간이 많았습니다.

• 나의 이야기3.
• 결과 & 성장 변화*
• 부트캠프 전후의 실력비교*

1. QA를 준비하게 되면 코딩에 대한 지식은 많이 필요없을 줄 알았는데 더 좋고 높은곳을 향해 달려 가려면 필수역량이라는 것을 깨달았습니다
2. 직접 Python 코드와 친해지도록 노력하며 간단한 가위바위보 게임을 만들 수 있게 되었고, 간단한 코드 로직의 흐름을 읽을 수 있게 되었습니다
3. 무엇보다 실무에서만 경험할 수 있는 젠킨스와 같은 프로그램에 대해서도 간단하지만 공부하게 되어 부족한 경험을 조금이라도 가득가득 채울 수 있는 계기가 되었던 것 같습니다

• 취업 & 포트폴리오 엘리스 QA 트랙을 진행하면서 실무 경험이 없고, 관련 학과가 아닌 저에게 이력서에 자신있게 적을 수 있는 하나의 무기가 생긴 것 같아 뿌듯합니다. 또한 이력서를 보고 연락오는 회사가 조금씩 생겼으며 포트폴리오에도 배운 프로젝트를 기반으로 내용을 작성해 나가며 스스로의 커리어를 성장시키고 있습니다

• 엘리스트랙을 추천하고 싶은 사람

1. 일단 거기 이 글을 보고 고민하고 있는 QA 꿈나무? 일단 지원해
2. QA가 테스트만 하는 사람이라고 착각하는 사람들? 와서 들어봐 아니야..

• 나의 이야기4
• 커넥팅 데이 후기

1.** 구성** A. 2시 까지라 식사는 안주실 줄 알았는데 완전 맛있는스팸 도시락을 주셨어요 B. 엘리스트랙의 귀여운 굿즈와 이름표를 지급해주셨어요 C. 수료식 진행 D. 고인물 강사님 2분의 강의 E. 강사님들과 개별 Q&A 시간 F. 마무리 단체 사진과 함께 작별

2.** 좋았던 점**

• 취업이 안되는게 제가 부족하기 때문이라고 생각했었는데 현업자분들의 말을 듣고 여러 레이서 분들과 말을 나누다 보니 다들 힘드신건 마찬가지라고 하셔서 더욱 힘내서 취준 생활을 해야겠다고 다짐하는 개기가 되었습니다.

3.** 동료들에게 전하는 말**

• 부족한 저와 함께 프로젝트 해주셔서 감사합니다!!!!!!!!
• 대단히 신세 많이 졌습니다!!!!!

- 엘리스QA트랙의 수업 자료 맛보기

맛보기 입니다 궁금하면? [엘리스QA 트랙 2기] 들어가야겠지?

• Open API : 사용할 수 있는 공개된 API
  EX) Kakao Map API

• Private API 내부 시스템에서만 사용하는 API
  EX) 관리자 시스템 등

• Partner API 특정 파트너에만 제공되는 API
  EX) 결제대행 API

2. RESTful API란? REST는 API 설계의 일종 / 리소스를 중심으로 설계된 구조

RESTful API의 특징

URL은 명사 중심 (자원) → /users, /posts/3/comments

HTTP 메서드로 동작 구분 → GET, POST, PUT, DELETE

무상태성 (Stateless) → 요청 간 상태를 서버가 기억하지 않음

계층화 (Layered) → 중간 서버(캐시, 프록시 등)를 둘 수 있음

3. GraphQL API란? REST와는 다른 방식으로 데이터를 주고받는 API

4. Webhook이란?

• API는 보통 클라이언트가 서버에 요청하는 방식 Webhook은 서버가 클라이언트에 이벤트 발생 시 자동 전송하는 방식

• EX) 결제 완료 시, 카카오 알림톡이 자동으로 전송되는 구조

5. API 응답 구조 (표준화)

{
  "success": true,
  "data": {
    "id": 1,
    "name": "홍길동"
  },
  "error": null
}

6. API Gateway란? 여러 개의 API 서비스를 하나로 통합해서 관리하는 중간 관리자 역할을 하는 서버

주요 기능

• 라우팅 (요청 전달)

• 인증/인가 처리

• 요청 제한(Rate Limiting)

• 로깅/모니터링

손님(당신) = 사용자 주방 = 서버(정보가 있는 곳) 직원 = API

API는 사용자의 요청을 서버로 전달하고, 결과를 다시 사용자에게 전달해주는 중간자 역할

2. API 작동 방식 (기본 개념)

메서드 / 설명/ 예시

GET / 정보 가져오기 / 유저 리스트 보기 POST / 새 데이터 생성 / 회원가입 하기 PUT / 데이터 전체 수정/ 유저 정보 전체 수정하기 PATCH / 데이터 일부 수정/ 유저 이메일만 바꾸기 DELETE / 데이터 삭제 / 게시글 삭제하기

3. Postman이란?

• API를 쉽게 테스트하고 요청을 보내볼 수 있는 도구

4. Postman으로 할 수 있는 것

• API 요청 보내기 (GET, POST, PUT, DELETE 등)

• 요청에 헤더/바디 설정

• 응답 확인 (상태 코드, 데이터 확인)

• 테스트 스크립트 작성

• API 자동 문서화

5. Postman의 주요 기능

5-1. Request 보내기

• 원하는 API 주소(URL) 입력하고

• 메서드 선택 (GET, POST 등)

• 필요한 헤더, 파라미터, 바디 입력 후

• Send 버튼 클릭하면 서버에 요청 전송

5-2. Response 확인

• 응답 데이터(JSON 등)

• 응답 코드 (200, 404, 500 등)

• 응답 시간, 크기

• 전체 응답 로그 확인 가능

5-3. 컬렉션 (Collections)

• 자주 사용하는 API 요청들을 폴더처럼 모아놓을 수 있음

• 예: 회원관리, 게시판, 결제 등으로 그룹화 가능

• 팀 프로젝트나 자동화 테스트에서 매우 유용함

5-4. 환경(Environment) 설정

• 같은 요청을 다른 서버(개발/운영) 에 보내야 할 때 사용

5-5. Authorization (인증)

• 토큰을 헤더에 넣는 식의 인증 처리를 쉽게 가능

• 토큰, Basic Auth, OAuth 등 다양한 인증 방식 지원

5-6. 테스트 스크립트 작성 (Tests 탭)

• 요청 후 응답을 자동으로 검사할 수 있음

• 예: 응답코드가 200인지 확인

5-7. Pre-request Script 요청 전에 실행되는 스크립트

보통 토큰 생성, 타임스탬프 추가 등에 사용

2. 자동화를 사용해서 얻는 장점

1. 반복적인 테스트를 자동화하여 개발 속도 향상
2. 사람의 실수를 줄이고 더 정확한 검증 가능
3. 코드 수정 후 빠르게 문제점을 발견 가능

** 3. unittest**

import unittest

# 테스트할 함수
def add(a, b):
    return a + b

# 테스트 클래스 (unittest.TestCase 상속)
class TestMathOperations(unittest.TestCase):
    def test_add(self):
        self.assertEqual(add(2, 3), 5)  # 2 + 3 = 5 확인

if __name__ == "__main__":
    unittest.main()

# unittest.TestCase를 상속해서 테스트 클래스 작성
# 그 후 self.assertEqual(결과, 예상값)을 사용해 검증

# unittest 실행 방법
python -m unittest test_script.py # 입력

3. pytest의 고급 기능과 데이터 기반 테스트 pytest = unittest보다 더 간단한 문법과 강력한 기능을 제공하는 테스트 프레임워크

* 프레임 워크 : 소프트웨어 개발을 쉽게 할 수 있도록 미리 만들어진 기본 구조

#pytest 설치
pip install pytest # 터미널에 입력


# 테스트할 함수
def multiply(a, b):
    return a * b

# pytest 테스트 함수
def test_multiply():
    assert multiply(3, 4) == 12  # 3 * 4 = 12 확인

#pytest 실행 방법
pytest test_script.py # 터미널에 입력

4. 테스트 데이터 생성 및 관리 기법

1. 테스트 실행 -> 입력값과 예상 결과값 필요
2. 소규모 프로젝트 -> 딕셔너리 리스트 사용
3. DB 테스트 -> 가상 데이터 생성 필요

대상혁(faker) 라이브러리를 활용한 가짜 데이터 생성

 pip install faker # 터미널 입력

 from faker import Faker

fake = Faker()

# 가짜 사용자 데이터 생성
print(fake.name())  # 랜덤 이름
print(fake.email())  # 랜덤 이메일
print(fake.address())  # 랜덤 주소

5. Appium을 활용한 모바일 UI 테스트 자동화 Appium = 모바일 앱 UI 테스트를 자동화하는 도구

1. Android, iOS 앱을 테스트할 수 있음
2. Python과 함께 사용할 수 있음
3. UI 요소를 찾아 클릭, 입력 등의 동작을 수행 가능

   pip install Appium-Python-Client # 터미널 입력
   

from appium import webdriver

Appium 서버 설정

capabilities = { "platformName": "Android", "deviceName": "emulator-5554", "app": "/path/to/app.apk" # 테스트할 앱 경로 }

driver = webdriver.Remote("http://localhost:4723/wd/hub", capabilities)

앱의 특정 버튼 클릭

driver.find_element("id", "com.example.app:id/button").click()

Selenium은 웹 브라우저를 자동으로 제어할 수 있는 오픈소스 도구 크롤링(데이터 수집), UI 테스트 자동화 등에 활용됨

2. 웹 요소 찾기(DOM 탐색)

from selenium import webdriver

driver = webdriver.Chrome()  # 크롬 브라우저 실행
driver.get("https://example.com")  # 웹페이지 접속

# 요소 찾기
element = driver.find_element("id", "username")  # ID로 요소 찾기
element.send_keys("test_user")  # 입력 값 넣기

#자주 사용하는 요소 선택 방법!!

find_element("id", "example") : ID로 요소 찾기
find_element("name", "example") : name 속성으로 찾기
find_element("xpath", "//*[@id='example']") : XPath로 찾기
find_element("css selector", ".example") : CSS 선택자로 찾기

• XPath = HTML 문서의 특정 요소를 찾기 위해 경로를 지정하는 방식
• CSS 선택자 = HTML 요소를 스타일링할 때 사용되는 방식

3. 웹페이지 자동 로그인 및 데이터 크롤링

#자동 로그인
driver.find_element("id", "username").send_keys("my_id")
driver.find_element("id", "password").send_keys("my_password")
driver.find_element("id", "login-button").click()  # 로그인 버튼 클릭

#데이터 가져오기
data = driver.find_element("id", "content").text  # 텍스트 가져오기
print(data)

4. 일정 관리 시스템 UI 자동화

driver.find_element("id", "add-event").click()  # 일정 추가 버튼 클릭
driver.find_element("id", "event-title").send_keys("회의")  # 일정 입력
driver.find_element("id", "save-button").click()  # 저장 버튼 클릭

5. 비동기 데이터 로딩 및 에러 처리

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# 특정 요소가 로드될 때까지 기다리기
wait = WebDriverWait(driver, 10)
element = wait.until(EC.presence_of_element_located((By.ID, "dynamic-content")))
print(element.text)

• 쿠키는 사용자의 브라우저에 저장되는 작은 텍스트 파일이야!

서버 친구가 클라이언트 친구에게 쿠키를 선물하면, 브라우저 친구는 쿠키를 저장하고, 동일한 서버에 요청을 보낼 때 마다 쿠키를 자동으로 전송해줘!!

사용 목적

1. 사용자 인증 상태 유지 (로그인 상태 유지)
2. 사용자 설정 저장 (언어, 테마 등)
3. 방문한 사이트 추적 (분석 도구나 광고 추적용)

특징

1. 클라이언트에 저장: 쿠키는 클라이언트(사용자의 브라우저)에 저장됨!

2. 유효 기간 설정 가능: 쿠키에는 만료 시간이 설정되어 있어, 일정 시간이 지나면 자동으로 삭제됨

3. 크기 제한: 한 개의 쿠키 크기는 일반적으로 4KB 이하로 제한됨!!

4. 보안: 쿠키는 클라이언트에 저장되기 때문에, 보안에 취약할 수 있습니다. 이를 해결하기 위해 Secure 플래그(HTTPS 연결에서만 전송)나 HttpOnly 플래그(자바스크립트 접근 차단)를 사용할 수 있다

세션은 몰까?

1. 세션은 서버 측에서 관리되는 사용자 상태 정보

2. 세션은 사용자가 웹 애플리케이션에 접속할 때 서버에서 생성 됨

3. 사용자가 요청을 보낼 때마다 고유한 세션 ID가 클라이언트로 전달

4. 세션 ID는 보통 쿠키에 저장되며, 이를 통해 서버는 해당 사용자의 상태를 추적가능!

사용 목적

1. 로그인 세션 유지(우리가 사용하는 ID 저장기능?)
2. 장바구니, 결제 등 일시적인 상태 유지

특징

1. 서버에 저장: 세션 데이터는 서버에 저장되고, 클라이언트는 세션 ID만 저장해!

2. 세션 ID: 세션 ID는 쿠키나 URL 파라미터를 통해 클라이언트와 서버 간에 주고받을 수 있어!

(*파라미터 : 어떤 함수나 요청에 추가적인 정보를 전달하는 값)

3. 유효 기간: 세션은 일반적으로 사용자가 로그아웃하거나 일정 시간 동안 활동이 없으면 만료됨!

4. 보안: 세션 데이터는 서버에 저장되기 때문에 상대적으로 안전하지만, 세션 ID가 탈취되면 보안 위협이 있을수 있음

요약 정리! <쿠키>

1. 쿠키는 클라이언트 측에 저장됨

2. 사용자가 방문한 사이트에 대한 설정이나 정보를 유지하는 데 사용

3. 주로 사용자의 인증 정보를 저장

4. 사용자가 페이지를 새로 고침하거나 다른 페이지로 이동할 때도 정보를 유지할 수 있게함

<세션>

1. 서버 측에서 관리

2. 사용자의 상태(로그인 상태 등)를 서버에서 추적하는 데 사용

3. 보통 중요한 정보는 서버에서 관리하며, 클라이언트에는 세션 ID만 전달됨

#for range 2 : 횟수로 반복하는 방법 (a)번 만큼 수행

#for 변수 in range(a):
#    <수행 할 명령>

count = 0
for i in range(10):
    count = count + 1

print(count) #10

#for range 3 : range와 len, 인덱싱을 이용가능
str = ["a", "b", "c", "d"]
for idx in range(len(str_list)):
    print(idx)

for idx in range(len(str_list)):
    print(str_list[idx])

#while문 : 조건 -> while -> 명령
# 조건이 맞으면 (True) 계속 실행된다
# 조건이 틀리면(False) 종료된다
while 조건:
    <수행 할 명령>

num = 5

while num > 0:
    print(num)
    num = num - 1

print("good day")

i = 1
sum = 0
while i < 5:
    sum = sum + i
    i = i + 1

print(sum) #10



#while문에서 조건이 항상 True일때 -> 무한루프 상태가됨

i = 1
while i > 0:
    print(i)
    i = i + 1

print("종료")



#break 문 : if문으로 조건을 걸고 break문 실행 -> 반복문 탈출
number = 1

while True:
    print("good day")

    if number >= 5 :
    break

    number = number + 1

print(number)

#continue문 : if문으로 조건을 걸어준 다음 #continue실행 -> 반복문을 건너뛰는 역할

for number in range(1, 11):

    if number % 2 !=0:
    continue

    print(number)

1. 사람이 직접 하지 않고 컴퓨터가 자동으로 테스트 하는것
2. 버튼 클릭, 로그인, 데이터 입력 등 반복 작업을 자동으로 수행
3. 더 빠르게 정확하게 테스트가 가능함

2. 테스트 자동화의 단점

1. 초기 설정이 어렵다 : 처음에는 코드를 작성해야 해서 시간이 걸림
2. 유지보수가 필요하다: 프로그램이 바뀌면 테스트도 업데이트를 해야함
3. 모든 테스트를 자동화 할수는 없다: 사용자 경험 테스트는 여전히 사람이 해야함

3. 주요 테스트 자동화 유형

1. 단위 테스트 (Unit Test) : 코드 한 조각이 제대로 작동하는지 확인하는 테스트
2. 통합 테스트 (Integration Test) : 여러 기능이 함께 작동하는지 확인하는 테스트
3. UI 테스트 : 실제 화면에서 버튼, 입력창 등이 잘 동작하는지 확인하는 테스트
4. API 테스트 : 서버와 데이터가 올바르게 주고 받아지는지 확인하는 테스트

4. 대표적인 테스트 자동화 도구

5. 단위 테스트

1. 코드의 가장 작은 단위(함수, 메서드)를 테스트
2. 개발자가 기능을 만들 때 바로 확인하는 테스트
3. 빠르게 쉽게 실행 가능

6. 단위 테스트가 필요한 경우

1. 새로운 기능을 추가할 때
2. 기존 기능이 고장 나지 않았는지 확인할 때
3. 반복적인 작업을 자동화하여 실수 방지
4. 빠른 피드백으로 개발 생산성 향상
5. 배포 후 심각한 오류 발생 가능성 최소화

7. 성공적인 테스트 자동화 적용 방법

1. 반복적인 테스트부터 자동화하기
2. 적절한 도구 선택하기
3. 테스트 자동화 유지보수 전략 수립

8. 자동화 할 수 있는 테스트 유형

1. 반복적으로 실행해야 하는 테스트
2. 명확한 입력과 출력을 가진 테스트
3. 실행 속도가 중요한 테스트(단위, API 테스트)

9. 자동화가 어려운 테스트 유형

1. UI가 자주 변경되는 테스트
2. 사용자의 감각적 평가
3. 실시간 데이터가 필요한 테스트

10. UI 테스트 자동화의 유지보수 문제

1. UI 요소가 변경되면 테스트 코드도 함께 수정해야 함
2. 화면 구조 변경 시 테스트가 실패할 가능성이 높음

11. API 테스트 자동화의 어려움

1. 외부 API 응답이 변할 가능성이 있음
2. 네트워크 상태나 서버 상태에 따라 테스트 결과가 달라질 수있음

12. 테스트 자동화 유지보수의 핵심요소

1. 테스트 환경을 일정하게 유지
2. 테스트 데이터를 관리하여 예측 가능한 상태 유지
3. 테스트 실행 속도를 최적화하여 불필요한 지연 방지
4. 테스트 실패 시 자동 로그 기록하여 원인 분석 가능하도록 설정

13. 코드 변경이 잦을 때 발생하는 문제

1. 기존 테스트 코드가 깨질 가능성이 높음
2. 유지 보수 비용증가
3. 코드 수정 후 테스트 결과가 일관되지 않을 수 있음

14. 테스트 자동화의 도입 이유

1. 반복적인 테스트 감소 -> QA팀의 업무 효율성 증가
2. 빠른 피드백 제공 -> 개발 속도 증가 및 품질 유지
3. 대규모 테스트 수행가능 -> 다양한 환경에서 테스트 실행 가능

15. KPI란?

1. 핵심 성과 지표, 즉 목표 달성을 측정하는 기준
2. 성과를 수치화 하여 자동화 테스트의 효과를 평가할 수 있음

16. 테스트 자동화에서 KPI의 역할

1. 자동화 도입 후 성과를 측정하는 기준 제공
2. 테스트의 실행 속도 및 오류 감지율 평가 가능
3. 불필요한 테스트 자동화를 방지하여 효율적인 운영 가능

17. 자동화 테스트 도입 전 필수 체크 항목

1. 자동화할 테스트 유형 결정 -> 단위,UI,API,성능 테스트 등
2. 유지보수 비용 고려 -> 유지보수 가능성 및 인력 확보 여부
3. 팀 내 기술 역량 평가 -> 자동화 도구 활용 능력 점검
4. 테스트 환경 표준화 -> CI, CD 연계 가능성 확인
5. 적절한 자동화 도구 선택 -> 프로젝트 요구사항과 도구의 적합성 비교

18. 환경 구성 자동화

1. 테스트 환경을 코드로 정의하여 자동으로 구축하는 방식
2. 서버, 네트워크, 애플리케이션 설정을 자동화하여 일관성 유지

*19. Mock 데이터 *

1. 테스트 할 때 실제 데이터를 사용하지 않고 가짜 데이터를 활용하는 방법
2. 운영 데이터를 직접 사용할 수 없는 경우 대체할 수있음
3. API 테스트,UI 테스트, 성능 테스트 등 다양한 환경에서 사용

1. 작업 흐름 추적 -> 진행 중 / 완료 / 보류 상태 관리
2. 이슈 관리 -> 버그 발생 -> 할당 -> 수정 -> 확인 -> 해결
3. 팀 협업 지원 -> 댓글. 태그 기능으로 개발자와 QA 간 소통

2. 관리툴마다 다른 용도

1. Jira : 버그 및 이슈 트래킹
2. Notion : 문서 정리 및 협업
3. Trello : 간단한 작업 보드
4. TestRail : QA 테스트 케이스 관리

3. 인원에 따라 다른 툴 사용법

1. 1~5명의 팀 : Trello, Notion
2. 5 ~ 20명의 팀 : Jira, Notion
3. 20명 이상의 대기업 : Jira, TestRail

4. 관리 툴의 비용 비교

5. Jira를 사용하는 이유

1. 프로젝트 관리 및 버그 추적 용이
2. 애자일 및 스크럼 환경에서 널리 사용됨
3. 소프트웨어 개발 뿐 아니라 다양한 프로젝트 관리에도 활용가능

6. Jira의 주요기능

• 프로젝트 관리 : 여러 개의 이슈를 모아 하나의 프로젝트로 관리
• 이슈 관리 : 이슈 생성, 할당 및 상태 변경
• 보고서 및 대시보드 : 진행 상황을 시각적으로 분석
• 스크럼 및 칸반 보드 : 애자일 방식으로 업무를 관리

7. 워크 플로우

1. 작업이 어떤 단계를 거쳐 진행되는지를 정의한 프로세스
2. 기본 워크 플로우 : To Do -> In Progress -> Done

8. 버그 리포팅 작성방법

1. 제목 : 버그의 요약
2. 설명 : 버그가 발생한 환경과 상세 내용
3. 재현 단계 : 버그가 발생하는 과정을 순서대로 정리
4. 기대 결과 vs 실제 결과 : 원래 예상된 동작과 실제 동작 비교
5. 스크린샷 첨부 : 시각적 자료 제공

9. Jira의 커스텀 필드

1. Jira에서 기본 제공되는 필드 외에 추가로 필요한 정보를 입력할 수 있는 기능
2. 팀의 필요에 맞게 설정 가능

10. Notion

1. 노트, 문서, 데이터 베이스, 프로젝트 관리 기능을 모드 제공하는 공간
2. 개인부터 팀 협업까지 다양한 용도로 사용 가능
3. 템플릿을 활용해 쉽게 업무 프로세스 구축

11. Notion이 다른 툴과 다른 점

1. 문서작성 + 테스트 관리 + 협업 도구를 하나로 통합
2. 사용자가 원하는 형태로 커스텀마이징 가능
3. 간단한 UI로 배우기 쉽지만 강력한 기능 제공

12. Notion으로 할수 있는 3가지 핵심 기능

1. 문서 작성 : 자유롭게 텍스트 및 멀티미디어 삽입
2. 테스트 관리 : 칸반 보드를 활용한 프로젝트 관리
3. 데이터베이스 활용 : 버그 리포트 및 QA 문서 정리

13. 칸반 보드

1. 시각적으로 작업 흐름을 관리하는 보드 형태의 시스템
2. Jira, Trello 등에서도 사용되는 방식

14. Notion에서 협업하는 방법

1. 문서 작성 및 실시간 공동 편집 가능
2. 댓글 기능을 활용한 피드백 제공
3. 특정 사용자에게 작업 할당 가능

15. To-Do lIST 기능

1. 체크박스를 활용해 할 일을 쉽게 정리할 수 있는 기능
2. 작업 완료 시 체크하여 진행 상황을 빠르게 확인 가능

16. 캘린더 기능

1. 특정 날짜에 해야 할 일이나 마감 기한을 설정 할 수있음
2. 일정 기반으로 작업을 계획하고 관리하는 기능

17. 작업 흐름

1. 작업이 시작될 때 부터 완료까지 진행되는 과정
2. 업무의 효율성을 높이고, 진행 상태를 명확하게 관리하는 역할
3. 버그 수정, 개발, QA 등 모든 프로세스에 필수

2. 오류(Error) : 코드 실행 중 발생하는 문제

3. 결함(Defect) : 코드의 설계나 논리적 문제

4. 버그 발생의 주요 원인

1. 코딩 실수: 사람이 작성한 코드는 종종 작은 실수로 인해 큰 문제를 발생시킴
2. 요구사항 미스매치 : 요구사항이 정확히 전달되지 않으면 버그가 발생
3. 복잡한 시스템 : 하나의 테이블 변경이 여러 다른 테이블에 영향을 미쳐 오류 발생

5. 버그가 만드는 사용자 불만

1. 사용자는 시스템이 안정적이고 기대에 부합하길 원함
2. 사용자 기대를 충족하지 못하게 만들어 불만을 유발함

6. 버그로 인한 매출 손실

• 결제 오류, 상품 정보 오류 등은 직접적으로 매출 손실로 이어집니다

7. 브랜드 신뢰의 하락

• 계발 단계 버그 발생
• 부정적 리뷰 증가
• 신규 고객의 감소

8. 버그는 연쇄적으로 문제를 일으킨다

• 하나의 버그가 다른 문제를 유발하며, 시스템 전반에 영향을 미침
• 해결을 위한 비용과 시간이 필요함

9. 사용자의 만족도를 보장하는 QA

1. QA는 사용자가 제품을 문제 없이 사용할 수 있도록 하는 것

10. QA는 제품 개발의 방향을 제시한다

1. QA는 테스트 결과를 통해 프로세스를 개선
2. 반복적인 실수를 줄이고 개발 효율성을 높힘

11. QA는 조직의 연결고리

1. QA는 개발팀과 운영팀 간의 가교 역할을 합니다
2. 문제를 분석하고 해결책을 제안하며 모든 팀이 같은 목표를 향해 협력하도록 조력자의 역할을 한다

12. QA의 주요 역할

1. 품질 보증 : QA는 제품이 안정적으로 작동하도록 품질을 보증합니다

2. 문제 탐지 : QA는 다양한 테스트를 통해 SW의 문제를 탐지합니다

3. 테스트 설계 : 효율적인 테스트 설계는 QA의 중요한 업무중 하나입니다

4. 요구 사항 전달 : QA는 명확한 요구사항을 개발팀에게 전달합니다

5. 테스트 결과 문서화 : QA는 테스트 결과를 문서화하여 개발팀과 공유합니다

6. 개발프로세스 개선 : QA는 반복적으로 발생하는 문제를 분석하여, 개발 프로세스를 개선합니다

7. 사용자 관점 대변 : QA는 사용자 관점에서 문제를 발견하고 해결합니다

8. 버그 예방 : QA는 사전에 문제를 발견하여, 출시 후 발생할 문제를 예방합니다

*13. 버그 리포팅 * : 문제를 개발팀에게 전달하는 핵심 과정

14. 잘못된 리포팅으로 인한 문제

1. 문제 해결 지연
2. 개발팀의 불필요한 시간 낭비
3. 추가 비용 발생

15. 나쁜 리포트, 문제를 더 복잡하게 만들 수 있음

1. 불명확한 제목 : 문제를 제대로 요약하지 못함
2. 재현 단계 누락 : 개발자가 문제를 재현할 수 없음
3. 기대 결과와 실제 결과 구분이 없음
4. 스크린샨 등 추가 자료 누락

16. 기능 버그의 유형

1. 입력 오류

• 사용자 입력이 올바르게 처리되지 않음

2. 프로세스 오류

• 여러 단계로 이루어진 기능이 중간에서 끊김

3. 계산 오류

• SW가 수치를 잘못 계산하여 잘못된 결과를 반환하는 문제
• 주로 금융, 통계, 이자 계산, 할인 적용 등에서 치명적

4. UI/UX 버그

• SW의 화면 구성(UI)과 사용자 경험 (UX)에 영향을 주는 문제
• 기능에는 문제가 없지만, 사용자가 불편함을 느낌

4-1. UI/UX 버그는 왜 생길까?

1. 반응형 디자인 오류 : 모바일/태블릿/PC 화면 크기에 따라 달라짐
2. 사용자 테스트 부족 : 실제 사용자가 불편한지 확인하지 않음
3. 디자인 가이드 미준수 : 버튼 크기, 글자 크기 등의 표준을 따르지않음

17. 성능 버그의 유형

1. 속도 지연

• 사용자가 버튼을 클릭했을 떄 응답이 느리거나 멈추는현상
• 주로 서버, DB, 코드 최적화 부족 등이 원인

2. 서버 과부하

• 사용자가 많아질수록 응답 속도가 느려지거나 서버가 다운되는 현상
• 트래픽 증가 시 서버가 처리할 수 있는 한계를 초과할 때 발생

18. 성능 테스트

1. SW가 다양한 환경에서 얼마나 안정적으로 실행되는지 평가하는 과정
2. 응답 속도, 처리 속도, 메모리 사용량 등을 테스트하여 성능 버그를 찾아냄

19. 대표적인 성능 테스트 유형

1. 부하 테스트 : 동시 접속 시 속도가 어떻게 변하는지 확인
2. 스트레스 테스트 : 극한의 조건에서도 시스템이 견딜 수 있는지 확인
3. 반응 속도 테스트 : 사용자의 요청에 대한 응답 시간을 측정

20. 코드 최적화를 통한 성능 개선 방법

1. 불필요한 연산 줄이기 -> 코드에서 반복되는 계산 최소화
2. DB 쿼리 최적화 -> 불필요한 호출 제거
3. 이미지 및 리소스 최적화 -> 웹 페이지 로딩 속도를 빠르게 하기 위해 압축된 이미지 사용

21. 성능 버그 예방

1. 정기적인 성능 모니터링 -> 서버 부하, 응답 속도 체크
2. 트래픽 증가 대비 서버 확장 준비 -> 클라우드 환경에서 자동 확장 적용
3. 배포 전 성능 테스트 필수 진행 -> 실사용 환경과 유사한 조건에서 성능 검증

22. 보안 버그

1. 시스템이 사용자의 정보나 데이터 보호에 실패하는 문제
2. 권한 없는 접근, 데이터 유출, 악성 코드 실행 등이 포함됨

23. 데이터 암호화 오류

1. 중요한 정보가 암호화되지 않고 저장되는 문제

24. XSS(크로스 사이트 스크립팅)

1. 공격자가 악성 스크립트를 웹 사이트에 삽입하여 사용자 정보 탈취
2. 로그인 정보 유출, 피싱 공격이 가능

25. CSRF(사이트 간 요청 위조)

1. 사용자가 모르는 사이 공격자가 특정 요청을 실행하도록 유도
2. 비밀번호 변경, 계좌 이체 등 무단 요청 실행

26. SQL Injection(인젝션)공격

1. 공격자가 입력창을 이용해 DB에 직접 명령어를 입력하는 방식
2. 데이터 유출, 관리자 계정 탈취가 가능

27. 패킷 스니핑(Packet Sniffing)

1. 해커가 네트워크에서 주고받는 데이터를 몰래 훔쳐보는 공격
2. 로그인 정보, 신용카드 번호가 탈취될 수 있음

28. 보안 사고 발생 시 대응

1. 사고 감지 및 초기 대응 -> 이상 징후 감지 후 즉시 차단
2. 원인 분석 및 복구 -> 해킹 경로 및 피해 분석 후 패치 적용
3. 보안 강화 및 재발 방지 대책 마련 -> 추가 보안 정책 적용
4. 표준 기술 사용 -> HTML, CSS, JavaScript 최신 표준을 준수
5. 반응형 디자인 적용 -> 다양한 해상도에서 UI가 정상적으로 보이도록 개발
6. OS/브라우저별 예외 처리 -> 환경에 따라 다르게 동작해야 하는 부분을 고려

29. 완벽한 테스트가 불가능 한 이유

1. 테스트 환경과 실제 환경의 차이
2. 사용자 데이터 및 트래픽 증가
3. 예기지 못한 사용자의 행동

1. 시스템의 구성 요소와 그들 간의 관계 및 상호작용을 정의하는 구조
2. SW시스템의 품질을 유지하고 확작성, 안정성, 보안성을 확보

2. 소프트웨어 아키텍처의 중요성

• 시스템의 복잡도를 관리 및 유지보수 비용 절감
• 다양한 팀 간의 협업을 효과적으로 지원
• 성능, 확장성, 보안성을 보장

3. 앱 아키텍처의 주요 구성 요소

4. 각 구성 요소의 상호 작용

5. 프론트엔드의 역할

• 사용자 인터페이스 제공
• 사용자 입력 처리 및 시각적인 콘텐츠 출력
• API 호출을 통해 백엔드와 데이터 통신

6. 데이터 베이스 설계원칙

1. 정규화 : 중복 데이터를 최소화하여 데이터 무결성 확보
2. 인덱스 최적화 : 검색 속도를 높이기 위한 인덱스 설정
3. 보안 : 민감한 데이터를 암호화하고 접근 권한을 관리

7. 클라이언트 - 서버 모델의 장단점

8. 클라이언트란 무엇인가?

클라이언트 : 서버에 요청을 보내고, 응답을 받아 사용자와 상호작용하는 장치 또는 애플리케이션

주요역할

• 사용자 인터페이스 제공
• 사용자 입력 처리 및 시각적인 콘텐츠 출력
• API 호출을 통해 백엔드와 데이터 통신

9. 서버란 무엇인가?

서버 : 클라이언트의 요청을 처리하고 데이터 연산 및 저장을 담당하는 중앙 컴퓨터 또는 시스템

주요역할

• 클라이언트의 요청 처리 및 응답 생성
• 데이터 베이스와 상호작용
• 비즈니스 로직 실행 및 데이터 검증

10. 서버의 기술적 구성 요소

11. 데이터 통신에서의 보안과 최적화

보안 : SSL/TLS를 사용한 데이터 암호화 : 인증 토큰(JWT, OAuth) 활용

최적화 : 데이터 압축(Gzip)으로 네트워크 사용량 감소 : CDN(Content Delivery Network)으로 데이터 전송 속도 향상 : 캐싱을 통해 반복 요청 최소화

12. RESTful API란 무엇인가?

: Representational State Treansfer 원칙을 준수하는 API

1. 무상태성 : 서버가 클라이언트 상태를 저장하지않음
2. 리소스 기반 설계: URL로 리소스를 식별 .3. HTTP 메서드 활용 : GET, POST, PUT, DELETE

13. API응답 구조

14. 데이터 포맷의 종류와 특징

JASON

• 경형 데이터 교환 포맷
• 사람이 읽기 쉬우며 대부분의 언어와 호환
• 가볍고 처리 속도가 빠름

XML

• 데이터 저장 및 전송에 사용
• 태그 기반 구조로 유연성이 높음
• 복잡한 데이터 표현에 적합

15. API 인증의 필요성

16. 고급 인증 방식

JWT: 클라이언트가 서버와 통신할 때 인증 상태를 유지 OAuth 2.0 : 엑세스 토큰을 통해 인증 및 권한 부여 인증과 권한을 분리하여 보안강화

17. 사용자 인터페이스(UI)란 무엇인가?

UI(User Interface) : 사용자가 앱과 상호작용하는 시각적, 물리적 구성 요소

1. 사용자가 앱의 기능을 쉽게 접근하고 이해하도록 설계
2. 복잡한 비즈니스 로직이나 데이터 흐름을 추상화하여 사용자 친화적으로 제공

18. UI 설계의 원칙

1. 일관성 : 버튼, 메뉴 등 디자인 요소가 일관되어야함
2. 직관성: 사용자사 쉽게 학습하고 사용할 수 있어야함
3. 응답성 : 사용자 입력에 빠르게 반응
4. 접근성 : 다양한 사용자(장애인)가 쉽게 사용가능해야함

19. 데이터 저장소 계층이란?

: 데이터를 저장하고 관리하는 계층으로, DB와 연결됨

1. 데이터를 안전하게 저장
2. 빠르고 효율적인 데이터 검색
3. 데이터 일관성 및 무결성 유지

20. 데이터베이스의 주요 구성 요소

21. 관계형 데이터 베이스

: 테이블 간의 관계를 기반으로 데이터를 관리

1. 데이터의 정형화된 구조
2. 관계를 통해 데이터 일관성과 무결성을 유지

22. 비관계 데이터 베이스

: 테이블 구조를 따르지 않고 데이터를 유연하게 저장

1. 비정형 데이터 처리에 유리
2. 스키마가 필요 없으며 확장성이 높음

23. 데이터 모델링

: 데이터베이스 구조를 시각적으로 설계하는 과정 데이터를 효율적으로 저장하고 관계를 정의

1. 데이터 중복 방지
2. 데이터베이스의 일관성과 무결성 보장

24. 데이터 교환 시 고려 사항

주로 결함이 나오지 않게 예방활동을 함

2. QC : Quality control

주로 검증활동을 진행함

3. QC와 QA의 주요 활동

4. QC와 QA의 협력

5. QA가 프로젝트 범위를 정하는 방법

1. 반드시 해야할 일 70%
2. 필요 없는 일 20%
3. 우선순위가 낮은 일 10%

6. 품질 기준 설정의 중요성

1. 품질에 대한 목표치를 명확하고 측정 가능하게 해야함

7. QA 체크리스트로 계획 단계의 성공 보장

1. 요구사항 검토 완료 여부
2. 품질 기준 정의 여부
3. 초기 리스크 문서화 여부

8. 계획 단계에서 QA가 직면하는 문제들

1. 요구사항의 모호성
2. 품질 기준 설정의 어려움
3. 이해관계자 간 의사소통 부족

9. QA 활동 실패 시 발생할 리스크

1. 품질 목표와 프로젝트 목표 간 불일치
2. 재작업 증가로 인한 비용 초과
3. 초기 결함 발견 실패로 인한 후속 단계의 문제

10. 요구사항 정의 단계의 목적 테스팅 원리

소프트웨어가 무엇을 해야하는지 명확히 규정 QA의 역할 : 요구사항이 명확하고 실현 가능하며, 품질 기준에 부합하도록 검토

11. SRS 검토에서 QA의 기여

1. SRS : software requirements specification) =요구 사항 명세서

12. 요구사항 변경 관리와 QA의 역할

요구사항) 로그인 화면에서 OTP 인증을 추가해주세요

1. 요청된 변경사항이 기존 요구사항 문서와 일치하나?
2. 프로젝트 범위 및 목표와 일치하나?
3. 시스템 성능이 영향을 받진 않을까?

13. QA툴로 요구사항 명확히 하기

14. 요구사항 정의를 위한 효과적인 커뮤니케이션

15. 설계 단계에서 QA 참여의 중요성

1. 시스템의 구조와 동작을 정의
2. QA의 역할 : 초기 설계단계 참여로 품질 문제 사전 방지

16. 설계 검토에서 QA의 역할

1. 아키텍처 검토
2. 요구사항 매핑
3. 설계 문서 검증

17. 설계 검증 활동의 주요 요소

1. 요구사항과 설계 간의 일치성 확인
2. 기능/비기능적 요구사항의 충족 여부 검증

18. 품질 기준 충족을 위한 QA 접근법

1. 품질 기준 점검
2. 명확하고 측정 가능한 설계 보장 = 잠재적 결함 예방

19. 설계 단계에서 QA와 개발 팀 협업

1. 정기적인 설계 리뷰 미팅
2. 품질 문제 식별 및 해결 방안 제안

20. 코드 리뷰에서 QA의 역할

21. 정적 분석 도구를 활용한 코드 품질 개선

1. 코드 복잡도
2. 잠재적 버그
3. 보안 취약점

22. 소스 코드 품질 기준과 QA 검토

1. 일관성, 가독성, 효율성을 따짐

23. 지속적 통합(CI) 프로세스와 QA

1. CI : 여러 사람이 동시에 작업할 때, 지속적으로 결과물을 합치고 자동화된 테스트를 통해 문제를 찾도록 도와주는 도구 (Jenkins, Github)

2. QA의 역할

• 자동화된 품질 점검
• CI 과정에서 발견된 결함 관리

24. 구현 단계에서 QA의 주요 확인 항목

1. 코드 표준 준수 여부
2. 테스트 가능성
3. 성능 및 보안 문제

25. QA 도구 활용으로 품질 관리 강화

1. Github로 코드 품질 자동화
2. 코드 변경 사항 테스트
3. 린트와 정적 분석 수행

26. 테스트 자동화 도구 활용

1. 셀레니움 : 웹 애플리케이션 자동화
2. 어피움 : 모바일 웹 테스트 자동화

27. 수동 테스트와 자동화 테스트의 조화

28. 회귀 테스트의 중요성테스팅 원리

29. 품질 보증을 위한 QA 활동

1. 자동화와 수동 테스트의 병행
2. 결함 보고 및 관리
3. 테스트 결과의 지속적인 피드백 제공

-> 품질 보증 극대화

30. 테스트 단계에서 발생하는 문제와 해결책

31. 비기능 테스트에서의 QA의 역할

1. 성능 테스트 : 시스템의 속도와 반응시간 측정
2. 보안 테스트 : 취약점 식별 및 보안 강화를 위한 검증
3. 확장성 테스트: 사용자 증가에 따른 시스템 처리 능력 확인

32. 테스트 환경 설정에서의 QA의 역할

1. 테스트 환경 구성 요소 확인
2. 실제 운영 환경과 유사한 환경 구축
3. 환경 검증 : 환경 설정 오류와 불일치 식별

33. 테스트 단계에서 QA의 모범사례

34. 사용자 수락 테스트에서 QA의 기여

1. UAT계획 및 시나리오 작성 지원
2. 테스트 결과 분석 및 문제 해결 지원
3. UAT 이슈 개발팀 전달 후 수정 확인

• UAT(User Acceptance Test) : 사용자 수용 테스트 소프트웨어 테스트의 마지막 단계로 개발된 소프트웨어가 실제 사용자가 원하는 업무를 제대로 처리할 수 있는지를 확인하는 단계

35. 배포 후 모니터링에서 QA의 역할

1. 시스템 성능 및 안정성 모니터링
2. 사용자 피드백 수집 및 분석
3. 발견된 문제를 개발팀과 공유하고 수정 확인

36. 릴리스 품질 검토에서 QA의 체크포인트

37. 안정적인 배포를 위한 QA 활동

1. 테스트 환경과 운영 환경 간 일관성 보장
2. 배포 중 발생 가능한 리스크 예측 및 대응 계획 수립 .3. 배포 후 초기 단계에서의 지속적 지원 제공

38. 유지보수 단계에서 QA의 주요 역할

1. QA의 역할 : 신규 결함 발견 및 분석
2. 운영 환경에서의 문제 해결, 수정된 기능 검증

39. 소프트웨어 업데이트 검증에서 QA의 역할

QA의 역할

• 회귀 테스트 : 기존 기능 정상 동작 확인
• 새로운 요구사항 테스트
• 업데이트 시뮬레이션 후 결과 분석

table 태그를 이용 tr -> 행을 나타내는 요소 th -> 헤더 셀을 나타냄, 굵은 글씨로 표시 td -> 데이터 셀을 나타냄

2. Form 양식

사용자로부터 입력을 받을 수 있는 HTML 양식 form -> 요소들을 감싸며 HTML의 fORM 양식을 정의

3. form 태그의 속성

1. method : 사용자가 입력한 내용들을 서버 쪽으로 어떻게 넘겨줄 지 지정(get, post) 존재
2. name : 폼의 이름을 지정
3. action : 데이터를 전송한 url이나 서버쪽의 script 파일명, 보통 서버의 프로그램과 연결되는주소

4. 폼 요소

1. label: 폼 요소에 레이블을 붙이기 위한 태그
2. input : 다양한 입력을 받고 type 속성을 통해 입력 필드의 종류 지정 가능
3. textarea : 여러줄의 텍스트를 입력할 수 있는 입력 필드

5. label 태그

6. input 태그

7. input의 type 속성

8. textarea 태그

1. 여러 줄의 텍스트를 입력할 수 있는 요소
2. cols, rows 속성 : textarea의 행과 열 개수를 지정하여 기본 사이즈 조정
3. placeholder, name 속성 : input과 동일

9. 폼 요소의 활용 예시

10. Semantic 태그의 활용

사용한 모습

사용하지 않은 모습 형태의 차이가 확연하게 다름

11. Semantic 태그

1. div 태그와 동일한 컨테이너 태그
2. 단순하게 구획만 나누는 div와 다르게 해당 요소의 역할과 의미를 예측 가능함
3. 태그만 보고 역할이나 위치 파악 가능

12. Semantic 태그의 종류

>직접 실습한 모습

좌 : div를 활용한 실습 우 : Semantic 태그를 사용해 한눈에 봐도 역할 파악이 가능하게 만듬