메뉴

소프트웨어 테스팅이란? 100 개 이상의 무료 수동 테스트 자습서

what is software testing

문제를 제거하기 위해 도구를 사용해보십시오

테스트 정의, 유형, 방법 및 프로세스 세부 정보가 포함 된 100 개 이상의 수동 테스트 자습서가 포함 된 완전한 소프트웨어 테스트 가이드 :

소프트웨어 테스팅이란 무엇입니까?

소프트웨어 테스트는 지정된 요구 사항을 충족하는지 확인하기 위해 응용 프로그램의 기능을 확인하고 유효성을 검사하는 프로세스입니다. 애플리케이션의 결함을 찾고 최종 사용자의 요구 사항에 따라 애플리케이션이 작동하는 위치를 확인하는 프로세스입니다.

수동 테스트 란 무엇입니까?

수동 테스트는 개발 된 코드 (소프트웨어, 모듈, API, 기능 등)의 동작을 예상 동작 (요구 사항)과 비교하는 프로세스입니다.

학습 내용 :

수동 소프트웨어 테스트 자습서 목록

이것은 소프트웨어 테스팅에 대한 가장 심층적 인 튜토리얼 시리즈입니다. 이 시리즈에서 언급 한 주제를주의 깊게 살펴보고 기본 및 고급 테스트 기술을 배우십시오.

이 일련의 자습서는 지식을 풍부하게하고 테스트 기술을 향상시킬 것입니다.

라이브 프로젝트에 대한 종단 간 수동 테스트 무료 교육 연습 :

튜토리얼 # 1 : 수동 소프트웨어 테스트의 기초
튜토리얼 # 2 : 라이브 프로젝트 소개
튜토리얼 # 3 : 테스트 시나리오 작성
튜토리얼 # 4 : 처음부터 테스트 계획 문서 작성
튜토리얼 # 5 : SRS 문서에서 테스트 케이스 작성
튜토리얼 # 6 : 테스트 실행
튜토리얼 # 7 : 버그 추적 및 테스트 사인 오프
튜토리얼 # 8 : 소프트웨어 테스팅 코스

소프트웨어 테스팅 수명주기 :

튜토리얼 # 1 : STLC

웹 테스트 :

튜토리얼 # 1 : 웹 애플리케이션 테스트
튜토리얼 # 2 : 크로스 브라우저 테스트

테스트 케이스 관리 :

병합 정렬 구현 C ++

튜토리얼 # 1 : 테스트 케이스
튜토리얼 # 2 : 샘플 테스트 케이스 템플릿
튜토리얼 # 3 : 요구 사항 추적 성 매트릭스 (RTM)
튜토리얼 # 4 : 테스트 범위
튜토리얼 # 5 : 테스트 데이터 관리

테스트 관리 :

튜토리얼 # 1 : 테스트 전략
튜토리얼 # 2 : 테스트 계획 템플릿
튜토리얼 # 3 : 테스트 추정
튜토리얼 # 4 : 테스트 관리 도구
튜토리얼 # 5 : HP ALM 자습서
튜토리얼 # 6 : Jira
튜토리얼 # 7 : TestLink 튜토리얼

기술 테스트 :

튜토리얼 # 1 : 사용 사례 테스트
튜토리얼 # 2 : 상태 전이 테스트
튜토리얼 # 3 : 경계 값 분석
튜토리얼 # 4 : 등가 분할
튜토리얼 # 5 : 소프트웨어 테스트 방법론
튜토리얼 # 6 : 애자일 방법론

결함 관리 :

튜토리얼 # 1 : 버그 수명주기
튜토리얼 # 2 : 버그보고
튜토리얼 # 3 : 결함 우선 순위
튜토리얼 # 4 : Bugzilla 튜토리얼

기능 테스트

튜토리얼 # 1 : 단위 테스트
튜토리얼 # 2 : 위생 및 연기 테스트
튜토리얼 # 3 : 회귀 테스트
튜토리얼 # 4 : 시스템 테스트
튜토리얼 # 5 : 수락 테스트
튜토리얼 # 6 : 통합 테스트
튜토리얼 # 7 : UAT 사용자 수락 테스트

비 기능 테스트 :

튜토리얼 # 1 : 비 기능 테스트
튜토리얼 # 2 : 성능 시험
튜토리얼 # 3 : 보안 테스트
튜토리얼 # 4 : 웹 애플리케이션 보안 테스트
튜토리얼 # 5 : 사용성 테스트
튜토리얼 # 6 : 호환성 테스트
튜토리얼 # 7 : 설치 테스트
튜토리얼 # 8 : 문서 테스트

소프트웨어 테스트 유형 :

튜토리얼 # 1 : 테스트 유형
튜토리얼 # 2 : 블랙 박스 테스트
튜토리얼 # 3 : 데이터베이스 테스트
튜토리얼 # 4 : 종단 간 테스트
튜토리얼 # 5 : 탐색 적 테스트
튜토리얼 # 6 : 증분 테스트
튜토리얼 # 7 : 접근성 테스트
튜토리얼 # 8 : 부정적인 테스트
튜토리얼 # 9 : 백엔드 테스트
튜토리얼 # 10 : 알파 테스트
튜토리얼 # 11 : 베타 테스트
튜토리얼 # 12 : 알파 대 베타 테스트
튜토리얼 # 13 : 감마 테스트
튜토리얼 # 14 : ERP 테스트
튜토리얼 # 15 : 정적 및 동적 테스트
튜토리얼 # 16 : 임시 테스트
튜토리얼 # 17 : 현지화 및 국제화 테스트
튜토리얼 # 18 : 자동화 테스트
튜토리얼 # 19 : 화이트 박스 테스트

소프트웨어 테스팅 경력 :

튜토리얼 # 1 : 소프트웨어 테스팅 경력 선택
튜토리얼 # 2 : QA 테스트 작업을 얻는 방법 – 전체 가이드
튜토리얼 # 3 : 테스터를위한 커리어 옵션
튜토리얼 # 4 : IT가 아닌 소프트웨어 테스트 스위치
튜토리얼 # 5 : 수동 테스트 경력 시작
튜토리얼 # 6 : 10 년 간의 테스트에서 얻은 교훈
튜토리얼 # 7 : 테스트 분야에서 생존과 발전

인터뷰 준비 :

튜토리얼 # 1 : QA 이력서 준비
튜토리얼 # 2 : 수동 테스트 인터뷰 질문
튜토리얼 # 3 : 자동화 테스트 인터뷰 질문
튜토리얼 # 4 : QA 인터뷰 질문
튜토리얼 # 5 : 모든 면접 처리
튜토리얼 # 6 : 더 신선하게 테스트 작업 받기

다른 도메인 응용 프로그램 테스트 :

튜토리얼 # 1 : 은행 애플리케이션 테스트
튜토리얼 # 2 : 건강 관리 애플리케이션 테스트
튜토리얼 # 3 : 지불 게이트웨이 테스트
튜토리얼 # 4 : POS (Point of Sale) 시스템 테스트
튜토리얼 # 5 : 전자 상거래 웹 사이트 테스트

QA 인증 테스트 :

튜토리얼 # 1 : 소프트웨어 테스트 인증 가이드
튜토리얼 # 2 : CSTE 인증 가이드
튜토리얼 # 3 : CSQA 인증 가이드
튜토리얼 # 4 : ISTQB 가이드
튜토리얼 # 5 : ISTQB 고급

고급 수동 테스트 항목 :

튜토리얼 # 1 : 순환 복잡성
튜토리얼 # 2 : 마이그레이션 테스트
튜토리얼 # 3 : 클라우드 테스트
튜토리얼 # 4 : ETL 테스트
튜토리얼 # 5 : 소프트웨어 테스팅 지표
튜토리얼 # 6 : 웹 서비스

이 매뉴얼 테스트 시리즈의 첫 번째 튜토리얼을 볼 준비를하세요 !!!

수동 소프트웨어 테스트 소개

수동 테스트는 개발 된 코드 (소프트웨어, 모듈, API, 기능 등)의 동작을 예상 동작 (요구 사항)과 비교하는 프로세스입니다.

예상되는 동작이 무엇인지 어떻게 알 수 있습니까?

요구 사항을주의 깊게 읽거나 듣고 완전히 이해하면 알 수 있습니다. 요구 사항을 완전히 이해하는 것은 매우 중요합니다.

Android 용 최고의 VR 앱은 무엇인가요

테스트 할 항목의 최종 사용자라고 생각하십시오. 그 후에는 더 이상 소프트웨어 요구 사항 문서 또는 그 안에있는 단어에 구속되지 않습니다. 그런 다음 핵심 요구 사항을 이해하고 작성되거나들은 내용에 대해 시스템의 동작을 확인하는 것뿐만 아니라 자신의 이해와 작성되거나 듣지 않은 내용에 대해서도 확인합니다.

때때로 누락 된 요구 사항 (불완전한 요구 사항) 또는 암시 적 요구 사항 (별도 언급이 필요하지 않지만 충족되어야하는 것) 일 수 있으며, 이것도 테스트해야합니다.

또한 요구 사항이 반드시 문서화 될 필요는 없습니다. 소프트웨어 기능에 대해 잘 알고 있거나 한 번에 한 단계 씩 추측 한 다음 테스트 할 수도 있습니다. 일반적으로 임시 테스트 또는 탐색 테스트라고합니다.

자세히 살펴 보겠습니다.

먼저 사실을 이해합시다. 소프트웨어 애플리케이션을 비교 테스트하든 다른 것 (차량이라고 가정 해 보겠습니다)을 비교하든 개념은 동일하게 유지됩니다. 접근 방식, 도구 및 우선 순위는 다를 수 있지만 핵심 목표는 동일하며 실제 동작과 예상 동작을 비교하는 것은 간단합니다.

둘째 – 테스트는 내면에서 나와야하는 태도 나 사고 방식과 같습니다. 기술을 배울 수는 있지만 기본적으로 내면에 몇 가지 자질이있을 때만 성공적인 테스터가됩니다. 테스트 기술을 배울 수 있다고 말하는 것은 소프트웨어 테스트 프로세스에 대한 집중적이고 공식적인 교육을 의미합니다.

그러나 성공적인 테스터의 자질은 무엇입니까? 아래 링크에서 이에 대해 읽을 수 있습니다.

여기에서 읽으십시오 => 매우 효과적인 테스터의 자질

이 튜토리얼을 계속하기 전에 위의 기사를 살펴 보는 것이 좋습니다. 소프트웨어 테스터의 역할에서 예상되는 특성과 사용자의 특성을 비교하는 데 도움이됩니다.

기사를 살펴볼 시간이없는 분들을위한 시놉시스는 다음과 같습니다.

“당신의 호기심, 세심함, 규율, 논리적 사고, 일에 대한 열정 및 사물을 해부하는 능력은 파괴적이고 성공적인 테스터가되기 위해 매우 중요합니다. 그것은 나를 위해 일했고 나는 그것이 당신에게도 효과가있을 것이라고 굳게 믿습니다. 이미 이러한 자질을 가지고 있다면 실제로 당신에게도 효과가있을 것입니다.”

우리는 핵심 전제 조건에 대해 이야기했습니다. 소프트웨어 테스터가됩니다. 이제 수동 테스트가 자동화 테스트의 성장 여부와 상관없이 항상 독립적으로 존재하는 이유를 이해하겠습니다.

수동 테스트가 필요한 이유는 무엇입니까?

테스터가되는 것이 가장 좋은 것이 무엇인지, 그것도 수동 테스터가되는지 알고 있습니까?

여기서 스킬 셋에만 의존 할 수 없다는 것은 사실입니다. 사고 과정을 가지고 / 개발하고 향상시켜야합니다. 이것은 몇 달러로 살 수없는 것입니다. 당신 자신이 그것을해야합니다.

넌해야만 해 질문하는 습관을 기르다 테스트 할 때 매분마다 물어봐야합니다. 대부분의 경우 이러한 질문을 다른 사람보다 자신에게해야합니다.

이전 섹션에서 추천 한 기사 (즉, 매우 효과적인 테스터의 자질)를 살펴 보셨기를 바랍니다. 그렇다면 테스트는 사고 과정으로 간주되며 테스터로서 얼마나 성공적 일지는 사람으로서 소유 한 자질에 달려 있다는 것을 알게 될 것입니다.

이 간단한 흐름을 살펴 보겠습니다.

  • 당신은 뭔가 ( 행동을 취하다 ) 어떤 의도로 그것을 관찰하는 동안 (예상과 비교). 이제 당신의 관측 기술과 징계 작업을 수행하는 것이 여기 그림에 나와 있습니다.
  • 짜잔! 그게 뭐야? 당신은 뭔가를 발견했습니다. 당신은 완벽을 주었기 때문에 그것을 알아 차 렸습니다. 세부 사항에 대한 관심 당신의 앞에. 당신이 있기 때문에 놓지 않을 것입니다 궁금한 . 이것은 예상치 못한 / 이상한 일이 발생할 계획이 아니 었습니다. 당신은 그것을 알아 채고 더 조사 할 것입니다. 그러나 지금 당신은 그것을하고 있습니다. 놓아도됩니다. 하지만 놓아서는 안됩니다.
  • 당신은 행복하고 원인, 단계 및 시나리오를 발견했습니다. 이제이를 개발 팀과 팀의 다른 이해 관계자들에게 적절하고 건설적으로 전달할 것입니다. 결함 추적 도구를 통해 또는 구두로 수행 할 수 있지만 건설적으로 전달 .
  • 이런! 내가 그렇게하면 어떡해? 적절한 정수를 입력으로 입력하지만 선행 공백이 있으면 어떻게됩니까? 만약 그러하다면? … 만약 그러하다면? … 만약 그러하다면? 쉽게 끝나지 않고 쉽게 끝나서는 안됩니다. 당신은 상상하다 많은 상황과 시나리오가 있으며 실제로 당신은 그것들을 수행하고 싶은 유혹을 받게 될 것입니다.

아래의 다이어그램은 테스터의 수명을 나타냅니다.

테스터의 삶

위에서 언급 한 4 개의 글 머리 기호를 다시 한 번 읽으십시오. 내가 매우 짧게 유지했지만 여전히 수동 테스터의 가장 풍부한 부분을 강조했다는 것을 알고 계셨습니까? 그리고 몇 마디에 걸쳐 굵은 강조 표시를 보셨나요? 이것이 바로 수동 테스터에게 필요한 가장 중요한 특성입니다.

자, 정말로 이러한 행위가 다른 것으로 완전히 대체 될 수 있다고 생각하십니까? 그리고 오늘날의 핫 트렌드 – 자동화로 대체 될 수 있습니까?

SDLC에서 어떤 개발 방법으로도 항상 일정하게 유지되는 것은 거의 없습니다. 테스터는 요구 사항을 사용하여 테스트 시나리오 / 테스트 사례로 변환합니다. 그런 다음 이러한 테스트 사례를 실행하거나 직접 자동화합니다 (몇몇 회사에서 수행하는 것을 알고 있습니다).

당신이 그것을 자동화 할 때, 당신의 초점은 일정하게 유지되며, 이는 기록 된 단계를 자동화합니다.

수동으로 작성된 테스트 케이스를 실행하는 공식적인 부분으로 돌아가 보겠습니다.

여기서는 작성된 테스트 케이스를 실행하는 데 집중할뿐만 아니라이를 수행하는 동안 많은 탐색 테스트를 수행합니다. 호기심이 많다는 것을 기억하십니까? 그리고 당신은 상상할 것입니다. 그리고 당신은 저항 할 수 없을 것이고, 당신이 상상 한 것을 참으로 할 것입니다.

아래의 이미지는 테스트 케이스 작성이 어떻게 단순화되었는지 보여줍니다.

간단한 테스트 케이스 작성

양식 작성 중이며 첫 번째 필드 작성이 완료되었습니다. 마우스가 다음 필드로 초점을 이동하기에는 너무 게으르다. '탭'키를 눌렀습니다. 다음 필드와 마지막 필드도 모두 채웠습니다. 이제 제출 버튼을 클릭해야합니다. 포커스는 여전히 마지막 필드에 있습니다.

죄송합니다. 실수로‘Enter’키를 눌렀습니다. 무슨 일이 있었는지 확인해 보겠습니다. 또는 제출 버튼이있는 경우 두 번 클릭합니다. 만족스럽지 않습니다. 너무 빨리 여러 번 클릭합니다.

눈치 채 셨나요? 의도 된 작업과 의도하지 않은 작업 모두 가능한 사용자 작업이 너무 많습니다.

테스트중인 애플리케이션을 100 % 다루는 모든 테스트 사례를 작성하는 데 성공하지 못할 것입니다. 이것은 탐색적인 방식으로 일어나야합니다.

애플리케이션을 테스트 할 때 새 테스트 케이스를 계속 추가합니다. 이전에 작성된 테스트 케이스가 없었던 버그에 대한 테스트 케이스입니다. 또는 테스트하는 동안 무언가가 사고 프로세스를 트리거하고 테스트 케이스 스위트에 추가하고 실행하려는 테스트 케이스가 몇 개 더 있습니다.

이 모든 것에도 불구하고 숨겨진 버그 . 버그가없는 소프트웨어는 신화입니다. 0에 가깝게 목표로 삼을 수는 있지만 위에서 본 예제 프로세스와 비슷하지만 이에 국한되지 않는 동일한 목표를 지속적으로 목표로 삼는 인간의 마음 없이는 불가능합니다.

적어도 오늘날에는 인간의 마음처럼 생각하고, 인간의 눈처럼 관찰하고, 인간처럼 질문하고 대답 한 다음 의도 된 행동과 의도하지 않은 행동을 수행하는 소프트웨어는 없습니다. 그런 일이 일어나더라도 누구의 마음과 생각과 눈이 모방할까요? 너나 내거야? 우리 인간도 같은 권리가 아닙니다. 우리는 모두 다릅니다. 그때?

자동화가 주변에있을 때 수동 테스트 필요 :

자동화 테스트는 오늘날 그 자체로 영광을 누리고 있으며 앞으로 더 많은 것을 가질 것이지만 수동 QA 테스트를 대체 할 수는 없습니다 (인간 / 탐사 테스트 읽기).

전에 들어 보셨을 겁니다.‘ 테스트를 자동화하지 않고 검사를 자동화합니다. ’. 이 문장은 자동화 테스트와 함께 수동 QA 테스트가 어디에 있는지에 대해 많이 설명합니다. 전 세계의 많은 유명 인사들이이 주제에 대해 글을 쓰고 말 했으므로 이에 대해 많이 강조하지 않겠습니다.

자동화는 다음과 같은 이유로 휴먼 테스트를 대체 할 수 없습니다.

  • 눈앞에서 (테스트하는 동안) 일어나는 모든 일에 대한 런타임 판단을 요구하며, 몇 가지 경우에는 뒤에서도 마찬가지입니다.
  • 명확하고 지속적인 관찰이 필요합니다.
  • 그것은 요구합니다 질문.
  • 조사가 필요합니다.
  • 추론이 필요합니다.
  • 테스트하는 동안 필요에 따라 계획되지 않은 작업이 필요합니다.

테스트는 세부 사항을 흡수하고, 처리하고, 작업을 명령하고, 인간의 마음과 인간처럼 수행 할 수있는 도구 / 기계로 대체 될 수 있습니다.이 모든 것은 런타임 및 가능한 모든 컨텍스트에서 가능합니다. 이 도구는 다시 모든 가능한 인간과 같아야합니다.

요컨대 인간 테스트는 대체 할 수 없습니다. 어쩌면 몇 년 후에 할리우드 공상 과학 영화가 그 영화에 가까워 보일지 모르지만 현실에서는 상상할 수있는 수백 년 동안 영화가 나오는 것을 볼 수 없습니다. 끝없는 가능성을 믿기 때문에 영원히 쓰지 않을 것입니다.

별도의 메모에서 실제로 수백 년이 지난 후에도 실제로 상상할 수있는 그림은 확실히 무서운 세상입니다. 변압기 시대. :)

= >> 추천 자료 – 최고의 수동 테스트 서비스 회사

자동화가 수동 테스트를 어떻게 보완합니까?

전에도 말했고 자동화는 더 이상 무시할 수 없다고 다시 말하고 있습니다. 지속적 통합, 지속적 배포, 지속적 배포가 필수 사항이되는 세상에서 지속적 테스트는 유휴 상태 일 수 없습니다. 어떻게해야하는지 방법을 찾아야합니다.

대부분의 경우 더 많은 인력을 배치하는 것은 장기적으로이 작업에 도움이되지 않습니다. 따라서 테스터 (테스트 리드 / 설계자 / 관리자)는 자동화 할 항목과 수동으로 수행해야하는 작업을 신중하게 결정해야합니다.

매우 정확한 테스트 / 검사를 작성하여 원래의 기대치에서 벗어나지 않고 자동화 할 수 있고 '연속 테스트'의 일부로 제품을 회귀하는 동안 사용할 수 있도록하는 것이 매우 중요 해지고 있습니다.

노트 : '연속 테스트'라는 용어의 연속이라는 단어는 위에서 사용한 동일한 접두사로 사용한 다른 용어와 유사한 조건부 및 논리적 호출의 대상이됩니다. 이 맥락에서 연속은 어제보다 더 자주, 더 빠르게 의미합니다. 의미 상 매초 또는 나노초를 의미 할 수 있습니다.

휴먼 테스터와 자동화 된 검사 (정확한 단계가있는 테스트, 해당 테스트의 예상 결과 및 종료 기준이 문서화 됨)가 완벽하게 일치하지 않으면 연속 테스트를 달성하는 것이 매우 어렵고 결과적으로 연속 통합, 연속 제공 및 연속 배포가 가능합니다. 더 어렵다.

나는 의도적으로 위의 테스트의 종료 기준이라는 용어를 사용했습니다. 우리의 자동화 수트는 더 이상 기존의 수트와 비슷할 수 없습니다. 실패하면 빨리 실패해야합니다. 그리고 빠르게 실패하게하려면 종료 기준도 자동화해야합니다.

예:

예를 들어 차단기 결함이있어 Facebook에 로그인 할 수 없습니다.

로그인 기능은 첫 번째 자동 검사가되어야하며 자동화 제품군은 상태 게시와 같이 로그인이 전제 조건 인 다음 검사를 실행해서는 안됩니다. 당신은 그것이 실패 할 수밖에 없다는 것을 잘 알고 있습니다. 따라서 더 빨리 실패하고 결과를 더 빨리 게시하여 결함을 더 빨리 해결할 수 있습니다.

다음은 이전에 들어 보셨을 것입니다. 모든 것을 자동화 할 수 없으며 그렇게해서는 안됩니다.

자동화 된 경우 상당한 이점이있는 테스트 사례 선택 인간 테스터에게 좋은 투자 수익을 제공합니다. 그 문제에 대해서는 모든 우선 순위 1 테스트 케이스를 자동화하고 가능하면 우선 순위 2를 자동화해야한다는 일반적인 규칙이 있습니다.

자동화는 구현하기 쉽지 않고 시간이 많이 걸리므로 최소한 우선 순위가 높은 경우를 완료 할 때까지는 우선 순위가 낮은 사례를 자동화하지 않는 것이 좋습니다. 자동화 할 항목을 선택하고 이에 집중하면 지속적으로 사용하고 유지 관리 할 때 애플리케이션 품질이 향상됩니다.

결론

지금 쯤이면 양질의 제품을 제공하기 위해 수동 / 인간 테스트가 얼마나 심하게 필요한지, 그리고 자동화가이를 보완하는 방법을 이해 했어야합니다.

QA 수동 테스트의 중요성을 받아들이고 그것이 특별한 이유를 아는 것은 우수한 수동 테스터가되기위한 첫 번째 단계입니다.

다가오는 수동 테스트 자습서에서는 수동 테스트를 수행하는 일반적인 접근 방식, 자동화 및 기타 여러 중요한 측면과 공존하는 방법을 다룰 것입니다.

이 시리즈의 전체 자습서 목록을 살펴보면 소프트웨어 테스팅에 대한 엄청난 지식을 얻게 될 것입니다.

https www google comyoutube to mp3

여러분의 의견을 듣고 싶습니다. 아래 의견란에 귀하의 생각 / 제안을 자유롭게 표현하십시오.

추천 도서

^