수동 테스트는 자동화된 도구를 사용하지 않고 테스트 사례를 수동으로 실행하는 소프트웨어 테스트 프로세스입니다. 최종 사용자의 관점에 따라 테스터가 수동으로 실행하는 모든 테스트 케이스입니다. 요구 사항 문서에 언급된 대로 애플리케이션이 작동하는지 여부를 확인합니다. 소프트웨어 애플리케이션을 거의 100% 완료하기 위해 테스트 케이스를 계획하고 구현합니다. 테스트 사례 보고서도 수동으로 생성됩니다.

수동 테스트는 소프트웨어의 눈에 보이는 결함과 숨겨진 결함을 모두 찾을 수 있으므로 가장 기본적인 테스트 프로세스 중 하나입니다. 소프트웨어에서 제공하는 예상 출력과 출력 간의 차이는 결함으로 정의됩니다. 개발자는 결함을 수정한 후 재테스트를 위해 테스터에게 전달했습니다.

자동 테스트 전에 새로 개발된 모든 소프트웨어에 대해 수동 테스트가 필수입니다. 이 테스트에는 많은 노력과 시간이 필요하지만 소프트웨어에 버그가 없다는 보장이 있습니다. 수동 테스트에는 수동 테스트 기술에 대한 지식이 필요하지만 자동화된 테스트 도구에 대한 지식은 필요하지 않습니다.

수동 테스트는 다음 중 하나 때문에 필수적입니다. 소프트웨어 테스팅 기본은 '100% 자동화는 불가능하다'이다.

수동 테스트가 필요한 이유

애플리케이션이 시장에 출시되고 최종 사용자가 애플리케이션을 사용하는 동안 불안정하거나 버그나 문제가 있거나 문제가 발생할 때마다.

이러한 종류의 문제에 직면하고 싶지 않다면 애플리케이션을 버그가 없고 안정적으로 만들고 고품질 제품을 클라이언트에게 제공하기 위해 한 차례의 테스트를 수행해야 합니다. 왜냐하면 애플리케이션에 버그가 없다면 최종 사용자는 더욱 편리하게 어플리케이션을 사용하실 수 있습니다.

테스트 엔지니어가 매뉴얼 테스트를 하면 최종 사용자 관점에서 애플리케이션을 테스트하고 제품에 더욱 익숙해질 수 있어 애플리케이션의 올바른 테스트 케이스를 작성하고 애플리케이션에 대한 빠른 피드백을 제공하는 데 도움이 됩니다.

수동 테스트 유형

수동 테스트에는 다양한 방법이 사용됩니다. 각 기술은 테스트 기준에 따라 사용됩니다. 수동 테스트 유형은 다음과 같습니다.

• 화이트 박스 테스트
• 블랙박스 테스트
• 회색 상자 테스트

화이트박스 테스트

화이트 박스 테스트는 개발자가 수행하며 테스트 엔지니어에게 코드를 제공하기 전에 코드의 모든 줄을 확인합니다. 테스트 중에 개발자가 코드를 볼 수 있으므로 화이트 박스 테스트라고도 합니다.

화이트박스 테스트에 대한 자세한 내용은 아래 링크를 참조하세요.

https://www.javatpoint.com/white-box-testing

블랙박스 테스트

블랙박스 테스트는 테스트 엔지니어가 수행하며 고객/클라이언트의 요구에 따라 애플리케이션이나 소프트웨어의 기능을 확인할 수 있습니다. 여기서는 테스트를 수행하는 동안 코드가 표시되지 않습니다. 이것이 바로 블랙박스 테스트라고 알려진 이유입니다.

블랙박스 테스트에 대한 자세한 내용은 아래 링크를 참조하세요.

https://www.javatpoint.com/black-box-testing

그레이 박스 테스트

그레이박스 테스트는 화이트박스와 블랙박스 테스트를 합친 것입니다. 코딩과 테스트를 모두 아는 사람이 수행할 수 있습니다. 그리고 한 사람이 애플리케이션에 대해 화이트박스 테스트와 블랙박스 테스트를 모두 수행하는 경우를 그레이박스 테스트라고 합니다.

그레이박스 테스트에 대한 자세한 내용을 보려면 아래 링크를 참조하세요.

https://www.javatpoint.com/grey-box-testing

수동 테스트 수행 방법

• 첫째, 테스터는 소프트웨어와 관련된 모든 문서를 관찰하여 테스트 영역을 선택합니다.
• 테스터는 고객이 명시한 모든 요구 사항을 다루기 위해 요구 사항 문서를 분석합니다.
• 테스터는 요구사항 문서에 따라 테스트 케이스를 개발합니다.
• 모든 테스트 케이스는 블랙박스 테스트와 화이트박스 테스트를 사용하여 수동으로 실행됩니다.
• 버그가 발생하면 테스트 팀에서 개발 팀에 알립니다.
• 개발팀은 버그를 수정하고 재테스트를 위해 소프트웨어를 테스트팀에 전달했습니다.

소프트웨어 빌드 프로세스

• 요구 사항이 수집되면 서로 다른 두 팀 개발 및 테스트 팀에 제공됩니다.
• 요구 사항을 얻은 후 관련 개발자는 코드 작성을 시작합니다.
• 그 동안 테스트 엔지니어는 요구 사항을 이해하고 필요한 문서를 준비합니다. 지금까지 개발자는 코드를 완성하고 버전 제어 도구 .
• 그 후 UI의 코드가 변경되고 이러한 변경 사항은 별도의 팀에서 처리됩니다. 팀 구성 .
• 이 빌드 팀은 코드를 가져와 빌드 도구를 사용하여 코드 컴파일 및 압축을 시작합니다. 일단 출력을 얻으면 출력은 다음과 같은 zip 파일로 이동됩니다. 짓다 (애플리케이션 또는 소프트웨어). 각 빌드에는 (B001, B002)와 같은 고유 번호가 있습니다.
• 그런 다음 이 특정 빌드가 테스트 서버에 설치됩니다. 그 후, 테스트 엔지니어는 테스트 URL을 통해 이 테스트 서버에 액세스하고 애플리케이션 테스트를 시작합니다.
• 테스트 엔지니어가 버그를 발견하면 해당 개발자에게 보고됩니다.
• 그런 다음 개발자는 테스트 서버에서 버그를 재현하고 버그를 수정한 다음 제어 버전 도구에 코드를 다시 저장하고 새로 업데이트된 파일을 설치하고 이전 파일을 제거합니다. 이 프로세스는 안정적인 빌드를 얻을 때까지 계속됩니다.
• 안정적인 빌드를 얻으면 고객에게 전달됩니다.

참고1

• 제어 버전 도구에서 파일을 수집한 후에는 빌드 도구를 사용하여 고급 언어에서 기계 수준 언어로 코드를 컴파일합니다. 컴파일 후 파일 크기가 커지면 해당 파일을 압축하여 테스트 서버에 덤프합니다.
• 이 과정은 다음에 의해 수행됩니다. 팀 구성 , 개발자 (빌드 팀이 없으면 개발자가 할 수 있음) 또는 테스트 리드 (빌드팀이 직접 zip을 처리하고 테스트 서버에 애플리케이션을 설치한 후 테스트 엔지니어에게 알릴 경우)
• 일반적으로 모든 버그에 대해 새로운 빌드를 얻을 수는 없습니다. 그렇지 않으면 대부분의 시간은 빌드를 만드는 데만 낭비됩니다.

노트 2

팀 구성

빌드팀의 주요 업무는 애플리케이션이나 빌드를 생성하고 고급 언어를 저급 언어로 변환하는 것입니다.

짓다

코드를 응용프로그램 형식으로 변환하는 데 사용되는 소프트웨어입니다. 그리고 안정화될 때까지 테스트 목적으로 테스트 엔지니어에게 전달되는 일부 기능 및 버그 수정 세트로 구성됩니다.

버전 관리 도구

다음과 같은 목적으로 사용되는 소프트웨어 또는 애플리케이션입니다.

• 이 도구에서는 다양한 유형의 파일을 저장할 수 있습니다.
• 동일한 로그인 자격 증명을 사용하여 도구에서 파일에 액세스하기 때문에 항상 안전합니다.
• 도구의 주요 목적은 기존 파일에 대한 변경 사항을 추적하는 것입니다.

빌드 프로세스의 예

실제 시나리오에서 프로세스 작업을 구축하는 방법을 이해하기 위해 한 가지 예를 살펴보겠습니다.

테스트 엔지니어는 버그를 발견하자마자 개발자에게 보내며 분석하는 데 시간이 필요합니다. 그 후에는 버그만 수정합니다. (테스트 엔지니어는 버그 수집을 제공할 수 없습니다.)

개발자는 자신의 시간에 따라 얼마나 많은 버그를 수정할 수 있는지 결정합니다. 그리고 테스트 엔지니어는 테스트를 중단할 여유가 없기 때문에 필요에 따라 어떤 버그를 먼저 수정해야 하는지 결정합니다.

그리고 메일을 받은 테스트 엔지니어는 어떤 버그가 수정되었는지만 알 수 있습니다. 버그 수정 목록 .

첫 번째 빌드에서 개발자가 다양한 기능에 대한 코드를 작성해야 하기 때문에 시간이 늘어납니다. 그리고 결국에는 버그 수정만 할 수 있게 되고 그 일수는 줄어들게 됩니다.

노트 3

테스트 주기

테스트 주기는 테스트 엔지니어가 모든 빌드를 테스트하도록 주어진 시간입니다.

두 빌드의 차이점

한 빌드에서 발견된 버그는 테스트 엔지니어의 요구 사항에 따라 향후 빌드에서 수정될 수 있습니다. 각각의 새로운 빌드는 이전 빌드의 수정된 버전이며 이러한 수정은 버그 수정이나 일부 새로운 기능 추가일 수 있습니다.

새 빌드를 받는 빈도

처음에는 매주 빌드를 받았지만, 최근 테스트 단계에서 애플리케이션이 안정되면 3일, 이틀에 한 번 또는 매일 새로운 빌드를 받곤 했습니다.

우리가 얻는 빌드 수

프로젝트 기간을 1년으로 생각하면 22~26개의 빌드를 얻었습니다.

ROM

버그 수정이 완료되면

일반적으로 우리는 테스트 주기가 완료된 후에만 버그 수정을 이해합니다. 또는 버그 수집이 한 빌드에서 수정되고 다음 빌드에서 인계됩니다.

수동 테스트의 장점

• 블랙박스 방식을 사용하면 프로그래밍 지식이 필요하지 않습니다.
• 동적으로 변화하는 GUI 디자인을 테스트하는 데 사용됩니다.
• 테스터는 실제 사용자로서 소프트웨어와 상호 작용하여 유용성과 사용자 인터페이스 문제를 발견할 수 있습니다.
• 이는 소프트웨어에 100% 버그가 없음을 보장합니다.
• 비용 효율적입니다.
• 새로운 테스터가 배우기 쉽습니다.

수동 테스트의 단점

• 많은 인력이 필요합니다.
• 시간이 많이 걸립니다.
• 테스터는 자신의 기술과 경험을 바탕으로 테스트 케이스를 개발합니다. 모든 기능을 다루었는지 여부에 대한 증거는 없습니다.
• 테스트 케이스는 다시 사용할 수 없습니다. 새로운 소프트웨어마다 별도의 테스트 케이스를 개발해야 합니다.
• 테스트의 모든 측면에 대한 테스트를 제공하지는 않습니다.
• 두 팀이 함께 일하다 보니 서로의 동기를 이해하기 어려울 때도 있고, 진행 과정을 오도할 수도 있다.

수동 테스트 도구

수동 테스트에서는 단위, 통합, 보안, 성능 및 버그 추적과 같은 다양한 유형의 테스트에서 Jira, Bugzilla, Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube 등과 같은 다양한 도구를 사용할 수 있습니다. 시장. 일부 도구는 오픈 소스이고 일부는 상업용입니다.

테스트 도구에 대한 자세한 내용은 아래 링크를 참조하세요.

https://www.javatpoint.com/software-testing-tools

하나씩 이해해 봅시다.

로드러너

가장 일반적으로 사용되는 성능 테스트 도구입니다. LoadRunner는 주로 광범위한 절차, 접근 방식 수 및 응용 프로그램 환경에 대한 성능 테스트를 지원하는 데 사용됩니다.

LoadRunner 도구를 실행하는 주요 목적은 성능 문제의 가장 일반적인 원인을 신속하게 분류하는 것입니다.

LoadRunner의 특징

• LoadRunner 도구에는 n개의 응용 프로그램이 포함되어 있어 보고서를 이해하고 설명하는 데 걸리는 시간이 줄어듭니다.
• LoadRunner 도구를 사용하면 철저한 성능 테스트 보고서를 얻을 수 있습니다.
• 분산 로드 테스트 비용을 절감하고 배포 추적을 위한 운영 도구도 제공합니다.

감귤류

Citrus는 가장 일반적으로 사용되는 테스트 프레임워크인 통합 테스트 도구입니다. 에 쓰여 있습니다 자바 프로그래밍 언어. 주로 서버 측과 클라이언트 측에 요청 및 응답하고 XML JSON 파일의 유효성을 검사하는 데 사용됩니다.

엔드투엔드 사용 사례 테스트를 수행하기 위해 Citrus는 여러 HTTP, JMS 및 SOAP 프로토콜을 지원합니다.

감귤의 특성

다음은 Citrus 도구의 중요한 기능 중 일부입니다.

• 메시지를 보내고 받는 데 사용됩니다.
• Citrus는 오픈 소스와 시장에서 라이선스를 모두 취득한 제품으로 제공됩니다.
• 저렴한 비용의 솔루션을 제공합니다.
• Citris 도구를 사용하여 데이터베이스를 인증할 수 있습니다.
• 메시지 순서를 설명하고 테스트 계획을 제공하며 테스트 적용 범위를 문서화합니다.
• 메시지를 생성하고 응답을 확인합니다.

기력

ZAP는 오픈 소스 웹 애플리케이션 보안 스캐너입니다. 그것은 다음을 의미한다. Zed 공격 프록시 . 다른 도구와 마찬가지로 JAVA 프로그래밍 언어 . 가장 효과적입니다 개방형 웹 애플리케이션 보안 프로젝트 [OWASP].

ZAP의 특징

• Windows, Linux, OS X 등 다양한 운영 체제를 지원합니다.
• 플러그인 기반 아키텍처를 가지고 있습니다.
• 여기에는 새로운 기능이나 업데이트된 기능을 추가할 수 있는 온라인 마켓플레이스가 포함되어 있습니다.
• ZAP의 GUI 제어판은 사용하기 쉽습니다.

수녀

NUnit은 가장 자주 사용되는 단위 테스트 도구 중 하나입니다. 이는 오픈 소스 도구이며 주로 다음에서 파생됩니다. JUnit .

본문에 완전 적혀있었는데 C# 프로그래밍 언어 그리고 모두에게 적합 .Net 언어 .

즉, NUnit 도구는 많은 .Net 언어 품질의 장점을 활용할 수 있도록 완전히 재설계되었다고 말할 수 있습니다. 예를 들어:

반사 관련 기능. 기타 사용자 정의 속성.

NUnit의 특징

• 어설션을 어드밴티지 클래스의 정적 메서드로 허용합니다.
• 데이터 기반 테스트를 유지합니다.
• .NET 코어 Xamarin 모바일, Silverlight 및 효율적인 프레임워크와 같은 여러 플랫폼을 지원합니다.
• NUnit의 기능은 테스트를 동시에 실행하는 데 도움이 됩니다.
• 콘솔 실행기를 사용하여 테스트를 로드하고 실행합니다.

지라

가장 일반적으로 사용되는 버그 추적 도구는 다음과 같습니다. 지라 , 이는 오픈 소스 도구입니다. 버그 추적, 프로젝트 관리, 이슈 추적에 사용됩니다.

이 도구를 사용하면 테스트 엔지니어가 생성한 소프트웨어와 관련된 모든 종류의 버그나 결함을 쉽게 추적할 수 있습니다.

JIRA의 특징

• 시간을 절약해 주는 도구입니다.
• Jira는 결함과 문제를 추적하는 데 사용됩니다.
• 문서화 작업을 설정하는 데 사용됩니다.
• Jira는 문서 개선을 추적하는 데 매우 유용한 도구입니다.

Jira 도구에 대한 전체 정보를 얻으려면 아래 링크(https://www.javatpoint.com/jira-tutorial)를 참조하십시오.

소나큐브

수동 테스트의 또 다른 테스트 도구는 지속적인 코드 품질과 코드 보안을 통해 작업 흐름을 개선하는 SonarQube입니다. 플러그인을 사용하여 유연하게 사용할 수 있습니다.

이는 완전히 JAVA 프로그래밍 언어로 작성되었습니다. Ant, Maven, Gradle, MSBuild 및 지속적인 통합 도구와의 완전 자동화된 평가 및 통합을 제공합니다. SonarQube에는 지표 기록을 기록하고 진화 그래프를 제공하는 기능이 있습니다.

소나큐브의 특징

다음은 SonarQube 도구의 중요한 기능 중 일부입니다:

• C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL 등과 같은 여러 프로그래밍 언어를 지원합니다.
• GNU Lesser General Public License에 따라 Sonarqube는 무료로 사용할 수 있습니다.
• SonarQube는 GitHub, Active Directory, LDAP 등과 같은 중요한 외부 도구와 제휴하고 있습니다.
• SonarQube는 Visual Studio, Eclipse, IntelliJ IDEA 개발 환경과 통합되었습니다. SonarLint 플러그인.

JMeter

JMeter는 정적 및 동적 리소스와 동적 웹 애플리케이션의 성능을 테스트하는 데 사용되는 오픈 소스 도구입니다.

이는 기능 테스트 동작을 로드하고 애플리케이션 성능을 측정하기 위해 JAVA 애플리케이션에서 완벽하게 설계되었습니다.

이는 사용자나 개발자가 다른 애플리케이션 개발을 위해 소스 코드를 사용하는 것을 용이하게 합니다.

JMeter의 특징

다음은 JMeter의 몇 가지 필수 특성입니다.

• 이는 플랫폼 독립적이며 다음과 같은 JVM을 허용합니다. 윈도우, 맥, 리눅스 등
• 이는 대화형이고 간단한 사용자 친화적인 GUI를 지원합니다.
• 여러 유형의 서버에서 성능 테스트를 로드하는 것은 놀라울 정도로 확장성이 뛰어납니다.

JMeter에 대한 자세한 내용은 아래 링크를 참조하세요.

https://www.javatpoint.com/jmeter-tutorial.

버그즈와 함께

수동 테스트에 사용되는 또 다른 버그 추적 도구는 다음과 같습니다. 버그즈와 함께 .

이는 많은 조직에서 애플리케이션의 다양한 버그를 추적하기 위해 가장 널리 사용됩니다.

Bugzilla는 고객과 클라이언트가 결함을 추적하는 데 도움이 되는 오픈 소스 도구입니다. Bugzilla는 또한 ALM, Quality Center 등과 같은 다른 테스트 사례 관리 도구를 쉽게 연결할 수 있기 때문에 테스트 관리 도구로 간주됩니다.

버그질라의 특징

Bugzilla에는 버그를 쉽게 보고하는 데 도움이 되는 몇 가지 추가 기능이 있습니다.

• Windows, Linux, Mac 등 다양한 운영체제를 지원합니다.
• Bugzilla의 도움으로 우리는 다양한 형식으로 버그를 나열할 수 있습니다.
• 사용자 기본 설정은 이메일 알림을 측정할 수 있습니다.
• Bugzilla에는 고급 검색 기능이 있습니다.

사마귀

Mantis는 웹 기반 버그 추적 시스템입니다. ManitsBT는 다음을 의미합니다. 맨티스 버그 추적기 . 소프트웨어 결함을 추적하는 데 사용되며 PHP 프로그래밍 언어로 수행됩니다. 또한 오픈 소스 도구이기도 합니다.

맨티스의 특징

특정 도구의 표준 기능 중 일부는 다음과 같습니다.

• 이 도구의 도움으로 우리는 전체 텍스트 검색에 접근할 수 있습니다.
• 문제에 대한 변경 사항을 감사 추적합니다.
• 개정 관리 시스템 통합을 제공합니다.
• 텍스트 필드 및 메모의 개정 제어

버그 추적 도구에 대한 자세한 내용을 보려면 다음 링크를 참조하세요. https://www.javatpoint.com/defect-or-bug-tracking-tool .

테시

또 다른 통합 테스트 도구는 테시 , 임베디드 소프트웨어에 대한 통합 및 단위 테스트를 수행하는 데 사용됩니다. 또한 소프트웨어나 애플리케이션의 코드 적용 범위를 찾는 데도 도움이 됩니다.

비즈니스 요구 사항, 테스트 관리, 적용 범위 수량, 추적성 등 전체 테스트 조직을 쉽게 관리할 수 있습니다.

Tessy에는 다음과 같은 세 가지 주요 기능이 포함되어 있습니다.

• 테스트 인터페이스 편집기(TIE)
• 테스트 데이터 편집기(TDE)
• 작업 공간.

테시의 특징

TESSY의 표준 기능은 다음과 같습니다.

• 테스트 실행 결과에 대한 테스트 보고서를 생성합니다.
• C, C++ 등 다양한 프로그래밍 언어를 지원합니다.
• Tessy는 함수의 인터페이스를 평가하고 해당 함수에서 사용되는 변수를 설명하는 데 사용됩니다.

통합 테스트 도구에 대한 자세한 내용은 다음 링크를 참조하세요: https://www.javatpoint.com/integration-testing-tools.

개요

이 기사에서 우리는 다음에 대한 자세한 정보를 보았습니다. 수동 테스트의 정의, 수동 테스트의 필요성, 수동 테스트 유형, 수동 테스트 도구, 수동 테스트 프로세스 및 몇 가지 중요한 이점과 단점을 포함하는 수동 테스트.

마지막으로 테스트 엔지니어가 매우 끈기 있고 혁신적이며 대응력이 필요한 프로세스라고 말할 수 있습니다.

수동 테스트에서 테스트 엔지니어는 최종 사용자 해석처럼 생각하고 수행해야 합니다.

수동 테스트를 구현하려면 테스트 엔지니어에게 생산적인 기술과 상상력이 필요합니다. 그리고 특정 애플리케이션을 테스트하려면 다양한 상황이나 시나리오를 생각해야 합니다.

현재 자동화 테스트를 통해 거의 모든 애플리케이션을 테스트할 수 있지만, 소프트웨어 테스트의 기반이기 때문에 여전히 수동 테스트가 필요합니다.