목차
2. 사용 사례의 적용 범위를 개선하고 테스트 누락을 줄이는 방법
3. 브라우저에 URL을 입력한 후 요청 프로세스는 어떻게 되나요?
4. 몇 가지 일반적인 HTTP 요청 헤더 필드에 대해 이야기해 보겠습니다.
8. 프로젝트 테스트 중에 어떤 유형의 버그를 발견했습니까? 버그가 발생할 가능성이 가장 높은 곳은 어디입니까?
9. 피들러는 어떻게 작동하나요? 프로젝트 테스트 중에 주로 어떤 시나리오에서 사용됩니까?
11. Xiao Ming이 Douyin을 탐색하는 동안 댓글을 게시했지만 APP 인터페이스에 표시되지 않습니다. 이 문제를 해결하는 방법은 무엇입니까?
1. 인터페이스를 디버깅할 수 없는 경우 원인을 해결하는 방법은 무엇입니까?
2. 온라인 접속 후 버그가 발생하면 어떻게 해야 하나요?
3. 테스트 누락으로 인해 온라인 버그를 경험한 적이 있습니까? 어떤 상황에서 테스트를 놓친 경우가 발생합니까?
4. 프로젝트를 단독으로 담당하는 경우 주의해야 할 사항은 무엇입니까?
5. 직장에서 개발자들과 효과적인 커뮤니케이션을 유지하는 방법은 무엇입니까?
1. 모든 사람이 읽고 쓸 수 있도록 /home/demo.txt 파일을 설정합니다.
2. a.log 파일에서 Exception과 다음 10줄이 포함된 로그를 검색합니다.
3. mysql 프로세스가 성공적으로 시작되었는지 확인
4. /home 디렉터리에서 mysql.log의 저장 디렉터리를 검색합니다.
5. Linux 서버에는 사용자의 접속 로그를 기록하는 a.log 파일이 있습니다.
하나의 이름을 사용하여 액세스 빈도가 가장 높은 상위 3명의 사용자를 계산합니다.
6. 포트 3306이 사용 중인지 확인하는 방법은 무엇입니까?
7. a.log에서 사용자 zhangsan의 어제 작업 로그를 보는 방법
1. 부서 번호와 부서 내 총 인원이 4명 이상인 사람의 수를 나열하세요.
2. 개발 부서와 테스트 부서의 직원 번호와 이름을 나열합니다.
3. 급여가 가장 높은 상위 3명의 사원의 사원번호와 이름을 출력하시오.
4. 급여가 1000-2000 사이인 모든 직원의 이름을 나열하십시오.
5. T 테이블에 다음과 같은 데이터가 있는데, 테이블에서 이름이 중복되는 데이터를 삭제하는 SQL을 작성하세요.
1. 일반적으로 사용되는 인터페이스 자동화 도구/프레임워크에 대해 이야기
4. 요소를 배치할 수 없는 경우 일반적으로 어떤 이유를 고려하시나요?
2. TPS가 상대적으로 낮은데, 그 이유는 무엇일까요?
4. 압력 테스트 중에 TPS를 누를 수 없는 경우 가능한 이유는 무엇입니까?
6. 애플리케이션 서버의 높은 CPU와 데이터베이스 서버의 높은 CPU에 대한 분석 아이디어는 무엇입니까?
1. 인터페이스 테스트를 수행해야 하는 이유는 무엇입니까?
4. 인터페이스 테스트와 웹 페이지 테스트의 차이점은 무엇입니까?
테스트 기본사항
1. 요구사항 문서 없이 테스트를 수행하는 방법
1. 요구사항 문서가 없다고 해서 요구사항이 없다는 의미는 아닙니다.
2. 제품 관리자, 개발자 등 요구 사항을 얻기 위해 관련 담당자와 통신할 수 있습니다.
3. 동종 업계의 경쟁 제품을 참고하여 귀하의 요구 사항을 요약하고 정리할 수 있습니다.
4. 일부 기능 요구 사항은 사용자의 사용 습관 및 일부 산업 사양을 기반으로 요약될 수 있습니다.
2. 사용 사례의 적용 범위를 개선하고 테스트 누락을 줄이는 방법
1. 각 요구사항이 해당 사용 사례에 포함되도록 요구 사항 문서를 기반으로 사용 사례를 작성합니다.
2. 비즈니스를 완전히 이해하고, 숨겨진 요구 사항을 발견하고, 해당 사용 사례를 작성합니다.
3. 정상적인 비즈니스 시나리오 외에도 더 많은 비정상적인 시나리오와 데이터를 고려하십시오.
4. 기능, 성능, 보안 및 기타 측면을 고려하여 다양한 차원에서 소프트웨어를 테스트합니다.
5. 사용자 관점에서 더 많이 생각하고 사용자의 사용 시나리오를 시뮬레이션하십시오.
6. 사용 사례 검토 구성
3. 브라우저에 URL을 입력한 후 요청 프로세스는 어떻게 되나요?
1. DNS 도메인 이름 확인
2. 서버와의 TCP 연결 설정
3. HTTP 요청 시작 및 데이터 전송
4. 서버는 HTTP 요청에 응답하고 데이터를 반환합니다.
5. 브라우저는 데이터를 구문 분석하고 렌더링합니다.
6. 연결을 닫습니다
4. 몇 가지 일반적인 HTTP 요청 헤더 필드에 대해 이야기해 보겠습니다.
5. 테스트 케이스에는 어떤 요소가 포함되나요?
유스케이스 번호, 그것이 속한 모듈, 유스케이스 제목, 전제 조건, 작업 단계, 우선순위, 예상 결과 등
6. 버그의 수명주기는 어떻게 되나요?
1.New: 새로운 버그를 제출하고 수정을 위해 개발자에게 할당합니다.
2.Open : 버그를 확인하고 수정이 필요하다고 생각하여 해당 개발자에게 할당합니다.
3.Fixed: 개발자가 수정한 후 고정된 상태로 표시되며, 테스터의 회귀 테스트를 통해 검증해야 합니다.
4.거부됨: 버그로 간주되지 않는 경우 수정이 거부됩니다.
5.Closed: 테스터의 회귀 테스트를 통해 버그 수정 상태가 확인되면 해당 버그가 종료됩니다.
6.Reopen: 확인된 버그가 여전히 존재하는 경우 해당 버그를 다시 열어야 하며 개발자는 이를 다시 수정할 수 있습니다
.
7. 프로젝트 테스트 프로세스를 기록해 보세요.
요구사항 검토, 테스트 계획, 기술 검토, 사용 사례 작성, 사용 사례 검토, 테스트 실행, 테스트 보고서, 온라인 검증
인증서, 프로젝트 요약
8. 프로젝트 테스트 중에 어떤 유형의 버그를 발견했습니까? 버그가 발생할 가능성이 가장 높은 곳은 어디입니까?
버그 유형: 주로 코드 논리 오류 및 구성 오류
버그가 발생하기 쉬운 곳 : 매개변수 검증, 경계조건, 복잡한 로직, 일부 비정상 시나리오 등은 고려하지 않음
포괄적인
9. 피들러는 어떻게 작동하나요? 프로젝트 테스트 중에 주로 어떤 시나리오에서 사용됩니까?
작동 원리: fiddler는 주로 클라이언트와 서버 간의 프록시 역할을 합니다. fiddler를 시작한 후,
모든 요청과 응답은 피들러를 통해 진행됩니다.
애플리케이션 시나리오:
1> 프런트엔드 및 백엔드 버그 확인
2> 데이터 분석을 위한 패킷 캡처
3> 주로 서버가 클라이언트가 제출한 불법 데이터(예: 구매한 티켓 수)를 확인하는지 여부를 테스트하기 위해 중단점을 요청합니다.
금액은 0, 무효 활동 시간 등입니다.
4> 중단점에 응답하고,
요청 중단점: 클라이언트가 제출한 불법 데이터를 서버가 검증하는지 여부를 테스트하는 데 주로 사용됩니다.예를 들어 구매한 티켓 수는
0, 유효하지 않은 활동 시간 등
응답 중단점: 서버가 비정상적인 데이터를 반환한 후 주로 클라이언트의 처리 방법을 테스트합니다(예: 서버가 500을 반환함).
아니면 다른 비정상적인 비즈니스 데이터
5> 약한 네트워크 테스트의 경우 fiddler에 내장된 네트워크 지연 시간을 수정할 수 있습니다. 기본값은 업로드의 경우 300ms, 다운로드의 경우 150ms입니다.
이 두 값이 클수록 네트워크 속도는 낮아집니다.
10. 앱의 오류 로그를 보는 방법은 무엇입니까?
a. 앱 패키지 이름을 확인하세요.
b.등록을 통해 APP 프로세스 번호를 확인하세요.
c. 프로세스 번호를 기준으로 adb logcat의 오류 로그를 필터링합니다.
11. Xiao Ming이 Douyin을 탐색하는 동안 댓글을 게시했지만 APP 인터페이스에 표시되지 않습니다. 이 문제를 해결하는 방법은 무엇입니까?
1. 클라이언트 네트워크에 문제가 있는지 확인하고, 다른 앱도 정상적으로 사용 가능한지 확인할 수 있습니다.
2. 버전 문제인지 확인하세요 운영체제(안드로이드, iOS)를 바꾸시거나 다른 소프트웨어 버전을 사용해 보세요.
3. 호환성 문제인지 확인하시고, 다른 휴대폰으로 시도해 보시기 바랍니다.
4. 패킷 캡처 분석: 앱이 서버에 요청을 보내지 않거나 요청 매개변수가 올바른 경우 앱에 문제가 있는 것입니다.
질문: 서버 응답 데이터가 올바르지 않으면 서버 측의 문제입니다.
시나리오 질문
1. 인터페이스를 디버깅할 수 없는 경우 원인을 해결하는 방법은 무엇입니까?
요청이 실패했습니다. 가능한 이유는 다음과 같습니다.
- IP, 포트 번호, URL이 잘못되었습니다.
- 클라이언트와 서버 사이의 네트워크가 연결되어 있지 않습니다
- 서버 측 프로젝트가 전혀 배포되지 않았습니다.
- 서버의 방화벽이 이를 차단했습니다.
- 서버 프로그램 내에서 오류가 발생했습니다.
- 접근 권한이 없습니다. (토큰, 쿠키 부족 등)
- 클라이언트에 네트워크 프록시가 설정되어 있습니다.
- 브라우저를 통해 접속하면 잘못 바인딩된 걸까요?
2. 온라인 접속 후 버그가 발생하면 어떻게 해야 하나요?
이전 경험을 바탕으로 우리는 먼저 개발팀과 협력하여 버그의 심각도와 원인을 초기에 평가합니다.
상대적으로 영향이 큰 기능적 문제가 있어 당분간 구체적인 원인을 찾기 어려운 경우 가장 먼저 고려해야 할 사항은 코드 복구를 수행하는 것입니다.
롤링하고 마지막 안정 버전으로 되돌립니다. 그런 다음 테스트 환경에서 다시 테스트하고 문제의 원인을 찾으십시오.
문제의 원인을 신속하게 찾아낼 수 있는 경우, 개발팀에서 긴급 복구 작업을 진행하고, 테스트를 통과한 후 온라인으로 긴급 신청을 하게 됩니다.
성능 문제인 경우 일반적으로 확장하거나 다시 시작하여 문제를 해결한 다음 개발팀에서 추가 문제 확인을 수행합니다.
비트합 최적화.
문제가 심각하지 않다면 대개 다음 버전에서 해결될 것입니다.
마지막으로, 온라인 버그가 해결된 후에는 문제 검토가 수행되어야 하며, 전체 프로세스가 기록되고 향후 방지를 위해 관련 분석 및 요약이 수행됩니다.
비슷한 문제가 계속해서 발생합니다.
3. 테스트를 놓쳐서 온라인 버그를 경험한 적이 있습니까 ? 어떤 상황에서 누출이 감지됩니까?
기본적으로 내 테스트에서는 P0 및 P1 수준 BUG가 없었습니다.
가끔 작은 문제가 있는 경우가 있는데, 주된 이유는 다음과 같습니다.
왜냐하면 그것은 호환성에 관한 것이기 때문입니다. 특히 안드로이드폰은 너무 파편화되어 있다.
그런 다음 주로 테스트 버그가 누락되는 일반적인 이유에 대해 이야기하겠습니다
.
⚫불분명한
요구 사항 사양으로 인해 테스트 사례를 너무 거칠게 작성하게 됩니다.
⚫
요구사항 사양이 변경되고 테스트 사례가 제때 업데이트되지 않았습니다.
⚫테스트
사례 적용 범위가 포괄적이지 않으며 시나리오가 생략되었습니다.
⚫
테스트 과정에서 테스트 케이스를 엄격하게 따르지 않는 경우
⚫
테스트 시간이 부족하여 테스트 과정에서 일부 기능 포인트가 무시되었습니다.
⚫
테스트 환경이나 테스트 데이터가 제한되어 있어 결함 누락이 발생함
⚫
개발자가 다른 버그를 수정할 때 도입되는 새로운 버그
4. 프로젝트를 단독으로 담당하는 경우 주의해야 할 사항은 무엇입니까 ?
1. 프로젝트의 테스트 범위와 테스트 주기를 평가하고 단독으로 완료할 수 있는지 여부를 평가합니다.
2. 좋은 테스트 전략과 계획을 세우고 각 링크가 제 시간에 완료되도록 노력하십시오.
3. 스스로 문제를 해결할 수 없다면 즉시 버리고, 위험을 노출하고 도움을 구해야 합니다.
4. 테스트 효율성을 높이기 위해 기술적 수단을 사용해 보십시오.
5. 사용 사례의 우선순위를 설정하고 우선순위에 따라 실행합니다.
6. 적시에 버그를 추적하고 개발을 촉진하여 가능한 한 빨리 버그를 해결합니다.
7. 발사 표준을 관리하고 테스트 보고서에 발사 위험을 표시합니다.
5. 직장에서 개발자들과 효과적인 커뮤니케이션을 유지하는 방법은 무엇입니까 ?
1. 있는 그대로 논의하고, 개발자와 소통할 때 감정을 담지 않으며, 객관적이고 진실되게 소통한다.
2. 개발에 너무 의존하지 말고, 문제가 생기면 먼저 분석해보고, 기본적인 판단을 한 뒤 개발에 들어갑니다.
3. 현재 무엇을 하고 있는지, 어떤 문제가 발생했는지, 어떤 개발이 필요한지 등 문제를 간결하고 명확하게 설명하세요.
돕다
4. 시험은 그 나름의 원칙과 관점이 있어야 하고, 자신이 옳다고 생각하는 것이 옳다고 생각하는 것이 있어야 하며, 굳건히 서서 스스로 판단해야 합니다.
Quan Tingxin 개발
5. 개발 작업이 자주 중단될 수 있는 단편적인 커뮤니케이션을 피하기 위해 가능한 한 중앙 집중식으로 문제를 커뮤니케이션합니다.
6. 기술적 능력과 인지력을 향상시키고, 보다 전문적인 언어를 사용하여 개발팀과 소통합니다.
7. 의사소통이 매우 어려운 개발 상황에 직면했을 때, 필요한 경우 적시에 피드백하고 도움을 구합니다.
리눅스
1. 모든 사람이 읽고 쓸 수 있도록 /home/demo.txt 파일을 설정합니다.
chmod 666 /home/demo.txt
2. a.log 파일에서 Exception과 다음 10줄이 포함된 로그를 검색합니다.
grep -A 10 "예외" a.log
3. mysql 프로세스가 성공적으로 시작되었는지 확인
ps -ef | grep mysql
4. /home 디렉터리에서 mysql.log의 저장 디렉터리를 검색합니다.
/home -name mysql.log 찾기
5. Linux 서버에는 사용자의 접속 로그를 기록하는 a.log 파일이 있습니다.
하나의 이름을 사용하여 액세스 빈도가 가장 높은 상위 3명의 사용자를 계산합니다.
2022-07-04 11:11:11 장산 /index.html 192.168.2.2
2022-07-04 12:11:12 lisi /로그인 192.168.2.2
2022-07-05 16:11:13 장산/상점/구매 192.168.2.2
2022-07-06 09:11:18 잭 /카트/고 192.168.2.2
答案：awk '{print $3}' a.log | 정렬 | 유니크 -c | 정렬 -rn | 머리 -3
6. 포트 3306이 사용 중인지 확인하는 방법은 무엇입니까?
netstat -anp | 그립 3306
또는
lsof -i 3306
7. a.log에서 사용자 zhangsan의 어제 작업 로그를 보는 방법
grep 'zhangsan' a.log | grep '어제 날짜'
8. 방화벽을 끄는 명령은 무엇입니까?
systemctl 방화벽 중지
9. a.log에 얼마나 많은 예외가 있는지 계산하는 방법
grep '예외' a.log | 화장실 -l
10. 일반적으로 사용되는 Linux 명령
pwd는 작업 경로를 보여줍니다.
shutdown -h now 시스템 종료 /halt 시스템 종료
shutdown -r 지금 다시 시작/재부팅 다시 시작
systemctl stop Firewalld 방화벽을 닫습니다.
IP 주소 IP 주소 보기
SQL 질문
부서 테이블 부서(dept_id, dept_name)
직원 테이블 직원(emp_id, emp_name, sex, dept_id, jobs)
급여 테이블 급여(salary_id, emp_id, Money)
1. 총 인원수가 4명 이상인 부서 번호 와 해당 부서의 인원수를 나열하세요.
직원에서 dept_id, count(*)를 선택합니다. e 그룹은 count(*)>4인 dept_id별로 그룹화됩니다.
2. 개발 부서와 테스트 부서의 직원 번호와 이름을 나열합니다.
e.emp_id,d.emp_name을 선택하세요.
직원 e 내부 조인 부서 d on e.dept_id = d.dept_id
여기서 ('개발 부서', '테스트 부서')의 d.dept_name
3. 급여가 가장 높은 상위 3명의 사원 의 사원번호와 이름을 출력하시오 .
e.emp_id, e.emp_name,s.money를 선택하세요.
s.emp_id = e.emp_id의 급여 s 내부 조인 직원 e에서
s.money로 주문
제한 3
4. 급여가
e.empname,s.salary를 선택하세요.
급여에서
내부 조인 직원 e on s.empid = e.empid
여기서 s.salary는 1000에서 2000 사이입니다.
5. T 테이블에는 다음과 같은 데이터가 있는데, 테이블에서 이름이 중복되는 데이터를 삭제하는 SQL을 작성하세요.
| 아이디 | 이름 | 나이 | 도시 |
1, 장산, 18, 베이징
2, Li Si, 35, 상하이
3, Zhang San, 20, 난징
4, 왕 우, 31, 천진
答案: ID가 없는 T에서 삭제(T 그룹에서 이름으로 max(id) 선택)
오토메이션
1. 일반적으로 사용되는 인터페이스 자동화 도구/프레임워크에 대해 이야기해 보겠습니다.
Jmeter, 우편 배달부
요청、pytest、unitest、HTTPClient、testNG、Junit
2. 자동화된 스크립트의 안정성을 향상시키는 방법
a. 고정된 데이터의 사용을 피하세요. 테스트 케이스에 사용된 오래된 테스트 데이터는 타인에 의해 수정되거나 삭제될 수 있습니다.
따라서 스크립트를 실행하기 전에 매번 스크립트에 새로운 데이터가 생성되고, 스크립트를 실행한 후에는 데이터가 지워집니다.
b. 사용 사례 간의 결합을 줄입니다. 각 사용 사례에 대해 완전한 프로세스를 따르도록 노력하세요. 피하기 위해 다른 사용 사례에 의존하지 마세요.
이렇게 하면 다른 사용 사례가 실패하고 후속 사용 사례에 영향을 미치는 것을 방지할 수 있습니다.
c. 종속 환경의 안정성을 향상합니다. 일반적으로 일부 사용 사례는 타사 시스템의 환경에 의존합니다. 타사 환경이
불안정성은 사용 사례 실행의 불안정성을 초래합니다. 모의를 사용하여 타사 환경을 보호하고 개선할 수 있습니다.
환경 안정성을 향상시킵니다.
d. 스크립트의 예외 처리를 위해 스크립트에서 더 많은 가능한 예외를 고려하고 각 예외에 대해 해당 응답을 갖도록 노력합니다.
실패 후 프로그램 종료를 방지하기 위한 처리 방법
3. pytest에서 케이스를 조립하는 방법
1) 기본적으로 test_ .py 또는 **test.py라는 파일명이 체크되어 있으며, 파일 내에서 test로 시작하는 파일명이 검색됩니다.
메소드 또는 함수 및 실행
2) 사용자 정의 마커(데코레이터)를 사용할 수 있습니다. 예를 들어 pytest가 실행 중일 때 이 마커로만 마커를 실행합니다.
테스트 케이스
3) pytest.ini 구성 파일에서는 특정 타겟을 실행하는 등 pytest가 실행되는 경우를 처리할 수 있습니다.
사용 사례 기록, 스크립트 파일 실행 등
4. 요소를 배치할 수 없는 경우 일반적으로 어떤 이유를 고려하시나요?
1) 잘못된 로케이터 선택
2) 포지셔닝 문자열 오류
3) 요소는 프레임에 중첩됩니다.
4) 페이지 요소가 제 시간에 로드되지 않습니다.
5) 새 창의 요소
6) 스크립트 프로세스가 실제 상황과 일치하지 않습니다.
7) 해당 요소가 현재 페이지에 없습니다.
성능
1. 성능 테스트의 공통 지표는 무엇입니까?
a) tps: 초당 트랜잭션 수로 시스템의 처리 능력을 나타내며, tps가 높을수록 성능이 좋습니다.
b) 응답 시간: 요청을 보내고 시스템 응답 데이터를 수신하는 데 걸리는 시간으로, 응답 시간이 짧을수록 성능이 좋아집니다.
더 나은
c) 처리량: 네트워크의 업스트림 및 다운스트림 트래픽의 합 처리량은 네트워크 병목 현상을 찾는 데 중요한 지표입니다.
d) 오류율: 스트레스 테스트 과정 중 시스템 오류가 발생한 비율
e) 운영 체제: CPU, 메모리, 네트워크, 디스크
2. TPS가 상대적으로 낮은데, 그 이유는 무엇일까요?
a) 언론 자체의 성과 병목 현상
b) 네트워크 IO 병목 현상
c) 미들웨어(tomcat/nginx/mysql) 연결 제한
b) 응용 프로그램: 메모리, 스레드 차단, 대기
e) 데이터베이스 성능 문제
f) 이 시스템 리소스(CPU, 메모리, 디스크, 네트워크 등)의 병목 현상
g) 다른 외부 시스템의 응답 시간이 너무 길어서 이 시스템이 대기하는 시간이 발생합니다.
3. 자동화된 테스트의 안정성을 확보하는 방법
1. 고정된 데이터의 사용을 피하세요 테스트 케이스에 사용된 오래된 테스트 데이터는 타인에 의해 수정되거나 삭제될 수 있습니다. 그래서
각 스크립트가 실행되기 전에 스크립트에 새 데이터가 구성되고, 스크립트가 완료된 후에는 데이터가 지워집니다.
2. 유스케이스 간의 결합을 줄입니다. 각 유스케이스에 대한 완전한 프로세스를 따르도록 노력하고 이를 피하기 위해 다른 유스케이스에 의존하지 마십시오.
다른 사용 사례의 실행이 실패하여 후속 사용 사례에 영향을 미쳤습니다.
3. 종속 환경의 안정성을 향상합니다. 일반적으로 일부 사용 사례는 타사 시스템의 환경에 의존합니다. 타사 환경이 불안정한 경우
판단되면 유스케이스 실행이 불안정해질 수 있다. 모의 객체를 사용하여 타사 환경을 보호하고 환경 안정성을 향상할 수 있습니다.
질적.
4. 스크립트에서 예외를 처리하려면 스크립트에서 가능한 더 많은 예외를 고려하고 그에 따라 각 예외를 처리해 보십시오.
실패 후 프로그램이 종료되는 것을 방지하는 방법
4. 압력 테스트 중에 TPS를 누를 수 없는 경우 가능한 이유는 무엇입니까?
a) 프레스 자체의 성능 병목 현상
b) 네트워크 IO 병목 현상
c) 미들웨어(tomcat/nginx/mysql) 연결 제한
b) 스레드 차단 및 대기
e) 데이터베이스 성능 문제
f) 시스템 리소스(CPU, 메모리, 디스크, 네트워크 등)의 병목 현상
g) 다른 외부 시스템의 응답 시간이 너무 길어서 이 시스템이 대기하는 시간이 발생합니다.
5. 성능 테스트 시나리오 설계 방법
일반적인 기본 시나리오에는 벤치마크 테스트, 단일 트랜잭션 테스트, 혼합 테스트 및 안정성 테스트가 포함됩니다.
벤치마크 테스트는 사용자 1명 또는 벤치마크 사용자 수를 기준으로
단일 시나리오 테스트를 몇 분간 실행하고, 동시 사용자 수가 점차 예상값까지 늘어나면 10분간 실행한다.
혼합 시나리오 테스트는 다양한 트랜잭션 설정과 다양한 동시 사용자 비율을 사용하여 30분 동안 실행됩니다.
안정성 테스트, 최대 동시 사용자 수의 80%를 지원하는 혼합 테스트 선택, 12시간 동안 실행
6. 애플리케이션 서버의 높은 CPU와 데이터베이스 서버의 높은 CPU에 대한 분석 아이디어는 무엇입니까?
1) 응용서버의 CPU가 높다면 먼저 TPS와 응답시간을 확인하고, 상대적으로 TPS가 높으면 정상적인 CPU라고 생각합니다.
소비: tps가 상대적으로 낮으면 일부 코드는 CPU를 너무 많이 소비하는 경우가 많습니다. 코드 분석 도구 사용을 고려해 볼 수 있습니다.
분석하다
2) 데이터베이스 서버 CPU가 높습니다. SQL 문 실행 효율성이 상대적으로 낮기 때문인 경우가 많습니다. 이는 데이터베이스 쿼리를 느리게 하면 달성할 수 있습니다.
실행 계획과 결합하여 해당 테이블에 인덱스가 없거나 인덱스가 적용되지 않았는지 분석하는 모니터링입니다.
상호 작용
1. 인터페이스 테스트를 하는 이유
A. 회사에서는 일반적으로 클라이언트와 서버를 서로 다른 팀에서 개발하는데, 프로젝트 개발 과정에서 클라이언트는
서버측과 서버측의 개발 진행이 일치하지 않는 경우, 예를 들어 서버측이 먼저 개발되는데 이때 서버측이 먼저 개발될 수 있습니다.
서버측 로직과 반환 데이터가 올바른지 확인하기 위한 인터페이스 테스트 후 클라이언트를 테스트합니다. 또한 일부 테스트 부서
팀은 서버측 개발팀 테스트를 전문으로 하므로 테스트 대상은 인터페이스입니다.
B. 특정 서비스를 테스트할 때 사용자 등록 등 프런트 엔드를 통해서만 테스트할 수는 없으며 프런트 엔드에서는 사용자 이름을 제한합니다.
비워둘 수는 없지만 도구를 사용하여 프런트엔드를 우회하고 서버 인터페이스를 직접 호출하는 경우도 있습니다.
관련된 논리적 판단으로 인해 데이터 오류가 발생합니다. 인터페이스 데이터 전송 시 주요 정보의 암호화 여부를 포함합니다.
따라서 서버 인터페이스를 별도로 테스트해야 합니다.
씨,
개발 및 테스트 후 먼저 도구를 통해 서버 측 인터페이스 테스트를 실행하여 인터페이스 테스트 사례가 모두 있는지 확인할 수 있습니다.
통과하면 서버 인터페이스가 기대치를 충족하는지 빠르게 확인할 수 있습니다. 그런 다음 UI 인터페이스를 통해 테스트합니다. 그렇지 않으면 수락
프런트 엔드 페이지에 버그가 있으면 프런트 엔드 페이지에도 버그가 있어야 합니다.
2. 인터페이스 테스트의 초점은 무엇입니까?
1) 매개변수 적법성, 매개변수 검증, 매개변수 경계, 빈 매개변수, 누락된 매개변수 등을 포함한 입력 매개변수
2) 다양한 상황에서 응답 내용이 정상인지 여부를 포함한 반환 값
3) 인터페이스 업무 로직 및 기능의 정상 여부
4) 데이터베이스 검증
5) 성능 테스트(인터페이스 tps, 응답 시간 등)
6) 보안, 민감정보의 암호화, 권한 통제 등
7) 멱등성
3. 받기와 게시의 차이점은 무엇인가요?
1) get 요청의 매개변수는 url에 있고 post 요청의 매개변수는 요청 본문에 있습니다
2) get 요청은 브라우저에 의해 캐시될 수 있지만 post 요청은 캐시될 수 없습니다.
3) get 요청 매개변수는 URL에 위치하며, URL의 길이는 제한되어 있지만 게시 인터페이스의 길이는 제한되지 않습니다.
4) get 요청 매개변수는 덜 안전한 URL에 배치되고, post 요청 매개변수는 덜 안전한 본문에 배치됩니다.
더 나은
5) get 요청은 브라우저를 통해 직접 액세스할 수 있으며 새로 고침 및 되돌리기를 지원합니다. 게시물 요청은 직접 탐색을 사용할 수 없습니다.
서버에 접속한 후 데이터를 새로고침한 후 다시 전송해야 합니다.
4. 인터페이스 테스트와 웹 페이지 테스트의 차이점은 무엇입니까?
1) 웹 페이지 테스트는 인터페이스 작업을 통해 수행되며, 다양한 데이터를 입력하여 다양한 시나리오를 테스트합니다.
2) 인터페이스 테스트는 도구를 사용하여 테스트를 위해 HTTP 요청을 서버에 직접 보내고, 다양한 매개변수를 입력하여 다양한 테스트를 수행하는 것입니다.
장면.
3) 일반적으로 웹페이지는 필수 필드, 데이터 형식 등과 같은 특정 입력 데이터를 제한합니다. 인터페이스 테스트 가능
데이터를 입력하면 더 많은 비정상적인 데이터 시나리오를 테스트할 수 있습니다.
4) 웹 테스트는 브라우저 호환성을 고려해야 하지만 인터페이스 테스트는 그렇지 않습니다.
5) 웹 테스트는 프론트엔드와 서버의 개발이 완료되어야 테스트가 진행되며, 인터페이스 테스트는 서버만 시작하면 됩니다.
릴리스가 완료되면 테스트를 시작할 수 있습니다.